Doch was bedeutet es für das Produkt-Entwickler-Team (und letztlich für das vertreibende Unternehmen), wenn man embedded Linux und weitere Open Source Komponenten in einem kommerziellen Produkt einsetzt? In unserem konkreten Umfeld gibt es zusätzlich zu embedded Linux meist auch noch die Bibliothek Qt, welche als Teil des embedded Linux Systems mit ausgeliefert wird. Was gibt es bei der Verwendung von Qt in der Open Source Variante zu beachten?
Was ist freie Software?
Der Begriff „freie Software“ wurde maßgeblich Mitte der 1980er Jahre von der Free Software Foundation (FSF, https://www.fsf.org/) geprägt. Sie wird über folgende 4 Freiheiten definiert:
- (0) Die Freiheit, das Programm auszuführen wie man möchte, für jeden Zweck (Freiheit 0).
- (1) Die Freiheit, die Funktionsweise des Programms zu untersuchen und eigenen Datenverarbeitungbedürfnissen anzupassen (Freiheit 1). Der Zugang zum Quellcode ist dafür Voraussetzung.
- (2) Die Freiheit, das Programm zu redistribuieren und damit Mitmenschen zu helfen (Freiheit 2).
- (3) Die Freiheit, das Programm zu verbessern und diese Verbesserungen der Öffentlichkeit freizugeben, damit die gesamte Gesellschaft davon profitiert (Freiheit 3). Der Zugang zum Quellcode ist dafür Voraussetzung.
Quelle: https://www.gnu.org/philosophy/free-sw.de.html
Basierend auf dieser grundsätzlichen Definition von freier Software gibt es dazu zahlreiche Lizenzen, welche diese Freiheiten erfüllen (siehe https://www.gnu.org/licenses/license-list.html) Die wichtigsten dieser Lizenzen daraus sind:
- GPL – General Public License
- LGPL – Lesser GPL
Vertreter der GPL Lizenz sind unter anderem der Linux Kernel, Notepad++, Git, MariaDB, usw… Vertreter der LGPL Lizenz sind unter anderem GTK, Qt, 7-Zip und viele weitere Software Bibliotheken, welche oft als Teile von Anwendungen mit ausgeliefert werden.
Die GPL Lizenz
Die GPL stellt sicher, dass Software, welche einmal unter der freien GPL entwickelt wurde, auch in Zukunft immer frei unter der GPL nutzbar bleibt (auch wenn jemand diese Software unter großem Aufwand weiter entwickelt,…). Sie gilt dabei immer für das gesamte „Corresponding Source“ (siehe Punkt 1 GPL Lizenz). Dies heißt vereinfacht: Sobald man eine GPL-Library im eigenen Source Code verwendet (sprich: compile, link), muss der gesamte Source Code unter der GPL veröffentlicht werden. Fazit: Für Libraries eignet sich darum die GPL eher nicht, da sie bei der Verwendung die gesamte eigene Software (welche meist proprietär bleiben soll) mit zur „Corresponding Source“ hinzuzählt und somit alles unter der GPL lizenziert werden muss, ergo frei zugänglich sein muss. Die Referenz zur GPL: https://www.gnu.org/licenses/gpl-3.0.html.en
Die LGPL Lizenz
Die LGPL ist eine Erweiterung der GPL. Es werden zusätzliche Begriffe definiert: Erst die LGPL unterscheidet nach „Application“ und „Library“ und definiert die Zusammensetzung davon als „Combined Work“. Somit stellt die LGPL sicher, dass freie Library-Software weiterhin frei bleibt, jedoch die Anwendungen, die LGPL-Libraries nutzen, unter „eigener Lizenz“ verbreitet werden können. Die Referenz zur LGPL: https://www.gnu.org/licenses/lgpl-3.0.html.en
Was heißt das nun in der Praxis?
Nutzt man GPL-Software und kompiliert oder linkt gegen diese, so gehört der gesamte Source Code (auch der selbst geschriebene) zur „Corresponding Source“ und muss gemäß der GPL wieder frei zugänglich sein.
Nutzt man in seinem Linux-Software-Projekt hingegen ausschließlich LGPL basierte Libraries, so kann der eigene Source Code „closed source“ (also proprietär) bleiben. Nur die LGPL basierten Software-Teile müssen weiterhin unter der LGPL Lizenz vertrieben werden. Jedoch muss der Umstand der Verwendung dieser LGPL Bibliotheken klar kommuniziert werden: Falls eine graphische Benutzeroberfläche vorhanden ist, muss in einem leicht zugänglichen Menüeintrag eine Auflistung aller verwendeten Bibliotheken samt Lizenz einsehbar sein (siehe Screenshots weiter unten: „about page“ und „all licenses page“)
Nutzt man Software-Bibliotheken mit kommerzieller Lizenz unter Linux, so gelten natürlich die spezifischen kommerziellen Lizenzen. Diese erlauben meist (ähnlich wie die LGPL) eine proprietäre Lizenz der eigenen Software.
Natürlich gibt es bei dieser Betrachtungsweise noch viele zusätzliche Details, die in diesem Artikel nicht abgedeckt werden und eventuell für ein konkretes Projekt große Bedeutung haben können: DRM, Tivoisation, Software-Patente, statisches Linken, user product vs. non-user product, LGPLv2 vs. LGPLv3, notwendige „installation information“, closed devices, …
Wie gliedern sich hier die Qt Lizenzen ein?
Qt bietet ein duales Lizenz-Modell: Es gibt die Möglichkeit Qt entweder unter Open-Source-Lizenzen zu nutzen, oder Qt unter einer kommerziellen Qt Lizenz zu verwenden. Alle Details hierzu finden sich hier: qt.io/licensing/. Entscheidet man sich für die Nutzung der Open-Source-Lizenzen, so sollte man folgendes im Blick haben:
- Gegen welche Qt Module kompiliere/linke ich meine Anwendung?
Die allermeisten Qt Framework Module sind mit der LGPL verfügbar, es gibt jedoch einige Module, die nur unter der GPL verfügbar sind (z.B. QtVirtualKeyboard, QtCharts,…). Möchte man seinen eigenen Qt-Code proprietär halten, so ist es notwendig, nur LGPL Module zu verwenden (siehe Grafik oben). Übrigens: Die reine Nutzung von GPL basierten Open-Source-Werkzeugen (wie z.B. QtCreator) ist natürlich auch dann weiterhin erlaubt, wenn man Qt nur mit LGPL basierten Modulen verwenden und somit seinen eigenen Code weiterhin proprietär halten will. Schlagwort „Corresponding Source“: Werkzeuge wie QtCreator gehören nicht zur „Corresponding Source“ im Sinne der GPL, weil QtCreator nicht als Teil der Produkt-Lösung im Verbund mit eigenem Code mit ausgeliefert wird.
Egal welche Bibliotheken man für die Umsetzung seiner Anwendung nutzt, ob man nun Qt mit kommerzieller oder Open Source Lizenz nutzt, es bleibt der Punkt, dass das Linux System und der Linux Kernel (GPL) auch aus Open Source Software bestehen und aus Sicht der Lizenzen korrekt behandelt werden müssen. Eine Grundvoraussetzung dies machen zu können ist, dass die „Software Bill of Materials“ Liste des Produktes erstellt wird. Für dies gibt es typischerweise in den Linux-Build-Tools (z.B. Buildroot und Yocto) Tool-Unterstützung, sodass im Idealfall diese Liste generiert werden kann. Zusammen mit einem „Written Offer“, der dem Endkunden die Möglichkeit gibt, den Source Code aller verwendeten Module herunterzuladen, ist hier die Basis für eine konforme Verwendung gelegt.
-
- Example for „about page“
-
- Example for „all licenses page“
Urheberrecht & Open Source Lizenzen – Eine Orientierung
Der Urheber ist die natürliche Person, die ein Werk (in unserem Fall meist Source Code) geschaffen hat. Dieses Recht ist nicht übertragbar und entsteht „automatisch“ mit der Schaffung des Werkes. Die Rechte des Urhebers beinhalten unter anderem das Vervielfältungsrecht, Werknutzungsrecht und Verbreitungsrecht. Diese Rechte können auch auf Dritte übertragen werden. Das Urheberrecht (Copyright) regelt dabei die Übertragung dieser Verwertungsrechte zum Schutz des geistigen Eigentums des Urhebers. Open Source Lizenzen detaillieren diesen Bereich, fügen Regeln hinzu, unter welchen Bedingungen ein Werk genutzt/verwertet und modifiziert und weiter verbreitet werden kann.
Fazit
Letztlich profitieren wir alle enorm von der Verwendung von freier Software. Ich kenne aktuell keinen Router, Smart-Fernseher, kein Fahrzeug oder Smartphone das gänzlich ohne freie Software auskommt. Die Verwendung dieser freien Software auch für große Konzerne zu kommerziellen Zwecken ist dabei völlig legitim, wenn sie unter der Einhaltung der Lizenz-Regeln erfolgt. Auch wenn es keinen direkten Geld-Rückfluss zu den Erstellern der freien Software gibt, so gilt es (schon allein aus Dankbarkeit und Respekt) die Lizenzen einzuhalten und darüber hinaus generell den Guten Willen „Good-Will“ bei der Unterstützung der Grundsätze von freier Software zu zeigen. Dazu könnte z.b. auch die Unterstützung von Vereinen oder Communities gehören, die sich um die Fortführung von Open Source Software organisiert haben, z.B. im Falle von Qt die KDE free Qt foundation https://kde.org/community/whatiskde/kdefreeqtfoundation/ oder die Linux foundation https://linuxfoundation.org/. Im deutschsprachigem Raum ist die „Open Source Automation Development Lab eG“, kurz OSADL (https://www.osadl.org/), eine interessante Möglichkeit sich mit anderen Unternehmen welche Open Source in der Industrie einsetzen zu vernetzten. Sequality ist selbst Associate Member von OSADL und profitiert von der Vernetzung mit Experten aus ganz Europa. Ergänzend ist es sicher auch eine gute Idee, den Nachwuchs an den Schulen und Unis/FHs zu fördern um auch die nächste Generation der Open Source Entwickler sicherzustellen.
Haben Sie noch weitere Fragen? Kontaktieren Sie mich unter stefan.larndorfer@sequality.at! Bei Bedarf biete ich Ihnen und Ihrem Team auch einen individualisierten 2-Stündigen Workshop rund um das Thema „Linux, Qt und Open Source“ an, in dem ich dann individuell auf Ihre Situation und Fragen eingehen kann. Link zu sequality Seminare und Trainings: https://www.sequality.at/loesungen/seminare-und-trainings/
Gerne unterstützen wir Sie auch dabei, ihre Software-Bill-of-Materials unter Buildroot oder Yocto zu erstellen und können Ihnen auch fertige QtQuick oder QWidgets Komponenten anbieten (siehe Screenshots oben), die Sie in Ihre Anwendung integrieren können und ihre Software-Bill-of-Materials anzeigen kann.