Restrictions in license
brian at collab.net
Wed Sep 28 04:41:55 UTC 2005
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.
More information about the License-discuss