On Fri, Jan 07, 2005 at 04:29:20PM -0700, Aly Dharshi wrote: > The more and more that I think about it I feel that it should be put in a repo ......... Addressing the general idea of putting any software which uses DJB's license into a Linux distro: No. And - No no. DJB's License is not an Open Source license, nor is it GPL nor is it FOSS. Quoting Rick Moen on the subject: from: http://www.linuxmafia.com/~rick/faq/index.php?page=warez#djb ################################################################################### Prof. Bernstein's software is, first of all, pervaded by a bloody-minded disregard for the rest of the world, e.g., qmail's trait (in earlier versions) of attempting to cram as much SMTP mail as possible down recipient systems' throats, which was notorious for crashing destination mail systems (and thus pioneered the art of mail delivery as a Denial of Service attack), and his publicfile and anonftpd ftp servers' demented EPLF text output. Second, it is characterised by bizarrely wrong design, e.g., qmail's insistence that binary packages must install all files including libraries, binaries, and configuration files within /var/qmail, and the default alias database being scattered among myriad tiny text files inside /var/qmail/aliases, all with names starting with the string ".qmail-". (Nope, DJB-acolytes, I do know all about fastforward. As usual, you are missing the point, that one must hunt down and add this as a modification and add-on to qmail proper.) This gaggle of tiny files and their naming convention, alone, will drive any sysadmin to drink, in short order. Now, it might be argued that lots of small alias files are somehow more efficient than /etc/aliases, but why should all their names start with ".qmail-"? But the clincher is his licensing. You will find that Bernstein software typically contains a copyright statement but no licence text whatsoever. Bernstein cannot possibly be unaware that this creates problems for free / open-source software users, preventing them from determining by inspection the nature of their right to use, modify, and redistribute the code, as is generally the case. Fortunately, those rights can be determined from statutory and case law -- here in the USA, at least -- and Bernstein himself has actually created a Web page to outline the provisions of USA Federal copyright law: Absent a licence, if you have legally acquired a piece of software (e.g., by downloading it from Bernstein's Web site), you are legally entitled to use, and compile the software, and you may distribute patches to that software. (Bernstein's further assertion that copyright law also entitles you to modify code has been convincingly disputed by John Cowan.) But you have no implied legal right to redistribute the software itself or works derived from it. (Thus, if you become dependent on Bernstein software, you run the risk that he might cease development and withdraw it from the Net. Neither you nor anyone else would then have the legal right to take over development and distribute even the old versions, let alone new ones -- except in the form of source-code patches. And other legal jurisdictions might give rise to different rights, or none at all.) (Yes, DJB-acolytes, I do know that Bernstein allows -- for now -- very limited verbatim or language-translated mirroring of some of his "documents", but he makes clear on his "distributors" page that the term refers to his HTML, not his software.) Exactly those conditions apply to every Bernstein package I know of. Exception: Unmodified specific versions of qmail and djbdns/tinydns (formerly dnscache) may be redistributed -- or at least so claimed Bernstein's Web pages, recently. Will those continue to be there, to point to? Remember, if he removes those pages, he says you may no longer mirror or distribute them. Nor are you even allowed to modify Bernstein's packages for redistribution even to the extent of appending copies of those Web pages. Essentially, you're betting that Bernstein never changes his mind, if you rely on such software. (Additional exception: A couple of Bernstein's smallest projects, e.g., CDB = Constant DataBase and libtai, have had looser licensing, but not lately.) I suppose you could stash away private copies of the current contents of these packages' "permission" pages that you're permitted neither to mirror/distribute nor add to the tarballs, documenting their terms and your compliance, but really -- is this any way to run a railroad? They are thus definitively proprietary software -- with limited rights of gratis use if you acquire the package from Bernstein or someone he's specifically authorised to distribute it. Therefore, if you repair his bizarre design decisions, you may not share your work (except as patches, add-ons, or reconfiguration recommendations), and must re-do that repair work with each new version. You also may not put up even unmodified versions for public access (of many of his packages) without special permission. Further, if you attempt to discuss patches he doesn't approve of on his mailing lists, Bernstein has been known to threaten to kick you out. (Please note that Bernstein has expressed to me in e-mail his view that this FAQ item contains "libel" and is "against the law". I referred him to my attorney, and Bernstein has thus far not pursued the matter further.) Prof. Bernstein personally deserves lasting gratitude and praise for the truly heroic role he played in protecting computer users' and programmers' rights in the EFF's Bernstein v. US Department of Justice lawsuit, and his software is beyond doubt of uniformly high coding quality and careful (if eccentric) design. However, I see no reason to put up with the other baggage his software comes with (detailed above). Life is too short to deal with Bernstein-isms, and there are always other decent software choices: Instead of qmail and ezmlm, use Postfix (or Exim) and Mailman. Instead of publicfile's (or anonftpd's) ftp server functions, use Marcus Ranum's aftpd (if you're on *BSD), Shane Kerr's oftpd, Peter Eriksson's pftpd, iMatix Corporation's Xitami, Andrew Kuchling's medusa, Frank Denis's Pure-FTPd, Matthew William Lefkowitz's Twisted, or Chris Evans's vs-ftpd. (I also maintain a list of all known ftp servers for Linux and other Unixes.) If you need an http (Web) server, in place of publicfile you should consider Jef Poskanzer's thttpd / micro-httpd / mini-httpd series, Thomas M. Ogrisegg's Cthulhu, Alex Belits's fhttpd, Ingo Molnar's TUX = Threaded linUX web server (a kernel-based static-page accelerator, now being promoted by its author's employer as "Red Hat Content Accelerator"), or Zach Brown's phhttpd/ matofali or the similar proprietary offering Zeus Web Server, Matthew William Lefkowitz's Twisted, Caudium WebServer, iMatix Corporation's proprietary Xitami, Andrew Kuchling's medusa, Felix von Leitner's fnord (requires the proprietary tcpserver daemon), Richard R.W. Jones's rws, Doug Neal's DNHTTPD, Gerd Knorr's webfs, Matthew R. Green's bozohttpd, Marc Pompl's ghttpd, Muhammad A. Muquit's MHTTPD, Greg Olszewski's chttpd, Doug Hoyte's Anti-Web httpd, Paul Vlaar's neepHttpd, Sven Berkvens's xs-httpd, Peter Eriksson's Phttpd, Fabian Wauthier's navajo, David A. Bartold's dhttpd, Larry Doolittle, Jon Nelson, and Paul Philips's Boa, Yann Ramin's ATPhttpd, Nikos Mavroyanopoulos's Hydra, GoAhead Software, Inc's GoAhead WebServer, Vincent Negrier's Nanoweb, Mark Grosberg's Seminole, Vlajko's BaukHTTPD, Jonas Reese and Torsten Köster's JServer, Eduardo Silva's Monkey HTTP Daemon, Anders Karlsson's PS-HTTPD, the Pegasi LUG's Pegasi Web Server, Matthew Parry's sedhttpd, Neil Conway's Tornado HTTP Server, Claes Wikstrom's Yaws, John Franks's WN, or Michiel Boland's Mathopd. Instead of Bernstein's ucspi-tcp and daemontools, use the much more conventional inetd / tcpwrappers combination, or xinetd. Instead of djbdns/tinydns (Bernstein's DNS nameserver suite): Many of us are migrating to Paul Vixie's (the Internet Software Consortium's) newer, written-from-scratch BIND v. 9 codebase, because the old, traditional BIND v. 8 package is too crufty and security-bug-filled (and has therefore been abandoned). Johannes Erdfelt's dents server remains promising, but development appears to be stalled. Suitable alternatives for some deployments include Thomas Moestl's permanent-caching server pdnsd, Sam Trenholme's MaraDNS, Michael Wolf's moodns, Don Moore's MyDNS, Alexis Yushin / Stichting NLnet Labs's NSD, Brad Garcia's DNRD - Domain Name Relay Daemon, Meilof Veeningen and Jama Poulsen's Posadis, Hubert Tonneau's Pliant, Salvatore Sanfilippo's Yaku-NS (formerly ENS), Eric Kidd's CustomDNS (formerly LiveDNS), Simon Kelley's Dnsmasq, Mrs. Brisby's ldapdns, Creighton Macdonnell and Mike Machado's GnuDIP, Roland Schemer and Rob Riepel's lbnamed, Eddieware's Eddie Enhanced DNS Server (formerly lbdns), and PowerDNS.com BV's PowerDNS. (Consider running your choice of name-server software chrooted, especially if still using BIND v. 8.) djbdns should not be assumed automatically to be an all-around-usage DNS server, either. Some of the areas in which Bernstein has elected not to follow IETF draft standards in djbdns's functioning are outlined in Scott Morizot's letter to Linux Weekly News (seventh letter down). (Note that there are third-party ways to fix djbdns to add support for the IETF NOTIFY protocol, for sending and receiving NOTIFYs, but the point is Bernstein decided not to implement that and many other core DNS protocols: He recommends, for example, that you eschew the standards-track NOTIFY and IXFR protocols, and use rsync instead.) A comprehensive list of IETF DNS protocols omitted from djbdns can be found in Paul Vixie's linuxsecurity.com interview. It can be argued that the omitted DNS protocols are merely standards-track (proposed) IETF protocols as of Nov. 2001 -- whose adoption Bernstein opposes on various grounds. (Relevant RFCs are 1995, 1996, 2136, 2535, 2536, 2537, 2538, 2539, 2845, 2930, 2931, 3007, 3008, 3090, and 3110.) But shunning common zone-transfer mechanisms (NOTIFY, IXFR, outgoing AXFR) is just unreasonable if you want to want to interoperate with the rest of the world. * Are you saying that DJB can revoke the licence to his software by changing or removing his Web pages? No, of course not. The prior essay nowhere states or implies that, nor does anything else I've said, Prof. Bernstein's assertions notwithstanding. The fact that the tarballs of qmail and djbdns/tinydns for which Bernstein permits redistribution may not include copies of his generous (if proprietary) licence terms, together with his restrictions on mirroring of those licence terms, make it very awkward to independently and lastingly document his licence terms and your compliance with them. Not entirely impossible, just very, very awkward -- one of the many hassles with Bernstein software that, in my view, make it not worth the trouble. That and absence of any right to fork (which means the projects effectively cease when/if Bernstein loses interest or dies) were, as I thought entirely obvious, what I meant in saying "Essentially, you're betting that Bernstein never changes his mind, if you rely on such software", especially in conjunction with the remainder of the accompanying licence analysis. The covered software itself may -- by those licence terms, be redistributed, in unmodified form, to anyone. In perpetuity. Some of the other hassles inherent in Bernstein's software are eloquently listed by my friend J. Paul Reed in a user group post (though his point "c" about licensing was in error on points detailed above, concerning which I publicly corrected Reed's erroneous claim (on that mailing list as well as here), and also in private mail. Unfortunately, the prior essay continues to be misrepresented by Prof. Bernstein's roving fanclub around the Internet, leading to my making further comments refocussing their attention on what I actually said and their failure to address it. Last modified: 2004-11-17 rick@xxxxxxxxxxxxxx Copyright (C) 1995-2004 by Rick Moen. Verbatim copying, distribution, and display of this entire article are permitted in any medium, provided this notice is preserved. Alternatively, you may create derivative works of any sort for any purpose, provided your versions contain no attribution to me, and that you assert your own authorship (and not mine) in every practical medium.u > such as that of Dag or ATrpms. I think that there are better modern smtp servers > out there that do a lot more stuff than Qmail and prolly more efficiently with > things built in, Exim comes to mind for one. Exiscan patch is being integrated > into main stream Exim so it should be ninja cool. > > Rahul Sundaram wrote: > > On Fri, 07 Jan 2005 15:41:03 -0700, Aly Dharshi <aly.dharshi@xxxxxxxxx> wrote: > > > >>Qmail has been fairly stationary in its development. I wonder if these shouldn't > >>just be part of a repo as opposed to be included in a FC3/4. I am sure that I > >>could be wrong about this but this is my take on it. > > > > > > the last release was in 1998. > > > > the thing wouldnt build on any modern system and be usable without an > > assortment of patches from qmail.org. > > > > rpms with these patches wouldnt be possible since binary > > redistribution with modifications are not allowed under the qmail > > license. > > > > someone could create a good spec file if they wanted to i guess > > > > -- > Aly Dharshi > aly.dharshi@xxxxxxxxx > > "A good speech is like a good dress > that's short enough to be interesting > and long enough to cover the subject" > > -- > fedora-list mailing list > fedora-list@xxxxxxxxxx > To unsubscribe: http://www.redhat.com/mailman/listinfo/fedora-list > -- Linux/Open Source: Your infrastructure belongs to you, free, forever. Idealism: "Realism applied over a longer time period" http://www.scaled.com/projects/tierone/ http://kinz.org http://www.fedoratracker.org http://www.fedorafaq.org http://www.fedoranews.org Jeff Kinz, Emergent Research, Hudson, MA. ~ ~ ~ ~
