Entwickler von proprietärer Software sind manchmal misstrauisch gegenüber Embedded-Linux-Plattformen, aufgrund der Auswirkungen von Open-Source-Lizenzen wie der GPL (der GNU Public License) für ihre Anwendungen. Sie befürchten, dass sie durch den Einsatz von Linux den Verpflichtungen aus den Open-Source-Lizenzen anderer Softwarekomponenten auf dem System in einer Weise ausgesetzt sein könnten, dass sie (durch Rechtsstreitigkeiten) gezwungen werden könnten, ihren Quellcode mit Wettbewerbern, Kunden oder der Öffentlichkeit zu teilen.
Ohne den Anspruch zu erheben, Rechtsberatung anzubieten, präsentiert dieser Artikel einige praktische Hinweise und Vorschläge für diejenigen, die darüber nachdenken, eine proprietäre Anwendung auf einer Open-Source-Plattform einzusetzen, basierend auf den typischen Erfahrungen vieler unserer Kunden, die gängige Plattformen wie Digi Embedded Yocto, Linaro, Android und andere verwenden.
Android als Open-Source-Alternative
Zugegeben, der sicherste und zuverlässigste Weg, die GPL zu vermeiden, ist, überhaupt nicht mit GNU/Linux zu arbeiten: Googles Android-Betriebssystem bietet eine Open-Source-Alternative für eingebettete Geräte, die von Anfang an bewusst so konzipiert wurde, dass GPL-lizenzierte Software aus der Benutzerumgebung entfernt wurde, zugunsten von Komponenten mit freizügigeren Lizenzen (wie die Apache- oder BSD-Lizenzen), die von den Entwicklern abgeleiteter Werke keine Freigabe ihrer Quellen verlangen.
Moderne Android-Versionen enthalten im Wesentlichen keine GPL-Komponenten (abgesehen vom Linux-Kernel selbst, der keine Einschränkungen für Anwendungen vorsieht). Es sind Distributionen für gängige Hardware verfügbar (einschließlich der ConnectCore® SOMs von Digi), und Android wurde erfolgreich auf viele kundenspezifische Embedded-Boards portiert.
Andererseits ist Android traditionell weniger gut für Headless-Systeme geeignet, und bis zu einem gewissen Grad ist es ein Betriebssystem, das von und für Mobiltelefonhersteller und Mobilfunk Carrier gepflegt wird. Obwohl es heutzutage viele talentierte Entwickler für die Erstellung von Anwendungen auf Telefonen gibt, sind Entwickler, die Erfahrung mit BSP (Board-Support Packages) unter Verwendung von eingebettetem Android haben, in der Community etwas seltener.
Überlegungen zur GPL bei eingebettetem GNU/Linux
Eingebettetes Linux erfreut sich nach wie vor einer großen Vielfalt an Hardware-Unterstützung und einer großen Entwicklergemeinschaft, die auf allen Ebenen des Software-Stacks arbeitet. Für diejenigen, die nicht gegen Systeme mit GPL-Software sind, kann es eine ausgezeichnete, zuverlässige Plattform sein. Zumindest unserer Erfahrung nach hat die überwältigende Mehrheit der Entwickler von Anwendungssoftware keine rechtlichen Probleme mit ihren Kunden, Wettbewerbern oder der Öffentlichkeit.
Anwendungsentwickler auf Embedded Linux sollten dennoch ein paar grundlegende Konzepte und Faustregeln im Auge behalten. Wir werden die folgenden behandeln:
- Grundlagen der GPL
- Anwendung vs. Treiber
- Open-Source-Bibliotheken
- Statische vs. dynamische Verknüpfung
- Kommunikation zwischen Prozessen
- Standard-C-Bibliothek
- Python und andere Programmiersprachen
Grundlagen der GPL
GPL-lizenzierte Software ist Open Source: Der Quellcode muss mit jedem geteilt werden, an den die Software weitergegeben wird. Aber das grundlegende und am meisten unterscheidende Konzept der GPL (sowohl GPLv2 als auch GPLv3) ist die Selbstweitergabe: Die GPL-Lizenz gilt für alle abgeleiteten Werke, d.h. andere Software wie Anwendungen, die die GPL-Software einbeziehen, z.B. durch Verlinkung mit GPL-Bibliotheken. Um es auf den Punkt zu bringen: Wenn Ihre Anwendung mit GPL-Software verlinkt oder sie auf andere Weise einbezieht, dann sind Sie möglicherweise verpflichtet, Ihre Quellen zu teilen.
Anwendung vs. Treiber
Auf einem Linux-System sind Treiber im Allgemeinen Komponenten, die mit dem Linux-Kernel kompiliert werden, und sie unterliegen zwangsläufig der GPL. Wenn Sie einen Treiber für Linux schreiben, müssen Sie möglicherweise Ihre Quellen freigeben, so wie es alle großen Silizium-Anbieter tun (NXP, TI, Intel, etc.). Es gibt einige Anbieter, die Kernel-Module in binärer Form vertreiben (hauptsächlich für kryptographische Geräte und andere sehr sensible Hardware), aber der rechtliche Status dieser unfreien Treiber ist nicht geklärt.
In jedem Fall hat die Mehrheit der Peripheriegeräte keine ernsthaften IP-Probleme auf der Ebene der Busschnittstelle, auf der die Treibersoftware arbeitet. Wenn Hardware-Geräte wertvolles IP enthalten, wird es häufig in der Firmware innerhalb des Geräts verwaltet und ist für Treiber nicht über eine Busschnittstelle zugänglich. Eine Anwendung hingegen arbeitet auf der Userspace-Ebene: Sie kann mit dem Linux-Kernel kommunizieren (über Systemaufrufe durch Bibliotheken), aber es ist weithin akzeptiert, dass Anwendungen keine Lizenzabhängigkeit mit dem Linux-Kernel haben.
Open-Source-Bibliotheken
C/C++-Anwendungen müssen in der Regel mit öffentlich verfügbaren Bibliotheken verknüpft werden, um auf Systemfunktionen zuzugreifen und zu vermeiden, dass das Rad neu erfunden wird. (Ein C-Programm, das Bluetooth verwendet, muss z. B. libbluetooth linken, das Teil des BlueZ-Stacks ist und unter der GPL lizenziert ist). Da viele Systembibliotheken unter GNU/Linux unter der GPL lizenziert sind, kann die Anwendung GPL-Verpflichtungen eingehen, indem sie mit ihnen gelinkt wird.
Statische vs. dynamische Verknüpfung
Es ist ein weit verbreiteter Glaube, dass dynamisches Linken (statt statisch) die Anwendung vor der Vererbung der GPL schützt, aber tatsächlich ist dies eine Kontroverse, die vor Gericht nicht vollständig geklärt wurde. Die FSF (Free Software Foundation, verbunden mit GNU) behauptet, dass die GPL sich auf dynamisch gelinkten Code erstreckt: https://www.gnu.org/licenses/gpl-faq.en.html#GPLStaticVsDynamic.
Kommunikation zwischen Prozessen
Andererseits müssen C/C++-Anwendungen nicht mit jeder Systembibliothek verknüpft werden. Viele Anwendungen kommen auch ohne libbluetooth oder andere GPL-lizensierte Bibliotheken zurecht. Es besteht keine GPL-Verpflichtung für die Anwendung, wenn sie keine GPL-lizenzierte Software einbindet, selbst wenn sie in einer GNU-Umgebung läuft. Wenn eine Anwendung Interprozesskommunikation mit GPL-Komponenten durchführt (z. B. DBus zur Kommunikation mit systemd oder anderen Daemon-Prozessen verwendet), wird allgemein akzeptiert, dass dies keine GPL-Verpflichtung für die Anwendung bedeutet.
Standard-C-Bibliothek
Die einzige Bibliothek, mit der praktisch jede C-Anwendung verknüpft werden muss, ist die Standard-C-Bibliothek: Die häufigste Implementierung unter Linux ist die GNU glibc. Obwohl es alternative C-Bibliotheken für eingebettete Linux-Systeme gibt, die freizügige Lizenzen haben (wie uclibc oder musl), gibt es keinen wirklichen Grund für Entwickler proprietärer Anwendungen, die GNU C-Bibliothek wegen der Lizenz zu meiden: weil sie nicht unter der GPL steht.
Die GNU C Bibliothek ist eigentlich unter der LGPL lizenziert: der wichtigste praktische Unterschied zwischen den beiden ist, dass die LGPL ("Limited GPL") ausdrücklich dynamisches Linken erlaubt: wenn Ihre Anwendung glibc dynamisch (nicht statisch) verlinkt, sind Sie nicht verpflichtet, Ihre Quellen zu teilen.
Python und andere Programmiersprachen
Was ist mit anderen Sprachen? Wenn Ihr Code nicht in C geschrieben ist, können Sie die GPL umgehen, weil Sie nicht auf GPL-Bibliotheken verlinken? Zum Beispiel hat der Python-Interpreter seine eigene permissive Open-Source-Lizenz. Sie schreibt nicht vor, dass man die Quellen freigeben muss. Aber die Python-Lizenz ist auch mit der GPL kompatibel. Wenn Sie ein Python-Skript schreiben und weitergeben und nur Python-Bibliotheken importieren, die nicht unter der GPL stehen, können Sie die Verpflichtungen der GPL umgehen. Auf der anderen Seite sind einige Python-Bibliotheken unter der GPL lizenziert. (Zum Beispiel, wenn sie von zugrundeliegenden GNU C-Bibliotheken abhängen, so dass sich die GPL auf die Python-Bibliothek überträgt.) Wie sich herausstellt, ist der Fall für eine Python-Anwendung dem von C/C++ sehr ähnlich.
Zum Mitnehmen
Proprietäre Closed-Source-Anwendungen können auf einem GNU/Linux-System mit GPL-Softwarekomponenten koexistieren. Da der rechtliche Status der dynamischen Verknüpfung unter der GPL nach wie vor umstritten ist, besteht ein sicherer Weg, um zu vermeiden, dass Sie versehentlich GPL-Verpflichtungen eingehen, darin, sicherzustellen, dass Ihre Anwendung weder mit GPL-Software verknüpft ist noch diese direkt "einbindet". Dies kann bedeuten, dass man nach Alternativen für bestimmte C- oder Python-Bibliotheken sucht. Die GNU-Standard-C-Bibliothek selbst gehört jedoch nicht dazu, da sie nur eine LGPL-Lizenz besitzt. Es gibt viele andere GPL-lizenzierte Komponenten, die auf einem Linux-System laufen, aber es ist allgemein anerkannt, dass diese ihre Lizenz nicht an eine Anwendung weitergeben, deren Code nicht von ihnen abgeleitet ist.
Unser Team kann Sie bei der Entwicklung beraten und Ihnen einen kompletten Service für Hardwaredesign und Anwendungsentwicklung sowie Zertifizierungsunterstützung anbieten. Nehmen Sie mit uns Kontakt auf, um das Gespräch zu beginnen.