RPL 1.5 discussion

Hi William;

Is it your intent to have 1.1 be put into a deprecated
state?

On 9/11/07, William J. Edney <bedneytechnicalpursuit.com> wrote:
>  All -
>
> On a completely different topic, I would like to open
discussion (if there
> is any) on the Reciprocal Public License (RPL) version
1.5 upgrade,
> submitted by myself to this list on July 24th, 2007:
>
> http://crynwr.com/cgi-bin/ezmlm-cgi?3
:mss:13076:200707:kdcakaahmlnjkcfaaijd
>
> RPL version 1.1 was approved in November of 2002 and is
currently in use by
> a number of organizations worldwide. This version of
the license makes a
> number of changes as per suggestions from both these
organizations and the
> FSF.
>
> If no one has any discussion points regarding this
license, then I would
> respectfully request that this license be considered
for approval at the
> next board meeting.
>
> Thanks very much.
>
>
> William J. Edney
> bedneytechnicalpursuit.com
> 314.757.9200
>
>
>
>


-- 
Open Source Programs Manager, Google Inc.
Google's Open Source program can be found at http://code.google.com
Personal Weblog: http://dibona.com

Chris -

Yes, it is our intent to deprecate 1.1.

Thanks!

- Bill

On Sep 11, 2007, at 3:12 PM, Chris DiBona wrote:

> Hi William;
>
> Is it your intent to have 1.1 be put into a deprecated
state?
>
> On 9/11/07, William J. Edney <bedneytechnicalpursuit.com> wrote:
>>  All -
>>
>> On a completely different topic, I would like to
open discussion  
>> (if there
>> is any) on the Reciprocal Public License (RPL)
version 1.5 upgrade,
>> submitted by myself to this list on July 24th,
2007:
>>
>> technicalpursuit.com
>> 314.757.9200
>>
>>
>>
>>
>
>
> -- 
> Open Source Programs Manager, Google Inc.
> Google's Open Source program can be found at http://code.google.com
> Personal Weblog: http://dibona.com

Then I'll get reading  Thanks
William.

Chris

On 9/11/07, William J. Edney <bedneytechnicalpursuit.com> wrote:
> Chris -
>
> Yes, it is our intent to deprecate 1.1.
>
> Thanks!
>
> - Bill
>
> On Sep 11, 2007, at 3:12 PM, Chris DiBona wrote:
>
> > Hi William;
> >
> > Is it your intent to have 1.1 be put into a
deprecated state?
> >
> > On 9/11/07, William J. Edney <bedneytechnicalpursuit.com> wrote:
> >>  All -
> >>
> >> On a completely different topic, I would like
to open discussion
> >> (if there
> >> is any) on the Reciprocal Public License (RPL)
version 1.5 upgrade,
> >> submitted by myself to this list on July 24th,
2007:
> >>
> >> technicalpursuit.com
> >> 314.757.9200
> >>
> >>
> >>
> >>
> >
> >
> > --
> > Open Source Programs Manager, Google Inc.
> > Google's Open Source program can be found at http://code.google.com
> > Personal Weblog: http://dibona.com
>
>


-- 
Open Source Programs Manager, Google Inc.
Google's Open Source program can be found at http://code.google.com
Personal Weblog: http://dibona.com

I'd like to second William's request and respectfully ask
that the  
RPL 1.5 be summarily approved at the next board meeting.

Revisions to the RPL v1.1 (originally approved in November
of 2002)  
were submitted in April of 2006, largely in response to
objections  
raised by the FSF when they noted that the RPL was the only
software  
license that was both OSI-approved and
"non-free".

Unfortunately, no action was ever taken on that submission
in spite  
of the fact that a) there was almost no license
activity/mailing list  
traffic during that month or subsequent months, b) I sent
email to  
several license-* groups asking about status, c) I sent
email  
directly to the board's mailing list, d) I exchanged email
with  
certain board members directly.

I got sick of trying and handed off to Bill. He re-submitted
RPL  
revisions for approval in July of this year. Since over a
year had  
passed with no action we decided to fine-tune the language
in certain  
areas and chose to label it v1.5. Perhaps unsurprisingly
there has  
been absolutely no action, discussion, or other commenting
on that  
submission. Not one message -- unless you count our
continued request  
that the board actually approve it since there has been no
objection  
cited.

While I understand the board has been busy with the GPL/LGPL
I'd  
hoped that the fact that the 1.3 submission had been
effectively  
ignored that you'd have respected his request to approve it
at the  
September meeting. Apparently a quick vote on a license with
no  
objections would have taken too long. Ok, that was probably
uncalled  
for, but seriously folks, what the hell?


ss



On Sep 11, 2007, at 2:19 PM, Chris DiBona wrote:

> Then I'll get reading  Thanks
William.
>
> Chris
>
> On 9/11/07, William J. Edney <bedneytechnicalpursuit.com> wrote:
>> Chris -
>>
>> Yes, it is our intent to deprecate 1.1.
>>
>> Thanks!
>>
>> - Bill
>>
>> On Sep 11, 2007, at 3:12 PM, Chris DiBona wrote:
>>
>>> Hi William;
>>>
>>> Is it your intent to have 1.1 be put into a
deprecated state?
>>>
>>> On 9/11/07, William J. Edney <bedneytechnicalpursuit.com> wrote:
>>>>  All -
>>>>
>>>> On a completely different topic, I would
like to open discussion
>>>> (if there
>>>> is any) on the Reciprocal Public License
(RPL) version 1.5 upgrade,
>>>> submitted by myself to this list on July
24th, 2007:
>>>>
>>>> technicalpursuit.com
>>>> 314.757.9200
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> --
>>> Open Source Programs Manager, Google Inc.
>>> Google's Open Source program can be found at http://code.google.com
>>> Personal Weblog: http://dibona.com
>>
>>
>
>
> -- 
> Open Source Programs Manager, Google Inc.
> Google's Open Source program can be found at http://code.google.com
> Personal Weblog: http://dibona.com

On Sep 18, 2007, at 11:25 AM, Scott Shattuck wrote:
> I'd like to second William's request and respectfully
ask that the  
> RPL 1.5 be summarily approved at the next board
meeting.

Russ doesn't track license submissions without "For
approval:" in the  
Subject header, but I agree that the original submission
should have  
received more attention.

> Revisions to the RPL v1.1 (originally approved in
November of 2002)  
> were submitted in April of 2006, largely in response to
objections  
> raised by the FSF when they noted that the RPL was the
only  
> software license that was both OSI-approved and
"non-free".

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.

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

-- 
-Chuck

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

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.

> De : Chuck Swiger [mailto:chuckcodefab.com]
> Envoyé : jeudi 20 septembre 2007 02:43
> À : Scott Shattuck
> Cc : License Discuss
> Objet : Re: RPL 1.5 discussion
> 
> 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.

Note that copyleft licences do not force any user modifying
a covered work
to become a new distributor for these changes. The spirit of
open-source and
copyleft licences is to also permit strictly personal use
without having to
give back to others those changes you have made.

The only requirement is to give the source of your
modifications to anyone
requesting it (not only those users to which you have
provided a licence of
your modified version) if you decide to become a new
distributor for any
implementation of your changes, even if this application is
commercially
distributed.

This means that proprietary code can be integrated within
any opensourced or
copyleft program and remain secret, as long as you do not
decide to
distribute your own private combined work. As soon as you
distribute only
one version of the modified work with a valid licence for it
to anyone, then
you are exposed to the licence requirements about source
availability to
ANYONE requesting it. The existence of only one delivered
valid licence to
someone else (including in the case where your private
modified application
needs to be used by another legal entity resulting from the
split of an
organization into two separate entities, or delivery of a
licence to
subsidiaries) is enough to require making the sources
available to anyone
(the requester does not need not justify that he got a
licence himself for
the modified program, just to be able to prove that someone
else got a valid
licence for those modifications, and that this licencing was
legally
obtained, without being stolen or illegally exported if such
legal
restrictions do exist).

Scott Shattuck wrote:

> Perhaps unsurprisingly there has been absolutely no
action,
discussion, or other commenting on that
> submission.

Speaking for myself, I can say I found it difficult to make
time to read
and comprehend such a long license.

> Apparently a quick vote on a license with no objections
would have taken
> too long. Ok, that was probably uncalled for, but
seriously folks, what
> the hell?

Now that I have considered the license, I have several
comments.  Most
importantly, I object to the attribution clause in its
current form.  It
has the same issues as earlier drafts of CPAL, but without
the
compromises (e.g. only on one screen, 10 words, etc.) OSI
agreed to.  I
would be reluctant to support any more attribution licenses
until CPAL
has been out for a while (say a year).

I also find RPL unnecessarily complex.  This is because you
seek to
specify every possible issue a court could consider
(Jurisdiction,
arbitration,  U.S. government end users, value for patent
lawsuits).  I
question whether all these stipulations will be effective,
especially in
non-U.S. jurisdictions.

All these factors serve to make the license less likely to
be reused.
Existing approved licenses (and others, such as Affero and
Honest Public
License that haven't been submitted), such as the Open
Software License
(http://ope
nsource.org/licenses/osl-3.0.php) seem to serve
approximately
the same purpose more efficiently.

Matt Flaschen