1 .. include:: ../disclaimer-ita.rst 1 .. include:: ../disclaimer-ita.rst
2 2
3 :Original: :ref:`Documentation/process/1.Intro 3 :Original: :ref:`Documentation/process/1.Intro.rst <development_process_intro>`
4 :Translator: Alessia Mantegazza <amantegazza@va 4 :Translator: Alessia Mantegazza <amantegazza@vaga.pv.it>
5 5
6 .. _it_development_intro: 6 .. _it_development_intro:
7 7
8 Introduzione 8 Introduzione
9 ============ 9 ============
10 10
11 Riepilogo generale 11 Riepilogo generale
12 ------------------ 12 ------------------
13 13
14 Il resto di questa sezione riguarda il process 14 Il resto di questa sezione riguarda il processo di sviluppo del kernel e
15 quella sorta di frustrazione che gli sviluppat 15 quella sorta di frustrazione che gli sviluppatori e i loro datori di lavoro
16 potrebbero dover affrontare. Ci sono molte ra 16 potrebbero dover affrontare. Ci sono molte ragioni per le quali del codice
17 per il kernel debba essere incorporato nel ker 17 per il kernel debba essere incorporato nel kernel ufficiale, fra le quali:
18 disponibilità immediata agli utilizzatori, su 18 disponibilità immediata agli utilizzatori, supporto della comunità in
19 differenti modalità , e la capacità di influe 19 differenti modalità , e la capacità di influenzare la direzione dello sviluppo
20 del kernel. 20 del kernel.
21 Il codice che contribuisce al kernel Linux dev 21 Il codice che contribuisce al kernel Linux deve essere reso disponibile sotto
22 una licenza GPL-compatibile. 22 una licenza GPL-compatibile.
23 23
24 La sezione :ref:`it_development_process` intro 24 La sezione :ref:`it_development_process` introduce il processo di sviluppo,
25 il ciclo di rilascio del kernel, ed i meccanis 25 il ciclo di rilascio del kernel, ed i meccanismi della finestra
26 d'incorporazione. Il capitolo copre le varie 26 d'incorporazione. Il capitolo copre le varie fasi di una modifica: sviluppo,
27 revisione e ciclo d'incorporazione. Ci sono al 27 revisione e ciclo d'incorporazione. Ci sono alcuni dibattiti su strumenti e
28 liste di discussione. Gli sviluppatori che son 28 liste di discussione. Gli sviluppatori che sono in attesa di poter sviluppare
29 qualcosa per il kernel sono invitati ad indivi 29 qualcosa per il kernel sono invitati ad individuare e sistemare bachi come
30 esercizio iniziale. 30 esercizio iniziale.
31 31
32 La sezione :ref:`it_development_early_stage` c 32 La sezione :ref:`it_development_early_stage` copre i primi stadi della
33 pianificazione di un progetto di sviluppo, con 33 pianificazione di un progetto di sviluppo, con particolare enfasi sul
34 coinvolgimento della comunità , il prima possi 34 coinvolgimento della comunità , il prima possibile.
35 35
36 La sezione :ref:`it_development_coding` riguar 36 La sezione :ref:`it_development_coding` riguarda il processo di scrittura
37 del codice. Qui, sono esposte le diverse insid 37 del codice. Qui, sono esposte le diverse insidie che sono state già affrontate
38 da altri sviluppatori. Il capitolo copre anch 38 da altri sviluppatori. Il capitolo copre anche alcuni dei requisiti per le
39 modifiche, ed esiste un'introduzione ad alcuni 39 modifiche, ed esiste un'introduzione ad alcuni strumenti che possono aiutarvi
40 nell'assicurarvi che le modifiche per il kerne 40 nell'assicurarvi che le modifiche per il kernel siano corrette.
41 41
42 La sezione :ref:`it_development_posting` parla 42 La sezione :ref:`it_development_posting` parla del processo di pubblicazione
43 delle modifiche per la revisione. Per essere p 43 delle modifiche per la revisione. Per essere prese in considerazione dalla
44 comunità di sviluppo, le modifiche devono ess 44 comunità di sviluppo, le modifiche devono essere propriamente formattate ed
45 esposte, e devono essere inviate nel posto giu 45 esposte, e devono essere inviate nel posto giusto. Seguire i consigli presenti
46 in questa sezione dovrebbe essere d'aiuto nell 46 in questa sezione dovrebbe essere d'aiuto nell'assicurare la migliore
47 accoglienza possibile del vostro lavoro. 47 accoglienza possibile del vostro lavoro.
48 48
49 La sezione :ref:`it_development_followthrough` 49 La sezione :ref:`it_development_followthrough` copre ciò che accade dopo
50 la pubblicazione delle modifiche; a questo pun 50 la pubblicazione delle modifiche; a questo punto il lavoro è lontano
51 dall'essere concluso. Lavorare con i revisori 51 dall'essere concluso. Lavorare con i revisori è una parte cruciale del
52 processo di sviluppo; questa sezione offre una 52 processo di sviluppo; questa sezione offre una serie di consigli su come
53 evitare problemi in questa importante fase. G 53 evitare problemi in questa importante fase. Gli sviluppatori sono diffidenti
54 nell'affermare che il lavoro è concluso quand 54 nell'affermare che il lavoro è concluso quando una modifica è incorporata nei
55 sorgenti principali. 55 sorgenti principali.
56 56
57 La sezione :ref:`it_development_advancedtopics 57 La sezione :ref:`it_development_advancedtopics` introduce un paio di argomenti
58 "avanzati": gestire le modifiche con git e con 58 "avanzati": gestire le modifiche con git e controllare le modifiche pubblicate
59 da altri. 59 da altri.
60 60
61 La sezione :ref:`it_development_conclusion` ch 61 La sezione :ref:`it_development_conclusion` chiude il documento con dei
62 riferimenti ad altre fonti che forniscono ulte 62 riferimenti ad altre fonti che forniscono ulteriori informazioni sullo sviluppo
63 del kernel. 63 del kernel.
64 64
65 Di cosa parla questo documento 65 Di cosa parla questo documento
66 ------------------------------ 66 ------------------------------
67 67
68 Il kernel Linux, ha oltre 8 milioni di linee d 68 Il kernel Linux, ha oltre 8 milioni di linee di codice e ben oltre 1000
69 contributori ad ogni rilascio; è uno dei più 69 contributori ad ogni rilascio; è uno dei più vasti e più attivi software
70 liberi progettati mai esistiti. Sin dal sul m 70 liberi progettati mai esistiti. Sin dal sul modesto inizio nel 1991,
71 questo kernel si è evoluto nel miglior compon 71 questo kernel si è evoluto nel miglior componente per sistemi operativi
72 che fanno funzionare piccoli riproduttori musi 72 che fanno funzionare piccoli riproduttori musicali, PC, grandi super computer
73 e tutte le altre tipologie di sistemi fra ques 73 e tutte le altre tipologie di sistemi fra questi estremi. È una soluzione
74 robusta, efficiente ed adattabile a praticamen 74 robusta, efficiente ed adattabile a praticamente qualsiasi situazione.
75 75
76 Con la crescita di Linux è arrivato anche un 76 Con la crescita di Linux è arrivato anche un aumento di sviluppatori
77 (ed aziende) desiderosi di partecipare a quest 77 (ed aziende) desiderosi di partecipare a questo sviluppo. I produttori di
78 hardware vogliono assicurarsi che il loro prod 78 hardware vogliono assicurarsi che il loro prodotti siano supportati da Linux,
79 rendendo questi prodotti attrattivi agli utent 79 rendendo questi prodotti attrattivi agli utenti Linux. I produttori di
80 sistemi integrati, che usano Linux come compon 80 sistemi integrati, che usano Linux come componente di un prodotto integrato,
81 vogliono che Linux sia capace ed adeguato agli 81 vogliono che Linux sia capace ed adeguato agli obiettivi ed il più possibile
82 alla mano. Fornitori ed altri produttori di so 82 alla mano. Fornitori ed altri produttori di software che basano i propri
83 prodotti su Linux hanno un chiaro interesse ve 83 prodotti su Linux hanno un chiaro interesse verso capacità , prestazioni ed
84 affidabilità del kernel Linux. E gli utenti 84 affidabilità del kernel Linux. E gli utenti finali, anche, spesso vorrebbero
85 cambiare Linux per renderlo più aderente alle 85 cambiare Linux per renderlo più aderente alle proprie necessità .
86 86
87 Una delle caratteristiche più coinvolgenti di 87 Una delle caratteristiche più coinvolgenti di Linux è quella dell'accessibilitÃ
88 per gli sviluppatori; chiunque con le capacità 88 per gli sviluppatori; chiunque con le capacità richieste può migliorare
89 Linux ed influenzarne la direzione di sviluppo 89 Linux ed influenzarne la direzione di sviluppo. Prodotti non open-source non
90 possono offrire questo tipo di apertura, che à 90 possono offrire questo tipo di apertura, che è una caratteristica del software
91 libero. Ma, anzi, il kernel è persino più a 91 libero. Ma, anzi, il kernel è persino più aperto rispetto a molti altri
92 progetti di software libero. Un classico cicl 92 progetti di software libero. Un classico ciclo di sviluppo trimestrale può
93 coinvolgere 1000 sviluppatori che lavorano per 93 coinvolgere 1000 sviluppatori che lavorano per più di 100 differenti aziende
94 (o per nessuna azienda). 94 (o per nessuna azienda).
95 95
96 Lavorare con la comunità di sviluppo del kern 96 Lavorare con la comunità di sviluppo del kernel non è particolarmente
97 difficile. Ma, ciononostante, diversi potenzi 97 difficile. Ma, ciononostante, diversi potenziali contributori hanno trovato
98 delle difficoltà quando hanno cercato di lavo 98 delle difficoltà quando hanno cercato di lavorare sul kernel. La comunità del
99 kernel utilizza un proprio modo di operare che 99 kernel utilizza un proprio modo di operare che gli permette di funzionare
100 agevolmente (e genera un prodotto di alta qual 100 agevolmente (e genera un prodotto di alta qualità ) in un ambiente dove migliaia
101 di stringhe di codice sono modificate ogni gio 101 di stringhe di codice sono modificate ogni giorni. Quindi non deve sorprendere
102 che il processo di sviluppo del kernel differi 102 che il processo di sviluppo del kernel differisca notevolmente dai metodi di
103 sviluppo privati. 103 sviluppo privati.
104 104
105 Il processo di sviluppo del Kernel può, dall' 105 Il processo di sviluppo del Kernel può, dall'altro lato, risultare
106 intimidatorio e strano ai nuovi sviluppatori, 106 intimidatorio e strano ai nuovi sviluppatori, ma ha dietro di se buone ragioni
107 e solide esperienze. Uno sviluppatore che non 107 e solide esperienze. Uno sviluppatore che non comprende i modi della comunitÃ
108 del kernel (o, peggio, che cerchi di aggirarli 108 del kernel (o, peggio, che cerchi di aggirarli o violarli) avrà un'esperienza
109 deludente nel proprio bagaglio. La comunità 109 deludente nel proprio bagaglio. La comunità di sviluppo, sebbene sia utile
110 a coloro che cercano di imparare, ha poco temp 110 a coloro che cercano di imparare, ha poco tempo da dedicare a coloro che non
111 ascoltano o coloro che non sono interessati al 111 ascoltano o coloro che non sono interessati al processo di sviluppo.
112 112
113 Si spera che coloro che leggono questo documen 113 Si spera che coloro che leggono questo documento saranno in grado di evitare
114 queste esperienze spiacevoli. C'è molto mat 114 queste esperienze spiacevoli. C'è molto materiale qui, ma lo sforzo della
115 lettura sarà ripagato in breve tempo. La com 115 lettura sarà ripagato in breve tempo. La comunità di sviluppo ha sempre
116 bisogno di sviluppatori che vogliano aiutare a 116 bisogno di sviluppatori che vogliano aiutare a rendere il kernel migliore;
117 il testo seguente potrebbe esservi d'aiuto - o 117 il testo seguente potrebbe esservi d'aiuto - o essere d'aiuto ai vostri
118 collaboratori- per entrare a far parte della n 118 collaboratori- per entrare a far parte della nostra comunità .
119 119
120 Crediti 120 Crediti
121 ------- 121 -------
122 122
123 Questo documento è stato scritto da Jonathan 123 Questo documento è stato scritto da Jonathan Corbet, corbet@lwn.net.
124 È stato migliorato da Johannes Berg, James Be 124 È stato migliorato da Johannes Berg, James Berry, Alex Chiang, Roland
125 Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, 125 Dreier, Randy Dunlap, Jake Edge, Jiri Kosina, Matt Mackall, Arthur Marsh,
126 Amanda McPherson, Andrew Morton, Andrew Price, 126 Amanda McPherson, Andrew Morton, Andrew Price, Tsugikazu Shibata e Jochen Voß.
127 127
128 Questo lavoro è stato supportato dalla Linux 128 Questo lavoro è stato supportato dalla Linux Foundation; un ringraziamento
129 speciale ad Amanda McPherson, che ha visto il 129 speciale ad Amanda McPherson, che ha visto il valore di questo lavoro e lo ha
130 reso possibile. 130 reso possibile.
131 131
132 L'importanza d'avere il codice nei sorgenti pr 132 L'importanza d'avere il codice nei sorgenti principali
133 ---------------------------------------------- 133 ------------------------------------------------------
134 134
135 Alcune aziende e sviluppatori ogni tanto si do 135 Alcune aziende e sviluppatori ogni tanto si domandano perché dovrebbero
136 preoccuparsi di apprendere come lavorare con l 136 preoccuparsi di apprendere come lavorare con la comunità del kernel e di
137 inserire il loro codice nel ramo di sviluppo p 137 inserire il loro codice nel ramo di sviluppo principale (per ramo principale
138 s'intende quello mantenuto da Linus Torvalds e 138 s'intende quello mantenuto da Linus Torvalds e usato come base dai
139 distributori Linux). Nel breve termine, contri 139 distributori Linux). Nel breve termine, contribuire al codice può sembrare
140 un costo inutile; può sembra più facile tene 140 un costo inutile; può sembra più facile tenere separato il proprio codice e
141 supportare direttamente i suoi utilizzatori. L 141 supportare direttamente i suoi utilizzatori. La verità è che il tenere il
142 codice separato ("fuori dai sorgenti", *"out-o 142 codice separato ("fuori dai sorgenti", *"out-of-tree"*) è un falso risparmio.
143 143
144 Per dimostrare i costi di un codice "fuori dai 144 Per dimostrare i costi di un codice "fuori dai sorgenti", eccovi
145 alcuni aspetti rilevanti del processo di svilu 145 alcuni aspetti rilevanti del processo di sviluppo kernel; la maggior parte
146 di essi saranno approfonditi dettagliatamente 146 di essi saranno approfonditi dettagliatamente più avanti in questo documento.
147 Considerate: 147 Considerate:
148 148
149 - Il codice che è stato inserito nel ramo pri 149 - Il codice che è stato inserito nel ramo principale del kernel è disponibile
150 a tutti gli utilizzatori Linux. Sarà automa 150 a tutti gli utilizzatori Linux. Sarà automaticamente presente in tutte le
151 distribuzioni che lo consentono. Non c'è bi 151 distribuzioni che lo consentono. Non c'è bisogno di: driver per dischi,
152 scaricare file, o della scocciatura del dove 152 scaricare file, o della scocciatura del dover supportare diverse versioni di
153 diverse distribuzioni; funziona già tutto, 153 diverse distribuzioni; funziona già tutto, per gli sviluppatori e per gli
154 utilizzatori. L'inserimento nel ramo princip 154 utilizzatori. L'inserimento nel ramo principale risolve un gran numero di
155 problemi di distribuzione e di supporto. 155 problemi di distribuzione e di supporto.
156 156
157 - Nonostante gli sviluppatori kernel si sforzi 157 - Nonostante gli sviluppatori kernel si sforzino di tenere stabile
158 l'interfaccia dello spazio utente, quella in 158 l'interfaccia dello spazio utente, quella interna al kernel è in continuo
159 cambiamento. La mancanza di un'interfaccia i 159 cambiamento. La mancanza di un'interfaccia interna è deliberatamente una
160 decisione di progettazione; ciò permette ch 160 decisione di progettazione; ciò permette che i miglioramenti fondamentali
161 vengano fatti in un qualsiasi momento e che 161 vengano fatti in un qualsiasi momento e che risultino fatti con un codice di
162 alta qualità . Ma una delle conseguenze di q 162 alta qualità . Ma una delle conseguenze di questa politica è che qualsiasi
163 codice "fuori dai sorgenti" richiede costant 163 codice "fuori dai sorgenti" richiede costante manutenzione per renderlo
164 funzionante coi kernel più recenti. Tenere 164 funzionante coi kernel più recenti. Tenere un codice "fuori dai sorgenti"
165 richiede una mole di lavoro significativa so 165 richiede una mole di lavoro significativa solo per farlo funzionare.
166 166
167 Invece, il codice che si trova nel ramo prin 167 Invece, il codice che si trova nel ramo principale non necessita di questo
168 tipo di lavoro poiché ad ogni sviluppatore 168 tipo di lavoro poiché ad ogni sviluppatore che faccia una modifica alle
169 interfacce viene richiesto di sistemare anch 169 interfacce viene richiesto di sistemare anche il codice che utilizza
170 quell'interfaccia. Quindi, il codice che è 170 quell'interfaccia. Quindi, il codice che è stato inserito nel ramo principale
171 ha dei costi di mantenimento significativame 171 ha dei costi di mantenimento significativamente più bassi.
172 172
173 - Oltre a ciò, spesso il codice che è all'in 173 - Oltre a ciò, spesso il codice che è all'interno del kernel sarà migliorato da
174 altri sviluppatori. Dare pieni poteri alla v 174 altri sviluppatori. Dare pieni poteri alla vostra comunità di utenti e ai
175 clienti può portare a sorprendenti risultat 175 clienti può portare a sorprendenti risultati che migliorano i vostri
176 prodotti. 176 prodotti.
177 177
178 - Il codice kernel è soggetto a revisioni, si 178 - Il codice kernel è soggetto a revisioni, sia prima che dopo l'inserimento
179 nel ramo principale. Non importa quanto for 179 nel ramo principale. Non importa quanto forti fossero le abilità dello
180 sviluppatore originale, il processo di revis 180 sviluppatore originale, il processo di revisione troverà il modo di migliore
181 il codice. Spesso la revisione trova bachi 181 il codice. Spesso la revisione trova bachi importanti e problemi di
182 sicurezza. Questo è particolarmente vero p 182 sicurezza. Questo è particolarmente vero per il codice che è stato
183 sviluppato in un ambiente chiuso; tale codic 183 sviluppato in un ambiente chiuso; tale codice ottiene un forte beneficio
184 dalle revisioni provenienti da sviluppatori 184 dalle revisioni provenienti da sviluppatori esteri. Il codice
185 "fuori dai sorgenti", invece, è un codice d 185 "fuori dai sorgenti", invece, è un codice di bassa qualità .
186 186
187 - La partecipazione al processo di sviluppo co 187 - La partecipazione al processo di sviluppo costituisce la vostra via per
188 influenzare la direzione di sviluppo del ker 188 influenzare la direzione di sviluppo del kernel. Gli utilizzatori che
189 "reclamano da bordo campo" sono ascoltati, m 189 "reclamano da bordo campo" sono ascoltati, ma gli sviluppatori attivi
190 hanno una voce più forte - e la capacità d 190 hanno una voce più forte - e la capacità di implementare modifiche che
191 renderanno il kernel più funzionale alle lo 191 renderanno il kernel più funzionale alle loro necessità .
192 192
193 - Quando il codice è gestito separatamente, e 193 - Quando il codice è gestito separatamente, esiste sempre la possibilità che
194 terze parti contribuiscano con una different 194 terze parti contribuiscano con una differente implementazione che fornisce
195 le stesse funzionalità . Se dovesse accader 195 le stesse funzionalità . Se dovesse accadere, l'inserimento del codice
196 diventerà molto più difficile - fino all'i 196 diventerà molto più difficile - fino all'impossibilità . Poi, dovrete far
197 fronte a delle alternative poco piacevoli, c 197 fronte a delle alternative poco piacevoli, come: (1) mantenere un elemento
198 non standard "fuori dai sorgenti" per un tem 198 non standard "fuori dai sorgenti" per un tempo indefinito, o (2) abbandonare
199 il codice e far migrare i vostri utenti alla 199 il codice e far migrare i vostri utenti alla versione "nei sorgenti".
200 200
201 - Contribuire al codice è l'azione fondamenta 201 - Contribuire al codice è l'azione fondamentale che fa funzionare tutto il
202 processo. Contribuendo attraverso il vostro 202 processo. Contribuendo attraverso il vostro codice potete aggiungere nuove
203 funzioni al kernel e fornire competenze ed e 203 funzioni al kernel e fornire competenze ed esempi che saranno utili ad
204 altri sviluppatori. Se avete sviluppato del 204 altri sviluppatori. Se avete sviluppato del codice Linux (o state pensando
205 di farlo), avete chiaramente interesse nel f 205 di farlo), avete chiaramente interesse nel far proseguire il successo di
206 questa piattaforma. Contribuire al codice è 206 questa piattaforma. Contribuire al codice è une delle migliori vie per
207 aiutarne il successo. 207 aiutarne il successo.
208 208
209 Il ragionamento sopra citato si applica ad ogn 209 Il ragionamento sopra citato si applica ad ogni codice "fuori dai sorgenti"
210 dal kernel, incluso il codice proprietario dis 210 dal kernel, incluso il codice proprietario distribuito solamente in formato
211 binario. Ci sono, comunque, dei fattori aggiu 211 binario. Ci sono, comunque, dei fattori aggiuntivi che dovrebbero essere
212 tenuti in conto prima di prendere in considera 212 tenuti in conto prima di prendere in considerazione qualsiasi tipo di
213 distribuzione binaria di codice kernel. Questo 213 distribuzione binaria di codice kernel. Questo include che:
214 214
215 - Le questioni legali legate alla distribuzion 215 - Le questioni legali legate alla distribuzione di moduli kernel proprietari
216 sono molto nebbiose; parecchi detentori di c 216 sono molto nebbiose; parecchi detentori di copyright sul kernel credono che
217 molti moduli binari siano prodotti derivati 217 molti moduli binari siano prodotti derivati del kernel e che, come risultato,
218 la loro diffusione sia una violazione della 218 la loro diffusione sia una violazione della licenza generale di GNU (della
219 quale si parlerà più avanti). L'autore qu 219 quale si parlerà più avanti). L'autore qui non è un avvocato, e
220 niente in questo documento può essere consi 220 niente in questo documento può essere considerato come un consiglio legale.
221 Il vero stato legale dei moduli proprietari 221 Il vero stato legale dei moduli proprietari può essere determinato
222 esclusivamente da un giudice. Ma l'incertezz 222 esclusivamente da un giudice. Ma l'incertezza che perseguita quei moduli
223 è lì comunque. 223 è lì comunque.
224 224
225 - I moduli binari aumentano di molto la diffic 225 - I moduli binari aumentano di molto la difficoltà di fare debugging del
226 kernel, al punto che la maggior parte degli 226 kernel, al punto che la maggior parte degli sviluppatori del kernel non
227 vorranno nemmeno tentare. Quindi la diffusi 227 vorranno nemmeno tentare. Quindi la diffusione di moduli esclusivamente
228 binari renderà difficile ai vostri utilizza 228 binari renderà difficile ai vostri utilizzatori trovare un supporto dalla
229 comunità . 229 comunità .
230 230
231 - Il supporto è anche difficile per i distrib 231 - Il supporto è anche difficile per i distributori di moduli binari che devono
232 fornire una versione del modulo per ogni dis 232 fornire una versione del modulo per ogni distribuzione e per ogni versione
233 del kernel che vogliono supportate. Per for 233 del kernel che vogliono supportate. Per fornire una copertura ragionevole e
234 comprensiva, può essere richiesto di produr 234 comprensiva, può essere richiesto di produrre dozzine di singoli moduli.
235 E inoltre i vostri utilizzatori dovranno agg 235 E inoltre i vostri utilizzatori dovranno aggiornare il vostro modulo
236 separatamente ogni volta che aggiornano il l 236 separatamente ogni volta che aggiornano il loro kernel.
237 237
238 - Tutto ciò che è stato detto prima riguardo 238 - Tutto ciò che è stato detto prima riguardo alla revisione del codice si
239 applica doppiamente al codice proprietario. 239 applica doppiamente al codice proprietario. Dato che questo codice non è
240 del tutto disponibile, non può essere revis 240 del tutto disponibile, non può essere revisionato dalla comunità e avrà ,
241 senza dubbio, seri problemi. 241 senza dubbio, seri problemi.
242 242
243 I produttori di sistemi integrati, in particol 243 I produttori di sistemi integrati, in particolare, potrebbero esser tentati
244 dall'evitare molto di ciò che è stato detto 244 dall'evitare molto di ciò che è stato detto in questa sezione, credendo che
245 stiano distribuendo un prodotto finito che uti 245 stiano distribuendo un prodotto finito che utilizza una versione del kernel
246 immutabile e che non richiede un ulteriore svi 246 immutabile e che non richiede un ulteriore sviluppo dopo il rilascio. Questa
247 idea non comprende il valore di una vasta revi 247 idea non comprende il valore di una vasta revisione del codice e il valore
248 del permettere ai propri utenti di aggiungere 248 del permettere ai propri utenti di aggiungere funzionalità al vostro prodotto.
249 Ma anche questi prodotti, hanno una vita comme 249 Ma anche questi prodotti, hanno una vita commerciale limitata, dopo la quale
250 deve essere rilasciata una nuova versione. A 250 deve essere rilasciata una nuova versione. A quel punto, i produttori il cui
251 codice è nel ramo principale di sviluppo avra 251 codice è nel ramo principale di sviluppo avranno un codice ben mantenuto e
252 saranno in una posizione migliore per ottenere 252 saranno in una posizione migliore per ottenere velocemente un nuovo prodotto
253 pronto per essere distribuito. 253 pronto per essere distribuito.
254 254
255 255
256 Licenza 256 Licenza
257 ------- 257 -------
258 258
259 IL codice Linux utilizza diverse licenze, ma i 259 IL codice Linux utilizza diverse licenze, ma il codice completo deve essere
260 compatibile con la seconda versione della lice 260 compatibile con la seconda versione della licenza GNU General Public License
261 (GPLv2), che è la licenza che copre la distri 261 (GPLv2), che è la licenza che copre la distribuzione del kernel.
262 Nella pratica, ciò significa che tutti i cont 262 Nella pratica, ciò significa che tutti i contributi al codice sono coperti
263 anche'essi dalla GPLv2 (con, opzionalmente, un 263 anche'essi dalla GPLv2 (con, opzionalmente, una dicitura che permette la
264 possibilità di distribuirlo con licenze più 264 possibilità di distribuirlo con licenze più recenti di GPL) o dalla licenza
265 three-clause BSD. Qualsiasi contributo che no 265 three-clause BSD. Qualsiasi contributo che non è coperto da una licenza
266 compatibile non verrà accettata nel kernel. 266 compatibile non verrà accettata nel kernel.
267 267
268 Per il codice sottomesso al kernel non è nece 268 Per il codice sottomesso al kernel non è necessario (o richiesto) la
269 concessione del Copyright. Tutto il codice in 269 concessione del Copyright. Tutto il codice inserito nel ramo principale del
270 kernel conserva la sua proprietà originale; n 270 kernel conserva la sua proprietà originale; ne risulta che ora il kernel abbia
271 migliaia di proprietari. 271 migliaia di proprietari.
272 272
273 Una conseguenza di questa organizzazione della 273 Una conseguenza di questa organizzazione della proprietà è che qualsiasi
274 tentativo di modifica della licenza del kernel 274 tentativo di modifica della licenza del kernel è destinata ad un quasi sicuro
275 fallimento. Esistono alcuni scenari pratici n 275 fallimento. Esistono alcuni scenari pratici nei quali il consenso di tutti
276 i detentori di copyright può essere ottenuto 276 i detentori di copyright può essere ottenuto (o il loro codice verrà rimosso
277 dal kernel). Quindi, in sostanza, non esiste 277 dal kernel). Quindi, in sostanza, non esiste la possibilità che si giunga ad
278 una versione 3 della licenza GPL nel prossimo 278 una versione 3 della licenza GPL nel prossimo futuro.
279 279
280 È imperativo che tutto il codice che contribu 280 È imperativo che tutto il codice che contribuisce al kernel sia legittimamente
281 software libero. Per questa ragione, un codic 281 software libero. Per questa ragione, un codice proveniente da un contributore
282 anonimo (o sotto pseudonimo) non verrà accett 282 anonimo (o sotto pseudonimo) non verrà accettato. È richiesto a tutti i
283 contributori di firmare il proprio codice, att 283 contributori di firmare il proprio codice, attestando così che quest'ultimo
284 può essere distribuito insieme al kernel sott 284 può essere distribuito insieme al kernel sotto la licenza GPL. Il codice che
285 non è stato licenziato come software libero d 285 non è stato licenziato come software libero dal proprio creatore, o che
286 potrebbe creare problemi di copyright per il k 286 potrebbe creare problemi di copyright per il kernel (come il codice derivante
287 da processi di ingegneria inversa senza le opp 287 da processi di ingegneria inversa senza le opportune tutele), non può essere
288 diffuso. 288 diffuso.
289 289
290 Domande relative a questioni legate al copyrig 290 Domande relative a questioni legate al copyright sono frequenti nelle liste
291 di discussione dedicate allo sviluppo di Linux 291 di discussione dedicate allo sviluppo di Linux. Tali quesiti, normalmente,
292 non riceveranno alcuna risposta, ma una cosa d 292 non riceveranno alcuna risposta, ma una cosa deve essere tenuta presente:
293 le persone che risponderanno a quelle domande 293 le persone che risponderanno a quelle domande non sono avvocati e non possono
294 fornire supporti legali. Se avete questioni l 294 fornire supporti legali. Se avete questioni legali relative ai sorgenti
295 del codice Linux, non esiste alternativa che q 295 del codice Linux, non esiste alternativa che quella di parlare con un
296 avvocato esperto nel settore. Fare affidament 296 avvocato esperto nel settore. Fare affidamento sulle risposte ottenute da
297 una lista di discussione tecnica è rischioso. 297 una lista di discussione tecnica è rischioso.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.