Are implicit dual-licensing agreements inherently anti-open?

[Alex Bligh]

Andrew,

> Alex Bligh wrote:
>
>> 1. Under 13, the Initial Developer (but not a contributor) has the
>>   right to designate portions of the Covered Code as
> Multiple-Licensed.
>>   Note the Covered Code INCLUDES Modifications contributed by others.
>>   As the Multiple Licensed code can be made available under ANY
> license
>>   (provided is is also made available under the MPL) this in practice
>>   allows the ID to do a very OVPL-like thing, and run a completely
>>   proprietary version.
>
> Your characterization of MPL 1.1 is completely wrong.  Since there is
> no license back from Contributor to Initial Developer, except insofar
> as Initial Developer may obtain a copy of Contributor Version under
> MPL (or other license which might have have been applied to
> Multiple Licensed code at the time of original publication), there is
> no license for ID to take any Contributor Modifications and make them
> proprietary.

I fully admit to twisting the words of the MPL to allow it to do
something which was probably not the authors' intent. However, I don't
see what is wrong with my interpretation. Why can the ID not do
precisely what I say, and achieve (in effect) a license-back - or
even a retrospectively introduced license-back?

> And by the way ... since you didn't respond the first time around ...
> let me ask the lawyers who read this list again about the
> enforceability of said mandatory license back.  Since it is part of a
> bare license and is not backed up by an actual, signed agreement
> between the parties (as is the case in an open source project with
> a contributor's agreement), is it enforceable?  IANAL,
> but I strongly suspect my legal colleagues would far, far prefer
> to have an actual contract to establish the provenance of any
> code we would ever take into a proprietary SW product.

Sorry, I didn't respond because I don't see a problem. I was waiting
for someone else to say WHY they thought it was unenforceable. In
the absence of which, I'll cover what I see as the current arguments.

Let me first address the principle of license-back.

The only problem I know of that has been mooted is that some jurisdictions
require certain things to be done in writing.

As far as I understand it, various jurisdictions including the US require
copyright assignment to be made in writing. Hence any form of electronic
license is not going to be enforceable if it attempts to achieve a
copyright assignment in those jurisdictions (I understand that a subset of
the jurisdictions that require assignments to be made in writing do permit
enforceable contractual agreements to make an assignment other than in
writing, but in those jurisdictions in order to effect the assignment the
agreement itself would have to be enforced).

However, all this is irrelevant in terms of the OVPL, because what it does
is a grant license, not make an assignment. The additional license it
grants to the ID under 3.3 is no  different in legal terms than the license
it grants under 2 to subsequent users, at least as I see it, and indeed the
license by which the contributor himself acquired rights to modify the
code. I am quite willing to accept there may be jurisdictions in which the
3.3 license fails, but in those jurisdictions I believe the grants in 2
would also fail for similar reasons, because they are qualitatively the
same.

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. In an assignment, the assignor gives up their
legal rights in favour of the assignee. This is not the case under
the OVPL license-back: we do not have provisions that (for instance)
make the license conditional on the contributors agreement to not
assert their IP rights in the licensed material against others, or
make the license exclusive, or seek to prevent the contributor from
further distribution.

Also, you describe it as a "mandatory license-back". That slightly
mis-characterizes (though I fully understand what you mean). It is really a
/conditional license/ - i.e. your license to use/distribute/modify the code
is conditional upon your agreement to license (i) any modifications to
others under the terms of the license (as per CDDL), and (ii) to the
ID under broader terms. So the potential contributor has a choice
(just like the do under the GPL or CDDL) - don't use the code in the
first place, or use it according to the terms of the license. If they
do choose to use/modify/distribute the code, the license to the ID
is mandatory in exactly the same sense that the license to any other
user is under section 2 (i.e. it is a condition of the license). As
Larry Rosen would no doubt point out, the remedy the ID has is in
IP law, not in contract.

Secondly, the issue of the enforceability of the OVPL license-back
as currently drafted. I believe this to be enforceable (well I would,
wouldn't I, I drafted it), and we have taken advice in one jurisdiction
which indicates that it would seem to be enforceable. I have had no
suggestions from anyone that it's not. David Barrett commented that
it was incomprehensible to a layman, which while unfortunate if true
is not a barrier to enforceability - I suggested deleting a chunk of
it as I think it makes little practical difference but haven't had
a response. If there is a reason you think it's unenforceable, I'm
keen to listen & correct it if necessary.

Alex