OVPL Summary, Take 4

[David Barrett]

Excellent comments; here's my attempt to integrate.  As always, small, 
specific changes to the summary are most welcome:

- Rewrote A based on Chris's and Alex's comments
- Rewrote intro to B based on Chris's comments
- Rewrote B.ii based on Alex's comments
- Leaving C in (I agree it's not OVPL-specific, but it generated a lot 
of discussion so I think it's worth mentioning)
- Rewrote D at Chris's request
- Added E to capture Ben's concern and Alex's reply
- Reworded conclusion on Alex's comments

-david

-------------

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 can request modifications that have been distributed in a 
non-general way (ie, within a private group) and use them, but only if 
the ID himself releases them in a public way.  (Note: Totally private, 
undistributed modifications -- including copies moved around within a 
single legal entity -- cannot be requested by the ID.  Further note that 
under no circumstances is a contributor required to notify the ID or 
anyone else.)


The major objections to the OVPL include:

A) The OVPL grants greater rights to the ID than to contributors.

While practical and legal considerations of many OSI-approved licenses 
often cause an asymmetrical distribution of rights between the ID and 
contributors, the question is whether the OSI should enshrine and extend 
this asymmetry to the degree the OVPL allows.  A "buyer beware" approach 
would leave it to individual contributors to make an informed decision. 
  Another approach would be to actively deny licenses that expand the 
asymmetry of rights by treating some contributors differently than 
others.  Both approaches can be reasonably and honestly argued, though 
the OSI has indicated a preference for the former (buyer beware).


B) The OVPL enables the ID to "freeload" on the community.

The concern is that an OVPL-project's community's "right to fork" cannot 
escape the ID's ability to integrate the fork's changes into his 
proprietary version or -- even worse -- escape the ID's ability to 
release proprietary versions of the community's fork.  Thus an ID could 
"freeload" on the efforts of an active community forever, merely due to 
his original past involvement (or by acquiring the right from a previous 
ID).  Granted, it could be argued that this "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 proposed 
by members of the list 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. 
(Note, this option is not endorsed by the OVPL sponsors.)

ii) Allow contributors to submit code under the BSD license, thereby 
obviating the need for OVPL 3.3 altogether. (Note, it's unclear how to 
write a license that achieves this in practice without also in practice 
BSD-licensing the original code base.)

Thus in the event of freeloading, contributors could (i) bind everyone 
(ID included) by copyleft, or (ii) release everyone from copyleft, with 
respect to their individual contributions.  In either way, this negates 
the ID's *exclusive* right to produce a proprietary derivative of the 
contribution.


C) The OVPL uses ambiguous language surrounding "distribution".

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


D) The OVPL forbids "private groups", such as the GPL allows.

The concern is that it's sometimes desirable to allow groups to modify 
and selectively distribute custom versions of software without being 
obligated to make the modifications public, and the OVPL doesn't really 
allow this (because the ID can request those modifications and integrate 
them with his public and any other releases).  However, a rebuttal to 
this concern is that it is sometimes *undesirable* to allow groups to do 
just this, and thus the OVPL's restriction on this can be seen as a 
feature, not a bug.


E) The OVPL allows the ID to go on "fishing trips" for modifications.

The concern is that because an ID has rights to all 
selectively-distributed modifications, he can arbitrarily issue requests 
to anyone he suspects might have made them, and if they have they will 
be compelled to reply.  However, the rebuttal is that this is no 
different than what any licensor can (and should) do when he suspects a 
licensee is not adhering to the terms of the license.  Indeed, if a 
licensee is compliant, he is under no obligation to respond to a 
"fishing trip" for non-compliance.



In summary, everyone agrees that the OVPL is a well-drafted, innovative 
license that offers genuinely new capabilities.  And most agree that the 
OVPL complies with reasonable interpretations (if not the only 
interpretations) of the OSD.  But we await formal acknowledgment that 
the OSI approves the OVPL as compliant with its interpretation of its 
OSD principles.