Reading Time: 9 minutes

Die Wahl einer Open-Source-Lizenz für Forschungskodex ist eine der wichtigsten Entscheidungen, die ein Forscher trifft – und eine, die die meisten Doktoranden und Hauptforscher zum ersten Mal ohne formelle Ausbildung treffen.

Ihre Lizenzauswahl bestimmt, wer Ihren Code verwenden kann, wie er ihn verwenden kann, ob Patentansprüche adressiert werden und ob nachgelagerte Änderungen offen bleiben. Es wirkt sich direkt auf die Reproduzierbarkeit, Zuordnung und Einhaltung der Geldgebermandate aus. Die Forschungsgemeinschaft hat jedoch keine Standard-Bildungsressource, die Forscher durch den tatsächlichen Entscheidungsprozess führt, die wichtigsten Lizenzen in Klartext vergleicht oder den häufig verwechselten Schnittpunkt der Datenlizenzierung und der Softwarelizenzierung erklärt.

Dieser Leitfaden behebt diese Lücke. Es führt die Forscher durch die praktischen Schritte der Auswahl einer Lizenz, vergleicht die wichtigsten Optionen, erklärt die Anforderungen der Geldgeber, klärt die Unterscheidung zwischen Daten und Code und skizziert institutionelle Überlegungen, bevor Sie Code veröffentlichen.

Warum ist die Wahl der Lizenz wichtig?

Das wichtigste Missverständnis in der Forschungsgemeinschaft ist, dass das Posten von Code ohne Lizenz bedeutet, dass er gemeinfrei oder frei verwendbar ist. es ist nicht. Nach dem Urheberrecht bleibt Code ohne eine explizite Lizenzdatei vollständig urheberrechtlich geschützt, was bedeutet, dass niemand anders ihn legal kopieren, modifizieren oder verteilen kann – auch nicht in akademischen Umgebungen. Dies ist die grundlegende rechtliche Realität, die jedes Forschungsteam verstehen muss, bevor es öffentlich teilt.

https://open-science-training-handbook.gitbook.io/book/02OpenScienceBasics/03OpenResearchSoftwareandOpenSource dokumentiert explizit dieses Missverständnis und listet andere häufige Mythen über Open-Source auf Lizenzierung.

Über die gesetzliche Einhaltung hinaus hat Ihre Lizenzauswahl direkte Konsequenzen für drei Bereiche:

Reproduzierbarkeit

Eine Open-Source-Lizenz gibt anderen Forschern die gesetzliche Erlaubnis, Ihre Arbeit auszuführen, zu modifizieren und zu reproduzieren. Ohne sie sind sogar Forscher, die Ihre Ergebnisse reproduzieren möchten, mit rechtlicher Unsicherheit konfrontiert – eine Barriere, die die Reproduzierbarkeitsbewegung in der Computerwissenschaft untergräbt.

Zuschreibung

Unterschiedliche Lizenzen behandeln die Attribution unterschiedlich. Zulässige Lizenzen wie MIT und BSD erfordern die Zuweisung von Quellenumverteilungen, während Copyleft-Lizenzen wie die GPL-Zuordnungsanforderungen tief in ihre Bedingungen einbetten. Die gewählte Lizenz bestimmt, wie Ihr Beitrag nachgelagert ist.

Funder Compliance

Große Forschungsförderer haben jetzt explizite Lizenzerwartungen. Die Software Data Policy 41A (SPD-41A) der NASA erfordert explizit eine freie Open-Source-Lizenzierung für alle vom Projekt entwickelte Software und sperrt generell proprietäre oder quellenverfügbare Lizenzen. Horizon Europe erwartet fair ausgerichtete Lizenzen. NIH Best Practices-Leitfaden für öffentliche Open-Source-Lizenzen. Das Ignorieren dieser Anforderungen kann nach der Veröffentlichung zu Compliance-Verstößen führen.

Der Entscheidungsprozess

Die Wahl einer Lizenz ist eine strukturierte Entscheidung, keine zufällige Auswahl. Folgen Sie diesen Schritten:

Schritt 1 – Klären Sie, was andere tun sollen

Fragen Sie sich: Möchten Sie, dass andere Ihren Code in proprietären Projekten frei verwenden, oder möchten Sie, dass alle Änderungen Open-Source bleiben? Diese Frage treibt den Rest der Entscheidung an.

Wenn Sie eine maximale Akzeptanz wünschen – einschließlich der Verwendung durch die Industrie, proprietäre Projekte und uneingeschränkte kommerzielle Verteilung – sind zulässige Lizenzen (MIT, BSD) angemessen. Wenn Sie möchten, dass Derivate Open-Source bleiben, sind Copyleft-Lizenzen (GPL) die Wahl.

Schritt 2 – Patent Implikationen berücksichtigen

Wenn Ihre Forschung neuartige Algorithmen, maschinelles Lernen oder Hardware-Integration beinhaltet, wird das Patentrisiko relevant. Apache 2.0 ist die einzige weit verbreitete Freigabelizenz mit einer expliziten Patentzuteilung. Dies bedeutet, dass die Beitragszahler den nachgeschalteten Benutzern eine Lizenz für alle Patentansprüche gewähren, die von den Mitwirkenden für Code innerhalb des Projekts gehalten werden. MIT, BSD und GPL enthalten keine expliziten Patentzuschüsse (GPLv3 enthält eine Patentvergeltungsklausel, aber keine Mitwirkende).

Schritt 3 – Angepasst an Community-Konventionen

Studieren Sie die Lizenzen, die von ähnlichen Projekten in Ihrem Unterfeld verwendet werden. Eine numerische Methodenbibliothek in der computergestützten Materialwissenschaft sollte berücksichtigen, welche Lizenzen etablierte Frameworks verwenden. Die Community-Ausrichtung reduziert die Reibung für Mitwirkende und Benutzer.

Einen tieferen Kontext zu Open-Source-Entwicklungs-Workflows in den Forschungseinstellungen finden Sie in unserem Handbuch zu , das zu FIPY beiträgt, in dem erläutert wird, wie Code in der Praxis funktioniert.

Schritt 4 – Überprüfen Sie die institutionellen Anforderungen

Viele Universitäten benötigen die Genehmigung des Tech Transfer Office, bevor sie Software unter einer Open-Source-Lizenz veröffentlichen. Arbeitsverträge können Lizenzentscheidungen einschränken. Überprüfen Sie immer die institutionellen Richtlinien, bevor Sie eine Lizenz anwenden.

Schritt 5 – Wenden Sie die ausgewählte Lizenz an

Legen Sie eine Lizenzdatei in das Repository-Stamm-Stamm ein, das genau als Lizenztext bezeichnet wird (z. B. LICENSE.mit, LICENSE.apache oder LICENSE.gpl). Fügen Sie optional Urheber-Headern zu Quelldateien hinzu, dies ist jedoch für die meisten Lizenzen nicht erforderlich.

Verwenden Sie choosealicense.com als interaktives Tool, um Ihren Anwendungsfall einer Lizenzempfehlung anzupassen.

Lizenzvergleich

Die vier am häufigsten in Forschungssoftware verwendeten Lizenzen sind MIT, BSD, Apache 2.0 und GPL. Sie fallen in zwei Familien:

  • Permissive (MIT, BSD, Apache 2.0): Ermöglichen Sie die eigenständige Verwendung, erfordern Sie eine Attribution, kurz und einfach
  • Copyleft (GPL): Erfordern, dass abgeleitete Werke Open-Source und stärkerer Gemeinschaftsschutz bleiben

MIT-Lizenz

Die einfachste aller weit verbreiteten Lizenzen. Ein einzelner Textabsatz, der eine Zuordnung bei Quellenumverteilungen erfordert. Keine Patenterteilung, kein Copyrleft, keine Kompatibilitätsanforderungen für nachgelagerte Bibliotheken.

Best for: Maximale Akzeptanz. Wenn Sie Ihren Code überall verwenden möchten – in akademischen Arbeiten, Eigenprodukten und modifizierten Derivaten – ohne Einschränkungen.

Research Adoption: Das MIT ist laut einer Studie von Jahanshahi aus dem Jahr 2026 die häufigste Lizenz unter lizenzierten Open-Source-Projekten (65%). Es dominiert aufgrund seiner Einfachheit und breiten Kompatibilität mit anderen Lizenztypen.

BSD-Lizenz

sehr ähnlich wie MIT. Die BSD-Lizenz mit zwei Klauseln entspricht funktional dem MIT. Die Variante mit drei Klauseln fügt eine explizite No-Endorsement-Klausel hinzu, die andere daran hindert, Ihren Namen zur Werbung für abgeleitete Produkte zu verwenden.

Best for: Wenn Sie maximale Akzeptanz und Schutz vor Missbrauch von Endorsement wünschen. Die BSD mit drei Klauseln ist in staatlich finanzierten Forschungs- und Hochleistungs-Computing-Communities verbreitet.

Apache 2.0

Die einzige weit verbreitete Freigabelizenz mit einer expliziten Patentzuschuss. Es ist länger als MIT oder BSD (~ 200 Zeilen) und enthält zusätzliche Bedingungen für die Verwendung von Marken, Urheberrechtshinweise und die Vergeltung von Patentansprüchen.

Best for: Forschung mit erheblicher Patentbelastung – Algorithmen, KI-Methoden, Hardware-Integration oder Community-Projekte, bei denen die Mitwirkenden möglicherweise Patente haben, die für den Code relevant sind.

Research Adoption: Ungefähr 12% der lizenzierten Open-Source-Projekte verwenden Apache 2.0 und ist damit die zweithäufigste Wahl.

GPL (Allgemeine öffentliche Lizenz)

die prominenteste Copyleft-Lizenz. GPLv2 und GPLv3 sind die beiden Hauptversionen. GPLv3 enthält Bestimmungen zur Anti-Tivoisierung (Verhinderung von Hardwarebeschränkungen beim Ausführen von modifizierter Software) und eine Klausel zum Patentvergeltung; GPLv2 fehlt dieser Schutz. Für moderne Forschungssoftware ist GPLv3 die aktuelle Wahl.

Best for: Wenn Sie den Downstream-Code benötigen, um Open-Source zu bleiben. GPL stellt sicher, dass alle öffentlich verteilten Änderungen oder abgeleiteten Werke auch unter GPL freigegeben werden müssen.

Research Adoption: Ungefähr 5% der lizenzierten Projekte verwenden GPL. Es ist in der Forschung weniger verbreitet, da viele Forscher freizügige Begriffe für eine maximale wissenschaftliche Wiederverwendung bevorzugen.

Vergleichstabelle

Die folgende Tabelle fasst die wichtigsten Funktionen der vier Lizenzen zusammen:

Funktion MIT BSD Apache 2.0 GPL
COPYLEFT? Nein Nein Nein Ja
Patentgewährung? Nein Nein Ja (explizit) Nur GPLv3-Vergeltung
Copyright-Header erforderlich? Ja Ja Ja Ja
am besten für? Maximale Adoption Adoption + No-Endorsement-Schutz Patentexposition, Gemeinschaftsprojekte Sicherstellen, dass der Downstream offen bleibt
Lizenzlänge? ~ 1 Absatz ~ 1 Absatz ~ 200 Zeilen ~80 Zeilen (GPLv3)
Kompatibel mit proprietärer Verwendung? Ja Ja Ja Nein (Derivate Werke müssen GPL bleiben)

Die obige Vergleichstabelle synthetisiert die Anleitung von https://safeguard.sh/resources/blog/open-source-license-comparison-mit-apache-gpl-bsd und https://ospo.library.jhu.edu/learn-grow/licensing-overview/choose-a-license/ (Johns Hopkins Ospo).

Empfehlung

Für die meisten Forschungscodes – numerische Solver, Simulationstools, Datenanalyseskripte – Wir empfehlen MIT. Es ist das einfachste, am weitesten verbreitete und ermöglicht die Verwendung Ihres Codes von jedem ohne rechtliche Hindernisse. Die breite Akzeptanz des MIT bedeutet, dass die Mitwirkenden bei der Kombination Ihres Codes mit anderen beliebten Bibliotheken keine Bedenken hinsichtlich der Lizenzkompatibilität haben.

Wählen Sie Apache 2.0, wenn:

  • Ihre Forschung beinhaltet neuartige Algorithmen mit Patentexposition
  • Sie möchten eine explizite Patentzuschuss zum Schutz der nachgelagerten Benutzer
  • Sie bauen ein Community-Projekt auf, in dem die Mitwirkenden relevante Patente halten können

Wählen Sie GPL, wenn:

  • Sie müssen sicherstellen, dass Änderungen Open-Source bleiben
  • Ihr Code ist ein Framework oder eine Bibliothek, in der das Downstream-Abhängigkeitsmanagement von Bedeutung ist
  • Sie priorisieren die Durchsetzung der Offenheit gegenüber der maximalen Adoption

Funder-Mandate

Forschungsförderer erwarten zunehmend spezifische Lizenzierungspraktiken. Das Ignorieren dieser Anforderungen schafft nach der Veröffentlichung ein Compliance-Risiko.

NASA – SPD-41A

Die Software Data Policy 41A (SPD-41A) der NASA erfordert eine freie Open-Source-Lizenzierung für alle vom Projekt entwickelte Software. Proprietäre oder quellenverfügbare Lizenzen sind im Allgemeinen für Code ausgeschlossen, der im Rahmen der NASA-Finanzierung erstellt wurde. Dies macht die Lizenzauswahl zu einer Compliance-Anforderung, nicht nur zu einer strategischen Präferenz für von der NASA finanzierte Forschungsteams.

NIH – Open-Source-Richtlinie

Der Best Practices-Leitfaden der National Institutes of Health (NIH) für öffentliche Open-Source-Lizenzen. Während das NIH keine bestimmte Lizenz beauftragt, fördern die Open-Source-Richtlinie und die Software-AS-SHA-Richtlinie die zulässigen Open-Source-Begriffe für Software, die mit NIH-Finanzierung entwickelt wurde, nachdrücklich.

Horizont Europa

Der European Research Council und Horizon Europe Funding Expansions erwarten explizit fair ausgerichtete Lizenzen für Forschungssoftware. Katz und Kollegen dokumentieren, wie sich diese Politik in den jüngsten Finanzierungsrunden entwickelt hat und wie europäische Forschungsteams ihre Lizenzentscheidungen an fairen Grundsätzen ausrichten müssen (https://open-research-europe.ec.europa.eu/articles/5-199).

Institutionelle RDM-Leitfäden

Viele Universitäten verfügen über formale Richtlinien für Forschungsdatenmanagement (RDM), die sich mit der Softwarelizenzierung befassen. Der Max-Planck-RDM-Leitfaden bietet praktische Anleitungen zur Auswahl von Lizenzen für Forschungssoftware (https://rdm.mpdl.mpg.de/2023/05/02/how-to-select-a-license-for-research-software/), während KU Leuven eine explizite Checkliste für fair ausgerichtete Lizenzierung ( https://www.kuleuven.be/rdm/en/guidance/fair-research-software ).

Practical Guidance: Wenn Sie sich über die Lizenzerwartungen Ihres Geldgebers nicht sicher sind, konsultieren Sie die Allgemeinen Geschäftsbedingungen Ihres Zuschusses oder fragen Sie bei Ihrem Forschungsbüro. Die meisten Geldgeberrichtlinien werden öffentlich veröffentlicht und können vor der Veröffentlichung überprüft werden.

Daten vs. Codelizenzierung

Eine der häufigsten Verwirrungsquellen in der Forschungssoftware ist die Beziehung zwischen Datenlizenzierung und Softwarelizenzierung. Forscher wenden häufig dieselbe Lizenz für beide an, was zu rechtlichen Fehlpaarungen führt.

Creative Commons funktioniert nicht für Code

Creative Commons (CC)-Lizenzen wurden für Daten, Veröffentlichungen und Bildungsinhalte entwickelt. Ihnen fehlen kritische Begriffe, die die Softwarelizenzierung erfordert:

  • Quellcode-Verteilungsbedingungen
  • Ausführbare Binärverteilungsbedingungen
  • Bibliotheksverknüpfungsbegriffe
  • Patentvergeltungsklauseln

Creative Commons empfiehlt ausdrücklich die Verwendung von CC-Lizenzen für Software. Die Anwendung von CC-BY oder CC-BY-SA auf Code schafft eher rechtliche Mehrdeutigkeit als Klarheit.

Möglicherweise benötigen Sie zwei Lizenzen

Bei Forschungsprojekten, die sowohl Daten als auch Code enthalten, sind häufig zwei separate Lizenzen der richtige Ansatz:

  • CC-Lizenz für Daten: CC-BY 4.0 für Datasets und Publikationen
  • OSS-Lizenz für Code: MIT, Apache 2.0 oder GPL für Software

https://www.rug.nl/digital-competence-centre/research-data/archive-and-public. sh / how-to-work-with-dataversenl / Choosing-eine-Lizenz für Ihren Datensatz?lang=en . Bietet explizite Anleitungen zu dieser Unterscheidung für Forschungsteams, die sowohl Datensätze als auch Software verwalten.

Praxisbeispiel

Ein Projekt, das neben der Simulationsausgabe (Daten) einen numerischen Solver (Code) veröffentlicht, sollte:

  1. Geben Sie LICENSE.mit für den Solver-Code ein (MIT-Lizenz)
  2. Geben Sie LICENSE.cc-by-4.0 oder ähnliches für die Datendateien ein
  3. Dokumentieren Sie beide Lizenzen in der Repository-Readme

Institutionelle IP-Überlegungen

Vor dem Veröffentlichen von Code unter einer Open-Source-Lizenz müssen Sie die Richtlinie zum geistigen Eigentum (IP) überprüfen. Dies ist die häufigste administrative Gefahr für akademische Forscher.

Universitäts-Tech-Transferbüros

Die meisten Universitäten betrachten den Forschungskodex als institutionelles geistiges Eigentum. Ein Tech Transfer Office (TTO) oder eine gleichwertige Stelle hat in der Regel das Urheberrecht in Code, das von Mitarbeitern als Teil ihrer Pflichten geschrieben wurde. Die Freigabe eines solchen Codes unter einer Open-Source-Lizenz ohne TTO-Genehmigung kann einen IP-Verstoß darstellen.

Arbeitsverträge

Viele akademische Arbeitsverträge enthalten IP-Klauseln, in denen angegeben ist, wem die Forschungsergebnisse gehören. Fakultätsmitglieder haben möglicherweise mehr Flexibilität als Postdoktoranden oder Forschungsmitarbeiter. Überprüfen Sie Ihre spezifischen Vertragsbedingungen.

Einschränkungen der Finanzierungsagentur

Einige Förderagenturen setzen Lizenzierungsbeschränkungen auf, die über die eigenen Lizenzerwartungen hinausgehen. Beispielsweise können bestimmte DARPA- oder DOE-Programme bestimmte Lizenzfamilien angeben oder patentbezogene Bedingungen erfordern.

Praktische Schritte

  1. Kontaktieren Sie Ihr Tech Transfer Office, bevor Sie Code unter einer Open-Source-Lizenz veröffentlichen
  2. Überprüfen Sie Ihren Arbeitsvertrag für IP-Besitzklauseln
  3. Stipendienbedingungen für Lizenzbeschränkungen
  4. Institutionelle Genehmigung durch Dokumente in Ihrem Repository oder Dokumentation

Praktische nächste Schritte

Wenn Sie Code zum Veröffentlichen oder bereits ohne Lizenz veröffentlichten Code haben, finden Sie hier einen praktischen Aktionsplan:

vor der Veröffentlichung

  1. Erklären Sie Ihre Lizenzabsicht — Verwenden Sie das oben genannte Entscheidungsrahmenwerk (Abschnitt 2)
  2. Überprüfen Sie die institutionelle Compliance — Wenden Sie sich an Ihre Tech Transfer Office
  3. Prüfung der Geldgeberanforderungen — Prüfen Sie die Bedingungen für die Lizenzerwartungen
  4. Lizenz auswählen — Verwenden Sie choosealicense.com als Leitfaden

Nach Auswahl einer Lizenz

  1. Den Lizenztext aus der offiziellen Quelle herunterladen (z.
  2. Lizenzdatei im Repository-Stamm mit dem exakten Lizenztext erstellen
  3. Datei konsistent benennen – Verwenden Sie zur Übersichtlichkeit LICENSE.mit, LICENSE.apache oder LICENSE.gpl
  4. Hinweis zum Urheberrecht hinzufügen – Der Lizenztext enthält in der Regel einen Platzhalter für das Urheberrechtsjahr und den Autorennamen. Füllen Sie dies aus.
  5. Dokument in Readme – Geben Sie die verwendete Lizenz an, verknüpfen Sie die Lizenzdatei und erklären Sie, wie andere den Code verwenden können

Wenn Sie bereits Code veröffentlicht haben

  1. Sofortige Lizenzdatei hinzufügen – Auch wenn der Code zuvor nicht lizenziert wurde, ist das Hinzufügen einer Lizenz eine einfache Korrektur
  2. Dokumentation des Repositorys aktualisieren – Lizenzbedingungen für bestehende Benutzer klären
  3. Bestehende Benutzer benachrichtigen – Wenn der Code Benutzer hat, teilen Sie die neuen Lizenzbedingungen mit

Zusammenfassung

Die Auswahl einer Open-Source-Lizenz für Forschungssoftware ist kein kleineres administratives Detail – es ist eine strategische Entscheidung, die sich darauf auswirkt, wer Ihre Arbeit nutzen kann, wie sie sie verwenden kann und ob Ihr Code den Funder-Mandate entspricht. Die Landschaft ist stabil und gut dokumentiert: Zulässige Lizenzen (MIT, BSD, Apache 2.0) ermöglichen eine maximale Akzeptanz, während Copyleft-Lizenzen (GPL) die nachgelagerte Offenheit gewährleisten.

Für die meisten Forschungscodes ist MIT aufgrund seiner Einfachheit, breiten Kompatibilität und dominanten Akzeptanz (65% der lizenzierten Projekte) die empfohlene Wahl. Wählen Sie Apache 2.0, wenn die Patentexposition relevant ist, und GPL, wenn Sie garantieren müssen, dass der nachgeschaltete Code open-Source bleibt.

Überprüfen Sie immer die institutionellen IP-Richtlinien, bevor Sie eine Lizenz anwenden, unterscheiden Sie klar zwischen Datenlizenzierung (CC) und Softwarelizenzierung (MIT, Apache, GPL) und stellen Sie sicher, dass die Anforderungen der Geldgeber eingehalten werden. Das größte Missverständnis – dieser Code ohne Lizenz ist frei wiederverwendbar – ist der grundlegende Grund, warum jedes Forschungsteam eine Lizenz explizit auswählen und veröffentlichen muss.

Verwandte Anleitungen

Wenn Sie Ihre Forschungssoftware-Praktiken über die Lizenzierung hinaus erweitern möchten, bieten diese zugehörigen Leitfäden eine ergänzende Berichterstattung:

Checkliste: Ihre Lizenzauswahl in 5 Minuten

  1. Was sollen andere tun? Freigabe (MIT/BSD) für maximale Akzeptanz; Apache 2.0 für Patentschutz; GPL für erzwungene Offenheit
  2. Erfordert Ihre Institution eine Genehmigung? Wenden Sie sich vor der Veröffentlichung an das Tech Transfer Office
  3. Hat Ihr Geldgeber Anforderungen? Überprüfen Sie die NASA SPD-41A, Horizon Europe Fair Alignment, NIH-Erwartungen
  4. Veröffentlichen Sie auch Daten? Verwenden Sie CC für Daten; Verwenden Sie OSS für Code
  5. Ist die Lizenzdatei im Repository-Stamm? Fügen Sie sie sofort hinzu, wenn sie fehlt

Befolgen Sie diese Checkliste, bevor Sie einen Forschungscode veröffentlichen. Es umfasst die wesentlichen Compliance- und strategischen Überlegungen, die Sie und Ihre Benutzer schützen.

Wenn Sie Forschungssoftware für eine breitere Akzeptanz entwickeln, lesen Sie unseren Leitfaden zu Aufbau nachhaltiger Forschungssoftware-Communities , der die Onboarding-Mitarbeiter, Governance-Modelle und die Community-Praktiken abdeckt, die gute Lizenzentscheidungen ergänzen.

Dieser Artikel enthält Informationen zur Open-Source-Lizenzierung für Forschungssoftware. Es stellt keine Rechtsberatung dar. Wenden Sie sich immer an die Technologietransferstelle und den Rechtsberater Ihrer Einrichtung, um die Einhaltung spezifischer Lizenzanforderungen und IP-Richtlinien zu erhalten.