OVPL Summary, Take 3
dbarrett at quinthar.com
Sun Sep 18 03:11:18 UTC 2005
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.
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
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
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.
More information about the License-discuss