Come mantengo la conformità con GPL quando forking su Github?

Naviga le tue risposte
13

Recentemente ho biforcato un progetto su Github e ho apportato alcune modifiche ad esso, reinserito nel repository biforcuto e chiesto allo sviluppatore originale di apportare le modifiche. (Considero che questo è il modo preferito di contribuire a Github.) Il progetto è concesso in licenza sotto GPLv3 .

Sono l'autore e il detentore del copyright delle modifiche apportate al codice. Ho anche il permesso di pubblicare il codice modificato (cioè la combinazione del codice originale e delle mie modifiche - che ho fatto spingendo le modifiche nella mia forchetta) a condizione che rispetti la licenza impostata dall'autore originale.

Ora ho trovato il seguente requisito in GPL.

The work must carry prominent notices stating that you modified it, and giving a relevant date.

Sembra che sia necessario un po 'di lavoro oltre l'effettiva codifica prima che sia legalmente autorizzato a trasmettere le mie modifiche a Github. Cosa comporta questo lavoro? Come ottemperare al requisito sopra riportato? (Aggiungo ulteriori avvisi di copyright ai file sorgente modificati? Creo file dei contributori e aggiungo a me stessi? O è il fatto che i commit indicano la mia proprietà sufficiente?) Ci sono ulteriori insidie quando forking un progetto protetto da GPL?

    
posta avakar 25.04.2012 - 16:28
fonte

1 risposta

2

Questa riga è intesa come pertinente alle opere derivate che vengono mantenute e spedite separatamente dal master. In tal caso, è necessario conservare questi record (operazione eseguita automaticamente dal controllo del codice sorgente)

Ciò che hai fatto tuttavia non è un lavoro derivato. Hai commesso le tue modifiche e sei stato riportato al ramo principale. Le tue modifiche ora fanno parte del progetto originale.

Inoltre, l'utilizzo del controllo del codice sorgente ( un archivio pubblico ) significa che rispetterà sempre questo requisito.

C'è il problema di come ogni persona possa definire "prominente". Per gli sviluppatori, il controllo del codice sorgente (/ + issue tracker) è un modo prominente di visualizzare le modifiche, tuttavia se si sta mantenendo un lavoro derivato, si consiglia di mantenere un elenco di modifiche sostanziali in un formato non tecnico.

    
risposta data 25.04.2012 - 16:41
fonte

Leggi altre domande sui tag

Esistono sistemi di compilazione che incorporano i tempi attesi relativi alle attività nella pianificazione? Un modello decente di branching git per prodotti che dovrebbe accompagnare la versione di un altro prodotto di terze parti (e pro e contro di una proposta)