OVPL Summary, Take 3

[Chris Zumbrunn]

On Sep 18, 2005, at 5:11 AM, David Barrett wrote:

> A) The OVPL violates the OSD due to its inherent asymmetry.

Your summary still does not adequately describe this problem.
Your rebuttal misses the point, plus your argumentation is flawed.

> B) The OVPL enables the ID to "freeload" on the community.

B) describes an issue that is already contained in A). I don't think
you need to list it separately.

> C) The OVPL uses ambiguous language surrounding "distribution".
>
> The rebuttal to this is that the OVPL's language surrounding
> disclosure requirements is not materially different than the
> OSI-approved CDDL or indeed many other licenses, and thus
> this is really a complaint about the ambiguity of many licenses,
> and not the OVPL specifically.

C) is a drafting issue. It is not material to the question of
OSI-approval and therefore best dropped from such a summary.

> D) The OVPL forbids "private groups", such as the GPL allows.
>
> The rebuttal is that this is an OSD-compatible feature, not a bug.

If you want to include this point in this summary, you at least
need to make clear what it is about (for someone that didn't follow
the discussion). I don't think it needs to be included, because even
if it is a bug, the OSD does not seem to care about it (unless you
somehow want to see this as another form of "discrimination
against persons or groups"). I think the concern is a DFSG concern,
not an OSD concern.


Stealing from the wording in Brian's message that I referred to in my
previous reply, a summary would look like this:

***

1) To what extent does the OVPL's grant of additional rights to
the initial developer thwart the rights of subsequent developers to 
fork,
in particular, does it prevent derivative works "to be distributed under
the same terms as the license of the original software" (OSD#3)?

Perhaps the answer here is: no problem. Subsequent developers are always
free to fork, they just have to be comfortable with the fact that all of
their work may be used in a proprietary version by the ID. This is sort
of true of any BSD project fork, with the difference that the forking
developers share with the ID the right to take their work proprietary.
The central question is whether enshrining such an asymmetry in a 
license
squares with open source principles or whether it prevents derivative
works from being sub-licensed under the same terms. It would also
probably be a defensible position for OSI to say: "Contributors beware:
Some open source licenses treat everyone the same and other open source
licenses grant special rights to certain people. Be sure you are 
comfortable
with this before you contribute under such a license."

2) Is a license with a copyleft provision that grants greater rights to
an initial developer than it grants to other licensees consistent
with OSI's principles, in particular, does it constitute "discrimination
against persons or groups" (OSD#5)?

There is a difference between the law providing an original
author with additional rights, and enshrining further additional rights
in an OSI-approved license. The OSI cannot directly control what laws
are enacted in various countries, but they do directly control what
licenses they approve. It would be a defensible position for the OSI to
say, "The law may give the original author additional rights not
provided to others by an open source license, but we will not approve
any license as 'open source' that seeks to further that asymmetry of
rights by treating some contributors differently than others."

***

I just realized that not even the QPL can serve as precedent for these
two problems in the OVPL. The QPL only allows the ID to merge patches
that are made available by other contributors, back in to the 
"Software",
provided that *such versions* remain available under the terms of the
QPL in addition to any other license by the ID. This means the ID can
only dual license *the same work*, but not use the contributions in
derivative works that are not made available under the QPL.

Note that the OVPL only requires the ID to release *a version* 
containing
a contribution under the OVPL, while the QPL requires the ID to release
*all versions* containing a contribution under the QPL.

Chris