LGPL HDL in larger FPGA design

Question

There is a project called NetFPGA that has HDL code for various Ethernet uses in an FPGA. The project is listed as LGPL. From a software perspective, my understanding is that if you dynamically link a LGPL library you can use it in a commercial application. How would this work in the case of an FPGA design? The concept of dynamic linking does not really exist in the hardware design.

If I use the LGPL HDL in a larger design would I have to release the source of the whole project? If I edit the LGPL HDL and use it in a larger design would I have to release the source of the LGPL HDL and/or the whole project?

(https://github.com/NetFPGA/NetFPGA-public/wiki/Licensing)

Answer 1

The aim of the LGPL license is that people can replace the LGPL code in a larger project, without requiring that the complete source code of the larger project is disclosed.

I am not familiar with how HDL works for FPGA design, but the LGPL requires that

• you release the modified LGPL HDL code under the LGPL license
• you release the rest of the full project in a format that makes it possible to re-create your FPGA design with another version of the LGPL code. This format does not need to be human-readable or source code.
• you give recipients of the FPGA design the right to replace the LGPL portion of it.

Answer 2

How would [the LGPL] work in the case of an FPGA design?

It doesn't. At least, not very well. You've correctly identified the problem with this license construction.

The only situation I can think of where the LGPL might be usefully applied to an FPGA design would be in a design that uses dynamic reconfiguration. In particular, this might be relevant to the use of a freely-licensed FPGA design in an environment which mandates the use of a non-free wrapper, like Amazon EC2 FPGA instances.

Answer 3

If I use the LGPL HDL in a larger design would I have to release the source of the whole project?

Possibly, but if so that's likely a limitation of the FPGA development tooling. If the tooling were good, it would let you isolate the LGPL'd component's placement in the design specifically to facilitate replacing it in-place without rebuilding the entire design/bitstream from source. This would be useful not only for licensing purposes, but also to make build times and testing cycles much more reasonable.

With that said, in order not to have to release the full source, you would also need to have clear interface boundaries between the components. For an ethernet core this does not seem like a problem; it will have documented public interfaces that the rest of the components interface with it through. On the other hand, if the LGPL coder were an FPU or vector operations core taken from one softcore CPU design that you were reusing as part of another softcore CPU design, it would be a lot less clear whether it was being used as a "library" or whether your new CPU design was a derived work requiring all source to be released.