The Python licensing situation.
chuck at codefab.com
Fri Jun 10 18:32:07 UTC 2011
On Jun 9, 2011, at 11:17 PM, Rick Moen wrote:
> [ ... ]
> Quoting Chuck Swiger (chuck at codefab.com):
>> In fact, OSI has approved licenses which forbid distributing modified
>> works except as patch files. This was done to largely to recognize
>> that software like DJB's qmail is still OSI open source.
> I may regret biting on this one.
> 1. Professor Bernstein's commendably generous pre-2007 licence for
> qmail was always an interesting edge case.
Yes, it was.
> I don't believe OSI ever opined that any of his pre-2007 licences, which he put on his Web pages, for software such as qmail 1.03 or djbdns 1.05, are open source, or am I
> misremembering? (I'm not saying you claimed that; just seeking
I think you and Brian Behlendorf discussed this back in 2005. The restriction on not modifying the original sources except via patches was generally considered OSD-clause-4 compliant (and Debian Free Software Guidelines compliant).
The restriction on distributing precompiled binaries from modified sources per:
...was the main cause of disagreement. The distribution terms did permit modified binaries to be redistributed, but only if they met the conformance requirements, as you'd noted per (b):
> 2. What made it an interesting edge case was some of the particulars,
> so let's review:
> (a) One of his pages, http://cr.yp.to/qmail.html,
> stated (pre-2007) that the qmail 1.00, 1.01, 1.02, or 1.03 source tarballs
> with stated MD5 hashes (i.e., unaltered) may be freely distributed. No
> modification of any sort was authorised for distribution, except as
> provided in item (b), next:
> (b) A separate page, http://cr.yp.to/qmail/dist.html, stated pre-2007 that
> binary compiled derivatives of qmail 1.03 may be redistributed provided
> they meet certain of Prof. Bernstein's conformance requirements, e.g.,
> being confined within /var/qmail. A binary package compliant with Prof.
> Bernstein's conformance requirements was dubbed a 'var-qmail package'.
The question is whether this aspect violates OSD #4. Technically, it does not (IMO), but I'm not sure we'd approve a newly submitted license with similar restrictions today.
More information about the License-discuss