Letters to the editor

qmail

Greetings,
 
In your issue of 27 May, 2004, you talked about the recent license change for
Movable Type 3.0, and warned your readers about the dangers of "almost free"
proprietary software. All well and good, but you then went on to make several
parallels with qmail (by Dan Bernstein) which I do not believe were quite apt,
for reasons I'll discuss.
 
You said qmail:
 
> [...] comes with a non-free license which forbids distribution of modified
> versions, and which makes the distribution of binary packages difficult.
 
Fair enough, and true. You do clarify later that qmail doesn't come with an
explicit license; instead, if you obtain a copy of qmail, the author believes
you have various rights granted to you by copyright law (such as the ability
to modify and use it as you see fit) that he does not need to explicitly
grant. These rights are ones that click-through "license agreements" of
commercial proprietary software typically tend to try to abrogate. The author
also notes that copyright law does not permit you to copy and redistribute the
software (under any conditions), so he then explicitly grants the right to
redistribute unmodified copies of the source code, plus binary packages that
meet certain criteria. It's all laid out fairly clearly in these two pages:
 
http://cr.yp.to/qmail/dist.html
http://cr.yp.to/qmail/var-qmail.html
 
I will grant that creating a binary package of qmail that satisfies the above
criteria and /also/ meets criteria for inclusion in a modern Linux or Unix
distribution would be problematic. But installing qmail from source is so
simple that I don't personally find that to be an obstacle.
 
The more troublesome statements follow later:
 
> There has not been a new qmail release since June, 1998.
 
The author has not released a new qmail tarball since that time. People used
to "release early, release often" might see that as indication of abandonment,
but it isn't the case with djb's software. Despite qmail-1.03 being six years
old, it /still/ has not had any security holes found in it, despite two cash
awards being available for the discovery of such.
 
> But, due to the redistribution restrictions, nobody can take over qmail
> maintenance and release a new version.
 
Some of us have tried. "netqmail-1.05" is a package which includes an
(unmodified) qmail-1.03 source tarball, a few (small) patches, and a script
which applies them. netqmail runs just fine on modern systems and fixes a
couple of tiny, non-security-related bugs later found in qmail. netqmail is
available from the qmail.org community site:
 
http://qmail.org/netqmail/
 
The most problematic statement you make almost qualifies as FUD:
 
> If qmail's author were ever to proclaim a new license, it would be hard for
> users to prove that any other terms had ever been in force.
 
The author has had these claims directed at him before. He points out, quite
rightly, that:
 
  -he has explicitly granted the right to copy and distribute unmodified
  source, with no expiration on this permission.
  -this statement is clearly present on his website, and is archived in
  many different places. Even if he changed his site, it would not
  retroactively revoke the permissions he has granted.
  -his statements granting such permission would definitely be taken into
  account if he ever tried to use the courts to revoke such rights. You
  cannot assure people you do not object to a hehaviour and then try to
  extort damages from them for such behaviour.
 
The qmail community feels there is no risk here.
 
One additional correction:
 
> [...] it seems pretty clear that qmail's author has long since lost interest
> in working on the code; the chances of there ever being another qmail
> release appear small.
 
I don't think this is true; qmail version 2 is under development. It simply
won't be visible to the public until djb feels it is alpha-quality (which is
better than most project's "release-quality" releases). Keep in mind
development may be somewhat slow; in addition to his research and teaching
duties as a professor at the University of Illinois at Chicago, the author has
also spent much of the last few years developing a BIND replacement (djbdns),
fighting the United States Department of Commerce over the restriction of
cryptography software distribution, and writing various other software.
 
Charles
--
-----------------------------------------------------------------------
Charles Cazabon <web-letters-lwn.net@discworld.dyndns.org>
-----------------------------------------------------------------------

Comments (7 posted)

Re: Movable type and "almost free" software

Sam Johnston writes:
 > <>This week's LWN (http://lwn.net/Articles/86020/) compares qmail to
 > Movable type (with reference to Six Apart's recent announcement[1] which
 > has upset users left[2], right[3] and centre[4]). It talks about there
 > being no qmail releases since June 1998,
 
Why does this LWN article ignore netqmail? One might as reasonably
criticize the PBM package because the author has not put out any new
releases. They'll say that the critical difference is in the
licensing. They're wrong. qmail has always been licensed under a
freely copyable without modification license. That is exactly what
the netqmail package is. Freely copyable without modification. The
only thing that you lose in the qmail->netqmail transition is the
ability to distribute unmodified pre-compiled binaries. Guess what?
Nobody does that anyway! Of course, there are people distributing
modified pre-compiled binaries now (can you say Plesk?); they could
easily switch to distributing netqmail instead, and be equally at
fault under the law.
 
Note that I haven't read the article because it is a proprietary
article. I find it VERY IRONIC that they criticize software that
isn't freely copyable in an article that isn't freely copyable.
 
--
--My blog is at angry-economist.russnelson.com | You know you have a
Crynwr sells support for free software | PGPok | politician that can't hurt
521 Pleasant Valley Rd. | +1 315 268 1925 voice | you when you see the hearse
Potsdam, NY 13676-3213 | FWD# 404529 via VOIP | go by.

Comments (2 posted)

LINUX Security - Buffer Overflows

 
LWN Editors:
 
The problem of buffer overflows has been around a long, long, long time . . . . . about 50 years! I have found the following steps to be very effective in detecting, defending from, and inhibiting buffer overflows:
 
1. Receiving buffers are placed in their own (virtual memory) segment (this technique unfortunately requires very detailed knowledge of the hardware platform and may not be a generally applicable technique).
2. Receiving buffers are preceded and followed by defensive buffers that are at least twice the size of the receiving buffer. These defensive buffers are filled with repeated (randomly generated and never x'00' or x'ff') identical byte contents. Those repeated identical byte contents checked by an asynchronous highest priority task for any changes, with the frequency for the check based on the speed of whatever is filling the receiving buffer. If any changes are detected in the defensive buffers, whatever is filling the receiving buffer is suspended and a very emphatic alert is generated. If the receiving buffer is filled by an process internal to the program, this check is done each time the receiving buffer is filled.
 
The size of the defensive buffers may be reduced overtime as confidence builds, but should never be eliminated. Defensive buffers will catch a lot of the programmer's logic errors!
 
The arguments against defensive buffers are a lot like the history of arguments against protective gear in sports (football, baseball, snow skiing, etc.); only after someone else is severely hurt does leadership arise that requires defensive measures. Perhaps LINUX and other operating systems have not yet hurt their users enough for users to mandate defensive measures.
 
Regards,
Troy Klein
Y2k-AT-ieee.org

Comments (4 posted)

BE May Editorial -- How Many Nines Is That, Again?

I hate to have to ruin your day, after you put all that work into it
and all...
 
But "5-nines reliability" does indeed mean 99.999, *not* 99.99999 --
it's a count of the *total* number of nines in the number.
 
And pat that IT guy on the back -- a *system-level* reliability of 99.99%
(four nines) means he has *really* done his homework; probably
including redundant network cabling to everything and dual switches.
 
And, alas, slap yourself in the face for screwing up. And I expect you
to do it in letters as large as the ones you screwed up in -- that is,
*on the editorial page*. Feel free to do the research you should have
done in the first place; if I'm wrong, you can use that space to slap
*me* around instead. But I don't think you will.
 
See the first 3 or 4 hits at http://www.google.com/search?q=five%20nines
for example, and note that 32 seconds a year is *six* nines... and
remember that each nine costs an order of magnitude modre, in
general... and remember also that system uptime is the product of the
uptimes of *every component on the critical path*.
 
Don't go dissin' IT people. Modulo our ability to get management to
spend enough to buy the gear they need for the reliability they ask
for, we'll make sure they get it. Ask a Wall Street trading firm.
 
Oh, and more and more of them have dumped Microsoft for Linux, for
precisely this reason. Windows often has a time between reinstalls
that is longer than the average Linux box's time between reboots -- and
*that* is often done solely because the operator wants to do a kernel
version upgrade; I believe the uptime record for a Linux box is
currently over 500 days.
 
Cheers,
-- jra
--
Jay R. Ashworth jra@baylink.com
Member of the Technical Staff Baylink RFC 2100
The Suncoast Freenet The Things I Think
Tampa Bay, Florida http://baylink.pitas.com +1 727 647 1274
 
        "They had engineers in my day, too." -- Perry Vance Nelson

Comments (9 posted)

Page editor: Jonathan Corbet