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

[Aidan Thornton]

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 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 <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! 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))