You know, I’m not sure that you can. The more I dig into this, the less I think so. Or at least, not without a whole heck of a lot more work.
Formerly, Linden Lab licensed viewer source-code under the “GPLv2 with FLOSS exceptions.”
What the heck does that mean? It means that the basic source-code was licensed under the GPL (version 2) (and that anyone distributing it in whole or in part can only do so if they comply with those terms). The “FLOSS exceptions” part was a little add-on to let the code be linked to binary libraries (for sound, media decoding and so on) that would not ordinarily be permitted under the GPL alone.
That’s how it was.
Now what we have is the viewer source code bundled up as LGPLv2. Where’s the FLOSS exceptions? No longer there, because you can link LGPL code to proprietary binaries, and that’s okay.
But wait…
Let’s look at that briefly.
2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
- a) The modified work must itself be a software library.
- b) You must… etc…
Yes, there’s the kicker. If you modify the source code prior to distribution, the result must be a library. The LGPL is (primarily) for libraries. While the license mentions that you can apply it to applications, well… you can. It’s just almost useless if you do.
So, there are two ways out of this trap.
One, you can convert the entire viewer tree into a library, compile it that way, and write a wrapper program (licensed however you like, but probably under the GPL to satisfy Linden Lab) to jump into it and pretend it’s a whole application and that you didn’t have to do all of that in the first place.
Second, you can take all the LGPL code and convert it to GPL code as a one-time, one-way conversion.
Then your source is back to where we started before the LGPL was used, right?
Wrong.
You don’t have any FLOSS exceptions anymore, so none of that naughty linking to anything that isn’t also GPL compatible. Period.
Quicktime? Can’t have it. In fact, there’s a whole bunch of media decoders you can’t have, because GPL versions simply do not exist.
Voice? No.
And probably a dozen other things.
Okay, so someone tell me I’m wrong here, because the new system looks like a legal nonsensicality that makes it almost impossible to build third-party viewers without breaking the license terms… and that’s before we look at anything to do with the third-party viewer policies.
| You know, I’m not sure that you can. The more I dig into this, the less I think so. Or at least, not without a whole heck of a lot more work.
Formerly, Linden Lab licensed viewer source-code under the “GPLv2 with FLOSS exceptions.”
What the heck does that mean? It means that the basic source-code was licensed under the GPL (version 2) (and that anyone distributing it in whole or in part can only do so if they comply with those terms). The “FLOSS exceptions” part was a little add-on to let the code be linked to binary libraries (for sound, media decoding and so on) that would not ordinarily be permitted under the GPL alone.
That’s how it was.
Now what we have is the viewer source code bundled up as LGPLv2. Where’s the FLOSS exceptions? No longer there, because you can link LGPL code to proprietary binaries, and that’s okay.
But wait…
Let’s look at that briefly.
2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
a) The modified work must itself be a software library.
b) You must… etc…
Yes, there’s the kicker. If you modify the source code prior to distribution, the result must be a library. The LGPL is (primarily) for libraries. While the license mentions that you can apply it to applications, well… you can. It’s just almost useless if you do.
So, there are two ways out of this trap.
One, you can convert the entire viewer tree into a library, compile it that way, and write a wrapper program (licensed however you like, but probably under the GPL to satisfy Linden Lab) to jump into it and pretend it’s a whole application and that you didn’t have to do all of that in the first place.
Second, you can take all the LGPL code and convert it to GPL code as a one-time, one-way conversion.
Then your source is back to where we started before the LGPL was used, right?
Wrong.
You don’t have any FLOSS exceptions anymore, so none of that naughty linking to anything that isn’t also GPL compatible. Period.
Quicktime? Can’t have it. In fact, there’s a whole bunch of media decoders you can’t have, because GPL versions simply do not exist.
Voice? No.
And probably a dozen other things.
Okay, so someone tell me I’m wrong here, because the new system looks like a legal nonsensicality that makes it almost impossible to build third-party viewers without breaking the license terms… and that’s before we look at anything to do with the third-party viewer policies. | | | |
This entry was posted
on Thursday, 2nd September, 2010.
You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.
Possibly related posts
Linden Lab alerts third-party viewer developers to active security exploit, Second Life viewer development build with “Basic” and “Advanced” modes, Third-party Second Life viewer developers call bullshit on Linden Lab GPL-violation claim, Experimental Imprudence build, Second Life third-party viewer directory myths
I almost wonder if this has been written in as a hammer to be used in the event that a viewer proves itself to be malicious – because the rule won’t enforce itself, only LL will. I think the intention is to have a trapdoor to quickly dispatch a malicious viewer. I mean, by the TOS, Phox, Fractured, et. al., could have all been kicked out as soon as the DDOS incident came to light – but LL showed considerable restraint in their actions. Perhaps they did so as a chess maneuver, taking the “keep your friends close and your enemies closer” approach – knowing it’s easier to track a name you know than it is an alt that you don’t know. But we shall see. I don’t know much about the Snowstorm project, but perhaps this might be an attempt to nudge TPV developers into that stable rather than having them work, benevolently or malevolently, as rogue coders.
To be clear, the FLOSS exception only allowed linking to software licensed under a specific list of approved free/libre/open-source software (aka FLOSS) licenses. There was no exception that allowed linking to proprietary libraries (such as Quicktime or Fmod).
Voice is not an issue, at least how it’s currently implemented. The voice components are not linked or even loaded by the viewer, bur rather are in a separate executable that the viewer communicates with via IPC (inter-process communication). That’s valid under both the GPL and LGPL.
Media support is also not really a problem, because of the new SLMedia plugin architecture. The plugins are run as separate processes that communicate with the viewer via IPC and shared memory. So, it’s possible to use GPL-incompatible (or even completely proprietary) media plugins, for the same reason it’s possible to use a proprietary voice program.
The real problem with the lack of FLOSS exception is that there are certain GPL-incompatible libraries that are vital to the viewer architecture. In particular, APR is tied up with many, many parts of the viewer, such that even if a suitable replacement library could be found, it would be a monumental task merely to modify all the source files where APR is used, let alone test that everything still works right.
What’s more, I’m not sure the LGPL would allow linking to incompatible lirbaries, either. I’m not a lawyer, and apparently there are several interpretaitons of this, but my interpretation of the LGPL is that there is a big difference between a non-(L)GPL application using an LGPL library, and a LGPL application using a non-(L)GPL library. In other words, it doesn’t go in both directions, and an LGPL viewer is on the wrong side.
There’s also the fact that none of the many, many GPL-licensed viewer patches can be applied to the LGPL source. So, even if you can use the LGPL source to make a viewer, you’d need to re-invent over 3 years worth of open source innovations. Meanwhile, you’d also have to revamp the UI to make it palatable to users who dislike the Viewer 2 UI.
So, to answer the question posed by the title: Yes, you could, in theory, build a third-party viewer with the new LGPL’d source. But it would be a hell of a pain in the ass.
Nitpick alert!
Jacek said: “There’s also the fact that none of the many, many GPL-licensed viewer patches can be applied to the LGPL source. So, even if you can use the LGPL source to make a viewer, you’d need to re-invent over 3 years worth of open source innovations.”
True, unless you created those same patches, or maybe know who did. In the first case, you own the copyright, and can use it under any style license you wish. If someone else write it, you may be able to get permission from them to use it under another license. A pain in the butt, but perhaps not a massive one in all cases. Just get the creator of jiggly boobies on board, and you’ll make many users happy.
As a matter of fact, LL wouldn’t have been able to change the viewer to LGPL at all without the contribution agreements that they had all external coders sign. Without those agreements, any code contributed to LL would have had to remain GPL. So, at least, any third party patches that made into the LL viewer are safe for inclusion in an LGPLed viewer.
I’m actually a little puzzled as to the reason for the license change. The only real benefit I can see to a switch to LGPL is in an effort to be less frightening to the lawyers of any corporation that might want to get involved in viewer development. BSD or MIT are usually the best choices for this, but LGPL doesn’t have nearly the stigma GPL has in that case, and provides a way to keep proprietary secret-sauces secret. Maybe Oz has given a clearer “whyfor”, but if he has I’ve forgotten it.
Marcus (you’re not the same marcus from my local LUG are you? weird timing):
If someone else wrote the patches and then had LL accept them the contribution agreement lets LL relicense it.
Personally I think LGPL is one of those licenses that really confuses things massively, I’d never bother using it myself. GPL if you want copyleft, BSD/MIT if you don’t, WTFPL if you don’t care, or my own favourite, the IRC paste license:
“I’ve probably not tested this code and it won’t even work, do whatever the hell you want with it just don’t try to make me liable and don’t claim you wrote it”
Does anyone know if the viewer includes the “or any later version” clause? Or if there’s something in the LGPL which allows for “upgrading” to full GPL? It’s not like the FSF to make a license purposely incompatible and I admit i’ve not studied the LGPL all that much – i’m very much a plain GPLv2 guy who doesn’t like LGPL or Affero GPL.
Why didn’t LL learn from their past mistakes?
See http://blogs.secondlife.com/community/technology/snowstorm/blog/2010/09/07/what-does-the-lgpl-mean-for-second-life-viewers
Oz just posted this:
http://blogs.secondlife.com/community/technology/snowstorm/blog/2010/09/07/what-does-the-lgpl-mean-for-second-life-viewers
When asked on IRC about the concerns, that while it’s allowed to link LGPL code into arbitrary licenced code, the other way around —linking arbitrary licensed code into LGPL code— might not be a allowed, he answered:
“linking is linking – there is no ‘into’”
Personally my favorite license is the Beerware license
/*
* —————————————————————————-
* “THE BEER-WARE LICENSE” (Revision 42):
* [Name of author] wrote this file. As long as you retain this notice you
* can do whatever you want with this stuff. If we meet some day, and you think
* this stuff is worth it, you can buy me a beer in return
* —————————————————————————-
*/