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.

Gut gemeint vs. gut gemacht

Es war einmal ein PHP-Skript…
Es sollte – nach einer Modifikation durch meine Wenigkeit –, um seine eigentliche Aufgabe bewerkstelligen zu können, (unter anderem) den absoluten Pfad zu einer Datei ermitteln können.
Welche Funktion der PHP Standard-Bibliothek wäre dafür besser geeignet, als realpath?
Leider keine.
 
realpath hat (nämlich) eine Macke (die auch im PHP-Handbuch vermerkt ist):

realpath() gibt FALSE zurück, wenn ein Fehler auftritt, beispielsweise wenn die Datei nicht existiert.

Warum um alles in der Welt prüft realpath (immer), ob der Pfad existiert (und schlägt fehl, wenn dem nicht so ist)?
Dafür gibt es doch die Funktion file_exists.
Außerdem widerspricht dieses Verhalten grundlegend der Unix-Philosophie:

Mache nur eine Sache und mache sie gut.

 
Python beispielsweise verhält sich da besser; seine Standard-Bibliothek ihre Funktion realpath zeigt das oben aufgeführte Fehlverhalten nicht und überlässt es dem Benutzer ob bzw. wann oder wie er prüft, ob der Pfad existiert.
 
readlink aus den GNU coreutils hingegen geht einen Kompromiss zu Gunsten des Benutzers ein; es lässt ihn einstellen, ob bzw. wie genau die Existenz des Pfades geprüft werden soll:

  • -e, --canonicalize-existing: verhält sich wie dem PHP sein realpath
  • -f, --canonicalize: wie -e, außer dass die letzte Komponente nicht existieren muss
  • -m, --canonicalize-missing: verhält sich wie dem Python sein realpath

 
Fazit: Typisch GNU-Betriebssystem – es macht (nur) das, was es machen soll.

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.

Red Hat #nEuland Linux, Python 2.4 und ich

Es war einmal ein Python-Software-Projekt, das ich für Icinga umzusetzen hatte.
Eine Vorgabe, die mir persönlich nicht gefallen hat, war die Python-Version: 2.4.
Ein größeres kleines Dorn im Auge war mir vor allem das Fehlen der (erst in Python 2.5 eingeführten) bedingten Ausdrücke:
print 'komfortabel' if sys.version_info[:2] > (2, 4) else u'umst\xe4ndlich'
Im Ernst: Wer verwendet heute noch den fast 10 Jahre alten Python-2.4-Interpreter?
Ach ja… Red Hat Enterprise Linux.
Die zu entwickelnde Software soll wohl u. a. auf der (bis einschließlich März 2017 unterstützten) Version 5 von RHEL laufen.
Aber warum ist RHEL eigentlich so konservativ?
Ein Grund ist sicher, dass RHEL für Geschäftskunden gedacht ist, von deren Servern ein extrem stabiler Betrieb verlangt wird (z. B.: Wissenschaft, Militär oder Raumfahrt).
Dieser ist des öfteren auch von großer Bedeutung – in den USA beispielsweise bei der NASA, dem Verteidigungsministerium oder der Luftfahrtbehörde.
RHEL 7 soll immerhin Python 2.7 enthalten, während Debian, das als eine der stabilsten Linux-Distributionen gilt, schon länger Python 3 anbietet.
Fedora (wohl eine der innovativsten Linux-Distributionen) will Python 3 sogar als Standart-Interpreter heranziehen.
Aber solch ein Schritt ist für RHEL wahrscheinlich noch #Neuland.

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.