OVPL - wrap-up of objections

[Wilson, Andrew]

Alex Bligh wrote:

> It may be that I am misunderstanding your argument here.

Perhaps.  Or, perhaps your pride of authorship is such that
you have something of a blind spot to criticism of OVPL?  Human nature,
if so.

Let me wrap my objections to OVPL in one e-mail, and then
stop, because this thread is in danger of overstaying its
welcome.  My position is well known, yours is well known, let
other readers form their own opinions.

ATW summary of OVPL

The intent of OVPL is to allow a central entity, the
Initial Developer, to accept public contributions to a
software project while maintaining a proprietary version of
the same code base.
OVPL attempts to do with one document, a license, what other
projects where code is controlled by a central entity, 
both open source (GNU, Apache) and non open source
(Java Community Process), accomplish through a combination of a
source code license and a contributor's agreement, e.g. a contract.
The license portion of OVPL is a straightforward derivative of
CDDL.  The "contract" portion of OVPL creates a bi-lateral 
agreement between the contributor and ID in which the contributor 
(a) agrees to furnish the ID with all future contributor modifications 
to covered code, and (b) agrees that the ID (and only the ID) 
has rights to, at its option, re-license contributor 
modifications on non-OVPL terms.

ATW objection #1

I can state with certainty that large US corporations
will not accept the validity of the "contractual" rights granted
under OVPL in the absence of a correctly executed agreement
between authorized representatives of the parties.
Post SCO/IBM, post Sarbanes-Oxley, you would be remiss
to accept code into your proprietary product absent well-documented
rights to do so.

This is actually the lesser of my two objections.

ATW objection #2

The mandatory license back to the ID is not in keeping with the
open source principles.  As has been astutely pointed out by
other readers of this thread, OVPL is a pay-to-play scheme.
You may or may not pay in currency to work with OVPL code, but
you certainly have to pay in code by pledging to deliver
all modifications to the ID and allowing the ID to relicense
them as proprietary code.  Pay-to-play, be it in cash or
code, is not open source.

Both objections could easily be handled by (a) making the license back
to the ID optional, and (b) allowing a contributor to indicate 
acceptance of the license back by signing a copy of OVPL 
and returning it to the ID.

Andy Wilson
Intel Open Source Technology Center