Are implicit dual-licensing agreements inherently anti-open?

[Michael Bernstein]

On Thu, 2005-07-21 at 20:15 +0100, Alex Bligh wrote:
> My reply was to Michael Bernstein, who was talking about the ability
> of Contributors (not the ID) to make proprietary versions. There is no
> such ability in the OVPL (it's the same as the CDDL in this respect,
> or for that matter the GPL). The bit of 3.3 (which grants the ID, not
> Contributors, the right to use contributor's modifications in the ID's
> proprietary versions) that gives the ID the right to require a
> distributor of modifications to provide them to the ID applies only to
> modifications which are selectively distributed, i.e. which are not
> made available to the general public (either because source code is
> distributed alone to a selective group, or because source code plus
> object code is distributed to a selective group, or because object
> code is distributed to a selective group and the source code is only
> made available to that group).

I believe I now understand.

- You want to prevent anyone else from making proprietary versions that
leverage the ID's investment in the code, except as (possibly)
proprietary plug-ins to a shared API.

- You want to reserve the right to make proprietary versions of the main
codebase to the ID.

So far so good. This can be accomplished very easily by licensing the
main code under the GPL (for example) and adding a special exemption to
allow proprietary plug-ins to use the common API.

However, you also want the ID to be able to incorporate community
modifications to the main application into the proprietary version.
Ordinarily, this would be accomplished by the contributor assigning or
licensing their modifications to the ID under terms that would allow
that, possibly for some additional consideration.

But you want to make this a condition of the license. For a number of
reasons, even if the resulting license were determined to be OSD
compliant, I don't think this would work. At all. Being able to roll
other people's work into your proprietary offering is a *privilege* not
a right.

Ordinarily, small bugfixes and the like are sent back to the ID for
inclusion in the main *free* codebase for a variety of reasons, such as
the developer thinks it's the right thing to do, or to remove future
maintenance headaches. In some cases, the ID (and maintainer) requires
an assignment in order to include the patch. The incentives for the
contributor to do so even without further consideration are fairly well
understood by now, and don't even require a reciprocal license to work
(Zope for example has a BSD-style license, but nothing gets checked in
to the SCM repository unless the developer has signed a contributors
agreement that includes a blanket assignment).

In this case though, the modification in question gets assigned back to
the ID with no guarantee that the change will make it into the free
codebase at all. From a social point of view, the ID is acting paranoid
in that it is seeking to prevent free competition to it's commercial
product from 'vile offspring' of the free codebase, and is in turn
inspiring mistrust. It would only take one or two instances of a bugfix
appearing in the ID's proprietary codebase first (or something similar)
to piss off everyone who had built a service business around the free
codebase (and possibly their own plug-ins). There is also ample
opportunity to retard the growth of the free codebase to maintain the
market for the proprietary offering.

This license is setting up a very precarious situation, ripe with
potential for all sorts of abuse by the ID, and that potential (even
absent actual bad faith on the part of the ID) will scare away most
potential contributors. I just don't think you will get the end result
you want, unless your goal is simply to be able to call your software
'open source' with few of the attendant obligations or risk.

Otherwise you might as well just call it 'visible source freeware' that
allows rebranding and third-party plug-ins, because that is what you are
setting up in practice.

You might consider taking this discussion to the Free Software Business
list (http://www.crynwr.com/fsb/) for further discussion of how your
business goals can be met without resorting to creating a new license.

- Michael Bernstein