Topic: Binary patches for qmail

[Scott]

Let me start by saying TINALF (this is not a legal forum) for the benefit of those who will reply with IANAL. But there are some reasonable opinions here.

The qmail license prohibits the distribution of modified binaries or source. Basically, you are limited to whatever is compiled from the stock qmail sources. If you apply any source code patches, you cannot distribute the resulting binary. Nor can you combine the code patches into a new source package and distribute that. DJB does provide for distributing modified versions, but only if he personally approves them. Somehow I think that might be a difficult or improbable task given the large number of qmail patches that exist, yet few (if any) modified distributions have resulted.

So, my question: What about a binary patch? If I compile a patched version of qmail, then create binary patch files to go from a stock version to the modified version, and distribute those patches for end-user application -- is that a breach of the qmail license? I'm thinking not, as I would not be distributing a modified binary. This seems no different than supplying a source code patch and compiling the modification onto the user system. Instead of patching source, I would be patching the binary.

Opinions?

Scott

[Charlie Brady]

Scott wrote:

> So, my question: What about a binary patch? If I compile a
> patched version of qmail, then create binary patch files to
> go from a stock version to the modified version, and
> distribute those patches for end-user application -- is that
> a breach of the qmail license?

Probably.

> This seems no
> different than supplying a source code patch and compiling
> the modification onto the user system.

It is quite different, especially so if you don't also make the source code of your patch available.

Charlie

[Scott]

Charlie

Okay, if the binary patch is accompanied by the source patch that was used to create the binary from which the binary patch was derived, then the end user is in possession of the tools (except perhaps the compiler, which can be obtained easily enough) necessary to have created the modified binary themselves.

How, then, would the distribution of a binary patch and the source used to create it and applying the patch via a utility, be different from distributing only the source and then compiling it to create the modified binary? Both yield the same result -- a user-modifed binary. The difference being that one requires the presence of a compiler and the other the presence of a binary patch tool.

What has been done is to replace the requirement for a compiler -- large, lots of files, configuration issues, etc. -- to create a modified binary, with a small and simple binary patching program. (Of course, this implies that the patches are EXTREMELY platform dependent, but in an SME environment the platform, other than hardware, is fairly well known.)

Can you please explain how this is "probably" a qmail license violation, and how it is "quite different" from code patching? Probably and quite different certainly offer an opinion, but they don't provide much in terms of explanation. I would be interested to know the thinking behind your opinions.

Thanks

Scott

[Rich Lafferty]

Scott wrote:
>
> Charlie
>
> Okay, if the binary patch is accompanied by the source patch
> that was used to create the binary from which the binary
> patch was derived, then the end user is in possession of the
> tools (except perhaps the compiler, which can be obtained
> easily enough) necessary to have created the modified binary
> themselves.

That paragraph makes me think that you're thinking about the GPL, or
similar open-source licenses. Remember, qmail is free software, but
it *isn't* open-source.

Essentially, Bernstein wants to guarantee that the only way your system
can have a nonconforming qmail installation is for you to build a nonconforming qmail installation yourself.
 
From http://cr.yp.to/qmail/dist.html:

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

That said, what modification are you trying to apply? Perhaps there's an
easier way.

Cheers,

--Rich

[Scott]

Rich

No, I wasn't thinking of the GPL. I was responding to Charlie's statement.

I can fully understand Dan's desire to prevent the distribution of modified binaries. He went through a lot of trouble to write a secure, efficient system and wants to ensure it stays that way.

However, he has not precluded the distribution of modifications to qmail. Only the distribution of modified binaries. There is nothing in the qmail license to prevent you from delivering qmail compiled in its standard form, and also delivering a patch such as qmail-smtp-auth-send. If the user installs that patch -- which modifies the source and then recompiles -- there is no violation.

Distributing a patch to be applied to a binary file is not the same as distributing a modified binary. If that were the case, then the source code patch would also be a violation as it results in modified binary. Dan's exclusion is against the distribution of modified binaries, not against the means to modify binaries.

Furthermore, a binary patch file is not a qmail binary. It is essentially a diff, except a diff of binary rather than textual (source code) data. I don't believe Dan's license has any more jurisdiction over a binary patch than it does over a source code patch. Do you?

Lastly, the point is that since SME ships without a development environment (compiler) it is unnecessarily challenging to apply some of the very useful qmail patches. With a binary patch utility, of which there are several that are small and easily distributed, it would be possible to apply patches to the binaries directly rather than having to go through the "patch the source, make, install, blah" process. At worst it might be necessary to distribute the source for the patch along with the resulting binary patch.

Otherwise, SME is a very controlled environment and most of the platform-specific issues that the qmail make file has to resolve do not apply. Binary patches would be a reliable solution provided they did not affect binaries dealing with system variant issues such as hardware. Most qmail patches don't play with the hardware, so that shouldn't be an issue. And, even if the binary patch didn't work, that would be little different from the source level patch that might not work.

I don't see that this would be a problem, to distribute patches in binary form. I don't believe it violates the qmail license. It might be an unusual approach, but it would certainly be beneficial.

Scott

[Rich Lafferty]

Scott wrote:
>
> I don't believe Dan's license has any more jurisdiction over a binary patch
> than it does over a source code patch. Do you?

Doesn't matter if I do or not. Neither of us get to decide -- only Dan
Bernstein does.

> Lastly, the point is that since SME ships without a development
> environment (compiler) it is unnecessarily challenging to apply some
> of the very useful qmail patches.

Yes, it's a real inconvenience. For instance, that's why we ship
smtpfront-qmail and use that instead of qmail-smtpd, and it has certainly
got in the way of some other things I've wanted to do and distribute
myself (but I've implemented them in other ways).

> I don't see that this would be a problem, to distribute
> patches in binary form. I don't believe it violates the qmail
> license. It might be an unusual approach, but it would
> certainly be beneficial.

The only way to know is to drop a line to djb@cr.yp.to, or just do it and
hope you don't get caught doing something that Dan thinks is forbidden.
It's not a question of benefit, it's a question of what Dan decides to let
you do with his property.

--Rich

[Kelvin]

Hi Scott,

I read with interest the point you are making on this. My beef with qmail in SME is the lack of an easy means to keep a copy of all outgoing mail. In reading the qmail FAQ, it turns out that you only need to change one line in one of qmail's source files and recompile to get this functionality. I believe that this was a really useful thing to have and have long wondered why Mitel did not just include this ability in its distribution of qmail until I read this thread. Seeing as this is documented and the recommended way to achieve mail archiving (as it comes from qmail's own FAQ), I believe it's really just dumb to exclude such a function from the standard distribution (Dan I mean, not Mitel as their hands are tied - legally speaking).

I am in agreement with you that if binary patching is a way to around the problem, then it should really be considered. In my scenario, if someone could come up with a patch to add the outgoing mail copying function, it would be so much simpler to achieve. Instead, I currently need to have a compiler setup and even then, if the source compiles correctly, I have no idea where to begin to replace the new, modified executables on the production servers. I have since gone down a different path to achieve mail archiving (not perfect but functional). However, this involves adding yet more stuff to servers when the means to do it is potentially already there. Bummer.

My 2 bits.

Kelvin

[Scott]

Honestly,

If qmail is so static that one can not implement
obviousely needed and available functions like
sticking a user name with a domain as opposed
to the all domains get the user mentality of
qmail standard distro. Then why is mitel using it?

There are plaenty of other imap servers out there
with the samve functionality of qmail without
the idiocrity of the owner preventing users from
having the full functionality of the server.

Not everyone wants to be so geeky that they
can tell you how to mod a program or an
entire system. Many people just do it as
a hobby because it's a lot cheaper than
cars. So for them, simply installing patches
is the way to go. I think mitel needs to chuck
qmail if the owner of the code doesn't want
the program modified to the greatest benefit
of the user.

Scott

[Dan Brown]

Scott,

Interesting, and misguided, way of reviving a year-old thread.  Misguided, because qmail is quite capable of handling multiple user namespaces for multiple domains--that is, fred@domain1 can be a different user from fred@domain2.  The reason that e-smith/SME uses a single namespace is due to a conscious and deliberate design decision by the developers, which has been discussed here MANY times in the past.  Read the forum archives; if you don't like that decision, you're probably best with a different distro.

[Dan Brown]

Oh, and qmail doesn't have anything to do with the imapd.

[Scott]

Dan Brown wrote:
>
> Scott,
>
> Interesting, and misguided, way of reviving a year-old
> thread.  Misguided, because qmail is quite capable of
> handling multiple user namespaces for multiple domains--that
> is, fred@domain1 can be a different user from fred@domain2.
> The reason that e-smith/SME uses a single namespace is due to
> a conscious and deliberate design decision by the developers,
> which has been discussed here MANY times in the past.  Read
> the forum archives; if you don't like that decision, you're
> probably best with a different distro.

I realize that SME thinks this is a step of simplicity.
I personaly think that they are wrong. As far as going
to a different distro? And have to work with their crippled
out of the box foolishness? No thank you. Besides, this
is the only real don't like issue I have about SME.
Instead, I'm going to figure out how to set qmail up
to do what I want it to do. It may mean simply installing
the latest redhat.rpm distribution. Do you know what version
qmail is on the SME5.6u4 box?

Of course, there is this thing about having to recompile
the software that everyone is talking about. So that may
be a hinderence. An easy workaround would be to set
up a differnet distro as the email server.

So's I don't forget, thanks for the tip about imap not
being part of qmail, I was under the impression that
qmail was an imap server.

Scott