Restrictions in license

[Brian Behlendorf]

On Sun, 25 Sep 2005, Rick Moen wrote:
> Quoting Brian Behlendorf (brian at collab.net):
>
>> P.S. - why doesn't the qmail license qualify as an Open Source license
>> given clause #4?  That license restricts my ability to distribute qmail in
>> modified form - but doesn't prevent me from distributing patches.
>
> Not even severely proprietary licences prevent you from distributing
> patches -- at least, not through application of copyright law:  Patches
> are not derivative works.
>
> However, please note that Dan's licence does _not_ meets the criteria of
> OSD clause #4, in that "patch files" may _not_ be packaged up with Dan's
> original tarballs and distributed that way "with the source code for the
> purpose of modifying the program at build time".  To quote:
>
>  You may distribute copies of qmail-1.03.tar.gz, with MD5 checksum
>  622f65f982e380dbe86e6574f3abcb7c.  [...]  If you want to distribute
>  modified versions of qmail (including ports, no matter how minor the
>  changes are) you'll have to get my approval.

Hmm, I don't read it the way you do.  I could create a tarball that within 
it contains qmail-1.03.tar.gz, and patches, and a Makefile that untars 
qmail and applies the patches and compiles it all together.  "With the 
source code" doesn't even need to mean the same tarball - it can simply 
mean that I am distributing qmail-1.03.tar.gz and everything-else.tar.gz 
on the same distro CD, or from the same location.  I realize that DJB's 
perspective (http://cr.yp.to/softwarelaw.html) is that there's no way he 
could prevent such a thing from happening anyways; still, some licenses 
could try to prevent it, and such would be barred by OSD clause #4.  That 
DJB feels compelled to mention it at least indicates that he considers 
this right non-obvious enough to be worth mentioning.

> The "Exception" paragraph at the bottom relates to precompiled _binary_
> packages with very narrowly constrained changes, not source code.

Right - fulfilling the requirement that "The license must explicitly 
permit distribution of software built from modified source code."

So it still seems to me that it's OSD-compliant.

On Mon, 26 Sep 2005, Russell Nelson wrote:
> Rick Moen writes:
> > However, please note that Dan's licence does _not_ meets the criteria of
> > OSD clause #4, in that "patch files" may _not_ be packaged up with Dan's
> > original tarballs and distributed that way "with the source code for the
> > purpose of modifying the program at build time".
>
> True.  With netqmail, we distribute the qmail-1.03.tar.gz unmodified
> along with a shell script that applies the patch, plus documentation
> all in another .tar.gz.  As a practical matter there's no impediment.
>
> > The "Exception" paragraph at the bottom relates to precompiled _binary_
> > packages with very narrowly constrained changes, not source code.
>
> Right, which means that you can't fork the code and compile binaries,
> which is why qmail isn't open source.

You can fork the code and compile binaries, but it must behave according 
to his requirements.  You can't fork the code and make any modifications 
you like - but then apparently other licenses restrict that.



There is a picture emerging for me that the OSD, and DFSG before it, were 
a classic engineer's solution to a political problem.  It was realized 
that there were a set of licenses in the community that did good things 
(like, allow for ISO images to be created of modified compiled packages 
and redistributed without cost and without requiring additional 
permissions) and other licenses that did not.  The ability to do good 
things was conflated with the notion of a broader set of criteria mapping 
to some sort of advanced philosophy about a new way of writing software. 
Instead of simply declaring an arbitrary set of those licenses as "Open 
Source", we as engineers came up with an arbitrary set of criteria that 
fit the popular licenses of the day and could fit future licenses.  It was 
hoped that such criteria would remove the need to make subjective 
decisions about who's in and who's out of our club.  But at the end of the 
day, deciding upon arbitrary criteria is still just as arbitrary as 
deciding upon arbitrary licenses - especially since the desire appears to 
be to have fewer popular Open Source licenses than criteria in the OSD!

Suggestion: dump the current OSD, preserve and clarify the few criteria 
that really matter (such as the right to fork) and recast them as 
requirements but not by themselves sufficient to get the Open Source 
trademark and seal-of-approval.  Stop calling it a certification process. 
New licenses aren't just approved, they are curated and improved until 
they represent a unique solution in the problem space, and are then 
accepted and promoted.  Care for them the way that the FSF cares for the 
GPL.  Authority and trust will come not from pretending that the OSD is 
written in stone and the OSI board are but impartial judges; but rather 
from the membership/election discussion underway.

 	Brian