Monday, September 20, 2010

Linden Lab to TPV developers: No KDU for you!(Updated)

During the final months of the now-banned Emerald viewer, one of the major scandals that hastened its' demise was the emkdu library that Emerald used was hacked to send user info to Modular Systems without the knowledge or consent of the user. As a result of the discovery, Emerald was forced to remove emkdu.

In the aftermath of Emerald's demise, Linden Lab has made a few drastic changes. First and most important, they have changed the license of the official 2.x viewer from GPL to LGPL. Second, they are no longer going to release llkdu as a DLL. They will statically link llkdu into the viewer binaries. Third, they are playing copyright cops by threatening to delist, ban or block TPVs that use KDU code without obtaining a proper license(claiming it is a GPL violation).

Why is KDU important? Well, it's the code used to render textures in-world. The advantage KDU has is that it renders textures faster than the open source equivalent, openjpeg. However, KDU's speed advantage seems to be negligible on machines with modern graphics capabilities. So it makes a difference only on lower-end machines.

My personal opinion on it is this: There's only two proper solutions for TPV developers: either switch to a 2.x codebase and obtain a KDU license(not cheap, by the way), or obsolete KDU by modifying openjpeg to match or outperform KDU.

The former solution is apparently what LL is betting TPV developers will not do. They must think that they will simply fall back on stock openjpeg, and as a result virtually all TPVs will be "inferior" to their own viewer. It's clearly a power play by the Lab, once you look at the bigger picture.

However, Kakadu does not have a monopoly on JPEG decoding and rendering. TPV developers can either enhance openjpeg, or switch to another open source library such as JasPer(Google "open source jpeg2000 library" for more possibilities) and work with that. And as a form of protest against LL's power play, TPV developers should temporarily not contribute JPEG library changes back to LL. If LL wants the improvements, they'll have to go out and download them, just like TPV developers do to incorporate LL changes.

Update:  It seems that KDU, if by what folks on SLU are saying is true about KDU vs. openjpeg speed, then ultimately KDU is merely a crutch for older and low-end machines. So ultimately, the KDU problem may solve itself when SL users upgrade their lower-end machines.