Was ist Dual Licensing? — MIT OR Apache-2.0 und das Modell GPL + kommerziell

Warum ein Code mehrere Lizenzen erhält

Ein Rechteinhaber kann denselben Code gleichzeitig unter mehreren Bedingungen lizenzieren. Empfänger wählen eine davon und halten deren Bedingungen ein. Dafür gibt es im Wesentlichen zwei Gründe.

Breitere Kompatibilität — damit der Code in unterschiedliche Ökosysteme passt.
Geschäftsmodell — um den Code als Open Source zu veröffentlichen und zugleich separate kommerzielle Lizenzen zu verkaufen.

Typ 1: zwei freizügige Lizenzen zusammen — `MIT OR Apache-2.0`

So machen es die Sprache Rust und die meisten Rust-Crates. Nutzer wählen, was ihnen besser passt: MIT oder Apache-2.0.

Wer Apache-2.0 wählt, erhält eine ausdrückliche Patentlizenz.
Wer MIT wählt, kann den Code auch in GPL-2.0-only-Projekte aufnehmen (weil die FSF Apache-2.0 als nicht kompatibel mit GPL-2.0 ansieht).

Man bekommt also beide Vorteile – deshalb ist das Modell bei Bibliotheksautoren beliebt. Üblicherweise liegen im Repository zwei Dateien: LICENSE-MIT und LICENSE-APACHE.

Typ 2: Copyleft + kommerziell — „GPL oder bezahlen“

Der Code wird unter GPL oder AGPL veröffentlicht, und Unternehmen, die keine Offenlegungspflicht übernehmen wollen, wird per separatem Vertrag eine kommerzielle Lizenz verkauft. Bekannte Beispiele sind MySQL (GPL + kommerzielle Lizenz von Oracle) und Qt (LGPL-3.0/GPL + kommerziell).

Das Modell funktioniert nur, wenn der Rechteinhaber die Rechte am gesamten Code besitzt. Code, den externe Beitragende nur unter der GPL beigesteuert haben, darf der Rechteinhaber nicht unter einer kommerziellen Lizenz verkaufen.

CLA und DCO

CLA (Contributor License Agreement): Ein Vertrag, mit dem Beitragende dem Projektträger weitreichende Nutzungsrechte an ihrem Beitrag (einschließlich Relizenzierung) einräumen oder das Urheberrecht übertragen. Für kommerzielles Dual Licensing ist er praktisch unverzichtbar. Es gibt auch Formen wie das ICLA der Apache Foundation, die nur Relizenzierungsrechte einräumen und das Urheberrecht bei den Beitragenden belassen.
DCO (Developer Certificate of Origin): Beitragende bestätigen mit jedem Commit, dass sie berechtigt sind, den Code unter der Projektlizenz einzureichen (mit git commit -s wird eine Zeile Signed-off-by: ergänzt). Der Linux-Kernel verwendet es. Ein DCO räumt keine Relizenzierungsrechte ein und reicht daher für kommerzielles Dual Licensing nicht aus.

Schreibweise mit SPDX-Ausdrücken

Das Verhältnis mehrerer Lizenzen wird mit SPDX-Lizenzausdrücken angegeben.

Ausdruck	Bedeutung	Beispiel
`A OR B`	Eine der beiden wählen und befolgen (Wahl-Dual)	`MIT OR Apache-2.0`
`A AND B`	Beide befolgen (verschiedene Teile gemischt)	`MIT AND BSD-3-Clause`
`A WITH Ausnahme`	Einer Lizenz eine Ausnahmeklausel hinzufügen	`GPL-2.0-only WITH Linux-syscall-note`
Klammern	Reihenfolge der Verknüpfung festlegen	`(MIT OR Apache-2.0) AND Unicode-3.0`

Wer OR und AND verwechselt, drückt das Gegenteil aus. Dürfen Nutzer wählen, heißt es OR; müssen alle eingehalten werden, heißt es AND.

Worauf man achten sollte

Bereits erteilte Rechte bleiben bestehen: Auch wenn später nur noch die kommerzielle Lizenz angeboten wird, bleiben die Erlaubnisse für früher als Open Source verbreitete Versionen in der Regel gültig.
Nicht dasselbe wie „Open Core“: Ein Modell mit Open-Source-Kern und proprietären, kommerziell verkauften Zusatzfunktionen ist kein Dual Licensing. Dual Licensing heißt, denselben Code unter zwei Lizenzen anzubieten.
Nicht mit Source-Available-Lizenzen verwechseln: Zunehmend wird auf Lizenzen wie BUSL oder SSPL umgestellt, bei denen der Quellcode einsehbar, nach OSI-Maßstab aber nicht Open Source ist. Das ist eine andere Strategie als Dual Licensing.
Hinweisdateien korrekt anlegen: Bei einer Wahlmöglichkeit alle Lizenztexte vollständig bereitstellen und im README klar sagen, dass zwischen ihnen gewählt werden kann.

Beispiel

Für ein Dual Licensing im Rust-Stil laden Sie im Generator die MIT- und die Apache-2.0-Datei herunter, speichern sie als LICENSE-MIT und LICENSE-APACHE und tragen in die Metadaten license = "MIT OR Apache-2.0" ein. In jeden Dateikopf schreiben Sie SPDX-License-Identifier: MIT OR Apache-2.0.

Dieser Artikel enthält allgemeine Informationen und ist keine Rechtsberatung. Besprechen Sie wichtige Entscheidungen mit Fachleuten.

Quellen

SPDX Specification, License Expressions — https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/
Rust API Guidelines, Licensing — https://rust-lang.github.io/api-guidelines/necessities.html
Developer Certificate of Origin — https://developercertificate.org/
Apache ICLA — https://www.apache.org/licenses/contributor-agreements.html