Mailing List Archive

lilo wrote:

> I can understand Dan's interest in maintaining tight control over
> modifications to his work, but this also makes use of his package less
> attractive. Effective maintenance involves feedback--the maintainer
> produces patches and provides updates to a user base (usually of varying
> technical skills) for testing, noting the results. If only one individual
> may determine whether a patched binary may be distributed, long-term
> maintenance begins to look more risky for less technical users.

My take on this is as follows.

Dan wants to control whatever patches are made to qmail because:

- it's his name on the package, and he doesn't want to be dumped on

- he doesn't want patches that will compromise aspects of qmail (such as
security) and potentially give the non-patched versions a bad name

- he wants to know what is being patched, because maybe it's a good idea
and could be useful to include for everyone else


How about this:

- precompiled versions may be freely distributed if they are unpatched

- patched versions may be freely distributed if the patches were for
portability reasons. They can not alter qmail functionality without
Dan's authorisation.

- all patches used in a distributed version must be sent to Dan,
including portability patches. This way they may be included in the
next release if appropriate.

- distributions may be repackaged (ie: Linux RPM). The archive must be
named qmail-version-distributor.archiver. For example,
qmail-1.00-redhat.rpm.

- a form-letter must be installed in /var/qmail stating that it is a
patched version and the distributor will handle all techncial support,
including the name of the distributor and at least a valid e-mail
address.

Evan

Evan Champion (evanc@synapse.net) wrote:
> - precompiled versions may be freely distributed if they are unpatched

I would prefer this be relaxed such that the conf-*.h files may be patched
freely, but nothing else, to distribute a binary version. I've been building
qmail for a while (on Linux) and never needing to patch anything apart
from these files. Possibly 95% of all requirements would be satisfied if
the conf-*.h could be freely modified (with due disclaimer of course).

> - patched versions may be freely distributed if the patches were for
> portability reasons. They can not alter qmail functionality without
> Dan's authorisation.

Portability patches should go back to Dan for inclusion in patches. I
assume 1.01 etc will simply be portability patches as new people start
to use qmail 1.0 on systems that haven't used it before. I assume there
won't be any bugs, right Dan ;-)

> - a form-letter must be installed in /var/qmail stating that it is a
> patched version and the distributor will handle all techncial support,
> including the name of the distributor and at least a valid e-mail
> address.

That's fair enough. Although I can still remember the wu-ftpd "bug" with
the SITE EXEC command simply being a config error. However people know it
as a wu-ftpd bug.

Actually a fair amount of the "problems" people perceive might happen
depends on Dans reaction to being asked if qmail can be distributed. He
may be very easy going with respect to what he allows, the restriction may
be in place simply to keep him in the loop about changes. And not to stop
patches which we seem to think will happen. If you are a package maker it
can't hurt to simply ask Dan if you can do xyz to qmail.

Cheers.
-- +------------------------------------------------------------+
. | John Saunders - mailto:john@nlc.net.au (EMail) |
,--_|\ | - http://www.nlc.net.au/ (WWW) |
/ Oz \ | - 018-223-814 or 02-9477-2881 (Phone) |
\_,--\_/ | NHJ NORTHLINK COMMUNICATIONS - Supplying a professional, |
v | and above all friendly, internet connection service. |
+------------------------------------------------------------+

lilo writes:
> I can understand Dan's interest in maintaining tight control over
> modifications to his work, but this also makes use of his package less
> attractive.

Less attractive to who, though, and why? While it does make
distribution of qmail more difficult to people who wish to modify it,
it makes the use of qmail more *reliable* to whose who merely wish to
use it. As a practical matter, to the ordinary user, replacing
sendmail with qmail is the best thing they can do for the security of
their system.

And I'd like to reiterate that trademarks are how reputations are
protected, not copyrights. Copyrights eventually expire. Trademarks,
are long as they are defended, never expire. Copyrights do not
protect against modification -- only distribution. Trademarks are
subject to any kind of license restriction. Dan has no way to
restrict the distribution of automagically-modified versions of qmail.
Someone could make an RPM which would extract qmail-1.00.tar.gz, patch
the hell out of it, compile it, and install it as "Dan Bernstein's
qmail", which of course it would no longer be. Since ``qmail'' is not
trademarkable, he has no way to prevent this. A trademark could allow
Dan to insist that it only be used to describe a qmail that has been
compiled without modification.

--
-russ <nelson@crynwr.com> http://www.crynwr.com/~nelson
Crynwr Software sells network driver support | PGP ok
521 Pleasant Valley Rd. | +1 315 268 1925 voice | Peace, Justice, Freedom:
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | pick two (only mostly true)

> Someone could make an RPM which would extract qmail-1.00.tar.gz, patch
> the hell out of it, compile it, and install it as "Dan Bernstein's
> qmail", which of course it would no longer be.

This has nothing to do with qmail or with trademarks. Someone could
distribute patches for sendmail that relabel it as ``Dan Bernstein's
mailer---yell at djb@pobox.com when your system is broken into.''

It's up to the user to evaluate information he receives. Caveat lector.

Fortunately for users, most information is carefully labelled. For
example, each document has a clearly identified author, name, and
version number. Yes, this takes a bit of work for the author, but it
makes life much simpler for everyone else.

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

D. J. Bernstein writes:
> > Someone could make an RPM which would extract qmail-1.00.tar.gz, patch
> > the hell out of it, compile it, and install it as "Dan Bernstein's
> > qmail", which of course it would no longer be.
>
> This has nothing to do with qmail or with trademarks. Someone could
> distribute patches for sendmail that relabel it as ``Dan Bernstein's
> mailer---yell at djb@pobox.com when your system is broken into.''

And obviously you would tell them to go to hell. But what if they
asked you about security problems with a ``qmail'' installation? How
do verify that the qmail has been unmodified? Without a trademark,
you have to check on a case-by-case basis.

> It's up to the user to evaluate information he receives. Caveat lector.

That's the WHOLE POINT behind trademarks. They reduce the transaction
cost of evaluating a product. Instead of evaluating the product every
time, you evaluate the brand once. If the brand is to serve its
purpose, the manufacturer will ensure that the characteristics of the
product do not change.

You're deliberately subverting this system, for reasons I cannot
understand. You have established that you don't care if people call
any damn thing they want ``qmail'', and yet you put a tiny bump in
their way -- that they must distribute the source unmodified. So
fucking what?!? If the whole point is to ensure consistency of
product then you should use effective means.

I don't think you've thought this through, Dan.

--
-russ <nelson@crynwr.com> http://www.crynwr.com/~nelson
Crynwr Software sells network driver support | PGP ok
521 Pleasant Valley Rd. | +1 315 268 1925 voice | Peace, Justice, Freedom:
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | pick two (only mostly true)

From: Russell Nelson <nelson@crynwr.com>
> Less attractive to who, though, and why?

Well, it won't be a part of Debian because it isn't free software.
I am really disappointed, because I was _led_to_think_ it would be
free software, and thus I have been lobbying people to use it for
at least a year now.

Bruce Perens
--
Bruce Perens K6BP Bruce@Pixar.com 510-215-3502
Finger bruce@master.Debian.org for PGP public key.
PGP fingerprint = 88 6A 15 D0 65 D4 A3 A6 1F 89 6A 76 95 24 87 B3

> If the whole point is to ensure consistency of
> product then you should use effective means.

Someone tells me that qmail-send doesn't schedule messages properly with
Sun's compiler. It turns out to be a compiler bug.

Someone tells me that qmail-send dies on Linux under high loads. It
turns out to be a kernel bug.

Someone tells me that qmail-send repeats bounce messages. It turns out
that qmail-start was run with SIGCHLD ignored.

See, I only built _part_ of the user's system. How am I supposed to
ensure ``consistency''?

> You have established that you don't care if people call
> any damn thing they want ``qmail'',

Of course I care. Someone who changes qmail has no right to distribute
the modified version without my permission.

---Dan
Let your users manage their own mailing lists. http://pobox.com/~djb/qmail.html

On 25 Feb 1997, Russell Nelson wrote:

> You're deliberately subverting this system, for reasons I cannot
> understand. You have established that you don't care if people call
> any damn thing they want ``qmail'', and yet you put a tiny bump in
> their way -- that they must distribute the source unmodified. So
> fucking what?!? If the whole point is to ensure consistency of
> product then you should use effective means.
>

As a potential adopter of qmail for our local mail setup, I
am more concerned with the tone of the "licensing" debate
than the "tiny bump" that Dan Bernstein put in the way of
distribution over the net. You, the early Qmail adopters,
come off looking quarrelsome and not very helpful by the
light of the on-going debate.

The main reason to package any software (RPM or whatever)
is that many software distributions are tricky to compile
because they attempt to predict all the compiler options
available on a given system (I gave up on Smail3 for that
reason). This is not the case with Qmail. It compiled on my
HP-UX 9.07 system with a tiny modification to c-conf.sh
(modify -O2 to -O). I didn't need a guru to pre-compile and
configure it for me. The installation instructions are
concise and lucid. Qmail represents a new way of building
a MTA and should be approached with a certain amount of
care. In fact, I would be worried about dropping a
brand-new package on my machine in binary form without a
chance to poke around it first.

A better way to spend all that energy is to help people
adopt Qmail within the parameters set by the author. Build
the FAQ, publish sample set-ups, share success stories,
place links to Qmail.org in your home page, whatever it
takes...

Regards
--Louis

Louis Bertrand, Senior Engineer Motorola Canada LMPS
Toronto Design Centre 3900 Victoria Park Avenue
SMTP: louisb@comm.mot.com North York, Ontario
X.400: Y10290 Canada, M2H 3H7
Mailstop: ONT1 +1.416.756.5855

> care. In fact, I would be worried about dropping a
> brand-new package on my machine in binary form without a
> chance to poke around it first.

Indeed, I think I finally achieved a certain zen acceptance of the
qmail distribution -- at least on systems I install, I'm just going to
think of the entire qmail source tree as a set of config files, that I
use "make" instead of just "killall -HUP" to get the system to
recognize...

D. J. Bernstein writes:
> > If the whole point is to ensure consistency of
> > product then you should use effective means.
>
> See, I only built _part_ of the user's system. How am I supposed to
> ensure ``consistency''?

Everything is relative. Just because you can't be perfect is no
reason to fail to try to be perfect.

> > You have established that you don't care if people call
> > any damn thing they want ``qmail'',
>
> Of course I care. Someone who changes qmail has no right to distribute
> the modified version without my permission.

Let's say that someone wants to do just that. You've already given
them permission to distribute qmail in source form -- you can't take
that away. The only impediment to modifying qmail is the need to
compile it. But EVERYONE has to compile qmail, so that modifications
are essentially free. As the current situation stands, the only way
you can discourage modifications to qmail is to freely grant people
permission to distribute binaries. The more control you try to
exercise over the binaries, the more people are encouraged to modify
the source. The less control you exercise over the binaries, well,
the less control you have.

Either way, you lose. The only way you can keep modified copies of
qmail from being used is to discourage the use of qmail (which you are
already doing with your restrictions on qmail distribution).

Sendmail *is* insecure, and it's *definitely* running on at least
65,000 hosts. qmail *might* be modified in ways that *might* make it
insecure. You seem willing to trade away a small potential for risk
for a large known risk. This seems like a bad tradeoff to me.

There are other ways to reduce the potential for risk that you fear,
and also reduce the known large risk of sendmail. Make qmail
completely freely copyable, and establish a trademark. Make the rules
for the trademark use be (among other possible rules) that it can only
be applied to a qmail which has been compiled unmodified.

The only good /usr/lib/sendmail is one with --------- permissions.

--
-russ <nelson@crynwr.com> http://www.crynwr.com/~nelson
Crynwr Software sells network driver support | PGP ok
521 Pleasant Valley Rd. | +1 315 268 1925 voice | Peace, Justice, Freedom:
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | pick two (only mostly true)

Louis Bertrand writes:
> On 25 Feb 1997, Russell Nelson wrote:
>
> > You're deliberately subverting this system, for reasons I cannot
> > understand. You have established that you don't care if people call
> > any damn thing they want ``qmail'', and yet you put a tiny bump in
> > their way -- that they must distribute the source unmodified. So
> > fucking what?!? If the whole point is to ensure consistency of
> > product then you should use effective means.
> >
>
> As a potential adopter of qmail for our local mail setup, I
> am more concerned with the tone of the "licensing" debate
> than the "tiny bump" that Dan Bernstein put in the way of
> distribution over the net. You, the early Qmail adopters,
> come off looking quarrelsome and not very helpful by the
> light of the on-going debate.

The problem is that Dan's chosen solution is unbalanced. It seeks to
eliminate ANY risk that ANY vendor will EVER modify qmail ANY way that
Dan does not approve. While this goes on, people are running
sendmail, which is a gaping security hole, the size of a truck, on
nearly every system it's running on!

--
-russ <nelson@crynwr.com> http://www.crynwr.com/~nelson
Crynwr Software sells network driver support | PGP ok
521 Pleasant Valley Rd. | +1 315 268 1925 voice | Peace, Justice, Freedom:
Potsdam, NY 13676-3213 | +1 315 268 9201 FAX | pick two (only mostly true)

> As a potential adopter of qmail for our local mail setup, I
> am more concerned with the tone of the "licensing" debate
> than the "tiny bump" that Dan Bernstein put in the way of
> distribution over the net. You, the early Qmail adopters,
> come off looking quarrelsome and not very helpful by the
> light of the on-going debate.

That has been the case for as long as I know this list. Every
discussion, at least on anything involving design choices by Dan,
escalates into a flame war even more quickly than the average
news.groups RFD. I have absolutely no idea why.

> A better way to spend all that energy is to help people
> adopt Qmail within the parameters set by the author. Build
> the FAQ, publish sample set-ups, share success stories,
> place links to Qmail.org in your home page, whatever it

A repository of sample set-ups, like the one in the smail sources,
would be a nice idea.

olaf

Well, it won't be a part of Debian because it isn't free software.
I am really disappointed, because I was _led_to_think_ it would be
free software, and thus I have been lobbying people to use it for
at least a year now.

Bruce Perens

Could using either of the GNU licenses really hurt the reputation of
qmail? Has anything bad happened to Emacs, gcc, Linux kernel, etc,
which would suggest to stay away from GPL?

For an outsider, the sentences

If you want to distribute modified versions of qmail (e.g.,
different packaging formats, porting changes, precompiled
binaries) you'll have to get my approval. Note that this means
approval of the version, not approval of your distribution
method.

sound as inviting as

"Here is my great receipe for hamburger. Cook some for
yourself, and let me know what you think. But beware: while you can
give the receipe to anybody in your family, they have to cook their
own burger. In case you think this is not possible (your 2 year old
cannot cook) then you can do this: invite me over, let me taste each
burger you cooked, and if I like them you can give them to your family.
Note that this means you need to invite me over every time you cook
burger from my receipe for your family."

Will this receipe enjoy widespread use?

Is the qmail license in its present form really useful? Does it
effectively prevent a soul with some free time to mix the main
ingredients of qmail into, say, Cuemail and put the result under GPL?


Mate Wierdl

On Tue, 25 Feb 1997, Mate Wierdl wrote:

> "Here is my great receipe for hamburger. Cook some for
> yourself, and let me know what you think. But beware: while you can
> give the receipe to anybody in your family, they have to cook their
> own burger. In case you think this is not possible (your 2 year old
> cannot cook) then you can do this: invite me over, let me taste each
> burger you cooked, and if I like them you can give them to your family.
> Note that this means you need to invite me over every time you cook
> burger from my receipe for your family."
>
> Will this receipe enjoy widespread use?

Last I checked, a recipe cannot be copyrighted. Only it's presentation
(as in a cookbook, etc.) is copyrightable. Or are you really just trying
for a dinner invite?? :)

Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null
Database Manager Michigan Area Repeater Council
# include <std/disclaimers.h> TEAM-OS2
Online Searchable Campground Directory http://www.camping-usa.com
==========================================================================

At 06:31 AM 2/26/97 -0500, you wrote:
>On Tue, 25 Feb 1997, Mate Wierdl wrote:
>> "Here is my great receipe for hamburger. Cook some for
>> yourself, and let me know what you think. But beware: while you can
>> give the receipe to anybody in your family, they have to cook their
>> own burger. In case you think this is not possible (your 2 year old
>> cannot cook) then you can do this: invite me over, let me taste each
>> burger you cooked, and if I like them you can give them to your family.
>> Note that this means you need to invite me over every time you cook
>> burger from my receipe for your family."
>>
>> Will this receipe enjoy widespread use?
>
>Last I checked, a recipe cannot be copyrighted. Only it's presentation
>(as in a cookbook, etc.) is copyrightable. Or are you really just trying
>for a dinner invite?? :)

If he was actively searching for a dinner invite, dontcha think he would
have suggested shrimp or lobster?!?! ;^)

BTW, anyone need a lobster recipe??? ;) ;)

Roger "Merch" Merchberger
{{{ Have you had your "Cheeseburger in Paradise" yet? I have! }}}
--apologies to Jimmy Buffett.

> > As a potential adopter of qmail for our local mail setup, I
> > am more concerned with the tone of the "licensing" debate
> > than the "tiny bump" that Dan Bernstein put in the way of
> > distribution over the net. You, the early Qmail adopters,
> > come off looking quarrelsome and not very helpful by the
> > light of the on-going debate.
>
> That has been the case for as long as I know this list. Every
> discussion, at least on anything involving design choices by Dan,
> escalates into a flame war even more quickly than the average
> news.groups RFD. I have absolutely no idea why.

We need two mailing lists: one for announcements, technical questions and
answers. One for "discussion" about Dan's decisions etc. Guess which one I'd
subscribe to.

Bruce Perens writes:
> Well, it won't be a part of Debian because it isn't free software.
> I am really disappointed, because I was _led_to_think_ it would be
> free software, and thus I have been lobbying people to use it for
> at least a year now.

I'm not sure that qmail is not free.

If Mark hasn't created a qmail_1.0_1.deb by the end of the already,
I'd do it with a line that says:

Depends: gcc, make

(tar and gzip are part of the base, after all...).

Note that this also solves the problem of variant qmail uids on
different systems. And, of course, this will install a lot faster
than some of the already existing free debian packages.

--
Raul

Mark Eichen:
> Indeed, I think I finally achieved a certain zen acceptance of the
> qmail distribution -- at least on systems I install, I'm just going
> to think of the entire qmail source tree as a set of config files,
> that I use "make" instead of just "killall -HUP" to get the system
> to recognize...

I don't know if I'd treat the bulk of the unpacked qmail distribution
as configuration files -- I'd just treat conf* that way. Most of it
I'd treat as library files.

--
Raul

Olaf Titz:
> That has been the case for as long as I know this list. Every
> discussion, at least on anything involving design choices by Dan,
> escalates into a flame war even more quickly than the average
> news.groups RFD. I have absolutely no idea why.

I have an idea about why.

Basically, Dan values concise, exact expression. However, often
people interpret shortness of speech as anger, (instead of, for
example, high energy).

[.Aside: I've seen writeups of speech-augmentation equipment for the
handicapped, and one of the biggest issues to deal with is how to
negotiate through the socially mandated preludes and sequels to
conversation. I think of this as an example of where the precise
expression of an idea interferes with cultural expectations of how
ideas should be expressed.]

Also, there's the configuration management issue (many people tend to
react negatively to change -- as if they've been threatened).

--
Raul

Russell Nelson:
> And I'd like to reiterate that trademarks are how reputations are
> protected, not copyrights. Copyrights eventually expire. Trademarks,
> are long as they are defended, never expire.

But there's a logistical problem: Trademarks require active legal
action to maintain their validity. To support a trademark, qmail
would have to be sold for a significant profit.

Personally, I'm happier with the current economics and culture for
qmail than I am with what I expect would have to happen to maintain a
trademark.

--
Raul