OVPL & "Otherwise Make Available" (was RE: Change ot topic,back to OVPL)

[Alex Bligh]

Chuck,


>> I would construe the wording therein quite widely - for instance I think
>> it would cover making publicly available an FTP server whose code was
>> licensed under the OVPL.
>
> Where do you draw the line?
>
> If I were to run a mail server under either the OSL or the OVPL, which is
> publicly accessible via SMTP, could I make private changes to the
> software without suffering an obligation to publish those changes?

The "where do you draw the line" question is a hard one, but no harder
than other questions of interpretation in copyright law (for instance
what is the dividing line between a trivial modification in which no
copyright independent of the original work subsists, and a derivative
work? Is it one character? one line? 5 lines? 100 lines?).

The question here (under either the OSL, or the OVPL with the amendment
[1]), is are you allowing a third party (i.e. not "You" to "use" the
software). That's a question of interpretation. Note a third party means
a person (natural or legal) not a server or process. I think the answer
here is probably "yes". I admit (under both the OSL and the OVPL it
is less than clear). I will assume the answer is "yes" in order
to respond to the other questions (else the answer to them is clearly
"no").

[1] the wording is not in the OVPL as currently submitted for approval to
the OSI board, but in an amendment on which I'm asking for comments - so
thanks for your comments :-)

> Would I be obliged to put a tarball of the FTP software itself on every
> FTP server I run?

No. "You" (the licensee) are in essence obliged under both the OSL
and the OVPL to provide source code (or an offer thereof) to anyone
to whom you have distributed (which includes External Deployment or
Otherwise Making Available) the work; if that is the public, then clearly
the easiest way to satisfy this is to make the source software public.

But you need only make it public. You need not make it public on the same
FTP software you have amended, let alone on every copy of it.

> Would I have to publish my config files, or the security database itself,
> to anyone who asks, simply because those are derivative works?

No, because the config files and security database are not (or should
not be) derivative works. If they are (let's say you are modifying
sendmail.cf scripts), then I would suggest whoever provides the scripts
might want to provide a license exception here.

> I am much happier with the way Apache v2 defines this:
>
>> "Derivative Works" shall mean any work, whether in Source or Object form,
>> that is based on (or derived from) the Work and for which the editorial
>> revisions, annotations, elaborations, or other modifications represent,
>> as a whole, an original work of authorship. For the purposes of this
>> License, Derivative Works shall not include works that remain separable
>> from, or merely link (or bind by name) to the interfaces of, the Work
>> and Derivative Works thereof.
>
> If I distribute my content, whether that be static HTML or dynamic
> programs running via CGI-BIN, those are seperate works which do not form
> a derivative work.  The Apache license isn't copyleft, but if it were,
> simply running Apache and serving my own content up wouldn't trigger an
> obligation to make source available.
>
> I don't think that relaying mail, or serving FTP files, reasonably
> constitutes a distribution of the SMTP or FTP software itself.  The mail
> message or the file you get via FTP is seperate and independent.

Sure, but that's doing something slightly different. Putting aside the
OVPL for a minute, the idea behind the OSL's clause 5 is precisely
to cover ASP deployment. The Apache license does not cover ASP deployment
(presumably equally deliberately). That's not a drafting issue, that's
a license choice issue.

Alex