RPL 1.5 discussion

[Scott Shattuck]

Chuck,

First let me thank you for taking the time to review/comment. It's  
great to see movement of any kind on this topic.


On Sep 18, 2007, at 5:04 PM, Chuck Swiger wrote:
>
> Agreed-- one of the two big concerns I have over the RPL is the  
> notion that you can't run your own modified version of the software  
> without having to redistribute your changes, which is why the FSF  
> considers it "non-free".  The exception for "personal use" in 1.11  
> restricts private commercial use unless one publishes those changes  
> to the world.  This isn't strictly against the OSD #6, but it is  
> coming closer than most copyleft licenses do.
>

Understood, however while I agree it doesn't meet the needs of those  
who are looking for an FSF-style license, this was the motivation for  
creating the RPL to begin with. Were it not for the RPL's distinction  
regarding what it means to "deploy", the GPL2 might well have served  
our needs.

Our goal in crafting the RPL was, quite frankly, to create one half  
of a dual-license approach based entirely on licensees choosing  
between an open source or closed source model for their derivative  
works. In particular we wanted to avoid distinctions or definitions  
regarding commercial vs. non-commercial use as had been done in the  
past.

The RPL is the open source half of that pair. Any license which  
grants relief from the requirement to release derivative work source  
code under the RPL is the other half (that license can be crafted by  
anyone who chooses the RPL for the open source member of the pair.)

Each potential licensee can make a choice of license based not on  
whether they will be using the code for commerce but based entirely  
on their ability or inability to open source their code. Further,  
they might make that decision on an application-by-application basis,  
or even on a server-side vs. client-side basis (see below). Some  
derivatives might be non-critical and hence open sourced under the  
RPL, some more critical and hence licensed under a "closed source  
license".

> The second concern I have is that the RPL tries to claim it applies  
> not just to derivative works but potentially to a completely  
> separate application which was written from the ground up which  
> merely communicates over the network to an RPL'ed application.   
> Using publicly published APIs to talk to your RPL'ed program from  
> separate code I've written myself does not mean my code must be  
> licensed under your terms.
>
> This isn't something which is against any part of the Open-Source  
> Definition, but it's unfortunate nevertheless.  I don't want to  
> recommend against approval, but neither do I feel that the license  
> is solidly grounded in the claims it asserts...
>

Our intention here was not to span separate application boundaries  
but to recognize an application, particularly a web application, as  
not being defined by the concept of "linking".

Web applications, while they run on separate machines and communicate  
over a network, effectively represent cooperating modules in a single  
application. This is certainly how the vast majority of them have  
been constructed in any case, with the boundary between client and  
server being fairly fuzzy -- JavaScript embedded everywhere in server- 
side templates etc. etc. This created a real problem for us in trying  
to define the boundaries of the application. Required components was  
our answer.

Certainly there are edge cases where that distinction is fuzzy, where  
the client code is completely independent of the server and the  
server completely unaware of the client. While not perfect, we  
presume that in those cases the parties involved will work to define  
how the license will apply to their efforts before they go too far  
down the path. As I mentioned earlier, the RPL was built to be one  
half of a dual-license scheme and there's nothing keeping the  
licensor from offering privacy protection for the server side code  
when that's what a particular application needs.

In the end our goal was to define something that could be applied  
with a fairly simple yet rigorous test -- run the client and look for  
missing functionality.


I hope this helps clarify the intent, even if it does nothing to  
change anyone's particular religion regarding FSF vs. OSI. But then  
again, if they were the same the OSI wouldn't need to exist, would  
it ;).



ss