Thought Leadership
Open Source-Software (OSS) und das Internet haben die IT in den vergangenen Jahrzehnten nachhaltig verändert. Der Erfolg beider Technologien ist eng miteinander verwoben. Wir zeigen hier, wie Unternehmen von Open Source profitieren.
Die Free Software Foundation hatte bereits in den achtziger Jahren mit dem GNU-Projekt die Basis für den wirtschaftlichen und juristischen Erfolg von Open Source-Software gelegt. In den 90ern wurde das Internet zum Motor für Produkte wie das Linux-Betriebssystem, den Apache HTTP- und Tomcat-Applikations-Server, den Firefox-Browser und die mySQL-Datenbank. Als Infrastrukturlösungen bilden sie heute das Rückgrat vieler Web-Anwendungen in Unternehmen. So hat sich Open Source vom Rechenzentrum in alle Räume des „IT-Hauses“ ausgebreitet.
Anwender freuen sich über die freie und kostenlose Nutzung von Open Source-Lösungen. Unternehmen sollten jedoch die rechtlichen Konsequenzen der unterschiedlichen Open Source-Lizenzen kennen und ein für sie geeignetes Lizenzmodell wählen. Zwar ist die Beschaffung freier Software über das Internet sehr einfach, jedoch unterliegt der Einsatz in der Unternehmens-IT klaren Regeln, die in der Governance beschrieben und überwacht werden müssen.
Was eine freie oder Open Source-Lizenz ist, regelt die Open Source-Initiative (OSI). Prinzipiell wird zwischen Lizenzen mit und ohne Copyleft unterschieden. Dies ist ein Wortspiel des englischen Begriffs Copyright und impliziert durch Ersetzen von „right“ durch „left“ die Möglichkeit zum Überlassen von Software. Das Copyleft bietet also grundsätzlich das Recht zum Kopieren, während es durch das Copyright verboten wird.
Seit ihrer Einführung gilt die GPL als am weitesten verbreitete freie Software-Lizenz, gefolgt von ihrer freieren Variante GNU Lesser General Public License (LGPL). Weniger restriktiv sind die an der Berkeley Software Distribution-Lizenz (BSD) angelehnten Varianten wie die Apache- und die MIT-Lizenz, die ursprünglich aus dem akademischen Bereich stammen. Um Software mit der Apache-Lizenz und der GPL zusammen verwenden zu können, wurden deren Bestimmungen in ihren aktuellen Versionen angeglichen. Als Sonderform für die freie Nutzung von immateriellen Gütern, wie Texten oder Bildern, gibt es beispielsweise die Creative Commons-Lizenz, wie sie Wikipedia verwendet.
Sowohl beim starken (GPL) als auch beim schwachen Copyleft (LGPL, MPL) muss eine Software-Lösung, die Software-Komponenten Dritter unter dieser Lizenz integriert hat, ihrerseits auch wieder unter diese Lizenz gestellt werden. In der Praxis bedeutet dies, dass Organisationen gegebenenfalls den Quellcode ihrer proprietären Software veröffentlichen müssen. Hier sollten die Verantwortlichen also besonders aufmerksam die Lizenzbestimmungen durchsehen, um rechtlich auf der sicheren Seite zu sein.
Die LGPL-Lizenz eignet sich besonders für Programmierbibliotheken, da diese von externen Programmen verwendet werden, die unter einer anderen Lizenz veröffentlicht sind. Diese können Entwickler für proprietäre Anwendungen verwenden, ohne dass der Quellcode der eigenen Software veröffentlicht werden muss. Solange die LGPL-Bedingungen erfüllt bleiben, werden einige kommerzielle Open Source-Produkte, wie beispielsweise RedHat Linux oder mySQL, parallel unter einer dualen kommerziellen Lizenz angeboten. Dies erfüllt sowohl die Bedürfnisse der Open Source-Gemeinschaft als auch der professionellen Anwender.
Unternehmen sollten, genau wie bei den kommerziellen Lizenzen, stets einen aktuellen Überblick über die genutzten Varianten haben. Gerade bei der großen Vielfalt an Open Source-Lizenzen gilt hier der Grundsatz „weniger ist manchmal mehr“. Daher ist es hilfreich, sich auf wenige übliche und miteinander kompatible Lizenzarten zu beschränken. Anders als bei den kommerziellen Lizenzen spielen bei kommerziellen Open Source-Varianten weniger die Menge, sondern die Art und die Kompatibilität untereinander eine wichtige Rolle.
Open Source richtig einsetzen
Da bei den meisten OSS-Lizenzen die Lizenzinformationen mit der Software ausgeliefert werden müssen, sollten diese Daten einheitlich im Projekt verwaltet werden. Bewährt hat sich eine Integration des Lizenz-Managements im Projekt-Wiki oder im Rahmen des Versionierungs- und Build-Prozesses. Mit dieser Übersicht vermeiden Entwickler Auseinandersetzungen oder gar Rechtsstreitigkeiten. Denn auch hier gilt: Unwissenheit und Nachlässigkeit schützen vor Strafe nicht.
Organisationen sollten die Lizenztexte für den internationalen Markt in mehreren Sprachen bereithalten und mit ihren eigenen Lizenzbedingungen vorher abstimmen. Bei allen verwendeten Open Source-Komponenten ist eine Angabe der Versionsnummern sinnvoll – ebenso wie bei der eigenen Software. Einige dieser Aufgaben übernimmt ein einheitliches Build-Management automatisch und sichert so die Einhaltung der Regeln.
Chancen und Risiken von Open Source
Die Vorteile von Open Source in der Software-Entwicklung sind nicht nur finanzieller Art. Durch die ständige Weiterentwicklung der Software durch die Community verbessern sich Stabilität und Sicherheit kontinuierlich – und davon profitiert auch die Anwendung, die diese Open Source-Komponenten einsetzt.
Aufgrund ihrer hohen Popularität sowie aus wirtschaftlichen Gründen wird Open Source immer häufiger im Rahmen kommerzieller Software-Projekte eingesetzt. So ist es möglich, in der Entwicklung stets die neuesten quelloffenen Versionen zu verwenden, in der Produktion jedoch zusätzlich die qualitätsgesicherten Varianten des Herstellers mit einem professionellen Support. Der konkrete Einsatz von Open Source-Produkten sollte sich immer an den Anforderungen und dem Nutzen für die zu unterstützenden Geschäftsprozesse orientieren.
Für den Einsatz von Open Source-Software und ihren wirtschaftlichen Nutzen bieten unabhängige Stellen, wie beispielsweise die EU oder der Branchenverband BITKOM, allgemeine Hinweise. Für die erste Suche nach einer konkreten Anwendung helfen die allgemeinen oder auf Unternehmensanforderungen spezialisierten Software-Verzeichnisse für freie Software, wie beispielsweise Ohloh oder das Enterprise-Open Source-Directory (EOSD). Diese kategorisieren und bewerten aktuelle Software-Informationen. Bei der Entscheidung für den Einsatz von architekturkritischen Open Source-Komponenten ist es jedoch effizienter, externe Experten einzubeziehen, die bereits praktische Erfahrung mit der gewünschten Lösung gesammelt haben.
Kostenlos ist nicht umsonst
Bei der quelloffenen Software können Anwender ihre Anregungen und Rückmeldungen in die laufende Entwicklung einbringen, wodurch sich beispielsweise die Fehlerbehebung beschleunigt. Da die meisten Kosten weniger bei der Software-Erstellung als vielmehr bei der Pflege und dem Betrieb entstehen, bieten Open Source-Produkte hinsichtlich der Langlebigkeit und der Unterstützung älterer Versionen große Vorteile. Dies sind Argumente, warum kostenbewusste Unternehmen und öffentliche Verwaltungen immer stärker Open Source-Lösungen einsetzen. Gerade für virtualisierte oder embedded Umgebungen sind Open Source-Lizenzen besser geeignet, als die eher an der realen Hardware und den Benutzern orientierten kommerziellen Lizenzen. Ebenso bietet sich Open Source für die Ablösung nicht mehr gewarteter Legacy-Anwendungen an, um damit einen späteren Vendor-Lock-In mit kostenintensiver Migration zu vermeiden.
Designed-by-Community vs. Designed-by-Company
Die meisten quelloffenen Produkte verfolgen die Strategie, mit einer stabilen Produktivversion und einer innovativen Entwicklerversion die Balance zu finden zwischen neuen Funktionen und einer eher traditionellen Weiterentwicklung. Oft werden Fehlerlösungen oder Sicherheitskorrekturen in beiden Versionen parallel übernommen. Solange Interesse für den Einsatz älterer Versionen besteht, kann jeder so lange wie gewünscht Anpassungen an den Quellen vornehmen. So ergeben sich oft längere Lebenszyklen als bei vergleichbaren kommerziellen Produkten. Da Funktionserweiterungen bei Open Source keinem festen Release-Plan folgen, ist die Weiterentwicklung stärker an den Anforderungen der Nutzer orientiert. Statt eines zu großen Funktionsumfangs und langer Release-Zyklen, wie dies bei kommerziellen Produkten oft üblich ist, steht hier eine Spezialisierung und agile Weiterentwicklung mit kurzen Feedback- und Test-Zyklen im Vordergrund. Hier bietet der Designed-by-Community-Ansatz deutliche Vorteile gegenüber den traditionellen Vorgehensweisen Designed-by-Company oder Designed-by-Committee. Oftmals wird jedoch bei dem Vergleich zwischen kommerzieller und Open Source-Entwicklung übersehen, dass sich beide Verfahren durchaus ergänzen können.
Auch bei der Open Source-Entwicklung werden formale Qualitäts-, Release- und Abstimmungsregeln beachtet. Ohne diese Prozesse wäre eine verteilte weltweite Entwicklung, wie sie bei Open Source üblich ist, gar nicht möglich. Außerdem folgen die Open Source-Community sowie das zugehörige Ökosystem dem Prinzip des Gebens und Nehmens.
Die durch den Open Source-Einsatz gewonnene größere Flexibilität und Freiheit steht häufig eine Unsicherheit der Unternehmen gegenüber, die den Support und die Haftung betrifft. Hier bieten spezialisierte Dienstleister oder professionelle Open Source-Unternehmen, ihre Unterstützung an. So wird Open Source schließlich zu einem festen Bestandteil der IT-Strategie.
Frank Pientka
Diesen Artikel finden Sie auch in der Ausgabe Januar/Februar 2011 des it management.
