IT-Sachverständiger Dr. Manfred Fitzner

(In meinem Post wird aus Gründen der Lesbarkeit und Klarheit auf die Verwendung einer gendergerechter 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.

Der folgende Artikel soll eine Sensibilisierung auf einen Sachstand setzen, der weitgehend unbeachtet scheint. Oder mit dem zumindest nicht immer professionell umgegangen wird. Sowohl bei Auftraggebern 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, das heute fast jedes Unternehmen, also auch die Traditionsanbieter, Open Source verwendet. Zuweilen sogar, ohne eine exakte, 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 bzw. bewerten, was dies in den Folgejahren für Auswirkungen auf seine Kosten & Wartbarkeit seiner Anwendung haben könnte?

Oder verlangt er vom AN eine Risikobewertung von möglichen Zusatzkosten?

Nein- dies ist in Ausschreibungen nicht enthalten!

Free and Open Source Software (FOSS) darf nach dem Willen der Urheber genutzt werden, wenn die individuellen Lizenzbestimmungen vom Nutzer eingehalten werden. Ein Programmierer kann bestimmen: Ich habe etwas programmiert und wer das Programm nutzt, soll meine Bedingungen einhalten. Das bedeutet auch: Wer das Programm nutzt, ohne sich an diese individuellen Lizenzbestimmungen zu halten hat keine Berechtigung zur Nutzung, muss die Nutzung unterlassen und löst ggf. noch weitere Rechtsfolgen aus.

Leider gibt es viele verschiedene Lizenzbestimmungen. Die Texte der Lizenzbestimmungen sind meistens im US englischen abgefasst und beinhalten viele rechtliche und technische Begriffe, was es schwierig macht, sie zu verstehen und entsprechend zu handeln.

Aus der Sichtweise des Praktikers kann man grob gesagt drei Gruppen von Lizenzbestimmungen betrachten. Gefährlich – nicht gefährlich aber mit administrativem Aufwand verbunden – ungefährlich.

Die Unterscheidung bestimmt sich nach dem sogenannten „Copyleft Effekt“ und der übrigen Komplexität der juristischen Regelungen, unter denen die OSS (Open Source Software) verwendet werden darf. Copyleft bedeutet kurz gesagt: Wenn Du meine Software nutzt und mit anderer Software permanent verbindest, muss auch sämtliche andere Software, die jetzt mit meiner Software ständig verbunden ist, meinen Lizenzbestimmungen unterfallen. Es gibt Softwaretypen, die einen strengen Copyleft Effekt bewirken (z.B.GPL2, GPL3, AGPL), Softwaretypen, die einen schwachen Copyleft nach sich ziehen (z.B. LGPL, Apache) und solche, die keinen Copyleft Effekt bewirken (z.B. MIT, BDS). Natürlich ist das keine juristisch belastbare Aussage die generell gilt, aber aus der Praxis kann man schon sagen: FOSS, der unter langen und komplexen Lizenztexten vertrieben wird (GPL) ist weniger gefährlich als FOSS, der unter kurzen Nutzungsbedingungen angeboten wird (BDS).

Welche Lizenzbestimmungen zu beachten sind, kann man nur nach der Rücksprache mit dem Lieferanten erfahren. Dieses muss eine interne Compliance mit den Programmierern durchführen!

Damit sind zumindest 2 Aufgaben zu lösen:

1. Das Systemhaus gibt an, welche Softwarebestandteile in „der Software“ beinhaltet sind.

2. Der Auftraggeber erarbeitet anhand der rechtlichen Bedingungen die von ihm einzuhaltenden Prozesse.

Eine weiterer Komplex kommt hinzu:

In den Verträgen ist unbedingt zu vereinbaren:

a) Wer ist dafür verantwortlich, die Pflichten einzuhalten, die sich aus den Verwendung der FOSS Lizenzen ergeben. Unter Juristen derzeit umstritten sprechen aber die besseren Argumente dafür, dass der Nutzer (sprich der AG) hierfür verantwortlich ist.

b) Wer ist dafür verantwortlich, dass der Kunde weiß, was er zu tun hat und diese Regelungen auch einhält. Die besseren Argumente sprechen dafür, dass dies das IT-Unternehmen (AN) ist.

Wenn wir moderne, preiswerte Software nutzen wollen muss trotzdem die Frage gestattet sein: Wer lebt denn wie von der Produktion dieser Software?

Sind das alles nur Nerds, die ohne Geld - wie eigentlich leben? Oder sind es intelligente, kommunikative Typen, die auch mal Bekanntschaft machen mit einem Business-Berater? Dieser wird dem intelligenten Open Source Entwickler ein nettes Geschäftsmodell – per Provision - anbieten. Und spätestens bei der nächsten Version zahlt dann der Auftraggeber.

Alles hat seinen Preis. 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 (Ausschreibung) sein. Für strategische Anwendungen sollten weitergehende Verträge abgeschlossen werden – die bis zu den Software-Quellen Verbindlichkeiten herstellen.

Vorlagen wie EVB-IT etc. beachten die oben genannte Aufgabenstellung – zumindest aus Sicht der Autoren – nicht in ausreichendem Maße. Das oben genannte Risiko ist über partnerschaftliche Verträge mit dem Auftragnehmer exakt zu vereinbarten. Die juristische Sicht und die Sicht des Nutzungszyklus der Software mit Fokus auf Entwicklung, Weiterentwicklung, Entstörung und Wartung muss unbedingt Beachtung finden.

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.

Bei komplexeren IT-Lösungen wird der Ansatz helfen, die geplanten Kosten durch Einbeziehung von Nutzungspartnern zu entlasten: Z.B. könnte eine Stadt eine IT-Lösung auch anderen Städten anbieten und damit eine Refinanzierung erreichen. Welche Rechte werden benötigt bzw. sind zu erwerben, um bei einer Refinanzierung nachhaltig aufzusetzen? Wie muss der AN einbezogen werden, damit aus Sicht des AG´s die Kosten für den Lebenszyklus auch längerfristig planbar bleiben?

Es existieren Modelle, um hier weitgehend Herr der Lage zu bleiben. Dabei ist mit Bedacht ein langfristiges Model auszuwählen. Dieses Modell muss den Anbietern Luft zum Atmen – sprich reagieren – lassen. Beim AG muss eine Analyse der Problematik und daraus ein qualifizierter Input in die Kosten- bzw. Haushaltsplanung erarbeitet werden.