Öffentlicher Sektor
(Quelle: PwC "Open-Source-Software-Studie 2017")
Auch wenn die Nutzung quelloffener Lösungen in der Privatwirtschaft inzwischen doch zum Standard geworden ist, so sieht es in der öffentlichen Verwaltung immer noch ganz anders aus. Hier wird Open-Source-Software lediglich punktuell, nicht aber strategisch und daher in nicht nennenswertem Umfang eingesetzt, wie Peter Ganten berichtet, Vorstandsvorsitzender der Open Source Business Alliance und Geschäftsführer des Open-Source-Spezialisten Univention.
In der Tat haben mehrere EU-Staaten - darunter Bulgarien, Frankreich, Großbritannien, Italien, Schweden und Spanien, um nur einige Beispiele zu nennen -, schon längst Bestimmungen erlassen, um die Einführung und die Nutzung von Open-Source-Software in öffentlichen Einrichtungen zu erleichtern. In Deutschland dagegen gab es bisher nur vereinzelte Initiativen und die sind oft auch noch gescheitert. Man denke nur an die einst beispielgebende Umstellung der IT der Stadt München auf Linux, die nach rund einem Jahrzehnt nun gerade wieder rückgängig gemacht wird.
„Sowohl im Vergleich mit den Wirtschaftsunternehmen in Deutschland, aber auch mit der öffentlichen Verwaltung in anderen EU-Ländern oder den USA hinkt die deutsche Verwaltung beim Einsatz von Open-Source-Software und allgemein in der
Digitalisierung sehr hinterher“, resümiert Peter Ganten von der Open Source Business Software Alliance.
Fachwissen fehlt immer noch
Hinter dem Scheitern vieler Open-Source-Projekte im öffentlichen Bereich steckt oft eine falsche Erwartungshaltung. Open-Source-Software mag an sich kostenlos sein, dies bedeutet jedoch nicht, dass deren Einführung ebenfalls ohne nennenswerte Kosten erfolgen könnte. „Man muss beispielsweise viel auf der Integrationsebene machen, alle nötigen Vorlagen anpassen und dazu noch die ganze Verwaltung darauf umstellen“, erläutert Björn Böttcher. „Dieser Aufwand wird häufig unterschätzt.“
Das allein ist allerdings noch keine hinreichende Erklärung dafür, warum die öffentliche Verwaltung beim Einsatz von Open Source so deutlich hinter der Privatwirtschaft oder dem öffentlichen Bereich anderer EU-Länder zurückbleibt. Das liegt vielmehr daran, so die Beobachtung von Peter Ganten, dass die immanenten Vorteile von Open-Source-Software - Transparenz, Anpassungsfähigkeit und Herstellerunabhängigkeit – bei den Ausschreibungen keine Berücksichtigung finden.
Außerdem haben viele Entscheider in den Ministerien und Behörden immer noch ein falsches Bild von Open Source. „Es herrscht dort die weit verbreitete Vorstellung von einer kostenlosen Community-Software ohne Serviceleistungen, die externe Entwickler in ihrer Freizeit zusammenstellen“, stellt Frank Termer von Bitkom fest. Darum komme für viele Open Source grundsätzlich nicht infrage.
Die meisten Hindernisse in der öffentlichen Verwaltung lassen sich auf das immer noch mangelnde oder sogar fehlende Fachwissen im Umgang mit Open Source zurückführen. In diesem Zusammenhang könnte der Staat wesentlich mehr Unterstützung bieten. Vor allem in den Behörden und in Schulen, so sieht es Andreas Nemeth von der Deutschen Telekom, müssten Open-Source-Lösungen gefördert werden, um eine Monopolisierung durch kommerzielle Software-Anbieter zu vermeiden.
Außerdem ist es aus seiner Sicht auch aus Sicherheitsgründen sinnvoll, gerade im öffentlichen Bereich auf Open Source zu setzen. Denn quelloffene Software böte hier den entscheidenden Vorteil, dass mögliche Sicherheitslücken und sogenannte Backdoors von der Community schnell entdeckt und beseitigt würden. „So kann der Staat sicherstellen, dass die sicherheitskritischen Systeme wirklich sicher sind“, betont Andreas Nemeth.
Auch aus diesem Grund muss die Beschaffung von Software für öffentliche Stellen erleichtert werden. So fordert Peter Ganten, dass das Kriterium „Open Source“ genauso wie Preis und Funktionsfähigkeit von Software in die Bewertungskriterien der Beschaffung eingehen sollte.
Der Digitalverband Bitkom setzt sich ebenfalls dafür ein, Open-Source-Software und proprietäre Software auf Augenhöhe zu behandeln und Rahmen- und Beschaffungsverträge so zu gestalten, dass sie die Beschaffung von Open Source in Behörden und Ministerien erleichtern.
Lizenzen mit strengem Copyleft-Effekt |
Jede Software, die auf einer derartig lizenzierten Open-Source-Komponente aufbaut, muss ebenfalls als Open Source verbreitet werden. So wird sichergestellt, dass jeder, der von einem solchen Programm profitiert, seine Weiterentwicklungen an die Entwicklergemeinschaft zurückgibt |
GNU General Public License
(GNU GPL) |
Diese Lizenz gilt für jede Weiterentwicklung des Quellcodes. Das bedeutet jedoch nicht, dass der Quellcode für jeden öffentlich gemacht werden muss, sondern lediglich für die Programmnutzer. Außerdem muss die modifizierte Version des Quellcodes nicht außerhalb des Unternehmens oder der Organisation veröffentlicht werden, solange sie nur intern benutzt wird |
GNU Affero General
Public License |
Gilt als Erweiterung der GNU GPL und ist für Software vorgesehen, die nicht zum Herunterladen zu Verfügung gestellt, sondern lediglich als Service über ein Netzwerk verwendet wird. Jeder Nutzer der Software unter dieser Lizenz erhält demnach das Recht auf den Zugang zu ihrem Quellcode |
Lizenzen mit beschränktem Copyleft-Effekt |
Hier erstreckt sich der Copyleft-Effekt in der Regel nur auf die eigentliche Open-Source-Software oder -Komponente. Der restliche Code kann unter einer proprietären Lizenz verteilt werden |
Mozilla Public License (MPL) |
Der Quellcode aller Dateien unter dieser Lizenz und aller Änderungen an diesen Dateien muss ebenfalls unter MPL verbreitet werden. Die hinzugefügten Dateien können auf beliebige Art lizenziert werden, solange der MPL-Code und der proprietäre Code separat gehalten werden. Die MPL wird nicht nur für die Mozilla-Produkte verwendet, sondern ist zum Beispiel auch in Libre Office und im Browser Tor enthalten |
GNU Lesser General
Public License (GNU LGPL) |
Diese Lizenz ist für Programmbibliotheken vorgesehen und setzt lediglich voraus, dass die Bibliothek selbst und alle ihre Änderungen der LGPL unterliegen. Insofern muss dem Anwender nur der ursprüngliche oder modifizierte Code dieser Bibliothek zur Verfügung gestellt werden, jedoch nicht der komplette Quellcode der Software |
Lizenzen ohne Copyleft-Effekt |
Diese Lizenzen erlauben es, Änderungen an der Original-Software unter beliebige Lizenzen zu stellen, ganz gleich ob als Open-Source-Software oder als proprietäre Software |
MIT-Lizenz |
Diese aus dem Massachusetts Institute of Technology stammende Lizenz erlaubt sowohl Änderungen am Quellcode als auch dessen freie Weiterverbreitung unter der Bedingung, dass die Urheberrechte und Haftungsausschlüsse in der Lizenz erhalten bleiben. Auch bekannt als X- oder X11-Lizenz |
New BSD License |
Diese Lizenz enthält die gleichen Bedingungen wie die MIT-Lizenz. Zusätzlich beinhaltet sie eine Nicht-Attributionsklausel, die erfordert, dass Entwickler eine ausdrückliche Genehmigung einholen, bevor sie den Namen des Erstellers verwenden, um abgeleitete Produkte zu bewerben. Auch 3-Klausel-BSD-Lizenz genannt |
Apache-2.0-Lizenz |
Die Apache-2.0-Lizenz enthält strenge Regeln für Umverteilungsrechte. So müssen Entwickler beispielsweise jegliche Änderungen des Quellcodes explizit erwähnen. Alle Urheberrechts-, Patent- und Attributionshinweise der Lizenz müssen beibehalten werden. Die Lizenz legt zudem ausdrücklich die Bedingungen für die Erteilung von Patentrechten fest, die in den Lizenzen BSD, Apache 1.1 und MIT nicht enthalten sind |
