OVPL Summary, Take 3

[David Barrett]

So my goal here is to create a summary that is reasonably accurate.  I'm
not trying to generate more discussion, nor am I trying to highlight any
more corner cases and fine details.  Rather, I'm hoping to get a general
summary of the major points in a form most of us agree upon.  So if you
see a flaw in the summary below, please don't respond with a broad
discussion -- respond with specific textual changes.  Likewise, if 
something sounds unreasonable, please don't extrapolate it to its 
extreme conclusion and then debate that point -- guess what reasonable 
point I'm trying to make and then propose a clarification.

-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 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 most 
others. Furthermore, given that the tactic of using an open-source 
license in conjunction with contributor agreements 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.  And finally, no matter what the license says, 
there is usually asymmetry 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 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. [I'll 
admit, I've never seen how this option solves anything; can someone 
clarify this point in 3 lines or less?  I'm only adding it here because 
it seemed other people understood and saw value in it; please propose a 
clarification or I'll just remove it.]

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


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

The rebuttal is that this is an OSD-compatible feature, not a bug.


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 guidance on whether the OVPL 
is compliant with the OSD as interpreted by the OSI, or whether the OSD 
itself should be clarified or amended to prohibit what the OVPL attempts.