it_IT/process/license-rules.rst

10 Regole per licenziare il kernel Linux
16 aggiunge eccezione per le chiamate di sistema come descritto in
20 debba essere licenziato per far si che sia chiaro e non ambiguo. Questo non
35 per esempio con una delle varianti compatibili della GPL e alternativamente con
38 I file d'intestazione per l'API verso lo spazio utente (UAPI) descrivono
39 le interfacce usate dai programmi, e per questo sono un caso speciale.
41 confine oltre il quale non si estendono i requisiti della GPL per quei
42 programmi che le usano per comunicare con il kernel.  Dato che i file
47 Il modo più comune per indicare la licenza dei file sorgenti è quello di
49 file.  Per via della formattazione, dei refusi, eccetera, questi blocchi di
50 testo sono difficili da identificare dagli strumenti usati per verificare il
60 rispettivi gruppi legali. Per maggiori informazioni, consultate
75    possibile di un file che possa contenere commenti.  Per la maggior parte
77    come prima riga '#!PATH_TO_INTERPRETER'.  Per questi script l'identificativo
95    principale per i commenti, allora dev'essere usato il meccanismo accettato
96    dal programma.  Questo è il motivo per cui si ha "/\* \*/" nei file
108    combinazione di due identificatori SPDX separati da "WITH" per i casi
113    Gli identificativi di licenza per licenze come la [L]GPL che si avvalgono
115    per indicare l'opzione 'o successive'.::
121    licenza.  Per esempio, la UAPI del kernel linux usa l'espressione::
133    corrispondenti file d'eccezione. Per maggiori dettagli consultate
137    licenza e solo una dev'essere scelta.  Per esempio, alcuni file dtsi sono
142    Esempi dal kernel di espressioni per file licenziati con doppia licenza
153    si applicano ad un file. Per esempio, quando il codice viene preso da
154    un altro progetto il quale da i permessi per aggiungerlo nel kernel ma
200      all'interno del progetto per far riferimento alla licenza in questione.
201      Solitamente, questo è un unico identificatore valido, ma per esempio le
212      Testo in formato libero per dare suggerimenti agli utenti. Il testo deve
254    Questo tipo di licenze dovrebbero essere usate solo per codice già esistente
277    I metatag necessari per le 'altre' ('other') licenze sono gli stessi
278    di usati per le `Licenze raccomandate`_.
297 3. Solo per doppie licenze
299    Queste licenze dovrebbero essere usate solamente per codice licenziato in
324    I requisiti per le 'altre' ('*other*') licenze sono identici a quelli per le
354    `Metatag per le eccezioni`_.
360    Contiene la descrizione dell'eccezione per le chiamate di sistema Linux
362    per i file d'intestazione per la UAPI.  Per esempio
369    sorgente è marchiato con questa eccezione. Questo è necessario per creare
372    _`Metatag per le eccezioni`:
393      Testo in formato libero per dare suggerimenti agli utenti. Il testo deve
433 Per ogni identificatore di licenza SPDX e per le eccezioni dev'esserci un file
434 nella sotto-cartella LICENSES.  Questo è necessario per permettere agli
435 strumenti di effettuare verifiche (come checkpatch.pl), per avere le licenze
436 disponibili per la lettura e per estrarre i diritti dai sorgenti, così come
437 raccomandato da diverse organizzazioni FOSS, per esempio l'`iniziativa FSFE
450    utente, per capire se il modulo è libero o proprietario.
452    Le stringe di licenza valide per MODULE_LICENSE() sono:
461     "GPL v2"			  Stesso significato di "GPL". Esiste per
464     "GPL and additional rights"   Questa è una variante che esiste per motivi
467 				  della licenza GPL v2 e quella MIT. Per favore
468 				  non utilizzatela per codice nuovo.
470     "Dual MIT/GPL"		  Questo è il modo corretto per esprimere il
489 				  proprietaria. Questa stringa è solo per i
491 				  essere usata per quelli che risiedono nei