Using an IP core licensed under the LGPL

[y_p_w]

Phil Tomson wrote:

In article <591da479.0408051151.3a1491d4@posting.google.com>,
y_p_w <y_p_w@hotmail.com> wrote:

So I'll just sum up what we're looking at, what we'll do with it,
and what we can or would rather not do:

1) I've located an open-source Verilog description (released under
the LGPL) of a hardware function we'd like to use.
2) We would have no problem releasing our modifications of this
code or giving credit to the original author; it only seems
fair.


That may or may not be required, however it's nice that you're flexible in
this area.


3) My employer would be extremely hesistant to release our other
HDL source code used in this design. Like most companies in
our industry, we are in the business of selling proprietary
hardware.


I doubt you would have to release the rest of your HDL code.


4) Much of the LGPL language doesn't seem to apply to the
hardware development flow.

Is this doable? It sounds like the LGPL was meant to allow for
open-source software to be used in otherwise proprietary products.
However - using the LGPL seems to be navigating a minefield in
this respect. The standard GPL makes things extremely clear -
you don't use it for proprietary products. In a worst case
situation, might it be possible to ask the author for permission
to use it under the terms of a different license (modified BSD
perhaps)?


It seems that you're in uncharted territory here. I suspect that, as you
say, the LGPL doesn't really apply here to your final product.

Essentially, you're taking an LGPL component written in an HDL and
synthesizing it to another form that gets realized in hardware. The
analogy _could_ be made to compiling and linking in the software world,
however, the language of the LGPL (as you note) does seem to refer to
software (object files and shared libraries) not hardware.

One thing that the LGPL is often interpreted to exclude is dynamic linking
- you apparently can't produces a dll/so file and dynamically link against
it. However, static linking is allowed by the LGPL. I don't know if
that kind of analogy can be stretched to your situation with hardware.
I would tend to see what you're doing as being closer to 'static linking'
than it is to 'dynamic linking'.

If I were you I would contact the author of your module and ask him what
his intent was for putting it under the LGPL. It looks like perhaps we
need some different type of Open Source license for hardware. As you say,
the GPL makes it clear that you can't use said component in a proprietary
system, but the LGPL seems unclear in this context.

Thanks. The core I was looking at was hosted at opensource.org.
The irony is that their mission statement mentions the LGPL as
the basis for their preferred license. Here's part of their
mission statement:

<http://opencores.org/projects.cgi/web/opencores/mission>

"Our main objective is to design and publish core designs under a
license for hardware modelled on the Lesser General Public License
(LGPL) for software. We are committed to the ideal of freely
available, freely usable and re-usable open source hardware."

Several of their authors don't seem to have used this psuedo-
LGPL license they refer to, but the actual LGPL itself.

 

[Isaac]

On Sat, 7 Aug 2004 12:32:20 +0200, roller <trash_nospam@hotmail.com> wrote:

a dumb question, how could anybody prove that you used their HDL code in an
ASIC?, let's say it's an Ethernet core, if you dont explicitily mention you
used somebody else's code, i dont think there's a way to know whether the
ASIC contains code you wrote, or that somebody else wrote.

Even if they could do so, I'm not convinced that hardware generated

without permission from an HDL description infringes the HDL code.

Isaac

 

[Phil Tomson]

In article <cf2b3u$2on2$1@avanie.enst.fr>,
roller <trash_nospam@hotmail.com> wrote:

"y_p_w" <y_p_w@hotmail.com> escribió en el mensaje
news:591da479.0408051151.3a1491d4@posting.google.com...
Hi-

My manager asked me to try and find any techniques or possibly
available cores for a certain hardware function. I believe that
I've found what I'm looking for available as a Verilog IP core
released under the GNU Lesser Public License, V2.1. The core
seems to work very well, and is probably better than what I could
have produced myself. We plan on using this core as a distinct
component in a larger design.

My basic problem is that the LGPL doesn't seem to be well suited
to a "hardware description languages" such as Verilog or VHDL
which are really abstractions of electronic functions rather than
"software" per se. For the non-hardware guys, the HDL code is
typically "synthesized" into gates/transistors that eventually
become part of the semiconductor layout. The LGPL refers to terms
such as "object code" and "executables" that simply don't apply to
our hardware production flow. In essence, the final hardware
**IS** the executable.


a dumb question, how could anybody prove that you used their HDL code in an
ASIC?, let's say it's an Ethernet core, if you dont explicitily mention you
used somebody else's code, i dont think there's a way to know whether the
ASIC contains code you wrote, or that somebody else wrote.

I was thinking the same thing - How could anyone find out? If you're
releasing an ASIC and not RTL code, then it's impossible to reverse
engineer the ASIC in order to discover the HDL code that was originally
used to describe the design.

But the original poster is trying to be honest & legal.

Phil

 

[Barry Margolin]

In article <cf31a5013nr@enews3.newsguy.com>,
ptkwt@aracnet.com (Phil Tomson) wrote:

I was thinking the same thing - How could anyone find out? If you're
releasing an ASIC and not RTL code, then it's impossible to reverse
engineer the ASIC in order to discover the HDL code that was originally
used to describe the design.

One could probably say the same thing about executable object code vs.
the high-level language source, especially when highly optimizing
compilers are used. Yet that doesn't prevent people from being
concerned about copyright violation of software.

But I suspect that someone *could* reverse engineer an ASIC, just as
people have been able to decompile object code. You wouldn't get back
the exact source code that was used, but you should be able to see
enough of its structure to determine if it's very similar to the code
whose infringement is suspected.

In a world where we've managed to reverse-engineer the genome, object
code and ASIC circuits are relative child's play.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

 

[roller]

"Barry Margolin" <barmar@alum.mit.edu> escribió en el mensaje
news:barmar-F4C159.13374107082004@comcast.dca.giganews.com...

In article <cf31a5013nr@enews3.newsguy.com>,
ptkwt@aracnet.com (Phil Tomson) wrote:

I was thinking the same thing - How could anyone find out? If you're
releasing an ASIC and not RTL code, then it's impossible to reverse
engineer the ASIC in order to discover the HDL code that was originally
used to describe the design.

One could probably say the same thing about executable object code vs.
the high-level language source, especially when highly optimizing
compilers are used. Yet that doesn't prevent people from being
concerned about copyright violation of software.

well they can be concerned, but has anybody actually proved copyright
violation or patent infringement from executable code?
like i read in another post, it seems that windows networking sucked before
they started "using" TCP/IP from BSD

But I suspect that someone *could* reverse engineer an ASIC, just as
people have been able to decompile object code. You wouldn't get back
the exact source code that was used, but you should be able to see
enough of its structure to determine if it's very similar to the code
whose infringement is suspected.

yes, but let's say it's a Ethernet controller, if any controller wants to
comply with the standard it'll implement certain functionality, which in
principle, should be the same for all controllers, thus making very hard to
distinguish between two implementations.

In a world where we've managed to reverse-engineer the genome, object
code and ASIC circuits are relative child's play.

well it depends on what you call "reverse-engineer", if it's just making a
map of the whole DNA sequence, or if it's actually understanding it all, to
know what to change to do something, i think we're pretty far from the
second.
but i agree that reverse-engineer an ASIC can be done under certain
circunstances, i believe smartcard crypto chips are protected against
physical reverse engineer though.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

 

[roller]

"Phil Tomson" <ptkwt@aracnet.com> escribió en el mensaje
news:cf31a5013nr@enews3.newsguy.com...

<snip>

I was thinking the same thing - How could anyone find out? If you're
releasing an ASIC and not RTL code, then it's impossible to reverse
engineer the ASIC in order to discover the HDL code that was originally
used to describe the design.

But the original poster is trying to be honest & legal.

Phil

wow! well some big companies should learn from that then...$CO, M$, etc..
in anycase, i believe that people releasing the source code of something are
already agreeing with "not caring" who use it, whether it's because they
just dont care, or because they are altruists or whatever, the thing is that
i dont believe they'd prosecute anybody using their code, they just rely on
the people using their code to be honest (as the OP) enough to choose to use
it or not according to the license and rights the authors gave, GPL, LGPL,
etc
however i guess some of them might have some principles and beliefs and they
might not want their code to be used commercially.

 

[Byron A Jeff]

In article <cf12g501i0q@enews3.newsguy.com>,
Phil Tomson <ptkwt@aracnet.com> wrote:
-In article <591da479.0408051151.3a1491d4@posting.google.com>,
-y_p_w <y_p_w@hotmail.com> wrote:
->

It's funny. I spent last night having a very similar LGPL discussion on
the PICLIST mailing list about LGPL'ed libraries for embedded systems.

I decided to check in here because I think you may have gotten some bad
moo-shoo here.

->So I'll just sum up what we're looking at, what we'll do with it,
->and what we can or would rather not do:
->
->1) I've located an open-source Verilog description (released under
-> the LGPL) of a hardware function we'd like to use.
->2) We would have no problem releasing our modifications of this
-> code or giving credit to the original author; it only seems
-> fair.

Glad you think it's fair. The LGPL makes it a requirement.

-
-That may or may not be required, however it's nice that you're flexible in
-this area.

It is required. Changes to LGPL'ed source are essentially GPL in nature.
You must release the changes (or make a written offer to do so) to anyone who
receives the final work.

-
->3) My employer would be extremely hesistant to release our other
-> HDL source code used in this design. Like most companies in
-> our industry, we are in the business of selling proprietary
-> hardware.

It's the standard clash of the titans between free and non-free components.

-
-I doubt you would have to release the rest of your HDL code.

This is bad moo-shoo. I'll clarify in a bit.

-
->4) Much of the LGPL language doesn't seem to apply to the
-> hardware development flow.
->
->Is this doable? It sounds like the LGPL was meant to allow for
->open-source software to be used in otherwise proprietary products.
->However - using the LGPL seems to be navigating a minefield in
->this respect. The standard GPL makes things extremely clear -
->you don't use it for proprietary products. In a worst case
->situation, might it be possible to ask the author for permission
->to use it under the terms of a different license (modified BSD
->perhaps)?
-
-It seems that you're in uncharted territory here. I suspect that, as you
-say, the LGPL doesn't really apply here to your final product.
-
-Essentially, you're taking an LGPL component written in an HDL and
-synthesizing it to another form that gets realized in hardware. The
-analogy _could_ be made to compiling and linking in the software world,
-however, the language of the LGPL (as you note) does seem to refer to
-software (object files and shared libraries) not hardware.

It's analogous. So you really have to step back to the intent of the rights
that the LGPL attempts to impart. Again I'll get to this a bit later.

-
-One thing that the LGPL is often interpreted to exclude is dynamic linking
-- you apparently can't produces a dll/so file and dynamically link against
-it. However, static linking is allowed by the LGPL. I don't know if
-that kind of analogy can be stretched to your situation with hardware.

It can. But that's all mechanism. The question is what is the right that
dynamic/static linking facilitates?

-I would tend to see what you're doing as being closer to 'static linking'
-than it is to 'dynamic linking'.

Actually I'll bet money it's worse than that. Hence the bad moo-shoo above.

-
-If I were you I would contact the author of your module and ask him what
-his intent was for putting it under the LGPL. It looks like perhaps we
-need some different type of Open Source license for hardware. As you say,
-the GPL makes it clear that you can't use said component in a proprietary
-system, but the LGPL seems unclear in this context.

OK. Enough dancing. Here's the rights that the LGPL attempts to impart:

1) Changes and attribution of the LGPL code follows GPL guidelines. In short
exactly point #2 above that the OP made. No problem here.

2) The second right I've dubbed the rebuild right. It's outlined in section
6 of the LGPL. In short it states that the end user must have access to
any items required to rebuild the system with an improved or updated LGPL
component. Note this makes the mechanism fuzzy. However it's what's going to
cause the death of this trail.

Let me give three quick examples, then proceed onto the current problem:

1) Typical Linux system has an app which uses an LGPL library. It's dynamically
linked. New library comes out. User installs and the app now uses the new
library. In effect the user can "rebuild" the system with a new library by
installing the library and running the app. The app can be a binary and no
source for that app (which I affectionately call yourcode) is required to
be released.

2) Typical embedded system consist of an assembler and linker which can link
libraries in. You have an embedded application that uses an LGPL library.
A newer better version of the library comes out. The user has the right
(and knows about it because the developer of yourcode had to inform them)
to rebuild the system using the newer library. Depending on the context the
user may have to be provided an linkable object file of yourcode, and possibly
even the linker too. Note that even if the user doesn't have any way to
upload the new firmware into the hardware, they still have the right to
rebuild the firmware with the newer library.

3) Another embedded system uses a compiler to generate code. No linker exists.
The JAL project (http://jal.sf.net) is a perfect example. Libraries are LGPL
licensed. Firmware is built by including the library into the yourcode
application and then compiling the whole shebang. Newer better version of the
library comes out. The user has rebuild rights. So the yourcode developer
has to provide the user the items necessary to rebuild. But since there's
no linker, the only way to rebuild yourcode with a new library is to use
the source of yourcode. So you must deliver yourcode's source to the user
to satisfy the rebuild right.

So now the question is how does the rebuild right fit within the context
of the Verilog build process? Since the core is licensed under the LGPL, users
have the right to rebuild their application with newer cores. Not that they'd
have anyway of loading this new combo to actual hardware. But the right
is delineated in the license and so in order to satisfy it, you must facilitate
the user's rebuild right.

Now it's all very silly. The LGPL simply wasn't written to be equipped to
handle the situation. But that's the author's licensing terms and you have
an obligation to abide by the probably unintended consequences of the
application of that license.

I'll bet money that the original code author really wanted to retain the
GPL nature of changes to their code, while dismissing the rebuild right.

But as written, you'd have to deliver to the end user whatever code and
tools rquired to get them to rebuild with an updated core.

If I were you I'd certianly go and ask the original authors about their intent.
I'd probably also ask them to relicense.

The need for an Embedded GPL needs to exists for situations like this. It
would have the core of the LGPL but needs language to squash these really
extraneous issues. Section 6 needs to be rewritten to modify or
eliminate the rebuild right.

Just my two cents. And watch out for that moo-shoo.

BAJ

 

[Byron A Jeff]

In article <cf2b3u$2on2$1@avanie.enst.fr>,
roller <trash_nospam@hotmail.com> wrote:
-
-"y_p_w" <y_p_w@hotmail.com> escribió en el mensaje
-news:591da479.0408051151.3a1491d4@posting.google.com...
-> Hi-
->
-> My manager asked me to try and find any techniques or possibly
-> available cores for a certain hardware function. I believe that
-> I've found what I'm looking for available as a Verilog IP core
-> released under the GNU Lesser Public License, V2.1. The core
-> seems to work very well, and is probably better than what I could
-> have produced myself. We plan on using this core as a distinct
-> component in a larger design.
->
-> My basic problem is that the LGPL doesn't seem to be well suited
-> to a "hardware description languages" such as Verilog or VHDL
-> which are really abstractions of electronic functions rather than
-> "software" per se. For the non-hardware guys, the HDL code is
-> typically "synthesized" into gates/transistors that eventually
-> become part of the semiconductor layout. The LGPL refers to terms
-> such as "object code" and "executables" that simply don't apply to
-> our hardware production flow. In essence, the final hardware
-> **IS** the executable.
->
-
-a dumb question, how could anybody prove that you used their HDL code in an
-ASIC?, let's say it's an Ethernet core, if you dont explicitily mention you
-used somebody else's code, i dont think there's a way to know whether the
-ASIC contains code you wrote, or that somebody else wrote.

Advocating theft be deception are we? "Nobody can find out, so why not
just steal it?!!" I love to see situational ethics in action.

The LGPL author wants their stuff to be used. They also would like to get
updates to their core. They probably didn't realize the unintended consequences
of the LGPL whenb applied into embedded context.

But toe sweep it all under the rug isn't the right way to handle it.

You should simply go talk to the core's author, and ask for a copy relicensed
so that it can be used. The ZPL or BSD license comes to mind. Or write a
license similar to the LGPL but from section 6. In short, usage of the core
is unlimited, changes to the source of the core must be distributed along
with the core, and nothing that uses the core unmodified is subject to the
LGPL no matter the mechanism of comingling the free and non free code.

Then it would be a done deal.

BAJ
-
-

 

[roller]

"Byron A Jeff" <byron@cc.gatech.edu> escribió en el mensaje
news:cf4avs$ft6@cleon.cc.gatech.edu...

In article <cf2b3u$2on2$1@avanie.enst.fr>,
roller <trash_nospam@hotmail.com> wrote:
-
-"y_p_w" <y_p_w@hotmail.com> escribió en el mensaje
-news:591da479.0408051151.3a1491d4@posting.google.com...
-> Hi-
-
-> My manager asked me to try and find any techniques or possibly
-> available cores for a certain hardware function. I believe that
-> I've found what I'm looking for available as a Verilog IP core
-> released under the GNU Lesser Public License, V2.1. The core
-> seems to work very well, and is probably better than what I could
-> have produced myself. We plan on using this core as a distinct
-> component in a larger design.
-
-> My basic problem is that the LGPL doesn't seem to be well suited
-> to a "hardware description languages" such as Verilog or VHDL
-> which are really abstractions of electronic functions rather than
-> "software" per se. For the non-hardware guys, the HDL code is
-> typically "synthesized" into gates/transistors that eventually
-> become part of the semiconductor layout. The LGPL refers to terms
-> such as "object code" and "executables" that simply don't apply to
-> our hardware production flow. In essence, the final hardware
-> **IS** the executable.
-
-
-a dumb question, how could anybody prove that you used their HDL code in
an
-ASIC?, let's say it's an Ethernet core, if you dont explicitily mention
you
-used somebody else's code, i dont think there's a way to know whether the
-ASIC contains code you wrote, or that somebody else wrote.

Advocating theft be deception are we? "Nobody can find out, so why not
just steal it?!!" I love to see situational ethics in action.

you're putting words in my mouth, i asked a question, besides, dont tell me
you actually believe that nobody will do/have done it...
when was the last time you saw ethics "working" in the business?, business a
re business, dot.
in anycase i dont see a way to actually check if somebody use our free cores
in commercial products, not that there's anything wrong with that.

The LGPL author wants their stuff to be used. They also would like to get
updates to their core. They probably didn't realize the unintended
consequences
of the LGPL whenb applied into embedded context.

agreed, they wanted updates

But toe sweep it all under the rug isn't the right way to handle it.

You should simply go talk to the core's author, and ask for a copy
relicensed
so that it can be used. The ZPL or BSD license comes to mind. Or write a
license similar to the LGPL but from section 6. In short, usage of the
core
is unlimited, changes to the source of the core must be distributed along
with the core, and nothing that uses the core unmodified is subject to the
LGPL no matter the mechanism of comingling the free and non free code.

Then it would be a done deal.

that's fair, but again, i dont think that's something all companies would do

 

[y_p_w]

Byron A Jeff wrote:

So now the question is how does the rebuild right fit within the context
of the Verilog build process? Since the core is licensed under the LGPL, users
have the right to rebuild their application with newer cores. Not that they'd
have anyway of loading this new combo to actual hardware. But the right
is delineated in the license and so in order to satisfy it, you must facilitate
the user's rebuild right.

The LGPL language specifically mentioned the ability to reverse engineer.

Now it's all very silly. The LGPL simply wasn't written to be equipped to
handle the situation. But that's the author's licensing terms and you have
an obligation to abide by the probably unintended consequences of the
application of that license.

I'll bet money that the original code author really wanted to retain the
GPL nature of changes to their code, while dismissing the rebuild right.

But as written, you'd have to deliver to the end user whatever code and
tools rquired to get them to rebuild with an updated core.

Yeah right. Sure - I'll include a copy of the Cadence NC-Affirma
simulator and Synopsys Design Compiler. There actually aren't that
many good free HDL tools, although apparently one is called (ironically
enough) "GPL".

If I were you I'd certianly go and ask the original authors about their intent.
I'd probably also ask them to relicense.

The need for an Embedded GPL needs to exists for situations like this. It
would have the core of the LGPL but needs language to squash these really
extraneous issues. Section 6 needs to be rewritten to modify or
eliminate the rebuild right.

Well I recall Cisco got in trouble when they bought out Linksys. Didn't
Linksys use Linux components in many of their boxes, and they didn't
care if the OS could be reverse engineered? When Cisco ended up
releasing the product, they balked at the open-source requirements,
but ended up releasing the source code after there was a legal threat
to force them to do so.

Just my two cents. And watch out for that moo-shoo.

Like I said, it's a minefield.

Yu-Ping Wang
Berkeley, California

 

[Barry Margolin]

In article <x%tRc.13230$9Y6.11177@newsread1.news.pas.earthlink.net>,
y_p_w <y_p_w@hotmail.com> wrote:

Byron A Jeff wrote:

So now the question is how does the rebuild right fit within the context
of the Verilog build process? Since the core is licensed under the LGPL,
users
have the right to rebuild their application with newer cores. Not that
they'd
have anyway of loading this new combo to actual hardware. But the right
is delineated in the license and so in order to satisfy it, you must
facilitate
the user's rebuild right.

The LGPL language specifically mentioned the ability to reverse engineer.

It gives you the right to reverse-engineer (you have to provide your own
ability). But if the box is all hardware, with no way to load new code
into it, that right doesn't do you a whole lot of good.

--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***

 

[Rudolf Usselmann]

y_p_w wrote:

Thanks. The core I was looking at was hosted at opensource.org.
The irony is that their mission statement mentions the LGPL as
the basis for their preferred license. Here's part of their
mission statement:

http://opencores.org/projects.cgi/web/opencores/mission

"Our main objective is to design and publish core designs under a
license for hardware modelled on the Lesser General Public License
(LGPL) for software. We are committed to the ideal of freely
available, freely usable and re-usable open source hardware."

Several of their authors don't seem to have used this psuedo-
LGPL license they refer to, but the actual LGPL itself.

Yu-Ping,

please note that this motion and mission statement are only
the opinions of a few contributors and mostly of the people
in control of the OpenCores server !

There are also quite a few cores that do not use the confusing
and as you point unappropriated LGPL. All of the IP Cores my
company has provided are available under a BSD style license
which is available on our web site.

I have been fighting the LGPL, but always seem to stand alone.
It would be help full if you point out your concerns on the
OpenCores mailing list as well.

Best Regards,
rudi
=============================================================
Rudolf Usselmann, ASICS World Services, http://www.asics.ws
Your Partner for IP Cores, Design, Verification and Synthesis

 

[glen herrmannsfeldt]

Phil Tomson wrote:

In article <pan.2004.08.05.20.49.44.167875@yahoo.com>,
General Schvantzkoph <schvantzkoph@yahoo.com> wrote:

(snip)

So I'll just sum up what we're looking at, what we'll do with it,
and what we can or would rather not do:

1) I've located an open-source Verilog description (released under
the LGPL) of a hardware function we'd like to use.
2) We would have no problem releasing our modifications of this
code or giving credit to the original author; it only seems
fair.
3) My employer would be extremely hesistant to release our other
HDL source code used in this design. Like most companies in
our industry, we are in the business of selling proprietary
hardware.
4) Much of the LGPL language doesn't seem to apply to the
hardware development flow.

Is this doable? It sounds like the LGPL was meant to allow for
open-source software to be used in otherwise proprietary products.
However - using the LGPL seems to be navigating a minefield in
this respect. The standard GPL makes things extremely clear -
you don't use it for proprietary products. In a worst case
situation, might it be possible to ask the author for permission
to use it under the terms of a different license (modified BSD
perhaps)?

Negotiating with the author is the right thing to do. I don't think it's a
hardware vs software issue. RTL code is software in the same sense that C
code is. Synthesis is the same as compilation, the object code is just
different. The place that's fuzzier is the definition of linking. Is the
map stage of the process equivalent to the link stage for software. I.e if
you were to synthesize the LGPLed core by itself and then link the edf
file to a separate edf file that contains your code, is that the same as
linking to a library file?

If it is worthwhile for your product it is probably worth a
small payment to the author, either lump sum or per device.

I would tend to think that what's being done is more analogous to static
liking than it would be to dynamic linking. The component will be
instantiated with the rest of the design. What is the executable in
this context - I would tend to think it is the resulting hardware.
I don't see how anything analogous to dynamic linking is possible
with hardware.

Dynamic reconfiguration of FPGA devices is very close to
dynamic linking, and seems to be very popular right now.

Static linking is allowed by the LGPL AFAIK (there are
issues with dynamic linking, though). I'm really kind of skeptical about
the LGPL being the appropriate license in this context (of hardware). I
suspect that the author chose the LGPL because it is more friendly for
commercial use - the original poster needs to ask the author about this.

I always thought it was that regular GPL allowed dynamic linking,
as the DLL could be distributed as 'mere aggregation', where static
linking is not compatible with the GPL. As usual, IANAL, but I
would think that in the LGPL case you would still be safe with
dynamic linking.

Since you are producing commericial hardware
you shouldn't take a chance. You need to get a letter from the owner of
the core saying what your rights are. Frankly the best thing to do is to
buy a commericial license from the copyright owners. If they won't sell
you one and if they won't define your rights in a letter then don't use
the core.

Definately he should contact the author to ask what his/her intent was for
using the LGPL in this context.

I wonder how common it is for GPL code to be used for commercial
purposes without licensing it. Decompiling synthesized hardware
code is even harder than decompiling object code.

-- glen

 

[glen herrmannsfeldt]

roller wrote:

(snip)

a dumb question, how could anybody prove that you used their HDL code in an
ASIC?, let's say it's an Ethernet core, if you dont explicitily mention you
used somebody else's code, i dont think there's a way to know whether the
ASIC contains code you wrote, or that somebody else wrote.

An ethernet core is about the only one I could imagine. One might
be able to show timing, side effects, or other unique signs of a
particular core from the outside. It might be specific enough
to prove its source.

-- glen

 

[glen herrmannsfeldt]

Barry Margolin wrote:

(snip)
(someone wrote)

The LGPL language specifically mentioned the ability to reverse engineer.

It gives you the right to reverse-engineer (you have to provide your own
ability). But if the box is all hardware, with no way to load new code
into it, that right doesn't do you a whole lot of good.

More and more often they are FPGA's with code in ROM loaded on
power up. It is more difficult to reverse engineer than object
code for popular processors, though.

-- glen

 

[Byron A Jeff]

In article <591da479.0408111427.2f5bd2d9@posting.google.com>,
y_p_w <y_p_w@hotmail.com> wrote:

byron@cc.gatech.edu (Byron A Jeff) wrote in message news:<cf4amh$fkb@cleon.cc.gatech.edu>...
In article <cf12g501i0q@enews3.newsguy.com>,
Phil Tomson <ptkwt@aracnet.com> wrote:
-In article <591da479.0408051151.3a1491d4@posting.google.com>,
-y_p_w <y_p_w@hotmail.com> wrote:
-

It's funny. I spent last night having a very similar LGPL discussion on
the PICLIST mailing list about LGPL'ed libraries for embedded systems.

I decided to check in here because I think you may have gotten some bad
moo-shoo here.

->So I'll just sum up what we're looking at, what we'll do with it,
->and what we can or would rather not do:
-
->1) I've located an open-source Verilog description (released under
-> the LGPL) of a hardware function we'd like to use.
->2) We would have no problem releasing our modifications of this
-> code or giving credit to the original author; it only seems
-> fair.

Glad you think it's fair. The LGPL makes it a requirement.

Well - I'm thinking in my experience how there are companies that
pay for or otherwise obtain licenses for products, components,
services, IP, software, etc. from third parties, and want to keep
those arrangements hush-hush. Some of those companies seem to think
it hurts their reputations or standing among customers if there's a
perception that they sought outside help to do something that might
have been performed in-house. As a consumer I just want what works.

Too true. That and the effect on the bottom line. And free designs can
possibly help the bottom line of the cost of a product by lowering the
barrier to the value add.

-
-That may or may not be required, however it's nice that you're flexible in
-this area.

It is required. Changes to LGPL'ed source are essentially GPL in nature.
You must release the changes (or make a written offer to do so) to anyone who
receives the final work.

I didn't quite get that at first. I was under the impression that the
changes must be publicly available. If we only need to deliver the
changes and netlists to the customer, then it might be feasible. Most
won't really care.

->3) My employer would be extremely hesistant to release our other
-> HDL source code used in this design. Like most companies in
-> our industry, we are in the business of selling proprietary
-> hardware.

It's the standard clash of the titans between free and non-free components.

I'm a realist about how things really work. Most of the IC design
world is proprietary. We use proprietary tools, IP, and processes,
and there's not much I can do about it. I like the idea of open
source IP cores, but their licensing should take into consideration
the proprietary nature of "The Other Stuff" that is used to bring a
complete design to hardware.

I agree. I have tentatively named this imaginary license the YourCode License.
Here are its tenants:

1) Your Code is your code. Publish it, hide it, whatever. It's not my concern.

Notes: This completely drops the 10 line source test of the LGPL. If it's
code that you generate, I really don't care how you generated it or whatever
headers from MyCode are required to get the two to work together.

2) MyCode however is My Code. And I want my code to be free. So feel free to
use it as you like unmodified. But if you change MyCode, then you must treat
it GPL style i.e. publish or make offer to distribute source, note changes,
inform the users of their rights with respect to MyCode typically by
distributing a copy of the YouCode license with MyCode's modified source.

Notes: The is pretty much how the LGPL operates. This is the part I want to
keep. Note that most of the freer licenses than the LGPL like zlib and BSD
don't have this requirement. I like the above because if you're using MyCode
and you improve it so as to make it work better with YourCode, then while as
pointed out in step 1 that YourCode is your code, I'd sure like to have access
to the changes that you made to MyCode. That's fair. Right?

3) In embedded systems YourCode and MyCode generally need to be combined to
create a system. The YourCode license makes no claim upon the combined
YourCode+MyCode work subject to the following two restrictions:

A) Documentation for the work must list the usage of MyCode under the
YourCode license.
B) If the work uses a modified MyCode as outlined in section 2 then the
modified MyCode source (or an offer to distribute) must accompany the
work as outlined in section 2 above.

Notes: The rebuild right is dropped to the floor. There simply has to be som
balance in the environment that YourCode will be used, deeply embedded
systems, where the ability to rebuild and the resources to do so (which may
in fact be the sources to YourCode + your tools) often makes the cost
exhorbitant

4) Usual legalese about no warrantee, no fitness for any purpose, it's not my
fault, yada yada.

Notes: Typical CYA management.


-
-> The need for an Embedded GPL needs to exists for situations like this.

BTW this Embedded GPL is this YourCode License outlined above.

It
would have the core of the LGPL but needs language to squash these really
extraneous issues. Section 6 needs to be rewritten to modify or
eliminate the rebuild right.

I can imagine some customers might have the ability to rebuild and
perhaps produce their own versions of hardware products. I suspect
most won't go through that trouble if there's a commidity part for
sale. I'm also guessing an FPGA based-design will be impractical -
have you seen the prices for Xilinx FPGAs?

Nope. But I'll bet it's steep.

It seems to have worked well for the OSS movement, where there has
been enough critical mass to assemble something as complex as Linux.

But traditional Linux has the facilities to allow for all of GPL, LGPL, BSD,
ZLIB, and non free software to all coexist. BTW embedded Linux is having some
of the same issues we're discussing here.

As far as I can tell, most commercial Linux developers are either
selling maintenance contracts and/or selling hardware. IBM seems
to be successful at doing both.

Some are selling actual software too. But many developers and power users get
used to being able to support themselves and get annoyed when some company
tries to pull out the rug by releasing binary only software.

But a license that protects the rights of both free and non free developers
when code has to be in close proximity is needed.

Does anyone know if an existing free license matches the tenants of the
proposed YourCode license above?

BAJ

 

[y_p_w]

Byron A Jeff wrote:

In article <591da479.0408111427.2f5bd2d9@posting.google.com>,
y_p_w <y_p_w@hotmail.com> wrote:

byron@cc.gatech.edu (Byron A Jeff) wrote in message news:<cf4amh$fkb@cleon.cc.gatech.edu>...

In article <cf12g501i0q@enews3.newsguy.com>,
Phil Tomson <ptkwt@aracnet.com> wrote:
-In article <591da479.0408051151.3a1491d4@posting.google.com>,
-y_p_w <y_p_w@hotmail.com> wrote:
-

It's funny. I spent last night having a very similar LGPL discussion on
the PICLIST mailing list about LGPL'ed libraries for embedded systems.

I decided to check in here because I think you may have gotten some bad
moo-shoo here.

->So I'll just sum up what we're looking at, what we'll do with it,
->and what we can or would rather not do:
-
->1) I've located an open-source Verilog description (released under
-> the LGPL) of a hardware function we'd like to use.
->2) We would have no problem releasing our modifications of this
-> code or giving credit to the original author; it only seems
-> fair.

Glad you think it's fair. The LGPL makes it a requirement.

Well - I'm thinking in my experience how there are companies that
pay for or otherwise obtain licenses for products, components,
services, IP, software, etc. from third parties, and want to keep
those arrangements hush-hush. Some of those companies seem to think
it hurts their reputations or standing among customers if there's a
perception that they sought outside help to do something that might
have been performed in-house. As a consumer I just want what works.



Too true. That and the effect on the bottom line. And free designs can
possibly help the bottom line of the cost of a product by lowering the
barrier to the value add.



-
-That may or may not be required, however it's nice that you're flexible in
-this area.

It is required. Changes to LGPL'ed source are essentially GPL in nature.
You must release the changes (or make a written offer to do so) to anyone who
receives the final work.

I didn't quite get that at first. I was under the impression that the
changes must be publicly available. If we only need to deliver the
changes and netlists to the customer, then it might be feasible. Most
won't really care.


->3) My employer would be extremely hesistant to release our other
-> HDL source code used in this design. Like most companies in
-> our industry, we are in the business of selling proprietary
-> hardware.

It's the standard clash of the titans between free and non-free components.

I'm a realist about how things really work. Most of the IC design
world is proprietary. We use proprietary tools, IP, and processes,
and there's not much I can do about it. I like the idea of open
source IP cores, but their licensing should take into consideration
the proprietary nature of "The Other Stuff" that is used to bring a
complete design to hardware.


I agree. I have tentatively named this imaginary license the YourCode License.
Here are its tenants:

1) Your Code is your code. Publish it, hide it, whatever. It's not my concern.

Notes: This completely drops the 10 line source test of the LGPL. If it's
code that you generate, I really don't care how you generated it or whatever
headers from MyCode are required to get the two to work together.

2) MyCode however is My Code. And I want my code to be free. So feel free to
use it as you like unmodified. But if you change MyCode, then you must treat
it GPL style i.e. publish or make offer to distribute source, note changes,
inform the users of their rights with respect to MyCode typically by
distributing a copy of the YouCode license with MyCode's modified source.

Notes: The is pretty much how the LGPL operates. This is the part I want to
keep. Note that most of the freer licenses than the LGPL like zlib and BSD
don't have this requirement. I like the above because if you're using MyCode
and you improve it so as to make it work better with YourCode, then while as
pointed out in step 1 that YourCode is your code, I'd sure like to have access
to the changes that you made to MyCode. That's fair. Right?

3) In embedded systems YourCode and MyCode generally need to be combined to
create a system. The YourCode license makes no claim upon the combined
YourCode+MyCode work subject to the following two restrictions:

A) Documentation for the work must list the usage of MyCode under the
YourCode license.
B) If the work uses a modified MyCode as outlined in section 2 then the
modified MyCode source (or an offer to distribute) must accompany the
work as outlined in section 2 above.

Notes: The rebuild right is dropped to the floor. There simply has to be som
balance in the environment that YourCode will be used, deeply embedded
systems, where the ability to rebuild and the resources to do so (which may
in fact be the sources to YourCode + your tools) often makes the cost
exhorbitant

4) Usual legalese about no warrantee, no fitness for any purpose, it's not my
fault, yada yada.

Notes: Typical CYA management.


-
-> The need for an Embedded GPL needs to exists for situations like this.

BTW this Embedded GPL is this YourCode License outlined above.


It
would have the core of the LGPL but needs language to squash these really
extraneous issues. Section 6 needs to be rewritten to modify or
eliminate the rebuild right.

I can imagine some customers might have the ability to rebuild and
perhaps produce their own versions of hardware products. I suspect
most won't go through that trouble if there's a commidity part for
sale. I'm also guessing an FPGA based-design will be impractical -
have you seen the prices for Xilinx FPGAs?


Nope. But I'll bet it's steep.


It seems to have worked well for the OSS movement, where there has
been enough critical mass to assemble something as complex as Linux.


But traditional Linux has the facilities to allow for all of GPL, LGPL, BSD,
ZLIB, and non free software to all coexist. BTW embedded Linux is having some
of the same issues we're discussing here.


As far as I can tell, most commercial Linux developers are either
selling maintenance contracts and/or selling hardware. IBM seems
to be successful at doing both.


Some are selling actual software too. But many developers and power users get
used to being able to support themselves and get annoyed when some company
tries to pull out the rug by releasing binary only software.

But a license that protects the rights of both free and non free developers
when code has to be in close proximity is needed.

Does anyone know if an existing free license matches the tenants of the
proposed YourCode license above?

Don't know, yet. I've looked at some of the less restrictive license
terms, and most just say that any derivative code must contain the same
license header. Nothing about making it available like the GPL or LGPL.

 

[john jakson]

ptkwt@aracnet.com (Phil Tomson) wrote in message news:<cf31a5013nr@enews3.newsguy.com>...

snipping

a dumb question, how could anybody prove that you used their HDL code in an
ASIC?, let's say it's an Ethernet core, if you dont explicitily mention you
used somebody else's code, i dont think there's a way to know whether the
ASIC contains code you wrote, or that somebody else wrote.

I was thinking the same thing - How could anyone find out? If you're
releasing an ASIC and not RTL code, then it's impossible to reverse
engineer the ASIC in order to discover the HDL code that was originally
used to describe the design.

But the original poster is trying to be honest & legal.

Phil

Well I am planning on releasing a cpu core under some kind of MIT/BSD
TBD license and since its a cpu (Transputer), I'd probably want to
know all users.

But for a generic cores with multiple suppliers who is going to know?
If it gets out that ACME corp uses free cores with no credits though,
it would look pretty tacky and might make for some light reading in
the EE press.

my 2c

johnjakson_usa_com

 

[J o h n _ E a t o n (at)]

glen herrmannsfeldt wrote:

roller wrote:

(snip)

a dumb question, how could anybody prove that you used their HDL code
in an
ASIC?, let's say it's an Ethernet core, if you dont explicitily
mention you
used somebody else's code, i dont think there's a way to know whether the
ASIC contains code you wrote, or that somebody else wrote.


An ethernet core is about the only one I could imagine. One might
be able to show timing, side effects, or other unique signs of a
particular core from the outside. It might be specific enough
to prove its source.

-- glen

So put a very obscure bug in all your code so can tell if anyone else is
using it.



There is a MAJOR problem with gpl type licenses that needs to be resolved
before Open Source HDL code really takes off.

I have no concerns over using open source cores released under any gpl. I would
even post any improvements and testbenchs that I created during development.

But I have a major problem with using cores that are illegally released without
the copyright holders permission. There is no way that I can determine if the
code was posted by the owner or someone who got a copy and decided to replace the
original copyright with the LGPL and post it to opencores.org. Until the Open
cores movement figures out how to track the origin of code then I will never use
it in a real product.


This is where open hardware is different from open software. If someone claims that
their code was illegally put in a linux release then the linux community can quickly
pull it out and replace it with legal code.


You can't do that with a ASIC in any reasonable length of time. There is a big difference
between "download the latest version" vs "bring back our product so we can replace the
asic".



John