David Nicol wrote: > This looks to me like, although he has PD'd the package, he intends to > retain the restrictions on > the qmail brand. If he's made it PD, he cannot impose any restrictions. The "please" recognizes that fact, and simply expresses a wish that people playing with qmail don't break other people's work.
On Nov 30, 2007, at 8:58 AM, Les Mikesell wrote: > Is the license change on qmail likely to change the direction of > qpsmtpd? (Now you can fix it instead of replacing parts...). This means that (net-)qmail can get bundled up as regular components / options in the various distributions and we can figure out how to make our RPMs, .debs, etc play nice with the "standard components". It's awesome. - ask -- -- http://develooper.com/ - http://askask.com/
On Nov 30, 2007, at 12:03 PM, Guy Hulbert wrote:
>> Uh - the very first version of qpsmtpd was almost a line by line port
>> of qmail-smtpd.
>
> That is interesting.
>
> If it were PD, would you have tried to build an XS interface instead ?
>
> Does that even make sense ?
What benefit do you imagine it'd have? Which part of "core qmail-
smtpd" is slow in qpsmtpd-{fork,select}server? Did you look at the
qmail-smtpd code?
- ask
--
--
http://develooper.com/ - http://askask.com/
On Nov 30, 2007 7:46 PM, Chris Lewis <clewis <at> nortel.com> wrote: > David Nicol wrote: > > > This looks to me like, although he has PD'd the package, he intends to > > retain the restrictions on the qmail brand. > > If he's made it PD, he cannot impose any restrictions. The "please" > recognizes that fact, and simply expresses a wish that people playing > with qmail don't break other people's work. > as I understand it, the name 'qmail' is a separate property from the source code released under the name. He released the software, not the name. (unless he released the name, too, somewhere else.) If one were to, for instance, package up a MTA created by modifying a stock qmail by ripping out qmail-smtpd and putting qpsmtpd in its place, and call that "qmail," or even "qmail 1.03," would that be acceptable? Clearly it is acceptable to distribute such a bundle now; I'm just talking about what to call it.
Guy Hulbert wrote: > On Fri, 2007-11-30 at 13:18 -0500, Matt Sergeant wrote: >> On 30-Nov-07, at 11:58 AM, Les Mikesell wrote: >> >>> Is the license change on qmail likely to change the direction of >>> qpsmtpd? >> Doubtful. Qpsmtpd wasn't written because of a dislike of the license. And there are quite a lot of us that don't run qmail at all. Personally I use qpsmtpd as it provides a powerful, central location to configure access, anti-spam and anti-virus controls. My backend is Postfix though and I don't use qmail anywhere. Regards James Turnbull -- James Turnbull <james <at> lovedthanlost.net> --- Author of Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) Hardening Linux (http://www.amazon.com/gp/product/1590594444/) --- PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40)(Continue reading)
On Fri, 2007-11-30 at 18:02 -0800, Ask Bjørn Hansen wrote:
> On Nov 30, 2007, at 12:03 PM, Guy Hulbert wrote:
>
> >> Uh - the very first version of qpsmtpd was almost a line by line port
> >> of qmail-smtpd.
> >
> > That is interesting.
> >
> > If it were PD, would you have tried to build an XS interface instead ?
> >
> > Does that even make sense ?
>
>
> What benefit do you imagine it'd have? Which part of "core qmail-
> smtpd" is slow in qpsmtpd-{fork,select}server? Did you look at the
> qmail-smtpd code?
No but you did. That's why I'm asking. My "would" above is
subjunctive.
What I'm asking, is *if* the license had already been changed, *would*
you have implemented qpsmtpd via XS rather than rewriting qmail-smtpd
entirely.
Some people have previously proposed, on the list, rewriting all of
qmail in perl. I am asking if you think that makes sense, based on your
experience rewriting qmail-smtpd.
>
>
(Continue reading)
On Fri, 2007-11-30 at 23:25 -0600, David Nicol wrote: > as I understand it, the name 'qmail' is a separate property from the > source code released under the name. Nope. Copyright is automatic but trademarks are not. Trademarks must be agressively protected ... and for some purposes registered. I don't think DJB has ever claimed a trademark on qmail. > > He released the software, not the name. (unless he released the name, > too, > somewhere else.) -- -- --gh
On Sat, 1 Dec 2007, Guy Hulbert wrote: > On Fri, 2007-11-30 at 23:25 -0600, David Nicol wrote: >> as I understand it, the name 'qmail' is a separate property from the >> source code released under the name. > > Nope. Copyright is automatic but trademarks are not. > > Trademarks must be agressively protected ... and for some purposes > registered. I don't think DJB has ever claimed a trademark on qmail. qmail has never been used "in trade" by djb. Ergo, not trademark protected.
On Fri, 30 Nov 2007, Les Mikesell wrote: > Who knows, but I'd certainly hope that someone would fix the stock smptd to > not back-scatter bounce messages to the generally-forged senders of messages > to recipients that don't exist. There's no need. Just delete qmail-smtpd. It's obsolete.
Guy Hulbert wrote:
>>> If it were PD, would you have tried to build an XS interface instead ?
>>>
>>> Does that even make sense ?
>>
>> What benefit do you imagine it'd have? Which part of "core qmail-
>> smtpd" is slow in qpsmtpd-{fork,select}server? Did you look at the
>> qmail-smtpd code?
>
> No but you did. That's why I'm asking. My "would" above is
> subjunctive.
>
> What I'm asking, is *if* the license had already been changed, *would*
> you have implemented qpsmtpd via XS rather than rewriting qmail-smtpd
> entirely.
I don't think there would be a big win from this. If you run perl at
all the problem is in the memory footprint and the difficulty in keeping
shared pages across forked processes. It might be a win, though, to run
the stock front end for some operations, letting it chat with a perl
process for certain steps. The down side is that multiplexing step-wise
operations to a small number of backend processes means that variables
don't hold values for the entire delivery process.
--
--
Les Mikesell
lesmikesell <at> gmail.com
(Continue reading)
RSS Feed3 | |
|---|---|
9 | |
1 | |
4 | |
21 | |
5 | |
3 | |
69 | |
199 | |
58 | |
3 | |
1 | |
6 | |
14 | |
19 | |
5 | |
16 | |
26 | |
5 | |
34 | |
27 | |
6 | |
13 | |
30 | |
5 | |
72 | |
9 | |
97 | |
25 | |
21 | |
30 | |
28 | |
14 | |
75 | |
46 | |
19 | |
25 | |
81 | |
59 | |
123 | |
73 | |
42 | |
97 | |
117 | |
55 | |
18 | |
36 | |
59 | |
22 | |
52 | |
38 | |
127 | |
75 | |
65 | |
94 | |
78 | |
116 | |
41 | |
78 | |
158 | |
275 | |
61 | |
142 | |
126 | |
86 | |
63 | |
208 | |
324 | |
78 | |
131 | |
157 | |
123 | |
80 | |
89 | |
123 | |
105 | |
181 | |
174 | |
233 | |
371 | |
85 | |
198 | |
76 | |
50 | |
88 | |
316 | |
133 | |
187 | |
162 | |
200 | |
168 | |
37 | |
66 | |
151 | |
84 | |
273 | |
121 | |
139 |
