OVPL and open ownership

[David Barrett]

Alex Bligh wrote:
> 
> Nearly. It is:
> "If you distribute code at all, you must do so in a manner that allows me
> to make Proprietary Versions that use it, provided I also make your code
> available as contributions available to the general public. However, if I
> develop code, I can either use it in my Proprietary Versions, or contribute
> it to the code base. Note that if you offer to make your source code
> available under this license, that doesn't a Proprietary Version".

Good, I understand.

>>     "What if rather than requiring that the community contribute under 
>> BSD,
>> they were given the *option* to contribute under BSD?"
> 
> They can do that anyway, just by dual licensing, unless I'm missing
> something.
> 
> However, as I wrote before, the whole "option" thing doesn't work
> (or rather doesn't add more than a "normal" license with an option
> to license back as a separate document).

Ok, I believe I'm not communicating this point effectively.  (Or I'm 
missing something terribly obvious, as I've read everything you've 
written on this list carefully and repeatedly, and I still don't 
understand why 'the whole "option" thing doesn't work'.)

- The current OVPL mandates that contributions be licensed under OVPL. 
This is accomplished without any extra paperwork.

- The "BSD Proposal", as I understand it, mandates that contributions be 
licensed under BSD.  This is also accomplished without introducing extra 
paperwork.

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:

------------------------------------------------------------------------
3.2.      Modifications.

The Modifications that You create or to which You contribute are governed by

 >>>
your choice of either the terms of this License or the BSD license, as 
indicated in a manner appropriate to your Your contribution (ie, for 
source code, at the top of new files, or in comments surrounding your 
Modification).  If no clear indication of your intent to submit under 
the BSD license is given, it is presumed that you are submitting under 
the terms of this License.
<<<

You represent that You believe Your Modifications are Your original 
creation(s) and/or You have sufficient rights to grant the rights 
conveyed by this License.
------------------------------------------------------------------------

The intent of this is to ensure that developers who are happy with your 
management (or plain lazy) implicitly submit code under the terms of the 
original License.  This is based on the assumption that it is *always* 
in the interests of the ID to have contributions submitted under OVPL, 
and thus extra care should be taken to ensure this is the easiest route 
possible.

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

So to repeat, I'm proposing the OVPL be written such that it allows the 
contributor to refuse the ID his special privileges on the contribution 
-- and to do so without submitting extra paperwork -- but to require 
explicit indication be made within within the contribution itself.

This requires no additional paperwork, and leaves no ambiguity as to 
which license is in effect.  (Indeed it states that if there is any 
ambiguity, it's assumed to be under OVPL.)

I guess my confusion is I believe I'm offering a proposal that protects 
the ID's interests better than the "BSD proposal".  Either way, whether 
contributions come in under OVPL or BSD, the ID can continue to use 
them.  But if they come in under OVPL, then it *also* magnifies the ID's 
exlusive privilege (and the value of his commercial licenses).  In other 
words, without losing anything, the ID can gain more.

Thus I'm befuddled as to why you're uninterested in this proposal, as in 
essence I'm trying to say "Rather than just ensuring the ID can use 
contributed code, why not make it so contributed code increases the 
commercial value of the ID's proprietary licenses?"  What is the 
downside that is lurking in my blindspot?

-david