OVPL - wrap-up of objections

[Ernest Prabhakar]

Hi Andrew,

I appreciate your concise summary -- I have a hard time keeping up on  
this!

One clarification request, if I may:

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

Compared to other licenses:
- the BSD allows the ID (or anyone else) to take the code private
- the GPL requires everyone to make their code public

I'm still trying to understand why the OVPL counts as 'pay to play'  
but the GPL does not. Is it the fundamental asymmetry that bothers  
you?   What if, for example, OVPL required that all modifications be  
published publicly under a BSD license?  Would that be 'in keeping  
with open source principles'?

Also, are you asserting that this violates the spirit or letter of a  
particular OSD clause, or is simply a bad idea?

-- Ernie P.


On Jul 21, 2005, at 9:51 AM, Wilson, Andrew wrote:

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