Are implicit dual-licensing agreements inherently anti-open?

[Michael Bernstein]

On Fri, 2005-07-22 at 10:50 +0100, Alex Bligh wrote:
> Michael,
> 
> > 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.
> 
> Yes(-ish).
> 
> However, we don't want to restrict it to plug-ins. Equally bugfixes,
> straightforward functionality additions etc. - sadly not everything
> is GPL'able.
> 
> > 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.
> 
> (or pretty much equivalently, just use the LGPL).

Not exactly. LGPL would not necessarily restrict to a shared API. You
could make the bulk of the program GPL, and the API implementation LGPL,
though. This would allow re-use of the API in another program.

> The problem with that approach is that it does not allow bug-fixes
> feature additions etc. to the main program to be used by the ID.

Well, that is what assignments and licenses are for (possibly for
additional consideration). The quid-pro-quo of a reciprocal license
properly applies to further free use of the contributors code, not
proprietary use.

It ought to be up to the contributor to explicitly decide that the ID
may use their code in this way. Most would do so, as long as the ID
continues to demonstrate good stewardship, but the ability to withhold
such permission for *future* modifications is an important 'stick'.
Eliminating this option for the Contributor means the ID does not have
to play fair, except to the extent they voluntarily limit their own
conduct. I think we're all familiar with examples of how such purely
voluntary limits sometimes work out in the long term.

> > 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.
> ...
> > 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.
> 
> Incorrect. That is the second half of 3.3. It expressly provides that
> the ID only gets the license to include the code in his proprietary
> version, if it makes it into the free version.

Hmm. That is a helpful limitation, thank you for pointing it out.

- Michael Bernstein