Your articles on configuring the pppd are outstanding [see Tony Mobily's “Configuring pppd in Linux” parts I and II in the February and March 2002 issues of LJ]. This is the way a HOWTO should be done—excellent hands-on information that works, with complete directions for us beginners. Well done! You can ask Tony back any time.
I read with interest Larry Rosen's “Unbiased License FUD” in your March 2002 issue. I am appreciative that Larry is dispelling the confusion about how the GNU GPL works. He is quite correct that to have obligations under the terms of the GNU GPL, one must actually create and/or distribute a derivate work of some copyrighted software licensed under the GNU GPL.
However, while dispelling FUD in that area, Larry (perhaps unintentionally) helped to spread similar FUD himself. In his article, Larry propagated the idea that the “GPL is an infection”. Infections are (according to “dict” on my Debian GNU/Linux system) things “which taint or corrupt morally” or “cause...disease”.
This sort of fear mongering about the GNU GPL became all too common during summer 2001, when various high-ranking executives of Microsoft called the GNU GPL an un-American cancerous virus that ate up software like a Pac-Man. I doubt that Larry or your magazine want to affiliate themselves with that concerted campaign of FUD.
As a strong advocate of software freedom, I often tell people: “The GNU GPL is not a virus; by contrast, it vaccinates you from harm.” The GNU GPL is designed to share freedom with all who benefit from the software. No one is required to “join the club”, but when you do choose to create derivative works of GNU GPLed software, you have obligations to the community. The GNU GPL is designed to create a software commons, with provisions that help avoid the tragedy of the commons.
I urge your editorial staff and Larry himself to avoid using biased terms like “infection” when trying to give “Unbiased License” information. The unbiased way to describe the GNU GPL's nature in this regard is simple: “The GNU GPL requires that those who distribute derivate works license the source of the derivate work in a GPL-compatible way.”
—Bradley M. KuhnVice President, Free Software Foundation
Larry replies: Bradley, thanks for your letter. I usually try to avoid the term “infection” when speaking of the GPL. However, I used that word in that particular article because, as I quoted directly in my second paragraph, the reader who responded to me used that word. I certainly did not intend to propagate the notion that the GPL has virus-like attributes, in the sense of things “which taint or corrupt morally” or “cause...disease”. I perhaps should have used the word “inheritance” instead, as I have done in my other writings about the GPL, because that word has more positive implications. Indeed, I have recently started to use the term “reciprocity” to describe the effect of the GPL and similar open-source licenses (including the MPL and CPL). Those licenses require licensees to reciprocate by licensing their derivative works under the same license as the work they were given. In contract law terms, I contend, the reciprocity obligation is the “consideration” you pay for the grant to you of the free license to the original code.
I have a few comments regarding David Bandel's Focus on Software column in the March 2002 issue of Linux Journal. First, great job, David. Keep up the good work! For me, your article is second only to Freshmeat when it comes to discovering new software. Second, I was thrilled to see coverage of Vipul's Razor (razor.sourceforge.net). I've found it to be incredibly effective in weeding out my daily dose of spam.
Although I am a long time Procmail user, I've often found its recipes difficult (at best) and cryptic (at worst). I can't begin to count the hours I've spent writing and debugging what should be a fairly simple filter. I think many of even the more hard-core Procmailers would be pressed to disagree with me on this point.
So, it was with no small amount of giddiness that I discovered Mail::SpamAssassin. This module (accessible via CPAN.org) is a plugin to the Mail::Audit module. The true advantage is that, because it's Perl, you can easily filter your e-mail through a Perl script. I have a tutorial covering this at PerlMonks (www.perlmonks.org) under the Tutorials section entitled (appropriately enough) “A Beginner's Guide to Using Mail::Audit and Mail::SpamAssassin”. Using these modules gives you the power of Perl (renowned for its ability to parse text) to filter your e-mail. I've been using this for several months now, and I've found that approximately 99% of my daily spam is filtered appropriately. And, I'm proud to report that none of my e-mail has been lost. Again, you're doing a great job. Keep it up!
—Stephen E. Hargrove
Special Reports: DevOps
Have projects in development that need help? Have a great development operation in place that can ALWAYS be better? Regardless of where you are in your DevOps process, Linux Journal can help!
With deep focus on Collaborative Development, Continuous Testing and Release & Deployment, we offer here the DEFINITIVE DevOps for Dummies, a mobile Application Development Primer, advice & help from the experts, plus a host of other books, videos, podcasts and more. All free with a quick, one-time registration. Start browsing now...
- The Ubuntu Conspiracy
- Science on Android
- A First Look at IBM's New Linux Servers
- Disney's Linux Light Bulbs (Not a "Luxo Jr." Reboot)
- Vigilante Malware
- Vagrant Simplified
- Libreboot on an X60, Part I: the Setup
- Bluetooth Hacks
- October 2015 Issue of Linux Journal: Raspberry Pi
- System Status as SMS Text Messages