Springe zum Inhalt

3

Wenn als Decoder-Version KDU angezeigt wird, dann nutzt man Kakadu.
Wenn als Decoder-Version KDU angezeigt wird, dann nutzt man Kakadu.

Die Betaversion 3.0 des Firestorm-Viewers ist voller Änderungen, wenn auch lange noch nicht fertig. Vor allem fehlt bisher die Möglichkeit, mit diesem Viewer Mesh wirklich nach Second Life uploaden zu können, dargestellt wird Mesh allerdings problemlos.

Eine der durchschlagendsten Änderungen in dieser Beta allerdings wurde im offiziellen Posting gar nicht verkündet: Firestorm nutzt als erster Third Party Viewer seit langem wieder die JPEG2000-Bibliothek der Firma Kakadu Software. Das ist dieselbe Bibliothek, die auch die Viewer von Linden Lab standardmässig nutzen. Wer es nicht weiß: diese kommerzielle Bibliothek ist in Sachen Dekodierungsgeschwindigkeit der Texturen knapp doppelt so schnell wie das in den meisten alternativen Viewern verwendete Pendant OpenJPEG.

Der letzte Viewer vorher, der das noch benutzte, war der seelige Emerald gewesen. Allerdings mißbrauchten die Benutzer damals die Bibliothek für unseriöse Machenschaften, so dass danach Linden Lab lange Zeit den Finger darauf hielt und den Einsatz von KDU bei alternativen Viewern nicht mehr weiter gestattete. Dies war damals natürlich nicht gut bei den Benutzern angekommen, aber was sollte man machen, man konnte sich nur bei den Entwicklern von Emerald dafür "bedanken", offensichtlich hat Linden Lab aber seine Meinung nun geändert. Sehr gut!

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.

Now that's something out of the IBM article, but worth an own entry: the open available JPEG-2000 library OpenJPEG got faster! This means you don't need the proprietary libraries from Kakadu anymore to get a good open source client, if you're living on the bleeding edge and this is making its way in the main tree of OpenJPEG after some time, I guess. Yeah!