Are implicit dual-licensing agreements inherently anti-open?

[Michael Bernstein]

On Wed, 2005-07-20 at 22:33 +0100, Alex Bligh wrote:
> I think your reading is mostly right. 3.3 only applies to "Licensed
> Modifications" which are Modifications that "You contribute,
> distribute, or
> otherwise make available whether in Source Code form or in Executable
> form." and thus does not cover modifications that are private &
> undistributed.
> 
> The written request of the ID bit (to which Andrew Wilson refers) thus
> is
> only relevant to Licensed Modifications which are NOT made generally
> available to the public at large (i.e. those selectively distributed).
> In
> this instance (only), the ID can ask for details of those
> modifications.
> This was a formulation we came up in response to some response on this
> list.

Hmm. Let me see if I understand this right.

- The ID releases software under the OVPL.

- Developer A makes private undistributed modifications and the ID
cannot ask to see them.

- Developer B makes some changes to the software, and releases a
proprietary derivative. The ID can ask to see the changes, and
incorporate them into the public release of the software.

- Developer C makes some changes to the software, and releases a
proprietary derivative. The ID can ask to see the changes and can
incorporate them into his *own* proprietary offering, without releasing
the code publicly.

- Developer D makes changes that she releases publicly under the OVPL.
The ID can incorporate these modifications into their proprietary
version too.

It seems to me that this is setting up a situation that in some ways is
the worst of all worlds: The ID can co-opt into a proprietary codebase
any publicly released derivative code, AND the ID can co-opt any
proprietary enhancements made by other vendors as well. This will most
likely have the effect of discouraging both a free software community
(other than part-time noodling and some bugfixes) and a proprietary
vendor ecology (other than superficial rebranding) from growing around
the OVPL code.

This is a big-fish-small-pond rent-seeking strategy, basically, though
it could work to defend a small niche long enough to be bought out by a
large proprietary vendor.

I would, however, also anticipate that a sufficiently determined
community or competing vendor could deliberately diverge/refactor the
code to make the incorporation of their subsequent improvements back
into the main codebase as difficult as possible.

What was it you were hoping to accomplish with this license, again?

- Michael