RPL 1.5 discussion
Scott Shattuck
idearat at mindspring.com
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
More information about the License-discuss
mailing list