Zusammenfassung

  • RFC 1602 sah ein dauerhaft online verfügbares, ausführbares Lizenzformular vor, einschließlich einer Anpassung, falls ein späterer Lizenznehmer günstigere Bedingungen erhielt. RFC 1915 bekam dieses Instrument nicht.
  • Nach einem öffentlichen Variance-Verfahren akzeptierte die IETF stattdessen eine allgemeine Zusicherung angemessener und nichtdiskriminierender Lizenzen. Damit war der Standardprozess autorisiert, nicht die Fairness künftiger Verträge bewiesen.
  • RFC 1962 und RFC 1968 belegen die Veröffentlichung von CCP und ECP. Sie belegen weder Patentgültigkeit noch Lizenzierung eines Produkts, Konformität, Einsatz oder Ende-zu-Ende-Sicherheit.

Der fehlende Nachweis lag außerhalb des Protokolls

Die PPP-Arbeitsgruppe hatte zwei Kontrollprotokolle an die IESG weitergeleitet. CCP handelte Kompression auf einer Punkt-zu-Punkt-Verbindung aus, ECP die Verschlüsselung. Beide beschrieben Optionen, Ablehnung und die Rückkehr in einen synchronen Zustand. Technisch ließ sich festlegen, welche Nachricht als Nächstes gesendet werden sollte.

Dann teilte Motorola der IETF mit, die US-Patente 5,245,614 und 5,130,993 könnten die Arbeiten berühren. RFC 1915 hält fest, dass die Standardisierung nach der Einreichung zum Stillstand kam. Daraus folgt nicht, dass die IETF die Patente für gültig oder für jede Implementierung notwendig erklärte. Es folgt, dass ein Rechtsanspruch unter der damals geltenden Verfahrensregel einen zusätzlichen Nachweis verlangte.

Patentbehauptung, rechtliche Gültigkeit, technische Abdeckung, Lizenzbereitschaft, konkretes Angebot, unterzeichneter Vertrag, konformes Produkt und produktiver Einsatz sind getrennte Zustände. Wer sie unter „Standard genehmigt“ zusammenfasst, gibt dem letzten Entscheidungsträger weniger Information, als die Akte tatsächlich enthält.

RFC 1602 verlangte einen gemeinsamen Ausgangspunkt

RFC 1602 enthielt ein detailliertes Modell. Es sah kostenfreie Rechte für die Internet Society im Rahmen der Standardarbeit und Lizenzen zu angemessenen Bedingungen für Mitglieder der Internetgemeinschaft vor, die den Standard implementieren wollten. Erhielte ein späterer Lizenznehmer günstigere Konditionen, sollten bestehende Lizenznehmer entsprechend bessergestellt werden.

Vor allem sollte das Lizenzformular ständig im Internet verfügbar sein. Ein Implementierer hätte denselben Text prüfen, ausfüllen und dem Rechteinhaber zustellen können, um ihn wirksam zu machen. Ein solches Formular entscheidet keinen Patentstreit. Es schafft aber ein beständiges Prüfobjekt: Fassung, Umfang, Pflichten und Annahmeweg können verglichen werden.

Diese gemeinsame Oberfläche senkt Informationsgefälle. Sie garantiert keinen niedrigen Preis, doch sie zeigt, ob der Einstieg für verschiedene Parteien mit demselben Dokument beginnt. Ohne sie bleibt die technische Spezifikation öffentlich, während der wirtschaftliche Zugang in voneinander getrennten Gesprächen entsteht.

Was die Zusicherung leistete – und was nicht

Motorola wollte das vorgesehene Formular nicht bereitstellen. Das Unternehmen gab stattdessen eine allgemeine Erklärung ab: Jedem Interessenten sollten Lizenzen zu angemessenen Bedingungen angeboten werden, die nachweislich frei von unfairer Diskriminierung seien. Patente und Kontakt wurden genannt; RFC 1915 nahm die Erklärung in die öffentliche Akte auf.

Das war mehr als ein Gerücht. Die Gemeinschaft kannte den Wortlaut und die Anlaufstelle. Dennoch ist die Zusage eines künftigen Vertrags nicht der Vertrag. „Angemessen“ braucht Zahlen, Berechnungsgrundlagen und Einschränkungen. „Nichtdiskriminierend“ braucht vergleichbare Fälle. „Verfügbar“ braucht Zeitstempel für Anfrage, Antwort, Angebot und Abschluss.

RFC 1915 benannte das Risiko ausdrücklich. Der Rechteinhaber könnte einzelne Anfragen unterschiedlich behandeln, einige vorantreiben und andere verzögern. Die Ausnahme beseitigte diese Möglichkeit nicht. Sie entschied, dass der technische Prozess nicht bis zu ihrem vollständigen Ausschluss warten würde.

Ein technischer Umweg trug keinen gemeinsamen Entschluss

Die Arbeitsgruppe prüfte Änderungen, die die beanspruchten Patente umgehen sollten. Ein Umweg war technisch möglich, wurde von manchen jedoch deutlich schlechter als der ursprüngliche Entwurf bewertet. Einige erklärten, sie würden das ursprüngliche CCP implementieren, gleichgültig, welche Variante die Arbeitsgruppe oder die IESG standardisierte. Andere akzeptierten die Alternative mangels Ausweg, nicht aus technischer Überzeugung.

Die unveränderte Anwendung von RFC 1602 hielt die Dokumente fest. Ein erzwungener Umweg konnte dagegen offiziellen Standard und tatsächlich eingesetzten Code auseinanderziehen. Laufender Code entschied keine Rechtsfrage; ein Rechtsanspruch verbesserte keine Architektur.

RFC 1915 wählte einen engeren Schritt. Auf Grundlage der Zusicherung vom 5. Juni 1995 durften die ursprünglichen Vorschläge weiterlaufen. Die Entscheidung erklärte weder den Umweg für unmöglich noch die Patente für notwendig noch die späteren Geschäftsbedingungen für vereinbart.

Die Ausnahme selbst musste überprüfbar sein

RFC 1871 hatte RFC 1602 um ein Variance-Verfahren ergänzt. Wenn Regeln keine ausreichende Orientierung boten oder zu einer Sackgasse führten, sollte die zuständige Arbeitsgruppe das Problem vorlegen, die IESG einen Lösungsweg vorschlagen und ein verlängerter Last Call öffentliche Einwände ermöglichen.

Die IESG musste Nutzen und Kosten für die Internetgemeinschaft, technischen Wert, Alternativen, Präzedenzwirkung, Nebenfolgen und die engstmögliche Begrenzung prüfen. Gegen die Entscheidung konnte beim IAB Einspruch erhoben werden.

Darum ist RFC 1915 nicht bloß eine Genehmigung, sondern ein Verfahrensbeleg. Er nennt die unerfüllte Forderung, die Ersatz-Zusicherung, die Schwierigkeiten des Umwegs und das verbleibende Risiko. Er zeigt, wie die IETF die Autorität über ihren eigenen Standardprozess ausübte.

Er zeigt nicht, dass die IESG zur Patentprüfung, Vertragsvertretung oder Kontrolle aller späteren Angebote befugt war. Die Nachprüfbarkeit der öffentlichen Entscheidung ist kein vorweggenommener Nachweis über private Transaktionen, die erst noch stattfinden sollten.

Veröffentlicht bedeutete: Die Spezifikation ist fertig

Im Juni 1996 erschienen CCP als RFC 1962 und ECP als RFC 1968. Die Texte regelten Aushandlung, Zurückweisung, Reset und Algorithmusoptionen. Sie ließen auch proprietäre Mechanismen zu, die über Organisationskennungen bezeichnet wurden. Eine öffentlich beschriebene Option konnte weiterhin Lizenz- oder Exportbeschränkungen unterliegen.

Fanden die Seiten unter CCP keine gemeinsame Kompression, konnte die Verbindung ohne Kompression fortgesetzt werden. Fanden sie unter ECP keine beidseitig akzeptierte Verschlüsselung, musste die Verbindung gegebenenfalls geschlossen werden. Jede Richtung wurde unabhängig ausgehandelt. Das Kontrollprotokoll regelte fehlende Einigung; es erzeugte keine verfügbare Lizenz.

RFC 1968 begrenzte auch die Sicherheitsbehauptung. Schutzstärke hing vom konkreten Algorithmus und von der Verwahrung geheimer Werte ab. Vollständige Sicherheit verlangte weiterhin Ende-zu-Ende-Mechanismen zwischen Hosts. Link-Verschlüsselung war kein Gütesiegel für das Gesamtsystem.

RFC 2026 ordnete die Nachweise neu

RFC 2026 löste RFC 1602 im Oktober 1996 ab. Das Sekretariat sollte weiterhin versuchen, eine schriftliche Zusicherung zu erhalten, dass jedermann die Technik unter veröffentlichten, angemessenen und nichtdiskriminierenden Bedingungen implementieren, nutzen und verbreiten könne. Das Ergebnis dieses Versuchs sollte den Standard jedoch grundsätzlich nicht mehr blockieren. Das detaillierte online ausführbare Formular aus RFC 1602 wurde nicht übernommen.

Außerdem sollte die IESG nicht ausdrücklich entscheiden, ob Nichtdiskriminierung praktisch erfüllt war. Unabhängige Implementierungen und Betriebserfahrung konnten eine Vermutung stützen, die im Last Call anfechtbar blieb.

Die Abfolge beweist einen Politikwandel, nicht dass RFC 1915 allein RFC 2026 verursachte. Sie zeigt eine dauerhafte Grenze: Eine technische Institution kann Offenlegung verlangen, eine Zusicherung veröffentlichen, eine Ausnahme prüfen und den Status ihrer Dokumente bestimmen. Sie kann künftige bilaterale Verträge nicht durch denselben Beschluss in bereits beobachtete öffentliche Tatsachen verwandeln.

Quellen und Beweisgrenzen

Diese offiziellen Quellen belegen Regeln, Zusicherung, Ausnahme und veröffentlichte Protokolltexte. Sie belegen weder Gültigkeit oder Notwendigkeit der Patente noch Konditionen einzelner Verhandlungen. Sie zertifizieren kein konkretes Produkt als lizenziert, konform, interoperabel, eingesetzt oder Ende-zu-Ende-sicher.