[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Status of qmail?



On Tue, Jul 14, 1998 at 07:25:27PM +1000, Manfred Bartz wrote:
> I am aware of the quirky licensing of qmail which so far has prevented 
> it from being packaged.

I will at some point be emailling the author about that.  It's possible
depending on what his biggest concerns about the software which cause him to
use the licensing scheme he does are.  His interests seem to be security,
portability, and being sure the program works as advertised.  It's possible
to do that and remain DFSG free.  I'm sure if he sees a reason to change
licensing terms, he'll likely do it.  Considering how much easier qmail is
to configure than smail or sendmail, it'd be a major success on systems
which don't need the complexity of some of the oddball things one can do
with sendmail.

Does anyone else think that qmail would be a better default MTA than smail
if it were free software or am I alone in this belief?


> What I would like to know is if any Debian developer is working on
> packaging qmail.  Or maybe qmail under a different name?

qmail-src, compiles with build-qmail.


Think about it, under current terms:

* qmail source must be pristine unless you get approval for changes.
* diffs are not only allowed but encouraged.
* bins are allowed as long as they meet certain criteria.

Uhoh.  That last one is the killer.  What criteria must be met for bins?

"
   Exception: You are permitted to distribute a precompiled var-qmail
   package if (1) installing the package produces exactly the same
   /var/qmail hierarchy as a user would obtain by downloading, compiling,
   and installing qmail-1.03.tar.gz, fastforward-0.51.tar.gz, and
   dot-forward-0.71.tar.gz; (2) the package behaves correctly, i.e., the
   same way as normal qmail+fastforward+dot-forward installations on all
   other systems; and (3) the package's creator warrants that he has made
   a good-faith attempt to ensure that the package behaves correctly. It
   is not acceptable to have qmail working differently on different
   machines; any variation is a bug. If there's something about a system
   (compiler, libraries, kernel, hardware, whatever) that changes qmail's
   behavior, then that platform is not supported, and you are not
   permitted to distribute binaries.
"

At first it seems that means making the package conform to the Debian
filesystem (either FSSTND or FHS or anything else for that matter) would not
be allowed.  HOWEVER, Debian's qmail-src package results in a qmail .deb
which CAN be used with the normal /var/qmail/* layout because /var/qmail is
a symlink tree maintained for compatibility.  If the author agrees that's
good enough, then there is no reason a binary qmail package can't be in
non-free.

However, while confirmation that the symlink tree is all Debian needs to be
able to distribute a binary, it's not enough to satisfy point 4 of the DFSG:

    4. Integrity of The Author's Source Code
       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. (This is a compromise.
       The Debian group encourages all authors to not restrict any files,
       source or binary, from being modified.)

The license doesn't grant permission to dostribute bins which do not fit his
above criteria at all.  If they had to document changes, give credit, and/or
change name of the program people might be annoyed a bit by distributing
derived works and just stick to source patches, but it would be possible for
a person to make the program do something it doesn't.

Of course if derived works were under the same license, the changes could be
incorporated if DJB wished them to be.  I'm not going to suggest he make the
license completely GPL compatible because frankly I suspect he will not want
qmail "infected" with the GPL.  I can't say I blame him terribly much for
that, but that's another argument..


Qmail might (but I don't think so) violate point 3 as well:

    3. Derived Works
       The license must allow modifications and derived works, and must
       allow them to be distributed under the same terms as the license
       of the original software.

Lets see, qmail's license in a nutshell:  source is okay and is the
preferred method of distribution.  Source patches are okay if you want to
write them.  Bins are okay only if they remain compatible and behave
properly.  This is probably not a problem.  =>


Any discussion or corrections I'd like to hear---so long as they're not
about the advantages and disadvantages of GPL vs. anything else.  =>

Attachment: pgpyhHTOzHTno.pgp
Description: PGP signature


Reply to: