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 IP in one of our products.

Specifically, the license talks about linking with a library, deriving from a library etc. Can anyone point to a paper/discussion on this issue (I tried search LGPL, but it hits on every project).

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

Hi Steven,

This is a complex subject, and I preface my remarks with the note that I am not a lawyer (IANAL).

Your best source of information on GPL/LGPL is the Free Software Foundation FAQ:

www.gnu.org/licenses/gpl-faq.html

However its worth noting the FAQ entry for the question "Can I use the GPL to license hardware?".

"Any material that can be copyrighted can be licensed under the GPL. GPLv3 can also be used to license materials covered by other copyright-like laws, such as semiconductor masks. So, as an example, you can release a drawing of a hardware design under the GPL. However, if someone used that information to create physical hardware, they would have no license obligations when distributing or selling that device: it falls outside the scope of copyright and thus the GPL itself."

This is currently a hot topic of debate. For FPGA/ASIC, Verilog/VHDL designs seem to be covered to some extent, since they are very like software. If a manufacturer took an OpenCores design (under LGPL), modified it and then distributed a new IP with a simulation model of that IP, then they would be obliged to distribute the modified source HDL.

However if they were to take the IP, modify it, and manufacture a chip, but with no simulation model, then they would not be legally obliged to publish their modified HDL.

There have been attempts to get round this using the law of contract. The most prominent of these is the TAPR Open Hardware License (OHL), written by John Ackermann, a professional lawyer and hobyist engineer:

www.tapr.org/ohl.html

John has recently published an article on the legal thinking behind the OHL. Toward Open Source Hardware, University of Dayton Law Review, Winter 2009, vol 34-2. The problem behind this approach is that, unlike copyright law, the law of contract varies hugely from jurisdiction to jurisdiction, so a license that works worldwide would be a huge challenge.

You'll see I have also written on the subject on this website Open Source for Hardware?. There is also a call for papers on this subject by the Journal of Information Law and Technology, which was promulgated on the OpenCores forum (www.opencores.org/forum,Cores,0,3480).

I presume you mean that the soft macro is licensed under LGPL and the IP under GPL. Remember that GPL is viral in nature. If you incorporate it into anything else, the whole thing becomes GPL.

You should include the copyright notice relating to the LGPL material. The user needs to know of their rights, and you are obliged to tell them. This is subject to my comments above, regarding the circumstances under which hardware triggers obligations under any GNU license.

Just to clarify you need to make the source code freely available - you can't charge the user for it (although you could charge the cost of media, for example if you posted a CD).

I think your last point refers to your GPL IP containing some LGPL IP. In that case, the whole project is GPL, although the LGPL component would remain under LGPL (for example if someone took your code, and excised just the LGPL part, they could then use that as an LGPL entity).

Again, this is subject to my comments above, regarding the circumstances under which hardware triggers obligations under any GNU license.

You need to be careful about this. The aim of GPL is to disclaim your liability when you reuse material. However, if there is a problem, liability will have to trace back to the cause of the problem. I can't just take someone's copyrighted code, stick a GPL license on it and hope not to be sued!

Hope this is useful. Once again remember IANAL. You should take proper legal advice if you need to.

Jeremy

--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@embecosm.com
Web: www.embecosm.com

Hi Jeremy,

Thanks for the detailed reply. Our company lawyer will have to sign off on this issue, but he won't actually undersand it ;-)

I have one question regarding your reply



I have read the LGPL license, and I don't see one can come to this conclusion. My "interpretation" was that the manufactured hardware is equivelant to the program (in S/W terms).
Further, it contains the soft IP core (which I equate to the S/W library).
If this is the case, then section 6 of the LGPL worries me (it talks about providing the rights to reverse engineer the design).

Have I misunderstood ?

Thanks again for the feedback.

Steven

Hi Steven,

It is at this point I stand back and let the lawyers debate the issue. As far as I am aware there has been no test case. However it comes down to whether manufacturing and distributing a chip amounts to "conveying" as described in the GPL/LGPL. The text talks about conveying "non-source" forms, but this is all written in terms of compiled object code. It is far from clear that this can be stretched to mean a manufactured chip is the compiled object code of a Verilog design.

Once again remember IANAL.

ATB

Jeremy

--
Tel: +44 (1590) 610184
Cell: +44 (7970) 676050
SkypeID: jeremybennett
Email: jeremy.bennett@embecosm.com
Web: www.embecosm.com

Hi Jeremy,

It seems that there are lots of issues for my company lawyer to consider ;-)

Thanks again for the feedback and links,

Steven

I have a similar question. If I use the HD63701 LGLP core in my vintage disk drive recreation. I write my own Verilog based on the disk drive controller schematic and integrate the HD63701 LGPL from open cores by including the source code files with my source code files to be synthesized. I run the Xlinix tools to synthesize the Verilog/vhdl and produce a bit file for the Xlinix fpga I plan to use.

I then build a PCB with various interface circuits and level shifters and load onto the serial flash the image created above. I then sell the disk controller to other vintage disk drive enthusiasts.

It seems to me that for an FPGA, LGPL and GPL are the same thing, because to be LGPL compliant, I have to give the end user the ability to relink my fpga code if there is a newer release of the HD63701 LGPL library. This is not possible, so if I use the HD63701 LGPL code I would have to release my entire source code...

If that is the case, why does open cores prefer LGPL.

What I think we need is a license is LGPL, without the dynamic loading or relinking requirement.

from: https://en.wikipedia.org/wiki/GNU_Lesser_General_Public_License

"A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a "work that uses the Library". Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License.
Essentially, if it is a "work that uses the library", then it must be possible for the software to be linked with a newer version of the LGPL-covered program. The most commonly used method for doing so is to use "a suitable shared library mechanism for linking". Alternatively, a statically linked library is allowed if either source code or linkable object files are provided.[2]"

The first part looks good, but "must be possible for the software to be linked with a newer version" seems impossible to do in an FPGA without releasing the source code.

Why not just talk to the "owner" of the firmware and see if they would be willing to release it under a different license? I realize this doesn't work for all free and open source firmware products, but its probably still worth at least asking.

Dan

(L)GPL licensing for IP cores have been discussed many times. The general consensus is that LGPL for IP cores is interpreted roughly as "Any modifications to the core will fall under LGPL license, but anything outside the core is not affected".

FYI, there will be a session on IP core licensing at this year's orconf

//Olof

Consensus doesn't really count. How does an IP core from opencores comply with LGLP 4.d when it cannot be dynamically linked or relinked after the fact?



Both 0 & 1 are not possible in an FPGA.

It's worth mentioning Javier Serrano of CERN has written a good article exploring the applicability of the GNU GPL licenses to HDL.

http://www.ohwr.org/documents/341

I'm not sure if it's their official opinion, but it has been floated that it might be easier to explain how the GPL applies to HDL rather than drafting a new license from scratch.

http://lists.ohwr.org/sympa/arc/cernohl/2014-07/msg00000.html

There is also a recorded video from orconf 2015 where Javier Serrano talks about this followed by some interesting discussions https://www.youtube.com/watch?v=JgRBDuZQsFg

Yes. He confirmed my assertion that for an FPGA GPL and LGPL are the same because it is not possible to recompile (place/route) with only the updated LGPL library. The proprietary (application) source is needed to do this, so it would need to be included in the conveyance.

So...

Why does opencores recommend LGPL?
What license should be used?

Lastly, It seems to me that we(or FSF) should just create specfic version of LGPL and call it "HLGPL" where they remove the requirement to "recompile/relink with a newer version" when the source is targeted at Hardware synthesis.

On the other hand...
If Altera/Xilinx FPGA tools would allow mere mortals(users) to create "encrypted IP cores", then the proprietary application could be released under LGPL as encrypted IP. A simple top level HDL would connect the encrypted IP application, the Library, and the system libraries. This could then be recompiled (place/route).

I don't think this is quite true. I can compile and evaluate my designs with Verilator--I just can't place and route them onto an FPGA chip with Verilator.

Dan

Maybe I'm misunderstanding the use case here, but I kind of disagree with the equivalence between software "compilation" and "place/route" in the context of an FPGA. The closest equivalent to compilation is probably "synthesis" (kind of).

Can't most of your concerns be addressed by synthesis to a netlist for proprietary IP? It is certainly possible to run PAR with a combination of HDL and netlist based cores.

I guess the argument can be made that reverse engineering the netlist to HDL is possible, but the same is true of software.

Also... I think Xilinx Vivado has supported construction and distribution of IP cores since about 2013... I'm not 100% certain, but I'm pretty sure encryption is supported as well.

Best!

/jw