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