1.
Geltungsbereich ^
Das EMBAG gilt für die zentrale Bundesverwaltung, also die Departemente des Bundes und die Bundeskanzlei sowie die dazugehörigen Generalsekretariate und Bundesämter (Art. 2 Abs. 1 EMBAG i.V.m. Art. 7 der Regierungs- und Verwaltungsorganisationsverordnung RVOV). Sofern der Bundesrat nicht eine Ausnahme vorgesehen hat, besteht besteht die OSS-Pflicht auch für die dezentrale Bundesverwaltung, also diejenigen Bundesbehörden mit eigener Rechtspersönlichkeit (z.B. Aufsichtsorgane, Stiftungen, Hochschulen oder Forschungsinstitute (Art. 2 Abs. 2 EMBAG i.V.m. Art. 7a RVOV).
Für die Kantone gilt das Gesetz mangels Bundeskompetenz nicht, ihnen steht es aber frei, eigene Normen zu erlassen.1
2.
Was bezweckt Art. 9 EMBAG? ^
Die neue Norm verspricht einen gesamtgesellschaftlichen Mehrwert durch die transparente und gemeinschaftliche Nutzung von mit öffentlichen Geldern finanzierten Softwarelösungen («Public Money, Public Code»). Im Weiteren beinhaltet OSS ein partizipatives Element, weil sie eine aktive Teilnahme und Mitgestaltung bei der Pflege und Weiterentwicklung nicht nur ermöglicht, sondern aktiv fördert.2 Durch die Freigabe können zudem insbesondere bewährte Softwarelösungen von Behörden getreu dem Motto «einmal entwickeln – mehrfach nutzen» auch von einer anderen Behörde übernommen und genutzt bzw. adaptiert werden.
3.
Pflicht zur offenen Lizenzierung ^
Nach Art. 9 Abs. 1 und 2 legen die dem EMBAG unterstehenden Bundesbehörden den Quellcode von Software offen, die sie zur Erfüllung ihrer Aufgaben entwickeln oder entwickeln lassen. Sie erlauben jeder Person, die Software zu nutzen, weiterzuentwickeln und weiterzugeben und sie erheben keine Lizenzgebühren.
Diese Nutzungsrechte müssen grundsätzlich gegenüber allen eingeräumt werden. Auch eine Beschränkung auf bestimmte Einsatzbereiche (z.B. nur nicht-kommerzielle Nutzung) ist nicht mit dem Grundgedanken von OSS vereinbar.3
4.
Ausnahmen ^
Die OSS-Pflicht gilt sodann dann nicht, wenn eine Offenlegung des Quellcodes und die freie Einräumung der Nutzungsrechte bestehende «Rechte Dritter» verletzen würde (erster Ausnahmetatbestand). Solche Rechte sind primär Immaterialgüterrechte und Rechte, die sich aus Lizenzen ergeben und das geistige Eigentum der Softwarentwickler*innen schützen. Vorbestehende proprietäre Lizenzen beispielsweise erlauben keine Offenlegung des Quellcodes und somit keine OSS-Freigabe. Deshalb gilt die OSS-Pflicht auch nur für Neuentwicklungen.
Weit weniger klar ist der zweite Ausnahmetatbestand, der bei «sicherheitsrelevanten Gründen» greift. Er dürfte auf Bedenken zurückzuführen sein, dass die Offenlegung des Quellcodes bei OSS Einblicke in mögliche Angriffspunkte bieten könnten, die durch eine Geheimhaltung des Quellcodes und eine eingeschränkte Nutzung abgewehrt werden können («Security by Obscurity»). Dieser Ansatz wird jedoch kritisiert,5 weil die Sicherheit einer Software im Wesentlichen nicht von der Geheimhaltung des Quellcodes abhängt, sondern von anderen Faktoren wie der Qualität der Programmierung und der verwendeten Algorithmen.
5.
Lizenzen ^
Das EMBAG stellt es den Behörden frei, unter welche OSS-Lizenz sie ihre Software stellen. Die Lizenzen sind privatrechtlicher Natur (Art. 9 Abs. 3 EMBAG)6, und es sind nach Möglichkeit international etablierte Lizenzen zu wählen (Abs. 4). Die Frage, welche Lizenzen als «international etabliert» gelten und welche nicht, ist nicht abschliessend geklärt. Die üblichen Verdächtigen wie MIT, Apache oder GPL dürften jedoch ohne weiteres darunter fallen.
Aus unserer Sicht ist sodann die Verwendung von Lizenzen mit Copyleft je nach Kontext sinnvoll. Zu bedenken ist zwar einerseits, dass zwar die Freiheit einer wirtschaftlichen Nutzung des Codes durch das Copyleft eingeschränkt wird, andererseits liegt das Ziel des Copyleft darin, den einmal freigegebenen Code frei zu halten, um eine Art Tauschverhältnis zu etablieren: Wer sich am öffentlich verfügbaren «Pool» von OSS bedient, soll seine Ergebnisse auch wieder in diesen Pool zurückleiten, sodass die Community wieder profitiert und die Software nachhaltig gewartet und weiter entwickelt wird.7 Dieses Tauschverhältnis ist je nach Anwendungsfall zentral oder tritt in den Hintergrund. Steht es im Zentrum, ist eine Lizenz mit Copyleft vorteilhaft.
6.
Fazit ^
Ursprünglich durch Rechtsunsicherheiten und Vorbehalte geprägt, hat die Diskussion über OSS in Behördensoftware über die letzten Jahre hinweg zu einem Umdenken geführt. Das EMBAG markiert dabei einen Wendepunkt, indem es OSS als Standard für Behördensoftware in Art. 9 EMBAG kodifiziert.
- 1 So geschehen im Kanton Bern mit Art. 28 DVG. Im Kanton Zürich befinden sich entsprechende Regeln in Ausarbeitung; KR-Nr. 65/2019.
- 2 Vgl. statt vieler Thomas Poledna/Simon Schlauri/Samuel Schweizer, Rechtliche Voraussetzungen der Nutzung von Open-Source Software in der öffentlichen Verwaltung, insbesondere des Kantons Bern, Berlin/Bern 2017, tinyurl.com/yzammywm, N 50 ff.
- 3 Dies im Gegensatz zu bestimmten «Creative-Commons»-Lizenzen, welche die kommerzielle Nutzung von Werken verbieten können; vgl. Simon Schlauri, Open-Source-Software im neuen Bundesgesetz über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben (EMBAG), 22. August 2023, tinyurl.com/2nxnzvuf.
- 4 Botschaft zum EMBAG, BBl 2022 804, 119.
- 5 Vgl. Schlauri (Fn. 3).
- 6 Weiter besagt Art. 9 Abs. 3 auch, dass im Streitfall ein Zivilgericht und nicht wie beispielsweise bei einem Zuschlag im öffentlichen Beschaffungswesen ein Verwaltungsgericht zuständig ist.
- 7 Vgl. Wolfgang Straub, Softwareschutz – Urheberrecht, Patentrecht, Open Source, 2. Aufl. Zürich 2024, Rz. 758; Till Jaeger/Axel Metzger, Open-Source-Software, 5. Aufl. München, 2020, Rz. 420 ff.; Matthias Stürmer, How Firms Make Friends: Communities in Private-Collective Innovation, Introductory chapter of the doctoral dissertation, 2009, tinyurl.com/3ycttnsf, 4.
