Le patch software ereditano mai la licenza del progetto patchato?
Questa è una domanda successiva a una domanda precedente che includeva un malinteso sulla natura della licenza MIT / X, ed è stata qui chiarita.
Considera il progetto software dwm di Suckless . Il progetto è chiaramente concesso in licenza con la MIT / X Consortium License. Di solito è aumentato da patch del codice sorgente .
Supponiamo che Alice apporti alcune modifiche a dwm. Le modifiche potrebbero essere convenientemente distribuite come file di patch o come fork del repository originale. Supponiamo che le modifiche di Alice non alterino la licenza esistente di dwm. Il suo fork includerebbe la stessa dichiarazione di licenza del progetto originale. Allora penso che:
- I fork di Alice in dwm sono chiaramente autorizzati come MIT / X.
- Le patch di Alice, prese da sole, hanno tutti i diritti riservati.
Ne consegue che fintanto che nessun fork che include la patch di Alice è stato pubblicato da Alice , Bob (che ha biforcato dwm e incluso la patch di Alice in buona fede), potrebbe violare il copyright di Alice distribuendo la sua versione. Questo suona come un problema per la gestione del copyright tra grandi progetti: è un problema in pratica? È stata fatta qualche deduzione sul fatto che le modifiche di Alice erano chiaramente intese a patchare dwm, o è necessario fare un accordo esplicito?
Una licenza con maggiore copyleft nel progetto padre (come la GPL) garantisce che il fork di Bob sia consentito. La sezione 5 della GPLv3 afferma (la mia enfasi):
5. Conveying Modified Source Versions.
You may convey a work based on the Program,
**or the modifications to produce it from the Program**,
in the form of source code under the terms of section 4,
provided that you also meet all of these conditions:
...
Copiato dalla domanda precedente : Bart von Ingen Schenau ha scritto i seguenti dettagli rilevanti:
C'è solo una situazione in cui la "licenza" predefinita del copyright cambia se è noto che le modifiche sono intese come una patch per un altro lavoro. Cioè se le modifiche vengono offerte in una richiesta pull a un repository che ha la politica che la licenza in entrata (la licenza dei contributi) è la stessa della licenza in uscita (la licenza con cui viene offerto il repository). In quel caso, effettuando una richiesta pull, Alice ha accettato di concedere in licenza le sue modifiche sotto la licenza del repository, anche quando non è esplicitamente indicato tra le modifiche.
Dicono che GitHub è un esempio di una piattaforma con tale ToS. Mi interessa scoprire se ci sono considerazioni più generali, in assenza di qualcosa come un ToS che garantisca esplicitamente questi diritti.
Risposte
Penso di poter rispondere alla mia domanda a questo punto. I due fattori rilevanti sembrano essere l'ambito del copyleft della licenza madre e se esiste un qualche tipo di contratto di licenza del contributore.
No CLA, con una licenza genitore senza copyleft
- I fork di Alice in dwm sono chiaramente autorizzati come MIT / X.
- Le patch di Alice, prese da sole, hanno tutti i diritti riservati.
Non è vero che i fork di Alice sono concessi in licenza con MIT / X. L'avviso di licenza ottenuto dal progetto padre si applica solo al codice di quel progetto . Il nuovo codice di Alice non è concesso in licenza in base a tali modifiche, il che implica che il fork di Bob è sempre non autorizzato, indipendentemente dalla distribuzione delle modifiche. Vedere le risposte a questa domanda per due opinioni in tal senso.
No CLA, con una forte licenza di copyleft
Come notato nella domanda, se sostituiamo "MIT / X" con, ad esempio, la GPL, anche le versioni modificate (o le parti del programma necessarie per riprodurre la versione modificata dall'originale) sono necessariamente concesse in licenza sotto la GPL.
CLA
Un CLA esplicito può cedere il copyright al manutentore del progetto, o può semplicemente concedere determinati diritti al manutentore per utilizzare il codice del contributore ( wiki ). Se il copyright viene ceduto, quel codice ora è un contributo del proprietario del progetto, non diversamente da qualsiasi altra parte del progetto.
Se il proprietario del progetto ha semplicemente una licenza per utilizzare il contributo nel proprio progetto, allora un forker sembra essere su un terreno più instabile e la situazione esatta probabilmente dipende dai dettagli del CLA.
CLA "impliciti" e aspettative della comunità
C'è generalmente un'aspettativa della comunità che "inbound = outbound": che i contributi ai progetti gratuiti siano gratuiti. Per quanto ne so, questo è sbagliato. Tuttavia, alcune piattaforme fanno di questo presupposto un accordo esplicito nei loro Termini di servizio. La domanda collegata fornisce un esempio di GitHub, e ancora una volta questo varia da piattaforma a piattaforma.