OVPL and open ownership

[David Barrett]

Ok, I hope you'll forgive me for taking so long, but something clicked 
for me in your last message and I think I might finally "get" your concern.

The discussion on risk/reward I think was a distraction, as I'll wager 
you would oppose the OVPL as written no matter how statistically 
insignificant the odds of abuse, just as I'd support it no matter how 
statistically significant.  Rather, I think we're debating a matter of 
principle, specifically: "how can source be called 'open' if the 
community doesn't own it?"

In the case of typical dual licensing, the community owns the code, and 
continously grants the initial developer extra privileges as a reward 
for "good behavior".  If the ID in a current dual-licensing scheme 
starts acting poorly, the community will just stop going through the 
extra effort to grant him special rights

In the case of the OVPL, the *initial developer* owns the code, and 
continously grants the community the right to modify it so long as it's 
advantageous to him.  However, there's no way for the community to 
reject the ID because they're not in charge.

Now the probability of the community wanting to reject the ID, or the 
severity if they're unable to do so, these are subjects for debate.  But 
that debate doesn't frankly matter.  What does matter is that 
maintaining the ID's irrevocable ownership over the project is the 
dividing line between open and closed.  Said another way, a requirement 
for "open source" is that the community owns the code, and always has 
the final say.


So, am I finally getting the point you (and others) have been making all 
along?


If so, I wonder if you'd support the following change to the OVPL:

Earlier, Andrew suggested that he'd support the OVPL if 3.3 was simply 
made optional, and contributors could opt-in by signing the license and 
mailing it in.  I rejected this in a kneejerk fashion, as it does very 
little to reduce my paperwork overhead or the "stamp-licking burden" on 
the contributor.

However, I wonder if you and Andrew would support making the license 
*opt-out*.

I recall that one of the existing OSI licenses (I can't recall which 
one, unfortunately) gave the contributor an option to either accept the 
license as is, or to remove a part of the license and submit it under 
that.  I wonder if the OVPL could do something similar, and give the 
contributor the right to remove section 3.3 in its entirety, and thus 
explicitly deny the initial developer his special rights.

In this way, the initial developer would simply confirm that the 
submitted code includes section 3.3, and can make an immediate decision 
on whether or not to include in his source code.  Auditing is likewise 
simplified, as there is no cross referencing to paper documents to 
perform -- simply review that all patches checked into the main tree 
include section 3.3, and there's a clear pedigree.  This neatly solves 
my paperwork overhead concern.

And so long as the initial developer is in good standing with the 
community, they would naturally leave section 3.3 intact, and continue 
granting the initial developer extra rights.  This would require no 
stamp licking, no paper signing, and in fact no effort whatsoever.  The 
typical one-time contributor need take no extra action to satisfy the 
criteria for inclusion in the initial developer's mainline repository. 
This neatly solves my contributor-hassle concern.

However, the big change is that anyone, at any time, could do a global 
search and replace on the codebase and remove section 3.3 entirely, 
thereby releasing a fork of the code to which the initial developer has 
no special rights.  Naturally the ID can keep all code contributed with 
3.3 up to that point.  But in this way, the community has the legal 
right to disown the initial developer and forge a new path.  I believe 
this neatly solves your concern.

(There's also the option of letting the community choose a new ID, but 
I'd recommend against that else the day after I release my code, a 
competitor could just snatch the whole thing up, reassign himself as the 
ID, and then go on an advertising blitz to attract all the developers to 
his branch.)

So have I finally grokked your concern about the OVPL?  And would this 
change address it?

-david