OVPL summary

[Alex Bligh]

--On 14 September 2005 12:25 -0700 Michael Bernstein <webmaven at cox.net> 
wrote:

> Well... that sort of depends on exactly how you define 'fork'. Since the
> ID can always mine any version for improvements to add to their
> proprietary product, regardless of the other contributors' wishes,
> forking to escape bad stewardship and community parasitization by the ID
> is very difficult (though perhaps not *quite* impossible).

"Community parasitization (sic)" is a perjorative term - it says no more
than that the ID has an additional license back. We know this. The intent
is that it cannot be "escaped". Quite clearly it will be unacceptable to
some (perhaps many) potential contributors. Quite clearly it is
inappropriate for many projects. These matters are not in dispute. The
answer here is for developers not to use the license where it is
inappropriate, and for people not to contribute code if they are unhappy
with the deal. Saying the license should not be approved because it doesn't
meet the OSD, and it doesn't meet the OSD because it is "parasitic" (i.e.
contains a license back) so shouldn't be approved is circular. So (apart
from the perjorative term) I agree with you about the "parasitic" nature,
but don't see why this should prevent approval.

As to poor stewardship, I'm afraid I disagree. There is NOTHING to prevent
a fork in the OVPL. Someone else can go maintain another version. The ID
will get license back. As the fork diverges from the ID's own code, the
license-back will be less and less useful, as code-bases will be harder to
align. It ENCOURAGES good maintainership.

>> So long as the changes I might make remain publicly available, for
>> anyone to  use, I don't object if the ID has the right to also create
>> proprietary works  using my changes.  I don't think the OVPL should
>> become an OSI-recommended or  top-tier license, but my feel is that it
>> conforms with the OSD.
>
> But what about the fact that any *private* changes you make to the
> software can be demanded by the ID and incorporated into both their
> proprietary version *and* the public version, regardless of your wishes?

Only if you distribute them. In which case they are (by definition) not
private. If you make the changes privately, and don't distribute them,
the ID does not get rights to them.

Alex