OVPL summary

Alex Bligh alex at alex.org.uk
Wed Sep 14 19:50:46 UTC 2005

Larry / Mitchell

--On 14 September 2005 12:27 -0700 Lawrence Rosen <lrosen at rosenlaw.com> 

> The MPL expressly defines "Initial Developer" and "Contributor" in section
> 1.6 and 1.1, respectively. If there is no difference, why two definitions?
> Why all those extra sections that describe the rights and obligations of
> the two in possibly different ways. This isn't just the duplication of
> sections 2.1 and 2.2. All of section 3 describes what a Contributor must
> do but doesn't demand the same of the Initial Developer. Not that Mozilla
> or others who use its license actually discriminate in practice, but the
> license does.
> I admit I didn't compare those sections word for word; I must have
> assumed, based on an earlier NPL license, that there were subtle
> "additional rights." If I have been confused by this, I'm sure others are
> as well. I'm sorry if I described your license unfairly.

I think there is some asymmetry in the MPL, but it is arguably not
materially (certainly not to the extent of the OVPL). I think Larry's
probably thinking of the NPL.

But there *IS* asymmetry there (there is less in the CDDL).

One reason people don't like asymmetry is that if the ID is treated
differently in any respect, it is technically not possible to merge
two products with different ID.

Below is what I wrote earlier on the MPL. Note as I conceded later,
my point (1) used a deliberately wide (and possibly not a likely)
interpretation of Clause 13 of the MPL.



--On 14 July 2005 18:19 +0100 Alex Bligh <alex at alex.org.uk> wrote:

>> Well, no, it doesn't.  I do not need to conduct a negotiation with
>> IBM to create a version which merges code I originated into a
>> variant of Eclipse.  No-negotiation-required is a hallmark of
>> open source-ness, which your OVPL fails.
> I think you do. This is because the question "who is the Initial
> Developer" remains unanswered. I accept that in practice the
> "who is the initial developer" question matters less in (say)
> the CDDL, but it still matters. For instance, if there are two
> separate initial developers, one could restrict the license to
> version 1.0 of the CDDL, and another could not (within the terms
> of the existing CDDL).

I should probably expand on this a bit because it sounds like I am making a
rather pedantic point, which I'm not. Take two products initially developed
by A and B respectively under the MPL v1.1, which actually suffers rather
more than the CDDL.

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. First, note that it is incredibly similar to the
   OVPL provision you are objecting to. Second, note that that the
   right is restricted to the Initial Developer - so if you merge code
   bases, which of A or B has this right?

2. Under 3.3, "You" have to include a
	a prominent statement that the Modification is derived, directly or
	indirectly, from Original Code provided by the Initial Developer
	and including the name of the Initial Developer in (a) the Source
   Now that would appear to be difficult if you don't know precisely who
   the ID is, because (say) you are a third party merging A and B's
   projects. I would suggest it's actually impossible to comply with.

3. If the source trees are "merged" without negotiation, then
   At what date license grant of A's code become effective? If A is
   now to be considered the ID, it will (per 2.1(c)) be when A originally
   published the code. If B is now considered to be the ID, it will be
   when A first made "Commercial Use" of his code - at the latest that
   could be when he makes it available to B (which we know has happened).

I believe that in practice, your comment about mergeability is ONLY going
to apply to license which accord NO differential rights to the Initial
Developer and the contributor. I would suggest a large proporition of
modern licenses would fail this test. On that subject, I will quote Bruce
Perens who put the matter better than I could hope to:

--On 11 April 2005 08:47 -0700 Bruce Perens <bruce at perens.com> wrote:
> Although the license to the original developer is onerous, It still
> allows you to freely redistribute the work. The relationship is
> assymetrical, but not outside of Open Source. The fields-of-endeavor test
> would be the one you should apply to this provision, it passes that too.
> An additional rights grant is not discriminatory under OSD #5 if the
> parties to whom the rights are NOT granted are still getting sufficient
> rights for it to otherwise be considered an Open Source license.

As a further point, I would add that the OVPL relicensing provisions
make merges EASIER not harder. If you accept the point that under the
CDDL (say) merging is not possible without agreement, it has to be
agreement not only between the IDs, but also between every contributor.
Under the OVPL each ID can relicense the code under ANY license, including
under the OVPL with another as ID (i.e. contribute it).


More information about the License-discuss mailing list