Are implicit dual-licensing agreements inherently anti-open?

[Alex Bligh]

Michael,

> 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.

Yes. And indeed in many jurisdictions, private undistributed modification
of computer software (at least for certain purposes), in the ABSENCE of
a license, is not prohibited by law anyway.

> - 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.

Sort of. It's right if you substitute "proprietary" for "selectively
distributed"

Developer B can't release a "proprietary" derivative in the sense of
a derivative that's not under the terms of the license. So, for instance,
if they release object code to end user X, end user X can ask for
source code, gains all the rights under the license.

The situation about "partial distribution" is where, for instance, B sells
some form of specialized hardware appliance, and only distributes the
modified executable with the hardware. Only those buying the hardware can
then ask for the source under the (unmodified) CDDL, GPL, etc. Joe Public
cannot (even if Joe is a contributor). What the OVPL does additionally
here is give the ID a right to request modifications, where B is not
making them publicly available.

> - 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.

Again, the first "proprietary" needs to be replaced with "selectively
distributed". Then this is the same as "B" above.

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

Yes.

> 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.

No. I think you are confusing "proprietary" with "selectively distributed".

The ID can incorporate ANY distributed modifications into its own code
base, so long as it makes them generally available. Where the modifier
does not make them generally available, the ID can ask for them.

> 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?

I appreciate that some of what you wrote above is based on the confusion
between proprietary and selectively-distributed open-source (the
latter being not only a potential, but an actual problem with all
reciprocal licenses).

I think what we are trying to achieve is pretty well set out in the
FAQ. However, to reiterate, the idea is that ONLY the ID is going to
have the right to distribute proprietary (by which I mean not
covered by the terms of the license, and thus not open source) versions;
the idea is to prohibit this. But we are trying to ENCOURAGE open source
input.

Yes, you are entirely correct, that there are advantages to the ID in
getting the benefit of the community's input into their proprietary
project. We have been more than up-front about that! However, that does not
necessarily mean there are DISADVANTAGES for the contributors (those who
make their contributions publicly available, which is the norm, have no
additional obligations). Yes, we agree that some community members will
prefer to contribute to a "purer" open source project, but they will do so
without the benefit of the code base provided by the ID. That's a
trade-off which each potential contributor will have to call. If the
code-base is worth nothing, or nearly nothing, then clearly the OVPL
is an inappropriate license. We have been more than upfront about that
too. We do not, however, believe that it this will restrict open-source
contributions to bugfixing and "part-time noodling" (the latter in
quotation marks as many reputable open-source projects have been
written by what their authors might describe as part-time noodling).

You are also quite right that a sufficiently determined portion of the
community could try and make incorporation of modifications deliberately
difficult. This happens under open license. It's a fork, plain and simple.
Some people do it deliberately. The presumption is that the ID will be the
maintainer, will play fair, and will continue to contribute substantially
to development. If they don't, you highlight exactly what will happen,
which is that it will become a community project entirely, 3.3 will be
there in letter only (because the modifications will become impossible to
backport to a proprietary tree), and the ID will lose control. This is the
INTENTION of the license - the ID has to play fair. Why is that a bad thing?

Alex