Linden Lab ist mal wieder auf Kriegspfad, so sehen es jedenfalls viele Verschwörungstheoretiker. Deren Meinung ist ganz einfach diese: Linden Lab verfolge eine Strategie, alle wichtigen alternativen Viewer uninteressant zu machen, so dass man geradezu gezwungen ist, den unglücklichen Viewer 2.x von Linden Lab zu benutzen. Diese Theorie ist weit verbreitet und macht immer wieder die Runde, was die Vertreter dabei allerdings übersehen ist der einfache Fakt, dass das Linden Lab herzlich egal ist, mit welchem Viewer man auf das Grid zugreift, Hauptsache man greift darauf zu und lässt sein Geld dort. Das Geschäftsmodell von Linden Lab basiert nämlich nach wie vor Großteils auf der Landvermietung und nichts anderem, der Viewer der Wahl ist dabei wirklich herzlich egal.
Nun ist es so, dass alle Texturen in Second Life auf dem Bildformat JPEG2000 basieren (nähere Erklärung in diesem Blogpost von mir). JPEG2000 ist eine sehr stark verlustbehaftete Bildkomprimierung und benötigt sehr viel Rechenzeit.
Der Viewer von Linden Lab benutzt dafür eine kommerziell vertriebene Programmbibliothek aus dem Hause Kakadu Software, während die meisten alternativen Viewer dafür das deutlich langsamer arbeitende OpenJPEG benutzen, welches Opensource ist (wen es interessiert, hier gibt es dazu viele Benchmarks, Kakadu gewinnt dabei immer). Nun war es bisher aber möglich, und der Code dafür stammt von den Lindens selbst, dass man einem alternativen Viewer wie meinetwegen Phoenix dazu überreden kann, die Bibliothek aus dem Hause Kakadu zu benutzen. Man musste dafür nur die Programmbibliothek llkdu.dll aus dem Verzeichnis eines offiziellen Second Life Viewers in das Verzeichnis des alternativen Viewers kopieren, neu starten – fertig. Das ist eine Sache, die auch viele gemacht haben, der alte Emerald kam am Ende sogar mit einer eigenen Version dieser Bibliothek namens emkdu.dll daher. Dies war für viele ein schöne, gern gesehene Sache, da doch so der alternative Viewer vor allem auch auf älteren Prozessoren spürbar flotter arbeitete.
Die Technik, die dabei eingesetzt wird, nennt sich DSO – dies steht für „Dynamic Shared Object“ und ist nichts anderes als eine zur Laufzeit geladene Programmbibliothek. Im Falle der Second Life Viewer wird diese Bibliothek direkt aus dem Programm heraus geladen, die dafür notwendigen Routinen befinden sich im Quellcode in der Datei llimage/llimagej2c.cpp. Das Vorhandensein der KDU-Bibliothek ist dabei für keinen der Viewer ein Muss, weil er nicht gegen diese Bibliothek gelinkt worden ist. Ist diese nicht vorhanden, läuft er dennoch und benutzt statt dessen als Fallback OpenJPEG. Ist allerdings auch OpenJPEG nicht vorhanden, dann startet er erst gar nicht richtig und quittiert das mit einer Fehlermeldung.
So. Die Codebasis, auf der alle bisherigen alternativen Viewer basieren, steht unter der GPLv2 inkl. einiger Ausnahmen, einer sog. FLOSS, damit man gegen Bibliotheken linken darf, die nicht mit der GPL kompatibel sind, die der Viewer aber zum Laufen benötigt (Snowstorm steht unter der LGPL, aber auf dessen Basis gibt es bisher keinen alternativen Viewer).
Was aber ist die GPL? Die GPL (Wikipediartikel dazu und Post von Kris Köhntopp) ist die Softwarelizenz, unter der dieser Code vertrieben wird und die genau festlegt, was man damit machen darf und was nicht. Das zentrale Wesen der GPLv2 ist dabei, dass sie virulent ist. Code, der einmal unter der GPL publiziert worden ist, bleibt das auf alle Zeit und alle daraus abgeleiteten Programme müssen ebenfalls unter dieser Lizenz zur Verfügung gestellt werden. Wichtig dabei ist, dass die GPL sagt: du musst mit mir kompatibel sein! Wenn man ein Projekt leitet und Code damit baut, der zum Teil auf Produkte mit anderen, inkompatiblen Lizenzen basiert, dann verstösst man damit gegen die GPL. Will man gegen lizenzmässig inkompatible Bibliotheken linken, dann braucht es eine FLOSS, so wie Linden Lab das getan hat.
Nun wird die KDU-Bibliothek als „Black Box“ benutzt. Das bedeutet, der Viewer checkt, ist sie da und lädt sie dann zur Laufzeit, ansonsten funktioniert das Programm auch ohne. Das Vorhandensein von KDU ist keine Voraussetzung für das Funktionieren des Viewers an sich. Damit bewegt man sich lizenzmässig gleich auf einem Drahtseilakt, aber möglich ist dieses durchaus. Letztendlich wäre es ein Fall für die Juristen, das abzuklären.
Jedenfalls sagt jetzt Linden Lab nun dies: „Wer alternative Viewer baut, die auf das Grid zugreifen wollen, der darf die KDU egal welcher Form nicht mehr nutzen können.“ und daran scheiden sich jetzt die Geister. Es bedeutet für die Benutzer von alternativen Viewern eine gehörige Verschlechterung der Ladezeiten und der Aufruhr ist dementsprechend groß. Es hat zudem Auswirkungen auf die in world Wirtschaft, da OpenJPEG mit einigen Texturen einfach nicht klar kommt und diese bestenfalls falsch darstellt, wenn überhaupt. Sollten dies natürlich Height Maps für Sculpties sein, dann guckt man schön in die Röhre. Entsprechend sauer sind viele auf Linden Lab und meinen sarkastisch, LL wolle die letzten verbliebenen Avatare nun auch noch endgültig aus Second Life vertreiben.
Nun ist die Begründung von Seiten Linden Labs, mit der sie das durchsetzen wollen, auch reichlich dünn: sie begründen das mit einem Verstoß gegen die GPL. Die meisten Entwickler alternativer Viewer sehen das naturgemäß anders, aber kommen in der Mehrheit Linden Labs Wünschen dennoch nach.
Warum? Weil Linden Lab eine ganz einfache Stellstchraube hat, mit denen sie die Entwickler dazu bewegen können: sie müssen keinen alternativen Viewer aufs Grid lassen, der ihnen nicht gefällt. Das ist der Knüppel im Sack, mit dem Linden Lab zur Not arbeiten kann, Emerald hat das bereits ja zu spüren bekommen.
Über den Grund, warum Linden Lab auf einmal diesen Schritt vollzieht, gibt es auch so einige Spekulationen. Am wahrscheinlichsten ist dieser, dass Kakadu Software Linden Lab mit der juristischen Keule in Form massiver Schadensersatzzahlungen wegen möglicher Lizenzverletzungen gedroht hat. Denn was Linden Lab mit der llkdu.dll geschaffen hat ist nichts anderes als eine beliebig kopierbare Variante dieser proprietären Bibliothek, die von jedem beliebigen Programm unter Windows, Linux und Mac OX S aufgeruft werden kann, um JPEG2000 zu handhaben. Die dafür notwendigen Schnittstellen sind ja offen im Quellcode von Linden Lab dokumentiert und so ist das ein leichtes. Es ist durchaus möglich, dass dies auch bereits geschehen ist, jedenfalls ist das so oder so eine Sache, die man natürlich im Hause Kakadu Software nicht gerne sehen dürfte.
Wenn dem aber so ist, dann sollte Linden Lab wenigstens auch so ehrlich sein und das offen zugeben. So aber kommen die meisten Entwickler mit der geballten Faust in der Tasche den Forderungen Linden Labs nach, aber bezeichnen die Begründung bestenfalls als unehrlich, meist eher noch als verlogen. Den Schaden tragen jedenfalls alle Benutzer, die lieber mit einem alternativen Viewer unterwegs sind in Form deutlich langsamerer Texturaufbauzeiten davon. Bis OpenJPEG die Qualität und Geschwindigkeit von Kakadu erreicht, dürfte noch einiges an Zeit vergehen, Bildkomprimierung ist ein ungeheuer theoretisches und ekliges Feld der Programmierung.
