OVPL and open ownership - summary of discussion

[David Barrett]

Great summary, thanks.  Just to toss in a couple points:

Alex Bligh wrote:
> 
> 7. Ernest Prabhakar suggested... I suspect there is a compromise to 
> be found here which would make everyone other than view 5 people 
> happy.

I agree, there's the makings of a compromise here, but I don't think
we're there yet.  Once the OSI gives us some guidance (assuming they
don't approve the OVPL as is -- which I hope they do), then we can
hammer out the details.


> 8. There has been some discussion over whether or not Clause 3.3 
> should be optional...

I would add one more concern to your summarized list, and that is of the 
community's inability to shake off a "freeloader" ID.  This was the 
whole reason for my proposed "opt-out" ability of Clause 3.3 (though 
that term carries misleading connotations).

I believe their essential argument is that an ID can "freeload" on the 
community if they cannot prevent an ID from having the exclusive right 
to release closed, proprietary versions containing their contributions. 
  I believe the options available to prevent freeloading (assuming it's 
even necessary) are to enable the community to:

1) Create a fork of the entire codebase to which *nobody* can release
closed, proprietary derivatives (including the ID)

2) Create a fork of the entire codebase to which *anyone* can release
closed, proprietary derivatives (including the ID)

Either way, it eliminates the ID's ability to *exclusively* release 
closed, proprietary versions of contributor code (aka, "freeload").  The 
downside of an anti-freeloading provision is it requires the formation 
(or potential formation) of an irrecoverable fork between the ID and 
community branches.

I merely point this out to distinguish it from the "BSD-esqe" proposal 
that Earnest made.  Under that proposal, an individual developer can 
release his personal contribution under a non-exclusive license (such as 
BSD).  However, if the contribution depends on the ID's work, this is a 
purely symbolic move -- and does not prevent the ID from freeloading -- 
because in effect only the ID can still ever create a proprietary 
derivative that makes use of it.

(It's like trying to set up "free room" in the middle of a theme park; 
even if it costs nothing to get in, the only way to get to the door is 
through the theme park's ticket stand.)


Other than that, I think you captured every issue that I noted.  I'm 
eager to hear what the OSI board has to say!

-david