Open-Source-Software

Markus Nüttgens

---

Open Source bedeutet wörtlich aus dem Englischen übersetzt “Freie Quelle”. Gemeint ist damit die freie Verfügbarkeit des Software-Quellcodes, der im Rahmen von Open-Source-Lizenzmodellen unentgeltlich genutzt und verändert werden kann.

Begrifflichkeit

Der Begriff Open-Source-Software entstand 1998 mit der Gründung der Open Source Initiative (OSI) und prägt seitdem das Bild der Softwareentwicklung [Brügge 2004].

Bezeichnungen wie “freie Software” und “offene Software” werden in der Literatur zunehmend synonym zu Open-Source-Software (OSS) verwendet. Sie bringen zum Ausdruck, dass die jeweilige Software von jedem genutzt, kopiert und verteilt werden darf. Dies kann unentgeltlich oder gegen eine Gebühr geschehen, auf jeden Fall muss aber der Quellcode für jeden Interessenten verfügbar sein. Die Gebühr ist dann aber keine Lizenzgebühr für Software, sondern soll die Kosten des Anbieters für die Bereitstellung decken.

Häufig werden vier charakteristische Merkmale in Bezug auf OSS genannt [Brügge 2004]:

• Lizenz der Software

• nicht-kommerzielle Einstellungen

• hoher Grad an Kollaboration bei der Programmentwicklung

• starke räumliche Verteilung der Entwickler

Proprietäre Software steht dem Open-Source-Konzept entgegen. Die Nutzung, (Neu-) Verteilung oder Modifikation von proprietärer Software erfordert in jedem Fall eine Genehmigung des Eigentümers. Die angesprochenen Merkmale von Open-Source-Software werden in der Open-Source-Definition zusammengefasst.

Da die Bezeichnung Open-Source beschreibend ist, kann sie nicht als Warenzeichen oder Schutzmarke eingetragen werden. Lizenzen sind keine Ware, folglich können sie auch nicht beim U.S. Patent and Trademark Office registriert werden. Aufgrund des Bedarfs der freien Software-Gemeinschaft nach einer verlässlichen Bezeichnung für Open-Source-Software hat die Open-Source-Initiative (OSI) ein sogenanntes “certification mark” als Prüfsiegel registrieren lassen. Wenn das Prüfsiegel “OSI certified” auf einer Software erscheint, steht sie unter einer Lizenz, die mit der Open-Source-Definition konform ist. Die Zertifizierung erfolgt in zwei Schritten:

1. Die Open-Source-Initiative veröffentlicht eine Liste von Lizenzen, die der Open-Source-Definition genügen. Eine Lizenz, die noch nicht in der Liste steht und der Open-Source-Definition genügen soll, kann zur Prüfung an <license-approval@opensource.org> gesandt werden.

2. Um das “OSI certified” mark auf einer Software-Distribution zu verwenden, muss die Software unter einer von der OSI veröffentlichten Open Source-konformen Lizenz stehen.

Das Prüfsiegel kann ausschließlich auf Software angewandt werden, nicht auf Lizenzen. Dies soll sicherstellen, dass ein Softwarepaket mit den enthaltenen Lizenzen eine Open-Source-Distribution ist.

Philosophie

Dem Open-Source-Ansatz liegen spezifische Modelle hinsichtlich Entwicklung und Distribution zugrunde (siehe hierzu auch Open-Source-Prozess). Die Vorgehensweise bei der Entwicklung freier Software war bis 1997 nicht dokumentiert und ausschließlich an bekannten freien Software-Projekten wie z. B. Linux ersichtlich. Raymond hat im Mai 1997 erstmalig versucht, Faktoren einer erfolgreichen Vorgehensweise zu dokumentieren. Nach seinem Essay „The Cathedral and the Bazaar“ wird das Software-Entwicklungsmodell auch Basarmethode genannt. Raymond hat bei seiner Analyse des Software-Entwicklungsmodells von Linux folgende Grundregel aufgestellt [Raymond 2000]:

„Veröffentliche früh und häufig, delegiere alles, was sich delegieren lässt, und sei offen bis zum Punkt des heillosen Durcheinanders, genannt Chaos.“

Weiterhin hat er unter anderem folgende Charakteristika der Open-Source-Philosophie benannt [Raymond 2000]:

• Jedes gute Programm hat seinen Ursprung in einer für den Entwickler störenden Unzulänglichkeit.

• Gute Programmierer wissen, was geschrieben werden muss. Große Programmierer wissen, was neu geschrieben werden muss und was wiederverwendet werden kann.

• Plane etwas zu verwerfen, denn du wirst es so oder so tun.

• Wenn man das Interesse an einem Programm verloren hat, dann besteht die letzte Pflicht in der Weitergabe an einen kompetenten und fachkundigen Nachfolger.

• Seine Benutzer als Mitentwickler einzubeziehen, ist die einfachste Art, den Programmcode schnell zu verbessern und die Effizienz der Fehlersuche zu steigern.

• Veröffentliche früh, oft und höre auf die Kunden.

• Ist die Basis an Mitentwicklern und Beta-Testern ausreichend groß, dann wird nahezu jedes Problem schnell charakterisiert werden und die Lösung jemandem offensichtlich sein.

• Debugging (Austesten und Fehlerbeseitigen) ist parallelisierbar.

• Wenn man seine Tester als die wertvollste Hilfsquelle behandelt, werden sie als eine solche reagieren.

• Nach guten eigenen Ideen ist das Erkennen guter Ideen anderer am besten. Manchmal ist letzteres aber noch besser.

• Oft kommen die besten und innovativsten Lösungen durch die Erkenntnis, dass der Lösungsansatz und das daraus resultierende Konzept falsch waren.

• Perfektion (im Design) ist nicht erreicht, wenn nichts mehr hinzuzufügen ist, sondern wenn nichts mehr entfernt werden kann.

Auf der Grundlage dieses Entwicklungsmodells hat sich ein komplementäres Distributionsmodell für Open-Source-Produkte etabliert. Entwickler stellen die Software im Internet für Benutzer zur Verfügung. Die Benutzer können selbst nach Software suchen, diese testen und einsetzen. Ein Benutzer kann per E-Mail in direkten Dialog mit Entwicklern treten und an der Entwicklung der Software teilnehmen, indem er die Software beurteilt und diese Beurteilung an die Entwickler sendet. Eine weitere Möglichkeit besteht darin, Bündel zusammengestellter Software bei einem Software-Händler zu kaufen. Im Unterschied zu proprietärer Software bezahlt man für freie Software ausschließlich für den Service der Bereitstellung, während bei proprietärer Software Lizenzgebühren zu entrichten sind. Konkret bedeutet dies, dass eine einmal erworbene freie Software nach Belieben verteilt werden kann. Die Distributoren stellen eigenständig Software-Pakete zusammen und verteilen diese gebündelt an Benutzer. Weiterhin hat der Benutzer die Möglichkeit, freie Software direkt vom Entwickler zu beziehen. Distributionsformen sind hauptsächlich Download-Möglichkeiten via Internet, z.B. SourceForge.net, github.com, Google Code und CodePlex.com.

Lizenzmodelle

Wie bereits beschrieben, versteht man unter Open-Source-Software, deren Quellcode (“source code”), also die geschriebenen Anweisungen des Programmierers, im Gegensatz zu herkömmlicher Software (“proprietärer” oder “Closed-Source-Software”) frei zugänglich ist. Die wesentlichen Eigenschaften von OSS sind:

• Jeder hat das Recht, die Software nach eigenem Ermessen zu nutzen.

• Der Quelltext muss jedem Benutzer offengelegt werden oder es muss auf eine frei zugängliche Stelle verwiesen werden, wo er erhältlich ist.

• Der Benutzer hat das Recht, die Software zu modifizieren und in modifizierter Form weiter zu verteilen.

• Die Lizenz darf niemanden im Verkauf oder der Weitergabe der Software in Form einer Softwarezusammenstellung einschränken.

Im Gegensatz hierzu gilt für proprietäre Software:

• Vervielfältigung, Weiterverbreitung und Modifizierung sind untersagt.

• Das Nutzungsrecht wird in Form einer Lizenz erteilt.

• Eigentümer der Software ist nicht der Anwender, sondern weiterhin der Hersteller, denn er hat das Urheberrecht und die vollständige Kontrolle über das Produkt.

Die wesentliche Kategorisierung von Open-Source-Lizenzen lässt sich anhand des Begriffes Copyleft [Stallman 2002] durchführen:

Ausprägung	Beschreibung	Lizenzen (Beispiele)
Starkes Copyleft	Keine Einbindung in proprietären Code möglich	GPL
Schwaches Copyleft	Statisches und dynamisches Linken von Code mit proprietärer Software sind zulässig, Eigenentwicklungen dürfen als proprietäre Software weitergegeben werden	LGPL
Kein Copyleft	Der gesamte Code darf auch als proprietäre Software weitergegeben werden	BSD, Apache

GPL und LGPL
Die GNU General Public License ist eine freie Copyleft Lizenz für Software und andere Produkte. Wo andere Lizenzen das freie Verbreiten und Verändern von Produkten verbieten, garantiert GPL die Freiheit zur Weitergabe der Werke. Somit können andere Entwickler beliebige Teile oder den gesamten Quellcode weiter verwenden [Open Source Initiative 2012].

BSD-License
Software unter dieser Lizenz darf frei genutzt werden, es ist auch gestattet, Teile oder den gesamten Quellcode zu kopieren, zu verändern und weiter zu verbreiten. Der Unterschied zur GPL und LGPL ist, dass es sich hierbei nicht um Copyleft handelt und der kopierte oder veränderte Code auch in proprietären Produkten auftauchen kann, ohne dass der Quellcode veröffentlicht wird [Open Source Initiative 2012].

Apache
Die Apache-Lizenz geht auf die Apache Software Foundation zurück und existiert bereits in der Version 2.0. Ähnlich der BSD handelt es sich hierbei ebenfalls nicht um Copyleft. Die hiermit lizensierte Software darf frei verwendet, verändert und verbreitet werden, muss allerdings eine Kopie der ursprünglichen Lizenz beinhalten [Open Source Initiative 2012].

Open Source Geschäftsmodelle

Im Rahmen von Open Source Vorhaben können unterschiedliche Geschäftsmodelle identifiziert werden. Leiteritz unterteilt diese in Produkt-, Dienstleistungs- und Mediator-Geschäftsmodelle [Leiteritz 2004].

• Produkt-Geschäftsmodelle

  • OSS-Distributor: Der OSS-Distributor fasst OSS-Komponenten zu einem Gesamtpaket zusammen und vertreibt es.

  • OSS-Applikationsanbieter: Der OSS-Applikationsanbieter entwickelt die Software selbständig und stellt diese ab einem gewissen Zeitpunkt unter eine OSS-Lizenz.

  • OSS-Appliance-Hersteller: Ein OSS-Appliance-Hersteller kombiniert Hardware und OSS-Software zu einer Gesamtlösung.

• Dienstleistungs-Geschäftsmodelle: Im Dienstleistungs-Geschäftsmodell werden Dienstleistungen für ein existierendes OSS-Produkt angeboten. Dabei handelt es um Leistungen, die von einem einfachen Telefon- oder E-Mail-Support bis hin zu einem kompletten Dienstleistungspaket reichen.

• Mediator-Geschäftsmodelle: Ein Mediator bringt die verschiedenen Interessensgruppen auf einem Marktplatz zusammen. Bekanntestes Beispiel ist SourceForge.

Krishnamurthy gliedert Open Source Geschäftsmodelle in [Krishnamurthy 2003]:

• Distributor Geschäftsmodell: Ähnlich der Darstellung von Leiteritz beschreibt Krishnamurthy den Distributor als Anbieter von OSS-Softwarepaketen inkl. Support für definierte Kundengruppen (Privatkunden und/ oder Unternehmenskunden). Weiterhin ermöglicht der Distributor den Zugang zu regelmäßigen Software-Updates.

• Software Producer [Non-GPL Model]: Ein Software Producer kann OSS-Software sowohl in ein dediziertes Softwareprodukt einarbeiten und als neues Produkt vertreiben als auch mit bestehenden Softwareprodukten bündeln. Der Source Code muss jedoch nicht offengelegt werden.

• Software Producer [GPL Model]: Dieses Modell unterscheidet sich zum vorherigen lediglich in der Hinsicht, dass der Source Code offen gelegt werden muss.

• Third Party Service Provider: Der Third Party Service Provider bietet Support für unterschiedliche Produkte an. Für ihn ist es nicht relevant von welcher Quelle ein Kunde sein Produkt bezogen hat, es muss jedoch einem festgelegten Kriterienkatalog erfüllen, um den vollen Support zu gewährleisten.

   

Hybride Geschäftsmodelle

Derzeit sind die Software-Geschäftsmodelle für “Open-Source” und “Closed-Source” noch scheinbar widersprüchlich. Abbildung 1 stellt die wesentlichen Merkmale der beiden Geschäftsmodelle gegenüber. Während traditionelle Geschäftsmodelle primär der linken Spalte entsprechen, tendieren Open-Source-Geschäftsmodelle zu den Merkmalsausprägungen der rechten Spalte.

Abb. 1: Merkmale von Softwaremärkten [Nüttgens 2007, S. 103].

Der Open-Source-Ansatz steht zunächst dem klassischen Ansatz des Software-Vertriebs entgegen, der seinen Quellcode in der Regel vor Dritten schützt, um zu verhindern, dass dieser kopiert wird und eine unkontrollierte Verteilung der Software einsetzt. Zunehmend gibt es aber eine Mischung beider Konzepte (Hybride Lizenzmodelle).

Das Open-Source-Konzept stellt eine alternative Form der Software-Entwicklung und des Software-Vertriebs dar. Es kombiniert bereits vorhandenes Wissen über Software-Entwicklung, -Vertrieb und -Organisationen mit den Effekten der Internet-Ökonomie. Durch die zunehmende Standardisierung von lizenzkostenfreien Software-Schnittstellen und -Formaten wird die Bedeutung proprietärer Softwarelösungen tendenziell abnehmen. Der Bezug benötigter Software aus Open-Source-Quellen wie z. B. Software-Brokern oder anderen Unternehmungen erscheint bei mindestens gleicher Leistungsqualität attraktiver als die Abhängigkeit von Herstellern proprietärer Lösungen. Die bisherigen Lizenzgebühren werden dann zunehmend durch Dienstleistungsgebühren ersetzt.

---

Literatur

Brügge, Bernd et al.: Open Source Software: Eine ökonomische und technische Analyse, Springer Verlag, 2004.

DiBona, Chris; Ockman, Sam; Stone, Mark (Hrsg.): Open Sources: Voices from the Open Source Revolution. Cambridge (MA): O’Reilly, 1999. http://www.oreilly.com/catalog/opensources/book/toc.html (Abruf 23.04.2020).

Krishnamurthy, Sandeep: An Analysis of Open Source Business Models. SSRN eLibrary, 2003.

Leiteritz, Raphael: Open Source-Geschäftsmodelle. In: Gehring, R.A., Lutterbeck, B. (Hrsg.): Open Source Jahrbuch 2004: Zwischen Softwareentwicklung und Gesellschaftsmodell. Lehmanns, Berlin, 2004, S. 139-170.

Nüttgens, Markus: IT Innovation & Open Source: A Question of Business Ethics or Business Model?. In: Hanekamp, Gerd (Hrsg.) Business Ethics of Innovation. Berlin et al., Springer, 2007, S. 101-110.

Open Source Initiative (OSI). http://www.opensource.org/ (Abruf: 23.04.2020).

Picot, Arnold; Fiedler, Marina: Organisation von Innovation – Koordination und Motivation von Open-Source-Software-Projekten, Gabler, 2008.

Raymond, Eric (Hrsg.): The Cathedral and the Bazaar. Version 3.0, 2000. http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ (Abruf: 23.04.2020).

Stallman, Richard M.: Free Software, Free Society: Selected Essays of Richard M. Stallman. Boston (MA): GNU Press, 2002. http://www.gnu.org/philosophy/fsfs/rms-essays.pdf (Abruf: 23.04.2020)