4

I am developing a firmware for embedded devices.

The project contains many libraries, plus one main executable that uses all the libraries. Each component is compiled individually. In the final step, all components are statically linked together to create one monolithic firmware image that gets flashed to the CPU.

I wish to use the LGPL license for my core libraries and the MIT license for the main executable that uses the libraries. My goal is to enable developers to create their own custom proprietary libraries from scratch and add those libraries into a derivative firmware without triggering a source release (provided they can make the addition without modifying my core libraries).

  • Can the code for the main executable be MIT/BSD licensed even though it is statically linked to LGPL libraries?
  • Does the combination of LGPL + MIT (or BSD) accommodate for the creation of proprietary additions as described above, while requiring copyleft for the core libraries specifically (which is where most of my effort was spent)?
4

IANAL.

Section 4, subsection D of the LGPL-3 requires (emphasis mine):

d) Do one of the following:

  1. Convey the Minimal Corresponding Source under the terms of this License, and the Corresponding Application Code in a form suitable for, and under terms that permit, the user to recombine or relink the Application with a modified version of the Linked Version to produce a modified Combined Work, in the manner specified by section 6 of the GNU GPL for conveying Corresponding Source.
  2. 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.

Section 5 clarifies the combination with non-LGPL works (emphasis mine):

You may place library facilities that are a work based on the Library side by side in a single library together with other library facilities that are not Applications and are not covered by this License, and convey such a combined library under terms of your choice, if you do both of the following:

a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities, conveyed under the terms of this License.
b) Give prominent notice with the combined library that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work.

Furthermore, the GPL FAQ says the following about static linking:

If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.

The main requirement here is that the people receiving a distributed copy of the firmware must have the option to modify the LGPL-licensed portions of the code and then use their modified version in place of yours to get a fully-working final firmware image ("fully working" barring any mistakes in their modifications).

If the source code for all components is available and can be built, then that is sufficient to meet this requirement for the LGPL-3.

If some components are proprietary or contain proprietary modifications, then those components must be provided as individual object files that can be re-linked to the (potentially modified) LGPL-licensed components by the end user.

Providing object files (*.o and *.a) alongside the distribution, as well as the instructions to combine those objects into a final firmware image, should be sufficient to meet this requirement for the LGPL-3.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.