Jusletter IT

Während Open Source Software (OSS)¹ in der Privatwirtschaft etabliert ist, entwickelt die öffentliche Verwaltung immer noch vorwiegend proprietäre Software (Poledna, Schlauri & Schweizer, 2017, Rz. 483 oder generell OS-Studie Schweiz 2021). Dies ist wohl darauf zurückzuführen, dass die Frage, ob Behörden die von ihnen entwickelte und genutzte Software (Behördensoftware) unter eine Open-Source-Lizenz (OSS-Lizenz) stellen dürfen oder gar sollen, in der Schweiz lange mit Rechtsunsicherheit behaftet war.

Die Diskussion über OS-Behördensoftware ist über 12 Jahre alt (Stürmer 2023). Sie geht auf die Gerichtssoftware «Openjustitia» zurück, die das Bundesgericht unter eine OSS-Lizenz stellte, um anderen Gerichte deren kostenlose Nutzung zu ermöglichen (Netzwoche 2014). Dies warf die daraufhin kontrovers diskutierte Frage auf, ob OS-Behördensoftware zu Konkurrenzierung der Privatwirtschaft und zu Wettbewerbsverzerrungen führen würde. Im Rahmen dieser Kontroverse wurden mehrere politische Vorstösse (siehe z.B. Interpellation Weibel 12.4247, Postulate Glättli 14.4275 und Graf-Litscher 14.3532) und zwei Rechtsgutachten veröffentlicht: Das erste Gutachten äusserte sich skeptisch zur Notwendigkeit von OS-Behördensoftware, befürwortete die «Bildung einer Closed Community» und verlangte eine gesetzliche Grundlage auf Verfassungsstufe (Müller & Vogel, S.30). Das zweite Gutachten hingegen hob die Vorteile von OSS hervor, stellte diese in einen staatspolitischen Kontext und analysierte die Notwendigkeit einer gesetzlichen Grundlage differenzierter (Poledna, Schlauri & Schweizer Rz. 281 und Rz. 482).

Diese Entwicklungen führten schliesslich zu einem Umdenken, welches die Bedenken in Bezug auf die Wettbewerbsneutralität von OSS in den Hintergrund rücken liessen. Es stellte sich immer mehr die Erkenntnis ein, dass OSS auch bzw. vor allem für die öffentliche Verwaltung aus Gründen der Effizienz, Transparenz und Inklusivität gewichtige Vorteile gegenüber proprietärer Software hat. Das 2021 verabschiedete «Bundesgesetzes über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben» (EMBAG) besiegelte schliesslich den Paradigmenwechsel und führte zu einer Kodifizierung von OSS als Standard für Behördensoftware in Art. 9 EMBAG.

Der vorliegende Beitrag beleuchtet diese neue Rechtsnorm, die den unterstellten Behörden eine Pflicht zur OSS-Lizenzierung gewisser Software auferlegt (OSS-Pflicht). Im Folgenden analysiert der Beitrag den Umfang und die Schranken der neuen OSS-Pflicht in Art. 9 EMBAG, die Ausnahmen davon sowie die damit einhergehenden Spielräume. Dabei soll auch auf die Frage eingegangen werden, was die OSS-Pflicht in Art. 9 EMBAG für die öffentliche Beschaffung von Behördensoftware bedeutet.

Das EMBAG verfolgt zwei Ziele (Botschaft EMBAG, S. 6 und S. 7): Erstens will es eine Rechtsgrundlage schaffen für die digitale Transformation des Bundes. Deshalb wird das Gesetz umgangssprachlich auch als «eGov-Gesetz» bezeichnet. In diesem Sinne normiert das EMBAG nebst OSS in Art. 9 EMBAG auch die Veröffentlichung von Verwaltungsdaten (Open Government Data, Art. 10 EMBAG) oder die Festlegung von Standards durch den Bund (Art. 12 EMBAG). Zweitens zielt das Gesetz darauf hin, die Zusammenarbeit zwischen den verschiedenen föderalen Ebenen zu verbessern.²

OSS spielt zur Erreichung beider Ziele eine wichtige Rolle. Sie verspricht einen gesamtgesellschaftlichen Mehrwert durch die transparente und gemeinschaftliche Nutzung von mit öffentlichen Geldern finanzierten Softwarelösungen («Public Money, Public Code»). Zudem ermöglicht die Übernahme bestehender OSS-Lösungen Effizienzgewinne und somit Kosteneinsparungen für die öffentliche Hand. 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 (vgl. statt vieler Poledna, Schlauri & Schweizer, 2017; ISB, 2019 und Straub, 2024).³

Auch in Bezug auf die verstärkte Zusammenarbeit zwischen den Behörden kann OSS eine wichtige Rolle spielen: Durch die Freigabe können 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 kann. Der sog. «Einer-für-alle-Ansatz» (EfA) bedeutet, dass z.B. ein Kanton (oder eine Gemeinschaft von Kantonen) eine Leistung zentral entwickelt und betreibt und diese anschliessend anderen Kantonen oder Gemeinden zur Verfügung stellt. Die Kosten werden geteilt (dazu Bundesministerium des Inneren und für Heimat, 2023; Schlauri, 2023).

Art. 9 EMBAG statuiert die Pflicht, von Behörden entwickelte Software grundsätzlich unter eine OSS-Lizenz zu stellen. Vorbehalten bleiben die im Gesetz umschriebenen Ausnahmen (Art. 9 Abs. 2 EMBAG, vgl. sogleich, Ziff. 3.4). Somit schafft Artikel 9 nicht nur Rechtssicherheit für die Freigabe von OSS durch Behörden, sondern geht einen Schritt weiter und verankert OSS gar als Pflicht für Behördensoftware.

Weil der Gesetzeswortlaut von der ursprünglich fakultativen «Kann-Bestimmungen» abgekommen ist und nun einen obligatorischen Charakter aufweist, wird vorliegend von einer eigentlichen OSS-Pflicht gesprochen.

Art. 9 Abs.1. und 2 EMBAG verankern den OS-Grundsatz, bzw. beschreiben, welcher Pflicht die unterstellten Behörden nachzukommen haben. Abs. 1 bezieht sich auf die Offenlegung des Quellcodes:

Die diesem Gesetz unterstehenden Bundesbehörden legen den Quellcode von Software offen, die sie zur Erfüllung ihrer Aufgaben entwickeln oder entwickeln lassen, (…). (Art. 9 Abs. 1, erster Teilsatz)

Die Offenlegung des Quellcodes, auch Sourcecode genannt (d.h. der für Menschen lesbare Text eines Computerprogrammes; vgl. etwa Straub, 2024, Rz. 7), ist der Grundstein des OSS-Gedankens, denn ohne diese Offenlegung kann die Software nicht insbesondere nicht durch Dritte angepasst werden (für eine detailliertere Schilderung vgl. ISB, 2019, S. 9). OSS unterscheidet sich von «Closed Source Software» gerade im Wesentlichen darin, dass Open Source Lizenzen grundsätzlich allen die urheberrechtlichen Nutzungsrechte am Quellcode einräumen (Poledna, Schlauri & Schweizer, 2017, Rz. 17 m.H.).

In einem zweiten Schritt spezifiziert Absatz 2 einen weiteren Grundsatz von OSS, namentlich die kostenlose Nutzung, Weiterentwicklung und Weitergabe der Software ohne Zweckbindung:

Sie erlauben jeder Person, die Software zu nutzen, weiterzuentwickeln und weiterzugeben, und erheben keine Lizenzgebühren. (Art. 9 Abs. 2 EMBAG)

Die kostenlose Nutzung, Weiterentwicklung und Weitergabe ist wesentliches Merkmal von Open Source Software (früher deshalb auch «free software» genannt, vgl. Poledna, Schlauri & Schweizer, 2017, Rz. 16): Diese zeichnet sich ja eben genau dadurch aus, dass Dritten die genannte Nutzung der Software erlaubt wird, und dabei keine Lizenzgebühren erhoben werden (wobei für die Weitergabe oder für das Kopieren Gebühren erhoben werden können, vgl. z.B. Botschaft EMBAG, S. 26 oder Straub, 2024, Rz. 717 mit Hinweis auf Ziff. 4 Abs. 2 GLP v3). Dabei ist wichtig zu betonen, dass diese Nutzungsrechte gemäss Art. 9 EMBAG grundsätzlich gegenüber allen eingeräumt werden müssen, und sich nicht auf spezifische Personen(gruppen) beschränken dürfen, wie es bei gebührenpflichtigen Lizenzmodellen der Fall ist. Auch eine Beschränkung auf bestimmte Einsatzbereiche (z.B. nur nicht-kommerzielle Nutzung) ist nicht mit dem Grundgedanken von OSS vereinbar (Schlauri, 2023).⁴

Als erstes stellt sich die Frage, welche Behörden OS-pflichtig werden: 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). Während der Entwurf des EMBAG die dezentrale Bundesverwaltung von der Unterstellung befreien wollte, verpflichtet Art. 2 Abs. 2 EMBAG in der finalen Version auch die dezentrale Bundesverwaltung (Art. 7a RVOV), also diejenigen Bundesbehörden mit eigener Rechtspersönlichkeit (z.B. Aufsichtsorgane, Stiftungen, Hochschulen oder Forschungsinstitute). Der Bundesrat kann allerdings Ausnahmen vorsehen; der Bereich Digitale Transformation und IKT-Lenkung der Bundeskanzlei veröffentlicht dazu eine Liste der Bundesbehörden, die nach Absatz 1 dem EMBAG unterstellt sind, sowie der für sie geltenden Bestimmungen des EMBAG (Art. 1 Abs. 2 EMBAV).

Dabei ist wichtig zu betonen, dass das EMBAG nur für die Behörden des Bundes gilt. Den kantonalen oder kommunalen Behörden kann es mangels Bundeskompetenz im Bereich Digitalisierung keine Verpflichtungen auferlegen, auch wenn dies gelegentlich von den Vernehmlassungsteilnehmenden gefordert wurde (vgl. z.B. Vernehmlassungsantworten der SP oder der GLP, Vernehmlassungsbericht, S. 7).

Den Kantonen steht es selbstverständlich frei, eigene Gesetzgebungen zu implementieren zu implementieren. So hat der Kanton Bern beispielsweise seit 2022 ein «Gesetz über die digitale Verwaltung» (DVG, BSG 109.1), das in Artikel 26 ebenfalls den Grundsatz von OSS und Open Government Data (OGD) «by default» verankert. In Zürich liess zudem der Regierungsrat auf ein an die Berner Vorlage angelehntes Postulat hin verlauten, bei noch zu erarbeitenden Vorgaben für die Applikations-, Daten- und Technologiearchitektur von Software sollten bezüglich des Themas OSS die im Postulat geforderten Massnahmen angemessen berücksichtigt werden (Regierungsrat Zürich, 5). Ansonsten kennen noch wenige Kantone eine OSS-Regelung. Wie Straub anmerkt, könnten sich aber auch Kantone bei der Auslegung (oder Ausgestaltung) ihres Rechts bezüglich der Verwendung von Open Source Software am EMBAG orientieren (Straub, 2024, Rz. 1171).

Weiter umfasst der Wortlaut des EMBAG nicht alle Software, sondern nur diejenige Software, die eine Behörde a) «entwickelt oder entwickeln lässt» und b) die «der Erfüllung einer öffentlichen Aufgabe» dient.

Als erstes Kriterium stellt der Wortlaut «entwickeln oder entwickeln lassen» klar, dass nur Neuentwicklungen unter die OSS-Pflicht fallen; also Software, die der Bund einerseits selbst neu entwickelt/programmiert, oder andererseits auf Markt von privaten Softwarefirmen neu entwickeln lässt. Weiterentwicklungen bereits bestehender Behördensoftware müssen nicht als OSS lizenziert werden (was rechtlich und technisch gesehen wohl gar nicht möglich wäre, zumindest sofern der Bund sich nicht die Rechte hat abtreten lassen oder im Fall von Eigenentwicklungen originäre Rechte erworben hat). Ebenfalls nicht unter die OSS-Pflicht fällt der Kauf bestehender Software, die «von Dritten unverändert erworben wird» (Botschaft EMBAG, S. 119). Somit steht es den Behörden weiterhin offen, eine proprietäre Software «von der Stange» zu kaufen.

Die neue Regelung hat auch beschaffungsrechtliche Implikationen: Diejenige Software, die eine Bundesbehörde auf dem privaten Markt einkauft oder entwickeln lässt, untersteht den Regeln des Bundesgesetzes über das öffentliche Beschaffungsrecht (BöB). Das bedeutet, dass sich die jeweilige Beschaffungsbehörde für Neuentwicklungen zumindest ein Recht des Bundes zur Unterlizenzierung als OSS in der Ausschreibung (und idealerweise auch im Vertragsentwurf) vorzubehalten hat. Sofern die Behörde – wie beispielsweise gemäss Art. 24.1.1 der AGB der SIK vorgesehen – die Rechte an den Arbeitsergebnissen ohnehin an den Bund abtreten lässt, entfällt dies aber, weil die Behörde ohnehin frei ist, die Ergebnisse als OSS zu lizenzieren. Auch Erfahrung im Bereich von OSS könnte als Eignungs- oder Zuschlagskriterium verlangt werden. Die öffentliche Beschaffung von bereits bestehender Software ist nicht von der OSS-Pflicht erfasst und erfordert keine entsprechenden Kriterien in der Ausschreibung.

Dabei ist wichtig zu betonen, dass die Frage welche Software genau beschafft oder entwickelt werden soll und ob diese selbst oder extern entwickelt werden soll («Make-or-Buy»-Entscheid) weiterhin im freien Behördenermessen liegt und von der OSS-Pflicht in Art. 9 EMBAG nicht tangiert wird (vgl. auch Straub, 2024, Rz. 722; Poledna, Schlauri & Schweizer, Rz. 342 ff.).

Das zweite Kriterium, «zur Erfüllung öffentlicher Aufgaben», ist weniger klar. Grob können all diejenigen Aufgaben zu den «öffentlichen Aufgaben» gezählt werden, welche die jeweilige Behörde aufgrund ihres gesetzlichen Auftrags wahrnimmt.⁵ Was genau zur öffentlichen Aufgabe der jeweiligen Behörde gehört, ergibt sich in der Regel aus dem Gesetz, bzw. kann aus diesem abgeleitet werden. Die Rechtsprechung im Kontext des öffentlichen Beschaffungswesens zeigt,⁶ dass dieser Begriff breit gefasst ist und im Zweifelsfall von einer öffentlichen Aufgabe ausgegangen werden muss (vgl. BGE 144 II 177 mit Referenzen oder WTO Appellate Body Report Canada – Certain Measures Affecting the Renewable Energy Generation Sector/Measures Relating to the Feed-in Tariff Program vom 6. Mai 2013, para. 5.58).

Von den öffentlichen Aufgaben abzugrenzen sind «kommerzielle Dienstleistungen». Dazu gehören Dienstleistungen, die eine Behörde im Ausnahmefall gegen Entgelt wahrnehmen kann, obwohl dies nicht direkt der Erfüllung ihrer öffentlichen Aufgaben dient (so z.B. auch die «ergänzenden Dienstleistungen» i.S.v. Art. 9. Abs. 5 EMBAG, siehe nachstehend Ziff. 5). Kommerzielle Dienstleistungen durch Behörden sind aufgrund des Legalitätsprinzips und der Wettbewerbsneutralität nur dann möglich, wenn dies in der jeweiligen gesetzlichen Grundlage verankert ist, da sonst die Gefahr von Wettbewerbsverzerrungen besteht.⁷

Somit ergibt sich die Frage, ob die jeweilige Software der Erfüllung öffentlicher Aufgaben dient, oder eher dem Bereich der kommerziellen Dienstleistungen zuzuordnen ist aus der Analyse der jeweiligen gesetzlichen Grundlage der Behörde.

Schliesslich muss die zu entwickelnde Software zur öffentlichen Aufgabe der jeweiligen Behörden in einem kausalen Zusammenhang stehen, also deren Erfüllung dienen.

Art. 9 EMBAG sieht zwei Ausnahmetatbestände vor, die eine unterstellte Behörde von der OSS-Pflicht befreien. So stellt Art. 9 Abs. 1 EMBAG die Offenlegung des Quellcodes unter folgenden Vorbehalt:

Die diesem Gesetz unterstehenden Bundesbehörden legen den Quellcode von Software offen, die sie zur Erfüllung ihrer Aufgaben entwickeln oder entwickeln lassen, es sei denn die Rechte Dritter oder sicherheitsrelevante Gründe würden dies ausschliessen oder einschränken.

Der von den Räten verabschiedete Wortlaut sieht nur zwei Ausnahmetatbestände vor: vorbestehende Rechte Dritter und sicherheitsrelevante Gründe. Bemerkenswert ist, dass die Entwurfsfassung von Art. 9 EMBAG die Ausnahmen noch sehr viel offener formulierte: Die Norm beschränkte den OSS-Grundsatz auf diejenigen Fälle, in denen die Offenlegung des Quellcodes «sinnvoll und möglich ist». Dieser schwammig formulierte Vorbehalt, der den unterstellten Behörden ein grosses Ermessen eingeräumt hätte, wurde in der parlamentarischen Debatte in Befolgung eines Minderheitsantrages gestrichen. Diese Streichung ist zu begrüssen, da der Vorbehalt ein wahrscheinlich allzu willkommenes Schlupfloch im Gesetz dargestellt hätte, auf die Lizenzierung als OSS zu verzichten (vgl. schon Schlauri, 2023).

Die OSS-Pflicht gilt dann nicht, wenn eine Offenlegung des Quellcodes und die freie Einräumung der Nutzungsrechte bestehende «Rechte Dritter» verletzen würde. 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 (vgl. oben, Kapitel 3.3.2).

Problematisch bleiben insbesondere Fälle, in denen Software zumindest teilweise auf vorbestehenden Modulen von mit der Entwicklung beauftragten Drittunternehmen abstellt. Sofern vom Hersteller nicht das Recht erhältlich ist, auch jene Teile unter eine Open-Source-Lizenz zu stellen (was aus Nutzersicht regelmässig die einfachste Lösung sein wird), sind jedenfalls die neu entwickelten Teile der Software als OSS freizugeben. Wer diese Teile verwenden will, kann sich diesfalls zumindest um eine (kommerzielle) Lizenz des Herstellers für die vorbestehenden bemühen oder diese nachentwickeln.

Weitere «Rechte Dritter» könnten sich aus dem Datenschutzecht ergeben. Weil Software typischerweise keine personenbezogenen Daten beinhaltet, läuft die Veröffentlichung von Software-Code i.d.R. aber nicht Gefahr, Datenschutzrechte zu verletzen. Nichtsdestotrotz ist es mit zunehmender Verbreitung von OSS umso wichtiger darauf zu achten, dass nicht (absichtlich oder unabsichtlich) personenbezogene Daten (wie nicht-fiktive Beispieldaten) im Code genannte werden.

Weit weniger klar ist der zweite Ausnahmetatbestand, der sich auf «sicherheitsrelevante Gründe» bezieht. Eine rein grammatikalische Auslegung dieses Wortlauts ist zwar deutlich: gemeint sind Gründe, in denen eine Offenlegung des Quellcodes die Sicherheit gefährden würde. Doch welche Gründe das sein könnten, bleibt bislang weitgehend unbeantwortet und wurde weder in der bundesrätlichen Botschaft zum EMBAG noch in der parlamentarischen Debatte thematisiert.

Der Ausnahmetatbestand dürfte auf Bedenken zurückzuführen sein, dass die Offenlegung des Quellcodes bei OSS potenziellen Angreifenden Einblicke in die Funktionsweise der Software und 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 (vgl. Schlauri, 2023), weil die Sicherheit einer Software nicht im Wesentlichen von der Geheimhaltung des Quellcodes abhängt, sondern von anderen Faktoren wie Qualität der Programmierung und regelmässigen Updates und Patches. In diese Richtung geht auch das Argument, dass die Offenlegung des Quellcodes eine bessere Sicherheit ermöglicht, da eine grössere Gemeinschaft von Entwickelnden potenzielle Schwachstellen identifizieren und beheben kann.

Lizenzen sind privatrechtliche Vertragsinstrumente, mithilfe deren die Lizenzgeber*innen ihren Vertragspartner*innen (Lizenznehmer*innen) das Recht zur Nutzung und allenfalls Weiterentwicklung der Software einräumen. Dies wird so auch in Art. 9 Abs. 3 EMBAG wiedergegeben:

Die Rechte nach Absatz 2 werden in der Form von privatrechtlichen Lizenzen erteilt (…). (Abs. 3, erster Teilsatz)

Definitionsgemäss hat jede OSS-Lizenz den Lizenznehmer*innen das Recht zur Nutzung und Weiterentwicklung einzuräumen (vgl. dazu im Detail Straub, 2024, Kapitel 7).

Was den darüberhinausgehenden Regelungsinhalt der Lizenz anbelangt, ist dieser je nach OSS-Lizenz unterschiedlich: So erfordern einige OSS-Lizenzen wie die GNU General Public License (GPL), dass Weiterentwicklungen (sog. «abgeleitete Werke») unter denselben strengen Bedingungen weitergegeben werden müssen («Copyleft»)⁸, während andere Lizenzen weniger restriktiv sind (statt vieler, vgl. Straub, 2024; Schlauri, 2023).

Das EMBAG stellt es den Behörden frei, unter welcher OSS-Lizenz sie ihre Software stellen. Art. 9 Abs. 3 und Abs. 4 EMBAG spezifizieren lediglich, dass die jeweilige OSS-Rechte nach Abs. 2 in der Form von privatrechtlichen Lizenzen erteilt werden, die wie der Vertrag im öffentlichen Beschaffungswesen privatrechtlicher Natur sind (Abs. 3)⁹, und die nach Möglichkeit «international etabliert» sein sollen (Abs. 4):

Soweit möglich und sinnvoll sind international etablierte Lizenztexte zu verwenden. Haftungsansprüche von Lizenznehmern sind auszuschliessen, soweit dies rechtlich möglich ist. (Abs. 4)

Nur schon aus Gründen der Rechtsicherheit empfiehlt es sich, international etablierte Lizenztexte zu verwenden,¹⁰ da diese den Entwickler*innen und Nutzenden gleichermassen bekannt sind. Zudem fördern etablierte Lizenzen die globale Zusammenarbeit innerhalb der OSS-Community, weil sie weit verbreitet und verstanden sind, was die Integration und Weiterentwicklung von Projekten erleichtert. Schliesslich gewährleisten solche Lizenzen die langfristige Verfügbarkeit und somit die Nachhaltigkeit der Software, da sie die Weitergabe und Nutzung unter klaren Bedingungen sichern. Eigene oder lokale, international nicht etablierte Lizenzen könnten die internationale Community abschrecken und sie daran hindern, an der Weiterentwicklung mitzuwirken.

Ebenfalls aus Gründen der Rechtsicherheit empfiehlt es sich, die Wahl der Lizenzen bereits als Teil der Projektinitialisierungsphase zu klären und in denjenigen Fällen, in denen die Entwicklung extern in Auftrag gegeben wird, die Wahl der Lizenz in den Ausschreibungsunterlagen als technische Spezifikationen festzuhalten.

Nicht-etablierte Lizenzen können sich im Beschaffungsverfahren als Wettbewerbshindernis auswirken für Anbieter*innen, welchen eine solche Lizenz nicht bekannt ist. Bei regional etablierten Lizenzen würde sich dieser Wettbewerbsnachteil auf ausländische Anbieter*innen beschränken, was dem Diskriminierungsverbot des Government Procurement Agreements (GPA) der Welthandelsorganisation (WTO) widersprechen könnte (Art. X:2 GPA).

Aus unserer Sicht ist 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 Ziel der Verwendung von Lizenzen mit Copyleft darin, den einmal freigegebenen Code nachhaltig frei zu halten 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 (vgl. Stürmer 2009, S. 4). Dieses Tauschverhältnis ist je nach Anwendungsfall zentral, oder tritt in den Hintergrund.

Aus unserer Sicht sind daher die folgenden Grundsätze zu beachten:

• Eine Lizenz mit Copyleft ist in jedem Fall dann zu wählen, wenn vorbestehende Teile der Software schon unter Copyleft lizenziert sind. Diesfalls ist das Gesamtprojekt schon aufgrund der Lizenzbedingungen der vorbestehenden Software unter die entsprechende Lizenz zu stellen.
• Liegt das Ziel der Freigabe einer Software als Open Source in einer langfristigen, nachhaltige Verfügbarkeit der Software, setzt dies den Aufbau einer Community voraus, die auch im Sinne des genannten Tauschverhältnisses längerfristig Beiträge liefert (vgl. Stürmer 2009, S. 4). Solches ist ohne Lizenz mit strengem Copyleft kaum zu erreichen.
• Eher gegen eine Lizenz mit Copyleft spricht eine Software, welche die Basis einer digitalen Kerninfrastruktur schaffen soll (Software-Bibliotheken mit grundlegenden Funktionen). Diesfalls ist eher eine Lizenz mit schwachem Copyleft oder gar eine solche ohne Copyleft zu wählen.
• Gegen die Verwendung einer Software mit Copyleft spricht auch, wenn es schon weit verbreitete vergleichbare Produkte auf dem Markt gibt, die nicht unter Copyleft-Lizenzen stehen, weil diesfalls die Gefahr besteht, dass die durch den Bund neu veröffentlichte Software wenig genutzt wird.

Ferner statuiert Art. 9 Abs. 3 EMBAG, dass Haftungsansprüche von Lizenznehmer*innen auszuschliessen sind. So kann eine Beschaffungsbehörde ausschliessen, dass sie für Fehler haften, die sich in Weiterentwicklungen eingeschlichen haben und bei der Nutzung dieser zu Schäden führen. Bei (international) etablierten Lizenzen ist ein solcher Haftungsausschluss typischerweise bereits durch den Lizenztext abgedeckt, was wiederum für die Verwendung (international) etablierter Lizenzen spricht. Nicht vertraglich wegbedungen werden kann die Haftung für grobe Fahrlässigkeit oder Vorsatz, was in der Praxis aber wenig Relevanz aufweisen wird.¹¹

Schliesslich stellen die letzten beiden Absätze von Art. 9 EMBAG klar, dass die unterstellten Behörden auch sog. «ergänzende Dienstleistungen» im Zusammenhang mit ihrer OSS zur Verfügung stellen dürfen:

Die diesem Gesetz unterstehenden Bundesbehörden können ergänzende Dienstleistungen, insbesondere zur Integration, Wartung, Gewährleistung der Informationssicherheit und zum Support erbringen, soweit die Dienstleistungen der Erfüllung von Behördenaufgaben dienen und mit verhältnismässigem Aufwand erbracht werden können. (Abs. 5)

Als «ergänzende» Dienstleistungen¹² gelten Dienstleistungen, welche die jeweilige Behörde nicht ausschliesslich zur Erfüllung der gesetzlichen Aufgabe erbringt (die aber typischerweise damit in einem Zusammenhang stehen), die sie aber «ergänzend» dazu auf privatwirtschaftlicher Basis erbringen kann, wenn Nachfrage besteht. Da diese Art von Dienstleistungen nicht direkt vom gesetzlichen Kernauftrag der jeweiligen Behörde gedeckt ist und in einem Spannungsverhältnis zur verfassungsmässigen Wettbewerbsneutralität des Bundes steht, können Behörden diese möglicherweise nur mit einer gesetzlichen Grundlage erbringen. In Bezug auf OSS-Dienstleistungen stellt Art. 9 Abs. 5 EMBAG eine solche gesetzliche Grundlage dar.

Als Beispiel für ergänzende Dienstleistungen nennt Art. 9 Abs. 5 EMBAG die Integration oder die Wartung der entwickelten Software (für eine andere Behörde oder ein privates Unternehmen) sowie Dienstleistungen in Bezug auf die Informationssicherheit. Diese zusätzlichen Leistungen können notwendig sein, um die korrekte Implementation der Software zu gewährleisten und ihre Nutzung und Verbreitung zu fördern.

Um die Wettbewerbsneutralität des Staates zu gewährleisten, müssen die Behörden solche ergänzenden Dienstleistungen zu zumindest kostendeckendem Entgelt erbringen (9 Abs. 6 EMBAG).¹³ Ausnahmen von diesem Grundsatz der Kostendeckung sind nur dann erlaubt, wenn der Bund ein überwiegendes öffentliches Interesse an der Erbringung der ergänzenden Dienstleistung hat (z.B. zur Förderung von OSS, vgl. Botschaft EMBAG, S. 69). Kostenlos erbrachte ergänzende Dienstleistungen sind aber nur dann möglich, wenn der private Markt diese nicht anbietet (Botschaft EMBAG, S. 69).

So oder so empfiehlt es sich aus Gründen des Projektmanagements, des Vertragsrechts und wo einschlägig auch des Beschaffungsrechts, sich früh zu überlegen, welche weiteren Dienstleistungen wie Wartungs- und Supportarbeiten bei der Implementierung der Software anfallen (so auch Praxisstudie BFH, S. 43). Bei OSS gehört dazu auch die Frage, ob die betreibende Behörde genug Kapazitäten für das sog. «Community Management» hat. Falls dies nicht der Fall ist, bzw. wenn die die OSS nutzende Behörde keine Kapazitäten für die mit der Implementierung zusammenhängenden Dienstleistungen hat (also der im umgekehrten Fall als in Art. 9 Abs. 5 EMBAG beschrieben) ist zu definieren, wer diese Rolle übernehmen soll. Wenn die jeweilige Software-Lösung auf dem freien Markt eingekauft wird, können diese Leistungen auch von der Anbieterin eingefordert werden. Dies ist dann im Beschaffungsprozess jeweils in der Ausschreibung als Eignungs- oder Zuschlagskriterium festzuhalten (vgl. auch Stürmer & Koch, 2024).¹⁴

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. Dies ist ein wichtiger erster Schritt in Richtung wirtschaftlicher und digitaler Nachhaltigkeit von Behördensoftware. Die Norm kann zudem als Basis für die Umsetzung des «Einer-für-alle-Ansatzes» auch in der Schweiz darstellen, d.h. sie kann dazu beitragen, dass einmal entwickelte Software durch verschiedene Behörden (auch über verschiedene föderale Ebenen hinweg) mehrfach genutzt werden kann.

Die OSS-Pflicht im EMBAG hat auch beschaffungsrechtliche Implikationen (zumindest was Software betrifft, die nicht inhouse oder instate, sondern extern auf dem Markt entwickelt und öffentlich beschafft wird). So führt das Gesetz dazu, dass die Beschaffungsbehörden alle OSS-relevanten Kriterien (wie beispielsweise die Lizenz) in der Ausschreibung wiedergeben müssen. Diesbezüglich sind noch viele Fragen offen: Welche Kriterien sollen bei OSS-Ausschreibungen als notwendige technische Spezifikationen oder Eignungskriterien, welche als wünschenswerte Zuschlagskriterien aufgenommen werden? Wie sollen das Community-Management und weitere Wartungs- und Supportarbeiten gehandhabt werden? Besteht die Möglichkeit, eine Entwicklung oder Beschaffung gemeinsam in Kooperation mit anderen Behörden durchzuführen? Wenn ja, wer beteiligt sich in welchem Umfang? Obwohl z.B. der Kanton Zürich bereits in der Vernehmlassung auf die «Wichtigkeit von beschaffungsrechtlich einwandfreien Grundlagen» hingewiesen hat, wurden bislang keine solche Grundlagen zur Verfügung gestellt.

Abschliessend lässt sich in Anlehnung an die parlamentarische Debatte (Votum von Ständerat Benedikt Würth, parlamentarische Debatte zum EMBAG vom 1. Juni 2022) festhalten, dass man «von diesem Gesetz keine Wunder erwarten» kann, aber dass es «ein wichtiges Element ist, damit wir in der digitalen Transformation besser und strukturierter voranschreiten können». Wie schnell und gut das Gesetz seine Ziele erreichen wird und wie das Instrument der OSS-Pflicht in der Praxis eingesetzt wird, wird sich im Laufe des Implementierungsprozesses zeigen.

Aegerter, J. (2012, 22. Oktober). Streit um Open-Source-Lösung «Openjustitia». Netzwoche. https://www.netzwoche.ch/news/2014-03-18/streit-um-open-source-loesung-openjustitia

Botschaft zum Bundesgesetz über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben. (2022, 4. März). BBl 2022 804. (zit.: Botschaft EMBAG).

Bundesministerium des Inneren und für Heimat (2023). Einer für Alle – Einfach erklärt.

https://www.digitale-verwaltung.de/Webs/DV/DE/onlinezugangsgesetz/efa/efa-node.html

Eidgenössisches Finanzdepartement EFD. (2022, 4. März). Vorentwurf des Bundesgesetzes über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben (EMBaG), Vernehmlassung vom 11. Dezember 2020 bis zum 25. März 2021 Bericht über die Ergebnisse der Vernehmlassung. (Zit.: Vernehmlassungsbericht). https://www.admin.ch/gov/de/start/dokumentation/medienmitteilungen.msg-id-87454.html.

Forschungsstelle Digitale Nachhaltigkeit. (2021, 17. Juni). Open Source Studie Schweiz. (zit.: OSS-Studie 2021). www.oss-studie.ch.

Informatiksteuerungsorgan des Bundes (ISB). (2019). Praxis Leitfaden, Open Source Software in der Bundesverwaltung. (Zit.: Praxisleitfaden ISB.). Abgerufen von: https://www.bk.admin.ch/dam/bk/de/dokumente/dti/ikt-vorgaben/strategien/oss/Praxis-Leitfaden_OSS_Bundesverwaltung_V_1-0.pdf.download.pdf/Praxis-Leitfaden_OSS_Bundesverwaltung_V_1-0.pdf.

Müller, G., & Vogel, S. (2014, 26. März). Rechtsgutachten zur verfassungsrechtlichen Zulässigkeit der Randnutzung von Software im Verwaltungsvermögen, insbesondere der Veröffentlichung und Verbreitung von Open-Source Software durch Träger von Bundesaufgaben. https://www.news.admin.ch/NSBSubscriber/message/attachments/37015.pdf.

Parlamentarische Debatte zum EMBAG vom 01. Juni 2022. Ständerat, dritte Sitzung. Amt.Bull. S 2022.022. www.parlament.ch/de/ratsbetrieb/amtliches-bulletin/amtliches-bulletin-die-verhandlungen?SubjectId=57030.

Poledna, Th., Simon S. & Samuel S. (2017). Rechtliche Voraussetzungen der Nutzung von Open-Source Software in der öffentlichen Verwaltung, insbesondere des Kantons Bern. Berlin – Bern: Carl Grossman Verlag. www.carlgrossmann.com/poledna-schlauri-schweizer-rechtliche-voraussetzungen-der-nutzung-von-open-source-software-in-der-oeffentlichen-verwaltung-insbesondere-des-kantons-bern.

Antrag des Zürcher Regierungsrates vom 15. September 2021 für einen Beschluss des Kantonsrates zum Postulat KR-Nr. 65/2019 betreffend Synergien beim Software-Einsatz im Kanton Zürich Nutzen, KR-Nr. 65/2019.

Schlauri, S. (2023). Open Source Software im neuen Bundesgesetz über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben (EMBAG). [PPT-Präsentation gehalten an der IT-Beschaffungskonferenz am 22. August 2023.] www.bfh.ch/dam/jcr:4a363a57-b139-476f-9f27-83d32dc9eb0c/Pr%C3%A4sentation%20-%20Simon%20Schlauri.pdf.

Straub, W. (2024). Softwareschutz – Urheberrecht, Patentrecht, Open Source (2. Aufl.). Dike.

Stürmer, M. (2023). «Open by default» als Gesetz. www.societybyte.swiss/2023/07/12/open-by-default-als-gesetz.

Stürmer, M. (2009). How Firms Make Friends: Communities in Private-Collective Innovation. ETH Zürich, Doctoral Dissertation No. 18630. www.researchgate.net/publication/228536679_How_Firms_Make_Friends_Communities_in_Private-Collective_Innovation

Stürmer, M. & Koch, R. (2024). Whitepaper zur öffentlichen Beschaffung von Open Source Software gem. Art. 9 EMBAG. Erscheint demnächst auf Societybyte.

Rika Koch ist Dozentin an der Berner Fachhochschule und Co-Leiterin der Fachgruppe Public Procurement.

Simon Schlauri ist Partner bei Ronzani Schlauri Anwälte.