I brevetti sono il rilascio parafulmine del momento nel software libero. Perché pongono la sola minaccia reale contro la quale la comunità del software libero non può difendersi. I problemi di copyright e di marchio ci si può sempre fare l'esperienza. Se parte del vostro codice sembra poter usurpare il copyright di qualche altro, voi potete riscrivere quella parte. Se vien fuori che qualcuno che ha il marchio sul nome del vostro progetto, nel peggior caso potete cambiar nome al vostro progetto. Sebbene il cambiamento del nome potrebbe essere un inconveniente temporaneo, non sarebbe un problema nei tempi lunghi, poiché il codice stesso farebbe ancora ciò che ha sempre fatto.

Ma una partente è una completa ingiunzione contro l'implementazione di una certa idea. Non importa chi scrive il codice, né quale linguaggio di programmazione è usato. Una volta che uno ha accusato un progetto di software libero di infrangere un brevetto, il progetto o deve smettere di implementare una data funzionalità, o trovarsi di fronte a una causa dispendiosa e che assorbe tempo. Poiché gli istigatori di tali cause sono usualmente compagnie con tasche profonde—cioè quelle che hanno le risorse e l'inclinazione ad acquistare i brevetti all'inizio—la maggior parte dei progetti di software libero non può permettersi l'ultima possibilità, e deve capitolare immediatamente anche se si pensa che è molto verosimile che il brevetto sarebbe non sacettibile di tutela giudiziaria nella corte. Per evitare di trovarsi in una tale situazione in primo luogo, i progetti di software libero, stanno incominciando a scrivere codice in modo difensivo, evitando in anticipo algoritmi patentati anche quando essi sono la migliore o l'unica soluzione disponibile per i problemi di programmazione.^[29]

Osservazione ed evidenze aneddotiche mostrano che non solo la vasta maggioranza del programmatori open source, ma una maggioranza di tutti i programmatori pensano che i brevetti dovrebbero esser abolite completamente.^[30] I programmatori open source tendono rendersi conto in maniera particolarmente forte di ciò, e possono rifiutarsi di lavorare a progetti che siano molto associati alla raccolta o all'imposizione dei brevetti. Se la vostra organizzazione raccoglie brevetti di software, allora chiarite, in modo pubblico irrevocabile, che i brevetti non sarebbero mai applicate ai progetti open source, e che sono solo da usare come difesa nel caso che altre parti inizino una procedura legale di infrazione contro la vostra organizzazione. Questa non solo è la cosa giusta da fare, è anche una buona pubblica relazione open source. Per esempio RedHat ha promesso che i progetti open source sono al sicuro dai suoi brevetti, vedere http://www.redhat.com/legal/patent_policy.html.

Sfortunatamente, la raccolta dei brevetti a scopo difensivo è un atto razionale. Il corrente sistema dei brevetti, almeno negli Stati Uniti, è per sua natura un confronto armato: se i vostri concorrenti hanno acquistato un sacco di brevetti, allora la vostra miglior difesa è acquistare un sacco di brevetti a vostra volta, così se siete colpiti da una azione legale di infrazione di un brevetto potete rispondere con una minaccia simile—allora le due parti si siedono ad un tavolo per un accordo commerciale di licenze incrociate in modo che nessuna di esse abbia da pagare qualcosa, eccetto che i legali della loro proprietà intellettuale, ovviamente.

Il danno fatto al software libero dai brevetti è più insidioso che la minaccia diretta allo sviluppo del codice, comunque. I brevetti di software incoraggiano una atmosfera di segretezza fra i progettisti di firmware, che giustamente temono che pubblicando i dettagli della loro interfaccia staranno dando un aiuto ai concorrenti che stanno cercando di dar loro uno schiaffo con azioni legali di infrazione dei brevetti. Questo non è un danno teorico; è avvenuto in modo evidente per lungo tempo nell'industria delle schede video, per esempio. Molti costruttori di schede video sono riluttanti a rilasciare le specifiche di programmazione necessarie per produrre drivers open source ad alte prestazioni per le loro schede, rendendo così impossibile ai sistemi operativi liberi di supportare quelle schede al pieno delle loro potenzialità. Perché i costruttori farebbero ciò? Non ha senso per loro lavorare contro il supporto al software; dopotutto la compatibilità con più sistemi operativi può significare solo più vendita di schede. Ma vien fuori che, dietro le porte della stanze di progettazione, questi negozi stanno tutti violando i brevetti l'uno degli altri, a volte con cognizione di fatto e altre inconsapevolmente. I brevetti sono così imprevedibili e così potenzialmente di larga portata che nessun costruttore di schede può mai essere certo do essere al sicuro, anche dopo avere fatto una ricerca del brevetto. Così, i costruttori non osano pubblicare le specifiche delle loro interfacce, perché ciò renderebbe molto più facile per i concorrenti capire se un brevetto è stata violato. (Certamente la natura di questa situazione è tale che non troverete una ammissione scritta da parte di una fonte primaria che ciò sta avvenendo; io lo ho appreso da una personale informazione).

Alcune licenze di software hanno delle clausole per combattere, o almeno scoraggiare, i brevetti di software. La GNU GPL, per esempio, contiene questa espressione:

      7. Se, in conseguenza di un giudizio della corte o di una dichiarazione 
         di violazione di un brevetto o per qualche altra ragione (non limitata
         al problema dei brevetti) sono imposte a voi condizioni (per decisione
         della corte, accordo o altro) che vadano contro le condizioni di questa
         licenza, esse non vi esonerano dalle condizioni di questa licenza. Se voi
         non potete distribuire in modo da soddisfare contemporaneamente i vostri
         obblighi con questa licenza e ogni altro obbligo pertinente, quindi di
         conseguenza non potete distribuire punto il Programma. Per esempio, se
         una licenza brevetto non permettesse la redistribuzione senza compenso
         del Programma da parte di tutti quelli che ne ricevono copie direttamente
         o indirettamente tramite voi, allora l'unico modo per voi di soddisfare sia
         essa che questa licenza sarebbe astenersi del tutto dalla distribuzione del Programma.

      [...]

      Non è proposito di questa sezione indurvi a violare alcun 
      brevetto o altri giusti  diritti di proprietà o a contestare la validità
      di alcuni di questi diritti; questa sezione ha il solo proposito di
      protegger il sistema di distribuzione del software libero che è
      implementato dalla prassi delle licenze pubbliche. Molte persone hanno dato
      generosi contributi alla larga estensione di software distribuito
      con questo sistema confidando nella applicazione coerente di quel
      sistema; dipende dall'autore/donatore decidere se vuol
      distribuire il software con altri sistemi e la licenza non può
      imporre quella scelta.
    

anche La Licenza Apache, Versione 2.0 (http://www.apache.org/licenses/LICENSE-2.0) ontiene requisiti anti-brevetto. Primo, stabilisce che chiunque distribuisca codice sotto la licenza debba implicitamente includervi un brevetto che liberi dal pagamento di qualsiasi copia per ogni brevetto che potrebbe contenere ciò che potrebbe applicarsi al codice. Secondo, e con moltissimo ingegno, essa punisce chiunque inizi un reclamo di violazione del brevetto sul lavoro coperto, ponendo termine automaticamente alla sua licenza brevetto nel momento in cui tale reclamo è fatto:

      3. Concessione di Licenza Brevetto. Soggetto ai termini e alle condizioni
         di questa Licenza ogni collaboratore concede con questo mezzo a Voi una licenza
         brevetto perpetua, per tutto il mondo, non esclusiva, gratuita, che libera 
         dal pagamento di qualsiasi copia, irrevocabile (eccetto quanto stabilito in
         questa sezione) a fare, aver fatto, usare, offrire per vendita, vendere, importare
         e in altro modo trasferire il Lavoro, dove tale licenza si applica solo a quei
         diritti di brevetto che danno facoltà di concedere diritti da parte di tale 
         Collaboratore e che sono necessariamente violati dal suo Contributo(i) da solo
         o in combinazione con il suo Contributo(i) al Lavoro al quale tale Contributo
         fu inviato. Se voi create una controversia con qualche entità (incluso un
         reclamo contro la parte che sta al vostro fianco o un contro reclamo in una corte)
         asserendo che il Lavoro o il Contributo incorporato nel Lavoro costituisce
         una violazione del brevetto diretta o derivante dal contributo, allora ogni
         licenza brevetto concessa a Voi sotto questa Licenza per quel Lavoro sarà
         terminata dalla data in cui tale controversia è depositata.
    

Sebbene ciò sia utile, sia da un punto di vista legale che come politica, per costruire la difesa dei brevetti nelle licenze di software libero a questo modo, alla fine questi passi non saranno sufficienti a dissipare l'effetto scoraggiante che la minaccia di dibattimento in tribunale ha sul software libero. Ciò creerà solo dei cambiamenti nella sostanza o nell'interpersonale della legge sui brevetti. Per apprendere sul problema e come sta venendo combattuto, andare a http://www.nosoftwarepatents.com/. L'articolo della Wikipedia http://en.wikipedia.org/wiki/Software_patent ha anche un sacco di utili informazioni sui brevetti di software. Io ho scritto anche un post in un blog che sintetizza gli argomenti contro i brevetti sul software a Questo capitolo è stato solo una introduzione ai problemi di licenza sul software libero, a http://www.rants.org/2007/05/01/how-to-tell-that-software-patents-are-a-bad-idea/.