[sldev] RLV breakage, derivative works, and non-GPL patches

[Michael Schlenker]

Aidan Thornton schrieb:
> On 6/28/09, danteferret at gmail.com <danteferret at gmail.com> wrote:
>> On Jun 27, 2009 4:31pm, Aidan Thornton <makosoft at googlemail.com> 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
Non open source by what definition? You get the source, so..., but your
right if you talk about libre/free software or some of the more
restrictive definitions.

> On 6/28/09, Michael Schlenker <schlenk at uni-oldenburg.de> wrote:
>> Aidan Thornton schrieb:
>>
>>> Hi,
>>  >
>>  > On Tue, Jun 16, 2009 at 4:48 PM, Marine Kelley<marinekelley at gmail.com> 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! 
Sure, as always when you add #includes and don't have the include files..
> 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.)
Oh, really, i guess it would take about 1-2 hours to turn all those
things into simple generic callbacks and just dynamically load the
interesting parts, but your correct with the patch as it is right now.

Its really not much more than adding policy based security/restriction
hooks but done in an inline fashion instead of a cleaner seperation. A
lot of that code would even be interesting for standard viewers like the
rotate avatar, teleport via script and some other parts. (I can even see
blocking/restricting IMs to small groups as useful for controlled
environments like education, e.g. restrict all IMing for some time only
to the class).

> 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).
Not really. Its more the try to standardize an API to prevent some
disasters with incompatible protocols for cooperating objects that
happend before. Basically RestrainedLife offers a sidechannel based API
to access viewer functions not available via normal LSL scripting. Due
to the nature of the code a lot of people could cry 'security holes' at
a lot of those functions (even if they are not really holes, but if you
read some of the CVEs that get issued you don't think security
developers have any trust in common sense of users) and 'patch' them but
still call it RestrainedLife.

So the main issue is: Prevent a fork to keep the API stable and
competition between the vendors of RLV supporting devices fair. Thats
GPL incompatible by design.

> 
>>
>>  (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.
Your correct for the Windows version, sorry, AFAIK the other versions
are contributed 3rd Party binaries.

> 
>>  > [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.
GPL proponents argue a lot. Its highly disputed what really is
derivative work and whats not. GPL proponents naturally take an extrem
position what falls under GPL (like GPL'ed protocols e.g. MySQLs on the
wire protocol?) but others disagree.

> 
>>  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. 
Major rewrite thats done in less than a day i would say.

>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.
Oh, nothing is stable in LL land..., so why care? And i don't think LL
would add the needed APIs to the official code as its only for seemingly
dirty 'adult' stuff.

> Plus, it wouldn't even necessarily fix the GPL compliance issues.
> (Remember, the GPL is *intended* to forbid this sort of addition.)
Intent and reality sometimes don't agree. If one would rewrite the patch
to a two part thing, one GPL'ed patch that added callbacks instead of
inlining the logic and shipped a dummy stub that did nothing it would be
fine.

Michael