Zukunftssichere Softwarelizenzen für Firmwares

Bei der Lizenzvergabe für Firmware-Code [1] haben wir bislang immer die GPL Lizenz gewählt und fanden sie dafür grundsätzlich ausreichend.

Persönlich stellte ich mir vor kurzem die Frage – gerade vor dem Hintergrund wenn man die Zeitreise der letzten Jahre Revue passieren lässt – was denn in Zukunft sein wird, wenn wir die ganzen Embedded Controller – in welche Runtime auch immer in der Zukunft en vogue [2] sein wird – wegvirtualisieren werden – und wie es dabei eigentlich mit den Lizenzen aussehen wird.

Siehe da – solche kruden Gedankenhypothesen wurden mal wieder von der Realität eingeholt: Am 29. Mai 2019 erschien ganz frisch die Ankündigung eines MicroPython-Port für das großartige Emscripten [3] auf der Bildfläche.

Wir werden also die Lizenz für die Firmwares ebenfalls auf die umfassendere AGPL umstellen, wenn dazu keine Vetos reinkommen.


  1. https://github.com/hiveeyes/arduino oder
    https://github.com/hiveeyes/hiveeyes-micropython-firmware ↩︎

  2. Out of thin air, anyone? Real cloud computing, you name it. ↩︎

  3. http://www.quakejs.com/ ↩︎

1 Like

Zur Erklärung warum AGPL statt GPL könnte das hilfreich sein:

https://www.gnu.org/licenses/why-affero-gpl.de.html

Die GNU Affero General Public License (AGPL) ist eine modifizierte Version der GNU General Public License (GPL), Version 3, und enthält eine zusätzliche Bedingung: wird ein modifiziertes Programm auf einem Server ausgeführt und kommuniziert dort mit anderen Nutzern, muss der Server auch den entsprechenden modifizierten Quellcode des ausgeführten Programms zum Herunterladen bereitstellen.

agpl bringt soweit ich das sehe praktisch nix fuer firmwares auf devices, sondern nur fuer reine serverbasierte software.
d.h. fuer z.b. kotori, etc schon relevant
fuer das c/python auf den devices mit den sensoren dran bringt uns das praktisch nix. (dafuer isses auch nicht gedacht).

die grundidee von agpl (soweit ich das verstanden habe) ist - das jemand der $platform betreibt mit agpl basis drunter die changes vom vanilla releasen muss, selbst wenn dieser jemand das binary nicht an 3. weitergibt (sondern z.b. zugriff auf eine runtime davon in form von logins auf der platform).

es aendert also den zwang “zugriff auf die aenderungen bieten” von “alle denen du das binary gibtst” auf “alle die den service, der dadurch moeglich ist benutzen”

ich bin kein anwalt - also alle angaben ohne gewaehr ;)