OVPL and open ownership

[David Barrett]

Alex Bligh wrote:
> Not quite. Mandates that all contributions be licensed under the OVPL (so
> others can use them, provided they comply with Clause 3), and ALSO to the
> ID (on a perpetual sublicense, to do whatever he likes with).

Ahh, I think I might have been missing this subtle (to me) point and 
thus speaking inaccurately.  When I said "contribute under the terms of 
the OVPL" I also assumed that meant granting the ID his additional 
rights.  I didn't realize they were separate actions.  Thus my intent 
was to do both: ensure contributors license their code under the OVPL 
(thereby reducing license confusion and ambiguity), and *also* grant the 
ID his special privileges.


>> What I'm proposing is that the choice of which of these options to take
>> is left to the developer (with the OVPL option being the default), and
>> worded in such a way that does not introduce extra paperwork.  For
>> example, you might modify section 3.2 to be:
> 
> OK. I didn't understand that bit. I think I now do.
> 
> Isn't this achieved equivalently by leaving the OVPL as it is, and
> for the contributor to dual-license their modifications to the extent
> they own the IPR? [*]

Perhaps I'm misunderstanding this.  By "dual license" do you mean 
execute an external contributor agreement (mean, sign a paper and lick a 
stamp)?  If so, I agree that the end result is equivalent (or nearly so, 
as the contributor agreement generally assigns copyright while OVPL 
section 3.3 doesn't go so far), but the mechanics are not.

I oppose external contributor agreements as I think they are significant 
(and unnecessary) obstacles to foist on contributors, and merely ensure 
that fewer people go through the hassle of contributing.  If at all 
possible, I'd like to get the benefit of an external contributor 
agreement (or as near as the law allows me) without forcing contributors 
to jump through any hoops.


> The danger to be avoided is impliedly licensing the contributor to
> distribute their modifications under a BSD license when they are
> dependent upon the ID grant (this is not the intention) - i.e.
> to use your analogy, implying "if you make any modication (e.g.
> if you replace all the tabs by spaces), then the resultant modified
> files may be distributed by you under a BSD license without following
> the terms of clause 3).

Yes, I agree entirely, but are you suggesting that my proposal 
aggravates this risk?  I believe any license that requires or gives the 
option for contributions to be licensed under BSD faces this risk 
equally.  However, I believe this is a separate issue to the one we're 
currently discussing (as it affects both my and Earnest's proposal 
equally, and needs to be solved either way), and this I humbly request 
we table it until we settle the matter at hand.


>> However, by giving the option of submitting under BSD (without requiring
>> any extra contributor agreement), the community is given the right to
>> refuse granting the ID privilege on new code.
> 
> More accurately, I think, to grant everyone else the same privilege
> on new code.

Yes.


>>  This is based on the
>> assumption that it is *always* to the disadvantage of the ID to have code
>> submitted under anything but the OVPL, and thus it's in the ID's interest
>> to require explicit action be taken to refuse the ID grant.
> 
> Yes. I'm with you. But contributors can just BSD license their
> (new) works, and contribute those under dual license, can't they
> (i.e. do '*').

If you're again referring to the equivalence of an external contributor 
agreement, I again oppose it as it's unduly bothersome for contributors. 
  I would like to find a more streamlined way (involving no stamp 
licking) to accomplish the same ends.  And I certainly don't want it to 
be easier to contribute code under BSD than under OVPL + ID-grant


> What I think Ernest was proposing is either mandating a BSD license
> for contributions, or alternatively (and this may be better) forcing
> the ID to relicense anything he incorporates into the proprietary version
> under a BSD license, allowing others to do the same.

I see how this would work.  However, it seems to pass up a unique 
opportunity to expand the value of being an ID.  If it's possible to 
craft a license that accomplishes what Earnest proposes, I believe it's 
possible to craft a license that does what I propose (mandate that 
contributors *either* contribute under OVPL and grant the ID extra 
rights *or* under the BSD and thereby deny the ID extra rights^^).


^^ When I say "deny the ID extra rights" I mean "deny the ID the 
exclusive right to create proprietary derivatives", which is equivalent 
to "grant everyone the right to create proprietary derivatives".


> I was uninterested before because I didn't understand it :-) I now
> do, but I think it can be achieved in practice without modifications
> to the current license (which is great, because it's additional
> complexity) for those who are worried about contributing OVPL-only
> code.

Whew, I'm glad to hear that I sold you on its value.  However, I don't 
see how the OVPL can do what I'm asking without change, unless we use 
external contributor agreements (which I've argued at length that I 
oppose for practical reasons, though envy for their effects).

-david