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

[Marine Kelley]

Hi all, I'm on a tight schedule and I have refrained from answering so far
because I feel the OP is quite aggressive on my license and I don't feel
like spending yet another hour trying to state my reasons. Thanks a lot
everyone who took my defence, it's really heartwarming :)

I could do everything that has been stated here, for instance throw my
license down the toilet and flush, which would be a catastrophe for the
content creators in the BDSM community because sooner or later someone would
take it as a competition advantage over the people who can't code on the
viewer. I could also cut the patch in two just to make it even more secure,
but frankly that's work with exactly no value added.

What I have long time planned to do is to eventually release the patch to
the GPL so I can be free from all those annoying questions, but after I have
written a full and clear specification as to what a RLV is and what it is
not. You have to keep in mind that there are people around who want the RLV
to go GPL just so they can eradicate their competitors with its help. Like I
said before, I have created the RLV to help people create new businesses,
not to destroy them. It worked so far (very well even, just look at the
number of people who base their businesses on the RLV), and I intend it
stays that way.

Now, I still don't get why I get all these attacks. I mean it's not like I
was making people pay me royalties, what I want is a consistent, monolithic
system so that business owners do not have to wonder which flavor of the RLV
their script is talking to. That's not asking much, I think. I often wonder
what the people who insist on me going GPL have in mind for the viewer.

And yes I am a control freak, but that's not the reason why I want to keep
the reins tight in this instance. lol. No offence taken here :)

Marine


2009/6/28 Michael Schlenker <schlenk at uni-oldenburg.de>

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20090628/a02cb930/attachment.htm