Are implicit dual-licensing agreements inherently anti-open?

[Michael Bernstein]

On Fri, 2005-07-22 at 19:46 +0100, Alex Bligh wrote:
> > Severity: Reciprocal licenses (which on the face of it the OVPL is)
> > exist largely in order to avoid this scenario. So, I would assume that
> ...
> > Probability: Likely low for any particular project, but near certainty
> > overall if the license is at all widely adopted, and plenty of IDs *are*
> ...
> Note, as per my earlier post, the REAL solution here is to make sure
> that it's not in the ID's interest to play badly.

The GPL and other reciprocal licenses manage this quite handily.

> Someone (and if
> it was you, sorry) pointed out that contributors can make code hard
> to merge. They can also cease contributing. They can also fork. All
> these things and more will happen if an ID doesn't play ball.

But making it hard to merge or forking doesn't stop the ID from becoming
a complete freeloader on the community (ie, they can always relicense
the forked code as a proprietary product), nor does it stop the ID from
relicensing to anyone else that wants to violate the spirit of the
license. Quite a nice racket, if you can set it up.

> You have much the same problem with a project that demands assignments
> external to the license to the maintainer.

Not true. For projects that use reciprocal licenses like the GPL,
assignment of future contributions to the ID can be withheld without
abandoning the codebase.

About the only thing that can be done with the OVPL in this situation to
stop the freeloading is to abandon the codebase (and any investment made
in it) entirely and stop contributing. A fork isn't sufficient, you have
to kill the free project.

- Michael Bernstein