OVPL summary

[Michael Bernstein]

On Wed, 2005-09-14 at 20:44 +0100, Alex Bligh wrote: 
> 
> --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.

Yes, it's a pejorative term, but it was only my intention to suggest
that the license enables parasitization, not that such parasitization
was inevitable (at least within any particular project), or even that an
ID necessarily wanted to engage in parasitic behaviour when choosing a
license like the OVPL (though I guess that will be true of many).

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

I did not describe the OVPL as parasitic. I am only saying that *if* the
ID behaves parasitically, there is little the community can do. 

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

Only up to the point that the ID gives up maintaining their fork, and
thereafter concentrates only on making proprietary value-added versions
of the community-maintained fork.

And remember, assuming the good intentions of the *current* holder of
the ID baton is shortsighted. 

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

I am well aware that the license-back only applies to 'Licensed
Modifications' and not all 'Modifications'.

(incidentally, the title of section 3.3 could be made a little more
clear in this regard: "Additional License of Licensed Modifications to
Initial Developer.")

Perhaps the problem is that I am casting a very wary eye on the
definition of 'Licensed Modifications' which is:

        1.10. "Licensed Modification" means Modifications that You
        contribute, distribute, or otherwise make available whether in
        Source Code form or in Executable form.

It's the 'otherwise make available' phrase that is worrisome to me.
You've made it clear that this *is* intended to close the
'software-as-a-service' loophole, so that, for example, an otherwise
undistributed-but-modified OVPL licensed SMTP server would (by virtue of
being publicly accessible) not qualify as a private change, and would
require disclosure of the modifications to the ID.

I assume that interposing an SMTP relay so that external users are never
*directly* using the OVPL code would not get the modifier off the hook,
because users are still using the functionality of the OVPL code, albeit
indirectly, so it is still being 'otherwise made available' (because,
after all, their own ISP's SMTP server is already acting as such a
relay).

So, let's assume that the OVPL code is some inventory management system.
Would an extranet (used by suppliers) that hooks into it constitute
making the functionality of the OVPL code 'otherwise available'? What
about a web storefront that shows availability of items?

Even if these particular examples turn out to be 'safe' according to a
particular legal opinion, I can think up others.

So, there are plenty of edge-cases and fuzzy boundaries here. Nothing
really new where the realms of software and law intersect, but it seems
to me (though IANAL, and TINLA) that there is *so* much opportunity for
mischief here that the only safe course is to assume that all
modifications must be made available to the ID, especially if the ID
asks for them.

- Michael