{"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 il trasferimento obbligatorio dei diritti di codice al Fondo SPO","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Gli sviluppatori della libreria di sistema GNU C Library (glibc) hanno apportato modifiche alle regole di accettazione delle modifiche e al trasferimento dei diritti d'autore, annullando il trasferimento obbligatorio dei diritti patrimoniali sul codice alla Fondazione SPI. In analogia con le modifiche precedentemente apportate al progetto GCC, la firma del CLA con la Fondazione SPI in Glibc \u00e8 stata spostata nella categoria delle operazioni facoltative, effettuate a discrezione dello sviluppatore. Le modifiche delle regole, che consentono l'accettazione di patch senza trasferire i diritti alla Fondazione SPI, entreranno in vigore il 2 agosto e interesseranno tutti i rami di sviluppo disponibili di Glibc, ad eccezione del codice utilizzato tramite Gnulib in collaborazione con altri progetti GNU. <\/p>\n
Oltre a trasferire i diritti di propriet\u00e0 al Fondo SPO, \u00e8 stata data ai programmatori la possibilit\u00e0 di certificare il diritto di trasferire il codice al progetto Glibc attraverso il meccanismo del Developer Certificate of Origin (DCO). Ai sensi del DCO, la tracciabilit\u00e0 dell'autore avviene attraverso l'allegazione ad ogni modifica della stringa \"Signed-off-by: nome e email del programmatore\". Allegando questa firma al patch, il programmatore conferma la propria paternit\u00e0 del codice trasferito e accetta la sua distribuzione come parte del progetto o come codice sotto una licenza open source. A differenza delle azioni del progetto GCC, la decisione in Glibc non \u00e8 stata imposta dal consiglio di amministrazione, ma \u00e8 stata presa dopo un adeguato confronto con tutti i rappresentanti della comunit\u00e0. <\/p>\n
L'annullamento dell'obbligo di firmare l'accordo con la Fondazione SPI semplifica notevolmente l'inserimento di nuovi partecipanti nello sviluppo, rendendo il progetto indipendente dalle tendenze della Fondazione SPI. Se la firma del CLA da parte dei partecipanti individuali portava solo a un inutile dispendio di tempo per questioni formali, per le aziende e i dipendenti di grandi societ\u00e0, il trasferimento dei diritti alla Fondazione SPI era associato a molte complicazioni legali e approvazioni, che non sempre si concludevano con successo. <\/p>\n
L'abbandono del controllo centralizzato dei diritti sul codice conferma anche le condizioni di licenza originariamente accettate, poich\u00e9 ora per cambiare licenza \u00e8 necessario ottenere il consenso personale di ogni sviluppatore che non ha trasferito i diritti al Fondo SPO. Nel contempo, il codice Glibc continua ad essere fornito sotto la licenza \"LGPLv2.1 o versione successiva\", il che consente il passaggio a versioni pi\u00f9 recenti della LGPL senza ulteriore consenso. Poich\u00e9 i diritti sulla maggior parte del codice continuano a rimanere nelle mani del Fondo SPO, tale organizzazione continua a svolgere il ruolo di garante della distribuzione del codice Glibc esclusivamente sotto licenze copyleft open source. Ad esempio, il Fondo SPO pu\u00f2 bloccare tentativi di introdurre una licenza duale\/commerciale o il rilascio di prodotti proprietari chiusi secondo accordi separati con gli autori del codice. <\/p>\n
Tra i difetti della rinuncia alla gestione centralizzata dei diritti sul codice si evidenzia la nascita di confusione nella gestione delle questioni legate alle licenze. Se prima tutte le controversie relative alla violazione delle condizioni di licenza venivano risolte interagendo con un'unica organizzazione, ora l'esito delle violazioni, comprese quelle non intenzionali, diventa imprevedibile e richiede un accordo con ciascun singolo partecipante. A titolo di esempio, si cita la situazione con il kernel Linux, in cui singoli sviluppatori del kernel intentano cause legali, anche con lo scopo di ottenere un arricchimento personale. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"