Unfreiwillige Wasserzeichen in World of Warcraft Screenshots

Momentan sind Teile der Spielerschaft von World of Warcraft sauer auf den Hersteller Blizzard. Der Stein des Anstoßes ist dabei dieser: Blizzard soll den Client so programmiert haben, dass er jeden im Client geschossenen Screenshot im JPEG-Bildformat mit einem individuellen Wasserzeichen versieht.

Angestoßen wurde diese Diskussion im Owned-Core-Forum und dort wurden auch bereits massive Analysen gefahren, wann das Wasserzeichen auftritt und wann eben nicht. Der einfache Tipp dabei ist dieser: wer das Wasserzeichen umgehen will, der soll entweder ein externes Programm für Screenshots nehmen oder diese im Targa-Bildformat speichern, dann nämlich treten die Wasserzeichen gar nicht mehr auf.

Die Gründe für das Vorgehen von Seiten Blizzards sind und bleiben nebulös, bisher steht eine offizielle Stellungnahme zu den Vorwürfen aus.

Folgende Daten werden im unfreiwilligen Wasserzeichen abgespeichert:

  • der Name des Accounts,
  • die Uhrzeit der Aufnahme sowie
  • und die IP-Adresse des Servers, auf dem man spielt.

Nicht enthalten sind: das Passwort des Benutzers, die IP-Adresse des Benutzers und ähnlich sensitive Daten!

Die Leute im Forum vermuten, dass das Wasserzeichen dazu benutzt wird, um Alts miteinander in Verbindung zu bringen und private WoW-Server zu verfolgen. Die Brisanz der Infos ist heutzutage weniger wichtig als vor ein paar Jahren, zwischen 2007 bis 2009 hätte man es für Hackversuche auf den Account benutzen können. Eingeführt haben soll Blizzard übrigens das Watermarking mit dem Patch 2.1.0 in 2007.

Einige argumentierten anfangs, dass was man sehen würde seien nur die üblichen JPEG-Artefakte; aber dafür trifft dasselbe Muster wiederholt zu oft in derselben Form auf und viele konnten es reproduzieren. Das deutet dann schon sehr stark auf Wasserzeichen hin.

Im Forum existieren auch inzwischen zwei Programme, eines in Java und eines in C# geschrieben, welches das Wasserzeichen auslesen können soll. Die Infos selber sind im Wasserzeichen nämlich unverschlüsselt abgelegt.

Es gibt auch einige, die vermuten, die angewandte Technik für das Wasserzeichen sei vom Branchenspezialist Digimarc lizenziert worden. Das aber ist bisher nur eine Vermutung, denn offziell hat sich Blizzard dazu noch nicht geäußert.

So oder so, es ist und bleibt eine unschöne Sache und auf eine mögliche Stellungnahme Blizzards zu dem Thema sind denke ich viele nun so richtig mal gespannt.

Diese Ruhe heute, hach…

Habt ihr irgendwas heute bemerkt? Alles schön ruhig, sonnig, man genießt das Leben, auch in den Medien und Zeitungen plätschert alles so für sich hin, wie man gewohnt ist.

Eigentlich ist heute ein ganz normaler Tag, ja fast… richtig, heute ist der 11. September. Da war doch noch was, ja richtig… war es auch, aber die Lage hat sich normalisiert, das monstranzartige Niederbeten, was damals passiert ist und Zelebrieren dieser Sache in den Medien hat endlich weitestgehend aufgehört.

Den Zeitungen ist es kaum noch Druckerschwärze wert, es gibt keine Sondersendungen mehr im Fernsehen und auch ansonsten alles ruhig.

Gut so – endlich kehren auch die letzten Hysteriker zur Normalität zurück und fangen mal langsam an, sich den wirklich wichtigen Problemen unserer Zeit zu widmen!

Kleines Update zur neuen JIRA-Regelung

Sooo… nachdem die Meinungen zur neuen JIRA-Politik ein wenig auseinandergehen, noch einige Fakten: hat man nun als Entwickler noch Zugriff darauf oder nicht?

Tonya Souther von Firestorm sagt, sie habe keinen Zugriff mehr darauf. Katharine Berry dagegen sagt, sie habe aktuell sehr wohl Zugriff darauf

Wie geht das zusammen? Die Antwort darauf ist einfach: Linden Lab wird noch auch ausgewählten Entwicklern Zugriff auf das JIRA geben, genauer auf die Suche, die im Vorfeld das Contribution Agreement unterzeichnet haben. Die genauen Bedingungen werden nach Oz Linden zwar noch diskutiert, aber darauf wird es ziemlich sicher hinauslaufen nach seiner Aussage.

Ist das nun gut oder schlecht, dass sich zukünftig nur noch ein handverlesener Kreis an Auserwählten sich alle Fehlerberichte ansehen kann? Eindeutig schlecht, denn es macht die Entwicklercommunity kaputt!

Warum macht es die Community kaputt? Ganz einfach weil die Mehrheit niemals die Vereinbarung mit Linden Lab unterzeichnet hat und viele, gute Programmierer wie Henri Beauchamp das auch aus sinnvollen Überlegungen niemals tun werden.

Linden Lab schafft hier eine Zweiklassengesellschaft, die der Community nur schadet und vor allem die Entwickler von Opensim-Viewern dürften es nun schwerer haben, auch wenn ich mir nun sicher bin, dass Firestorm noch Zugriff auf den Bugtracker bekommen wird.

Was bedeutet die Reform des JIRA-Trackers genauer?

Ich habe mir zu der Änderung im Umgang mit dem JIRA-Tracker noch so einige, weitere Gedanken gemacht.

Die einen sehen darin einen notwendigen Schnitt und Schritt in die Normalität. Ein Bugtracker ist schließlich zum Melden von Fehlern gedacht und nicht als Abstimmungssystem über Features, die viele nun sehr gerne hätten oder um in den Kommentaren Druck auf die Entwickler auszuüben. Aber gerade das war sehr häufig im Laufe der Zeit im JIRA geschehen, wer kennt es nicht, dass irgendjemand ein Ticket zu irgendwas eröffnete, dann den Link weiter reichte und darum bat, man möge bitte dafür abstimmen, damit Linden Lab mal den Arsch hochkriegt und das behebt? Eben!

Dafür war das System nie gedacht gewesen, andererseits ist es aber auch so, wenn man es wirklich systematisch ausgewertet hat, konnte man daraus eine Menge über die Wünsche seiner Kunden erfahren.

Also ist das aus Sicht Linden Labs ein Schritt in die richtige Richtung, diese Unkultur im Bugtracker zu unterbinden, für die er niemals gedacht gewesen ist.

Aber das greift dann eben doch ein wenig zu kurz. Man hätte nämlich es so machen können, dass Bugs sehr wohl noch für jeden öffentlich sichtbar sind, aber nicht mehr jeder kommentieren/abstimmen kann. Die meisten erfolgreichen Opensource-Projekte fahren generell mit offenen Bugtrackern, weil eben diese durch die Offenheit leben. Beispiele dafür sind die Bugtracker von Firefox, Linux, Video Land Client, Chromium (die Basis von Google Chrome) und viele weitere. Offen einsehbare Bugs gehören zu einer guten Opensource-Entwicklung einfach dazu, denn sie bringen eine Menge an Vorteilen. So etwas ist also Standard.

Was nun Linden Lab getan hat, ist die Abstimmungskultur im JIRA schlagartig zu beenden. Gut, das ist deren Sache. Aber sie taten eben noch mehr, indem sie dafür sorgten, dass Bugs grundsätzlich nicht mehr öffenlich sind, auch die Bugs, die die Viewerentwicklung betreffen.

Und damit zeigen sie den externen Viewerentwicklern eindeutig den Stinkefinger, etwas anderes ist das nämlich nicht. Sie berauben diese Entwickler nämlich einer immens wichtigen Informationsquelle.

Wer das nicht glaubt, der sollte sich mal damit auseinandersetzen, was gerade in einem ähnlichen Fall passiert. Die Datenbank MySQL gehört schon seit längerem zu Oracle. Oracle selber entwickelt diese als Opensource auch weiter, aber es gibt mindestens zwei kommerzielle Konkurrenten zu MySQL, einmal Percona und dann MariaDB.

Was tut also Oracle, um seine eigene Datenbank zu pushen und die Entwicklung der Konkurrenz zu erschweren? Sie sorgen dafür, dass gewisse Bugs nicht mehr öffentlich sind und stellen zu gewissen Features im öffentlich zugänglichen Quellcode nicht mehr die Testfälle zur Verfügung.

Die externen Entwickler sehen dann in Release-Notes meinetwegen nur noch, Bug 123 und 456 wurde behoben – was aber der Bug gewesen ist, das wissen sie nicht mehr. Das erschwert ihnen also die Entwicklung und das Gleichziehen mit dem Mutterprodukt MySQL gehörig.

Ebenso wird es ihnen erschwert, die Kompatibilität ihrer eigenen Forks noch zu gewährleisten, wenn Oracle nicht mehr die dazu notwendigen Testfälle bereitstellt.

Aus Sicht von Oracle ist das ein logischer Schritt: man behindert die unleidliche Konkurrenz, hofft darauf, dass die Benutzer auch weiterhin den Arsch nicht hoch kriegen sondern bei MySQL bleiben und man so verstärkt Supportverträge verkaufen kann. Diesen Effekt, die unliebsame Konkurrenz so trotz Opensource abhängen zu wollen verstärkt Oracle noch dadurch, dass sie MySQL mit einer brachialen Geschwindigkeit weiter entwickeln.

Also alles in allem eine Sache, die in der MySQL-Nutzerschaft sehr skeptisch aufgenommen wird und kritisch beäugt, wie man beispielsweise bei Kris Köhntopp nachlesen kann.

So, und nun zurück zu Second Life und der JIRA-Reform: die Parallelen sind mehr als offensichtlich. Linden Lab lässt die Entwickler von alternativen Viewern am langen Arm verhungern, indem sie alle Bugreports nun als privat markieren, dazu kommt auch die sehr schnelle Weiterentwicklung der eigenen Viewerlinie.

Damit macht Linden Lab nichts anderes als Oracle mit seinen Konkurrenten: man zeigt ihnen den Stinkefinger und trocknet deren Tümpel aus. Gerade dieser Schritt von Seiten Linden Labs ist nun wirklich mal brachialer und auch folgenreicher als die damals stark kritisierte Havok-Unterlizenz, die ja nur optional ist.

Mit dieser Maßnahme schadet Linden Lab den Entwicklern von Firestorm&Co. nämlich wirklich massiv, und viele bemerken das nicht einmal.

Die Kathedrale und der Basar und wie Fragmentierung einem Projekt mehr schadet als nützt

Eric S. Raymond verfasste und veröffentlichte 1996 einen der grundlegenden Essays zum Thema Opensource: „Die Kathedrale und der Basar.“ In diesem beleuchtet er genauer die unterschiedlichen Vorgehensweisen zwischen kommerzieller Softwareentwicklung und Opensource.

Herkömmliche Softwareentwicklung ist dabei für ihn die Kathedrale: es gibt einen Chefarchitekten, der genau bestimmt, in welche Richtung hin sich die Entwicklung bewegen wird, und dieser leitet das Projekt unangefochten.

Im Gegenzug meint er, dass Opensourcesoftware nach einem anderen Modell entwickelt wird, das er den Basar nennt: da jeder zu einem Projekt beitragen kann, gibt es wenn die Entwicklerbasis für ein Projekt groß genug ist, verschiedene alternative Ansätze zur Lösung desselben Problems, aus denen sich der Projektleiter das seiner Meinung nach am Besten geeignete rauspicken kann – oder man baut einfach beide gleichzeitig ein. Nach Raymonds Meinung ist der Basar wegen seiner Vielfalt der Kathedrale deutlich überlegen. Als erfolgreiche Bestätigung für dieses Modell sieht er den Linux-Kernel an.

Damit mag er Recht haben. Auch Opensimulator selber ist im Grunde so ein Basar: jeder, der zu diversen Problem beitragen will, der kann das natürlich gerne tun, und so ist es oft geschehen und geschieht es auch weiterhin. Auch ist zweifelsohne Opensimulator ein recht erfolgreiches Softwareprojekt: es gibt eine große Nutzerbasis, eine stabile Community um das Projekt und viele kennen es.

Dennoch hat Opensimulator in meinen Augen ein Problem, nämlich seine BSD-Lizenz. Das ist eine der zwei großen Opensource-Lizenzen, die es gibt.

Die bekanntere Lizenz ist von der amerikanischen Free Software Foundation die GPL. Die GPL selber wird auch gerne als virale Lizenz bezeichnet, denn sie besagt folgendes: hier hast du den Sourcecode, mach damit was du willst, solange du die Lizenz beachtest. Solltest du Änderungen an dem Projekt vornehmen und vertreiben, dann hast du auch diese Änderungen dem Projekt unentgeltlich zugänglich zu machen.

Oder anders gesagt: einmal Opensource, immer Opensource. Ein Beispiel dafür, was das genau bedeutet, ist das Android-Projekt. Die haben den Linuxkernel geforkt, jeder Smartphonehersteller nutzt dabei seine eigene Version inkl. Treibern und wegen der GPL sind sie dann dazu verpflichtet, diese Quellcodes der Allgemeinheit zugänglich zu machen. Das tun sie dann auch nach dem erscheinen einer Androidversion mehr oder weniger flott, und deshalb gibt es auch eine große Community an Custom ROMs und dergleichen mehr.

Die BSD-Lizenz selber ist liberaler, sie sagt nämlich nur folgendes: hier ist der Code, mach damit was du willst. Das einzige, was wir erwarten, ist dass du unseren Namen irgendwo nennst und fertig. Wenn du auf Basis dieses Codes kommerzielle Software entwickelst und verkaufen willst, dann kannst du das tun, den von dir auf unserem Projekt aufbauenden Quellcode aber musst du nicht veröffentlichen, wenn du nicht willst. Das ist genau der Gegensatz zur GPL, denn unter der GPL darf man das auch tun, aber muss eben den Quellcode mit den eigenen Änderungen veröffentlichen. Mehr Analysen zum Thema GPL und dessen Sinn liefert in gewohnt guter Qualität Kristian Köhntopp. Lesen!

Nun ist es so, dass Opensimulator die Basis vieler, kommerzieller Grids ist. Diesen kommerziellen Grids ist aber möglicherweise das Plain Vanilla Opensim nicht mächtig genug, weil ihnen da einfach gewisse Features fehlen oder sie ihnen nicht weit genug fortgeschritten sind. Das kommt ja vor, und warum auch nicht, das ist keine schlechte Sache, im Gegenteil es treibt zuerst einmal das Projekt voran und sorgt mitunter für die Entwicklung besserer Komponenten.

Das tut es nun auch tatsächlich, so manches kommerzielle Opensimgrid hat einen oder mehrere Entwickler, die beispielsweise eine bessere Scripting-Engine basteln, die Physik massiv aufbohren oder vieles andere mehr. Diese gridspezifischen Eigenheiten sind dann die Merkmale, mit denen die Grids unter anderem gegeneinander in Konkurrenz treten.

Nichts gegen Konkurrenz, und unter der BSD-Lizenz ist das auch alles erlaubt, aber das Ding ist dann dies: wegen der BSD-Lizenz besteht absolut kein Zwang, die Verbesserungen , Änderungen und Erweiterungen am Opensim-Code mit dem Projekt zu teilen. Was hier also faktisch passiert ist, dass es einen Haufen geschlossener Forks von Opensim gibt, die alle in house entwickelt und gepflegt werden, von denen aber je nach Politik des Entwicklers ggf. nur wieder sehr wenig zurück an die Community fließt.

Beispielsweise war das untergegangene Meta 7 Grid stolz auf seine eigens entwickelte Scripting Engine – und dann gingen sie pleite, die Engine verschwand mit ihnen. Wäre Opensim unter der GPL lizenziert, dann hätten sie diese veröffentlichen müssen und es ans Projekt zurückgeben müssen.

Nun sind Forks normalerweise kein Problem, solange gewährleistet ist, dass man noch innerhalb derselben Codebasis Quellcode tauschen kann. Das ist aber bei Opensim und seinen Abkömmlingen nicht überall unbedingt mehr gegeben.

Man stelle sich nur einmal vor, wie weit Opensim schon sein könnte, wenn es unter der GPL gestanden wäre und all diese netten Inhouse-Entwicklungen Bestandteil der Kerndistribution wären. Da es das aber leider nicht ist, ist das ein frommer Wunschtraum.

So aber bleibt es eben so, wie es ist: es gibt eine einigermaßen stabile Kerndistribution und viele, viele kommerzielle Grids mit ihren Eigenheiten. Sollte aber solch ein Grid untergehen, dann verschwindet mit dem auch dessen Inhalte und die auf deren Eigenheiten basierenden Dinge ziemlich sicher auf Nimmerwiedersehen. Das ist mit Meta 7 damals so geschehen, und keiner kann garantieren, dass nicht irgendwann noch andere Grids pleite gehen werden und dann das Spiel von vorne beginnt.

Schade, aber das ist eben so. Wer wirklich einigermaßen sicher in Sachen Opensimulator agieren will, der sollte daher besser nur die frei verfügbaren Komponenten einsetzen und sich nicht von irgendeiner Firma abhängig machen, die er kaum kennt, weil er gerade erst meinetwegen die Schnauze von Linden Lab voll hat.

Denn wieso sollte man sich von der einen, heftigen Umklammerung freiwillig direkt in die nächste begeben wollen? Wenn schon Freiheit, dann aber auch eben richtig!