Cornelius Schumacher, Schlomo Schapiro, 28.10.2019
Mit "Inner Source" wird das Vorgehen beschrieben, Open-Source-Prinzipien auf die Software-Entwicklung innerhalb eines Unternehmens anzuwenden, ohne den Programmcode außerhalb des Unternehmens zu veröffentlichen. Damit kann von den Vorteilen von Open-Source-Entwicklungsmodellen profitiert werden, ohne die Entwicklung öffentlich zu machen, und ohne das Geschäftsmodell des Verkaufs von Software-Lizenzen aufzugeben.
Inner Source kann so zu einer verbesserten Zusammenarbeit, zu Erhöhung von Entwicklungsgeschwindigkeit und Qualität führen, sowie dazu beitragen, Kosten zu senken. Dies gelingt insbesondere in Situationen, wo verschiedene Unternehmensteile Software-Komponenten mit ähnlichen Anforderungen benötigen, zum Beispiel bei internen Standardbibliotheken, Infrastruktur-Komponenten oder Entwicklungs-, Test- und Deployment-Werkzeugen.
Innerhalb einer einzigen Firma ist Inner Source vor allem eine neue Art der Zusammenarbeit und erfordert keine besonderen Verträge oder Softwarelizenzen, da alle Urheber und Nutzer einer Software derselben Firma angehören. Im Konzernkontext ergeben sich aus der Zusammenarbeit zwischen den unterschiedlichen eigenständigen Konzerntöchtern weitere Herausforderungen. Die Weitergabe von Quellcode oder Binärpaketen zwischen den unterschiedlichen Unternehmen -- selbst in demselben Konzern -- benötigt eine vertragliche Regelung und muss sich in der Bilanzierung der Firmen wiederfinden.
Die DB Inner Source Lizenz löst die vertraglichen Fragestellungen und schafft einen rechtssicheren Rahmen für die Kollaboration zwischen den Konzerntöchtern. Damit leistet die DBISL einen konkreten Beitrag zur ganzheitlichen Optimierung für den DB Konzern.
Die finanziellen Aspekte sind nicht Teil der Betrachtung für die DBISL. Die Lizenz ermöglicht sowohl die kostenfreie Weitergabe als Schenkung als auch den Abschluss von zusätzlichen Verträgen, in denen z.B. eine Weiterentwicklung oder Support rund um die unter der DBISL lizenzierte Software vereinbart werden.
Da klassische Open Source Lizenzen nur von einer Schenkung der Software ausgehen und das Ziel haben, die maximale öffentliche Verbreitung der Software in der Welt zu ermöglichen und zu fördern, sind diese für die Kollaboration nach Open-Source-Prinzipien innerhalb eines Konzerns nicht anwendbar. Die DBISL als neue Lizenz schafft die Brücke zwischen diesen Welten und stellt einen rechtlichen Rahmen für die Open-Source-Zusammenarbeit innerhalb der DB Konzerns zur Verfügung.
Die DB Inner Source Lizenz (DBISL) ist eine Softwarelizenz, unter der Software innerhalb des DB Konzerns frei verwendet und entwickelt werden kann und der Quellcode allen Software-Entwicklern innerhalb des DB Konzerns zu Verfügung steht. Sie ermöglicht damit kollaborative Entwicklungs- und Geschäftsmodelle ähnlich zu bekannten Open-Source-Modellen innerhalb des Konzerns ohne das Risiko, dass diese an die Öffentlichkeit außerhalb der DB gelangen.
Die DBISL ist an eine Lizenz des sogenannten "Copyleft"-Typus angelehnt, der nicht nur sicherstellt, das Quellcode zu Verfügung steht und frei verwendet werden kann, sondern dass Änderungen und Weiterentwicklungen unter denselben Bedingungen zugänglich gemacht werden müssen, so dass der größtmögliche Nutzen aus dem gemeinsam genutzten und entwickelten Code gezogen werden kann.
Die Lizenz steht als Option für interne Software-Entwicklung zu Verfügung und kann auch im Zusammenhang von Aufträgen und Verträgen zwischen verschiedenen Teilen des Konzerns genutzt werden.
Neben den rechtlichen Rahmenbedingungen für das Teilen von Code innerhalb eines Open-Source-ähnlichen Entwicklungsmodells bietet die DBISL auch die Grundlage, um Elemente der Open-Source-Kultur zu adaptieren, wo sie helfen können, die Kommunikation und Zusammenarbeit zu verbessern und Prozesse effizienter, transparenter und selbst-organisierter zu gestalten.
Die DBISL bildet Rechte und Pflichten, die aus Open-Source-Lizenzen bekannt sind, auf das Szenario der konzerninternen Entwicklung ab.
Es ist wichtig zu beachten, dass die Rechte und Freiheiten, die sich daraus ergeben, immer auf Verwendung und Weitergabe innerhalb des Konzerns beschränkt sind. Jegliche Weitergabe an Parteien außerhalb des Konzerns bedarf einer expliziten Umlizenzierung, die von den entsprechenden Rechteinhabern vorgenommen werden muss.
Software, die unter der DBISL lizensiert ist, erfüllt innerhalb des Konzerns die vier Freiheiten von Open-Source-Software:
-
Die Software kann ohne Einschränkungen innerhalb des Konzerns genutzt werden
-
Der Quellcode der Software steht allen Nutzern zu Verfügung
-
Nutzer können die Software selbständig verändern, um Anpassungen und Verbesserungen vorzunehmen
-
Veränderte Versionen der Software können an andere weitergegeben werden
Die Ausübung der Freiheiten erfolgt ausschließlich auf Basis der Lizenz. Es sind keine Lizenzzahlungen oder andere zusätzliche Vereinbarungen notwendig.
Bestehen Anforderungen, die über die von der Lizenz erteilten Rechte hinausgehen, zum Beispiel bezüglich Haftung und Gewährleistung oder zusätzlicher Garantien für Support oder Entwicklung, sind zusätzliche Vereinbarungen notwendig, die diese Anforderungen abdecken. Die DBISL erlaubt es daher, solche Vereinbarungen einzugehen.
Die Hauptverpflichtung der DBISL besteht darin, den Quellcode der unter der DBSIL lizenzierten Software allen Empfängern der Software zu Verfügung zu stellen. Dies schließt den Originalcode ein sowie alle Änderungen, die am Code vorgenommen worden sind.
Diese Verpflichtung kann nicht eingeschränkt werden, und pflanzt sich somit von einem Empfänger der Software zum nächsten fort. Damit wird sichergestellt, dass der Aufwand, der in die Entwicklung der Software geht, einem möglichst breiten Empfängerkreis zu Verfügung steht. Etwaige Weiterentwicklungen kommen so auch allen anderen Nutzern der Software zugute, im Sinne der Optimierung für den DB Konzern.
Die DBISL erlaubt grundsätzlich sogenannte "Forks", das heißt Entwicklungszweige der Software, die unabhängig vom Original-Zweig weitergeführt werden. Allerdings sollte dies nur in gutbegründeten Ausnahmefällen notwendig sein. Es ist in jedem Fall geraten, gemeinsam an einem Zweig zu entwickeln und Änderungen im Hauptzweig vorzunehmen oder zumindest zeitnah wieder zurückfließen lassen. Das vermeidet die Aufwände für Parallel-Entwicklungen, führt zu einer optimalen Wertschöpfung durch Bündelung von Entwicklungskapazitäten, und stellt sicher, dass die Software nachhaltig gepflegt werden kann.
Die Nutzung der DBSIL bietet sich immer dann an, wenn Code einem breiten Publikum innerhalb des DB Konzerns auf möglichst einfach zu nutzende Art und Weise zu Verfügung gestellt werden soll und Zusammenarbeit an diesem Code ermöglicht und gefördert werden soll.
Grundsätzlich kann das Inner-Source-Modell für eine Vielzahl an Anwendungsfällen genutzt werden. Es bietet sich insbesondere für folgende Fälle an:
Infrastruktur und Werkzeuge, die für viele Projekte ähnlich sind, und üblicherweise nicht den fachlichen Kern der Anwendung darstellen
Referenz-Implementationen, die möglichst einfach einem möglichst gr0ßen Publikum zu Verfügung stehen sollen
Kunden-Aufträge, in denen durch den Kunden eine möglichst breite Nutzbarkeit der Software erwartet wird
Implementierungen von Standards, die helfen, allgemeingültige Standards zu etablieren
Nicht geeignet ist die DBISL für Code, der unter dem Geschäftsmodell des Verkaufs von Software-Nutzungslizenzen entwickelt wird, und für Software, die an Empfänger außerhalb des DB Konzerns weitergegeben werden soll. Hier bieten sich, je nach Anwendungsfall, traditionelle proprietäre oder Open-Source-Lizenzen an.
Die Anwendung der Lizenz erfolgt in ähnlicher Weise wie von der Apache-Lizenz bekannt.
Ein wichtiger Grundsatz ist, dass bestehende Lizenz- und Copyright-Hinweise nicht entfernt werden dürfen, sondern bei Weitergabe und Veränderung der Software vollständig erhalten werden müssen. So wird sichergestellt, dass Klarheit über Lizenz und Rechteinhaber von allen Teilen der Software herrscht.
Der Lizenz-Text wird in einer Datei mit dem Namen "LICENSE" (ggf. mit einer Dateiendung wie .TXT oder .MD) im Wurzelverzeichnis des Code-Repositories gespeichert. Diese Datei muss bei Weitergabe der Software immer mit eingeschlossen sein, das gilt sowohl für die Weitergabe als Quellcode, als auch als Weitergabe in Binärform.
Wenn die Software in Binärform weitergegeben wird, muss ein wirkungsvoller Hinweis enthalten sein, wie der Empfänger den Quell-Code erhalten kann, aus dem die Binärform erzeugt wurde.
Idealerweise wird aller Code, der unter der DBISL entwickelt wird, in einem Versions-Kontroll-System verwaltet, das für alle gleichermaßen zugänglich ist, um Nutzung des Codes und Zusammenarbeit daran möglichst effektiv zu gestalten.
In jeder Datei des Quell-Codes muss am Anfang ein Hinweis auf die Lizenz und den Inhaber der Verwertungsrechte enthalten sein.
Beispiel:
// Copyright 2019 DB Systel GmbH
// Licensed under the DBISL, see the accompanying file LICENSE.
Wenn Änderungen an einer Datei durchgeführt durch einen Rechteinhaber durchgeführt werden, der noch nicht im Copyright-Hinweis genannt ist, fügt dieser neue Rechteinhaber eine zusätzliche Copyright-Zeile ein.
Die in den Copyright-Hinweisen genannten Jahre sollten den Jahren entsprechen, in denen durch den entsprechenden Rechteinhaber Änderungen vorgenommen wurden. Das kann auch eine Liste oder ein Bereich von Jahren sein, zum Beispiel "2017, 2019" oder "2018-2019".
Inner Source
-
How Inner Source is like FLOSSing - Kurzes Vortragsvideo das erklärt, was Inner Source ist und warum es gut ist
-
InnerSource Commons - Community-Ressourcen aus der Praxis zum Thema Inner Source
-
Adopting Inner Source, Principles and Case Studies - Buch mit Fallstudien von erfolgreicher Anwendung von Inner Source in Unternehmen wie Bosch, Ericsson oder Paypal
Open Source Lizenzen
Zum Vergleich hier die Links zu einigen anderen Lizenzen:
-
EUPL - Open-Source-Lizenz der EU, angepasst an die Europäische Rechtslage, Vorlage für einen Teil der DBISL
-
Kommentar EUPL - Kommentierte Version der EUPL
-
LGPL - Open-Source-Lizenz mit "schwachem Copyleft"
-
Apache Lizenz - Einer der verbreitetsten "permissive" Lizenzen