Das Bundesgesetz über den Einsatz elektronischer Mittel zur Erfüllung von Behördenaufgaben (EMBAG) und die Verordnung EMBAV befassen sich mit diversen Facetten der Digitalisierung. Das EMBAG, die zugehörige Botschaft sowie die EMBAV und deren Erläuterungen schaffen die Rechtsgrundlage für die Umsetzung von Open Government Data und Open Source Software (OSS) und beinhalten Regelungen zu APIs (elektronischen Schnittstellen).

Zentrale Punkte sind:

• die Veröffentlichung von Open Government Data (OGD)
• die Veröffentlichung von Open Source Software (OSS)
• den Einsatz von Schnittstellen (APIs)
• die Verwendung von Standards

Das EMBAG fördert Offenheit, Innovation und einen Kulturwandel in der Bundesverwaltung und unterstützt die digitale Nachhaltigkeit durch «Digital Public Goods».

Wir unterstützen Sie gerne beim Erreichen der EMBAG-Readiness!

Unser Angebot an Sie:

Kostenloses Beratungsgespräch

Wir führen während circa einer Stunde ein Gespräch zur EMBAG-Readiness Ihrer Organisation (gleich hier buchen!). Dabei besprechen wir Ihre vorgängig gemachte Einschätzung bezüglich der nachstehenden Punkte des EMBAG-Checks und identifizieren den Handlungsbedarf, damit Ihre Organisation EMBAG-ready wird.

Preis: kostenlos

Workshop & Roadmap

Wir absolvieren mit Ihnen in einem halbtägigen Workshop vertieft den EMBAG-Check und erarbeiten auf Ihre Organisation und aktuelle Situation abgestimmte konkrete Verbesserungsmassnahmen. Wir erstellen eine Dokumentation der wichtigsten Erkenntnisse und der Empfehlungen für Verbesserungsmassnahmen zuhanden von Entscheidungsträgerinnen und Entscheidungsträgern.

Preis: CHF 3’500

Individuelle Beratung und Unterstützung

Neben dem Beratungsgespräch und Workshop & Roadmap oder zusätzlich dazu unterstützen wir Sie bei Bedarf gerne mit individuellen Beratungsleistungen und mit Unterstützung in der technischen Umsetzung zum Beispiel bezüglich Definition einer Data Governance, bezüglich OGD oder im Data Engineering.

Preis: nach Aufwand

Meine Organisation ist vom EMBAG betroffen.

Falls die Organisation zur zentralen Bundesverwaltung zählt, ist sie auf jeden Fall vom EMBAG betroffen. Grundsätzlich gilt das auch für die dezentrale Bundesverwaltung (öffentlich-rechtliche Anstalten wie Post, SBB etc.), sofern der Bundesrat keine Ausnahme vorsieht (gemäss EMBAG Art. 2)

Folgefragen:

• Falls unsere Organisation (noch) nicht vom EMBAG erfasst ist: Könnte es sein, dass in naher Zukunft ähnliche Vorgaben auch für meine Organisation / meinen Kanton / meine Gemeinde gelten könnten?

Es gibt eine Data Governance für meine Organisation.

Eine Data Governance beschreibt die Regeln, Prozesse und Rollen für die effektive Nutzung von Daten in einer Organisation (siehe die Erläuterungen zur EMBAV Art. 4, Seite 12 zum Rollenmodell). Es hilft, diese Inhalte schriftlich festzuhalten, um sie in der Organisation bekannt zu machen und sich darauf beziehen zu können.

EMBAG Art. 3 beschreibt den Grundsatz, dass Bundesbehörden «elektronische Mittel für die Interaktion» mit anderen Behörden, Unternehmen und natürlichen Personen einsetzen. Sie sollen dabei das «Prinzip der Nachhaltigkeit» und die «Risiken für den Datenschutz und die Informationssicherheit sowie für die Sicherheit und Verfügbarkeit von Daten und Diensten» berücksichtigen.

Folgefragen:

• Gibt es je nach Art der Daten unterschiedliche Regeln, die gelten? Welche sind das?
• Wer kümmert sich um die Erstellung, Einführung und Einhaltung der Regeln?
• Wie können wir die Regeln in unserer Organisation bestmöglich verankern?

Es ist bekannt, welche und wie viele Ressourcen (Zeit, Geld, Personen) für das Thema Daten aufgewendet werden können.

Falls zusätzliche Aufgaben anfallen, muss definiert werden, wer diese übernimmt. Grundsätzlich sind keine neuen Mittel für die Umsetzung des EMBAG vorgesehen. Es gibt jedoch Bestimmungen im Gesetz über Finanzhilfen (EMBAG Art. 7), Pilotprojekte (EMBAG Art. 15) und die Anschubfinanzierung (EMBAG Art. 16 und Art. 17).

Folgefragen:

• Gibt es Dienstleistungen, welche zentral angeboten werden bzw. werden sollten (zum Beispiel Datenkatalog, Qualitätssicherung, Automatisierungsschritte)?
• Schlummern in unserer internen Ablauforganisation unrealisierte Effizienzgewinne bei der Arbeit mit Daten?

Die organisatorischen Zuständigkeiten bzw. Rollen sind definiert.

Klar definierte Zuständigkeiten helfen Daten-Nutzenden, die richtige Ansprechperson zu finden. Je nach Modell werden im Daten-Bereich verschiedene Rollen unterschieden. Die Open Government Data-Strategie des Bundes beispielsweise nennt folgende Rollen: Data Stewards, Data Custodians, Dateneigner (siehe Rollenmodell in den Erläuterungen zur EMBAV Art. 4, S. 12).

Folgefragen:

• Wer ist für die Erfassung und Pflege der Daten zuständig? Wer bereitet den Datensatz auf?
• Wer ist für die Erfassung und Pflege der Metadaten zuständig?
• Wer kann fachliche Fragen zum Datensatz beantworten?
• Wer unterstützt, wenn es Probleme beim Datenbezug gibt?
• Wer ist zuständig, dass der als OGD publizierte Datensatz regelmässig aktualisiert wird?
• Sind unsere Prozesse bereits ausreichend automatisiert?

Es gibt einen regelmässigen Austausch der datenaffinen Personen in der Organisation.

Sogenannte «Communities of Practice» (CoP) sind ein effektiver Weg um Personen mit ähnlichen Aufgaben und/oder Themen über Abteilungsgrenzen hinweg miteinander zu vernetzen. Gerade im Daten-Bereich gibt es oft ähnliche Fragestellungen (zum Beispiel automatisierte Daten-Pipelines, Anonymisierung, Metadaten, gemeinsame Infrastruktur, Datenaufbereitung, Datenanalysen, Visualisierungen, Dashboards), die sich optimal in einer CoP besprechen lassen.

CoP können auch organisationsübergreifend eingerichtet werden. Ein gutes Beispiel dafür ist die «Community für offene Behördendaten» der Mitarbeitenden der Verwaltungseinheiten und Organe des Kantons Zürich.

Folgefragen:

• Welche Ziele verfolgen wir mit einer CoP?
• Wer leitet die CoP bzw. wer lädt dazu ein? Wer wird eingeladen?
• Ist unsere CoP in der Bundesverwaltung bekannt? Wie werden neue Mitarbeitende und Partnerorganisationen auf die CoP aufmerksam?
• Welcher Zeitpunkt und welche Art von Veranstaltung passt am besten für Treffen im CoP-Rahmen? Wie gestalten wir den Ablauf?
• Wünschen wir externe Inputs in die CoP?

Es gibt eine Strategie, wie mit dem Thema Daten umgegangen wird.

Eine solche Strategie umfasst üblicherweise die Bereiche Datenerhebung bzw. -beschaffung, Datenbewirtschaftung, Datenpublikation und Datennutzung. Sie kann auch weitere Themen wie ein Rollenkonzept oder eine Data Governance umfassen.

Folgefragen:

• Gibt es in unserer Organisation bereits Konzepte oder Strategien, die Teilbereiche abdecken – zum Beispiel eine OGD-Strategie, eine Digitalstrategie, eine Amts- oder Geschäftsstrategie?
• Wer sind in unserer Organisation beim Thema Daten die wichtigsten Stakeholder?
• Wie wollen wir den Einbezug der Stakeholder für die Formulierung einer Datenstrategie gestalten?
• Was sollen die zentralen Inhalte unserer Datenstrategie sein?

Es gibt eine Dokumentation der IT-Architektur.

Es ist zentral zu wissen, welche IT-Systeme vorhanden sind und welche Schnittstellen und Abhängigkeiten diese zueinander haben. Mit diesem Wissen kann auch festgestellt werden, welche Daten überhaupt vorhanden sind, welche IT-Systeme wo betrieben werden und wie die Datenflüsse im Gesamtsystem verlaufen. Dazu kommen Fragestellungen zur Skalierbarkeit der IT (vertikal oder horizontal) und zur Informationssicherheit und zum Datenschutz (ISDS).

EMBAG Art. 12 schreibt vor, die Interoperabilität von Systemen zu unterstützen und internationale, offene Standards zu verwenden.

Folgefragen:

• Wie halten wir die Dokumentation der IT-Architektur und der IT-Systeme unserer Organisation aktuell?
• Wie sind die Systemgrenzen definiert?
• Verfügen wir über eine Strategie bezüglich des Betriebs von IT-Systemen in der Cloud oder «on premise»?
• Wie lassen sich unsere IT-Systeme skalieren?

Es gibt eine Übersicht, welche Daten in meiner Organisation vorhanden sind.

Ein Dateninventar kann dabei helfen, Übersicht über alle in der Organisation vorhanden Daten zu erlangen. Typischerweise wird zur Erfassung und Verwaltung des Inventars ein Datenkatalog eingesetzt, der die wichtigsten Metadaten zu den Daten enthält.

EMBAG Art. 14 schreibt vor, die Interoperabilitätsplattform (I14Y) des Bundesamts für Statistik zu verwenden.

Folgefragen:

• Wie definiert unsere Organisation einen Datensatz?
• Welche Metadaten braucht ein spezifischer Datensatz?
• Liefert unsere Organisation bereits Daten und Metadaten an andere Stellen?

Es ist definiert, welche Daten in welchem Format bereit gestellt werden.

Jede Organisation sollte für die verschiedenen Arten von Daten definieren, wie sie diese zugänglich machen wird. Zum Beispiel können tabellarische Daten als CSV-, Parquet- oder Excel-Dateien bereitgestellt werden. Oder Geodaten beispielsweise als GeoPackage oder GeoJSON. Daten, die von einer Webapplikation genutzt werden, werden am besten als JSON zur Verfügung gestellt. Gemäss EMBAG Art. 12 gelten dabei die Standards, die von der Bundeskanzlei verbindlich erklärt wurden.

Wenn es sich um sehr grosse Daten handelt, kann die Bereitstellung auch über einen Dienst (API, Datenbank, Data Warehouse etc.) erfolgen.

Folgefragen

• Verfügen wir über die notwendigen Werkzeuge, um diese Daten bereitzustellen und zu konsumieren?
• Ist das Know-How intern und extern vorhanden, um diese Daten zu nutzen?
• Gibt es eine Dokumentation der Daten? Und für den Zugriff darauf?

Die IT-Systeme sind überwacht und es lassen sich Aussagen zur Nutzung machen.

Zentrale Vorgaben des Monitorings sind, im Fehlerfall schnell die Ursache zu finden und schnell zu sehen, wenn es Anomalien gibt (zum Beispiel ungewöhnlich viele Daten, zu langsames Login, etc.). Ferner sollen Aussagen zur Nutzung von IT-Systemen (Analytics) gemacht werden können und so die Dimensionierung der Systeme gesteuert werden.

Folgefragen

• Welche Grössen sollen in unserem IT-Monitoring erheben werden (was wird gemessen)?
• Wie häufig wird gemessen?
• Wer hat Zugriff auf die Messdaten? Wie und für welche Verwendungszwecke?

Regelmässige Arbeiten (zum Beispiel Aktualisierungen, Publikation) sind automatisiert.

Gerade im Zusammenhang mit Daten und Prozessen lassen sich viele Arbeitsschritte durch Automatisierung vereinfachen. Dies fördert die Standardisierung von Prozessen und vereinfacht die Übergabe an bzw. die Einarbeitung von neuen Mitarbeitenden.

Sowohl in der Softwareentwicklung als auch bei der Datenverarbeitung haben sich entsprechende Praktiken etabliert: DevOps, Continuous Integration, Data Engineering, Daten-Pipelines, etc.

Folgefragen

• Wer ist in unserer Organisation für Automatisierungen zuständig?
• Ist es sinnvoll, gewisse Automatisierungsschritte in unserer Organisation zentral bereitzustellen?
• Haben alle unsere Systeme die für die Automatisierung nötige(n) Schnittstelle(n)?
• Wer kann uns bei Automatisierungen bei Bedarf unterstützen (zum Beispiel Swisstopo KOGIS, BFS oder externe Dienstleister)?

Es gibt einen etablierten Prozess, der prüft, ob Daten veröffentlicht werden müssen («Open by Default»-Ansatz).

EMBAG Art. 10 schreibt vor, dass Daten im Normalfall («by default») als offene Verwaltungsdaten (OGD) zugänglich gemacht werden müssen. Bei neuen oder aktualisierten Daten soll geprüft werden, wie und ob die Daten als OGD publiziert werden müssen. Vor allem beim Start von neuen Vorhaben und oder der Erstellung neuer datenerzeugender Systemen muss OGD mitgedacht werden. Zum Beispiel sollte im Rahmen einer Ausschreibung für eine Software eine standardisierte Schnittstelle für den Datenexport eingeplant werden, um die Anforderungen von «Open by Default» erfüllen zu können.

Folgefragen

• Wer stösst in unserer Organisation den Prüfprozess bezüglich OGD bzw. für Ausschlussgründe für OGD an?
• Wer muss in unserer Organisation das OK für eine Veröffentlichung von Daten geben?
• Müssen Metadaten zu den Daten unserer Organisation vor der Veröffentlichung überarbeitet werden?
• Wie können schützenswerte Daten so aufbereitet werden, dass der Datenschutz gewahrt bleibt?

Die OGD-Veröffentlichungsprinzipien sind bekannt und werden eingehalten.

Die zehn Open-Data-Prinzipien der Sunlight Foundation haben bis heute Gültigkeit. Sie beschreiben, wie Daten veröffentlicht werden sollen:

1. Vollständigkeit (Completeness): alle Daten und die zugehörigen Metadaten
2. Primärquellen (Primacy): Primärdaten der Verwaltung mit Angaben zu Quelle und Erhebungsmethode (vgl. auch Sekundärnutzung)
3. Zeitliche Nähe (Timeliness): so schnell als möglich publizieren und aktualisieren
4. Einfacher Zugang (Ease of Access): auffindbar via zentralem Verzeichnis oder Portal
5. Maschinenlesbarkeit (Machine Readability): vgl. das Fünf-Sterne-Modell für offene Daten von Tim Berners-Lee
6. Diskriminierungsfreiheit (Non-Discrimination): keine Registrierung oder Authentisierung für den Datenzugriff
7. Offene Standards und Schnittstellen (Commonly Owned or Open Standards): gemeinsam verwaltete oder offene Standards
8. Lizenzierung (Licensing): freie Nutzung der Daten für beliebige Zwecke
9. Dauerhaftigkeit (Permanence): Daten bleiben (versioniert) für immer abrufbar
10. Nutzungskosten (Usage Costs): kostenlose Nutzung der Daten

Diese Grundsätze sind auch im EMBAG Art. 10 Abs. 4 festgehalten.

Folgefragen

• Kennen wir die Bedürfnisse unserer Datennutzenden – zum Beispiel bezüglich Maschinenlesbarkeit, offene Standards, Lizenzierung oder Aktualisierung der Daten?
• Wie können wir in Austausch mit unseren (potenziellen) Datennutzenden kommen? Und wie bleiben wir es?
• Wie können wir eine Daten-Community von Personen innerhalb und ausserhalb unserer Organisation aufbauen, die uns nützt?

Es ist definiert, über welchen Kanal bzw. über welches Portal unsere Daten zur Verfügung gestellt werden.

Für OGD gibt es in der Schweiz einige etablierte Kanäle, über die offene Verwaltungsdaten einer breiten Öffentlichkeit zugänglich sind – zum Beispiel opendata.swiss und die I14Y-Plattform. Es ist zu prüfen, ob die Daten der eigenen Organisation (zum Beispiel in Form von Dateien oder von Schnittstellen) direkt oder indirekt auf diesen Kanälen publiziert werden können. EMBAG Art. 14 schreibt die Nutzung der Interoperabilitätsplattform (I14Y-Plattform) des Bundesamts für Statistik vor.

Manche Organisationen pflegen einen internen Datenkatalog, der die Daten an die oben angesprochenen Kanäle weitergibt. Aus technischer Sicht ist es zwingend, zu den Daten die Metadaten im Format DCAT-AP Switzerland bereitzustellen.

Folgefragen

• Wie können wir die Daten unserer Organisation selbständig öffentlich zugänglich machen?
• Gibt es in unserer Organisation bereits etablierte Veröffentlichungskanäle, die mit den zentralen Kanälen bzw. Portalen verbunden sind?
• Wie können Nutzende der zentralen Kanäle bzw. Portale mit unserer Organisation in Kontakt treten («contact point»)?
• Welche «Good Practices» sind im Tätigkeitsgebiet meiner Organisation fürs Zugänglichmachen von Datei-Downloads und von Schnittstellen etabliert?

Für jeden Datensatz ist definiert, wie die Datenaufbereitung für OGD zu erfolgen hat.

Bei OGD handelt es sich per Definition um eine Sekundärnutzung von (bereits bestehenden) Daten. Das heisst, es geht bei OGD um Daten, welche bereits in Gebrauch sind und die für OGD aufbereitet und veröffentlicht werden.

Die Aufbereitung der Daten kann verschiedene Aspekte umfassen:

• Datenformate (zum Beispiel Export aus einer Datenbank im CSV-Format)
• Auswahl der Attribute (alle oder, zum Beispiel aus Datenschutzgründen, nur ein Subset)
• Anonymisierung (zum Beispiel durch Aggregation)
• Datenstruktur (zum Beispiel «Tidy»-Format, Zeitreihe)

Ein weiterer wichtiger Aspekt ist die Qualität der Daten und der Metadaten. Alle Datensätze sollten gut beschrieben, zugänglich, interoperabel (mit Hilfe der Interoperabilitätsplattform (I14Y)) und wiederverwendbar sein.

Folgefragen

• Erfolgt die Aufbereitung von Daten für die Veröffentlichung als OGD automatisiert?
• Wo ist die Datenaufbereitung dokumentiert?
• Hält unsere Organisation die Grundsätze der FAIR-Prinzipien ein?

Die gängigen API-Paradigmen und -Standards sind bekannt.

Für gewisse Daten gibt es bereits Standards, wie diese als API veröffentlicht werden sollen (z.B. OGC für Geodaten oder Abstimmungsdaten als JSON-API). Der Begriff «API» (Schnittstelle) kann hier sehr breit aufgefasst werden: vom REST- oder RPC-API, über stabile URLs bis zur Publikation in einem öffentlichen Object-Storage ist alles denkbar. Die API Guidelines der Bundeskanzlei geben wertvolle Hinweise, wie RESTful APIs erstellt werden sollen.

EMBAG Art. 13 verlangt, dass der Datenaustausch zwischen Bund, Kantonen, Gemeinden und Privaten über «elektronische Schnittstellen» abgewickelt werden kann.

Folgefragen

• Werden gleiche oder ähnliche Daten wie die Daten unserer Organisation bereits von anderen Stellen publiziert?
• Gibt es de jure (offizielle) oder de facto (inoffizielle) Standards, die verwendet werden sollten (zum Beispiel eCH, W3C, OGC)?
• Gibt es in unserer Organisation ein API-Management (für API Keys, Caching, Throttling)?

Grosse Daten und Daten, die häufig ändern, werden als API angeboten.

Gerade grosse Datenmengen werden sinnvollerweise als API angeboten, so dass Datennutzende einen einfachen und einheitlichen Zugang zu den Daten bekommen (EMBAG Art. 13). Unter Umständen kann eine Veröffentlichung als API und als Datei-Download in Betracht gezogen werden, um unterschiedliche Bedürfnisse zu befriedigen. Beispiel: Eine Badi-App will die aktuelle Wassertemperatur anzeigen. Sie nutzt dafür die entsprechende API. Forschende, die die Wassertemperaturschwankungen der letzten 100 Jahre untersuchen möchten, sind im Gegenzug froh um die Möglichkeit eines Datei-Downloads.

Folgefragen

• Wie oft werden die Daten unserer Organisation jeweils aktualisiert?
• Wie oft werden die Daten unserer Organisation konsumiert? Durch wen und für welche Anwendungsfälle?

Die angebotenen Schnittstellen sind dokumentiert.

Um Nutzenden den Einstieg in die Verwendung einer API zu erleichtern, ist eine aktuelle und gut verständliche Dokumentation sehr wichtig. Zentral ist dabei, dass alle relevanten API-Endpunkte beschrieben sind, insbesondere Parameter und Wertelisten, die die Endpunkte von den Nutzenden erwarten. EMBAG Art. 14 Abs. 1b verlangt «ein Verzeichnis der Schnittstellen [..] sowie der zu deren Nutzung notwendigen Informationen».

Für REST-APIs hat sich OpenAPI als Standard etabliert. Diese Spezifikation wird von geeigneten Tools direkt unterstützt (zum Beispiel durch Swagger für eine interaktive Web-Dokumentation oder durch Postman als Desktop-Applikation). Für komplexere APIs ist es von Vorteil, Beispiel-Code zu veröffentlichen, wie die API zu verwenden ist. Ein Beispiel hierfür ist die API-Dokumentation für offene Daten der Stadt Zürich.

Folgefragen

• Gibt es eine zentrale Stelle, wo unsere Organisation die Dokumentation unserer Schnittstellen zugänglich macht (zum Beispiel in einem Developer Portal oder auf der I14Y-Plattform)?
• Ist die Dokumentation der Schnittstellen unserer Organisation up-to-date?
• Wer ist in unserer Organisation für die Pflege der Dokumentation verantwortlich? Wie funktioniert der entsprechende Prozess?

Es ist bekannt, unter welchen Voraussetzungen Software als Open-Source-Software bereit gestellt werden muss.

Im Grundsatz muss jede Software, die von Organisationen entwickelt wird, die dem EMBAG unterstehen, offengelegt werden. Sobald eine Software selbst entwickelt wird oder ein Dienstleister diese im Auftrag entwickelt muss diese als Open-Source-Software (OSS) zur Verfügung gestellt werden (EMBAG Art. 9).

Es gibt aber Ausnahmen von dieser Regel:

1. Die Software wird unverändert beschafft (z.B. als Lizenz oder als Software-as-a-Service): In diesem Fall ist der OSS-Grundsatz freiwillig. Er kann jedoch in der Beschaffung gefordert werden.
2. Die Rechte Dritter würden verletzt, zum Beispiel wenn eine bestehende Software weiterentwickelt wird
3. Sicherheitsrelevante Gründe

Im September 2024 hat die Bundeskanzlei Hilfsmittel zu Open Source Software publiziert. Diese umfassen unter anderem einen «Strategischen Leitfaden» und einen «Praxis-Leitfaden».

Folgefragen

• Ist es denkbar, dass die Software auch noch von anderen Organisationen eingesetzt wird (anderes Amt, anderer Staat, Kantone, Gemeinden, Private)?
• Sind sich unsere Software-Dienstleister dieser neuen Bestimmungen bewusst?
• Stehen Beschaffungsvorhaben für Software an, in denen wir die neuen Bestimmungen umsetzen müssen?

Es ist definiert, unter welcher Lizenz die Software veröffentlicht wird.

Das EMBAG macht klar: «[Die Behörden] erlauben jeder Person, die Software zu nutzen, weiterzuentwickeln und weiterzugeben, und erheben keine Lizenzgebühren» und «soweit möglich und sinnvoll sind international etablierte Lizenztexte zu verwenden» (EMBAG Art. 9). Somit sind alle etablierten OSS-Lizenzen denkbar (zum Beispiel mit «Copyleft»). Wichtig ist dabei auch die lizenzrechtliche Kompatibilität aller eingesetzten Komponenten (zum Beispiel Programmbibliotheken).

Bekannte OSS-Lizenzen:

• Open Source-Lizenzen mit «Copyleft» (diese verlangen, dass alle Änderungen der Software frei verfügbar bleiben)
  • GPL (GNU General Public License): die am weitesten verbreitete Copyleft-Lizenz, aktuell nur in Englisch vorhanden
  • AGPL (GNU Affero General Public License): ideal für Webanwendungen
  • EUPL (European Union Public License): verfügbar in 22 Sprachen
• Permissive Open Source-Lizenzen ohne «Copyleft» (freizügig):
  • MIT (Massachusetts Institute of Technology License): nur Haftungsausschluss
  • BSD (Berkley Software Distribution License): Haftungsauschluss und «Werbeverbot», dadurch ist kein ungewolltes Endorsement von Software möglich

Die Webseite ChooseALicense.com von GitHub kann bei der Auswahl der passenden Lizenz helfen.

Use Cases

• Software basiert auf einer bestehenden, als Open Source unter Copyleft lizenzierten Lösung
  • Empfehlung: die bestehende Copyleft Lizenz verwenden
• Es soll eine Community rund um die Software entstehen, die am Code mitarbeitet
  • Empfehlung: Lizenz mit Copyleft verwenden (z.B. GPL, AGPL)
• Beim Code handelt es sich um eine Referenzimplementierung, die möglichst breit eingesetzt werden soll
  • Empfehlung: permissive Lizenz ohne Copyleft verwenden (z.B. MIT, BSD)
• Die Software soll einmal publiziert werden, und danach will man nichts mehr damit zu tun haben
  • Empfehlung: permissive Lizenz ohne Copyleft verwenden (z.B. MIT, BSD)

Diese Use Cases basieren auf einem Referat von Simon Schlauri und Ronja Lichtsteiner.

Folgefragen

• Welche Lizenz(en) haben wir in unserer Organisation bislang eingesetzt? Weshalb?
• Wünschen wir starkes «Copyleft»?
• Wo wird die mit einer Lizenz zu versehene Software künftig zum Einsatz kommen?
• Ist allenfalls eine «Dual License» möglich und sinnvoll?

Es ist definiert, wer und wie eingesetzte Software weiterentwickelt wird.

Sobald Software unter einer offenen Lizenz (OSS) veröffentlicht wird, stellen sich einige zusätzliche Fragen, was die Weiterentwicklung der Software betrifft (siehe auch EMBAG Art. 9). Es lohnt sich, diese Fragen möglichst früh in einem Projekt zu klären und Lösungen zu entwickeln. Oft wird dazu eine Richtlinie erstellt, die zusammen mit der Software veröffentlicht wird (vgl. Richtlinien für Repository-Mitarbeitende festlegen in der Dokumentation von GitHub). Diese Richtlinie sollte klarstellen, wie mit Bug Reports und Pull Requests umgegangen wird.

Ganz allgemein stellt sich die Frage, wie die Community des OSS-Projekts gestaltet werden soll. Sind andere Bundesstellen, Organisationen und Private eingeladen beim Projekt mitzuwirken? Unter welchen Bedingungen? Was passiert, wenn die Software an unterschiedlichen Orten zum Einsatz kommt und die Anforderungen der Beteiligten sich ändern?

Folgefragen

• Können und sollen ergänzende Dienstleistungen angeboten werden (zum Beispiel Support, Wartung, Integration)?
• Wo ist das OSS-Projekt publiziert (zum Beispiel in GitHub, GitLab, etwas eigenes)?
• Wie kann mit dem Projekt interagiert werden (Diskussionen, Chat, Forum, Bug Reports, …)?
• Wie wird mit Forks des Projekts umgegangen?