Hinweis: Dieser Artikel ist älter als 3 Jahre
Inhalte, Quelltexte oder Links können zwischenzeitlich überholt sein.
Hinweis: Dieser Artikel ist älter als 3 Jahre
Inhalte, Quelltexte oder Links können zwischenzeitlich überholt sein.
Die Kommunale Gemeinschaftsstelle für Verwaltungsmanagement hat ein Arbeitspapier zu freier Software in Verwaltungen und öffentlichen Einrichtungen veröffentlicht1. Thema und Zeitpunkt hätte kaum besser gewählt sein können: Der Landkreis Anhalt-Bitterfeld hat gestern den Katastrophenfall ausgerufen. Durch einen Ransomware-Vorfall in dessen Microsoft-zentrierter IT-Infrastruktur sind zentrale Dienste für Wochen ausgefallen. Leistungen z.B. für Bedürftige, Löhne und Gehälter können nicht ausgezahlt werden.2
Es ist Zeit mit den immer gleichen Vorurteilen und vermeintlichen Argumenten aufzuräumen, die bar jeder Grundlage vorgetragen werden. Ich zitiere Full-Text das Kapitel 4 des unter einer CC-Lizenz stehenden Positionspapiers3, das in weiten Teilen auch auf Unternehmen übertragbar ist. Die Fußnoten zu den einzelnen Aussagen sind direkt aus dem Original-PDF zu entnehmen:
Beim Einsatz von IT befinden sich Kommunalverwaltungen immer in einer Art “Abhängigkeitsverhältnis”. Unter „Digitaler Souveränität“ wird daher das selbstbestimmte “Steuern von Abhängigkeiten” verstanden:
Ein bewusster Umgang mit Abhängigkeiten in der Digitalisierung setzt die Einsicht voraus, dass Abhängigkeiten unvermeidbar und nicht in jedem Fall problematisch sind. Vielmehr geht es um die planvolle Wahl von Abhängigkeitsgraden.
Beim Einsatz von Open-Source-Software beschränkt sich das Abhängigkeitsverhältnis lediglich auf eine “Dienstleisterabhängigkeit”. Denn der Software-Code an sich ist öffentlich. Das heißt auch, dass mit Betrieb, Weiterentwicklung oder Support unterschiedliche IT-Dienstleister beauftragt werden können, ohne die IT-Struktur der Verwaltung durch vollkommen neue Programme grundsätzlich verändern zu müssen. Dafür ist allerdings frühzeitig zu betrachten, wie “vital” ein Open-Source-Projekt ist: Wenn es sich um eine Lösung von nur einer Handvoll Entwickler handelt, ist dies problematisch für einen professionellen Betrieb in der Verwaltung. Dies gilt im Übrigen auch für proprietäre Software und ist häufig bei Anbietern von “Nischenprodukten” der Fall. Wenn hingegen eine große, durchaus auch kommerzielle, Community hinter der Lösung steht und mit dem Code arbeitet, dann ist ein nachhaltiger Einsatz in der Verwaltung möglich. Dies ist im Rahmen einer üblichen Marktrecherche zu evaluieren und kann beispielsweise aus der Aktivität in Code Repositorys wie GitHub abgelesen werden. Dabei handelt es sich um Plattformen, auf denen Open-Source-Software communitybasiert weiterentwickelt wird. Auch ein Austausch mit anderen Kommunen bietet sich dafür an.
Wie die Ausführungen gezeigt haben, gibt es gerade im Kontext der IT immer “Abhängigkeitsverhältnisse”. Das Risiko von Abhängigkeiten lässt sich beispielsweise reduzieren, wenn hinter einer Lösung eine große Community steht. Durch den Einsatz von OSS werden insbesondere Herstellereinschlüsse vermieden, sodass sie mit einer richtigen “Governance” zu mehr digitaler Souveränität beiträgt.
Natürlich ist ein Code, der veröffentlicht wird, im ersten Moment erst einmal “unsicherer”, da Sicherheitslücken einfacher entdeckt werden können. Aber gerade durch die Veröffentlichung kann dieser von einer großen Community umfänglich getestet und Sicherheits-Reviews unterzogen werden, was ihn dann grundsätzlich sicherer macht. So wurde auch ein Sicherheitsrisiko in der Corona-Warn-App nur aufgedeckt, weil der Code ab einem gewissen Zeitpunkt öffentlich war. Dieser Fehler konnte dank einer aufmerksamen Community schnell behoben werden. Ein guter Beweis für die Sicherheit von Open-Source-Software ist, dass auch Verschlüsselungssoftware offen ist.
Sogenannte White-Hat-Hacker werden daher, beispielsweise im Rahmen von Hackathons oder sog. Bug-Bounty-Programmen, regelmäßig einbezogen, um OSS zu prüfen und für den guten Zweck zu hacken. Beispielsweise gab es hierzu das EU-Projekt EU-FOSSA, welches umfangreiche Sicherheitsaudits durch Expert*innen zum Ziel hatte. Bei Bug-Bounty- Programmen werden Preise an die “Hacker” ausgelobt, die eine Sicherheitslücke entdecken.
Der gegensätzliche Ansatz will Sicherheit durch Geheimhaltung schaffen – auch als “Security through Obscurity” bekannt.
Ein auf dem Geheimhalten des Software-Codes basierendes Sicherheitskonzept gilt unter Fachleuten als ineffektiv, weil Sicherheitsprobleme dadurch tendenziell eher versteckt als beseitigt werden. Der Einsatz von FLOSS bietet per se keine Gewähr für ein sicheres System. Er bietet in diesem Prozess jedoch bedeutende strategische Vorteile.
so das Bundesamt für Sicherheit in der Informationstechnik.
Es ist nicht von der Hand zu weisen, dass OSS manchmal Einbußen in Design und “User Experience” hat - also dem “Look & Feel” beim Arbeiten mit der Software, insbesondere dann, wenn eine Anwendung nicht regelmäßig auf einen neuen Stand gebracht worden ist und veraltete Darstellungen enthält. Das lässt sich aber keinesfalls pauschalieren: Viele bekannte Lösungen wie der Mozilla Firefox, das mobile Android-Betriebssystem oder die Content Management Systeme WordPress, Drupal und Typo3 basieren auf OSS und stehen proprietärer Software in Nichts nach beziehungsweise bieten sogar eine wesentlich umfangreichere Funktionalität.
Genau wie bei proprietärer Software, gibt es auch Open-Source-Software, die in Sachen User Experience noch Potenzial hat. Marktanbieter unterliegen hier sicherlich einem größeren Druck, da dies ein entscheidender Faktor sein kann, damit sich der potenzielle Nutzende für das Produkt entscheidet. Die “Ästhetik der Nutzung” ist in einer digitalisierten Welt von enormer Bedeutung. Es zählt häufig die letzte Nutzendenerfahrung als Maßstab – und das kann dann eben auch Amazon oder Netflix sein.
Die Aussage lässt sich so pauschal nicht treffen. Perspektivisch sollte hier aber auch im OS-Bereich zunehmend “nachjustiert” werden.
Der Code von Open-Source-Software selbst ist öffentlich. Damit ist er nach herrschender Meinung unentgeltlich. Die Software an sich unterliegt daher nicht dem Vergaberecht. Vom Beschaffungs- und Vergaberecht umfasst sind allerdings die anhänglichen Dienstleistungen wie Weiterentwicklung, Support oder Sicherheitsaudits. Es ist daher im Einzelfall zu prüfen, inwiefern das Vergaberecht auch bei Open-Source-Software anzuwenden ist. Während der „Direktdownload ohne externe Dienstleister“ vergaberechtsfrei ist, ist Vergaberecht anzuwenden, sobald externe Dienstleister ins Spiel kommen.
Dienstleistungen im Kontext von Open-Source-Software können Gegenstand von Ausschreibungsverfahren sein. Dies betrifft auch Weiterentwicklungen. Wenn OSS zielgerichtet weiterentwickelt wird, sind nicht mehr so viele Neuentwicklungen erforderlich.
Klassische Vollverträge sind tatsächlich nicht mit OSS vereinbar. Denn es gibt ja gerade keinen Anbieter, der z. B. die Überlassung abdecken kann. Diese Vertragsform ist also schlichtweg nicht erforderlich! Aber für Pflege und Wartung können auch im Open-Source-Bereich Dienstleistungs-EVB-IT Verträge abgeschlossen werden (s. o.).
Die Beschaffung der mit OSS verbundenen Dienstleistungen ist auch unter Anwendung der EVB-IT-Musterverträge möglich. Dabei sind allerdings einige Besonderheiten zu beachten. Eine gute Hilfestellung liefert die “Handreichung zur Nutzung der EVB-IT beim Einsatz von Open-Source-Software” von der OSB Alliance.
Wenn die Verwaltung die Eigenentwicklung kommerziell vermarkten würde, kann die Aussage zutreffen. Es verstößt aber nicht gegen die Wettbewerbsneutralität, wenn Anwendungen, ggf. auch in interkommunalen Entwicklergemeinschaften, selbst (weiter)entwickelt und verbreitet werden. Die Öffentliche Verwaltung sollte sogar einen Beitrag an die Community leisten und nicht nur nehmen, sondern auch zurückgeben. Dies ist ggf. auch lizenzrechtlich so vorgesehen (Stichwort “Copyleft”) und entspricht dem Gedanken “Public Money? Public Code!”.
Genau wie proprietäre Software unterliegt auch Open-Source-Software einer Lizensierung. Lizenzen sind mit Rechten verbunden. Bei Freier Software drücken diese sich in den vier Freiheiten aus - aber auch mit Pflichten. Die Pflichten sind gerade dafür da, anderen die Rechte zuzusichern. Die rechtlichen Risiken sind nicht größer als im proprietären Bereich, das Lizenzmanagement muss allerdings professioneller gestaltet werden.
Kommunen müssen sich im Rahmen der Open-Source-Governance mit dem Lizenzmanagement auseinandersetzen. Hier können auch externe Sachverständige oder Beratungsstellen, beispielsweise das sog. “Legal Network” bei der FSFE, herangezogen werden.
Auch mit Open-Source-Software lässt sich Geld verdienen! Und so gibt es auch eine wachsende Open-Source-Wirtschaft. Das Geschäftsmodell liegt hier in den Dienstleistungen, die es rund um den Einsatz von Open-Source-Software braucht. Beispiele sind Support, Weiterentwicklung, Service oder Beratung.
Open-Source-Software ist mit Geschäftsmodellen vereinbar und die damit verbundenen Dienstleistungen können auch kommerziell angeboten werden. Häufig sind diese Geschäftsmodelle gerade in KMU anzutreffen. Sie werden mit Open-Source-Software konkurrenzfähig, was gut für die Wirtschaft ist.
Beim “Verstehen” geht es insbesondere um den Zugang zu Information und Wissen, der bei öffentlicher Software Teil des demokratischen Selbstverständnisses ist (“Public Money? Public Code!”). Auch wenn die Kommune in ihrer Rolle als Nutzerin den Quellcode nicht selbst verstehen kann, besteht die Chance, dass in der Community von “sachverständigen Dritten” die Sicherheit der Software geprüft und Sicherheitslücken entdeckt werden.
Der Sinn eines öffentlichen Codes zielt nicht allein darauf ab, dass der Nutzende, beispielsweise die Verwaltung, ihn verstehen kann. Es geht insbesondere darum, den Code einer breiten Community zugänglich zu machen, die ihn in der Rolle eines „unabhängigen sachverständigen Dritten“ prüfen kann.
Es gibt zahlreiche Unternehmen, die Geschäftsmodelle auf Basis von Open-Source-Software entwickelt haben. Sie bieten mit OSS verbundene Dienstleistungen wie Weiterentwicklungen, Support oder Services an. Teilweise wird Open-Source-Software auch mit weiteren Features versehen und zusätzlich proprietär lizenziert. Dann handelt es sich nicht mehr um gänzlich freie Software. Dies ist häufig, nicht immer, bei sogenannten „Enterprise Editions“ von Software-Lösungen der Fall.
Der wohl beste Beweis für die kommerzielle Lukrativität von Open Source ist der größte Verkauf eines Software-Unternehmens in der Geschichte: IBM kaufte 2019 das Open-Source-Unternehmen Red Hat für eine Summe von rund 34 Milliarden Dollar.
Open-Source-Software kann mit Geschäftsmodellen verbunden werden. Diese beinhalten dann nicht die Lizenzierung, sondern die Dienstleistungen rund um den Einsatz von OSS.
Eine Vielzahl von Freie-Software-Projekten geht auf die Initiative von Freiwilligen zurück. Dass der Code ausschließlich von Hobbyprogrammierer*innen stammt, ist trotzdem ein Vorurteil. Viele Beitragende im Bereich der Freien Software sind hochqualifizierte IT-Profis.
Dieses Zitat drückt alles aus: “Community” ist nicht gleichzusetzen mit “unprofessionell”. Ganz im Gegenteil! Hinter öffentlichem Code stecken regelmäßig gefragte Expert*innen und darüber hinaus auch große, weltweit agierende Unternehmen. Innovation entsteht in diesem Bereich gerade durch ein Open-Source-Ökosystem, das global auf Fachwissen zurückgreift.
Dabei handelt es sich um ein Vorurteil. Dieses ist gerade im Kontext der Zusammenarbeit mit der Open-Source-Community abzulegen. Es gehört daher auch zu einer Open-Source-Governance Community bzw. ihre Funktionsweise zu kennen und sie zu unterstützen.
https://www.kgst.de/dokumentdetails?path=/documents/20181/5616949/B-5-2021_Open-Source.pdf/325cead0-bd83-9286-faf5-a3682d0cf677 ↩︎
https://www.mz.de/lokal/bitterfeld/hacker-angriff-landkreis-anhalt-bitterfeld-ruft-den-katastrophenfall-aus-3202185 ↩︎
https://blog.jakobs.systems/pdf/20210710-kgst-bericht-oss.pdf ↩︎