OVPL summary

[Alex Bligh]

Ian,


>> So private distribution is not prohibited, it just may not remain
>> private.

(First a clarificatory comment, driven by a confused off-list: by private
here I'm using the word in the sense of the FSF prologue Ian quoted which I
think means 'selective' - I am not talking about in-organization
distribution which the OVPL does not reach into, and doesn't "count"
as distribution at all - same licensee)

> Private distribution that does not remain private is not private
> distribution.  It's the same as public distribution.  Right?

It's still selective (in that it may not be published). I think these
public/private words are confusing - they can either mean "available to
everyone" and "available to fewer people than everyone", or something else
(I'm not quite sure what, but at least one person has read 'private' as
'within the organization'). Let's try "selective" and "generally publicly
available".

> Let me put it another way, in an attempt to make it clearer.  The GPL
> guarantees the right of private distribution given mutual agreement
> among all parties (and, yes, assuming that source is distributed with
> the binaries).  The OVPL does not guarantee that right.

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.

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.

> But there is a qualitative difference between something becoming
> public through the action of somebody in the group who received the
> distribution, and something becoming public through the action of the
> ID.
>
> In particular, it would seem that the ID can go on a fishing
> expedition and request a copy of something which has been privately
> distributed even if the ID is only guessing that that has happened.

I don't think so. The licensee can merely not reply if this has happened.
He won't be in breach of the license because the ID is wrong that there
is an obligation on him to reply.

Sure the ID can go on a fishing trip in the sense that he can allege
that the Licensor has broken the license. But that's the same with
any license. He can (under the GPL) say "we have reason to believe you
have distributed modified versions without accompanying them with
source or publishing them". The compliant licensor can ignore that too.

> For debating purposes, I concede on this point, although I think it
> depends upon what is meant by "notify."  I believe that there is a
> general expectation of privacy in free software, but it may not be
> supported by those exact words.

It wasn't only meant to be a debating point. The obligation of
notification is itself onerous. It requires taking a positive action.
The onus is here on the ID.

> But I think I am right that (1) free software includes the freedom of
> privacy within a group, not just within a company, and (2) the OVPL
> does not guarantee that freedom.
>
> I accept that (1) is open to dispute, subject to a discussion with the
> FSF, but I think we can all agree on (2).
>
> 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.

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

Alex