<div dir="ltr">Thank you both for the clarification.<div><br></div><div>> Do you mind if we add your questions to our license FAQ?</div><div><br></div><div>Of course not, please do.</div><div><br></div><div>Craig Younkins</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 23, 2015 at 7:37 AM, Kaspar Schleiser <span dir="ltr"><<a href="mailto:kaspar@schleiser.de" target="_blank">kaspar@schleiser.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey,<br>
<br>
whatever I write, I am not a lawyer and we will have to consult e.g., the Free Software Foundation, to clarify these points.<span class=""><br>
<br>
On 03/22/15 23:42, Craig Younkins wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1. Am I legally obligated to provide a software upgrade mechanism on the<br>
device? Do I need to publish the documentation on how to upgrade it?<br>
</blockquote>
<br></span>
§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."<br>
<br>
So, the *license* of the distributed combined work cannot restrict upgrading / modification of the license part.<br>
<br>
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.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2. Am I permitted to only allow signed software upgrades?<br>
</blockquote></span>
See above. You cannot forbid unsigned upgrades in the license terms of your product, but LGPL doesn't mention technical means.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
3. Many micros have lock bits that prevent further programming without<br>
erasure. Are there any restrictions on setting those?<br>
</blockquote></span>
See above.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4. Can I store secrets like private or symmetric keys in flash memory<br>
alongside but that is not part of the flashed binary? This would be<br>
similar to storing those secrets in external EEPROM, which is almost<br>
certainly permitted. This has interesting effects in combination with 3,<br>
including potentially bricking a device if firmware upgrade was<br>
attempted due to erasure of keys.<br>
</blockquote></span>
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.<br>
This data can be put alongside your application, but is not part of it's source code.<br>
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.<br>
<br>
Do you mind if we add your questions to our license FAQ?<span class="HOEnZb"><font color="#888888"><br>
<br>
Kaspar</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<u></u>_________________<br>
users mailing list<br>
<a href="mailto:users@riot-os.org" target="_blank">users@riot-os.org</a><br>
<a href="http://lists.riot-os.org/mailman/listinfo/users" target="_blank">http://lists.riot-os.org/<u></u>mailman/listinfo/users</a><br>
</div></div></blockquote></div><br></div>