license submission: qmail

[Matthew C. Weigel]

On Thu, 7 Jun 2001, Brian Behlendorf wrote:

>    4. The license may restrict source-code from being distributed in
>    modified form only if the license allows the distribution of "patch
>    files" with the source code for the purpose of modifying the program at
>    build time. The license must explicitly permit distribution of software
>    built from modified source code. The license may require derived works
>    to carry a different name or version number from the original software.
> 
> I think this is a flaw in the OSD - what it means is that those authors
> who place their software under such a license effective make forking
> impossible.  Why?  Because a project aimed at building a derivative work
> may not have a shared code tree, making collaboration impractical enough
> to effectively prevent a fork.

Automate patch, and you have a shared source tree.  There is no
technical limitation to forking, there is simply a higher cost attached
to the technical possibility.

> This allows for pragmatic window-dressing and bug fixing by
> repackagers like Debian and other linux distributions, but it does
> not really provide for the same checks on power between developers
> that are really what open source is all about.

I submit that checks on power is not the point of open source (or free
software), but rather the freedom from legal culpability in sharing,
and the removal of the most onerous restrictions that prevent forking.
"Most onerous restrictions" would include things like running code
through an obfuscator, distributing in pseudocode or assembly, etc.

> By this token, I hereby submit that qmail's license terms, at least as
> defined at http://cr.yp.to/qmail/dist.html, passes this clause, and the
> others in the OSD, based on one theory - that the requirement
> 
>   only if the license allows the distribution of "patch files" with the
>   source code

I think that "...software built from modified source code..." implies
*binaries* built from modified source code fairly clearly.  Which is
not allowed.

> is superfluous.  Such a promise never needs to be made, because a
> potential redistributor *always* has the right to create and distribute
> patches (was it the Accolade case that established that?), and "with" is
> not well defined and could simply mean on the same CD or from the same
> website, though that's largely immaterial: I have the right to distribute
> patches to qmail - I even have the right to create a single tarball that
> includes the qmail tarball and my patchset.  These are standard rights
> under copyright law - it's clearly a "compilation", and not a derived
> work.

I think it is relevant, given the way case law and the legislators are
leaning now, to mention the need in the definition, though.  It renders
interpretations of copyright law by judges and juries irrelevant - open
source software must allow at least distributing patches.

> The other terms of clause #4 are met by DJB's requirements on package
> builders that he states on that same page.  The other clauses in the OSD
> are also not violated.  Clause #3 would be in question, but #4 seems to
> allow exceptions to #3 - which seems to fly in the face of the rationale
> of #3: "people need to be able to experiment with and redistribute
> modifications".

People need to be able to distribute at least patches so that fellow
hackers hacking the same piece of software can experiment, and people
need to be able to distribute binaries of their hacks for people less
inclined to compile themselves.

> Thus, I submit that either qmail's license be approved as an
> OSD-conformant license, or OSI consider whether clause #4 needs, er,
> "clarification".  It's hard to argue that neither is the case.

I would, although I'm not against clarification.
-- 
 Matthew Weigel
 Research Systems Programmer
 weigel+ at pitt.edu