(In meinem Post wird aus Gründen der Lesbarkeit und Klarheit auf die Verwendung einer gendergerechten Sprache verzichtet.)
Smart Gouvernement, Smart City, die Digitale Stadt – unter diesen Schlagworten werden IT-Systeme entwickelt, um den Bürgern moderne Informationsdienste zur Verfügung zu stellen.
Dieser Artikel zeigt ein häufig unterschätztes Risiko moderner Softwareprojekte: unklare Rechte an eingesetzten Komponenten – mit direkten Auswirkungen auf Kosten und Betrieb. Sowohl bei Auftraggebern – insbesondere im öffentlichen Sektor – als auch bei Auftragnehmern existieren in diesem Umfeld relevante Baustellen.
Ein Auftraggeber (AG) erwirbt ein Softwaresystem. Allerdings besteht oft keine Klarheit über künftige Kostenrisiken.
Hintergrund: Heutige Software soll modern sein – und ist es auch. Neue Unternehmen agieren am Markt und stellen tolle Produkte vor.
Die Entwickler sind findig und modern, schreiben nicht jeden Code selbst, sondern nutzen die massenhaft im Internet zu findenden Bibliotheken. D.h.: Softwareentwickler binden (oft auch eigenständig) Open Source für die Lösung ihrer Aufgaben ein.
Open Source – dieser Begriff suggeriert offenen, für alle unentgeltlich zu nutznießenden Code.
Stopp: An diesem Punkt müssen wir den ersten Fehler korrigieren. Open Source Software hat Urheber, die haben Urheberrechte. Dies tut erst einmal nicht weh. Welche Rechte haben die Urheber aber zu der Software im Detail bestimmt?
Können Unternehmen (Softwarehäuser & Anwender) die Software nur nutzen oder auch verändern? In welchem Umfang? Für welches Release gilt welches Recht?
Es existieren viele interschiedliche Lizenzmodelle.
Die folgende zwei Beispiele haben Entwickler ihrem Code zugeordnet:
(1) Aufforderung zur Rück-Lieferung von verändertem Code an den Entwickler,
(2) kostenlos nur bei nicht-kommerzieller Anwendung.
Ein Softwarehaus nutzt Open Source als Bibliothek zur Entwicklung eigener Produkte. Ein typischer Releasewechsel der Basisplattform steht an, z.B. auf Windows, Release xyz. Dieses Release behebt Sicherheitslücken, das vorherige wird irgendwann abgekündigt. Die Open Source Bibliothek funktioniert an einigen Stellen nicht mehr, daher muss in Folge auch auf ein neues Release gewechselt werden.
Doch für dieses Release wird für die Nutzung seitens des Urhebers „plötzlich“ ein Obolus erhoben.
Was macht das Softwarehaus, der Auftragnehmer (AN)? Es muss Kosten an seinen Kunden – den AG – durchreichen.
Oder es muss Wartungskosten erhöhen. Oder es „setzt zu“, kommt dann aber in finanzielle Schwierigkeiten. Ein jedes Szenario mündet – früher oder später – in eine Kostenerhöhung beim AG.
Das Systemhaus (AN):
Insider wollen wissen, dass heute fast jedes Unternehmen, also auch Traditionsanbieter, Open Source verwendet. Zuweilen sogar, ohne eine exakte und aktuelle Übersicht über alle Bausteine und deren exakte Nutzungsbedingungen zu haben. Hier muss dringend nachgearbeitet werden.
Der AG:
Verlangt der Auftraggeber vom Lieferanten eine Liste der genutzten Open Source-Bausteine und der dazugehörigen Rechte? Möchte der AG tatsächlich Kopien von fremdländischen Rechtsangaben lesen? Kann er überhaupt einschätzen, was dies in den Folgejahren für Auswirkungen auf seine Kosten und die Wartbarkeit seiner Anwendung haben könnte?
Oder verlangt er vom AN eine Risikobewertung von möglichen Zusatzkosten?
Nein – dies ist in Ausschreibungen oft nicht enthalten.
Free and Open Source Software (FOSS) darf nach dem Willen der Urheber genutzt werden, wenn die individuellen Lizenzbestimmungen vom Nutzer eingehalten werden. Wer ein Programm nutzt, ohne sich an diese individuellen Lizenzbedingungen zu halten, hat keine Berechtigung zur Nutzung, muss die Nutzung unterlassen und löst gegebenenfalls weitere Rechtsfolgen aus.
Leider gibt es viele verschiedene Lizenzbestimmungen. Die Texte sind meistens im US-Englischen abgefasst und beinhalten zahlreiche rechtliche und technische Begriffe, was sie in der Praxis schwer verständlich macht.
Aus praktischer Sicht lassen sich grob drei Gruppen unterscheiden: gefährlich – nicht gefährlich, aber mit administrativem Aufwand verbunden – ungefährlich.
Entscheidend ist unter anderem der sogenannte Copyleft-Effekt. Es gibt Lizenztypen mit starkem Copyleft (z.B. GPL2, GPL3, AGPL), mit schwachem Copyleft (z.B. LGPL, Apache) und solche ohne Copyleft-Effekt (z.B. MIT, BSD).
Welche Lizenzbestimmungen konkret zu beachten sind, kann man oft nur nach Rücksprache mit dem Lieferanten erfahren. Dieser muss dafür eine interne Compliance mit den Programmierern durchführen.
Damit sind zumindest zwei Aufgaben zu lösen:
1. Das Systemhaus gibt an, welche Softwarebestandteile in „der Software“ enthalten sind.
2. Der Auftraggeber erarbeitet anhand der rechtlichen Bedingungen die von ihm einzuhaltenden Prozesse.
Hinzu kommt ein weiterer Komplex:
a) Wer ist dafür verantwortlich, die Pflichten einzuhalten, die sich aus der Verwendung der FOSS-Lizenzen ergeben?
b) Wer ist dafür verantwortlich, dass der Kunde weiß, was er zu tun hat und diese Regelungen auch einhält?
Wenn wir moderne, preiswerte Software nutzen wollen muss die Frage gestellt werden: Wer lebt denn wie von der Produktion dieser Software?
Die zunehmende Verbreitung einer Open-Source-Komponente kann dazu führen, dass deren Urheber bei späteren Versionen wirtschaftliche Interessen berücksichtigen und die Nutzung lizenzpflichtig ausgestalten. Dann entstehen neue Kosten für die Wartung - entweder auf AG- oder AN-Seite.
Open Source reduziert initial Kosten – verschiebt aber Risiken in den Betrieb. Für langfristig einzusetzende Lösungen sind beim Wartungsbudget entsprechend dem Anteil an Open Source gewisse Sicherheitspuffer einzuplanen.
Wenigstens sollte man seine Lieferanten auffordern, die eigenen Risiken selbst aufzuarbeiten. Dies kann und muss heute ein Bestandteil des Lastenheftes sein.
Für strategische Anwendungen sollten weitergehende Verträge abgeschlossen werden – bis hin zu Regelungen, die Verbindlichkeiten auf Ebene der Software-Quellen schaffen.
Grundlage ist eine Aufarbeitung der Dokumentation über alle Open Source Bibliotheken beim AN und die lizenzrechtliche Auswertung bzw. Risikobetrachtung aus Kostensicht für den AG.