OVPL Summary, Take 2

[Chris Zumbrunn]

On Sep 16, 2005, at 9:30 AM, David Barrett wrote:

> A) The OVPL violates the OSD due to its inherent asymmetry.
>
> The rebuttal to this is that other OSI-approved licenses also grant 
> the ID special privileges, though the OVPL certainly goes further than 
> any other. Furthermore, given that the "dual licensing" tactic is 
> embraced as open-source compatible, and given that the OVPL produces 
> an effectively equivalent result, the OVPL's goals should likewise be 
> embraced as open-source compatible.

This is like saying that because the BSD license allows for dual 
licensing a project under a proprietary license, proprietary licenses 
should suddenly be considered open source.

If an ID chooses to "dual license", likely only one of the licenses is 
"open source". If you roll the two licenses into one, you do not have 
an open source license anymore. I do not think the OVPL is doing that, 
but you seem to see it that way, and your argumentation is flawed.

> B) The OVPL enables the ID to "freeload" on the community.
>
> The rebuttal to this is that the "freeloading problem" is a non-event;
> contributors choose to contribute under the conditions of the license 
> or
> not.  A community that perceives the ID is freeloading should stop
> contributing.  However, at least two compromises have been offered to
> address this freeloader concern:
>
> i) Allow contributors to "opt-out" of the ID license-back, thereby
> requiring the ID to obey the copyleft should he accept the 
> contribution.

As you know, this is not an option for the stewards of the OVPL, so it 
has not "been offered".

> ii) Allow contributors to submit code under the BSD license.

That does not fix this problem. This would only be effective if the 
project would no longer contain any contributions (or any original 
contributions?) by the ID. The contributors could always achieve the 
same legal effect by dual licensing their contributions under a BSD 
license. In practice, it does not help much, since contributions and 
original works will stay virtually inseparable in the derivative works.

> In other words, in the event of freeloading, contributors could (i) 
> bind
> everyone (ID included) by copyleft,

Not an option for Alex.

> or (ii) release everyone from
> copyleft.

No, contributors would still not be able to produce a derivative 
proprietary work, while the ID could still use the contributions to 
produce a derivative proprietary work (as long as he also includes 
these contribution under the OVPL license, but that doesn't fix 
anything).

> In both cases, the ID's exclusive exemption from copyleft
> would be negated.

No, only in case i) it would, but that is not an option for Alex.

> In neither case, however, would the sponsors of the OVPL be satisfied.

I don't think the stewards of the OVPL would have a problem with ii), 
but it does not change problem B)

> C) The OVPL uses ambiguous language surrounding "distribution".
>
> The rebuttal to this is that the OVPL's language surrounding 
> disclosure requirements is not materially different than the 
> OSI-approved CDDL or indeed many other licenses, and thus this is 
> really a complaint about the ambiguity of many licenses, and not the 
> OVPL specifically.

This is not an issue effecting OVPL (or OSL) approval. We are just 
interested in this because we would like to know, how to impose open 
source license obligations on ASP deployments and to make that 
intention hold up in the courts.

Chris