GNU Lesser Public License and Soft IP

[moogyd]

Hi,

I am looking through the GNU Lesser General Public License (LGPL) and
trying to understand how it applies to H/W i.e. Using the vhdl or
verilog IP in one of our products.

I have seen where it is stated that IP's license under LGPL can be
used in propriety products, but I don't know how one comes to this
conclusion from reading the LGPL.

Specifically, the license talks about linking with a library, deriving
from a library etc.

My understanding is (from a simple example):

There is an soft macro IP named LGPL_IP and an IP named GPL_IP

- I can use LGPL_IP in my product PRODUCT_A without restriction
- LGPL_IP will be used in a compiled (synthesized)
- I *do not* need to make PRODUCT_A available under LGPL
- If I modify LGPL_IP source code, I need to make the changes
available under LGPL ?
- Do I need to include a copyright notice relating to LGPL_IP in the
documentation for PRODUCT_A (if it relates to LGPL_IP operation?)

- I can use GPL_IP in my product PRODUCT_B without restriction
- GPL_IP will be used in a compile form (syntheised)
- I *do* need to make PRODUCT_B available under GPL (as source if
someone reqests)
- If I modify LGPL_IP source code, I need to make the changed
available under GPL

- In both cases, there is no warranty or liability

Can anyone state (or suggest) exactly exactly which section of the
LGPL is applicable to this case ?

Thanks,

Steven

 

[glen herrmannsfeldt]

< I am looking through the GNU Lesser General Public License (LGPL) and
< trying to understand how it applies to H/W i.e. Using the vhdl or
< verilog IP in one of our products.

< I have seen where it is stated that IP's license under LGPL can be
< used in propriety products, but I don't know how one comes to this
< conclusion from reading the LGPL.

My understanding is that the usual use is for libraries, such
as the C library. Without the LGPL you couldn't distribute compiled
C programs (for example) because of the included library routines.
(Well, you could but you would have to distribute source, too.)

< Specifically, the license talks about linking with a library,
< deriving from a library etc.

I don't know the details, but that is its main use.

-- glen

 

[Pieter Hulshoff]

Hello Steven,

I am looking through the GNU Lesser General Public License (LGPL) and
trying to understand how it applies to H/W i.e. Using the vhdl or
verilog IP in one of our products.

I have seen where it is stated that IP's license under LGPL can be
used in propriety products, but I don't know how one comes to this
conclusion from reading the LGPL.

You should keep in mind that the (L)GPL licenses were primarily written
with software designs in mind. As such, not all terminology maps well
to hardware designs.

The main difference between the GPL and the LPGL is that embedding GPL
code within your design requires you to make your entire design available
under the GPL, while LGPL only requires you to make the LGPL code and any
changes you make to the LGPL code available under the LGPL. As such, you're
allowed to embed LGPL code into your proprietary product as long as you keep
the embedded design and all changes to it available under the LGPL.

Embedding (L)GPL code into your design is a matter of deciding how the
cost of building said code by yourself weighs against compliance with
the (L)GPL license.

Kind regards,

Pieter Hulshoff

 

[Rich Webb]

Hello Steven,


You should keep in mind that the (L)GPL licenses were primarily written
with software designs in mind. As such, not all terminology maps well
to hardware designs.

The main difference between the GPL and the LPGL is that embedding GPL
code within your design requires you to make your entire design available
under the GPL, while LGPL only requires you to make the LGPL code and any
changes you make to the LGPL code available under the LGPL.

That's correct only if the application can be supplied as an object
module that dynamically links to the LGPL code. If that's not possible
(and I'm not sure how it could be in any HDL environment) then
sufficient source code must be supplied to allow an interested user to
recreate the application with the current or a modified version of the
LGPL code. See Section 4.d of the LGPL. As you say, it's aimed at a
conventional software model.

 

[Pieter Hulshoff]

That's correct only if the application can be supplied as an object
module that dynamically links to the LGPL code. If that's not possible
(and I'm not sure how it could be in any HDL environment) then
sufficient source code must be supplied to allow an interested user to
recreate the application with the current or a modified version of the
LGPL code. See Section 4.d of the LGPL. As you say, it's aimed at a
conventional software model.

An encrypted hierarchical netlist with the LGPL module as separate non-encrypted
hierarchy combined with the source code may do it. Note that this only needs to
be supplied to actual users of your chip; not to the public at large. Still, it's
probably easier to contact the copyright holders of the LGPL module to get a
separate license or explanation to this part. I doubt a developer puts an LGPL
license on a module with the idea that it could never be used within a non-GPL
environment.

Kind regards,

Pieter Hulshoff

 

[moogyd]

Hi,

Thanks for all the feedback.

This is obviously quite complex :-(, and there seems to be no correct
answer.

Additional feedback I received was that there is a significant
difference between H/W and S/W.
- S/W Can be copyrighted
- H/W Cannot be copyrighted - it can only be patented.

The link is

http://www.febo.com/law/Ackermann_Open_Source_Hardware_Article_2009.pdf

GPL is based on copyright law, and this doesn't apply to H/W. Since I
am targeting an ASIC (it's all I deliver), (L)GPL no longer applies,
so I should be alright.

(I will also contact the copyright holder and check their
understanding)

Anyway, thanks again for the feedback,

Steven

 

[jm l]

> GPL is based on copyright law, and this doesn't apply to H/W. Since I
am targeting an ASIC (it's all I deliver), (L)GPL no longer applies,
so I should be alright.

I think that's wrong.
For example, a CD containing software is just a piece of hardware, but
it's content is copyrighted.
Your ASIC contains a "copy" of the LGPL software, so you must conform
to the LGPL license.

But I'm not a lawyer...

 

[Pieter Hulshoff]

Additional feedback I received was that there is a significant
difference between H/W and S/W.
- S/W Can be copyrighted
- H/W Cannot be copyrighted - it can only be patented.

The link is

http://www.febo.com/law/Ackermann_Open_Source_Hardware_Article_2009.pdf

GPL is based on copyright law, and this doesn't apply to H/W. Since I
am targeting an ASIC (it's all I deliver), (L)GPL no longer applies,
so I should be alright.

The (L)GPL is a license delivered with the copyrighted VHDL/Verilog design.
As such, you can use it within the boundaries of the license, or adhere
to copyright law. Wether the resulting ASIC is copyrighted/patented/etc. is
not relevant towards the usage of the copyrighted VHDL/Verilog code. As the
article you mentioned indicated:
"There is nothing in the copyright law to stop one from implementing the
circuit – in other words, the idea – described by a schematic diagram, even
if that diagram is clearly subject to copyright."
This implies that copyright still applies to part of the design process even
if the end-result (the ASIC) does not. The main difficulty however is that
the (L)GPL terminology doesn't map very well to the hardware so the best thing
is usually to contact the copyright holders, and ask them what you are and
are not allowed to do with their code.

Kind regards,

Pieter Hulshoff

 

[moogyd]

The (L)GPL is a license delivered with the copyrighted VHDL/Verilog design.
As such, you can use it within the boundaries of the license, or adhere
to copyright law. Wether the resulting ASIC is copyrighted/patented/etc. is
not relevant towards the usage of the copyrighted VHDL/Verilog code. As the
article you mentioned indicated:
"There is nothing in the copyright law to stop one from implementing the
circuit – in other words, the idea – described by a schematic diagram, even
if that diagram is clearly subject to copyright."
This implies that copyright still applies to part of the design process even
if the end-result (the ASIC) does not. The main difficulty however is that
the (L)GPL terminology doesn't map very well to the hardware so the best thing
is usually to contact the copyright holders, and ask them what you are and
are not allowed to do with their code.

Kind regards,

Pieter Hulshoff

Hi Peter,

You are correct in that the mapping to H/W (and the H/W design flow)
is not defined, and therefore we cannot be sure about anything. I
would therefore have difficulty recommending the use of LGPL IP within
any products within our company.

I have contacted the copyright holder, and we are currently in
discussions about the best way to proceed.

Thanks for you comments,

Steven

 

[moogyd]

 > GPL is based on copyright law, and this doesn't apply to H/W. Since
I


I think that's wrong.
For example, a CD containing software is just a piece of hardware, but
it's content is copyrighted.
Your ASIC contains a "copy" of the LGPL software, so you must conform
to the LGPL license.

But I'm not a lawyer...

Hi,

The CD analogy is incorrect. The CD containing the S/W contains the
copyrighted material (in a digital form), and this would also apply to
the verilog (or VHDL) source, and even the netlist (?).

In my opinion (and from what I have read), Copyright (and therefore
GPL) does not apply to H/W.

e.g. If I design a fantastic new type of Widget, I own the copyright
of the technical drawings. However, there is *nothing* in law to
prevent you (or anyone else) taking this drawing and producing this
new type of Widget.
I would only have protection if I had patented the design.

(I am also not a lawyer, and this is my understanding).

My conclusion from this investigation is that LGPL is probably *not*
OK if you want to keep your end products and company secrets secret
(there are too many question marks over interpretation).

Thanks,

Steven

p.s. Please don't take this thread as "big corporation takes community
effort for profit". As a company, we would probably be happy to return
improvements we made to the IP back to the community, but we cannot
afford to take the risk that someone would have access to our
unrelated IP

 

[Pieter Hulshoff]

e.g. If I design a fantastic new type of Widget, I own the copyright
of the technical drawings. However, there is *nothing* in law to
prevent you (or anyone else) taking this drawing and producing this
new type of Widget.

Actually, there is! There is nothing preventing you from making a clean
room reverse engineering of the drawing (which I admit is relatively easy
compared to most reverse engineering), but producing by copying is still
in violation of copyright. It's just harder to deal with in a court of law
(that's aside from a widget being art, and thus covered by other parts of
copyright law as well).

With regards to an ASIC: there's nothing in copyright law preventing you
from taking my (L)GPL code, and doing a clean room reverse engineering of
said code, but if you use it as direct input for your design process
without adhering to the license, you're still in violation of copyright
law. Not by distributing the chip, but simply as part of your design process.

In general though, you should also consider what's more costly to your company:
designing the (L)GPL code by yourself or using it and adhere to the license. If
it's 90% of your design effort, then you should wonder how much you're protecting
anyway, and if it's 10% of your design effort, then you should seriously consider
writing your own implementation.

Kind regards,

Pieter Hulshoff

 

[glen herrmannsfeldt]

I am also not a lawyer.

The one I remember is that patent protects the idea, copyright
protects the expression of the idea.

The CD analogy is incorrect. The CD containing the S/W contains the
copyrighted material (in a digital form), and this would also apply to
the verilog (or VHDL) source, and even the netlist (?).

In my opinion (and from what I have read), Copyright (and therefore
GPL) does not apply to H/W.

I don't see any problem with copyrighting hardware, but the protection
is weak. Someone can generate a new expression of the same idea
and get around it. Considering the "look and feel" discussed some
years ago, one might, for example, copyright a front panel design
for some hardware. Moving the controls around and changing the
color might get around that, but it would protect against exact
copies of the original.

e.g. If I design a fantastic new type of Widget, I own the copyright
of the technical drawings. However, there is *nothing* in law to
prevent you (or anyone else) taking this drawing and producing this
new type of Widget.

In copyright sense, that would be a new expression of the idea.
Well, I think you have to be a little careful. One couldn't copy
the drawings while building the new widget, but if they bought
a copy then they could create all the widgets from it that
they wanted to.

I would only have protection if I had patented the design.

Consider the case that someone patented the murder mystery.
(I have no idea if that has or hasn't been done.) That would
restrict story writing for years to come. Copyrighting one
protects that specific mystery but allows others to write
different ones.

(I am also not a lawyer, and this is my understanding).

My conclusion from this investigation is that LGPL is probably *not*
OK if you want to keep your end products and company secrets secret
(there are too many question marks over interpretation).

It might work in some situations. It would be a little more
restrictive that public domain, for example.

-- glen

 

[glen herrmannsfeldt]

Actually, there is! There is nothing preventing you from making a clean
room reverse engineering of the drawing (which I admit is relatively easy
compared to most reverse engineering), but producing by copying is still
in violation of copyright. It's just harder to deal with in a court of law
(that's aside from a widget being art, and thus covered by other parts of
copyright law as well).

As usual, I am not a lawyer. It seems to me that you could buy a
copy of the copyrighted drawings and create widgets as different
expressions of the same idea. You couldn't copy the drawings, though.

With regards to an ASIC: there's nothing in copyright law preventing you
from taking my (L)GPL code, and doing a clean room reverse engineering of
said code, but if you use it as direct input for your design process
without adhering to the license, you're still in violation of copyright
law. Not by distributing the chip, but simply as part of your design process.

But the whole idea for the LGPL is that it does allow copying.
Mostly it is for system libraries which get copied into the output
file by the linker, pretty much (in the copyright sense) unchanged.

I would say that you could use an LGPL verilog module in your
design in the same way one uses a C library routine when compiling
with GCC. The LGPL is needed to allow distribution of GCC compiled
output. If one modified the LGPL module then one would have
to release the source for that module, which might be okay.

For a GPL module, one would have to go through the clean room
implementation, but not for the LGPL module.

In general though, you should also consider what's more costly to
your company: designing the (L)GPL code by yourself or using it
and adhere to the license. If it's 90% of your design effort,
then you should wonder how much you're protecting anyway, and if
it's 10% of your design effort, then you should seriously consider
writing your own implementation.

-- glen

 

[Pieter Hulshoff]

I would say that you could use an LGPL verilog module in your
design in the same way one uses a C library routine when compiling
with GCC. The LGPL is needed to allow distribution of GCC compiled
output. If one modified the LGPL module then one would have
to release the source for that module, which might be okay.

The main problem with the LGPL and hardware lies in clause 4d (see
http://www.gnu.org/copyleft/lesser.html for details). It's a clause
that makes a lot of sense when applied to software, but none when
applied to hardware. It's up to the copyright holders how to wish
to apply this clause when it comes to hardware.

Kind regards,

Pieter Hulshoff

 

[ajjc]

The main problem with the LGPL and hardware lies in clause 4d (seehttp://www.gnu.org/copyleft/lesser.htmlfor details). It's a clause
that makes a lot of sense when applied to software, but none when
applied to hardware. It's up to the copyright holders how to wish
to apply this clause when it comes to hardware.

Kind regards,

Pieter Hulshoff

Yes, that is actually the key point.

"1) Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (a) uses at run time a copy
of the Library already present on the user's computer system, and (b)
will operate properly with a modified version of the Library that is
interface-compatible with the Linked Version. "


My take on it, and IANAL, is that by having a reasonable library/API
interface, the intent of
section 4d is satisfied, through that type of firewall. You should be
able to replace the LGPL library with any other library that can use
that interface.
This will, I believe, effectively give you
the license firewall desired and implied by the term "library".

The synthesis step is the compile step, and a "derivative work", the
mapped netlist is produced
by a compiler. Up to this step, I believe you can argue that the
model is the same as the
software world.

Where you now do the place and route, bitstream download and run is
where the machine models and the copyright-based "derivative work" GPL/
LGPL licensing gets into new territory for hardware described by
textual models(e.g. HDL code) and many, many transformational programs
(e.g. place and route, partial reconfiguration, etc.). In fact, I
believe that multi-core machines will end up having this same
problem...interpreting the Von Neumann machine model magic of "static
linking/dynamic linking" with repect to what that means with new
machine models and modes of operation for the GPL/LGPL license
hierarchy.

As one of the other contributors in this thread mentioned, asking the
creators of the library for
reasonable permissions can stave off misinterpretations later on.

alan

 

[glen herrmannsfeldt]

(snip of LGPL and hardware discussion)

Yes, that is actually the key point.

"1) Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (a) uses at run time a copy
of the Library already present on the user's computer system, and (b)
will operate properly with a modified version of the Library that is
interface-compatible with the Linked Version. "

As before, I am not a lawyer, but this is a computer question.

This has to do with modified versions of code distributed as
shared libraries. It was some years ago that I looked into the LGPL
question, and GNU/GCC does use shared libraries, so it makes some sense.

Looking at the intent, not the wording, the intent is that if someone
modifies it and distributes it that previous users can use it.

Now, this actually does make sense in the hardware sense with
partial reconfiguration, but I don't think that is where you are
actually trying to go. You could claim, though, that partial
reconfiguration corresponds to software dynamic linking. One could
distribute a .BIT file with a known interface, and allow others
to interface to it, or to a modified version of it.

Does LGPL require dynamic libraries, or is one still allowed to
distribute static linked libraries? The convenience of DLL is
that the code isn't so comingled, and that one can distribute one
and expect users (licensees) to keep it separate. Also, as
that paragraph allows, one can use a new version without recompilation.

If the original author decides to distribute static linked libraries,
modifications should be done in such a way that existing code still
works with the modified library. (after relinking)

Much of the software/ABI discussion should apply at the module
level in HDL. If you don't modify the original code, but use it
as is then many of these problems don't appear.

-- glen

 

[Paul Uiterlinden]

Hi,

Thanks for all the feedback.

This is obviously quite complex :-(, and there seems to be no correct
answer.

Additional feedback I received was that there is a significant
difference between H/W and S/W.
- S/W Can be copyrighted
- H/W Cannot be copyrighted - it can only be patented.

The link is

http://www.febo.com/law/Ackermann_Open_Source_Hardware_Article_2009.pdf

Just FYI, I noticed the link is mentioned in today's article in the IC
Design and Verification Journal:

http://www.icjournal.com/articles/2009/20091020_opensource.htm