RPL 1.5 discussion

Wed Sep 19 03:47:51 UTC 2007

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