Linden Lab and the Kakadu discussion
Sunday, September 19, 2010 9:13:55 AM
You may have heard of the troubles and neverending stories about the Emerald viewer that used an exploit in the Kakadu (KDU) library that they distributed with their viewer to collect user data. LL reacted on this and several other violations and banned Emerald. As a side effect we now also have a discussion about the usage of that 3rd party Kakadu library that seems to get a bit out of control.
As a starter, Chalice posted the following today in SLU from Oz Linden:
Oz Linden: - Use of KDU
Linden Lab does consider use of our existing llkdu.dll in any TPV to
be a GPL license violation, whether or not you distribute it.
- We will shortly be changing our viewer builds such that KDU will not
be in a dll (it will be statically linked).
- We will no longer be distributing a dll containing KDU.
Linden Lab will cooperate with other viewers on closed-source
development of a KDU wrapper that we can share, but only with viewers
developers who can show us evidence that they have a KDU license that
allows them to distribute applications containing KDU.
I don't want to make that long, so let's get straight to the facts. The Kakadu library was developed at University of New South Wales in Aussie land and is marketed by an commercial offspring. It is a JPEG2000 (graphic format) de/encoder and licensed/used by LL in Secondlife.
The llkdu library is used in different versions for Windows/Mac/Linux viewers; and the situation so far was that due the licensing status of SL (GPL) and KDU (commercial) it was not possible to redistribute KDU with a third party viewer. No big deal, as one could simply take the official Linden version, copy that into their viewer installation, and voila, you had accelerated graphics.
What changes now? LL says if a TPV is capable of using KDU in any way, they would consider it a violation of GPL. Which is basically right from the point of view that a TPV binary would link to that KDU library or the library itself would be re-distributed with that particular viewer.
But, the devil is in the details. The KDU library is not, and was never, linked to SL or a third party viewer. It behaves like a black box that accepts commands, and gives the corresponding output back to the viewer, in form of de- or encoded graphics. Just the very same like SL uses ones proprietary (read: not GPL licensed) video or sound driver to display it's output or make some noise .
Legal merrygorounds here. Again, back to the facts. A TPV developer can compile their viewer without having any KDU library present. That clearly means it is not linked, neither dynamically nor statically to the resulting viewer binary. As such it can never be a violation of GPL, as Oz Linden claims in the quoted posting above.
Why is that so? The viewer checks for the presence of llkdu, and if it can find it, it will use and control it via some API interface, which are a handful of commands to import and export data. If the viewer can't detect llkdu it will use openjpeg (which does the same, just slower) instead.
In summary, the llkdu library is not linked to the viewer binary, as such there can not be any GPL violation, and LL has no legal leverage on any developer whose viewer works with any KDU library, either LL's version or any other like emkdu from Emerald.
What does it mean for Rainbow/Cool? Nothing . The KDU library is not linked to the viewer, nor is it re-distributed in any form. The viewers, although no longer updated, are in perfect compliance with GPL and TPV and there is absolutely no risk to use them to connect to SL.
Sorry for the long posting