The Python licensing situation.

Chuck Swiger chuck at
Fri Jun 10 18:32:07 UTC 2011

On Jun 9, 2011, at 11:17 PM, Rick Moen wrote:
> [ ... ]
> Quoting Chuck Swiger (chuck at
>> 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
> clarification.)

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,,
> 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,, 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 mailing list