Aufgabenstellung

Smart Government, Smart City, die Digitale Stadt – unter diesen Schlagworten werden IT-Systeme entwickelt, um Bürgern moderne Informationsdienste zur Verfügung zu stellen.

Der folgende Artikel soll für einen Sachverhalt sensibilisieren, der weitgehend unbeachtet bleibt oder zumindest nicht immer professionell gehandhabt wird. Sowohl bei Auftraggebern (AG) als auch bei Auftragnehmern (AN) existieren in diesem Umfeld relevante Baustellen.

Risiko & Hintergrund

Ein Auftraggeber erwirbt ein Softwaresystem. Allerdings besteht oft keine Klarheit über künftige Kostenrisiken.

Heutige Software soll modern sein – und ist es auch. Neue Unternehmen agieren am Markt und stellen überzeugende Produkte vor. Die Entwickler sind findig und effizient, schreiben nicht jeden Code selbst, sondern nutzen die massenhaft im Internet verfügbaren Bibliotheken. Das heißt: Softwareentwickler binden (oft eigenständig) Open Source für die Lösung ihrer Aufgaben ein.

„Open Source“ suggeriert vielen: offener, für alle kostenlos nutzbarer Code. Stopp: Open-Source-Software hat Urheber – und diese Urheber haben Rechte. Die Frage ist: Welche Rechte haben die Urheber im Detail festgelegt?

Können Unternehmen (Softwarehäuser & Anwender) die Software nur nutzen oder auch verändern? In welchem Umfang? Und für welches Release gelten welche Rechte?

Beispiele für Open-Source-Lizenzbedingungen

Es existieren viele unterschiedliche Lizenzmodelle. Zwei typische Beispiele:

  • Aufforderung zur Rücklieferung von verändertem Code an den ursprünglichen Entwickler.
  • Kostenlose Nutzung nur bei nicht-kommerzieller Anwendung.

Szenario aus der Praxis

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 eingesetzte Open-Source-Bibliothek funktioniert an einigen Stellen nicht mehr, daher muss ebenfalls auf ein neues Release gewechselt werden. Für dieses neue Release verlangt der Urheber plötzlich ein Entgelt.

Was macht das Softwarehaus (AN)? Es muss Kosten an seinen Kunden – den AG – weiterreichen, Wartungskosten erhöhen oder die Mehrkosten selbst tragen und dadurch in wirtschaftliche Probleme geraten. Jedes Szenario führt früher oder später zu höheren Kosten beim AG.

Faktencheck

Das Systemhaus (AN)

Insider wissen: Heute verwendet nahezu jedes Unternehmen – auch Traditionsanbieter – Open Source. Zuweilen sogar, ohne eine exakte, aktuelle Übersicht über alle Bausteine und deren Nutzungsbedingungen zu haben. Hier besteht dringender Nachholbedarf.

Der Auftraggeber (AG)

Verlangt der Auftraggeber vom Lieferanten eine Liste der genutzten Open-Source-Bausteine und der dazugehörigen Rechte? Möchte der AG tatsächlich fremdsprachige Lizenztexte lesen? Kann er einschätzen, was dies langfristig für Kosten und Wartbarkeit bedeutet?

Oder verlangt er vom AN eine Risikobewertung möglicher Zusatzkosten? In der Praxis: Nein – dies ist in Ausschreibungen meist nicht enthalten.

Systematik der FOSS-Lizenzen

Free and Open Source Software (FOSS) darf nach dem Willen der Urheber genutzt werden, wenn die individuellen Lizenzbestimmungen eingehalten werden. Ein Programmierer kann bestimmen: „Ich habe etwas programmiert, und wer es nutzt, muss meine Bedingungen einhalten.“

Wer das Programm ohne Beachtung dieser Bedingungen nutzt, hat keine Berechtigung zur Nutzung, muss die Nutzung unterlassen und löst gegebenenfalls weitere Rechtsfolgen aus.

Aus praktischer Sicht lassen sich grob drei Gruppen unterscheiden:

  • Gefährlich (rechtlich riskant / starke Bindung).
  • Nicht gefährlich, aber mit administrativem Aufwand verbunden.
  • Ungefährlich (geringe Einschränkungen).

Entscheidend ist der Copyleft-Effekt und die Komplexität der Regelungen. Copyleft bedeutet kurz: Wenn Sie meine Software nutzen und mit anderer Software dauerhaft verbinden, muss auch diese andere Software meinen Lizenzbestimmungen unterliegen.

Beispiele:

  • Strenger Copyleft: z. B. GPL2, GPL3, AGPL.
  • Schwacher Copyleft: z. B. LGPL, Apache.
  • Kein Copyleft-Effekt: z. B. MIT, BSD.

Aus der Praxis lässt sich sagen: FOSS mit langen, klaren Lizenztexten (z. B. GPL) ist oft weniger riskant als FOSS mit sehr kurzen, vagen Nutzungsbedingungen (z. B. BSD), weil die Pflichten besser beschrieben sind.

Aufgaben von AN und AG

Welche Lizenzbestimmungen konkret zu beachten sind, kann nur in Abstimmung mit dem Lieferanten geklärt werden. Dieser muss eine interne Compliance mit den Programmierern durchführen.

Daraus ergeben sich mindestens zwei Aufgaben:

  1. Das Systemhaus (AN) dokumentiert, welche Softwarebestandteile in der Lösung enthalten sind – inklusive aller Open-Source-Komponenten.
  2. Der Auftraggeber (AG) erarbeitet anhand der rechtlichen Bedingungen die von ihm einzuhaltenden Prozesse.

Zusätzlich sollte vertraglich geregelt werden:

  • Wer ist verantwortlich dafür, die Pflichten aus den FOSS-Lizenzen einzuhalten? Viele Juristen sehen primär den Nutzer (AG) in der Verantwortung.
  • Wer ist verantwortlich dafür, dass der Kunde weiß, was er zu tun hat und diese Regelungen einhält? Hier sprechen viele Argumente dafür, dass das IT-Unternehmen (AN) diese Rolle übernehmen muss.

Den Tatsachen ins Auge blicken

Wenn wir moderne, preiswerte Software nutzen wollen, müssen wir uns fragen: Wer lebt eigentlich wovon in dieser Kette?

Sind das alles nur „Nerds“, die ohne Geld leben? Oder sind es intelligente, kommunikative Personen, die mit Business-Beratern Geschäftsmodelle entwickeln? Spätestens bei der nächsten Version zahlt der Auftraggeber – häufig ohne, dass die Lizenzmodelle vorher transparent diskutiert wurden.

Fazit

Alles hat seinen Preis. Für langfristig eingesetzte Lösungen sollten im Wartungsbudget entsprechend dem Anteil an Open Source Sicherheitspuffer eingeplant werden.

Wenigstens sollten Lieferanten aufgefordert werden, ihre eigenen Risiken systematisch aufzuarbeiten. Dies kann und muss heute Bestandteil des Lastenhefts (Ausschreibung) sein.

Für strategische Anwendungen sollten weitergehende Verträge abgeschlossen werden, die bis zu den Software-Quellen klare Verbindlichkeiten herstellen. Vorlagen wie EVB-IT berücksichtigen diese Aufgabenstellung nach Ansicht vieler Praktiker nicht ausreichend.

Grundlage ist eine saubere Dokumentation aller Open-Source-Bibliotheken beim AN und eine lizenzrechtliche Auswertung bzw. Risikobetrachtung aus Kostensicht für den AG.

Weiterentwicklung der Thematik

Bei komplexeren IT-Lösungen kann der strukturierte Umgang mit Open-Source-Lizenzen helfen, geplante Kosten durch Einbeziehung von Nutzungspartnern zu entlasten. Beispiel: Eine Stadt könnte eine IT-Lösung auch anderen Städten anbieten und damit eine Refinanzierung erreichen.

Welche Rechte müssen dafür vorhanden sein oder erworben werden, um diese Refinanzierung nachhaltig aufzusetzen? Wie muss der AN einbezogen werden, damit aus Sicht des AG die Kosten für den Lebenszyklus planbar bleiben?

Es existieren Modelle, um hier weitgehend Herr der Lage zu bleiben. Wichtig ist, ein langfristig tragfähiges Modell zu wählen, das den Anbietern Luft zum Reagieren lässt und auf Seiten des AG eine fundierte Analyse der Problematik mit sauberer Integration in die Kostenplanung sicherstellt.