Subject: RE: DEPLOY: Microsoft Royalty Free Sender ID Patent License FAQ

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 26 Aug 2004 07:49:42 -0700

> > Or an alternative MTA :-)
> 
> I'm not sure that is really a joking matter.  We aren't supposed to
> talk about "hidden agendas", but since you raised the issue, I'll ask
> directly:
> 
> Is your goal in supporting the SenderID license to get people to use
> "an alternative MTA", say the one that Harry and Jim work on?

QMail is not being maintained. The license terms make it impossible
for it to be maintained. There are better mailers out there with
true open source licenses. These do not create issues in the 
standards development area.

I would advise anyone using QMail to move to a supported product.
Whether that support is commercial or voluntary does not matter to
me, I don't sell mail servers.

I don't think that a standards group should be constrained by the
license terms of an unsupported product that has not been maintained
for years and is unlikely to be maintained in the future.

> > If I had to patch Qmail the way I would do it is as follows:
> >
> > [ideas snipped]
> 
> Your scheme does not match the design of qmail.  What you are
> suggesting is a major rewrite of the qmail MTA.

Actually not, it is many years since I looked at QMail, but this is 
the type of modification I used to do in a day or so. 

Making a call out to a sharred library is no different in principle
than making a call out to an object library. 

Take a look at the following:

http://users.actcom.co.il/~choo/lupg/tutorials/libraries/unix-c-libraries.ht
ml#shared_dlsym

#include <dlfcn.h>      /* defines dlopen(), etc.       */
.
.
void* lib_handle;       /* handle of the opened library */

lib_handle = dlopen("/full/path/to/library", RTLD_LAZY);
if (!lib_handle) {
    fprintf(stderr, "Error during dlopen(): %s\n", dlerror());
    exit(1);
}

/* first define a function pointer variable to hold the function's address
*/
struct local_file* (*readfile)(const char* file_path);
/* then define a pointer to a possible error string */
const char* error_msg;
/* finally, define a pointer to the returned file */
struct local_file* a_file;

/* now locate the 'readfile' function in the library */
readfile = dlsym(lib_handle, "readfile");

/* check that no error occured */
error_msg = dlerror();
if (error_msg) {
    fprintf(stderr, "Error locating 'readfile' - %s\n", error_msg);
    exit(1);
}

/* finally, call the function, with a given file path */
a_file = (*readfile)("hello.txt");

dlclose(lib_handle); 

		Phill

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 26 Aug 2004 17:27:49 +0200

Granted, qmail isn't maintained. (And if you want to comment negatively 
on its quality, I shall offer not one word of disagreement.)

But isn't that all beside the point? Surely exactly the same 
IP/licensing problems would still apply if djb were to release a new 
version tomorrow.

Arnt

---

From: Rand Wacker <[email-masked]>
Date: Thu, 26 Aug 2004 09:17:52 -0700 (PDT)

Hmm, IANAL, and believe it or not this has nothing to do with who I work
with/for, but from what I've learend about Open Source licensing in the
past few weeks it would seem to me that the qmail license itself is
incompatible with the definition of open source (specifically that it
prohibits re-distribution and sub-licensability).

djb's choice of licensing terms is djb's choice, and this group probably
shouldn't get too hung up on the requirements of a software package that
prohibits *any* modifications to its base code.

-Rand

---

From: wayne <[email-masked]>
Date: Thu, 26 Aug 2004 12:26:05 -0500

In <[email-masked]> "Hallam-Baker, Phillip" <[email-masked]> writes:

> for it to be maintained.

This is incorrect. Qmail *is* being maintained, just not by DJB.  As I
mentioned in my first post[1] about possible qmail conflicts with the
SenderID license, the qmail community has to use patches to maintain
the program.  This makes life hard, but apparently, enough people like
it that qmail is still one of the most popular MTAs (possibly the second
most popular after sendmail).

> for years and is unlikely to be maintained in the future.

You are right, we should not be constrained by licensing terms of
packages.  We should, however be constrained by deployment issues.
The possibility that requiring every single user of qmail to get a
signed license from Microsoft is a reason for concern.  (Yes, this is
orders of magnitude more work than the patches that qmail users have
to do.)

> than making a call out to an object library. 

I think you should look at the qmail source again.  It makes a several
fork/exec's on each SMTP transaction.  Despite the fork/execs, qmail
is still very fast because it doesn't do any expensive operations such
as your suggested dlopen.  

While in principle, what you have suggested might work, in practice,
what you have suggested is a non-starter.

In <[email-masked]> Rand Wacker <[email-masked]> writes:

> [...], but from what I've learend about Open Source licensing in the
> incompatible with the definition of open source [...]

Yes, you are correct, and I said as much in my first post[1] on the
subject of qmail.

I do not like qmail because of this and for all the reasons that PHB
also complained about.  However, Arnt is right, this is besides the
point.  My concern is not whether the SenderID license causes problems
with any specific program, open source, proprietary, or otherwise, but
whether the SenderID license causes problems with any major MTA and/or
spam filter.

-wayne

[1] http://www.imc.org/ietf-mxcomp/mail-archive/msg03638.html

---

From: Rand Wacker <[email-masked]>
Date: Thu, 26 Aug 2004 09:17:52 -0700 (PDT)

-Rand

---

From: Rand Wacker <[email-masked]>
Date: Thu, 26 Aug 2004 12:49:41 -0700 (PDT)

> most popular after sendmail).

So in spite of its burdensome and open source incompatible license, qmail
has *still* managed to see wide deployment.  (Some would say that qmail's
license is /wildly/ more restrictive than Sender ID's).

> orders of magnitude more work than the patches that qmail users have

The license requires no such thing from end-users of qmail that are
applying patches.

> packages.  We should, however be constrained by deployment issues.

You are exactly right.  So what's the issue? ;)

-Rand

---

From: Jeff Macdonald <[email-masked]>
Date: Thu, 26 Aug 2004 16:25:22 -0400

> license is /wildly/ more restrictive than Sender ID's).

Qmail is one of several MTAs that one can choose. If there is only one
way to determine a PRA and that way requires a license then that leaves
no freedom to choose. I know of no binary based Distributions that
distribute Qmail. But those distributions have other choices to choose
from. It seems to me that this license would exclude Open Software based
distributions.