OVPL Summary, Take 2

[Alex Bligh]

David,

--On 16 September 2005 00:30 -0700 David Barrett <dbarrett at quinthar.com> 
wrote:

> Ok, so given all that discussion, I'll attempt to update my summary:
>
> ----
>
> The OVPL binds all contributors with a strong "copyleft" clause, with a
> single exception made for the the "initial developer" (ID) who is exempt
> (and thus able to relicense the combined work, including contributions,
> without restriction).  The OVPL has three primary innovations:
>
> 1) The OVPL achieves a similar effect to the traditional "contributor
> grant", but without the paperwork.
>
> 2) The license-back used by the OVPL is mandatory, unlike the "opt-in"
> approach of traditional contributor grants.
>
> 3) The OVPL discourages "private groups" by allowing the ID to request
> all modifications that have been distributed to anyone.  (Note: Totally
> private, undistributed modifications cannot be requested by the ID.
> Further note that under no circumstances is a contributor required to
> notify the ID or anyone else.)

I think that's a little confusing.
* The ID cannot request changes that have been made generally publicly
  available.
* The ID can request changes that have been distributed, but have not been
  made generally publicly available, but can't do anything with them unless
  he makes them generally publicly available (i.e. if he gets them,
  everyone gets them).
* There is no obligation with respect to undistributed modification (and
  moving copies around within a legal entity is not distribution).

> The major objections to the OVPL include:
>
> A) The OVPL violates the OSD due to its inherent asymmetry.
>
> The rebuttal to this is that other OSI-approved licenses also grant the
> ID special privileges, though the OVPL certainly goes further than any
> other.

It goes less far than (say) the QPL. It is fair to say it goes further
than any recently approved license (not that there are many, but...)

> Furthermore, given that the "dual licensing" tactic is embraced as
> open-source compatible, and given that the OVPL produces an effectively
> equivalent result, the OVPL's goals should likewise be embraced as
> open-source compatible.

I don't think the OVPL produces an equivalent result to dual licensing
(or we would have done that!). In dual licensed software, the recipient
has the choice of license. In the OVPL, there is no choice. However,
what is true is that dual licensed software can also produce asymmetry
(which is the point that was brought up).

There other argument is that there is asymmetry whatever the license says,
brought about by practical circumstance.

> B) The OVPL enables the ID to "freeload" on the community.
>
> The rebuttal to this is that the "freeloading problem" is a non-event;
> contributors choose to contribute under the conditions of the license or
> not.  A community that perceives the ID is freeloading should stop
> contributing.  However, at least two compromises have been offered to
> address this freeloader concern:
>
> i) Allow contributors to "opt-out" of the ID license-back, thereby
> requiring the ID to obey the copyleft should he accept the contribution.
> ii) Allow contributors to submit code under the BSD license.
>
> In other words, in the event of freeloading, contributors could (i) bind
> everyone (ID included) by copyleft, or (ii) release everyone from
> copyleft.  In both cases, the ID's exclusive exemption from copyleft
> would be negated.  In neither case, however, would the sponsors of the
> OVPL be satisfied.

We are unhappy with (i).

I'm not sure what you mean by (ii). Contributors contributing their
own original works can license it under whatever terms they like. If they
chose BSD, this can be re/sub-licensed under the OVPL, and is unproblematic.
So to the extent the contributions do not rely upon the original work,
contributors are already free to do this (just like with any other
license). Indeed, even where this is not the case, the contributor
can dual-license the IP *HE* has in any modification under BSD and the
OVPL. All he need do is so mark it - what he can't do is relicense
someone ELSE'S IP under BSD.

What has been suggested at one stage is to make this automatic (I think
this was Ernest's idea). This would make the grant from the contributors a
BSD grant (subject to publication of source to all distributed
modification), and the grant from the ID a reciprocal grant (if I
understand what is proposed), and presumably obviate the need for 3.3. I am
not sure whether this is in practice doable (the drafting is pretty hairy),
or of much practical use (in order for someone other than the ID to
make a proprietary version, they'd need to make sure there was nothing
derived from the ID's own code - an exercise akin to unscrambling an egg).

So I don't think (ii) is unacceptable - I just didn't see where it got
us and the discussion petered out. I may have misunderstood what Ernest
meant.

> C) The OVPL uses ambiguous language surrounding "distribution".
>
> The rebuttal to this is that the OVPL's language surrounding disclosure
> requirements is not materially different than the OSI-approved CDDL or
> indeed many other licenses, and thus this is really a complaint about the
> ambiguity of many licenses, and not the OVPL specifically.

Though we are more than happy to tidy it up. I think there are three
options: either delete it (the "make otherwise available"), leave it
as it is, or Larry convinces me he's got it an OSL version that works
well (I'm not currently convinced about the current wording).


Alex