Normale Ansicht

IPv6 obsolet?

31. Oktober 2024 um 22:55

Kurz notiert: In den letzten Tagen kursierte ein Artikel von Geoff Huston von der APNIC durchs Netz, in dem er das Ziel in Frage stellt, IPv4 langfristig durch IPv6 zu ersetzen. Warum es obsolet ist? Weil es DNS, NAT und SNI gäbe. Heißes Thema, ich weiß.

Drei Gedanken hierzu:

(1) Transition. Ja, hier hat IPv6 ziemlich versagt und das war schon ziemlich früh absehbar, siehe The IPv6 mess von djb. Ich muss eine Station komplett für IPv6 und IPv4 konfigurieren, damit in der Übergangsphase die Erreichbarkeit sichergestellt ist. Das ist das Gegenteil, wie viele Protokolle agiert haben, die sich gut migrieren lassen. Bei abwärtskompatiblen Protokollen sieht das Protokoll für nicht migrierte Teilnehmer wie das alte Protokoll aus und neue Teilnehmer können anderweitig die neue Version erkennen und besondere Features nutzen. Hätte man besser machen können, aber ich vermute, dass die IPv6-Autoren auch mit einer unkomplizierten Migration gerechnet haben. Und eines ist auch klar: Wenn man ein Protokoll neu und ordentlich entwirft, kann man auch endlich alte Zöpfe abschneiden.

(2) Internet gleichberechtiger Teilnehmer. Einer der großen Durchbrüche beim TCP/ICP-basierten Internet, so wie wir es heute kennen, ist, dass technologisch nicht zwischen Konsument und Produzent unterschieden wird. Jeder Teilnehmer kann einen eigenen Server aufspannen und möglichst weltweit seine Dienste anbieten. NAT (vor allem, wenn man es selber nicht verwalten kann) verhindert das Prinzip und schafft ein klares Gefälle, weil hinter dem NAT liegende Stationen nicht mehr frei agieren können.

(3) IPv4-Adresshandel. Die Knappheit der IPv4-Adressen hat einen Markt geschaffen, wo /24er-Blöcke für zehntausende an Euros gehandelt werden. Wir reden hier – um bei einer Analogie zu bleiben – von reinen Nummerschildern. Diese künstliche Verknappung schafft eine weitere Einstiegshürde für neue, ggfs. Teilnehmer und friert in Folge nur den heutigen Status Quo ein.

Fazit: Eigentlich ist die IPv6-Migration auf einem guten Weg. IPv6-only sollte auch das Ziel in meinen Augen sein. Jetzt auf dem (vermutlich erst halben) Weg abzubrechen, würde ich aber sehr kritisch sehen, weil es nur denen in die Hände spielen würde, die sowieso nach alter TK-Manier eine Unterteilung in Konsumenten und Produzenten sehen wollen. Aber jeder der großen Big-Tech-Konzerne auch mal als kleiner Teilnehmer an den Start gegangen. Die Schaffung höherer Einstiegshürden ist zwar in so einem Markt natürlich, aber nichts, was man gutheißen sollte. Freier Zugang für das Internet ist für die Innovationsfähigkeit umso wichtiger, weil aufstrebende Nutzer im Netz der KI-generierten Inhalte noch einen Unterschied machen können – außerhalb der moderierten Plattformen. Und für einen freien Zugang braucht man auch eine freie Adressvergabe und das geht nur, wenn – wie bei IPv6 – viele Adressen noch günstig verfügbar sind, ohne, dass man erst "digitales Land" für substanzielle Beträge abkaufen muss.

Elasticsearch nimmt AGPL als Lizenz auf

31. August 2024 um 12:09

Interessanter Gegentrend: Während ich vor ziemlich genau einem Jahr über das zu der Zeit aktuellste Beispiel HashiCorp schrieb, wo eine Umstellung auf BSL-artige Lizenzen erfolgte, scheint es wohl auch einige Kandidaten zu geben, die wieder auf OSI-genehmigte Lizenzen umstellen. So verkündete Elastic am vergangenen Donnerstag, das sie wieder mit ihrer Suchmaschinensoftware Elasticsearch "Open Source" werden möchten, indem sie die AGPL als Lizenzoption aufnehmen.

Hintergrund

Hier einmal der Hintergrund bis jetzt, so wie es auf mich als externen Beobachter wirkte: Open Source hat es im Zeitalter der Cloud recht schwer, wenn man damit Geld verdienen möchte (um z. B. die Entwicklung zu finanzieren!). Das verbreitete Standardmodell zur Monetarisierung war bisher, eine Software Open Source anzubieten und den Support oder das Hosting kostenpflichtig anzubieten. Aus Kundensicht bestellt man dann direkt bei dem Hersteller, der seine Software auch am besten verstehen sollte.

Cloud Provider haben dem Modell das Wasser abgegraben, da sie einfach die Open Source Software nehmen und auf ihrer Plattform deployen konnten – ohne einen Cent dem Projekt zahlen zu müssen. Teilweise wurde die Software erweitert, ohne, die Änderungen wieder veröffentlichen zu müssen (deswegen sind auch die MIT- und BSD-Lizenzen so beliebt). Aus Kundensicht kauft man zwar nicht mehr bei dem Hersteller ein, hat aber

  • einerseits alles zentralisiert auf einer Cloudplattform und
  • andererseits gar keinen Bedarf für Herstellersupport, weil die Software sowieso über das SaaS-Modell supported wird und nicht mehr on-premise läuft.

Die Antwort vieler Projekte war es nun, die Lizenz so zu ändern, dass dieses Verhalten nicht mehr möglich ist, z. B. durch die Beschränkung von Konkurrenz-Hostingprodukten. Das verstößt allerdings gegen das Diskriminierungsverbot der OSI, nach dem die Verwendung von Produkten nicht durch die Lizenz beschränkt werden sollte (siehe auch das Good-Evil-Thema bei der JSON-Lizenz).

In der Konsequenz spalteten sich wie mit Open Search Elasticsearch-Forks ab, die weiterhin die offenen Lizenzen nutzen und durch Cloud Provider wie AWS direkt gepflegt wurden und werden. Wie Elasticsearch betont, sollen diese Projekte aber gleichzeitig auch einen eigenen Weg mit eigener Spezialisierung entwickelt haben. Die Community war natürlich aber auch verärgert, da die Software Elasticsearch nun nicht mehr als Free Open Source Software (FOSS) galt.

Wieder Open Source

Elasticsearch plant nun die Wogen zu glätten, indem die AGPL als weitere Lizenz zur ELv2 und SSPL zusätzlich aufgenommen wird. Die Nutzer können also frei entscheiden, welche Lizenz sie nutzen wollen, da insbesondere im Geschäftskontext die AGPL juristisch gesehen als heikel eingeschätzt wird, wenn man das Produkt aus verschiedenen Komponenten zusammengebaut und nicht den gesamten Quelltext veröffentlichen möchte. FOSS-Nutzer und Distributionen haben allerdings wieder die Möglichkeit, die Software wiederaufzunehmen. So entspricht z. B. die AGPL den Debian Free Software Guidelines.

Ende gut, alles gut? Wenn es nach der Ankündigung von Elastic geht, ist das Team zufrieden mit der Entscheidung, wieder Open Source zu sein. Ob der Fork OpenSearch aufrecht erhalten wird oder schlussendlich in das Urprodukt einfließt, ist allerdings noch nicht gewiss und muss sich in der Zukunft zeigen. Vielleicht sind die Communities auch schon zu sehr divergiert, sodass es nun unterschiedliche Lösungen für unterschiedliche Anwendungsfälle gibt.

❌