Читать книгу Praxishandbuch Open Source - Christian Galetzka - Страница 10

11

Software-Entwickler haben gelegentlich Mühe, ihren Inhouse-Juristen zu erklären, dass ein kompletter Verzicht von FOSS genauso wenig denkbar ist wie der Vorschlag, auf sämtliche Copyleft Lizenzen zu verzichten. Wer sich auf ein Linux Ökosystem eingelassen hat, kann den Einsatz von GPL nicht kategorisch ausschließen. Das einfache Modell, Lizenzen in Gut und Böse einzuteilen, hält dem Realitätscheck nicht lange stand. Wohl dem, der bei Entwicklung seiner Lizenzrichtlinien rechtzeitig mit seinen Entwicklern gesprochen hat.

12

Basic: Copyleft (siehe Rn. 225ff.)

Das ist das zentrale Prinzip des FOSS Ideals. Hat die Lizenz ein Copyleft, so muss ein von der FOSS Komponente „abgeleitetes Werk“ ebenfalls unter den Bedingungen der FOSS Lizenz verfügbar gemacht werden. Es gibt Lizenzen mit strengem Copyleft, die dieses Prinzip voll umsetzen, andere mit beschränktem Copyleft, die teils Ausnahmen vorsehen, sowie Lizenzen ohne Copyleft, die nur die Einhaltung anderer Bedingungen vorsehen. In der Regel wollen Unternehmen Copyleft vermeiden, um eigenen bzw. proprietären Code nicht im Source Code unter einer FOSS Lizenz freigeben zu müssen, damit sie die Lizenzvorgaben einhalten.

13

Auf der anderen Seite wird das Argument der technischen Notwendigkeit und Alternativlosigkeit viel zu häufig hingenommen. Wer sich dann im nächsten Schritt auch sagen lässt, dass die Einhaltung der theoretischen Bedingungen praktisch oder wirtschaftlich unmöglich ist, findet sich im Dilemma, zwischen Lizenzverstoß und Lästigkeit entscheiden zu müssen. Man solle doch pragmatisch sein, statt Probleme zu schaffen, wettert der CTO gegenüber der Rechtsabteilung und diese antwortet dann mit einer Strafbarkeitswarnung an den CEO. Diese Eskalation ist am Ende peinlich, wenn sich später herausstellt, dass eine legale Lösung nur aus Unfähigkeit übersehen wurde.

14

Zugegeben, an FOSS kommt man kaum vorbei, sobald ein Stromverbraucher mehr macht, als einen Wolfram-Draht zu erwärmen. Früher konnte man die typischen Einsatzfelder von FOSS noch mit Linux Servern beschreiben, während eingebettete Software häufiger individuell programmierte Software enthielt. Mit dem Internet der Dinge ist kaum noch eine Anwendung zu primitiv, um nicht mit FOSS umgesetzt zu werden. Eine Glühbirne kommt heute mit WLAN-Empfang auf FOSS Basis und synchronisiert das Programm mit Heizung, Kamera und Lautsprecher, ebenso das ferngesteuerte Sexspielzeug. Was kommuniziert, enthält vermutlich auch FOSS.

15

Kommerzielle Betriebssysteme wie iOS oder Windows enthalten bereits selbst FOSS und die dafür geschriebenen Anwendungsprogramme erst recht. Selbst die Steuerung einer Sieben-Segment-Anzeige wird gelegentlich mit FOSS realisiert. Wenn man FOSS freie Systeme sucht, müsste man daher schon auf die analoge Ebene des Operationsverstärkers zurückgehen – der enthält garantiert keine FOSS.

16

Es gibt jedoch auch leistungsfähige Realtime Betriebssysteme, die ohne Copyleft Lizenzen auskommen, dafür aber Lizenzgebühren kosten. Teilweise geben Rechtsinhaber die gleiche Anwendung unter FOSS Lizenz oder unter kommerzieller Lizenz heraus, so dass der Verzicht auf Copyleft Effekt gegen Gebühr gekauft werden kann. Bei vielen Libraries gibt es alternative Komponenten unter liberalen Lizenzen, was manchmal erst spät im Entwicklungsprozess bemerkt wird. Juristen sind daher gut beraten, bei behaupteter Alternativlosigkeit genauer hinzuschauen.

17

Basic: Begriffsklärung Software/Komponente/Produkt/Projekt/Library/File

Im Bereich FOSS werden viele Begriffe unterschiedlich eingesetzt. Wir verwenden als zentrale Bezeichnung FOSS Komponente für das einzelne urheberrechtlich geschützte Werk, das abgrenzbar für die Software-Entwicklung eingesetzt wird. Parallel werden auch die Begriffe FOSS, Produkt oder Projekt verwendet. Gerade die Internetauftritte von FOSS Komponenten werden häufig als Projekthomepages bezeichnet und bei entsprechender Community die Gemeinschaft/Komponente oft als Projekt. Ist die Komponente unselbstständig, wird sie häufig als Library bezeichnet (typisches Format ist eine .dll-Datei).

Eine FOSS Komponente besteht aus einer Vielzahl einzelner Files, die Zeilen von Header Informationen und Code beinhalten. Sie enthält ggf. weitere Komponenten oder Komponentenbestandteile, sogenannte Abhängigkeiten oder Dependencies. Teils sind diese nicht direkt in den Code einbezogen, sondern werden erst beim Kompilierungsvorgang, also der Umwandlung des Source Code in ein Kompilat, hinzugezogen.

Wir setzen den Begriff Produkt nicht für die einzelne Komponente ein, sondern wenn wir das Ergebnis der Zusammenstellung der Komponenten ggf. auch mit proprietärem Code bezeichnen wollen. Also ist damit quasi das Endergebnis der Programmiervorgänge gemeint. Alternativ wird das auch als Projekt bezeichnet. Projekt nutzen wir jedoch als Referenz für den gesamten Entwicklungsvorgang, insbesondere mit Bezug auf die Zeitschienen.