Seite wählen

NETWAYS Blog

Zwei Juristen, drei Meinungen

Es ist schwer zu glauben, dass es für einen Anwendungsentwickler überhaupt von Vorteil ist, auch nur einen Hauch juristischen Sachverstandes zu besitzen; dem ist aber so.
Dies musste ich feststellen, als neulich die Frage im Raum Stand, unter welche Lizenz wir unsere Software zukünftig stellen sollen.
Für meine Stellungnahme dazu gab es eine Menge zu recherchieren; ich halte es für sinnvoll, die Ergebnisse dieser Recherche allgemein zugänglich zu machen:

Allgemeine Lizenzfragen

  1. Soll das Programm freie Software sein oder proprietäre Software?
  2. Im Falle erstgenannter: Soll ein das Programm mit einem Copyleft versehen werden?

Wir als Firma beabsichtigen, die Nutzer unserer Software nicht in ihrer Freiheit einzuschränken; daher kommt nur eine Freie-Software-Lizenz in Frage.
Ein mit einem Copyleft versehenes Programm darf nur unter den gleichen Bedingungen weitergegeben werden; ob das sinnvoll ist, muss von Fall zu Fall entschieden werden.

Häufig verwendete Freie-Software-Lizenzen

Die folgende Liste erhebt keinen Anspruch auf Vollständigkeit. Siehe auch: dem GNU-Projekt seine Liste Freier-Software-Lizenzen

„Public Domain“

Verzicht auf alle möglichen Ansprüche seitens des Urhebers.

MIT License (aka X11 License), BSD 2-Clause License

Copyright-Vermerk muss allen Kopien der Software beiliegen.

BSD 3-Clause License

Wie 2-Clause, zusätzlich darf dem Urheber sein Name nicht zum Bewerben oder Kennzeichnen von von der Software abgeleiteter Werke verwendet werden.

BSD 4-Clause License

Wie 3-Clause, zusätzlich mit der unausstehlichen BSD-Werbeklausel. (Von der Verwendung dieser Lizenz wird ausdrücklich abgeraten!)

PHP-Lizenz

Vergleichbar mit der BSD 4-Clause License.

Apache License, Version 2.0

Vergleichbar mit der BSD 3-Clause License, zusätzlich droht Nutzern – seitens des Urhebers, im Bezug auf die unter dieser Lizenz stehende Software – keine Klage wegen Patentverletzung.

GNU General Public License (GPL)

  1. Copyright-Vermerk muss allen Kopien der Software beiliegen.
  2. Bietet Benutzern folgende vier Freiheiten:
    • die Freiheit, das Programm für jeden Zweck auszuführen,
    • die Freiheit, das Programm eigenen Bedürfnissen anzupassen,
    • die Freiheit, die Software mit Freunden und Mitmenschen auszutauschen und
    • die Freiheit, gemachte Änderungen mit anderen auszutauschen.
  3. Modifizierte oder mit anderen Werken kombinierte Versionen dürfen nur unter den gleichen Bedingungen weitergegeben werden. (Copyleft)
  4. Ein jeder Benutzer muss die Möglichkeit haben, ohne (zusätzliche) Kosten eine Kopie des gesamten Quellcodes zu erhalten.

GNU Lesser General Public License (LGPL)

Wie GPL, zusätzlich darf das Programm („vorzugsweise“ eine Bibliothek) (auch) in Nicht-(L)GPL- (sogar proprietäre) Software eingebunden werden – bspw. durch statisches/dynamisches Linken.
Der Nutzer muss – bspw. nach einer Modifikation der Bibliothek – diese (selbstständig) in das einbindende (evtl. Nicht-(L)GPL-)Programm linken können.

GNU Affero General Public License (AGPL)

Wie GPL, zusätzlich müssen Nutzer, die über ein Netzwerk mit der Software kommunizieren, den Quellcode dieser – ohne (zusätzliche) Kosten – erhalten können.

Kompatibilität Freier-Software-Lizenzen

Die Frage nach der Kompatibilität verschiedener Software-Lizenzen kann (wie so viele Rechtsfragen) nicht pauschal beantwortet werden, sondern nur von Fall zu Fall – siehe:

Kompatibilität LGPL – GPL – AGPL

  1. Es ist erlaubt, Werke unter GPL mit Werken unter AGPL zu linken/kombinieren;
    • die Lizenzen gelten weiterhin für die entsprechenden Teile der Software, aber
    • Sektion 13 der AGPL (Interaktion über ein Netzwerk) gilt für das gesamte Werk.
  2. Die LGPL ist kompatibel mit der GPL.

Kompatibilität GPLv2 – GPLv3

Diese zwei Lizenzen sind nicht kompatibel, außer durch die „or (…) any later version“-Klausel; diese erlaubt es, ein Programm (optional) unter einer beliebigen später erschienenen Version der GPL zu Nutzen.
Diese Klausel muss, sofern gewünscht, explizit angegeben werden, ist aber bereits im Standard-GPL-Lizenz-Header enthalten. Letztgenannter muss ggf. „nur“ übernommen werden.
Es wird ausdrücklich empfohlen, so zu verfahren, da sonst die Gefahr besteht, dass unter einer später erschienenden Version der GPL stehende Software „von morgen“ sich keinen Quellcode wird einverleiben können von Software ohne die Klausel.

GPLv2 vs. GPLv3

Siehe:

Fazit

Es existiert zur Zeit ein für einen Laien nur schwer überschaubarer Dschungel an Software-Lizenzen. Welche Software unter welche Lizenz gestellt werden sollte/kann/darf, muss von Fall zu Fall entschieden/geklärt werden.

Empfehlung

Ich persönlich empfehle, eine der folgenden Software-Lizenzen zu verwenden:

  • GPLv3+ (`+‘ für die „or (…) any later version“-Klausel)
  • LGPLv3+
  • Apache License 2.0
Alexander Klimov
Alexander Klimov
Senior Developer

Alexander hat 2017 seine Ausbildung zum Developer bei NETWAYS erfolgreich abgeschlossen. Als leidenschaftlicher Programmierer und begeisterter Anhänger der Idee freier Software, hat er sich dabei innerhalb kürzester Zeit in die Herzen seiner Kollegen im Development geschlichen. Wäre nicht ausgerechnet Gandhi sein Vorbild, würde er von dort aus daran arbeiten, seinen geheimen Plan, erst die Abteilung und dann die Weltherrschaft an sich zu reißen, zu realisieren - tut er aber nicht. Stattdessen beschreitet er mit der Arbeit an Icinga Web 2 bei uns friedliche Wege.

Papier zum Umgang mit der GPL in Firmen veröffentlicht

Das Software Freedom Law Center (SFLC) hat einen Guide zum Umgang mit der GPL veröffentlicht. Das Papier mit dem Titel „Practical Guide to GPL Compliance“ erläutert die genauen Bediengungen der GPL und gibt Unternehmen praktische Hinweise, wie man sich lizenzkonform verhält und wie man am besten vorgeht, wenn man wegen eines Lizenzverstoßes angegengen wird. Das Software Freedom Law Center, das Open-Source-Projekten rechtlichen Beistand leistet, hat schon Unternehmen wegen Verstößen gegen die GPL verklagt. Insbesondere Netzausrüster sind immer wieder aufgefallen, weil sie Teile des Linux Codes in ihren Produkten verwendet hatten, ohne die Quelltexte zu veröffentlichen oder einen Hinweis auf die GPL zu geben.

Julian Hein
Julian Hein
Executive Chairman

Julian ist Gründer und Eigentümer der NETWAYS Gruppe und kümmert sich um die strategische Ausrichtung des Unternehmens. Neben seinem technischen und betriebswirtschaftlichen Background ist Julian häufig auch kreativer Kopf und Namensgeber, beispielsweise auch für Icinga. Darüber hinaus ist er als CPO (Chief Plugin Officer) auch für die konzernweite Pluginstrategie verantwortlich und stösst regelmässig auf technische Herausforderungen, die sonst noch kein Mensch zuvor gesehen hat.