Are implicit dual-licensing agreements inherently anti-open?

[Alex Bligh]

Andy,

--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
	Code,
   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).

Alex