[riot-users] LGPL Requirements

Craig Younkins craig at freshtemp.com
Mon Mar 23 21:43:02 CET 2015


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

On Mon, Mar 23, 2015 at 7:37 AM, Kaspar Schleiser <kaspar at schleiser.de>
wrote:

> 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.
>
> On 03/22/15 23:42, Craig Younkins wrote:
>
>> 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
>
> _______________________________________________
> users mailing list
> users at riot-os.org
> http://lists.riot-os.org/mailman/listinfo/users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.riot-os.org/pipermail/users/attachments/20150323/9fbc914d/attachment.html>


More information about the users mailing list