On Wed, 30 Dec 1998, Sam wrote:
> On Wed, 30 Dec 1998, Dave Sill wrote:
> > Brister has to deal with whatever gunk is in the RPM because he's
> > going to get questions about it.
>
> If that's true, Brister would've never had the time to write inn 2.0,
While I agree with Sam here (frankly, people will complain about problems
to their vendor, not to the author, whom they might not even know about),
I have to speak up on this point. James Brister was responsible for the
packaged release of INN 2.0, but the majority of the coding was done by
others. The ISC only oversees releases now; the majority of the INN
developers now aren't even remotely associated with the ISC.
> As time goes by, you may see some other vendors make some inquiries as
> well. However, the end result will always be the same.
Exactly. Actually, the licensing might be acceptable to a commercial OS
vendor who doesn't want people on-staff who deal with software patches
directly. But any vendor who wants to be responsive to their customers
will either have to choose:
a) develop their own MTA, or contract with someone who does it for them
and gives them responsiveness guarantees through the contract
b) go with an Open Source(tm) MTA, which gives them the ability to ensure
that they can respond to security problems with their own distributions
without being locked into the schedule of an external developer.
Just like everyone here assumes the worst of Red Hat (that they will
introduce problems to QMail), Red Hat must assume the worst of DJB (in
that he might not be available when a security issue arises, and hence,
even with the availability of third-party (or their own) patches, their
hands are tied).
But, I've said many times: it's DJB's software, and his to choose how to
license. I migrated a long time ago to QMail, and while it's technically
an excellent product, the licensing disagrees with me. Hence, I've
switched to another product (postfix) to replace it, because the license
sits better with me (with a built-in understanding that the author won't
be around to maintain it forever), and still (in my mind) achieves the
level of technical excellence that QMail reaches.
It's not as mature as QMail, but in my mind it has more hope of gaining
widespread acceptance than QMail. And with open source projects, more eyes
are always a good thing.
(For anyone who thinks my decision was because of the author: nope,
personality issues never even came into it. With the bickering I've seen
between DJB and Weitse, I wouldn't run EITHER product if personality meant
anything to me. ;-)
--
Edward S. Marshall <[EMAIL PROTECTED]> [ What goes up, must come down. ]
http://www.logic.net/~emarshal/ [ Ask any system administrator. ]
Linux labyrinth 2.2.0-pre1 #1 Tue Dec 29 16:35:16 CST 1998 i586 unknown
8:25pm up 1 day, 2:17, 4 users, load average: 0.00, 0.00, 0.00
