Regarding LLKDU

Yesterday afternoon, Linden Lab held a meeting of third-party viewer developers to inform us of some policy changes and implications for open-source viewers. One significant issue is that Linden Lab now considers the use of the LLKDU image decoder library by GPL-licensed third-party viewers (such as Imprudence) to be a violation of the GPL. Therefore, all GPL-licensed third-party viewers have been instructed to remove the ability to load and use LLKDU.

A little bit of background information: LLKDU is a wrapper library around Kakadu, a proprietary JPEG2000 image codec. It is used in the Second Life viewer to decode textures downloaded from the server, and to encode images that you upload. There is an open source alternative library called OpenJPEG, which Imprudence and most other viewers use by default. However, OpenJPEG is considerably slower and less stable than Kakadu, so many third-party viewer users have found it beneficial to copy LLKDU from their Second Life installation to their preferred viewer. Linden Lab is instructing us (and all other GPL-licensed TPVs) to modify the viewer so that it will not use LLKDU, even if the user does copy it.

It is our strong belief, based on careful reading of the GPL, that Linden Lab’s claim of a GPL violation is baseless and without merit. We do not distribute any proprietary Kakadu code, nor is any such code compiled or linked into the Imprudence Viewer executables. All other libraries in the viewer are linked at compile time, and the viewer contains small parts of the libraries’ code (known as header files). In contrast, LLKDU is optionally loaded at run-time if present, using a different method known as Dynamic Shared Object (DSO) loading. The code for loading LLKDU in this way was created and released by Linden Lab under the GPL as part of the official viewer source code, and has been included in the Second Life viewer and third-party viewers for years.

The real issue, in my opinion, is not a matter of GPL violation. Rather, Linden Lab has been making a serious licensing mistake for the past several years by distributing the LLKDU files in a form that could easily be used separately from the Second Life viewer. They are now trying to correct that mistake, perhaps under pressure from the Kakadu creators. The claims of GPL violation are paper tigers meant to scare us into modifying the viewer, to avoid compounding their mistake (and their legal liability).

Despite our firm belief that Linden Lab’s claims are baseless and not in good faith, we will remove the Imprudence Viewer’s ability to load and use LLKDU in the near future, as soon as it is feasible for us to do so. This is not strictly necessary under the terms of the GPL, but we will do it out of courtesy and consideration of Linden Lab’s sensitive situation.

We have been preparing two new releases for this weekend: Experimental 2010.09.18 (which will be released later today), and 1.3.0 RC3. These versions had already been scheduled before Linden Lab’s meeting, and will be released with LLKDU support intact. Depending on how RC3 performs (i.e. the number of significant bugs), the 1.3.0 final release may or may not have LLKDU support. Future Experimentals, after this weekend, will not have LLKDU support.

We understand the inconvenience this will cause for many of our users, who encounter texture errors or stability problems when using OpenJPEG. We will be working to address those issues as much as possible. For Mac users, we have some very good news: Elektra, our new Mac dev, is working on replacing OpenJPEG with CoreImage, a system library included in Mac OS X. This is expected to boost texture performance and reliability on Mac, well beyond even what LLKDU provides. Unfortunately there is no similar magic bullet for Windows and Linux, but we will do our best to get OpenJPEG working well for as many people as possible.

Thank you for your patience during this transition, and thank you for using Imprudence!

36 Responses to “Regarding LLKDU”


  1. Peter Stindberg

    Thank you very much for this extensive explanation. When I read the first reports I had a different suspicion, but your explanation makes more sense.

    I look forward to Elektra’s magic.

  2. Gavin Hird

    Yeh, looking forward to seeing CoreImage being put to use.

  3. DarkStorm Paine

    This is going to kill the TPV use of those of us whose older machines really need the benefit of using the llkdu.dll to load graphics. I’d had some recent admiration and appreciation for LL’s work on ridding SL of cretins and the improvements I saw coming in the main viewer via updates about Snowstorm I’ve seen but this… this just cripples TPV’s unnecessarily. I can’t tell you how this saddens me. Phoenix is unusable to me for this very reason and I am afraid that this will be the case for Imprudence for me as well once the non-llkdu versions are released. I am sorry this happened and cannot express how damned sad and angry this makes me.

    DarkStorm

  4. Burnman Bedlam

    Thanks for the update!

    Forcing this issue also gives LL a way to reduce the quality of Third Party Viewers, forcing people back to their own home grown abomination… V2.

    I will continue to use Imprudence regardless of what library is available, and with luck, a viable alternative will surface in the future.

  5. Wayfinder

    I appreciate what you’re saying here and agree. Your assessment also seems right on the nose.

    What I dislike in the extreme however, is the number of people who just cave to Linden Lab’s whims… legal or not.

    What ever happened to standing up for what is right? What happened to filing a class-action lawsuit? What ever happened to looking an unethical and dishonest company in the face and saying, “What you’re doing is wrong and even illegal. Continue, and we will take action.”

    In other words, what happened to people showing a little guts?

    You already summarized the legal issue. You’re not copying the proprietary library module. That module already exists on the customer’s computer, by license. All that’s happening is that your code is taking advantage of a module that is already there. To my knowledge, there is nothing even remotely illegal or even unethical in such a process.

    Since this is an apparent “paper tiger” move by Linden Lab… then what about the option of saying, “We believe Linden Lab is incorrect in this matter and we will not comply. If your company attempts to force this issue, we will take whatever legal action necessary in response.”

    I believe if customers had done so more in the past, we would be experiencing far less of this dictatorial attitude that seems to be currently cropping up from that company on a regular basis. They tell us we can’t export our own builds if they contain items from any other creator (even public domain textures and other public domain items)… when they have no legal right to insist on that. The TPVs caved to that policy as well instead of fighting it. What, should we all just bend over any time Linden Lab picks up a switch?

    Maybe it’s time for people to show a bit of spine and simply say, “No, we’re not going to comply with that policy whim.” If we keep cringing every time the bully shows a fist… that bully will continue doing so.

  6. Emilie

    The use of llkdu is required by tpvs in order to avoid massive differences in rendering ( Refer e.g. http://emilie.hermit.net/?q=node/717 ). It ought to be possible to make a patch to restore the calls to llkdu after its removal, requiring only patch application to restore full functionality to any tpv so crippled. The risk here is that depending on how such a patch is distributed, it could become contaminated. As such it is to be hoped that some mechanism to validate patches provided via a separate site operated by a non-tpv affiliated developer be established, as this would prevent LL from acting against the developers or the tpvs which would be and would remain compliant with LL’s insanity. Should this not be done, a current llkdu and appropriate diffs would likely be created and distributed anonymously to repair broken tpvs without appropriate contamination prevention measures, resulting in a significant increase in risk to users and the system due to LL’s lack of forethought and investment in enabling use of SL as its user base has already and massively indicated it prefers.

  7. Morgaine

    Good call, Jacek. I agree 100% that LL’s claims of GPL violation are baseless, a fact that should be very clear to anyone who understands that the GPL (like all open source licenses) triggers at the time of distribution only, and Imprudence is not being distributed with LLKDU.

    From an open source perspective, I think you’re doing the right thing in removing support for this closed source module. However, one should be able to load other modules dynamically, especially when Imprudence is being used in Opensim.

    Morgaine.

  8. Solo Mornington

    Burnman Bedlam says: “Forcing this issue also gives LL a way to reduce the quality of Third Party Viewers, forcing people back to their own home grown abomination‚Ķ V2.”

    I seriously doubt that’s their intention. I agree with Jacek that LL have probably been in error to distribute the code that allows Kakadu to be used in this way. However, the reason they’d do such a thing in the first place is to improve the quality of third-party viewers, with a sort of nod and wink approach. That way, someone using a third-party viewer has a better experience of SL. It seems LL is under some licensing pressure of their own, so they’re trying to assert some control over the process. I can’t blame them; they have a lot at stake.

    I think Imprudence project is taking the right tack: Release what they’ve got, and comply in the next iteration. I also hope LL can figure out what they really need to do. And… CoreImage? Oh yeah. :-)

  9. phacelia

    Fred Rookstown, maker of the Luna viewer, just invited “all TPV and OpenSim Devs” to “come together and create our own fork of OpenJPEG that is stable, usable, and efficient.”

    http://www.sluniverse.com/php/vb/alternative-sl-clients/49256-invitation-all-tpv-opensim-devs.html

  10. Crim Mip

    It sounds like you’re right. LLKDU really shouldn’t ever have been usable by other viewers. However that being the case, the ethical thing would likely be for LL to stop using it as well. I obviously don’t expect that to happen.

    Alternatively, did they say that TPV’s couldn’t licence their own from Kadaku and make it available as an option download separate from the GPL’d code. I’m not sure how that would go over given what the Emerald devs did with it. Kadaku really ought to publish some sort of way to check that the library hasn’t been modified.

    My understanding was that there was another open source library that was much faster than OpenJpeg. I don’t recall the name as I’m not a coder.

    Ultimately it doesn’t matter very much to me personally. I noticed very little difference with or without llkdu and am running the experimental version of Imprudence without it.

  11. Andros Baphomet

    Personally, I’m torn. From an open source perspective, I would love to see less dependence on closed-source binaries. On the other hand, the current open source solutions for what needs to be done really, really suck. And folding to LL like this is a mistake, especially when they’re doing it for selfish reasons, and especially when they’ve treated TPVs with barely veiled contempt. I can just see some Linden gushing about the LL viewer’s speed and stability compared to those crash-prone TPVs, especially after they tried to force them all to be that way. Why should you all help them?

    LLKDU support shouldn’t be removed until there is a stable and usable alternative available. And that will take some time, especially with the people trying to improve OpenJPEG doing it in the spare time they don’t have committed to improving their own TPVs. As such, I imagine it will take something on the order of 1-2 years before significant progress is made. (I’d help myself, but I know almost nothing about JPEG2000 decoding, and less about *efficient* JPEG2000 decoding.)

    Until there is a useful solution in place, I would implore you all to reconsider this move. The rationale behind it is poppycock, and the quality of the viewers should not be compromised to avoid embarrassing the Lindens.

  12. Nikki

    LL is trying to plug the loophole for EmKDU rather than LlKDU. They have to do that to prevent any linking to the library. So it is not really about LlKDU per se, but about preventing any resurrected Emerald from doing any further harm.

  13. Winter Seale

    Yeah, it’s a weird place, where yes, linking a proprietary library into a GPL app is clearly a violation. Except that the copyright holder distributed the link, and people redistributing the source code are not obligated to patch it in any way, on copyright terms.

    Aren’t they switching the viewer to LGPL soon? It’s very clearly not a violation of the LGPL to link to proprietary libraries, so when that time comes I can’t tell what their argument would be.

  14. Beezle

    I’m thinking the “GPL” is smoke and mirrors and they’re actually trying to prevent the abuse that occurred with a hacked “__kdu” in that green viewer . . .or something. I’m just not buying the “licensing issue” argument, especially when it comes to the end user copying over files, and not actually being distributed by the TPV developers.

    I’ve also noticed that links to LL source for older clients is broken. I’m not sure whether this was intentional or whether it’s LL’s basic inability to keep things functional, though.

  15. Eris Asphodelia

    It’s possible I’m misunderstanding the essence of the issue, but would it be sufficient to selectively disable LLKDU only when connected to Linden’s grid, but permit loading it when connected to other grids?

  16. Ron Overdrive

    @Wayfinder: You’re forgetting something. In the world of Law, Guts requires Money. LL is a multi-million dollar company with an expensive legal department. They would easily outlast us in court. Also because an alternative is actively available and used, OpenJPEG, the FSF/GNU legal reps won’t help us on this.

    @Winter: All the source code in the Vanilla 2.x tree as of August and on as a part of the SnowStorm Project is LGPL. LL did not and will not re-license SL 1.23/SnowGlobe 1.x as LGPL so it will forever remain GPLv2+FLOSS.

  17. Troy McConaghy

    I look forward to trying Imprudence using CoreImage on my Mac. It sounds sweet!

  18. Martin Martinette

    @phacelia, Fred Rookstown is also formerly the leader of the PN as N3X15 and prohibited from ever logging onto Second Life, so I’d take whatever he has to say with a grain of salt.

  19. Boy Lane

    I just wrote a longer posting on my blog.

    It’s so super straight forward to prove LL’s accusation completely wrong. You can compile a viewer binary without any KDU lib present, it therefore can not be linked in any way. Still the viewer will find and use llkdu if you copy that into your installation directory. No GPL violation at all.

    COMPLETE FAIL

  20. Michael

    Is the CoreImage stuff available in the git repository somewhere?

  21. Mimika Oh

    Adding CoreImage while removing Quicktime? Seems inconsistent.

  22. Ron Overdrive

    @Mimika actually we’re not removing QuickTime, we’re removing Gstreamer. At current time Imprudence has no QuickTime elements in it as it was removed early on because it would be considered a GPL violation to use it. The GPL has a “System Library” exemption that permits the linking against of libraries supplied by the OS. In this case all the Core libraries included on OSX fall under the System Library catagory so no GPL violation using them. Its still in the air if we want to use CoreVideo (which is basically the system library for QuickTime) for OSX’s media backend or if we want to keep it under one media backend.

  23. David Ferraris

    I was an enthusiastic Emerald user. I log in from an Intel-based laptop (i945 chipset), and my OS is Linux. I didn’t have any problems with Emerald up to the 1636 release. Indeed, I used it because it was the only viewer that worked for me (not even the official LL viewer works on my box). I had been trying other viewers, including Imprudence, and didn’t have any luck until today. I am currently logged in with Imprudence (which before used to be completely non functional as I wasn’t even able to rez myself). I activated the Advanced menu, went to Rendering, and *disabled* object-object occlusion. And Shazam! I rezzed. It’s not as beautiful as Emerald with KDU (yet), but it enables me to rez, which is a good start. I want to thank the developers! By the way, I heard about a library called Jasper, which could be an alternative to KDU.

  24. Mimika Oh

    @Ron Thank you for clarification. QuickTime is supplied by Mac OS. There is no GPL problem using it for Mac OS users, just like CoreImage, and it has advantages.

  25. SKK

    About LLKDU the custom open jpeg from Kirstens S38 is open source and is already faster than the latest KDU.

    Jasper is nice but way too slow to be a nice alternative.

    About QT of course it is nice for mac, but is really a pain in the ass for PC user Linux and (even if less) windows user.

    why not letting QT suport for mac (as the best solution for them) and use another stuff for our machine?

  26. SLB

    I just wanted to say that this post is absolutely enlightening and undoubtedly shows the competence of the team. I’m following the development of this viewer with much interest along with some other ones, and I’m glad to see seriously professional people working on it.

  27. Fender Strangelove

    From what I saw on the Kakadu website, a license for their product is $250… if 250 Imprudence users chip in one dollar each… isn’t that enough for the license?

  28. Thraxis Epsilon

    Please notice that this requirement of removal only affects NON-Snowstorm based versions of Third Party Clients. That means any client that is not based on the 2.x interface.

  29. PocoLoco Darwin

    @Fender
    I think you missed this part on the page quoting $250/lic for non-commercial use


    A non-commercial licence allows you to use the SDK to build Applications for your personal use. It is applicable where the licensee receives no commercial and/or financial benefit. It does not permit you to distribute or use any Applications. This licence can only be purchased by individuals, Academic Institutions, not-for-profit organizations and libraries which do not generate revenue by using this software

    My reading sees this as a Personal Use lic expressly not for distribution. Such a license would not help the current situation.

  30. Fender Strangelove

    @PocoLoco
    I did see that, it’s #3 in the list. However, #4 says:
    “The Licensee shall have the right to Deployment of the KAKADU software, provided that such Deployment does not result in any direct or indirect financial return to the Licensee or any other Third Party which further supplies or otherwise uses such Applications.” There is a little more to it but the gist seems to say (to me) that as long as someone is not trying to make money with the Kakadu software, “deployment” is allowed under the license.

  31. Ron Overdrive

    @SKK: The only problem with Kirsten’s Viewer is that its tailored for high end machines for machinamists and his S20Jpeg reflects that. If you look at Kirsten’s minimum specs its the same as LL’s recommended specs as it requires a Cuda/OpenCL capable GPU. We might be able to use that for a performance version, but not for our normal distribution.

    The only problem I can see with having multiple media backends is just that, you’re working with 2 backends instead of one. Its a challenge as it is working with multiple texture decoders.

    @Fender & @PocoLoco: Like Thraxis said TPV’s based on SL/SG 1.x are basically now being forbidden to have a llkdu drop in regardless if we have a license or not. Only SnowStorm based TPV’s may use KDU if they can present to LL a copy of their Kadaku license then you will be given a copy of LL’s wrapper. You’re not allowed to make your own wrapper even with SnowStorm.

  32. Zorin Frobozz

    Does llkdu really make much of a difference? I’m watching the texture console as things rez, and with and without llkdu, the “DEC” step is such a quick blink I hardly notice the letters there. I can’t even tell if the blink is faster with llkdu; it’s nearly instantaneous.

    The bulk of the delay is waiting for the darned textures to be sent by the sim. The decode step is a drop in the ocean. So why is this such a huge deal?

  33. Sneeker

    @Zorin Because it is unstable and sometimes textures never load. This includes sculpt maps which means some objects never load. And on older machines seconds are as minutes.

  34. Sneeker

    Personally I am fed up with LL. I already started a dispute with them in the California BBB because they stole $20 from me and manipulated me into not disputing it or they ban my account for life. I was going to reinstall this after doing a fresh install of xp but now I am hesitant. LL are just a bunch of crooks and its time I looked elsewhere to spend my time/money.

  35. Redwood Rhiadra

    @Fender

    There’s a difference between “deployment” and “distribution”. Deployment means you can use it in an application and install that application onto other machines you control.

    Distribution of applications (i.e. giving them to other people) is expressly forbidden.

  36. Ron Overdrive

    @Zorin: If you have a modern machine with a decent graphics card that hovers around or exceeds LL’s Recommended Specs you won’t notice a difference. Majority of users fall somewhere between their Minimum and Recommended Specs which will see a performance boost from using KDU. Only time you will notice a problem with OpenJPEG with a newer machine is if there is a bug or glitch affecting OpenJPEG’s stability.