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

Benvenuti ad un nuovo numero di Brave GNU World. Come promesso alla fine del precedente numero, questo mese mi piacerebbe presentare un progetto che mi ha reso la vita assai più facile.

SpamAssassin

Lo SpamAssassin [5] di Justin Mason consente di "assassinare" lo Spam nella vostra posta elettronica in arrivo - o almeno contrassegna lo Spam facendo si che Procmail o il client di posta possano gestirlo nel modo meno fastidioso per l'utente.

Il cuore dello SpamAssassin è un programma Perl distribuito con la medesima doppia licenza GNU GPL/Artistic License di Perl. Questo ha consentito di distribuire SpamAssassin attraverso il "Comprehensive Perl Archive Network" (CPAN) [6] e di riutilizzare il codice da lì proveniente senza nessun problema di carattere legale.

Le questioni di licenza sono state una parte cruciale all'inizio di questo progetto. Prima di scrivere SpamAssassin, Justin utilizzava un altro filtro di posta scritto in Perl, la qual cosa divenne un problema a causa delle proprie regole statiche ed una situazione incerta della licenza.

Di questo progetto Justin ha adottato l'idea di lavorare con i punteggi, un concetto molto simile allo "Adaptive Scoring" ("Punteggio Adattivo" N.d.T.) impiegato dal lettore di news e di posta GNUS. [7]

Lo SpamAssassin funziona applicando diversi test alla posta elettronica che analizza. Ci sono test per messaggi in HTML puro, che verificano se il messaggio contiene frasi usate frequentemente nello Spam, se un messaggio dichiara di non essere Spam in accordo a specifiche leggi e regolamenti, se contiene una quantità inconsueta di punti esclamativi o interrogativi, se parla di "Millions Dollars" e così via.

Per ciascun test che è stato attivato, un messaggio guadagna punti; quanti punti vengano totalizzati da ciascun test può essere specificato dall'utente in un file di configurazione ASCII piuttosto semplice. Se la somma di tutti i punteggi supera una certa soglia, anch'essa definibile dall'utente, SpamAssassin stabilisce che quel messaggio è probabilmente Spam.

Sulla base di questa decisione, SpamAssassin inserisce dei flag nell'intestazione che forniscono informazioni sull'esito del test. Se l'utente lo desidera, ai messaggi Spam viene "forzato" un Content-Type "text/plain," che rende molto più facili ulteriori verifiche dei risultati. Inoltre, SpamAssassin può inserire un dettagliato rapporto di test all'inizio del messaggio così che un utente può facilmente rendersi conto del perchè un messaggio sia stato classificato come Spam.

Il più grosso rischio nell'utilizzo di SpamAssassin è chiaramente costituito dai cosiddetti risultati "falsi positivi" - normali e regolari messaggi classificati erroneamente come Spam. Si raccomanda quindi di verificare sistematicamente la cartella dello Spam, che è quella in cui tutto lo Spam identificato dovrebbe andare di solito, per rettificare eventuali risultati "falsi positivi".

Potete anche scegliere di abbassare la sensibilità di SpamAssassin, la qual cosa farà aumentare la quantità di Spam non rilevato. Trovare il giusto equilibrio è il delicato compito dell'amministratore di SpamAssassin.

Per impedire agli spammers di trovare il modo di eludere i test dello SpamAssassin, il progetto include il maggior numero di test possibile ed è inoltre facilmente estendibile.

Naturalmente supporta anche le liste nere (blacklists) online. Sono supportate liste nere DNS standard, che indicano note fonti e relay per lo Spam, come Vipul's Razor, [8] un database di Spam che consente l'identificazione di Spam noto.

Per facilitare il filtraggio di grosse quantità di posta ed il collegamento al maggior numero possibile di caselle, Craig Hughes ha scritto il demone "spamd", distribuito col pacchetto di SpamAssassin.

Il più grosso punto debole di SpamAssassin è quello di essere rivolto ad utenti tecnicamente preparati e di non avere (ancora) una interfaccia grafica.

Sistemare questa cosa, così come scrivere più test e creare più moduli per i sistemi di posta sono le cose più importanti per un ulteriore sviluppo. Sono attualmente disponibili collegamenti a Procmail, Qmail, Postfix e Sendmail attraverso la libreria Milter ed il plug-in Mail::Audit.

Spero vogliate scusarmi se riporto che il plugin sendmail-milter [9] è stato scritto da me, dopo inutili ricerche di soluzioni già esistenti. In questo modo ho potuto utilizzare SpamAssassin per filtrare tutta la posta in arrivo. Comunque, la mancanza di tempo da parte mia mi impedisce di mantenere adeguatamente il progetto, così Michael Brown, la cui azienda lo utilizza e lo offre in una soluzione commerciale, si è preso carico del mantenimento, nella miglior tradizione del Software Libero.

Questo è un bell'esempio di come il Software Libero può armonizzare il classico approccio "chi fa da sé fa per tre" con gli interessi commerciali di un'azienda, a vantaggio di tutti gli utenti.

Dovendo affrontare un flusso crescente di Spam che rischia di seppellire internet, devo ammettere che ho una grossa simpatia per i progetti come SpamAssassin, che si sbarazza di circa 60 messaggi Spam al giorno per me.

Voxximate

I lettori abituali di Brave GNU World dovrebbero avere ormai una certa familiarità con molte delle argomentazioni a favore dell'adozione del Software Libero in campo scientifico.

Alla fin fine, il Software libero è la sola scelta ragionevole nel lungo periodo per tutti i tipi di produzioni scientifiche, poichè solo il Software Libero può offrire la garanzia di restare utile per futuri progetti, permette di essere incluso nei propri risultati scientifici, ad esempio pubblicazioni, come parte del proprio lavoro e di affidarlo a qualcun altro quando necessario.

Voxximate [10] di Andreas Neumann è uno di questi progetti scientifici rilasciati come Software Libero sotto Licenza Pubblica Generale GNU (GNU GPL N.d.T.)

Voxximate sta per "Vortex flow simulation made at home," ("Simulazione del flusso di un vortice fatta in casa", N.d.T.), è un programma per la simulazione delle correnti e dei vortici in un fluido. Il programma funziona basandosi su posizioni di partenza predefinite ed adotta provvedimenti concreti per calcolare l'influenza di ciascun vortice in tutti gli altri vortici, tracciandone lo sviluppo nel tempo.

Il progetto è maggiormente utile a tutti quegli studenti che affrontano la fluidodinamica durante i loro studi, interessati a studiare come i vortici interagiscono e modellano strutture.

Voxximate è stato scritto in Java, per cui porta con se i soliti problemi di Java, ma ciò non dovrebbe impedire a nessuno di supportare ulteriori sviluppi. Come ulteriori passi, Andreas spera di includere un editor grafico per definire le posizioni di partenza e la possibilità di salvare i grafici e le animazioni per poter poi essere pubblicate sul web.

Monica

Monica [11] è un programma di calibrazione del monitor di Tila Riemer. È stato scritto in C++ ed utilizza il Fast Light Toolkit (FLTK) [12] ed il programma di Xfree86 xgamma [13].

Una errata correzione gamma del monitor può rendere impossibile distinguere i colori che sono vicini o creare una impressione insoddisfacente degli schemi di colorazione. Questa cosa potrebbe risultare fastidiosa, specialmente nel caso in cui un computer fosse utilizzato per lavori di grafica.

Inizialmente, Tilo Riemer tentò di utilizzare un progetto simile: KGamma [14]; ma non fu in grado di compilarlo perchè mancavano diverse librerie KDE ed inoltre KGamma sembrava essere così profondamente collegato a KDE da necessitare di grosse parti di KDE per funzionare.

Così nel Gennaio 2002 ha iniziato a scrivere Monica, che ha il vantaggio di essere molto piccolo e veloce. Questo ha permesso di includere una modalità "on-the-fly" ("al volo", N.d.T.) che rende possibile un feedback dinamico. Su un computer di 900Mhz ciò necessita di circa il 10-20% di tempo della CPU.

Ulteriori punti di forza di Monica sono l'assenza di dipendenze - al di là delle librerie FLTK - e la politica di salvare le modifiche negli ".xinitrc" degli utenti per renderli indipendenti dal window manager o dal desktop.

Il recente rilascio della versione 1.0 chiarisce che Tilo non intende investire ancora molto tempo per Monica, ciò nonostante egli apprezzerebbe eventuali sforzi per la propria internaziolizzazione.

Originariamente, Tilo pensò di rilasciare Monica come "Dominio Pubblico," poichè gli pareva piccolo ed insignificante per preoccuparsi della licenza. Nel codice sorgente scrisse comunque "Copyright © Tilo Riemer," - senza pensaci troppo.

Il concetto di Dominio Pubblico è piuttosto problematico nell'Europa continentale. In Germania, la comune interpretazione del termine è: privo di rivendicazioni relative al diritto d'autore - che solitamente significa che l'autore è sconosciuto o deceduto da più di 70 anni. Entrambi i casi non sono evidentemente applicabili.

Perciò Tilo decise di pubblicare Monica sotto una licenza stile BSD, risolvendo il problema immediato e rendendo Monica Software Libero.

Questa storia non è rara e dimostra che agli sviluppatori ovviamente non piace molto pensare alle licenze - nonostante sia molto facile introdurre punti deboli facendo in questo modo. Perciò tenterò di fornire una introduzione comprensibile alla "manutenibilità legale" del Software Libero.

"Manutenibilità legale" del Software Libero

La maggior parte delle persone sono coscenti del fatto che grossa parte del software necessita di manutenzione costante oppure perderà rapidamente la propria utilità. Spesso, solo il software che è costantemente manutenuto può essere impiegato per lunghi periodi di tempo.

Questa procedura prettamente tecnica dipende dall'accesso al codice sorgente e dal diritto, cioè la libertà, di eseguire la manutenzione. In generale, definire i diritti e i doveri di ciascun membro della società è ciò di cui si occupa il sistema politico-legale.

Se il sistema legale funzioni bene oppure no non è la questione importante. Quello di cui ci si dovrebbe rendere conto è che alcuni dei prerequisiti per la manutenibilità tecnica sono di natura legale.

Specialmente in un ambiente commerciale, la garanzia di una manutenibilità duratura e permanente è uno dei vantaggi rilevanti del Sofware Libero. Questo vantaggio dipende fortemente dalla manutenibilità legale del Software Libero.

Le libertà, i diritti ed i doveri del Software Libero, sono garantire e talvolta protette attraverso le licenze, che sono "ancorate" al software attraverso il diritto d'autore. Per funzionare, il Software Libero non dipende prettamente dal diritto d'autore, ma siccome la legge sul diritto d'autore esiste, dobbiamo fare i conti con essa.

Cosa significa manutenibilità legale in questo contesto?

Anche se non è la maniera nella quale la maggior parte delle persone lo percepisce, il sistema legale non è statico, cambia in continuazione.

Le modifiche che riguardano la legge sul diritto d'autore potrebbero, come in un recente caso accaduto in Germania, potenzialmente indebolire o persino mettere fuori legge il Software Libero. In questo caso specifico, ifrOSS [15] e FSF Europe [16] sono state in grado di suggerire una modifica alla proposta di revisione della legge, introducendo un'eccezione per il Software Libero. Questa modifica ha reso legge l'eccezione nella forma originale suggerita da ifrOSS ed è divenuta parte integrante della legge approvata il 25.01.2002 che verrà presto emanata.

Uno dei compiti della FSF Europe è di sorvegliare su questi sviluppi ed influenzarli in modo positivo per il Software Libero. Senza la cooperazione con organizzazioni quali ifrOSS, la cui natura è perfettamente legale, sarebbe molto più difficile riuscirci; questo è il motivo per cui FSF Europe lavora per stabilire e rafforzare la cooperazione in Europa.

Sarebbe anche stato possibile che modifiche di altri parametri legali avessero richiesto un adattamento delle licenze. Modifiche alla legge o nuovi concetti tecnici come "Application Service Providing" (ASP) potrebbero aggirare la protezione della libertà in qualche aspetto o addirittura renderla inefficace, in realtà violando lo spirito delle licenze.

La maggior parte degli sviluppatori pubblicano il proprio software sotto la Licenza Pubblica Generale GNU (GNU GPL N.d.T.), consapevoli che facendo in quel modo hanno assicurato e protetto le libertà del proprio software. Facendo così, i provvedimenti più importanti per rendere sicuro il Software Libero sono già stati presi. In più, utilizzando la clausola "or any later version" ("o qualsiasi successiva revisione" N.d.T.), la FSF è in parte autorizzata a proteggere globalmente, difendere e mantenere la protezione fornita attraverso la (L)GPL.

In ogni caso, talvolta potrebbe diventare importante modificare esplicitamente una licenza. I progetti che non hanno stabilito una gestione centralizzata delle questioni legali possono trovarsi in guai seri in questo caso, specialmente quando la clausola "or any later version" della GPL è stata rimossa.

In questi casi tutti gli sviluppatori - ammesso che sia possibile trovarli tutti - devono accettare le modifiche. Dato l'ampio spettro di interessi ed opinioni degli sviluppatori che lavorano ad un progetto, ciò appare estremamente improbabile.

Inoltre, nella maggior parte dei casi il detentore dei cosiddetti "diritti escusivi di utilizzazione", cioè del "diritto d'autore", ha la facoltà legale di far applicare la licenza in tribunale. Così i progetti potrebbero incappare in serie difficoltà nel momento in cui si cercasse di difendere i loro interessi in tribunale.

Nel momento in cui diversi autori lavorano su un progetto, essi dovranno efficacemente formare un gruppo ed agire assieme al fine di proteggere i loro interessi individuali. Questo necessita di un sacco di coordinamento, tempo e fatica. Inoltre, non tutti gli autori gradiscono o sono in grado di vedere giungere a conclusione una disputa legale potenzialmente lunga.

Sarebbe buona cosa se più progetti si rendessero conto di queste relazioni e prendessero adeguate precauzioni. Incaricando un fiduciario, gli autori possono inoltre dedicarsi a migliorare essi stessi il software.

Appare probabile che in futuro i progetti con condizioni legali chiare e ben definite avranno un vantaggio in termini di guadagno in popolatità, poichè gli utenti molto probabilmente vi presteranno attenzione con maggior frequenza.

Per assicurare la manutenibilità legale del Software Libero - specialmente all'interno dell'area chiave del Progetto GNU, ma non solo - la Free Software Foundation ha iniziato fin da subito a lavorare con il così detto "trasferimento del diritto d'autore" che la autorizza a difendere il diritti del Software Libero (anche in tribunale) ed adattare la licenza al cambiare delle circostanze.

Poichè la legge sul diritto d'autore dell'europa continetale ha basi differenti rispetto al Copyright anglo-americano, la FSF Europe ha lavorato assieme ad Axel Metzger, Carsten Schulz e Till Jaeger della ifrOSS alla stesura di un "Fiduciary Licence Agreement," ("Accordo di Licenza Fiduciario ", N.d.T.) che permette alla FSF Europe di agire come fiduciaria degli autori.

L'autore mantiene una quantità illimitata di "diritti individuali di sfruttamento", che possono essere utilizzati per rilasciare il software, utilizzando uno schema di licenza doppio, sotto un'altra licenza (potenzialmente persino proprietaria).

Allo stesso tempo, la FSF Europe garantisce di utilizzare i diritti trasferiti esclusivamente nell'interesse del Software Libero e pubblicherà il software solamente sotto una licenza libera - contrariamente tutti i diritti ritornano all'autore.

Questo accordo è attualmente nella "fase di revisione" interna e sarà presentato al pubblico in un futuro non troppo lontano.

Come presidente della FSF Europe ritengo che la Free Software Foudation sia meglio preparata a questo compito poichè continuerà ad affrontare queste sfide con l'affidabilità per la quale la FSF è conosciuta da diversi anni.

Loro non solo sono in possesso della più grossa conoscenza ed esperienza con la Licenza Pubblica Generale GNU (GNU GPL N.d.T.) e la Lesser GPL, essi possono agire a livello mondiale ed hanno la giustificata reputazione di essere capaci di difendere gli interessi del Software Libero; anche per vie legali, se ce ne fosse bisogno.

Per oggi è abbastanza

Dovrebbe errere abbastanza per oggi. Spero di essere riuscito nell'ultima parte a creare una maggior consapevolezza dei retroscena, del lavoro e dei compiti della Free Software Foudation.

Come al solito, vi chiederei di inviarmi una gran quantità di messaggi di posta elettronica con idee, commenti, domande e nuovi progetti.