Open-Source-Software Freiheit bei der Programmierung

Es ist noch nicht so lange her, dass Software-Entwicklungsteams darüber entschieden, ob eine bestimmte Funktionalität selbst entwickelt oder eingekauft werden sollte. Die Entscheidung war nicht immer nur eine Kostenfrage. Auch das fehlende Wissen über kommerzielle Komponenten Dritter hatte zur Folge, dass Software-Entwickler den größten Teil des Quellcodes – mehr als 90 Prozent – in ihren Softwareprodukten letztlich selbst schrieben.

Mit dem Internet hat sich das grundlegend geändert. Die weltweite Vernetzung erlaubt einen engen Austausch zwischen Software-Entwicklern und bietet eine Plattform, auf der Millionen kostenloser Softwarekomponenten zur Verfügung stehen. Heute liegt der Anteil der OSS-Produkte bei 50 bis 90 Prozent und umfasst Hunderte, wenn nicht Tausende von OSS-Komponenten.

Mehr Freiheit braucht mehr Kontrolle

Der Einsatz von OSS-Komponenten ermöglicht Unternehmen, große und anspruchsvolle Projekte zu stemmen, die letztlich auf „Best of Breed“-Komponenten beruhen. Das hat auch Folgen für die Entwicklungsprozesse. Um zum Beispiel Vertragsbedingungen auszuhandeln, Lizenzen zu erwerben und Vertraulichkeitserklärungen oder Service Level Agreements abzuzeichnen, mussten früher alle Softwarekomponenten von Drittanbietern durch IT, Einkauf und Rechtsabteilungen abgesegnet werden.

Heute hingegen finden abteilungsübergreifende Absprachen nur noch selten statt. Zudem wird der Einsatz von OSS in vielen Fällen nicht mit geltenden Richtlinien abgeglichen. Sind die Komponenten erst einmal ausgewählt und integriert, werden sie ohne regelmäßige Überprüfung einfach weiter verwendet.

Die Risiken solcher nicht verwalteter Open-Source-Software sind groß, werden aber von vielen Unternehmen nicht ernst genommen. In den meisten Fällen fehlt dafür schlichtweg eine Übersicht der im Unternehmen genutzten OSS-Komponenten. Bei Konzernübernahmen – wenn Transparenz eine zentrale Rolle spielt – kann häufig kein einziges OSS-Projekt genannt werden. Liegt ein Verzeichnis mit Open-Source-Komponenten vor, führt dieses für gewöhnlich nur einen Bruchteil auf – im Schnitt 20-mal weniger Open-Source-Komponenten als tatsächlich im Einsatz sind.

Wird Open-Source-Software nicht ordnungsgemäß verwaltet, kommt es zu zwei grundlegenden Problemen: Zum einen laufen Unternehmen Gefahr, gegen die Compliance-Richtlinien der von ihnen genutzten Lizenzen zu verstoßen. Zum anderen setzen sie sich dem Risiko unentdeckter Softwareschwachstellen aus, die sich in der OSS befinden.

Lizenzierungen prüfen

Geht es um die Auswahl geeigneter Komponenten sollten Software-Entwickler daher bestimmte Aspekte berücksichtigen – ganz gleich, ob es sich um Open Source oder um ein kommerzielles Angebot handelt. An erster Stelle stehen die legalen Rahmenbedingungen bei der Verwendung der Komponente und die damit verbundenen Verpflichtungen. Bei kommerziellen Komponenten gilt es, Zahlungs- und Nutzungsbedingungen zu verhandeln.

Aber auch Open-Source-Komponenten müssen hinsichtlich ihrer Lizenzierung geprüft werden. Wer beispielsweise eine Komponente in seinem Softwareprodukt nutzt, die unter die GNU General Public License fällt, verpflichtet sich unter anderem dazu, den Quellcode für das Produkt sowie den Quellcode für die ursprüngliche Komponente bereitzustellen. Komponenten mit MIT-Lizenz machen es erforderlich, einen Urheberrechts- und Genehmigungshinweis in die Software aufzunehmen.

Ist die Lizenzierung einer Open-Source-Komponente nicht eindeutig, ist Vorsicht geboten. Entweder wird die Komponente nicht häufig genutzt oder der Kreis der Benutzer ist relativ klein. So oder so ist es denkbar, dass ein Mitentwickler im Rahmen des ursprünglichen Entwicklungsprojekts nachträglich einen Antrag stellt, um den Code unter eine Lizenz zu stellen oder die lizenzrechtliche Lage neu festzulegen. Wird die Komponente bereits in einem Softwareprodukt verwendet, kann das für Softwarehersteller zu einem ernsten Problem werden. Die Entscheidung, ob eine profitable Software vom Markt genommen werden muss, hängt dann oft allein von der Reaktion des Autors/Urhebers der OSS oder des Projektverantwortlichen ab.

Alter und Wartung berücksichtigen

Neben der Lizenzierung lohnt es sich zudem, bei der Auswahl einer OSS-Komponente auf das Alter und den Wartungszustand des zugrundeliegenden Projekts zu achten. Gab es in den vergangenen Jahren keine weiteren Beiträge? Oder beschränkt sich die Mitwirkung am OSS-Projekt auf einen einzigen Autor? Die Zahl der aktiven Entwickler an einem Projekt und die aktive Lebensdauer eines Projekts sind wichtige Indikatoren für dessen Vitalität.

Es gibt jedoch auch eine Reihe von OSS-Projekten, die ausgereift sind und nur von einer einzigen Person getragen werden. Ihr Vorteil: Änderungen sind seltener notwendig als in Komprimierungs- und Bildverwaltungsbibliotheken. Hier findet man üblicherweise wenige Mitwirkende, aber viele Nutzer.

Sicherheit groß schreiben

Eine zentrale Rolle spielen auch Sicherheitsaspekte – in erster Linie mögliche, in OSS-Komponenten enthaltene Schwachstellen. Entwickler können hier auf Datenbanken und Feeds zurückgreifen, in denen aktuelle Listen bekannter Schwachstellen für die entsprechenden Komponenten geführt werden. Eine der bekanntesten Quellen mit Informationen zu OS-Schwachstellen ist zum Beispiel die National Vulnerability Database. In dieser Datenbank können Entwickler nach Komponentennamen suchen und die damit verbundenen Schwachstellen versionsspezifisch einsehen.

Trotz aller Vorsicht sollte man dabei jedoch bedenken, dass eine Schwachstelle nicht zwangsläufig ein Hinweis auf eine qualitativ minderwertige Komponente ist. Je beliebter oder wichtiger eine Komponente ist, desto wahrscheinlicher wird sie von Sicherheitsexperten mit dem Ziel überprüft werden, die Qualität zu verbessern. Eine Komponente, für die bereits Schwachstellen gemeldet sind, ist oft sicherer als eine Komponente, die diesbezüglich eine augenscheinlich „weiße Weste“ besitzt.

Schwchstellen regelmäßig überprüfen

Mit der Auswahl einer Komponente ist das OSS-Management jedoch noch nicht zu Ende. Eine regelmäßige Überprüfung auf bekanntgewordene Schwachstellen ist zentral, um die Sicherheit der Anwendungen gewährleisten zu können. Neue Angriffe über Schwachstellen werden typischerweise erst dann aufgedeckt, nachdem eine Komponente freigegeben und für gewisse Zeit verwendet wurde. Behält man hier den Überblick, lassen sich nach dem Bekanntwerden neuer Schwachstellen die Anwendungen über Updates schützen und Patches bereitstellen.

Schwachstellen, Lizenzierung und Projektverlauf gehören beim Einsatz von Open Source auf die Checkliste und stellen sicher, dass bei der Auswahl die beste Komponente für die jeweilige Anwendung zum Einsatz kommt. Für Entwickler wie Unternehmen lohnt es sich zudem Feedback, Bug Reports und Prüfungsergebnisse an die betreffenden Open-Source-Projekte zurückzuspielen und so effektiv und langfristig zur gesamten Open-Source-Community beizutragen. Diese Aktivitäten zahlen sich aus: Durch hochwertige OSS-Komponenten, sicherere Produkte, besser gesteuerte Upgrade-Zyklen und weniger Nacharbeit.