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

From: "Gordon Fecyk" <[email-masked]>
Date: Mon, 23 Aug 2004 21:35:25 -0500

Is the only thing Microsoft asking for in any source code release is an IPR
disclosure?  And indemnification?

I'm reading Section 2.2 of said license and I get the impression nothing
would stop me from writing a library based on this and release it under the
GPL, because 2.2 says I can release source if I also include that other text.

Have I misinterpreted that?

-- 
PGP key (0x0AFA039E): <http://www.pan-am.ca/[email-masked]>
Sometimes it's hard to tell where the game ends and where reality bites,
er, begins. <http://vmyths.com/resource.cfm?id=50&page=1>

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 26 Aug 2004 09:47:46 -0700

> 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.

If QMail was actively maintained the license issues would be
exactly the same as for any other mailer. The problems come
from the fact that the mailer is abandonware and the license
prohibits any other party taking it on.

I would not waste my time maintaining QMail, I would replace 
it wholesale or use one of the many other fine mail systems
out there. 

		Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 26 Aug 2004 09:47:46 -0700

Phill

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 26 Aug 2004 11:05:24 -0700

> This is incorrect. Qmail *is* being maintained, just not by DJB. 

And DJB refuses to allow Qmail to be updated. Therefore I stick
by my original claim.

> > Making a call out to a sharred library is no different in principle
> > 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.  

Do the dlopen in the initialization loop and pass it to the child process
along with the socket.

If the O/S supports transfer of sockets then this is almost certain to work.

Calling a handle returned by a dynamic link library is not going to be any
slower than a normal handle call.

This can be made to work if anyone cares to want to make it work.

---

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. 

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: "Ryan Malayter" <[email-masked]>
Date: Thu, 26 Aug 2004 17:51:13 -0500

[Mark Shewmaker]
>In the section you quoted, they grant End Users a "use" right without
>any mention of a right to "make" object code.

Huh?

How do you use a source code implementation, except as to run it in
interpreted fashion or build it?

I think you're reaching. The separation of source code versus object
code sections in the license seems to be made so that one form (source)
requires a statement of IP ownership be attached, while the other
(object) does not.

Microsoft's license FAQ says basically the same thing: only when you
implement their IP do you need a license, not to use a licensed
implementation. 

I have a tentative agreement for an *independent* (niether MS nor FSF)
IP lawyer friend confirm these issues for me on a pro-bono basis. I will
let everyone know what he says, or if he tells me I'm going to have to
pay up because analyzing these four pages (the MS license in combination
with the GPL) turns out to be too much work to do for free ;-).

Regards,
	Ryan