LGPL Requirements

Help archive
1

Hello there,

Not sure which list this should go in, devel or users.

A few questions about the LGPL requirements. We may not do some of these, and many OSS advocates would not like it if we did, but I need to understand our legal obligations.

  1. Am I legally obligated to provide a software upgrade mechanism on the device? Do I need to publish the documentation on how to upgrade it?

  2. Am I permitted to only allow signed software upgrades?

  3. Many micros have lock bits that prevent further programming without erasure. Are there any restrictions on setting those?

  4. Can I store secrets like private or symmetric keys in flash memory alongside but that is not part of the flashed binary? This would be similar to storing those secrets in external EEPROM, which is almost certainly permitted. This has interesting effects in combination with 3, including potentially bricking a device if firmware upgrade was attempted due to erasure of keys.

Thank you!

Best, Craig Younkins FreshTemp

2

----- Mail original -----

De: "Craig Younkins" <craig@freshtemp.com> À: users@riot-os.org Envoyé: Dimanche 22 Mars 2015 23:42:00 Objet: [riot-users] LGPL Requirements

Hello there,

Not sure which list this should go in, devel or users.

A few questions about the LGPL requirements. We may not do some of these, and many OSS advocates would not like it if we did, but I need to understand our legal obligations.

1. Am I legally obligated to provide a software upgrade mechanism on the device? Do I need to publish the documentation on how to upgrade it?

I don't think so. It could/should be in case of GPL v3.

2. Am I permitted to only allow signed software upgrades?

I think so.

3. Many micros have lock bits that prevent further programming without erasure. Are there any restrictions on setting those?

I don't think so.

4. Can I store secrets like private or symmetric keys in flash memory alongside but that is not part of the flashed binary? This would be similar to storing those secrets in external EEPROM, which is almost certainly permitted. This has interesting effects in combination with 3, including potentially bricking a device if firmware upgrade was attempted due to erasure of keys.

More generally speaking I don't think LGPL v2 is a problem for you except in the case you "derivate" LGPL source code without providing modifications to the end user. LGPL adds "linking exception" (to the GPL) so you can even link priopritary objects with LGPL libraries.

regards

3

Hey,

whatever I write, I am not a lawyer and we will have to consult e.g., the Free Software Foundation, to clarify these points.

1. Am I legally obligated to provide a software upgrade mechanism on the device? Do I need to publish the documentation on how to upgrade it?

�6 of LGPL permits combinations of the licensed work or works based on it "to produce a work containing portions of the Library, and [to] distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer�s own use and reverse engineering for debugging such modifications."

So, the *license* of the distributed combined work cannot restrict upgrading / modification of the license part.

As I read that, if there are *technical* reasons prohibiting upgrades (e.g., only signed or no upgrades possible), LGPL poses no restrictions on those.

2. Am I permitted to only allow signed software upgrades?

See above. You cannot forbid unsigned upgrades in the license terms of your product, but LGPL doesn't mention technical means.

3. Many micros have lock bits that prevent further programming without erasure. Are there any restrictions on setting those?

See above.

4. Can I store secrets like private or symmetric keys in flash memory alongside but that is not part of the flashed binary? This would be similar to storing those secrets in external EEPROM, which is almost certainly permitted. This has interesting effects in combination with 3, including potentially bricking a device if firmware upgrade was attempted due to erasure of keys.

IMHO the flashed binary can be seen as a file system layout. Part of it might be RIOT, part of it might be your application, and part of it might be some data your application is using. This data can be put alongside your application, but is not part of it's source code. It should not make a difference if your application is just opening a file you distribute along with your application, or if it is put somewhere in it's own section by the linker script and your application accesses it using the flash address.

Do you mind if we add your questions to our license FAQ?

Kaspar

4

Thank you both for the clarification.

Do you mind if we add your questions to our license FAQ?

Of course not, please do.

Craig Younkins