Letters

Readers sound off.
Letters

Well-Tamed Demon

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.

—Jack Dennon

Propagating Disease?

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.

A Perl in the Spam

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

______________________

White Paper
Fabric-Based Computing Enables Optimized Hyperscale Data Centers

Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.

Learn More

Sponsored by AMD

White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy

Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6

Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.

Learn more about catching the bad guy in this free white paper.

Learn More

Sponsored by DLT Solutions