Are implicit dual-licensing agreements inherently anti-open?

[Michael Bernstein]

On Thu, 2005-07-21 at 17:34 -0700, David Barrett wrote:
> Michael Bernstein wrote:
> > 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.
> 
> It's very clear that the OVPL makes you uncomfortable, and that you 
> might not contribute under its terms.  But could you please detail:
> 
> 1) Which OSI principle does the OVPL violate, and how?
> 
> 2) Why might the OVPL be unenforceable?

I cannot. Others on this list might be able to, and I will defer to
their greater knowledge.

> I agree with your assessment that an ID could be a total loser and abuse 
> his privileges in such a way that hamstrings the project and pisses 
> people off.  The OVPL was never intended to make people nice or smart.

No, but it does seem intended to shield the ID from the worst
consequences of that abuse.

> But it seems to me that *at worst*, if the ID is wholly malicious in 
> every possible way, the greatest harm he can cause is... not 
> redistribute contributions.  I mean, the *absolute worst case scenario* 
> is really not bad at all as anybody can just take the whole body of 
> source code, set up an alternate repository, and manage it like any 
> other open-source project.  Problem solved.

Not really. The ID is set up perpetually as the sole proprietary free
rider. In the worst-case scenario, the ID (and no one else) can continue
to use the forked code as the basis for their proprietary product, even
though they are now expending no effort to maintain it.

We already have licenses that allow *anyone* to be a proprietary free
rider, and licenses that allow *no-one* to be a proprietary free rider.
There seems to only be one implied purpose in allowing only the ID to be
a proprietary free-rider.

> Furthermore, you seem to be discounting that there's any possible way 
> that such an arrangement could go "right".  I mean, do you disagree that 
> it's possible an ID could be smart, could treat his community of 
> contributors fairly, and could actually release code in an open way -- 
> code that probably wouldn't have been released at all otherwise -- such 
> that he and everyone benefits?

Ah, but in the positive scenarios, the normal dynamics of open-source
licensing with a dual-licensing business model would suffice, and the
additional safeguards (in the form of perpetual special privileges) in
the OVPL for the ID are unnecessary.

> Nobody is obligated to use the OVPL.  Nobody is obligated to contribute 
> under the OVPL.  It's just another option that, depending on the 
> application and participants, can go well or badly.

True. Keep in mind though that the OVPL shifts nearly all the risks to
potential contributors. This makes it much less likely that you will
have any significant contributions. In which case calling the OVPL 'open
source' is just a marketing gimmick.

> Just like any other license.

Not quite. Unlike most (all?) other OSD-compliant licenses, it is
difficult to completely escape the ID's bad actions, except by
abandoning the codebase.

I do realize that these are not *necessarily* arguments against OSD
compliance (I'll leave that determination to others).

I would however argue that the OVPL does not represent a useful (from
the OSI's point of view) innovation in software licensing, and I
strongly urge you to reconsider whether you truly need the special
privileges the OVPL grants to the ID.

- Michael Bernstein