+ <para>FreeBSD è un marchio registrato della FreeBSD Foundation.</para>
+ <para>Intel, Celeron, Centrino, Core, EtherExpress, i386, i486, Itanium, Pentium e Xeon sono marchi o marchi registrati di Intel Corporation o dei suoi affiliati negli Stati Uniti o in altri paesi.</para>
+ <para>Molte denominazioni usate dai produttori e dai rivenditori per distinguere i loro prodotti sono rivendicati come marchi. Laddove queste denominazioni appaiono in questo documento e il FreeBSD Project è al corrente della rivendicazione del marchio, le denominazioni sono state fatte seguire dai simboli <quote>™</quote> o da <quote>®</quote>.</para>
+ </legalnotice>
+
+ <pubdate>$FreeBSD$</pubdate>
+
+ <releaseinfo>$FreeBSD$</releaseinfo>
+ </info>
+
+<sect1 xml:id="intro">
+ <title>Introduzione</title>
+
+ <para>Questo documento promuove l'uso di una licenza in stile BSD per programmi e dati; in particolare raccomanda l'uso di una licenza in stile BSD al posto della GPL. Esso può anche essere letto come un'introduzione e un riassunto comparativo per le licenze Open Source BSD e GPL.</para>
+</sect1>
+
+<sect1 xml:id="history">
+ <title>Storia molto breve dell'Open Source</title>
+
+ <para>Molto prima che il termine <quote>Open Source</quote> fosse usato, esisteva del software che veniva sviluppato da vaghe associazioni di programmatori e che veniva liberamente scambiato. A cominciare dai primi anni Cinquanta, organizzazioni quali <link xlink:href="http://www.share.org">SHARE</link> e <link xlink:href="http://www.decus.org">DECUS</link> sviluppavano molto del software che le compagnie di hardware informatico vendevano incluso nelle loro offerte di hardware. A quel tempo le aziende informatiche vendevano hardware; qualsiasi cosa che riducesse il costo del software e rendesse disponibile un maggior numero di programmi rendeva le aziende hardware più competitive.</para>
+
+ <para>Questo modello cambiò negli anni Sessanta. Nel 1965 ADR sviluppò il primo prodotto con licenza software indipendente dall'hardware dell'azienda. ADR competeva contro un pachetto gratuito dell'IBM originalmente sviluppato dai clienti di IBM. ADR brevettò il proprio software nel 1968. Per interrompere la condivisione del suo programma, lo distribuì a condizione di noleggio di materiale il cui pagamento si estendeva per tutta la durata di vita del prodotto. ADR ne mantenne così la proprietà e poteva controllarne la rivendita e il riuso.</para>
+
+ <para>Nel 1965 il Dipartimento di Giustizia degli Stati Uniti accusò IBM di rovinare aziende offrendo software gratuito incluso nel prezzo di hardware IBM. In seguito al processo, IBM escluse il suo software; cioè, i programmi divennero prodotti separati dall'hardware.</para>
+
+ <para>Nel 1968 Informatics introdusse la prima applicazione di successo e rapidamente stabilì i concetti di prodotto software e azienda software, nonché alti tassi di ricavo. Informatics sviluppò la licenza perpetua che è ora uno standard nell'industria informatica e che prevede che la proprietà non venga mai trasferita al cliente.</para>
+</sect1>
+
+<sect1 xml:id="unix-license">
+ <title>Unix dal punto di vista delle licenze BSD</title>
+
+ <para>AT&T, prorietario dell'implementazione originale di Unix, era un monopolio pubblicamente regolato e vincolato da una causa antitrust; non poteva vendere legalmente prodotti nel mercato del software. Poteva, tuttavia, distribuire software ad istituzioni accademiche al prezzo del supporto.</para>
+
+ <para>Le università adottarono rapidamente Unix dopo che una conferenza sui sistemi operativi ne pubblicizzò la disponibilità. Fu estremamente utile il fatto che Unix girasse su PDP-11, un computer 16-bit molto economico, e fosse codificato in un linguaggio di alto livello che era dimostrabilmente buono per la programmazione di sistemi. Il DEC PDP-11 aveva, in effetti, un'interfaccia hardware aperta progettata per rendere facile per i propri clienti la scrittura dei propri sistemi operativi, un'operazione allora comune. Come il fondatore di DEC Ken Olsen proclamò con una celebre dichiarazione <quote>il software viene dal cielo quando hai un buon hardware</quote>.</para>
+
+ <para>L'autore di Unix Ken Thompson tornò alla sua alma mater, l'Università di Berkeley in California (UCB), nel 1975 ed insegnò il kernel riga per riga. Questo risultò infine in un sistema in evoluzione noto come BSD (Berkeley Standard Distribution). L'UCB convertì Unix a 32-bit, aggiunse la memoria virtuale e implementò la versione dello stack TCP/IP sulla quale sostanzialmente fu costruito Internet. L'UCB rese BSD disponibile al costo del supporto, sotto quella che divenne nota come la <quote>licenza BSD</quote>. Un cliente comprava Unix da AT&T e quindi ordinava un nastro BSD dall'UCB.</para>
+
+ <para xml:lang="en">In the mid-1980s a government anti-trust case against AT&T
+ ended with the break-up of AT&T. AT&T still owned Unix and was now
+ able to sell it. AT&T embarked on an aggressive licensing effort
+ and most commercial Unixes of the day became AT&T-derived.</para>
+
+ <para xml:lang="en">In the early 1990's AT&T sued UCB over license violations
+ related to BSD. UCB discovered that AT&T had incorporated, without
+ acknowledgment or payment, many improvements due to BSD into AT&T's
+ products, and a lengthy court case, primarily between AT&T and UCB,
+ ensued. During this period some UCB programmers embarked on a
+ project to rewrite any AT&T code associated with BSD. This project
+ resulted in a system called BSD 4.4-lite (lite because it was not
+ a complete system; it lacked 6 key AT&T files).</para>
+
+ <para>Una lunga serie di articoli pubblicati poco dopo nella rivista Dr. Dobbs descriveva una versione di Unix per PC 386 derivata da BSD, con file sotto licenza BSD per la sostituzione dei 6 file mancanti da 4.4-lite. Questo sistema, chiamato 386BSD, era opera del programmatore William Jolitz, in precedenza nell'UCB. Esso divenne la base originale di tutti i PC BSD oggi in uso.</para>
+
+ <para xml:lang="en">In the mid 1990s, Novell purchased AT&T's Unix rights and a
+ (then secret) agreement was reached to terminate the lawsuit. UCB
+ soon terminated its support for BSD.</para>
+</sect1>
+
+<sect1 xml:id="current-bsdl">
+ <title>Lo stato attuale di FreeBSD e le licenze BSD</title>
+
+ <para>La cosiddetta <link xlink:href="http://www.opensource.org/licenses/bsd-license.php">nuova licenza BSD</link> applicata a FreeBSD negli ultimi anni è di fatto una dichiarazione per la quale si può fare qualsiasi cosa col programma o il suo sorgente, ma non si riceve nessuna garanzia e nessuno degli autori ha nessuna responsabilità (sostanzialmente, non è possibile querelare nessuno). Questa nuova licenza BSD è intesa per incoraggiare la commercializzazione di prodotti. Qualsiasi codice BSD può essere venduto o incluso in prodotti proprietari senza restrizioni sulla disponibilità del codice o su comportamenti futuri.</para>
+
+ <para>Non si confondano la nuova licenza BSD con il <quote>dominio pubblico</quote>. Sebbene anche un oggetto in dominio pubblico sia libero di essere usato da chiunque, esso non ha proprietario.</para>
+
+</sect1>
+
+<sect1 xml:id="origins-gpl">
+ <title>Le origini della GPL</title>
+
+ <para>Mentre il futuro di Unix era così farraginoso nei tardi anni Ottanta e nei primi anni Novanta, la GPL, un altro sviluppo con importanti considerazioni in materia di licenza, giunse a compimento.</para>
+
+ <para>Richard Stallman, il programmatore di Emacs, era un membro del personale del MIT quando il suo laboratorio cambiò i propri sistemi da proprietari a casalinghi. Stallman si innervosì quando scoprì di non poter apportare legalmente piccoli miglioramenti al sistema. (Molti dei collaboratori di Stallman se ne erano andati per formare due aziende basate su software sviluppato al MIT e licenziato dal MIT; pare che ci sia stato disaccordo sull'accesso al codice sorgente di questo software). Stallman ideò un'alternativa alla licenza software commerciale e la chiamò GPL, o "Gnu Public License". Creò anche una fondazione senza scopo di lucro, la <link xlink:href="http://www.fsf.org">Free Software Foundation</link> (FSF), che intendeva sviluppare un intero sistema operativo, software associato incluso, che non sarebbe stato oggetto di licenza proprietaria. Il sistema fu chiamato GNU, stante per "GNU non è Unix".</para>
+
+ <para>La GPL fu progettata per essere l'antitesi della licenza proprietaria standard. A questo fine, si richiese che ogni modifica che fosse apportata ad un programma GPL fosse restituita alla comunità GPL (richiedendo che il sorgente del programma fosse reso disponibile all'utente) e che ogni programma che usasse o linkasse codice GPL venisse sottoposto alla GPL. La GPL intendeva impedire che il software diventasse proprietario. All'ultimo paragrafo la GPL dichiara:</para>
+
+ <para><quote>Questa Licenza Pubblica Generale non permette di incorporare il tuo programma in programmi proprietari.</quote></para>
+
+ <para>La <link xlink:href="http://www.opensource.org/licenses/gpl-license.php">GPL</link> è una licenza complessa quindi ecco alcune regole pratiche sul suo utilizzo:</para>
+
+ <itemizedlist>
+
+ <listitem><para>è possibile fissare qualsivoglia prezzo per la distribuzione, il supporto o la documentazione del software, ma non è possibile la vendita del software stesso.</para></listitem>
+
+ <listitem><para>la regola generale stabilisce che se è necessario codice GPL per la compilazione di un programma, il programma deve essere sottoposto alla GPL. Il link statico ad una libreria GPL implica che il programma sia sottoposto alla GPL.</para></listitem>
+
+ <listitem><para>la GPL richiede che qualsiasi brevetto associato a software GPL debba essere sottoposto ad una licenza che ne garantisca il libero uso da parte di chiunque.</para></listitem>
+
+ <listitem><para>la semplice aggregazione di software, come il porre programmi diversi su uno stesso disco, non conta quale inclusione di programmi GPL in programmi non GPL.</para></listitem>
+
+ <listitem><para>l'output di un programma non conta quale lavoro derivato. Questo consente al compilatore gcc di essere usato in ambienti commerciali senza problemi legali.</para></listitem>
+
+ <listitem><para>siccome il kernel Linux è sottoposto alla GPL, ogni codice linkato staticamente col kernel Linux deve essere sottoposto alla GPL. Questo requisito può essere aggirato linkando dinamicamente moduli del kernel. Questo permette alle aziende di distribuire driver binari, ma spesso con lo svantaggio che essi funzioneranno solo per versioni particolari del kernel Linux.</para></listitem>
+ </itemizedlist>
+
+ <para>A causa della sua complessità, in molte parti del mondo oggigiorno gli aspetti legali della GPL vengono ignorati per quanto riguarda Linux e software relativo. Le conseguenze a lungo termine di questo approccio non sono chiare.</para>
+
+</sect1>
+
+<sect1 xml:id="origins-lgpl">
+ <title>Le origini di Linux e della LGPL</title>
+
+ <para>Mentre imperversavano le guerre tra gli Unix commerciali, il kernel Linux veniva sviluppato come un clone di PC Unix. Linus Torvalds riconosce l'importanza del compilatore GNU C e degli strumenti GNU associati per l'esistenza di Linux. Egli sottopone il kernel Linux alla GPL.</para>
+
+ <para xml:lang="en">Remember that the GPL requires anything that statically links
+ to any code under the GPL also be placed under the GPL. The source
+ for this code must thus be made available to the user of the
+ program. Dynamic linking, however, is not considered a violation
+ of the GPL. Pressure to put proprietary applications on Linux
+ became overwhelming. Such applications often must link with system
+ libraries. This resulted in a modified version of the GPL called
+ the <link xlink:href="http://www.opensource.org/licenses/lgpl-license.php">LGPL</link>
+ ("Library", since renamed to "Lesser", GPL). The LGPL allows
+ proprietary code to be linked to the GNU C library, glibc. You do
+ not have to release the source code which has been dynamically
+ linked to an LGPLed library.</para>
+
+ <para>Se si linka staticamente un'applicazione con glibc, come è spesso necessario in sistemi integrati, non è possibile mantere la propria applicazione proprietaria, vale a dire, il sorgente deve essere rilasciato. Sia la GPL che la LGPL impongono che ogni modifica al codice direttamente sottoposto alla licenza venga rilasciata.</para>
+
+</sect1>
+
+<sect1 xml:id="orphaning">
+ <title>Licenze Open Source e il problema dell'Orphaning</title>
+
+ <para>Uno dei gravi problemi associati al software proprietario è noto come <quote>orphaning</quote>. Esso si presenta quando un'impresa fallisce o un cambiamento nella strategia dei prodotti causa il fallimento di una vasta piramide di sistemi dipendenti e di compagnie per ragioni al di là del loro controllo. Decadi di esperienza hanno dimostrato che la dimensione o il successo momentanei di un distributore di software non garantiscono che il loro software rimanga disponibile, dato che le condizioni del mercato e le strategie possono cambiare rapidamente.</para>
+
+ <para>La GPL tenta di impedire l'orphaning spezzando il legame con la proprietà intellettuale proprietaria.</para>
+
+ <para>Una licenza BSD consegna all'azienda il software in una specia di acconto di garanzia senza complicazioni o costi legali. Se un programma sottoposto a licenza BSD diventa orfano, un'azienda può semplicemente subentare, in maniera proprietaria, nel mantenimento del programma da cui dipende. Una situazione anche migliore si presenta quando codice BSD viene mantenuto da un piccolo consorzio informale, siccome il processo di sviluppo non dipende dalla sopravvivenza di una singola azienda o di una linea di prodotti. La sopravvivenza di una squadra di sviluppo mentalmente concentrata è molto più importante della semplice disponibilità fisica del codice sorgente.</para>
+
+</sect1>
+
+<sect1 xml:id="license-cannot">
+ <title>Ciò che una licenza non può fare</title>
+
+ <para>Nessuna licenza può garantire la futura disponibilità del software. Benché il detentore di copyright possa tradizionalmente cambiare i termini del copyright stesso in qualsiasi momento, si presuppone nella comunità BSD che tale tentativo causi semplicemente il fork del sorgente.</para>
+
+ <para>La GPL vieta esplicitamente la revoca della licenza. È accaduto, tuttavia, che un'azienda (Mattel) avesse comprato un copyright GPL (cphack), revocato l'intero copyright e vinto in tribunale [2]. Cioè, essa ha legalmente revocato l'intera distribuzione e tutti i lavori derivati basati su quel copyright. Se ciò possa accadere con una distribuzione più ampia e sparsa è una questione aperta; c'è anche qualche confusione riguardo a se il software fosse veramente sottoposto alla GPL.</para>
+
+ <para>In un altro esempio, Red Hat comprò Cygnus, un'azienda di ingegneria che era subentrata nello sviluppo degli strumenti del compilatore della FSF. Cygnus era autorizzata a svolgere questa operazione perché aveva sviluppato un modello commerciale che prevedeva la vendita di supporto al software GNU. Questo le permise di assumere una cinquantina di programmatori e guidare la direzione dei programmi contribuendo alla maggior parte delle modifiche. Come dichiara Donald Rosenberg "progetti che usano licenze quali la GPL... vivono sotto la costante minaccia di vedersi soffiar via il progetto da qualcuno che produce una versione migliore del codice e lo fa più veloce dei proprietari originali." [3]</para>
+
+</sect1>
+
+<sect1 xml:id="gpl-advantages">
+ <title>Vantaggi e svantaggi della GPL</title>
+
+ <para>Una ragione comune per l'uso della GPL è la modifica o l'estensione del compilatore gcc. Ciò è particolarmente conveniente quando si lavora con processori molto particolari in ambienti in cui è probabile che tutti i costi del software siano considerati spese di gestione, con minime aspettative riguardo all'uso da parte di altri del compilatore risultante.</para>
+
+ <para>La GPL è vantaggiosa per piccole aziende che vendono CD in un ambiente dove "compra basso, vendi alto" può ancora consegnare all'utente finale un prodotto molto economico. Essa è vantaggiosa anche per le aziende che contano di sopravvivere fornendo varie forme di supporto tecnico, documentazione inclusa, per il mondo della proprietà intellettuale GPL.</para>
+
+ <para>Un uso meno pubblicizzato e imprevisto della GPL consiste nell'essere molto favorevole a grandi aziende che vogliono tagliar fuori aziende del software. In altre parole, la GPL è adatta per essere utilizzata come un'arma di mercato, potenzialmente riducendo il beneficio economico globale e contribuendo ad un comportamento monopolistico.</para>
+
+ <para>La GPL può costituire un vero problema per coloro che vogliono commercializzare software e trarne profitto. Per esempio, la GPL accrese la difficoltà di uno studente laureato di fondare un'azienda per commercializzare i risultati delle sue ricerche e accrese altresì la difficoltà di uno studente di entrare in un'azienda a condizione che un suo progetto di ricerca promettente venga commercializzato.</para>
+
+ <para>Per coloro che devono lavorare con implementazioni linkate staticamente di diversi standard software, la GPL è spesso una licenza infelice, perché preclude l'uso di implementazioni proprietarie degli standard. Così la GPL riduce il numero di programmi che possono essere costruiti usando uno standard GPL. La GPL intenzionalmente non fornisce un meccanismo per sviluppare uno standard sul quale si possano sviluppare prodotti proprietari. (Ciò non si applica alle applicazioni Linux perché non si collegano staticamente al kernel, bensì usano un'API trap-based.)</para>
+
+ <para>La GPL cerca di portare i programmatori a contribuire ad una collezione di programmi in evoluzione, quindi di competere nella distribuzione e nel supporto di questa collezione. Questa situazione è irrealistica per molti standard di sistema di base richiesti, che potrebbero essere applicati in ambienti ampiamente variabili richiedenti personalizzazioni commerciali o integrazioni con standard legacy sottoposti a licenze già esistenti (non GPL). Sistemi in tempo reale sono spesso linkati staticamente, quindi la GPL e la LGPL sono decisamente considerate potenziali problemi da molte aziende di sistemi integrati.</para>
+
+ <para>La GPL è un tentativo di mantenere gli sforzi, senza riguardo per la domanda, ai livelli della ricerca e dello sviluppo. Questo massimizza i benefici per i ricercatori e gli sviluppatori, ad un costo ignoto per coloro che guadagnerebbero da una distribuzione più ampia.</para>
+
+ <para>La GPL è stata progettata per impedire che i risultati di ricerca diventassero prodotti proprietari. Si suppone spesso che questo passo sia l'ultimo nel processo tradizionale di trasferimento tecnologico ed è solitamente abbastanza difficile nelle migliori delle circostanze; la GPL lo rende intenzionalmente impossibile.</para>
+
+</sect1>
+
+<sect1 xml:id="bsd-advantages">
+ <title>Vantaggi di BSD</title>
+
+ <para>Una licenza in stile BSD è una buona scelta per ricerche di lunga durata o altri progetti che necessitano di un ambiente di sviluppo tale che:</para>
+
+ <itemizedlist>
+
+ <listitem><para>abbia costi quasi nulli</para></listitem>
+ <listitem><para>evolva in un lungo periodo di tempo</para></listitem>
+ <listitem><para>permetta a chiunque di mantenere la possibilità di commercializzare i risultati finali con problemi legali minimi.</para></listitem>
+ </itemizedlist>
+
+ <para>Quest'ultima considerazione può essere spesso quella dominante, come fu il caso quando il progetto Apache decise la sua licenza:</para>
+
+ <para><quote>Questo tipo di licenza è ideale per promuovere l'uso di un codice di riferimento che implementi un protocollo per un servizio comune. Questa è un'altra ragione per cui l'abbiamo scelto per il gruppo Apache - molti di noi volevano vedere HTTP sopravvivere e diventare un vero standard comune e non si sarebbero preoccupati minimamente se Microsoft o Netscape avessero scelto di incorporare il nostro motore HTTP o qualsiasi altra componente del nostro codice nei loro prodotti, se fosse stato ulteriormente utile allo scopo di mantenere HTTP comune... Tutto ciò significa che, strategicamente parlando, il progetto necessita di mantenere slancio sufficiente e che i partecipanti realizzano valore maggiore condividendo il loro codice col progetto, anche quel codice che avrebbe avuto valore se mantenuto proprietario.</quote></para>
+
+ <para>I programmatori tendono a trovare la licenza BSD vantaggiosa per il fatto che tiene i problemi legali fuori dai piedi e lascia loro fare ciò che vogliono con il codice. Al contrario, coloro che contano principalmente di utilizzare un sistema piuttosto che di programmarlo, o contano che altri facciano evolvere il codice, o coloro che non contano di vivere del loro lavoro associato al sistema (quali gli impiegati di governi), trovano la GPL vantaggiosa, perché fa sì che il codice sviluppato da altri sia loro restituito e impedisce il loro datore di lavoro di mantenere il copyright e così potenzialmente di "seppellire" il software o di renderlo orfano. Se si desidera costringere i concorrenti ad aiutare, la GPL è vantaggiosa.</para>
+
+ <para>Una licenza BSD non è semplicemente un regalo. La domanda <quote>perché dovremmo aiutare i nostri concorrenti o lasciarli rubare il nostro lavoro?</quote> sorge spesso riguardo ad una licenza BSD. Secondo la licenza BSD, se un'azienda è venuta a dominare una nicchia di mercato che altri consideravano strategica, le altre aziende possono, con uno sforzo minimo, formare un mini-consorzio mirato a riequilibrare le parti contribuendo ad una variante BSD competitiva che aumenta la concorrenza di mercato e l'equità. Ciò permette ad ogni azienda di ritenere che sarà in grado di trarre profitto da un qualche vantaggio che è capace di fornire, nonché di contribuire alla flessibilità e all'efficienza economica. Più rapidamente e facilmente i membri cooperanti sono in grado di attuare ciò, più successo conseguiranno. Una licenza BSD è essenzialmente una licenza complicata il minimo necessario da consentire tale comportamento.</para>
+
+ <para>Un effetto chiave della GPL, la costruzione di un sistema Open Source completo e competitivo ampiamente disponibile al prezzo del supporto, è uno scopo ragionevole. Una licenza in stile BSD, in congiunzione con consorzi ad hoc ed individui, può raggiungere questo scopo senza distruggere i presupposti economici costruiti attorno al termine del processo di trasferimento tecnologico, vale a dire la distribuzione.</para>
+
+</sect1>
+
+<sect1 xml:id="recommendations">
+ <title>Raccomandazione specifiche per l'uso di una licenza BSD</title>
+
+ <itemizedlist>
+
+ <listitem><para>La licenza BSD è preferibile per trasferire risultati di ricerca in modo che vengano ampiamente distribuiti e che benefici l'economia. Pertanto, agenzie di finanziamento di ricerca, qualsi NSF, ONR o DARPA, dovrebbero incoraggiare, nelle fasi iniziali dei progetti di ricerca finanziati, l'adozione di licenze in stile BSD per software, dati, risultati e hardware aperto. Dovrebbero incoraggiare anche la formazione di standard basati su sistemi implementati Open Source e progetti Open Source in sviluppo.</para></listitem>
+
+ <listitem><para>Le politiche di governo dovrebbero minimizzare i costi e le difficoltà nel pasaggio dalla ricerca alla distribuzione. Quando possibile, le sovvenzioni dovrebbero richiedere che i risultati vengano resi disponibili secondo le condizioni di una licenza compatibile con la commercializzazione in stile BSD.</para></listitem>
+
+ <listitem><para xml:lang="en">In many cases, the long-term results of a BSD
+ style license more accurately reflect the goals proclaimed in
+ the research charter of universities than what occurs when
+ results are copyrighted or patented and subject to proprietary
+ university licensing. Anecdotal evidence exists that
+ universities are financially better rewarded in the long run by
+ releasing research results and then appealing to donations from
+ <listitem><para>Le aziende hanno riconosciuto da molto tempo che la creazione di standard de facto è una tecnica di commercializzazione chiave. La licenza BSD interpreta bene questo ruolo, se un'azienda ha veramente un vantaggio unico nell'evoluzione del sistema. La licenza è legalmente vantaggiosa per il pubblico più ampio mentre l'esperienza dell'azienda assicura il controllo dello standard. Esistono casi in cui la GPL può essere il veicolo appropriato per creare uno standard del genere, soprattutto quando si cerca di sabotare o cooptare altri. La GPL, tuttavia, penalizza l'evoluzione dello standard, perché promuove una collezione di software piuttosto che uno standard commercialmente applicabile. L'uso di una tale collezione solleva costantemente problemi legali e di commercializzazione. Può non essere possibile mescolare standard quando alcuni sono sottoposti alla GPL mentre altri non lo sono. Un vero standard tecnico non dovrebbe imporre esclusioni di altri standard per ragioni non tecniche.</para></listitem>
+
+ <listitem><para xml:lang="en">Companies interested in promoting an evolving
+ standard, which can become the core of other companies' commercial
+ products, should be wary of the GPL. Regardless of the license
+ used, the resulting software will usually devolve to whoever
+ actually makes the majority of the engineering changes and most
+ understands the state of the system. The GPL simply adds
+ more legal friction to the result.</para></listitem>
+
+ <listitem><para>Grandi aziende, in cui viene sviluppato codice Open Source, dovrebbero essere a conoscenza del fatto che i programmatori apprezzano l'Open Source perché lascia il software disponibile all'impiegato quando cambiano datore di lavoro. Alcune aziende incoraggiano questo comportamento come un vantaggio dell'impiego, soprattuto quando il software in questione non è direttamente strategico. Si tratta, in effetti, di un benificio anticipato dell'interruzione del rapporto di lavoro con costi di perdita potenziali ma senza costi diretti. Incoraggiare gli impiegati a lavorare per colleghi al di fuori dell'azienda è un economico beneficio trasferibile che un'azienda può a volte fornire quasi senza svantaggi.</para></listitem>
+
+ <listitem><para>Piccole aziende con progetti software vulnerabili all'orphaning dovrebbero cercare di usare la licenza BSD quando possibile. Aziende di tutte le dimensioni dovrebbero considerare di formare tali progetti Open Source quando il mantenimento al minimo dei problemi legali e dei costi generali associati ad un vero progetto Open Source in stile BSD costituisce un vantaggio per tutte le parti.</para></listitem>
+
+ <listitem><para>Le organizzazioni senza fini di lucro dovrebbero partecipare a progetti Open Source quando possibile. Per evitare problemi di programmazione del software, come il mescolamento di codici sottoposti a licenze diverse, bisognerebbe incoraggiare l'uso di licenze in stile BSD. Essere cauti con la GPL è particolarmente indicato nel caso di organizzazioni senza scopo di lucro che interagiscono con il mondo della programmazione. In località in cui l'applicazione della legge diventa un esercizio costoso, la semplicità della nuova licenza BSD, paragonata alla GPL, può costituire un vantaggio considerevole.</para></listitem>
+
+ </itemizedlist>
+
+</sect1>
+
+<sect1 xml:id="conclusion">
+ <title>Conclusione</title>
+
+ <para>Al contrario della GPL, che è progettata per impedire la commercializzazione proprietaria di codice Open Source, la licenza BSD pone restrizioni minime su comportamenti futuri. Questo consente al codice BSD di rimanere Open Source o di venire integrato in soluzioni commerciali, dato che i bisogni di un progetto o di un'azienda cambiano. In altre parole, la licenza BSD non diventa una bomba ad orologeria legale in nessun punto del processo di sviluppo.</para>
+
+ <para>Inoltre, siccome la licenza BSD non comporta la complessità legale delle licenze GPL e LGPL, consente ai programmatori e alle aziende di impiegare il loro tempo nel creare e promuovere codice di qualità invece di preoccuparsi riguardo alla possibilità che tale codice violi qualche licenza.</para>