Utilizzo di licenze diverse per diversi rami dello stesso repository
Ho un repository Git con un progetto di medie dimensioni su GitHub. Poiché ci sono alcuni componenti che dipendono dalle librerie GPL, il repository è attualmente concesso in licenza anche sotto GPL. Tuttavia, la libreria con licenza GPL viene utilizzata solo da alcuni componenti (che possono essere isolati) e il resto del progetto è perfettamente utilizzabile senza quei componenti. Pertanto, voglio concedere in licenza tutto ciò che non ha dipendenze da alcuna libreria GPL sotto la licenza MIT. Quali sono le migliori pratiche per raggiungere questo obiettivo?
La mia idea è di avere due rami diversi: un ramo contiene il codice completo ed è concesso in licenza con GPL. L'altro ramo rimuove tutte le funzionalità che dipendono dal codice GPL ed è concesso in licenza in base al MIT. È fattibile e / o comune avere licenze differenti per rami diversi dello stesso repository? In caso contrario, quali sarebbero le alternative migliori?
Potrebbe essere un problema che, tecnicamente, l'intera storia di quel nuovo ramo non GPL una volta includesse codice GPL? O va bene fintanto che tutto il codice GPL viene rimosso da quel ramo prima di aggiungere il nuovo file di licenza MIT sul ramo?
Nota che questa domanda è in qualche modo simile, ma ho la sensazione che la mia sia più interessata all'implementazione tecnica . Cioè, posso semplicemente mettere due diversi file LICENSE nella directory principale del repository, a seconda del ramo in cui ci troviamo attualmente?
Risposte
I rami Git non funzionano molto bene per mantenere diverse "edizioni" dello stesso progetto, perché non esiste un buon modo per condividere le modifiche tra i rami senza unirli completamente. Quindi, semplicemente per motivi tecnici, ti esorto a non utilizzare filiali con licenze diverse. Tali rami inoltre non sono molto rilevabili dagli utenti.
Invece, mantieni tutto il codice in un ramo principale, ma mantieni il codice con licenza diversa in cartelle diverse e rendi molto chiaro quale codice è sotto quale licenza.
La GPL non richiede che alcun codice a valle sia sotto la GPL. Richiede che qualsiasi opera derivata (nel suo insieme) sia sotto la stessa licenza GPL. Ma questo può essere soddisfatto quando tutti i componenti che hai scritto tu stesso sono sotto una licenza compatibile con GPL, come il MIT. A scanso di equivoci, potresti anche concedere una doppia licenza a tali componenti come "MIT o GPL". Ciò sarebbe importante per le licenze che non sono compatibili, ad esempio "solo Apache-2.0 o GPL-2.0".
Quindi la migliore pratica sarebbe quella di separare le parti coperte da GPL dalle parti che hai scritto completamente da solo e utilizzare la LICENZA di livello superiore per descrivere quali parti sono disponibili con quale licenza. Se vuoi farlo in modo estremamente accurato, potresti persino adottare il copyrightformato di file leggibile dalla macchina di Debian che associa i pattern glob con le licenze. Si potrebbe memorizzare il testo completo della licenza sia all'interno dello stesso file di licenza, o forse come file separati piace LICENSE.GPL.txt, LICENSE.MIT.txto nelle rispettive directory.
Dato che attualmente offri l'intero codice sotto GPL, spostare il MIT per alcune parti richiederebbe una nuova licenza . Questo è banale se sei l'unico contributore, perché tu come unico detentore del copyright puoi rilasciare licenze come preferisci. Ma se ci sono altri contributori, dovrai ottenere il loro consenso alla nuova licenza o rimuovere i loro contributi (il che può essere estremamente complicato perché generalmente richiede la riscrittura del componente a partire dall'ultimo stato prima del contributo coperto dalla GPL). Non penso sia importante che la cronologia di Git mostri quegli stessi file coperti da GPL anche dopo la nuova licenza. La vecchia licenza è ancora valida per quelle vecchie versioni, la nuova licenza è ancora valida per quelle nuove versioni.