{"id":100874,"date":"2021-07-30T10:22:40","date_gmt":"2021-07-30T08:22:40","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/proekt-glibc-otmenil-obyazatelnuyu-peredachu-prav-na-kod-fondu-spo"},"modified":"2021-07-30T10:22:40","modified_gmt":"2021-07-30T08:22:40","slug":"proekt-glibc-otmenil-obyazatelnuyu-peredachu-prav-na-kod-fondu-spo","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/proekt-glibc-otmenil-obyazatelnuyu-peredachu-prav-na-kod-fondu-spo","title":{"rendered":"Il progetto Glibc ha annullato l'obbligo di trasferimento dei diritti sul codice alla Fondazione SPI","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Gli sviluppatori della libreria di sistema GNU C Library (glibc) hanno modificato le regole per l'accettazione delle modifiche e la trasmissione dei diritti d'autore, annullando l'obbligo di trasferire al Free Software Foundation i diritti patrimoniali sul codice. In analogia con le modifiche precedentemente adottate nel progetto GCC, la firma dell'accordo CLA con la Free Software Foundation in Glibc \u00e8 diventata un'operazione facoltativa, eseguita a discrezione dello sviluppatore. Le modifiche alle regole che consentono l'accettazione di patch senza trasferimento dei diritti alla Free Software Foundation entreranno in vigore il 2 agosto e interesseranno tutti i rami di sviluppo di Glibc disponibili, ad eccezione del codice che attraverso Gnulib viene utilizzato insieme ad altri progetti GNU. <\/p>\n
Oltre al trasferimento dei diritti di propriet\u00e0, il Fondo SPO offre agli sviluppatori la possibilit\u00e0 di confermare il diritto alla cessione del codice al progetto Glibc attraverso il meccanismo del Developer Certificate of Origin (DCO). Secondo il DCO, il tracciamento dell'autore avviene tramite l'aggiunta, a ciascuna modifica, della stringa «Signed-off-by: nome e email dello sviluppatore». Allegando questa firma al patch, lo sviluppatore conferma la propria paternit\u00e0 del codice trasferito e accetta di distribuirlo come parte del progetto o come codice sotto licenza libera. A differenza delle decisioni del progetto GCC, la decisione in Glibc non \u00e8 stata imposta dall'alto dal consiglio di amministrazione, ma \u00e8 stata presa dopo un preliminare dibattito con tutti i rappresentanti della comunit\u00e0. <\/p>\n
L'annullamento dell'obbligo di firmare un accordo con il Fondo SPO semplifica notevolmente l'ingresso di nuovi partecipanti nello sviluppo e rende il progetto indipendente dalle influenze del Fondo SPO. Se la firma dell'accordo CLA da parte di partecipanti individuali comportava solo una perdita di tempo in formalit\u00e0 superflue, per le corporation e i dipendenti delle grandi aziende il trasferimento dei diritti al Fondo SPO era soggetto a molte complicazioni legali e approvazioni che non sempre avevano esito positivo. <\/p>\n
La rinuncia alla gestione centralizzata dei diritti sul codice conferma anche le condizioni di licenza originariamente accettate, poich\u00e9 ora il cambio di licenza richiede il consenso personale di ogni sviluppatore che non ha trasferito i diritti al Fondo Sviluppo Software Libero. Inoltre, il codice Glibc continua a essere distribuito con la licenza \u00abLGPLv2.1 o versione successiva\u00bb, che consente il passaggio a versioni pi\u00f9 recenti della LGPL senza ulteriori accordi. Poich\u00e9 i diritti sulla maggior parte del codice rimangono nelle mani del Fondo Sviluppo Software Libero, questa organizzazione continua a svolgere il ruolo di garante della distribuzione del codice Glibc esclusivamente sotto licenze copyleft libere. Ad esempio, il Fondo Sviluppo Software Libero pu\u00f2 bloccare tentativi di introduzione di licenze doppie\/commerciali o il rilascio di prodotti proprietari chiusi tramite accordi separati con gli autori del codice. <\/p>\n
Uno degli svantaggi dell'abbandono della gestione centralizzata dei diritti sul codice \u00e8 la confusione che pu\u00f2 sorgere nell'accordo riguardante questioni relative alle licenze. In precedenza, tutte le contestazioni per violazioni delle condizioni di licenza venivano risolte interagendo con un'unica organizzazione. Ora, l'esito delle violazioni, comprese quelle involontarie, diventa imprevedibile e richiede un accordo con ciascun partecipante. Si riporta, ad esempio, la situazione con il kernel Linux, dove singoli sviluppatori del kernel avviano cause legali, anche con l'obiettivo di ottenere un arricchimento personale. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"