CLA vs. DCO: Welche Contributor-Vereinbarung sollte Ihr Open-Source-Projekt verwenden?

Ihr Side-Project hat gerade 500 Sterne überschritten, und ein Fremder hat den ersten ernsthaften Pull Request eröffnet: 2.000 Zeilen, die ein Problem beheben, das Sie seit Monaten vor sich herschieben. Sie möchten auf Merge klicken. Aber bevor Sie das tun, stellen Sie sich die unangenehme Frage: Haben Sie tatsächlich das rechtliche Recht, diesen Code auszuliefern — und ihn weiterhin unter Ihrer Lizenz auszuliefern, für immer, egal für wen dieser Contributor arbeitet?

Wenn Ihr Repository keine Contribution-Richtlinie hat, lautet die ehrliche Antwort, dass Sie es nicht sicher wissen. Der Contributor besitzt weiterhin das Urheberrecht an jeder Zeile, die er geschrieben hat, und die Lizenz Ihres Projekts allein klärt nicht immer, wer wem was gewährt hat. Diese Unsicherheit bleibt unsichtbar, bis zu dem Tag, an dem sie zählt: eine Relizenzierung, eine Übernahme, ein Unternehmensnutzer, der Lizenz-Due-Diligence betreibt, oder der Arbeitgeber eines Contributors, der behauptet, die Arbeit sei von Anfang an seine gewesen.

Zwei Mechanismen lösen dieses Problem, und fast jedes Open-Source-Projekt wählt einen davon: die Contributor License Agreement (CLA) und das Developer Certificate of Origin (DCO). Beide existieren, um festzustellen, dass ein Contributor berechtigt ist, den Beitrag zu leisten, und dass das Projekt das Recht hat, ihn zu verbreiten. Sie unterscheiden sich enorm in Gewicht, Aufwand und dem, was sie Ihnen später erlauben. Dieser Leitfaden erklärt, wie jeder funktioniert, wann Sie welchen wählen sollten und wie Sie Ihre Wahl an einem Nachmittag einrichten.

Warum Ihr Projekt überhaupt eine Contribution-Richtlinie braucht​

Das Urheberrecht entsteht automatisch. In dem Moment, in dem jemand Code schreibt, besitzt er ihn — keine Registrierung, kein Urheberrechtshinweis erforderlich. Wenn er ihn bei Ihrem Projekt einreicht, deckt Ihre Open-Source-Lizenz viel ab, aber sie lässt Lücken, die nur eine Contribution-Richtlinie schließt:

• Die eingehende Gewährung. Ihre ausgehende Lizenz (MIT, Apache-2.0, GPL) sagt Nutzern, was sie mit Ihrem Code tun dürfen. Eine Contribution-Richtlinie macht explizit, dass eingehende Beiträge unter kompatiblen Bedingungen eintreffen, sodass Sie das kombinierte Werk verbreiten können, ohne die Herkunft jeder Datei von Hand nachzuverfolgen.
• Arbeitgeberansprüche. Die meisten Arbeitsverträge übertragen IP aus Side-Projects auf den Arbeitgeber, zumindest für Arbeit, die mit der Tätigkeit des Mitarbeiters zusammenhängt. Eine Richtlinie, die Contributors bittet zu bestätigen, dass sie das Recht zur Einreichung haben, legt diese Verantwortung — und den Papiernachweis — auf den Contributor.
• Relizenzierungs-Optionalität. Wenn Sie jemals Lizenzen ändern, eine kommerzielle Edition hinzufügen oder das Projekt an eine Stiftung spenden möchten, brauchen Sie Rechte von jedem Contributor. Diese Erlaubnis nachträglich von Dutzenden früheren Contributors einzuholen, ist irgendwo zwischen schmerzhaft und unmöglich. Eine am ersten Tag gewählte Richtlinie entscheidet, ob diese Tür offen bleibt.
• Patentschutz. Code-Beiträge können Patentrechte mit sich bringen. Manche Richtlinien enthalten eine ausdrückliche Patentgewährung; andere nicht, was mehr zählt, als den meisten Maintainern bewusst ist.

Nichts davon erfordert eine Anwaltskanzlei auf Abruf. Es erfordert, sich für CLA oder DCO zu entscheiden, es in Ihrem Repository schriftlich festzuhalten und es automatisch durchzusetzen. Folgendes bringt jede Wahl mit sich.

Was ist eine Contributor License Agreement (CLA)?​

Eine Contributor License Agreement ist ein unterzeichnetes Rechtsdokument zwischen dem Contributor und dem Projekt (oder dem Unternehmen oder der Stiftung dahinter). Der Contributor unterschreibt einmal, und diese Unterschrift deckt alle seine zukünftigen Beiträge ab.

Anders als Open-Source-Lizenzen sind CLAs nicht standardisiert. Jedes Projekt schreibt seine eigene, aber die meisten fallen in zwei vertraute Formen:

Individuelle vs. Unternehmens-CLAs​

• Individuelle CLA (ICLA): unterzeichnet von einer Person, die im eigenen Namen beiträgt. Sie gewährt dem Projekt typischerweise eine breite Urheberrechtslizenz und oft eine Patentlizenz, während der Contributor sein eigenes Urheberrecht behält.
• Unternehmens-CLA (CCLA): unterzeichnet von einem Unternehmen, das seine Mitarbeiter zur Beitragsleistung autorisiert. Das Unternehmen gewährt dieselben Rechte für Arbeit, die seine Leute einreichen. Projekte, die Unternehmensbeiträge ohne eine CCLA akzeptieren, vertrauen darauf, dass der Vorgesetzte jedes Mitarbeiters davon weiß — und zustimmt —, was genau die Art von Vertrauen ist, die sich während der Due Diligence in Luft auflöst.

Lizenzgewährung vs. Urheberrechtsübertragung​

Die meisten modernen CLAs sind Lizenzgewährungen: Der Contributor behält das Eigentum und gibt dem Projekt eine unbefristete, weltweite, gebührenfreie Lizenz — oft eine, die breit genug ist, um eine Relizenzierung zu erlauben. Die ICLA der Apache Software Foundation ist das kanonische Beispiel.

Eine Minderheit von Projekten verwendet Urheberrechtsübertragung, bei der der Contributor das Eigentum vollständig überträgt (der Ansatz der Free Software Foundation). Die Übertragung gibt dem Projekt maximale Freiheit, Rechte durchzusetzen und zu relizenzieren, verlangt aber Contributors am meisten ab und ist bei gemeinschaftsgetriebenen Projekten aus der Mode gekommen.

Was eine CLA Sie und Ihre Contributors kostet​

Der Kompromiss ist Reibung. Ein erstmaliger Contributor muss den Pull Request verlassen, ein Rechtsdokument lesen, es unterzeichnen (normalerweise elektronisch) und darauf warten, dass die Statusprüfung grün wird, bevor ein Maintainer seinen Code prüft. Tooling hat dies fast schmerzlos gemacht — Bots wie CLA Assistant kommentieren den Pull Request mit einem Unterzeichnungslink und zeichnen die Unterschrift automatisch auf —, aber es ist immer noch ein Tor zwischen „Ich habe Ihren Bug behoben" und „Sie können meinen Fix mergen". Manche Gelegenheits-Contributors springen daran ab.

Im Gegenzug erhält das Projekt einen unterzeichneten, prüfbaren Nachweis: diese Person, an diesem Datum, hat diese Rechte gewährt. Für unternehmensgestützte Projekte, dual-lizenzierte Projekte und alles, was eines Tages übernommen werden könnte, ist dieser Papiernachweis bares Geld wert.

Was ist das Developer Certificate of Origin (DCO)?​

Das Developer Certificate of Origin wurde 2004 von der Linux Foundation für den Linux-Kernel eingeführt, genau um das Gewicht einer CLA zu vermeiden. Es ist kein Vertrag, den ein Contributor unterschreibt und ablegt. Es ist eine kurze Bescheinigung — fünf Absätze, Version 1.1 —, die der Contributor mit jedem Commit bestätigt, indem er eine Signed-off-by-Zeile zur Commit-Nachricht hinzufügt:

Fix off-by-one error in retry backoff calculation
 
The retry delay doubled one extra time because the loop counter
started at 1 instead of 0.
 
Signed-off-by: Alex Rivera <[email protected]>

Das Hinzufügen der Zeile ist ein Flag: git commit -s hängt sie automatisch an, unter Verwendung Ihrer konfigurierten Git-Identität. Mit dem Sign-off bescheinigt der Contributor, dass:

1. Er den Beitrag (ganz oder teilweise) erstellt hat und das Recht hat, ihn unter der Open-Source-Lizenz des Projekts einzureichen, oder
2. Sein Beitrag auf vorheriger Arbeit basiert, die bereits unter einer geeigneten Open-Source-Lizenz steht, die diese Einreichung erlaubt, oder
3. Er den Beitrag von jemand anderem erhalten hat, der eines der oben Genannten bescheinigt hat, und er ihn nicht verändert hat, und
4. Er versteht, dass der Beitrag und sein Nachweis — einschließlich seines Sign-offs — öffentlich sind und unbegrenzt aufbewahrt werden.

Das ist der ganze Mechanismus. Kein separates Dokument, keine Kontoverknüpfung, kein Onboarding pro Projekt. Die Durchsetzung ist eine Statusprüfung: Die DCO-App oder eine gleichwertige Prüfung verifiziert, dass jeder Commit im Pull Request einen gültigen Sign-off trägt, und Maintainer mergen nur, wenn sie grün ist.

Die bewussten Einschränkungen des DCO​

Beachten Sie, was das DCO nicht tut. Es gewährt keine Lizenz über das hinaus, was die ausgehende Lizenz des Projekts bereits vermittelt — es verlässt sich darauf, dass der Beitrag unter den Lizenzbedingungen des Projekts eintrifft. Es enthält keine Patentgewährung. Und weil nichts pro Contributor unterzeichnet und abgelegt wird, gibt es kein zentrales Register darüber, wer was zugestimmt hat; die Git-Historie selbst ist der Nachweis.

Befürworter betrachten dies als Feature: Die niedrige Hürde des DCO ist der Punkt. Der Linux-Kernel, GitLab (das 2017 von einer CLA wechselte) und Chef (das 2016 wechselte) kamen alle zu dem Schluss, dass die Pro-Commit-Bescheinigung ihnen die benötigte Herkunft liefert, ohne jeden Contributor zu belasten. Das Technical Committee von OpenStack beschloss 2025, seine CLA für alle Beiträge durch das DCO zu ersetzen. Der Branchentrend ist unverkennbar — aber ein Trend ist kein Urteil für Ihr Projekt, wie die nächsten Abschnitte erklären.

CLA vs. DCO im direkten Vergleich​

Wann eine CLA die richtige Wahl ist​

Wählen Sie die CLA, wenn die Zukunft des Projekts von Rechten abhängen könnte, die das DCO nicht erfasst:

• Sie planen Dual-Lizenzierung oder Relizenzierung. Wenn eine kommerzielle Edition, ein Lizenzwechsel oder ein Wechsel von Copyleft zu permissiver Lizenzierung auch nur entfernt plausibel ist, ist eine CLA mit breitem License-back der einzige leichte Weg, diese Option offenzuhalten. Die Zustimmung Jahre später zu rekonstruieren, ist das Albtraumszenario.
• Ein Unternehmen steht hinter dem Projekt. Unternehmenssponsoren, Übernehmer und Enterprise-Kunden, die IP-Due-Diligence betreiben, wollen ein Signaturregister, keine Archäologie. Google, Apache-Projekte und Canonical verwenden CLAs genau aus diesem Grund.
• Patente zählen in Ihrer Domäne. Codecs, Funkprotokolle, ML-Modellarchitekturen — in patentlastigen Feldern leistet die ausdrückliche Patentgewährung der CLA echte Arbeit, die das DCO stillschweigend überspringt.
• Eine Stiftung verlangt sie. Manche Stiftungen schreiben ihre CLA als Bedingung für Hosting oder Graduierung vor. Prüfen Sie, bevor Sie annehmen, dass das DCO ausreicht.

Wenn Sie diesen Weg gehen, halten Sie die CLA selbst standardmäßig und langweilig: Beginnen Sie mit der Apache ICLA oder einer Harmony-Vorlage, statt von Grund auf zu entwerfen, veröffentlichen Sie sowohl individuelle als auch Unternehmensversionen und richten Sie am ersten Tag einen Unterzeichnungsbot ein, damit die Reibung ein Klick ist, kein PDF-Hin-und-Her.

Wann das DCO gewinnt​

Wählen Sie das DCO, wenn Beiträge die Lebensadern sind und Reibung der Feind ist:

• Community-Projekte mit vielen Gelegenheits-Contributors. Dokumentationskorrekturen, Tippfehlerbehebungen, kleine Bug-Patches — die Beiträge, die am ehesten an einem Unterzeichnungstor abspringen, sind auch die, die ein DCO elegant handhabt.
• Permissive Lizenz, keine Relizenzierungspläne. Wenn das Projekt für immer MIT oder Apache-2.0 bleiben wird und keine kommerzielle Edition auf der Roadmap steht, bringen Ihnen die zusätzlichen Rechte der CLA wenig.
• Solo-Maintainer und kleine Teams. Das DCO braucht keine Signaturinfrastruktur, keine juristische Person zur Verwahrung von Vereinbarungen und keinen Prozess zur Gegenzeichnung von Unternehmensformularen. Es ist Governance, die Sie aus einer CONTRIBUTING.md-Datei und einer Statusprüfung heraus betreiben können.
• Maximale Kompatibilitätshaltung. Manche Contributors — insbesondere die, die bei großen Unternehmen mit strikten IP-Richtlinien angestellt sind — können ein DCO-Sign-off leisten, aber keine externe CLA ohne rechtliche Prüfung unterzeichnen. Das DCO hält diese Tür offen.

Welche Sie auch wählen, schreiben Sie die Entscheidung auf. Eine CONTRIBUTING.md, die die Richtlinie festhält, den genauen Sign-off- oder Unterzeichnungsablauf zeigt und den vollständigen Text verlinkt, beseitigt die häufigste Verwirrungsquelle: Contributors, die Anforderungen aus einer fehlschlagenden Statusprüfung erraten.

5 Fehler, die jede der beiden Wahlmöglichkeiten untergraben​

1. Beides sagen. Der häufigste Fehler in der Praxis ist eine CONTRIBUTING.md, die in einem Absatz DCO-Sign-offs und in einem anderen CLA-Unterschriften verlangt — meist nach einer halbfertigen Migration. Contributors folgen einer Anweisung, die andere Prüfung schlägt fehl, und Maintainer mergen trotzdem, was den Sinn beider zunichtemacht. Wählen Sie einen Mechanismus, setzen Sie ihn durch und löschen Sie jede Spur des anderen.

2. Keine automatisierte Durchsetzung. Eine nur in Prosa festgehaltene Richtlinie ist ein Vorschlag. Verdrahten Sie die Prüfung als erforderliche Statusprüfung in Ihren Pull-Request-Workflow — die DCO-App für Sign-offs, CLA Assistant oder EasyCLA für Unterschriften —, damit ein nicht zugestimmter Beitrag nicht versehentlich oder durch Maintainer-Müdigkeit gemergt werden kann.

3. Unternehmens-Contributors ignorieren. Wenn Unternehmen Ihr Projekt nutzen und patchen, reichen Mitarbeiter Code während der Arbeitszeit ein. Unter einer CLA-Richtlinie bedeutet das, die CCLA frühzeitig unterzeichnen zu lassen, solange die Beziehung noch warm ist. Unter einer DCO-Richtlinie bedeutet es, sicherzustellen, dass die Sign-off-Anforderung sichtbar genug ist, damit der erste Beitrag von niemandem zu einem IP-Vorfall wird.

4. Annehmen, dass Arbeitsverträge das Beitragen erlauben. Kehrseite derselben Medaille: Wenn Sie zu anderen Projekten beitragen, prüfen Sie zuerst Ihren eigenen Arbeitsvertrag. Viele übertragen IP aus arbeitsbezogenen Side-Projects standardmäßig auf den Arbeitgeber. Die DCO-Bescheinigung („Ich habe das Recht, dies einzureichen") ist nur wahr, wenn dieser Papierkram das sagt.

5. Keine Richtlinie für KI-unterstützten Code. Maschinell generierte Beiträge werfen Herkunftsfragen auf, die weder der DCO-Text aus dem Jahr 2004 noch die meisten CLA-Vorlagen vorhergesehen haben. Legen Sie Ihre Haltung fest — erlaubt mit Prüfung, offengelegt oder verboten — und halten Sie sie in CONTRIBUTING.md neben Ihrer CLA/DCO-Richtlinie fest, bevor Ihr erster KI-generierter Pull Request eintrifft und nicht danach.

Vergessen Sie die Finanzseite Ihres Projekts nicht​

Hier ist der Teil, den Maintainer bis zur Steuersaison aufschieben: In dem Moment, in dem Ihr Projekt seinen ersten Dollar verdient — GitHub-Sponsors-Auszahlungen, Open-Collective-Spenden, ein Beratungsauftrag, der wegen Ihrer README kam —, hat es Finanzen, und Finanzen brauchen Bücher.

Dieselbe Disziplin, die die Herkunft von Beiträgen prüfbar macht, macht Projektgeld handhabbar. Verfolgen Sie Sponsoring-Einnahmen getrennt von Ihrem Gehalt, damit Sie wissen, was steuerpflichtiges Einkommen aus Selbstständigkeit ist. Erfassen Sie Projektausgaben — Domain-Verlängerungen, CI-Minuten, den Nachmittag, den ein Anwalt mit der Prüfung Ihrer CLA verbracht hat — in eigenen Konten, damit Abzüge nicht in persönlichen Kreditkartenabrechnungen verdampfen. Wenn das Projekt zu einer LLC heranwächst oder einem Fiscal Host beitritt, machen saubere historische Aufzeichnungen den Übergang langweilig statt forensisch.

Plain-Text-Buchhaltung passt zu diesem Workflow ungewöhnlich gut: Ihr Journal liegt in der Versionskontrolle neben Ihrem Code, jeder Eintrag hat eine Historie, und nichts versteckt sich in einem proprietären Format. Unsere Dokumentation führt Sie durch den Start eines ersten Journals in Minuten.

Halten Sie die Bücher Ihres Projekts so sauber wie seine Git-Historie​

Die Wahl zwischen CLA und DCO dauert einen Nachmittag; die Entwirrung von Herkunft oder Projektfinanzen Jahre später dauert Wochen. Treffen Sie die Beitragsentscheidung jetzt, automatisieren Sie ihre Durchsetzung und widmen Sie dem Geld des Projekts dieselbe Sorgfalt wie seinen Commits. Beancount.io bietet Plain-Text-Buchhaltung, die Ihnen vollständige Transparenz und Kontrolle über Ihre Finanzdaten gibt — keine Blackboxen, kein Vendor-Lock-in. Starten Sie kostenlos und sehen Sie, warum Entwickler und Finanzfachleute auf Plain-Text-Buchhaltung umsteigen.