Are implicit dual-licensing agreements inherently anti-open?

[Alex Bligh]

--On 19 July 2005 10:12 -0700 "Wilson, Andrew" <andrew.wilson at intel.com> 
wrote:

>> For completeness, one might suggest that the license-back is "an
>> assignment in disguise" (and thus not enforceable in jurisdictions
>> requiring such assignments to be made in writing). This is pretty
>> easily rebutted.
>
> Really? OVPL mandates that a consideration of value (license rights
> to modifications) be exchanged between contributors and the ID.
> In addition to sounding like an assignment in disguise, this sounds
> very much like a contract (as opposed to a license) in disguise.

I am not attempting to rebut the "disguised consideration" argument,
though I would suggest that applies to any reciprocal license. I am
trying to say it isn't an ASSIGNMENT in disguise, a key feature of
assignments is rights pass from one to another (i.e. the assignee gains
AND the assignor loses). This is quite different to a non-exclusive
license.

> One might then well ask, are Joe and Jane Engineer, employees of
> a typical large corporation who have downloaded some OVPL code,
> authorized to enter into a contract on behalf of their employer?
> Of course, the answer is usually no.

Powers of agency and ostensible authority are no doubt interesting
areas of law. However, I fail to see why the question is different
here from (say) under the CDDL where a contributor makes a license
to the code they contribute available to others ("You") under section 2.
What if Joe and Jane, as engineers, do not have authority to do that?
Same under (say) GPL.

IE the problem is no different to the operation of ANY reciprocal license,
whereby the license to use/modify/distribute the code is conditional
upon the licensee giving others rights to use/modify/distribute their
modifications. Sure, there might be enforcement difficulties (just like
if Joe or Jane signed a contract to buy a building) - but they apply
in both cases and the courts will have no special difficulty in dealing
with these ones.

> Post-SCO/IBM, any corporation that is paying attention is going to
> be extra-careful about the provenance of any code they incorporate
> into a SW product.  Relying on the imputed contract in OVPL strikes
> me as quite risky behavior for an ID.

To be clear, they are NOT relying upon an implied contract. They are
relying upon a license.

If your argument is that contracts are easier to enforce, well, this
applies EQUALLY to the MPL, the CDDL, and the GPL. In his book Larry Rosen
makes the point very eloquently, and indeed this is precisely
why he structure the OSL as a contract (as I understand it - he's
more than capable of speaking for himself). However, we were keen
to base our license on a well understood license that we could adapt.
Larry did not (see archives) give permission to use a modified version
of his license (which is quite within his rights), and I believe his
is the ONLY license framed in terms of a contract.

> What does the question of contractual validity have to do with
> the open source principles per se? Probably not much.  However, since the
> novelty of OVPL vis-à-vis CDDL lies in the license back to
> the ID, it is still germane to the question of whether OVPL should be
> approved.  If OVPL == CDDL + an additional license back which is
> not enforceable, then I do not see a case for approval.

I do not see why the license-back should be any different in
enforceability than the straightforward conditional license in
any reciprocal license. As far as I know, these have had minimal
(if any) testing in court.

You will note in framing the OVPL 3.3 we used language deliberately
similar to the section 2 licenses (as far as possible) so that they
had similar enforceability properties.

Alex