RPL 1.5 discussion

[Chuck Swiger]

On Sep 18, 2007, at 8:47 PM, Scott Shattuck wrote:
> 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.

You're most welcome, Scott.

> 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.

Ok.  That background isn't critical to the review of your license,  
but it is useful to understand why existing copyleft licenses don't  
suit your requirements.

>> 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".

Fair enough, as the real consideration of whether something  
constitutes a derivative work is a question of law which would be  
decided by a judge for a specific circumstance.  Even dynamically  
linking a binary against something like a particular platform's  
standard C library probably would likely not result in the resulting  
executable being considered a derivative work.

> 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.

While I can recognize your point, I feel certain that almost nobody  
would consider a client like Firefox or Safari to be a derivative  
work of a webserver like Apache, IIS, dhttpd, etc-- nor a derivative  
of a website such as citibank.com, google.com, etc either. [1]

> 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.

Your license applies to the code you write, and to derivative works  
which contain enough of your original software to merit copyright  
protection.  Someone writing a completely independent code shouldn't  
have to do anything at all to figure out how someone else's license  
terms would apply to their work.

-- 
-Chuck

[1]: However, I should note that at one point long ago, the earliest  
web browsers actually did derive some of their source code from the  
NCSA webserver.  This might even still be true of IE or historical  
versions of Netscape, but neither Safari nor Firefox list that  
reference as far as I've been able to see.