[DE | EN | FR | IT | JA | ES | KO | PT]

Welcome to a new issue of the Brave GNU World. As promised at the end of the last issue, this month I'd like to introduce a project that has made my life much easier.

SpamAssassin

The SpamAssassin [5] by Justin Mason allows "assassinating" Spam in your incoming email - at least it marks the Spam and so allows Procmail or the mail reader to handle Spam in the least annoying way for the user.

The heart of the SpamAssassin is a Perl program distributed under the same dual GNU General Public License/Artistic License as Perl itself. This made it possible to distribute the SpamAssassin through the "Comprehensive Perl Archive Network" (CPAN) [6] and reuse code from it without any legal problems.

Licensing issues have been a crucial part in the beginning of this project, by the way. Before he wrote the SpamAssassin, Justin used another mail filter written in Perl, which became a problem because of its static rules and unclear license situation.

From this project Justin did adopt the idea to work with scores, a concept very similar to the "Adaptive Scoring" employed by the GNUS News- and Mailreader. [7]

The SpamAssassin works by applying many different tests to the email it parses. There are tests for HTML-only mail, whether mail contains often-used Spam-phrases, whether a mail claims not to be Spam according to certain laws and regulations, whether it contains an unusual amount of exclamation or question marks, talks about "Millions Dollars" and so on.

For every test that was triggered, an Email collects points; which tests scores how many points can be specified by the user in a rather simple ASCII configuration file. If the sum of all scores passes a certain - also user-definable - threshold, the SpamAssassin judges that the mail is probably Spam.

Based on this decision, the SpamAssassin inserts header flags informing about the test results. If the user so wishes, the Spam emails are also forced to have Content-Type "text/plain," which makes it much easier to later check the results. Also the SpamAssassin can insert a more detailed test report at the beginning of the mail, so a user can easily see why a mail has been rated Spam.

The biggest potential risk in using SpamAssassin are clearly the "false-positive" results - regular, normal Email falsely classified as Spam. Therefore it is recommended to regularly take a look at the Spam-folder, which is where all detected Spam should normally go, in order to rectify false-positive results.

You can also choose to lower the sensitivity of the SpamAssassin, which will increase the amount of undetected Spam. Finding the proper balance is the tricky part for the SpamAssassin administrator.

To prevent spammers from finding ways to bypass the SpamAssassin tests, the project incorporates as many different tests as possible and is also easily extensible.

Of course it also supports the online-blacklists. Standard DNS-blacklists referencing known sources and relays for Spam are equally supported as Vipul's Razor, [8] a Spam database allowing identification of known Spam.

In order to allow easy filtering of large amounts of mail and connection to as many mail-sources as possible, Craig Hughes wrote the "spamd" daemon, which comes with the SpamAssassin package.

The biggest weakness of the SpamAssassin is that it is more or less targeted at the technically experienced user and does not (yet) have a graphical user interface.

Fixing this as well as writing more tests and creating more bindings to mail sources is the focal point of further development. Currently available are bindings to Procmail, Qmail, Postfix, Sendmail through the Milter library and a Mail::Audit plugin.

I hope to be excused for mentioning that the sendmail-milter plugin [9] was written by me after an unsuccessful search for existing solutions, so I could use the SpamAssassin to filter all incoming mail. Lack of time on my side forbids to maintain the project properly, however, so Michael Brown, whose company employs/offers it in a commercial environment, has taken over as the maintainer in best Free Software tradition.

This is a nice example of how Free Software can harmonize the classic "scratch your own itch" approach with commercial interests of a company for the best of all users.

Facing an increasing flood of Spam threatening to bury the internet under it, I have to admit I hold great sympathy for projects like the SpamAssassin, which gets rid of about 60 Spam emails a day for me.

Voxximate

Regular readers of the Brave GNU World should by now be pretty familiar with many of the arguments for Free Software in the scientific field.

Ultimately, Free Software is the only sensible long-term choice for all kinds of scientific work, because only Free Software can offer the guarantee to remain useful for future projects and it allows being included in own scientific results i.e. publication as part of ones work and passing on when required.

Voxximate [10] by Andreas Neumann is such a scientific Free Software project under the GNU General Public License.

Voxximate stands for "Vortex flow simulation made at home," it is a program for the simulation of currents/vortices in fluids. The program works based on predefined starting positions and uses concrete steps to calculate the influence of all vortices on all other vortices, tracking the development through time.

The project is probably most useful for all students facing fluid dynamics at some point in their studies, interested in studying how vortices interact and build structures.

Voxximate was written in Java, which brings the usual Java problems, but this should not keep anyone from supporting further development. For the next steps, Andreas hopes to include a graphical editor to define starting positions and capabilities to save graphics and animations that can then be published on the web.

Monica

Monica [11] is a monitor calibration program by Tilo Riemer. It was written in C++ and uses the Fast Light Toolkit (FLTK) [12] and the xgamma program of XFree86. [13]

A wrong gamma-correction for the monitor can make it impossible to distinguish colors that lie close together or create an unsatisfactory impression of the coloring-schemes. Especially if a computer is used for graphical work, this can be disturbing.

Initially, Tilo Riemer tried to use the related project KGamma, [14] but he failed to compile it because several KDE libraries were missing and also KGamma seemed to be so deeply embedded in KDE that it needs large parts of KDE to work.

So in January 2002 he began writing Monica, which has the advantage of being very small and fast. This allowed including an "on-the-fly" mode, making dynamic feedback possible. On a 900MHz computer this needs about 10-20% of the CPU time.

Further strengths of Monica are an absence of dependencies beyond the FLTK and the policy to save changes in the users ".xinitrc;" to make them independent of the window manager or desktop.

The recent release of version 1.0 indicates that Tilo does not plan to invest a lot more time into Monica, although he would welcome efforts to internationalize it.

Originally, Tilo planned to release Monica as "Public Domain," since it seemed to small and insignificant to warrant thinking about licenses. Into the sourcecode he wrote "Copyright © Tilo Riemer," though - without further thinking about it.

The notion of Public Domain isn't quite unproblematic in continental Europe, however. In Germany, the standard legal interpretation of the term is free of authorship/copyright claims - which usually means either the author is unknown or dead for more than 70 years. Both cases clearly did not apply.

Therefore Tilo decided to publish Monica under a BSD-like license, solving the immediate problems and making Monica Free Software.

This story is not very unusual and demonstrates that developers obviously don't like thinking about licenses very much - although it is very easy to introduce insecurities when not doing so. Therefore I will try to give an understandable introduction into the the legal maintainability of Free Software.

Legal maintainability of Free Software

Most people are aware that a large part of all software requires permanent technical maintenance or it will quickly lose its usefulness. Often only software that is permanently maintained can be employed over longer periods of time.

This per se technical procedure depends on access to the source code and the right i.e. the freedom to perform the maintenance. Generally speaking, defining the rights and obligations of every member of society is what the political/legal system does.

Whether the legal system is working well or not isn't the important point. What one should realize is that some of the prerequisites for technical maintainability are of legal nature.

Especially in a commercial environment, the guarantee of permanent and lasting maintainability is one of the seminal advantages for Free Software. This advantage depends strongly on the legal maintainability of Free Software.

The freedoms, rights and obligations of Free Software are granted and sometimes protected through licenses, which are "anchored" to the software through the copyright of the author. Free Software does not strictly depend on copyright law to work, but since copyright law exists, we need to deal with it.

What does legal maintainability mean in this context?

Even if this is not how most people percieve it intuitively, the legal system is not statical, it is ever-changing.

Changes affecting the copyright law could, as was recently the case in Germany, potentially weaken or even outlaw Free Software. In this specific case, ifrOSS [15] and FSF Europe [16] were capable of suggesting a change of the proposed copyright law revision, introducing an exception for Free Software. This change made it into the law in the original form suggested by the ifrOSS and became part of the law passed on 25.1.2002 that will be enacted soon.

One of the tasks of the FSF Europe is to keep looking for such developments and influence them in a positive way for Free Software. Without cooperation with organizations like the ifrOSS, which is clearly entirely legal in nature, doing this would be much harder; which is why the FSF Europe works on establishing and strengthening cooperations throughout Europe.

It would also have been possible that changes in other legal parameters would have required an adaptation of the licenses. Legal changes or new technical concepts like "Application Service Providing" (ASP) could possibly bypass the protection of freedom in some areas or even render it ineffective, effectively violating the spirit of the licenses.

Most developers publish their software under the GNU General Public License, conscious of by doing so having secured and protected the freedom of their software. When doing so, the most important step towards securing Free Software has already been taken. By employing the "or any later version" clause the FSF is also partially empowered to globally protect, defend and maintain the licensing under (L)GPL.

Sometimes it may become important to explicitly change a license, however. Projects that have not established a central maintenance of legal rights can get into serious trouble in such a case, especially when the "or any later version" clause of the GPL has been removed.

In such a case all developers - assuming they can all be found - have to agree to the change. Given the rather wide spectrum of interests and opinions of the developers working on some projects, this does not seem very likely.

Additionally, in most cases only the holder of the so-called "exclusive exploitation rights" i.e. the "Copyright" is legally entitled to enforce the license in court. So projects can run into serious difficulties when trying to represent the interests of the project in court.

Given that many authors are working on a project, they will effectively have to team up and act together in order to protect their individual interests. This requires a lot of coordination, time and effort. Also not all authors are willing or capable of seeing a potentially drawn-out legal struggle through to the end.

It would be good if more projects became aware of these relationships and took adequate precautions. By appointing a fiduciary, authors can also get back to improving the software itself.

For the future it seems likely that projects with clear and sorted-out legal circumstances will have an advantage gaining popularity, since users will quite likely more often pay attention to this.

In order to secure the legal maintainability of Free Software - especially inside the core area of the GNU Project, but not limited to it - the Free Software Foundation has started early to work with the so-called "Copyright Assignments," which empower it to defend the rights of Free Software (even in court, if need be) and adapt the licensing to the changing circumstances.

Since the continental-European Authorship law has a different basis than the anglo-american Copyright, the FSF Europe has also been working together with Axel Metzger, Carsten Schulz and Till Jaeger of the ifrOSS on a "Fiduciary Licence Agreement," which allow the FSF Europe to act as the fiduciary of the authors.

The author retains an unlimited amount of "single exploitation rights," which can be used by the author to dual-license the software under other (potentially even proprietary) licenses.

At the same time, the FSF Europe guarantees to only use the transferred rights in the interest of Free Software and will only publish the software under a Free license - otherwise all rights fall back to the author.

This agreement is currently in the final internal "review phase" and will be introduced to the public in the not too distant future.

As the president of the FSF Europe I consider the Free Software Foundation to be best-suited for this task as they will continue meeting these challenges with the reliability that the FSF has been known for in long years.

They not only possess the largest knowledge and experience with the GNU General Public License and Lesser GPL, they can act worldwide and have a justified reputation for being able to defend the interests of Free Software; also with legal means, if need be.

Enough for today

That should be enough for today. I hope to have succeeded in the last part to create some more awareness for the background and the tasks and work of the Free Software Foundation.

As usual, I'd like to ask for loads of Email [1] containing ideas, comments, questions and new projects.