Zusammenfassung

  • RFC 5377 formulierte die gewünschten ausgehenden Rechte der IETF-Gemeinschaft, überließ aber den Trustees die genaue rechtliche Umsetzung und den Zeitpunkt ihrer Wirksamkeit. Der Konsens war eine Weisung, nicht selbst der operative Lizenztext.
  • Autoren können unabhängig zusätzliche Lizenzen anbieten. Diese bilden jedoch einen eigenen Provenienzpfad; sie dürfen weder mit den Trust-Bestimmungen verschmolzen noch als Ersatz für fehlende eingegangene Rechte behandelt werden.
  • RFC 8721 löste RFC 5377 ausschließlich ab, um Verweise auf das IAOC zu entfernen. Die sachliche Trennung von Gesamtkopie, Zitat, Codekomponente und gewöhnlicher Prosa blieb bestehen. Dies ist Governance-Analyse, keine Rechtsberatung.

Zwei Erlaubnisse können nebeneinander stehen

Ein Entwickler findet in einem RFC eine nützliche Passage. Die aktuellen Trust-Bestimmungen scheinen für seinen Zweck eng. Auf der Website eines Autors entdeckt er eine weitere Lizenz, die Bearbeitung erlaubt. Nun liegen nicht „mehr Rechte“ in einem einzigen Topf, sondern zwei voneinander unabhängige Begründungswege vor.

Der erste Weg beginnt bei den Beiträgen zur IETF, den dabei eingeräumten Rechten und der Verwaltung durch den IETF Trust. Der zweite beginnt bei einem Autor oder anderen Rechteinhaber, dessen eigener Erklärung und dem dort bezeichneten Werk. Beide Wege können denselben späteren Gebrauch erlauben. Sie können aber auch unterschiedliche Teile, Bedingungen oder Zeiträume betreffen.

Eine saubere Entscheidung hält fest, auf welchen Weg sie sich stützt. Dazu gehören der Aussteller, der Wortlaut, die Version, der Fundort, der Zeitpunkt, der Werkumfang und die Autorität des Ausstellers. Ein Link mit der Beschriftung „alternative licence“ ist noch kein Beweis, wenn die verlinkten Bedingungen später verschwinden.

Das Zusammenrechnen der Wege wäre verführerisch, aber falsch. Eine Bedingung aus der Trust-Regelung darf nicht stillschweigend durch eine externe Erlaubnis ersetzt werden. Umgekehrt sollte eine private Lizenz die Rechte, die die IETF selbst gewähren will, nicht einschränken oder verwirren.

Die Gemeinschaft definierte das Ergebnis

RFC 5377 entstand aus der Frage, welche Rechte die IETF-Gemeinschaft den Nutzern von Beiträgen und RFCs zur Verfügung stellen wollte. Rough consensus konnte die politischen Ziele bestimmen: weite Verbreitung vollständiger Dokumente, saubere Zitate und ausreichend Freiheit für Bestandteile, die Implementierer tatsächlich übernehmen und verändern müssen.

Der RFC enthielt absichtlich nicht die endgültige juristische Formulierung. Die Trustees des IETF Trust sollten die konkreten Einfügungen, Hinweise und sonstigen Mechanismen auswählen. Ebenso sollten sie bestimmen, wann Änderungen an Dokumenten und Richtlinien wirksam wurden.

Diese Arbeitsteilung verhindert, dass jede rechtliche Korrektur eine Revision des politischen RFC erfordert. Ein unklarer Satz in einer Lizenz kann verbessert werden, obwohl die gemeinschaftliche Absicht gleich bleibt. Gleichzeitig darf eine substanzielle Änderung des Ziels nicht als bloße redaktionelle Reparatur getarnt werden.

Für die Nachvollziehbarkeit entstehen mehrere Belege. Der Konsens dokumentiert das gewünschte Ergebnis. Der Trustee-Beschluss dokumentiert den autorisierten Mechanismus. Die genaue Fassung und ihr Wirksamkeitsdatum zeigen, was zu einem bestimmten Zeitpunkt galt. Erst der spätere Gebrauch zeigt, welche Erlaubnis tatsächlich beansprucht wurde.

Der operative Text hatte einen eigenen Zeitpunkt

Ein häufiges Governance-Problem ist der Status „genehmigt“. Er sagt nicht, wer was genehmigt hat und ob weitere Handlungen nötig waren. Bei RFC 5377 konnte die Gemeinschaft ihre Richtung abgeschlossen haben, während die Trustees noch den exakten Mechanismus festlegen mussten.

Darum ist das Veröffentlichungsdatum des RFC nicht automatisch das Wirksamkeitsdatum jeder empfohlenen Klausel. Zwischen Richtung, Umsetzung und Anwendung können Zeiträume liegen. Eine historische Wiederverwendung muss die Fassung finden, die für ihr Dokument und ihren Zeitpunkt tatsächlich galt.

Ein lebender Weblink reicht dazu nicht. Er zeigt gewöhnlich die heutige Fassung. Ein revisionssicheres System bewahrt eine Kopie oder einen Hash, das Datum, die betroffene Dokumentklasse und den Beschluss, der die Fassung in Kraft setzte.

Auch die Behebung einer Zweideutigkeit braucht eine Änderungsbegründung. Ohne sie kann ein späterer Prüfer nicht erkennen, ob nur die Worte verbessert oder die Rechte materiell erweitert wurden. Wartbarkeit entsteht durch kontrollierte Versionen, nicht durch eine ständig überschreibbare Seite.

Niemand kann ausgeben, was nie eingegangen ist

Die ausgehende Erlaubnis des Trust ist durch seine eingegangenen Rechte begrenzt. RFC 5378 behandelt die Rechte, die Mitwirkende einräumen. RFC 5377 und sein Nachfolger befassen sich mit den gewünschten Erlaubnissen an Nutzer. Der Eingang setzt die Obergrenze für den Ausgang.

Vorhandenes Material kann besonders schwierig sein. Ein Autor darf vielleicht seinen neuen Beitrag weit lizenzieren, aber nicht einen eingebetteten Text eines Dritten. Dass beide in einem RFC stehen, vereinheitlicht ihre Herkunft nicht.

Auch eine spätere politische Präferenz erweitert ältere Rechte nicht. Wenn der maßgebliche Inhaber nur eine enge Erlaubnis erteilt hat, benötigt eine breitere Nutzung eine weitere Einräumung. Der Trust kann seine Verwaltungsrolle nicht in Eigentum umwandeln.

Das gilt ebenso für die externe Autorenlizenz. Der Aussteller muss die Rechte an dem Teil besitzen, den er lizenzieren will. Eine selbstbewusste Erklärung auf einer persönlichen Website ist kein Ersatz für diese Prüfung. Die separate Lizenz ist nur so stark wie ihre eigene Rechtekette.

Das vollständige Dokument war ein Verbreitungsfall

Die Empfehlung für vollständige Kopien und Übersetzungen zielte auf breite Verbreitung ohne Verlust von Zusammenhang und Bedeutung. Das Dokument bleibt als Ganzes erkennbar, seine Hinweise und Zuschreibungen bleiben erhalten.

Diese Erlaubnis beantwortet nicht automatisch die Frage, ob einzelne Prosaabschnitte verändert und in einem neuen Werk veröffentlicht werden dürfen. Vollständige Wiedergabe und abgeleitete Bearbeitung sind unterschiedliche Handlungen.

Ein belastbarer Beleg nennt die konkrete Fassung, die Lizenzbestimmungen, die bei der Verbreitung galten, die beibehaltenen Hinweise, die Übersetzungssprache und das ausgelieferte Artefakt. Ein Repository-Eintrag mit Dateiname und Datum reicht nicht, wenn die Verpackung Hinweise entfernt hat.

Ein Zitat blieb unverändert und zugeordnet

Für Zitate sah das gewünschte Modell eine unveränderte Wiedergabe und angemessene Zuordnung zur IETF und zum betreffenden Beitrag vor. Die geringe Länge eines Ausschnitts verkürzt nicht seine Herkunftskette.

Der Prüfbeleg sollte den exakten Abschnitt, seine unveränderte Form, seine Quelle und die tatsächlich sichtbare Zuschreibung enthalten. Wenn ein Redakteur Wörter austauscht, um einen Absatz verständlicher zu machen, ist das Ergebnis nicht mehr bloß ein unverändertes Zitat.

Zuschreibung und Erlaubnis müssen getrennt überwacht werden. Ein korrekt genannter Urheber erzeugt keine fehlende Bearbeitungserlaubnis. Umgekehrt kann ein grundsätzlich erlaubter Gebrauch seine Pflicht zur Nennung verletzen.

Codekomponenten brauchten Bewegungsfreiheit

RFC 5377 nennt Bestandteile wie ABNF, XML-Schemata, DTDs, Relax-NG-Definitionen, Wertetabellen, MIBs, ASN.1 und klassischen Programmcode. Solche Elemente sollen in Implementierungen gelangen. Dafür müssen sie oft extrahiert, angepasst und in andere Systeme eingebettet werden.

Die Gemeinschaft wollte deshalb weitreichende Rechte für diesen Zweck. Der praktische Wert einer Grammatik liegt nicht darin, dass sie nur im RFC betrachtet werden kann. Interoperabilität verlangt die Möglichkeit, sie maschinenlesbar zu übernehmen und an die konkrete Umgebung anzupassen.

Die Freiheit hängt jedoch von der Klassifikation ab. Neben einem Schema kann erklärende Prosa stehen. Die Einordnung des Schemas als Code überträgt sich nicht auf die Nachbarsätze. Vorgeschlagen wurden eine gepflegte Liste typischer Codearten und textuelle Markierungen für konkrete Abschnitte.

Damit wird die Komponentengrenze zu einem autoritätsrelevanten Datensatz. Sie darf nicht allein aus Einrückung, Schriftart oder Dateiendung geraten werden. Gespeichert werden sollten die autorisierte Markierung, der Abschnitt, die anerkannte Art und die damals geltende Fassung.

Gewöhnliche Prosa blieb ein anderer Fall

Für die allgemeine Wiederverwendung von RFC-Text in Zusammenhängen, die eine Veränderung verlangten, verzeichnete RFC 5377 damals keinen Konsens. Das stand nicht im Widerspruch zur Offenheit für Code. Es unterschied zwei Zwecke.

Technische Prosa trägt Begründungen, historische Einordnung und normative Präzision. Eine kleine sprachliche Änderung kann die Aussage verschieben. Codeartige Bestandteile werden dagegen gerade veröffentlicht, damit sie in eine Implementierung wandern.

Hier kann die separate Autorenlizenz relevant werden. Ein Autor darf zusätzliche Freiheit gewähren, sofern er dazu berechtigt ist. Der Nutzer muss jedoch die externe Quelle erhalten, ihren Umfang bestimmen und ihre Bedingungen erfüllen.

Die Entscheidung sollte nicht behaupten, der Trust habe diese zusätzliche Erlaubnis erteilt. Sie sollte sagen: Dieser konkrete Gebrauch stützt sich auf Lizenz X von Aussteller Y für Werkbereich Z. Diese Klarheit schützt sowohl die IETF-Regelung als auch den externen Lizenzgeber.

Eine Klassifikation ist keine Eigentumsmaschine

Eine gepflegte Liste kann später einen neuen Komponententyp aufnehmen. Das kann die heutige Behandlung klären. Es beweist aber nicht, dass historisches Drittmaterial plötzlich mit breiteren eingegangenen Rechten ausgestattet wurde.

Ebenso darf eine aktuelle Definition nicht ohne Zeitbezug auf eine alte Veröffentlichung angewendet werden. Für eine frühere Freigabe sind die damalige Liste, die damaligen Markierungen und die damaligen Trust-Bestimmungen maßgeblich.

Fehlt die Eingangsprovenienz, bleibt sie unbekannt. Automatisierung sollte diese Lücke nicht durch die Vermutung „steht im RFC, also erlaubt“ schließen. Ungewissheit ist ein Zustand, der eskaliert werden kann; eine erfundene Erlaubnis ist ein Fehler, der sich weiterverbreitet.

RFC 8721 korrigierte die institutionelle Adresse

RFC 8721 machte RFC 5377 im Februar 2020 obsolet. Der Nachfolger erklärt, sein einziger Zweck sei die Entfernung von Verweisen auf das IETF Administrative Oversight Committee aus der früheren Verwaltungsstruktur gewesen.

Damit sind zwei Aussagen gleichzeitig wahr. RFC 5377 ist nicht mehr das aktuelle Prozessdokument. Seine sachliche Architektur wurde durch die Ablösung aber nicht verworfen.

RFC 8721 bewahrt die Rollenverteilung: Die Gemeinschaft artikuliert gewünschte Rechte, die Trustees bestimmen die genaue Umsetzung, der Rechtebestand begrenzt die Gewährung, und unterschiedliche Nutzungen bleiben unterschiedlich behandelt.

Ein Register sollte deshalb sowohl den Statuswechsel als auch seinen erklärten Umfang festhalten. „Obsolet“ weist zum Nachfolger. „Ausschließlich IAOC-Verweise“ verhindert die unbegründete Deutung einer materiellen Kehrtwende. Für aktuellen Gebrauch bleiben die aktuellen Trust Legal Provisions die operative Oberfläche.

Die Lizenzentscheidung als nachvollziehbare Kette

Eine belastbare Akte verbindet mindestens:

  • Identität, Fassung und Status des Beitrags;
  • Mitwirkende, Rechteinhaber und vorbestehendes Material;
  • eingegangene Rechte und ihre Grenzen;
  • Konsensdokument und Nachfolgestatus;
  • Trustee-Beschluss und exakte Bestimmungsfassung;
  • Wirksamkeitsdatum und betroffene Dokumentklasse;
  • Komponentengrenze und Klassifikation;
  • beabsichtigte Handlung: Gesamtkopie, Übersetzung, Zitat, Codeverwendung oder Prosabearbeitung;
  • tatsächlich erhaltene Hinweise und Zuschreibungen;
  • gegebenenfalls die separate Autorenlizenz mit eigener Provenienz;
  • ausgeliefertes Ergebnis und beobachtete Einhaltung.

Jede Zeile löst ein anderes Problem. Der Konsens erklärt den Zweck, aber nicht den operativen Wortlaut. Der Wortlaut erklärt die Erlaubnis, aber nicht den Rechteerwerb. Die externe Lizenz eröffnet vielleicht einen zweiten Weg, repariert jedoch keinen unklaren ersten.

Ein System sollte die gewählte Grundlage nennen. „Erlaubt“ ohne Begründung ist nicht ausreichend, wenn später eine Webseite verschwindet, eine Bestimmung wechselt oder ein Rechteinhaber widerspricht.