fighting-software-patents.html (9293B)
1 <!--#set var="ENGLISH_PAGE" value="/philosophy/fighting-software-patents.en.html" --> 2 3 <!--#include virtual="/server/header.it.html" --> 4 <!-- Parent-Version: 1.96 --> 5 <!-- This page is derived from /server/standards/boilerplate.html --> 6 <!--#set var="TAGS" value="essays laws patents" --> 7 <!--#set var="DISABLE_TOP_ADDENDUM" value="yes" --> 8 9 <!-- This file is automatically generated by GNUnited Nations! --> 10 <title>Contro i brevetti sul software - Individualmente ed insieme - Progetto GNU - 11 Free Software Foundation</title> 12 13 <!--#include virtual="/philosophy/po/fighting-software-patents.translist" --> 14 <!--#include virtual="/server/banner.it.html" --> 15 <!--#include virtual="/philosophy/ph-breadcrumb.it.html" --> 16 <!--GNUN: OUT-OF-DATE NOTICE--> 17 <!--#include virtual="/server/top-addendum.it.html" --> 18 <div class="article reduced-width"> 19 <h2>Contro i brevetti sul software - Individualmente ed insieme</h2> 20 21 <address class="byline">di Richard Stallman</address> 22 23 <p> 24 Per un progetto software, i brevetti sul software sono l'equivalente delle 25 mine antiuomo: ogni decisione di progettazione porta con sé il rischio di 26 calpestare un brevetto che andrà a distruggere il vostro lavoro.</p> 27 <p> 28 Lo sviluppo di un programma ampio e complesso comporta la combinazione di 29 molte idee, spesso centinaia o migliaia. Nei paesi che ammettono i brevetti 30 sul software, è altamente probabile che molte delle vostre idee siano già 31 state brevettate da qualche azienda. E' possibile che centinaia di brevetti 32 coprano parti del vostro programma. Uno studio condotto nel 2004 ha concluso 33 che in un solo programma importante si faceva uso di almeno 300 brevetti 34 registrati negli Stati Uniti d'America. Fare uno studio del genere è un 35 lavoro così gravoso che ne è stato fatto soltanto uno.</p> 36 <p> 37 Dal punto di vista pratico, uno sviluppatore di software si troverà spesso 38 ad essere colpito da un brevetto alla volta. In tal caso si potrebbe 39 superare il problema senza subire danni riuscendo a trovare delle 40 argomentazioni giuridiche per evitare il brevetto. Si può anche provare e, 41 riuscendoci, si avrebbe una mina in meno nel nostro campo minato. Se questo 42 brevetto è particolarmente minaccioso in generale, la <a 43 href="https://wiki.endsoftwarepatents.org/wiki/Public_Patent_Foundation">Public 44 Patent Foundation</a> potrà occuparsi del caso: è il suo ruolo. Se venisse 45 chiesta la collaborazione della comunità degli utenti informatici per 46 cercare pubblicazioni precedenti della stessa idea, in modo da usarle per 47 eliminare un brevetto, tutti dovremmo rispondere con ogni informazione utile 48 che sia a nostra conoscenza.</p> 49 <p> 50 Tuttavia, combattere i brevetti uno ad uno non eliminerà mai il pericolo dei 51 brevetti sul software, sarebbe come cercar di sconfiggere la malaria 52 schiacciando le zanzare. Non ci si può aspettare di abbattere ogni brevetto 53 che si incontra, così come non si può sperare di uccidere tutti i mostri di 54 un videogioco: prima o poi, uno di questi vi vincerà e danneggerà il vostro 55 programma. L'ufficio americano competente rilascia circa 100.000 brevetti 56 all'anno: nonostante i nostri sforzi, non possiamo immaginare di 57 disinnescare queste mine con la stessa velocità con cui vengono piazzate.</p> 58 <p> 59 Alcune di queste mine non sono neutralizzabili. Ciascun brevetto sul 60 software è dannoso e limita ingiustamente il nostro modo di usare il 61 calcolatore, ma non tutti sono legalmente nulli secondo i criteri del 62 sistema di regolamentazione competente. Quelli che possiamo far annullare 63 sono quelli nati da “errori”, nei quali non sono state correttamente 64 applicate le regole del sistema dei brevetti. Non possiamo fare alcunché nei 65 casi in cui l'unico errore di rilievo risulta essere la politica che 66 permettere i brevetti sul software.</p> 67 <p> 68 Per salvare il salvabile, non basta uccidere i mostri non appena ci si 69 parano davanti: occorre eliminare il meccanismo che li produce. Far 70 annullare uno ad uno i brevetti non renderà più sicuro il lavoro dei 71 programmatori. Per fare ciò, occorre cambiare il sistema dei brevetti in 72 modo che questi non possano più minacciare gli sviluppatori di software e 73 gli utenti.</p> 74 <p> 75 Non c'è alcun conflitto tra queste due campagne: si può contemporaneamente 76 lavorare sull'obiettivo a breve termine e su quello a lungo termine. Se si 77 fa attenzione, si può fare in modo che gli sforzi necessari a far invalidare 78 ogni singolo brevetto sul software abbiano una doppia funzione, fornendo 79 sostegno agli sforzi necessari per correggere l'intero sistema. Il punto 80 cruciale è non mettere sullo stesso piano i brevetti “cattivi” e quelli 81 sbagliati o non validi. Ogni volta che invalidiamo un brevetto, ogni volta 82 che parliamo dei nostri piani per riuscirci, dovremmo dire senza mezzi 83 termini: «Un brevetto in meno, una minaccia in meno per i programmatori; 84 l'obiettivo è zero».</p> 85 <p> 86 La battaglia sui brevetti software nell'Unione Europea sta raggiungendo una 87 fase critica. Un anno fa il Parlamento Europeo votò definitivamente contro i 88 brevetti. A maggio il Consiglio dei Ministri votò per cancellare gli 89 emendamenti del Parlamento e rendere la direttiva ancora peggiore di quanto 90 non lo fosse all'inizio. Ad ogni modo, almeno un paese tra quelli che 91 sostenevano questa posizione ha già rovesciato il suo voto. Dobbiamo fare 92 del nostro meglio per convincere un altro paese europeo a cambiare il 93 proprio voto e convincere i nuovi membri del Parlamento Europeo a ritornare 94 al voto iniziale. Visitate il sito <a 95 href="https://www.ffii.org/">ffii.org</a> per avere maggiori informazioni su 96 come aiutare e contattare altri attivisti.</p> 97 </div> 98 99 <div class="translators-notes"> 100 101 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't have notes.--> 102 </div> 103 </div> 104 105 <!-- for id="content", starts in the include above --> 106 <!--#include virtual="/server/footer.it.html" --> 107 <div id="footer" role="contentinfo"> 108 <div class="unprintable"> 109 110 <p>Per informazioni su FSF e GNU rivolgetevi, possibilmente in inglese, a <a 111 href="mailto:gnu@gnu.org"><gnu@gnu.org></a>. Ci sono anche <a 112 href="/contact/">altri modi di contattare</a> la FSF. Inviate segnalazioni 113 di link non funzionanti e altri suggerimenti relativi alle pagine web a <a 114 href="mailto:webmasters@gnu.org"><webmasters@gnu.org></a>.</p> 115 116 <p> 117 <!-- TRANSLATORS: Ignore the original text in this paragraph, 118 replace it with the translation of these two: 119 120 We work hard and do our best to provide accurate, good quality 121 translations. However, we are not exempt from imperfection. 122 Please send your comments and general suggestions in this regard 123 to <a href="mailto:web-translators@gnu.org"> 124 125 <web-translators@gnu.org></a>.</p> 126 127 <p>For information on coordinating and contributing translations of 128 our web pages, see <a 129 href="/server/standards/README.translations.html">Translations 130 README</a>. --> 131 Le traduzioni italiane sono effettuate ponendo la massima attenzione ai 132 dettagli e alla qualità, ma a volte potrebbero contenere imperfezioni. Se ne 133 riscontrate, inviate i vostri commenti e suggerimenti riguardo le traduzioni 134 a <a 135 href="mailto:web-translators@gnu.org"><web-translators@gnu.org></a> 136 oppure contattate direttamente il <a 137 href="http://savannah.gnu.org/projects/www-it/">gruppo dei traduttori 138 italiani</a>.<br/>Per informazioni su come gestire e inviare traduzioni 139 delle nostre pagine web consultate la <a 140 href="/server/standards/README.translations.html">Guida alle traduzioni</a>.</p> 141 </div> 142 143 <!-- Regarding copyright, in general, standalone pages (as opposed to 144 files generated as part of manuals) on the GNU web server should 145 be under CC BY-ND 4.0. Please do NOT change or remove this 146 without talking with the webmasters or licensing team first. 147 Please make sure the copyright date is consistent with the 148 document. For web pages, it is ok to list just the latest year the 149 document was modified, or published. 150 151 If you wish to list earlier years, that is ok too. 152 Either "2001, 2002, 2003" or "2001-2003" are ok for specifying 153 years, as long as each year in the range is in fact a copyrightable 154 year, i.e., a year in which the document was published (including 155 being publicly visible on the web or in a revision control system). 156 157 There is more detail about copyright years in the GNU Maintainers 158 Information document, www.gnu.org/prep/maintain. --> 159 <p>Copyright © 2004, 2021 Richard Stallman</p> 160 161 <p>Questa pagina è distribuita secondo i termini della licenza <a rel="license" 162 href="http://creativecommons.org/licenses/by-nd/4.0/deed.it">Creative 163 Commons Attribuzione - Non opere derivate 4.0 Internazionale</a> (CC BY-ND 164 4.0).</p> 165 166 <!--#include virtual="/server/bottom-notes.it.html" --> 167 <div class="translators-credits"> 168 169 <!--TRANSLATORS: Use space (SPC) as msgstr if you don't want credits.--> 170 Tradotto originariamente da Vasco Maria Cleri. Modifiche successive di 171 Giorgio V. Felchero, Paola Blason. Domenico Delle Side, Dora Scilipoti, 172 Francesco Potortì.</div> 173 174 <p class="unprintable"><!-- timestamp start --> 175 Ultimo aggiornamento: 176 177 $Date: 2021/10/16 10:33:12 $ 178 179 <!-- timestamp end --> 180 </p> 181 </div> 182 </div> 183 <!-- for class="inner", starts in the banner include --> 184 </body> 185 </html>