Using an IP core licensed under the LGPL

[y_p_w]

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.

I've gone over the LGPL multiple times, and it seems that the term
"work based on the library" refers only to actual modifications
or close coupling of code with the LGPL'ed component. I'm still
unclear (the language of the LGPL is mind-boggling) whether or
not we would be required to release (and to what extent) the other
source code that is used to develop this product.

Making our modifications to a publicly available open-source core
seems like a fair "price" for its use. We would have no problem
acknowledging that we used this core. My company has a website,
and we could make our mods (if any) available for download there.
My employer more than likely won't want to make our proprietary HDL
source code available though.

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)?

Thanks in advance.

Yu-Ping Wang
Berkeley, California

 

[General Schvantzkoph]

On Thu, 05 Aug 2004 12:51:28 -0700, y_p_w wrote:

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.

I've gone over the LGPL multiple times, and it seems that the term
"work based on the library" refers only to actual modifications
or close coupling of code with the LGPL'ed component. I'm still
unclear (the language of the LGPL is mind-boggling) whether or
not we would be required to release (and to what extent) the other
source code that is used to develop this product.

Making our modifications to a publicly available open-source core
seems like a fair "price" for its use. We would have no problem
acknowledging that we used this core. My company has a website,
and we could make our mods (if any) available for download there.
My employer more than likely won't want to make our proprietary HDL
source code available though.

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)?

Thanks in advance.

Yu-Ping Wang
Berkeley, California

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? 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.

 

[Phil Tomson]

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.

Phil

 

[roller]

"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.

 

[y_p_w]

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.

-
-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.

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.

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?

It seems to have worked well for the OSS movement, where there has
been enough critical mass to assemble something as complex as Linux.
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.

Yu-Ping Wang
Berkeley, California

 

[Byron A Jeff]

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

Hi-

Hello.

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.

A typical scenario.

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.

Actually this is mecahnism. You don't want to deal with the meachnisms without
understanding the policy.

I've gone over the LGPL multiple times, and it seems that the term
"work based on the library" refers only to actual modifications
or close coupling of code with the LGPL'ed component. I'm still
unclear (the language of the LGPL is mind-boggling) whether or
not we would be required to release (and to what extent) the other
source code that is used to develop this product.

Now you're on the right track. What is the policy governing the release of
your code relative to the LGPL code. The mind boggling language has its
purpose.

Making our modifications to a publicly available open-source core
seems like a fair "price" for its use.

That's a part of the deal. But there's more.

We would have no problem acknowledging that we used this core.

I'm not sure it's necessary other than than the notice of where the
sources required for release can be had.

My company has a website,
and we could make our mods (if any) available for download there.

Which is sufficient.

My employer more than likely won't want to make our proprietary HDL
source code available though.

OK now we're at the crux of the "problem."

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.

Fine. Here's the first policy issue. That LGPL code is free and must remain
free to downstream users. There are two parts to this. The first, modifications
to that actual core must be free, you have a grasp on. We'll work on the other
in a minute.

2) We would have no problem releasing our modifications of this
code or giving credit to the original author; it only seems
fair.

Like I said you're clear on that. Good.

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.

Which to a point the LGPL is supposed to alleviate.

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

That's mechanism. It's relevant only in relationship to the policy.

Is this doable? It sounds like the LGPL was meant to allow for
open-source software to be used in otherwise proprietary products.

Only to a point.

However - using the LGPL seems to be navigating a minefield in
this respect.

OK. Enough stalling. Here's the LGPL tipping point: ability for the user to
do updates to the LGPL code. And it drives proprietary vendors nuts.

Remember that the LGPL code is free. Your code doesn't have to be free and
the LGPL usually doesn't place any restrictions upon it. However because the
LGPL code is free, the end user has the right to update it. That's the policy.

Now finally we can get back to the mechanism. If you can give the user the
mechanism to update the free code without revealing your code, then you can do
so. The mechanism used with desktop software is typically shared/dynamic
libraries.

I know that is most embedded and Verliog type space this doesn't make much
sense. But you have to offer your user a way for them to update their LGPL
side.

Hope this helps,

BAJ

 

[glen herrmannsfeldt]

Byron A Jeff wrote:

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

(snip)

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.
(big snip)

2) We would have no problem releasing our modifications of this
code or giving credit to the original author; it only seems
fair.

(little snip)

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.

(medium sized snip)

Remember that the LGPL code is free. Your code doesn't have to be free and
the LGPL usually doesn't place any restrictions upon it. However because the
LGPL code is free, the end user has the right to update it. That's the policy.

Now finally we can get back to the mechanism. If you can give the user the
mechanism to update the free code without revealing your code, then you can do
so. The mechanism used with desktop software is typically shared/dynamic
libraries.

My understanding of LGPL originally had to do with subroutine
libraries. One could write a library, say, for example, the C library
needed for compiled C code, and distribute that with the LGPL.
The regular GPL would require that any code compiled with a GPL
library be released under GPL. The LGPL, though, would allow one
to distribute code linked with an LGPL C library without releasing
the source to your code, only the LGPL code.

In the case of statically linked libraries, it is not normally
possible for end users to modify and replace such library functions.
(The OS/360 linker allows it, but most others don't.)

For an FPGA one could conceive of allowing one to change the LGPL
code, resynthesize the design, and load it. For an ASIC that obviously
wouldn't make any sense.

If one considers synthesized FPGA code equivalent to compiled and
linked object code, it seems a fair comparison to the LGPL library
model. (LGPL is sometimes called the Library GPL, though I believe
that Lesser GPL is more correct.)

-- glen

 

[glen herrmannsfeldt]

Neo wrote:

This issue about LGPL has been extensively debated in the opencores
forum sometime back and there had been many attempts at restating the
licensing terms in a more clear manner.
Some even suggested a modified BSD type license for hardware. But
unfortunately the consensus was not unanimous and the discussion
fizzled out. But the mojority feeling was that the LGPL is not exactly
suitable for hardware but the best already available. The contributors
dont mind the cores being used by anyone for whatever purpose
profit/non-profit as long as his authorship is acknowledged and any
modifications to the core downloaded is not copyrighted by the users
and made publicly available if asked. So it was generally felt that
this exact intention was not accurately described in the LGPL but due
to non-availability of alternatives it was left in LGPL.

This sounds reasonably close to the normal use of library routines.
They are compiled and linked with user code, but not normally
modified. If one used an LGPL verilog module without modification
that would seem similar to linking of a library routine.

(snip)

This may become an issue if a company makes substantial modifications
to the core which enhances its performance or fucntionality to a great
extent. then I think the license shouldnt restrict them from having a
copyright on the changed core. this, the license dosent address I
believe, so it would be better that in such a case the users take the
written consent of the authors for changes on the core to be made by
them and his no-objection to their having a proprietary core as a
result. This said, I think it is better we develop a licensing concept
much better suited for hardware.

I would suggest that before such modifications are done that a
discussion with the original author could be started. It could
then be decided jointly how to share credit for the new version,
but a joint copyright (I believe that is legal) would seem fair.

Otherwise, I would say that following the library model that
existing modules could be used unchanged, or completely new ones
written and "linked" with existing modules. Each would have its
own copyright. (As usual, IANAL, but it sounds right to me.)

-- glen

 

[Byron A Jeff]

In article <yb6dndzSRN3V2eTfRVn-uA@comcast.com>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

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

(snip)

humongous snip...

Remember that the LGPL code is free. Your code doesn't have to be free
and the LGPL usually doesn't place any restrictions upon it. However
because the LGPL code is free, the end user has the right to update it.
That's the policy.

Now finally we can get back to the mechanism. If you can give the user
the mechanism to update the free code without revealing your code, then
you can do so. The mechanism used with desktop software is typically
shared/dynamic libraries.

My understanding of LGPL originally had to do with subroutine
libraries. One could write a library, say, for example, the C library
needed for compiled C code, and distribute that with the LGPL.

You're on point so far.

The regular GPL would require that any code compiled with a GPL
library be released under GPL.

Right.

The LGPL, though, would allow one
to distribute code linked with an LGPL C library without releasing
the source to your code, only the LGPL code.

Except for the update policy that is outlined above. One can distrubute
code without distrubting the source. But you had to provide a mechanism for
the end user to update the library. Ojbect files are sufficent to meet that
requirement.

In the case of statically linked libraries, it is not normally
possible for end users to modify and replace such library functions.

Unless you release the object files for the proprietary source so that
it can be relinked.

(The OS/360 linker allows it, but most others don't.)

Hence the need to release object files.

For an FPGA one could conceive of allowing one to change the LGPL
code, resynthesize the design, and load it. For an ASIC that obviously
wouldn't make any sense.

It doesn't matter if the ASIC can physically be updated or not.
The requirement is that you have to provide the end user with the means
and the tools to update the LGPL code. This is even if the end user cannot
actually do anything with the updated "executable".

If one considers synthesized FPGA code equivalent to compiled and
linked object code, it seems a fair comparison to the LGPL library
model. (LGPL is sometimes called the Library GPL, though I believe
that Lesser GPL is more correct.)

I can agree with that. But the question is then what is the Verilog
equivalent to unlinked object code?

BAJ

 

[Byron A Jeff]

In article <pan.2005.05.05.13.21.54.194666@PleaseDontSpamMEpolybus.com>,
B. Joshua Rosen <bjrosen@PleaseDontSpamMEpolybus.com> wrote:

On Thu, 05 May 2005 00:00:42 -0700, Neo wrote:

massive snippage...

Developers who want to offer free software, whether it's in C or Verilog,
should do so under a license that makes their intentions crystal clear.

The problem is that much of it is clear as mud.

If your intention is to require the users of your code to share their
changes with the world then use the GPL.

That's unclear already. Share changes to the GPL code? Share the code
that you generate that's combined with the GPL code but not an actual
part of it?

The GPL enforces both. The reason that the LGPL exists is that the latter
situation isn't necessarily the intent.

If you want to give it away in a free an unencumbered fashion then
use the BSD.

Unencumbered cuts both ways. While the BSD doesn't require any sharing at
all, it's troublesome to generate something that is given away yet
facilitates someone else encumbering the code and not making useful
changes available. Unencumbered code should not be encumberable (is that
a word? ;-) by anyone else.

For hardware the LGPL should never
be an option because it's intentions are not clear.

Not true. It's intentions are very clear.

1. The LGPL code is free. So modifications to the LGPL code itself must
be distributed.
2. The LGPL code can be combined with non free code so long as...
3. The end use retains the right to update the LGPL code.

It's crystal clear. It's just that it's inconvenient to proprietary
developers who wish to both utilize LGPL code, yet at the same time keep
their own code to themselves.

I know that the above statement may seem to denegrate proprietary
developers. That's not my intent. I have no problem with YourCode being
YourCode. But when you leverage OS code (LGPL) in the process you also
have to deal with the restrictions.

I offer a free CAE
tool called HDLmaker, http://www.polybus.com/hdlmaker/users_guide/. I
license HDLmaker under the BSD license. I developed HDLmaker for my own
use, it's what I use to build all of the things that I FPGA and ASIC
projects that I do. I'm not in the CAE business, I'm in the FPGA
consulting and IP business, and I have no desire to be in the CAE
business. Therefore I chose the BSD for HDLmaker because it makes it very
clear that I'm giving it away. The BSD license say that you can use it
anyway you want. It also says that you are on your own, there is no
warranty either expressed on implied.

That's cool. The counterargument is always based around the scenario where
someone adds some useful functionality to your tool, then starts selling
it. Now we can probably both agree that's cool. However wouldn't it be just
a bit irksome that someone who is using your tool is going to charge you
money for the piddling additions added to your own work?

The probable answer is "Well I can just put that stuff in myself." Sure you
can. But you've already said that you don't want to be in the CAE business.
Wouldn't it be better to leverage off of someone else's additions when you
having to recode them yourself?

Others may have different intentions
with the free software that they provide. If you truly think that what you
developed could be a catalyst for building something much greater then the
GPL may be appropriate.

Right.

The GPL forces other people to contribute their changes back to the
community.

In an indirect way. You actually only have to contribute the source to
those that you distribute to. So you're not obligated to distribute to
the community. You can even sell if you like. But the other shoe is that
you can't prevent any downstream users from continuing the redistribution
even at a zero price point

If enough people do that then it can result
in something much greater then what one person can create. However it also
limits the use of that code to users who can afford to give away all of
the code that it touches. When you use the GPL you are restricting the use
of the code, if that's what you mean to do then do it, if not then use the
BSD.

But the LGPL is a almost workable compromise between the two. It's only the
update/relink requirement that causes it to stall in the hardware arena
because that arena often doesn't have clean mechanisms for free and non free
code to be conjoined without having the source for both components.

There is a need for another license in the breech. I actually wrote the
abtract to it last year in this self same comp.lang.verilog newsgroup.
Named it the YourCode license. Here's the general idea from that post:

------------------- The YourCode License Description --------------------

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 some
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.

------------------------------------------------------------------

That's the ticket but I don't think it exists...

BAJ

 

[B. Joshua Rosen]

I offer a free CAE
tool called HDLmaker, http://www.polybus.com/hdlmaker/users_guide/. I
license HDLmaker under the BSD license. I developed HDLmaker for my own
use, it's what I use to build all of the things that I FPGA and ASIC
projects that I do. I'm not in the CAE business, I'm in the FPGA
consulting and IP business, and I have no desire to be in the CAE
business. Therefore I chose the BSD for HDLmaker because it makes it
very clear that I'm giving it away. The BSD license say that you can use
it anyway you want. It also says that you are on your own, there is no
warranty either expressed on implied.

That's cool. The counterargument is always based around the scenario
where someone adds some useful functionality to your tool, then starts
selling it. Now we can probably both agree that's cool. However wouldn't
it be just a bit irksome that someone who is using your tool is going to
charge you money for the piddling additions added to your own work?

I thought about that when I put HDLmaker on the web. When I first put it
up, 5 years ago, I put my own license on it which reserved the commercial
rights to me but gave everyone the right to make internal use of it. But
then I thought long and hard about the business case for a product like
this and what that business would look like. For a tool like HDLmaker to
be successful you have to sell a lot of copies and you have to provide a
lot of support to a lot of users. That's not a business that I wanted to
be in. I decided there was value to me in giving away HDLmaker because it
attracts people to my website but that I wasn't ever going to try and make
money from it directly (I make lot's of money from it indirectly because
it allows me to create products that I either couldn't do at all without
it or would take vastly more labor). At that point I decided that is was
more important to use a standard license then to try to reserve some
rights that I wasn't really interested in preserving anyway. I picked the
BSD because I think that if you are giving something away you should do it
with no strings attached. If someone comes along and figures out how to
sell HDLmaker for a profit, more power to them. If it turned into a huge
product I might have a twinge of regret but I've made choice and I'll live
with it. My original point was that every developer has to decide exactly
what they want to achieve when they choose a license.

As for creating a hardware specific license, while it may seem like a good
idea to create a new hardware specific open source license the
proliferation of free/open source licenses has become a huge problem.
There are already too many licenses by a factor of 10, the world doesn't
need one more. I think that if your intention is give something away then
you should use the BSD. If you feel strongly about forcing people to share
enhancements then you should use the GPL. The problem with the LGPL is
that it's not really fish or fowl. It was designed for a single purpose
which was to allow people to compile and run a proprietary program on a
Linux system. It's very specific to that application. It barely works in
the context for which it was designed and it doesn't work at all for any
other use. Parenthetically when I say barely works in the application for
which it is designed think about the distribution specificity problems
that the Xilinx tools have. If Xilinx had statically linked the libraries
they needed into ISE there wouldn't be any problem running it on any
distribution. But they couldn't do that because of the LGPL's requirement
that libraries be dynamically linked.

 

[Byron A Jeff]

In article <pan.2005.05.06.12.52.47.580651@PleaseDontSpamMEpolybus.com>,
B. Joshua Rosen <bjrosen@PleaseDontSpamMEpolybus.com> wrote:
Big snippage...

I offer a free CAE tool called HDLmaker ... under the BSD license.

That's cool. The counterargument is always based around the scenario
where someone adds some useful functionality to your tool, then starts
selling it.

" I thought about that when I put HDLmaker on the web. When I first put it
up, 5 years ago, I put my own license on it which reserved the commercial
rights to me but gave everyone the right to make internal use of it. But
then I thought long and hard about the business case for a product like
this and what that business would look like. For a tool like HDLmaker to
be successful you have to sell a lot of copies and you have to provide a
lot of support to a lot of users. That's not a business that I wanted to
be in. I decided there was value to me in giving away HDLmaker because it
attracts people to my website but that I wasn't ever going to try and make
money from it directly (I make lot's of money from it indirectly because
it allows me to create products that I either couldn't do at all without
it or would take vastly more labor). At that point I decided that is was
more important to use a standard license then to try to reserve some
rights that I wasn't really interested in preserving anyway. I picked the
BSD because I think that if you are giving something away you should do it
with no strings attached. If someone comes along and figures out how to
sell HDLmaker for a profit, more power to them. If it turned into a huge
product I might have a twinge of regret but I've made choice and I'll live
with it. My original point was that every developer has to decide exactly
what they want to achieve when they choose a license."

Very true that they have to think about what they want to achieve.

So where does "create a shared community" fit into this spectrum? BTW you
keep saying that the GPL forces you to do things. It doesn't force anything.
Saying that is like saying that I am forced to purchase fast food. It's
a choice with conditions attached, nothing more, nothin less.

As for creating a hardware specific license, while it may seem like a good
idea to create a new hardware specific open source license the
proliferation of free/open source licenses has become a huge problem.

Prolific or not, after examining the landscape, there is still a real need
that needs to be filled.

There are already too many licenses by a factor of 10, the world doesn't
need one more.

I disagree. If there isn't a license that meets a need, then one should be
created whether or no it adds to the crowd.

I think that if your intention is give something away then
you should use the BSD.

It's not.

If you feel strongly about forcing people to share
enhancements then you should use the GPL.

I'm not forcing anyone to do anything. A license is always a condition of
use/distribution/modification. You can choose not to play.

The problem with the LGPL is that it's not really fish or fowl.
It was designed for a single purpose
which was to allow people to compile and run a proprietary program on a
Linux system.

I find that hard to believe considering that it predated Linux.

It's very specific to that application.

No it isn't.

It barely works in
the context for which it was designed and it doesn't work at all for any
other use. Parenthetically when I say barely works in the application for
which it is designed think about the distribution specificity problems
that the Xilinx tools have. If Xilinx had statically linked the libraries
they needed into ISE there wouldn't be any problem running it on any
distribution. But they couldn't do that because of the LGPL's requirement
that libraries be dynamically linked.

The LGPL has no requirement that libraries be dynamically linked. You can
link statically all day long. As I have stated elsewhere in this thread,
the LGPL's requirement is that the downstream user has the right to update
the free LGPL part of the application. The condition for combining with
LGPL code is that you preserve that right.

Xilinx could have statically linked and distributed. They chose not to.
Also with the current state of Linux package management, updating the
shared libraries should be that big a deal anyway.

At the end of the day there is the need for another license. Libraries
provide shared infrastructure. I can live without the relink/update
requirement, but I do strongly believe that the shared infrastructure should
in fact be shared without competitive advantage. So changes to the
shared infrastructure should be shared while usage of that infrastructure
should be.

That concept extends to Open Cores, embedded interpreters, and embedded
libraries too.

BAJ

 

[glen herrmannsfeldt]

Byron A Jeff wrote:

(another snip)

Remember that the LGPL code is free. Your code doesn't have to be free
and the LGPL usually doesn't place any restrictions upon it. However
because the LGPL code is free, the end user has the right to update it.
That's the policy.

Now finally we can get back to the mechanism. If you can give the user
the mechanism to update the free code without revealing your code, then
you can do so. The mechanism used with desktop software is typically
shared/dynamic libraries.

My understanding of LGPL originally had to do with subroutine
libraries. One could write a library, say, for example, the C library
needed for compiled C code, and distribute that with the LGPL.

You're on point so far.

(snip)

Except for the update policy that is outlined above. One can distrubute
code without distrubting the source. But you had to provide a mechanism for
the end user to update the library. Ojbect files are sufficent to meet that
requirement.

I haven't looked at so much, but I believe that some systems have the
ability to write an internal format file, somewhat equivalent to a
linkable object file. If so, that would seem to satisfy the
requirement. It would seem to me to satisfy the spirit, if not the
letter of the requirement to offer to synthesize with a modified version
of the LGPL code to anyone requesting it. For FPGA code that makes
some sense. For ASIC code it doesn't, but one could offer it anyway.

For ASICs one could offer to resynthesize and generate new masks
at cost plus the usual charges that GPL allows. If the cost was in
the millions of dollars that would discourage most people.

For the FPGA case, one could supply a web site that would synthesize
for a supplied modification to the LGPL code.

In the case of statically linked libraries, it is not normally
possible for end users to modify and replace such library functions.

Unless you release the object files for the proprietary source so that
it can be relinked.

Is it really true that no-one distributes statically linked gcc
output without object modules? (I believe that glibc is LGPL.)

(The OS/360 linker allows it, but most others don't.)

Maybe it is time to revive the OS/360 model. As I understand it,
OS/360 supplied this ability to save the time to recompile a large
program. As computers got faster, it turned out not to be such a
useful savings, especially as the linker wasn't so fast.

(snip)

It doesn't matter if the ASIC can physically be updated or not.
The requirement is that you have to provide the end user with the means
and the tools to update the LGPL code. This is even if the end user cannot
actually do anything with the updated "executable".

Is the executable is the ASIC itself?

-- glen

 

[Byron A Jeff]

In article <s_KdnQxkeP1AmOHfRVn-sw@comcast.com>,
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

Byron A Jeff wrote:

massive snippage...

In the case of statically linked libraries, it is not normally
possible for end users to modify and replace such library functions.

Unless you release the object files for the proprietary source so that
it can be relinked.

Is it really true that no-one distributes statically linked gcc
output without object modules? (I believe that glibc is LGPL.)

No. Most simply release the source.

More snippage...

It doesn't matter if the ASIC can physically be updated or not.

Is the executable is the ASIC itself?

No. It's the mask for the ASIC. And the executable doesn't matter...

As another posted correctly pointed out, the LGPL really isn't the right
license for the task. Unfortunately the cores are assigned with it.

The OP needs to talk to the original author about it.

BAJ

 

[B. Joshua Rosen]

On Thu, 05 May 2005 00:00:42 -0700, Neo wrote:

This issue about LGPL has been extensively debated in the opencores
forum sometime back and there had been many attempts at restating the
licensing terms in a more clear manner.
Some even suggested a modified BSD type license for hardware. But
unfortunately the consensus was not unanimous and the discussion
fizzled out. But the mojority feeling was that the LGPL is not exactly
suitable for hardware but the best already available. The contributors
dont mind the cores being used by anyone for whatever purpose
profit/non-profit as long as his authorship is acknowledged and any
modifications to the core downloaded is not copyrighted by the users
and made publicly available if asked. So it was generally felt that
this exact intention was not accurately described in the LGPL but due
to non-availability of alternatives it was left in LGPL.
Even when I contributed a core to the OC, I didnt know what kind of
license I should release it under. But just put it under LGPL because
others had done before. My intention was to make my work to be of use
to others if found fitting. whether it is student working on his
project or a manager looking for a efficient plugin for his larger
project shouldnt matter as long as the core used remains in open
domain. I think there should be no problem as long as you maintain the
openess of the core downloaded with/without any modifications made.
This may become an issue if a company makes substantial modifications
to the core which enhances its performance or fucntionality to a great
extent. then I think the license shouldnt restrict them from having a
copyright on the changed core. this, the license dosent address I
believe, so it would be better that in such a case the users take the
written consent of the authors for changes on the core to be made by
them and his no-objection to their having a proprietary core as a
result. This said, I think it is better we develop a licensing concept
much better suited for hardware.

Developers who want to offer free software, whether it's in C or Verilog,
should do so under a license that makes their intentions crystal clear. If
your intention is to require the users of your code to share their changes
with the world then use the GPL. If you want to give it away in a free an
unencumbered fashion then use the BSD. For hardware the LGPL should never
be an option because it's intentions are not clear. I offer a free CAE
tool called HDLmaker, http://www.polybus.com/hdlmaker/users_guide/. I
license HDLmaker under the BSD license. I developed HDLmaker for my own
use, it's what I use to build all of the things that I FPGA and ASIC
projects that I do. I'm not in the CAE business, I'm in the FPGA
consulting and IP business, and I have no desire to be in the CAE
business. Therefore I chose the BSD for HDLmaker because it makes it very
clear that I'm giving it away. The BSD license say that you can use it
anyway you want. It also says that you are on your own, there is no
warranty either expressed on implied. Others may have different intentions
with the free software that they provide. If you truly think that what you
developed could be a catalyst for building something much greater then the
GPL may be appropriate. The GPL forces other people to contribute their
changes back to the community. If enough people do that then it can result
in something much greater then what one person can create. However it also
limits the use of that code to users who can afford to give away all of
the code that it touches. When you use the GPL you are restricting the use
of the code, if that's what you mean to do then do it, if not then use the
BSD.

 

[Neo]

This issue about LGPL has been extensively debated in the opencores
forum sometime back and there had been many attempts at restating the
licensing terms in a more clear manner.
Some even suggested a modified BSD type license for hardware. But
unfortunately the consensus was not unanimous and the discussion
fizzled out. But the mojority feeling was that the LGPL is not exactly
suitable for hardware but the best already available. The contributors
dont mind the cores being used by anyone for whatever purpose
profit/non-profit as long as his authorship is acknowledged and any
modifications to the core downloaded is not copyrighted by the users
and made publicly available if asked. So it was generally felt that
this exact intention was not accurately described in the LGPL but due
to non-availability of alternatives it was left in LGPL.
Even when I contributed a core to the OC, I didnt know what kind of
license I should release it under. But just put it under LGPL because
others had done before. My intention was to make my work to be of use
to others if found fitting. whether it is student working on his
project or a manager looking for a efficient plugin for his larger
project shouldnt matter as long as the core used remains in open
domain. I think there should be no problem as long as you maintain the
openess of the core downloaded with/without any modifications made.
This may become an issue if a company makes substantial modifications
to the core which enhances its performance or fucntionality to a great
extent. then I think the license shouldnt restrict them from having a
copyright on the changed core. this, the license dosent address I
believe, so it would be better that in such a case the users take the
written consent of the authors for changes on the core to be made by
them and his no-objection to their having a proprietary core as a
result. This said, I think it is better we develop a licensing concept
much better suited for hardware.

 

[Tom Verbeure]

When I asked the designer of a popular, LGPL licenced IP block if we
could use this code in an asic, the answer was that we
could use it anyway we wanted as long as we released changes to IP
block
*itself*.

Like the other poster said, your best bet is to ask clarification from
the original copyright holder. Most likely, they will agree with the
definition that usage in a proprietary product is permitted as long as
RTL modifications to the core *itself* are publicly released. Look at
it this way: if they did not want to allow this, they would have
released it under GPL instead of LGPL.

It remains to be seen if the laywers of your company (who should be
involved in this!) will be satisfied with an email from the copyright
holders. They may have more peace of minds if a private commercial
license is given a small fee.

Tom

 

[y_p_w]

Tom Verbeure wrote:

When I asked the designer of a popular, LGPL licenced IP block if we
could use this code in an asic, the answer was that we
could use it anyway we wanted as long as we released changes to IP
block
*itself*.

That seems to be the intent of most open source IP.

Like the other poster said, your best bet is to ask clarification from
the original copyright holder. Most likely, they will agree with the
definition that usage in a proprietary product is permitted as long as
RTL modifications to the core *itself* are publicly released. Look at
it this way: if they did not want to allow this, they would have
released it under GPL instead of LGPL.

It remains to be seen if the laywers of your company (who should be
involved in this!) will be satisfied with an email from the copyright
holders. They may have more peace of minds if a private commercial
license is given a small fee.

I've already handed a copy of the code in question and the LGPL to
one of our company's lawyers. However - he said he hasn't considered
open source licenses in a couple of years.

 

[y_p_w]

General Schvantzkoph wrote:

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.

Releasing a generic gate-level netlist of this core probably isn't that
big a deal for my employer. However - we typically use proprietary
processes where we might not want to release gate names for non-
disclosure reasons. Also - many of our design flows have involved
flattened netlists, so which level of "combined object code" needs
to be released.

I've considered releasing my own open source IP. However - there's
gotta be something more HDL specific than the LGPL, and that won't
scare off the majority of companies that use assorted proprietary
resources.

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? 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.

Something tells me the authors of these cores aren't interested in
making money.

 

[Phil Tomson]

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

On Thu, 05 Aug 2004 12:51:28 -0700, y_p_w wrote:

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.

I've gone over the LGPL multiple times, and it seems that the term
"work based on the library" refers only to actual modifications
or close coupling of code with the LGPL'ed component. I'm still
unclear (the language of the LGPL is mind-boggling) whether or
not we would be required to release (and to what extent) the other
source code that is used to develop this product.

Making our modifications to a publicly available open-source core
seems like a fair "price" for its use. We would have no problem
acknowledging that we used this core. My company has a website,
and we could make our mods (if any) available for download there.
My employer more than likely won't want to make our proprietary HDL
source code available though.

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)?

Thanks in advance.

Yu-Ping Wang
Berkeley, California

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?

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. 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.

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.

Phil