OVPL and open ownership

[David Barrett]

Alex Bligh wrote:
> 
> --On 25 July 2005 10:54 +0200 Chris Zumbrunn <chris at czv.com> wrote:
> 
>> You are misunderstanding this. If a contributor can opt-out of 3.3 then
>> you will not be able to use his contribution in your proprietary version.
>> If a contributor has to contribute under a BSD-style license then you 
>> can.
> 
> Exactly

Ah, ok, I have been misunderstanding this.  Let me restate my 
understanding (to confirm it's correct) and update my proposal.

I was thinking the goal was to maximize the value of the ID's exlusive 
privileges (ie, the commercial value of a license) by actively 
preventing others from distributing proprietary versions.  In the case 
of contributions, I was thinking the bargian you wanted was:

	"You can contribute in a way that allows me alone to create proprietary 
versions, or in a way that allows *nobody* to create proprietary versions."

The upside of this approach is the commercial value of your license 
increases with every "non-disgruntled contribution" (not just your own), 
as the only way to create a proprietary version of any code is through 
you.  The downside is it allows "disgruntled contributors" to submit 
code from which no proprietary version can be made.


However, it sounds now like your goal is to maximize the proprietary 
usability of contributions, while maintaining exclusive proprietary 
distrubtion rights over your own code.  In other words, the bargain is:

	"You must contribute in a way that allows me to make proprietary 
versions.  However, the code I contribute will only allow me to make 
proprietary versions."

The upside of this approach is that you will always be able to release a 
proprietary version including code from any contributor -- "disgruntled" 
or not.  The downside is the value of of your commercial license is 
limited to solely your contribution (minus whatever is "effectively 
converted" to BSD through extensive contributor modification).


So the first goal is in the spirit of "anti-proprietary with exceptions 
for the ID", while the second is "pro-proprietary with exceptions for 
the ID".  I think both make sense for different projects:

- The second makes sense for a vendor looking to protect its investment 
from hijacking, while leveraging community contributions.  In this case, 
the sum of all community contributions is likely far less than the ID 
contribution, and this ratio remains constant throughout the course of 
the project.

- The first makes sense for a developer looking to organize an open 
source project around an existing codebase as a commercial venture 
itself.  In this case, the sum of all community contributions starts out 
far less than the ID contributions, but might equal or exceed the ID 
contributions over time.  (The ID privilege is what enables the ID to 
fund the maintenance of the project.  In effect, the community "hires" 
the ID to manage the project.)


These goals are very different, and I could see an argument made to 
develop a license tuned for each.  However, let me adjust my proposal in 
light of this (I hope) improved understanding, and I think we can 
accomodate both goals with a single license:

	"What if rather than requiring that the community contribute under BSD, 
they were given the *option* to contribute under BSD?"

For all non-disgruntled contributors (which I'm assuming make up an 
extremely high proportion), they wouldn't make any special effort to 
change licenses, and thus contribute under OVPL:

- This maximizes the value of the ID's exclusive proprietary rights, 
thereby supporting the ID's business model and thus enabling him to 
continue managing and supporting the project.

- And this simultaneously minimizes confusion caused by extensive mixing 
of licenses, as the normal churn of contributors modifying a single 
file, regardless of frequency, size, or scope of contribution, will 
never cast doubt on which portions of the file are OVPL.

I would expect that nearly all bugfixes and minor changes (ie, all those 
that wouldn't "stand alone") would be contributed under the original 
terms of the OVPL, thereby maintaining near uniform OVPL licensing from 
top to bottom.

However, for those developers who want to contribute a new, standalone 
module, they can submit it under BSD and thus protect their investments.

And finally, a community that gets sick of an ID and explicitly wants to 
cut him loose can simply decide to set up an alternate repository and 
contribute all future modifications under BSD.  They can't revoke the 
existing rights of the ID to existing OVPL code, of course, but they can 
make an effort not to grant the ID additional rights going forward.


So have I correctly understood and captured your goal above?  And does 
my proposal sound like an improvement?  If not, where am I off?

-david

PS: Sorry for the huge volume of long emails.  I'm trapped between "I'm 
writing so much I'm boring myself" and "I still don't get our 
disagreement"; what to do? :)