1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
#use wml::debian::template title="Paragoni tra Licenze Software"
#use wml::debian::translation-check translation="a2d057aa44562ddcc643379de20b7fc2c0c7f9e4"
<P><STRONG>******Questo documento è ancora in sviluppo*******</STRONG></P>
<P>La gente che è stata attorno a Free Software tende a sviluppare
opinioni molto marcate sulle licenze. I principianti non se ne curano
molto dato che essi sono più impegnati nel finire l'attività a mano e
non comprendono le implicazioni a lungo termine di scegliere il
software con una licenza invece di un altra (si dubita che ci siano
molte persone, che non abbiano opinioni marcate in materia, in
grado di comprendere le sfumature delle concessioni in licenza).
<P>Con gli anni una quantità di licenze hanno guadagnato importanza
dato che offrono agli autori del software il tipo di controllo sulle
loro creazioni che molti sviluppatori desiderano. È ancora comune
trovare software che non ha alcun visibile copyright o contiene
un'unica licenza sviluppata dall'autore.
L'ultimo caso può risultare abbastanza noioso per i distributori di
software (sia on-line sia le persone che creano CD) dato che molte di
queste licenze contengono <A HREF="#mistakes">errori comuni</A> che
rendono il software difficile da distribuire.
<P>Segue un'elenco di comuni licenze Free (Open) software con punti a
sfavore e a favore di ciascuna.
Sono evidenziati solo i punti rilevanti nella licenza.
Inoltre, molti punti sono elencati sotto l'intestazione "ASPETTO POSITIVO/NEGATIVO".
Sono punti che possono sia essere buoni che cattivi, dipende dal punto
di vista.
<UL>
<LI>La <A HREF="https://www.gnu.org/">GNU General Public License (GPL)</A>.
<BR>
<B>SOMMARIO:</B> il codice sorgente deve essere reso disponibile;
il software può essere venduto; lavori derivati devono usare la stessa
licenza.
<BR>
<B>ASPETTO POSITIVO:</B> Ci sono buone ragioni per cui questa è
una delle
licenze per software Free (Open) più diffuse. Compie bene il lavoro
di proteggere i diritti degli sviluppatori software e la
disponibilità del codice garantisce che gli utenti non dovranno
preoccuparsi di perdere il supporto in futuro.
<BR>
<B>ASPETTO POSITIVO/NEGATIVO:</B> Il software rilasciato utilizzando
la GPL non può essere incorporato all'interno di software
commerciale. Se questa sia una cosa negativa dipende dal tuo punto
di vista. Le persone che sviluppano software commerciale spesso si
sentono frustrate quando la soluzione è disponibile ma non può essere
usata a causa di conflitti nella licenza. Certo, nulla impedisce
loro di contattare l'autore e vedere se possono acquistare una
versione utilizzando un'altra licenza.
Chiunque rilascia software utilizzando GPL non considera queste
restrizioni cattive, perché impediscono ad altri di far soldi
sfruttando il loro duro lavoro ed impedendo ad altri di usarlo.
<LI>Artistic License
<A HREF="http://language.perl.com/misc/Artistic.html">http://language.perl.com/misc/Artistic.html</A>.
<BR>
<B>SOMMARIO:</B>
<BR>
<B>ASPETTO POSITIVO:</B>
<BR>
<B>ASPETTO NEGATIVO:</B>
<LI><A HREF="https://opensource.org/licenses/BSD-3-Clause">licenza stile BSD</A>.
<BR>
<B>SOMMARIO:</B>Il codice sorgente e il prodotto finale devono
contenere la licenza; la pubblicità deve menzionare gli sviluppatori
elencati nella licenza.
<BR>
<B>ASPETTO NEGATIVO/POSITIVO:</B> Le compagnie che vogliono che un
eseguibile sia generalmente disponibile (possibilmente gratis)
senza rilasciare il codice sorgente spesso apprezzano questa
licenza.
Un buon esempio è una compagnia che vuole rilasciare un driver
per una scheda video. Gli avvocati di Open Source
preferirebbero comunque che la compagnia rilasciasse specifiche
hardware. Se lo sviluppo di driver per XFree86 è indicativo, i
migliori driver sono quelli scritti con il sorgente
disponibile. Tali compagnie stanno solo cercando di far
sembrare non buoni i loro prodotti rilasciando driver
proprietari che sono lenti e problematici. Possono inoltre
risparmiare sui costi di sviluppo permettendo ad altri di
sviluppare il driver per loro.
<BR>
<B>ASPETTO POSITIVO/NEGATIVO:</B> Chiunque può prendere i
sorgenti, modificarli e rilasciare il risultato senza rilasciare i
cambiamenti. Se questo sia positivo o negativo è un'opinione
personale.
</UL>
<HR>
<P><A name="mistakes">Alcuni errori comuni nelle licenze scritte da sé</A>
<UL>
<LI>Non permettere o restringere la vendita per-profit del software.
Questo rende difficile inserire quel software nel CD. La gente
spesso compie l'errore di usare termini che non sono ben definiti,
come 'costi ragionevoli'.
È meglio usare semplicemente una delle licenze menzionate sopra
dato che svolgono la stessa attività senza ricorrere a tali frasi.
Per esempio, permettendo a chiunque di distribuire il software,
GPL mantiene basso il costo attraverso le comuni leggi del mercato.
Se qualcuno vende un CD con un ampio margine di guadagno non
passerà molto tempo prima che dei concorrenti entreranno nel mercato e
vendano per un prezzo più basso.
<BR>Nota: la 'Artistic License' usa il termine `Ragionevole costo
di copiatura', ma lo qualifica in modo tale da renderlo meno vago.
<LI>Non permettere la distribuzione di versioni modificate del
software.
Questo ostacola la distribuzione di software da parte di certi
gruppi. Per esempio, siccome Debian distribuisce software
compilato, spesso è necessario modificare i sorgenti per farlo
compilare o per renderlo applicabile a
<A HREF="http://www.pathname.com/fhs/">FHS</A>.
Ma facendo questo, non siamo poi in grado di distribuirlo.
<LI>Richiedere che tutti i cambiamenti al software vengano riportati
all'autore. Mentre è una buona idea informare l'autore di
cambiamenti/miglioramenti affinché possano essere ampiamente
distribuiti, farne un requisito può causare problemi.
Quante persone sanno dove saranno tra 5 anni??
Semplicemente lo si cambi in 'Qualsiasi cambiamento al software
dovrebbe essere riportato all'autore'.
Lo desiderano molte persone.
<BR>Questa sezione è presente di solito per impedire lo sviluppo
di progetti laterali.
La storia ha mostrato che finché non si ferma lo sviluppo sul
codice originale i cambiamenti hanno successo solo se ci sono
altre forze che guidano la divisione.
<LI>Affermare che il software è di pubblico dominio, ma poi aggiungere
costrizioni (come non permettere la vendita per
guadagno). Qualcosa può essere di pubblico dominio o no - non c'è via
di mezzo. Tali licenze non hanno significato e facilmente quelle
condizioni extra non avranno voce in tribunale.
</UL>
|
