On 6/28/09, [email protected] <[email protected]> wrote: > On Jun 27, 2009 4:31pm, Aidan Thornton <[email protected]> wrote: > When I read this on here it surprised me. Enough to go "Wow that's so > blatantly against the gpl, how are they getting away with it?". So I looked > at the page. And.. that's not what it says at all! It could not even > remotely be interpreted to say that. As some random third party, normally I > wouldn't reply. But that's just rude to post such lies here in public. You > obviously have some hidden agenda, and are trying to make it look bad.
Ah, I beg her pardon. The licence doesn't forbid all modifications to the patch, just non-trivial ones; bugfixes and porting to newer viewers are allowed. It does forbid sale of the code (and possibly any viewer containing it) and distribution of the viewer source with the patch applied. It also restricts what other modifications you can make to the viewer if you want to distribute viewers with the patch applied, though the exact limitations are vague. Each of these restrictions still makes it GPL-incompatible, non-open source and non-DFSG compliant. (In fact, they're classic examples of restrictions that do. Nothing new under the sun, etc.) On 6/28/09, Michael Schlenker <[email protected]> wrote: > Aidan Thornton schrieb: > > > Hi, > > > > On Tue, Jun 16, 2009 at 4:48 PM, Marine Kelley<[email protected]> > wrote: > >> Hi all, > >> > >> Sorry for making this message sound like a rant, but it seems that the RC > >> viewer has finally gone gold... without any prior warning. As a result, a > >> lot of people are now asking me when the compatible Restrained Life viewer > >> will be out, while I have not even finished working on my latest version. > I > >> am now forced to release a half-done viewer (it is operational, it just > >> doesn't have all the features that I had planned to add for 1.23) so that > >> people can just keep using it. > > > > Okay, so your Restrained Life patches are closely tied enough that > > they break on viewer updates? I could be wrong, but that's probably > > not helpful to your argument that they're not derivative works and > > therefore releasing them under your non-GPL compatible, non-open > > source license[1] is OK. > > Read her patch. One part could maybe be argued as derivative work if you > were nitpicking, the major part is not. I guess she could release the > part that look like derivative work under GPL, BSD or some other > permissive license, their mostly trivial, worthless but harmless without > the other part, as they just add some trivial hooks to the GPL'ed viewer > code. No, the part that "just adds some trivial hooks" is not harmless without the main part. In fact, if you just apply that part of the patch, the viewer won't compile anymore! That's because it doesn't actually add hooks, but direct calls into the main Restrained Life code, and the other things it does are even bigger issues. The patch changes the viewer behaviour directly, by modifying the viewer code itself in many places to check the Restrained Life status and behave differently. (Said status is stored and queried via RRInterface.cpp/h, which is another reason the parts of the patch can't be separated.) Pretty much all the enforcement of restrictions is done via direct modifications to the viewer code - with the exception of chat handling, the only code in RRInterface.cpp/h called for restriction enforcement is generic helper functions. There's even non-trivial Restrained Life-related business logic in the "trivial" part of the patch, for example the way teleportViaLocation tests if teleporting is allowed[1]. Oh, and a fairly large chunk of Restrained Life code is added directly to LLAppViewer::mainLoop and another to send_chat_from_viewer. Basically, it's a highly intrusive patch to the viewer, you can't seperate RRInterface.cpp/h from the changes to the viewer source code itself since they're so heavily interdependent, and the viewer changes are non-trivial and make up a substantial part of the actual Restrained Life code. (RRInterface.cpp/h just handles RL commands, does forced actions, stores settings and contains some generic helper functions. *All* the enforcement decisions are made in the changes to the viewer code.) Finally, if she did relicense just the viewer changes under a GPL or BSD license, it'd be a significant change - the current license forbids any change that "makes the viewer react differently to commands in the script/viewer protocol", which is pretty much any significant change to any part of the patch (including the bits that modify existing code). > > > (Especially as you're distributing compiled > > viewers containing them too.) > > This is technically wrong, Marine does NOT personally distribute > compiled viewers herself... Errm... yes she does. She hosts them on a third-party site, http://www.erestraint.com/realrestraint/ but they're her compiled viewers. > > > [1] http://realrestraint.blogspot.com/2009/03/rlv-license.html - > > forbids modification, distribution of the SL source code with the > > patch applied, distribution of binaries that contain both the patch > > and any other major changes compared to the official viewer, and sale. > > Each of these restrictions is GPL-incompatible. > > > If you read the license there in depth you'll see that its not really a > GPL issue. There is just a single step thats questionable and GPL > incompatible, and that is combining the patches to produce a binary and > distributing that. As GPL is only concerned with distribution its > perfectly legal to patch the source on your host and compile it, and > Marines license allows just that. The GPL also forbids distribution of derivative works under a non-GPL license. The patch itself contains major changes to existing viewer code, so there's an argument that it's a derivative work. GPL proponents would also argue that the interaction with internal data structures makes RRInterface.cpp a derivative work too. > One could discuss if Marine should split her patch in two parts, one > part that modifies the viewer code (mostly adding trivial callbacks in > the right spot, thats the part that breaks with every single viewer > update, because it adds a policy based rights management to most > user<->in-world interactions) and one that provides the implementation > of the rights management code. If she put the the rights management code > into its own DLL and just did runtime linking like llkdu does it would > be fully okay. Perhaps, but you're talking a major rewrite. In addition to a significant proportion of the code being integrated into the viewer code itself rather than cleanly separated, the code also interacts with viewer-internal data structures which aren't guaranteed to be stable across releases, or even across different compiler versions. Plus, it wouldn't even necessarily fix the GPL compliance issues. (Remember, the GPL is *intended* to forbid this sort of addition.) > > I had that argument with her via mail when she published that license > and her response and thoughts about the issue are pretty well thought > out. So yes, you could try to ban the binary distributions as a GPL > violation, but thats it... > > > Michael [1] The rule is: if RL is enabled and (the avatar is teleport locked OR (the avatar is sitting and is banned from getting up)) _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
