ТОП просматриваемых книг сайта:
Praxishandbuch Open Source. Christian Galetzka
Читать онлайн.Название Praxishandbuch Open Source
Год выпуска 0
isbn 9783800593842
Автор произведения Christian Galetzka
Серия Kommunikation & Recht
Издательство Bookwire
74
Bei Public Domain Software handelt es sich um ein Phänomen, das auf die Besonderheiten des amerikanischen Rechts zurückzuführen ist. Danach ist es möglich, gänzlich auf sein Urheberrecht zu verzichten und ein Werk gemeinfrei zu stellen.55 Dies gilt prinzipiell für den gesamten angloamerikanischen Rechtsraum, in dem wegen der grundsätzlichen Übertragbarkeit des Urheberrechts z.B. auch eine juristische Person das Urheberrecht sowohl originär erwerben als auch das Recht von einer natürlichen Person übertragen bekommen kann.56
75
Ein solcher Verzicht auf das Urheberrecht ist unter Geltung der deutschen Urheberrechtsordnung sowie in vielen anderen europäischen Staaten jedoch nicht möglich (siehe z.B. § 29 Abs. 1 UrhG). Das Urheberrecht ist zum einen unveräußerlich; das Werk kann also nicht etwa in die Gemeinfreiheit entlassen werden. Zum anderen belässt das Schöpferprinzip dem Urheber zumindest den Kern der Urheberpersönlichkeitsrechte, die wegen ihres höchstpersönlichen Charakters ebenfalls unveräußerlich und unverzichtbar sind.57 Eine echte Gemeinfreiheit tritt hier daher nicht ein, so dass die Public Domain Software nach anderen Maßstäben zu beurteilen ist.
76
Die Public Domain wird hier daher als die Einräumung einer Lizenz an jedermann gewertet, die eine unbeschränkte Verwertung der Software gestattet.58 Da Public Domain Software regelmäßig im Source Code veröffentlicht wird und dem Nutzer, durch die Gemeinfreiheit bzw. die Lizenz zur unbeschränkten Verwertung, die typischen Freiheiten der FOSS gewährt, kann Public Domain auch mit unter den FOSS Begriff gefasst werden. Zumindest die in diesem Buch dargestellten Rahmenbedingungen sind auch auf Public Domain Software anwendbar.
50 Stallman, https://www.gnu.org/philosophy/open-source-misses-the-point.de.html. 51 Stallman, https://www.gnu.org/philosophy/free-sw.html.en. 52 OSI, The Open Source Definition, https://opensource.org/osd. 53 Stallman, https://www.gnu.org/philosophy/open-source-misses-the-point.de.html. 54 Stallman, https://www.gnu.org/philosophy/free-sw.html.en. 55 Zum rechtlichen Rahmen von Public Domain und den Besonderheiten auch ausländischer Rechtsordnungen Jaeger/Metzger, Open Source Software, Rn. 8 m.w.N. 56 Statt vieler Hoeren, in: Hoeren/Sieber/Holznagel, Hdb. MultimediaR, Teil 7.8 Rn. 25. 57 Statt vieler Bullinger, in: Wandtke/Bullinger, UrhG, Vor §§ 12 Rn. 5 m.w.N. 58 Jaeger/Metzger, Open Source Software, Rn. 8; Spindler, in: Spindler, Rechtsfragen bei open source, Kap. B. Rn. 13; Spindler, in: Schricker/Loewenheim, Vor §§ 69a ff. Rn. 19f. m.w.N.
Kapitel II Technische Grundlagen: Coding und Kompilierung
77
Bei der Bewertung des Einsatzes von FOSS genügt es häufig nicht, einfach nur festzustellen, dass FOSS eingesetzt wird und welche Lizenzen für die jeweils eingesetzten FOSS Komponenten zu beachten sind. Um ermitteln zu können, ob ein lizenzkonformer Einsatz der FOSS im konkreten Projekt möglich ist, muss oft auch die technische Ausgestaltung des Einsatzes der jeweiligen FOSS Komponenten ermittelt und berücksichtigt werden. Denn unterschiedliche technische Ausgestaltungen können – je nach Lizenz – zu einer anderen rechtlichen Bewertung führen. Während einige Lizenzen nur danach unterscheiden, ob die Software im Source Code oder lediglich als ausführbare Datei im Binärcode an den Nutzer weitergegeben wird, enthalten andere Lizenzen auch unterschiedliche Verpflichtungen, je nachdem in welcher Form die FOSS Komponenten mit eigenem, proprietärem Code interagiert.
78
Um die unterschiedlichen Anforderungen der FOSS Lizenzen, die sich konkret auf verschiedene technische Ausgestaltungen hinsichtlich der Nutzung der FOSS Komponenten beziehen, richtig einordnen und die Risiken des FOSS Einsatzes sachlich bewerten zu können, ist es hilfreich, sich einige technischen Grundlagen in Bezug auf Software-Erstellung und -Architektur anzueignen. In diesem Kapitel wollen wir daher einen kurzen Überblick über diejenigen technischen Grundlagen geben, auf die in FOSS Lizenzen regelmäßig Bezug genommen wird. Dies soll Ihnen einerseits dabei helfen, die Anforderungen der FOSS Lizenzen besser zu verstehen, und andererseits, bei auftretenden Problemen nicht nur juristische, sondern auch technische Lösungsansätze für Ihre eigenen Projekte zu finden.
1. Welche Arten von Code gibt es?
79
– FOSS Lizenzen enthalten teilweise unterschiedliche Anforderungen, je nachdem in welcher Form die Software an den Nutzer weitergegeben wird.
– Zumindest muss zwischen menschenlesbarem Code (Source Code) und maschinenlesbarem Code (Object Code, Binaries, Executables) unterschieden werden.
– Durch den Kompiliervorgang wird der Source Code zu Object Code/Binärcode/Executables umgewandelt.
80
Verschiedene FOSS Lizenzen machen unterschiedliche Vorgabe zur Nutzung der Software bzw. knüpfen andere Verpflichtungen an den Einsatz der Software, je nachdem, in welcher Form die Software an den Nutzer weitergegeben wird. Daher ist es wichtig, die unterschiedlichen Formen zu kennen, in denen der Code einer Software vorliegen kann und wie diese unterschiedlichen Formen von Code jeweils erzeugt werden können.
a) Source Code bzw. Quellcode
81
Source Code – häufig auch Quellcode oder Quelltext genannt – ist der für den Menschen lesbare, in einer der diversen Programmiersprachen verfasste Text eines Computerprogramms. Er beschreibt sowohl die jeweiligen Funktionen der Software als auch deren Aussehen bzw. die Darstellung des Programms bei der Ausführung. Bevor ein im Source Code vorliegendes Programm von einem Computer ausgeführt werden kann, muss der Source Code zunächst in eine für den Computer verständliche Form übersetzt werden. Dies geschieht z.B. mittels eines Compilers oder Interpreters, der entweder vorab den kompletten Source Code in Maschinensprache übersetzt oder dies erst zur Laufzeit des Programms tut.1 Im Source Code liegen neben den reinen Informationen, die für die Ausführung des Programms notwendig sind, in der Regel auch noch andere nützliche Informationen vor, wie beispielsweise Dokumentationen und Hinweise zur Anpassung des Code oder zur Fehlerbehebung. Die für die FOSS Bewertung relevantesten Informationen sind aber die häufig in den Headern der Dateien enthaltenen Angaben zur Lizenzierung der Software. Oft werden hier der jeweilige Text der FOSS Lizenz oder zumindest ein Verweis auf die Lizenz und auf den Ort, wo der Lizenztext zu finden ist, sowie Hinweise zum jeweiligen Rechtsinhaber der Software angegeben.
b) Object Code
82
Die nächste Stufe zwischen dem Source Code und der Maschinensprache ist der sog. Object Code oder auch Objektcode. Der Object Code ist ein Zwischenergebnis, das bei der Übersetzung des menschenlesbaren Code mittels eines Compilers entsteht. Er besteht bereits hauptsächlich aus Maschinencode und enthält neben dem bereits vorübersetzten Code des Programms andere verwendete Programmbibliotheken, die ebenfalls in das Programm eingefügt und mit diesem zum fertigen Programm verlinkt werden sollen. Das Format des Object Code hängt sowohl von der Programmiersprache, dem verwendeten Compiler als auch der Maschine ab, auf der das Programm ablaufen soll.2 Wichtig für die FOSS Beurteilung ist, dass der Object Code in der Regel keine verwertbaren bzw.