OVPL - wrap-up of objections

[Lawrence Rosen]

I express no position on the basic model of the OVPL with its mandatory
license by the contributor to the ID. But the following statement gives me
some heartburn:

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

Certainly you don't mean to suggest that every open source license,
including the GPL, is unenforceable in the absence of a "correctly executed"
agreement? Or to suggest that executing open source licenses as express
contracts is essential for acceptance of open source by companies?

In any commercial setting in which it would matter, licensees will accept
the validity of the license even though they haven't executed it. Otherwise,
they admit to being infringers and will have to stop using the software. It
is a damned-if-you-do and damned-if-you-don't situation for open source
"licensees" because patents and copyrights are infringed in the absence of a
license. That's the big difference between such open source copyright and
patent licenses and other contractual agreements (e.g., NDAs, JDA, etc.)
with which most companies are familiar.

So I hope you will stop confusing the legal advantages of contract formation
-- a position I have long supported on this list -- with the FUD that a
"correctly executed agreement" is the only way we have to license our
copyrights and patents so that licensees will honor the terms in
commercially important settings. 

/Larry

Lawrence Rosen
Rosenlaw & Einschlag, technology law offices (www.rosenlaw.com)
3001 King Ranch Road, Ukiah, CA 95482
707-485-1242  *  fax: 707-485-1243
Author of "Open Source Licensing: Software Freedom and 
   Intellectual Property Law" (Prentice Hall 2004) 
   [Available also at www.rosenlaw.com/oslbook.htm]
 
 

> -----Original Message-----
> From: Wilson, Andrew [mailto:andrew.wilson at intel.com] 
> Sent: Thursday, July 21, 2005 9:52 AM
> To: Alex Bligh; license-discuss at opensource.org
> Subject: OVPL - wrap-up of objections
> 
>  
> 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
>