OVPL summary

[Ian Lance Taylor]

Alex Bligh <alex at alex.org.uk> writes:

> Let me rearrange that into something I think we'll both agree on.
> 
> Under the GPL, a modifier can (if he so chooses) arrange things so
> he can send a derived work to a third party without any obligation to
> make the changes available to any other third parties - he can do this
> by including the source.
> 
> Under the OVPL, that possibility is not there. He must either make
> the changes generally publicly available (i.e. available for everyone),
> or be prepared to respond to a request from the ID for a copy (which,
> if the ID is to use, he must make those changes publicly available for
> everyone). So under the OVPL, there is slightly less freedom, in that
> you cannot distribute a change to third parties and hope to keep them
> out of the "creative commons", as the ID can act as an agent for their
> distribution. Note the role of the ID here is merely to restore the
> situation to what it would have been had the modifier made the code
> generally publicly available himself.
> 
> There is a difference here (clearly). I'm not actually sure who is meant
> to be losing.

I also don't know who is losing.  I agree with your description.  My
only comment is that by dropping the word "private" your vocabulary
slides past my point, which is that GPL provides a degree of privacy
which the OVPL does not.

Privacy is the flip side of openness.  Both are important.  Should
everything be private?  The GPL and open source in general says no.
Should everything be open?  The GPL says no; it should be possible for
two people to share a private secret.


> For instance, you could create a GPL-X in the same terms as the GPL,
> but which said that the obligation to provide source code HAD to be
> done by making the source generally publicly available (whether or
> not it was supplied with executable). It might be undesirable, but I
> don't think it would be non-OSD, and it would (arguably) give the GPL
> rather more teeth.

It would give the GPL more teeth at the cost of removing an important
freedom.  It would be, in my opinion, a bad trade-off.


> > And, for that matter, I think the OVPL is the only open source license
> > which does not guarantee that freedom, although, as I said already, I
> > don't think that freedom is part of the OSD.
> 
> That's certainly not the case - off the top of my head the QPL doesn't
> do that.

Sorry, you're right.  The QPL is a troubling license for several
reasons.

> I /thought/ there where other OSD approved licenses which required source
> to be published, though I'd have to research it.

Explicit publishing requirements have been rejected in the past.


I'm not sure this discussion is getting us anywhere at this point.  I
think I've made my point.  My goal is not to challenge OSI approval of
the OVPL.  If asked, I would advice people against using it, but that
is true of most of the list of approved licenses.

Ian