6

I'm working on a commercial project involving an STM32 microcontroller, designed to be locked down for security and business reasons. The device can only be updated through a bootloader controlled by a Android app, which allows users to select the firmware version for update without access to the actual hex file or source code.

A small portion of our FW is under LGPLv2.1. Given the restrictive update process and the lack of direct access for users to the hex or source code, I'm concerned about complying with the LGPL requirements that allow users to modify and recompile at least the LGPL parts.

My questions are:

  1. Can LGPLv2.1 requirements be met in this restricted environment?
  2. Are there recommended practices or alternative solutions that allow the use of LGPL code without violating the terms while maintaining device security and integrity?

Any advice or insights from similar experiences would be greatly appreciated.

Thank you.

MadHatter
  • 48,547
  • 4
  • 122
  • 166
WITC
  • 63
  • 4
  • LGPLv2 or LGPLv3? – MadHatter Feb 05 '24 at 08:08
  • it is LGPL 2.1 version – WITC Feb 05 '24 at 09:04
  • WITC, welcome to OpenSource, and thanks for a well-written, interesting, and well-received first question. It's traditional to accept an answer you're happy with by clicking on the "tick" outline next to it, which drives the site's reputation system for both you and the answer's author, and marks the question as completed so it doesn't float around forever. If on the other hand you're not yet satisfied, it's useful if you can add to your question to clarify what still remains, in your mind, unanswered. My apologies if you already know all this! – MadHatter Feb 06 '24 at 08:38

2 Answers2

10

The LGPLv2.1 has a "loophole" that makes it possible to use an LGPLv2.1 library in your situation. The "loophole" is that, while customers must be able to build their own copy of the hex file, you are not required to give them the possibility to upload that custom hex file to their device.

To comply with the LGPLv2.1 license requirements, you must provide

  • The source code of the LGPLv2.1 portion of your software
  • Source code or binary files of the rest of the software to make it possible to re-create the binary.
  • Enough information on the build tooling that a fellow programmer is able to re-create the binary.

If the dependency were under the LGPLv3 license, you would have been required to also provide a means to actually run the produced executable/hex-file on the device, but that requirement does not exist in the LGPLv2.1.

Are there recommended practices or alternative solutions that allow the use of LGPL code without violating the terms while maintaining device security and integrity?

The LGPL does not care about why you would want to prevent your users from knowing what software runs on their device or, in the case of LGPLv3, to run a modified version of that software.

But, the LGPLv3 also doesn't care about the level of warranty and support that users get who run a modified software. Having a custom firmware version on the device is a valid reason to void the warranty.

If there are legal reasons (e.g. complying to mandated standards) why parts of the code cannot be modified, then those parts can be in a proprietary-licensed part that links to the LGPL part and is provided only in binary format (with a license that explicitly forbids all modification).

Bart van Ingen Schenau
  • 29,549
  • 3
  • 46
  • 83
  • 2
    Couldn't have put it more clearly myself - bravo! – MadHatter Feb 05 '24 at 11:15
  • 3
    Depending on the applicable laws (ask your lawyers, do not trust strangers on the internet!), you might also be able to simply include a statement that "the XYZ component was designed to comply with regulation W ([reference]), and modifications may void this compliance; [company] will not be held responsible for any such violations." Not all laws/regulations will let you get away with that sort of liability-shifting, which is why it is so important to check with lawyers. – Kevin Feb 05 '24 at 19:15
  • 2
    "Having a custom firmware version on the device is a valid reason to void the warranty." In the United States this is certainly not the case. You can void the warranty if damage that would otherwise be covered under the warranty is caused by the custom firmware. If the device contains, say, plastic parts, and the warranty covers the plastic parts breaking, it would certainly be illegal in the US to refuse that coverage on the basis of an unrelated software change. – Glenn Willen Feb 06 '24 at 00:08
  • 1
    @GlennWillen Unless the software change is related to the breakage of the parts, for example because the software is expected to stop powering a motor when a part moves to its end stop, and the modified software did not. – user253751 Feb 07 '24 at 16:39
  • Thank you: I think I understand, but as a commercial company, we are not allowed to publish the source code for our devices, so we cannot use 3rd party code with LGPL2 license. Yes, we have secure boot, but we still don't want anyone to be able to look into our source codes. – WITC Feb 08 '24 at 08:07
  • 1
    @WITC forgive me, but your comment suggests you may not understand. As Bart clearly says, LGPLv2.1 requires you to give the binary recipient enough that they could create a new binary with an upgraded or replaced LGPL library. Source code will accomplish this, but so will linkable object code for your proprietary executable. I also note that when you say "as a commercial company, we are not allowed to publish the source code", I think you mean "as a commercial company, we have decided not to publish the source code"; commercial companies are permitted to publish source, and many do. – MadHatter Feb 08 '24 at 11:13
  • Some jurisdictions (like the EU) have stated that hardware warranty can't legally require a unmodified software, so it is not a valid point there – Nicolas Formichella Feb 09 '24 at 10:12
  • @MadHatter Yes, I really don't understand it much. Our management prohibits us from publishing the source code, or a binary or hex file. Therefore, we probably really can't use code with LGPL?! – WITC Feb 12 '24 at 09:12
  • 2
    @WITC, the consequence of the management decision to not allow publishing the software in any form (other than flashed on the device) is indeed that you cannot comply with the LGPL license (and maybe also not with other copyleft licenses) and that you therefor cannot use third-party software under that license. – Bart van Ingen Schenau Feb 12 '24 at 10:49
2

This is answered by the GPL FAQ on Tivoization (quoted below), which applies to LGPL too.

The LGPLv2 and GPLv2 requires source code and the means to recompile a modified version of the software to be made available to those who received a copy of the software. However, it does not require the software to be updateable into the device. Updating the software into the device is typically prevented using Secure Boot, because the end user would not have the signing keys.

The LGPLv3 and GPLv3 introduced new conditions in Section 6 to require that the end user of a consumer product must be able to receive the signing keys and update the software into the device.

Due to this, to be on the safe side, many embedded product manufacturers ban the presence of any software licensed under GPLv3, LGPLv3 or AGPLv3 on their products, regardless of whether it is a consumer product or not. Secure Boot is necessary for ensuring security and safety of the product, while preventing violation of product liability and loss of warranty.

Linus Torvalds strongly disagreed with the anti-Tivozation clause, and hence licensed the Linux kernel under GPLv2-only.

What is tivoization? How does GPLv3 prevent it? (#Tivoization)

Some devices utilize free software that can be upgraded, but are designed so that users are not allowed to modify that software. There are lots of different ways to do this; for example, sometimes the hardware checksums the software that is installed, and shuts down if it doesn't match an expected signature. The manufacturers comply with GPLv2 by giving you the source code, but you still don't have the freedom to modify the software you're using. We call this practice tivoization.

When people distribute User Products that include software under GPLv3, section 6 requires that they provide you with information necessary to modify that software. User Products is a term specially defined in the license; examples of User Products include portable music players, digital video recorders, and home security systems.

ruben2020
  • 2,318
  • 3
  • 19
  • Note that tivoization is an accidental loophole and even though it is technically legal, everybody who knows what you are doing will hate you forever. – user253751 Feb 07 '24 at 16:40