La licenza è un problema per i sottomoduli Git?

7

Ad esempio: un progetto con licenza MIT desidera semplificare il processo di compilazione per i suoi utenti includendo parte della toolchain GNU (che è ovviamente GPL) come Submodule.

  • Potrebbe essere interpretato come rendere il progetto MIT un "lavoro derivato" della toolchain GNU?
  • Includere un progetto come Git Submodule (o qualche meccanismo simile - forse anche solo uno script di Bash che lo scarica) conta come "ridistribuire" quel progetto?
  • Che dire se il Makefile creava anche il sottoprogetto?

Secondo me (e probabilmente la maggior parte dei popoli) la risposta a queste domande è un chiaro "no". Sono più interessato ad ascoltare i precedenti e le norme relative a questo problema piuttosto che discutere le nostre interpretazioni della legge sul copyright. Sei a conoscenza di progetti open source che hanno Sottomoduli sotto licenze incompatibili? Conosci qualcuno che li ha deliberatamente evitati e perché l'hanno fatto?

Giusto per chiarire per persone non-Git: i sottomoduli non causano l'inclusione del contenuto reale, sono come "puntatori" di un repository diverso. Nell'esempio che ho dato, quando hai clonato il progetto MIT e hai eseguito git submodule init , Git avrebbe scaricato automaticamente il codice GNU da un repository GNU.

    
posta Brendan 20.05.2014 - 17:01
fonte

2 risposte

2

Il progetto Open Source Android quasi esattamente rispecchia il caso che ho usato nel mio esempio: la maggior parte della fonte è sotto Licenza Apache , ma usano un meccanismo equivalente ai sottomoduli Git per consegnare la toolchain GNU .

    
risposta data 15.04.2016 - 18:23
fonte
6

Dubito che troverai materiali legali significativi sui sottomoduli git di per sé. Un angolo sarebbe quello di fare un'analogia con un altro sistema con una comunità più grande / una storia più lunga / più precedenti. A tal fine, definiamo "git submodules" - sono, infatti, due cose:

  1. Un formato di file (".gitmodules") che elenca i nomi / indirizzi di altri pacchetti software. (Per brevità, chiamiamo questi file "manifest".)
  2. Uno strumento che legge il formato del file e scarica il software.

Ora, selezioniamo un altro progetto che soddisfi questi criteri - ad esempio, il gestore pacchetti di Debian fornisce entrambi:

  1. Un formato file che elenca i nomi / gli indirizzi di altri pacchetti software. (Per brevità, chiamiamo questi file "manifest".)
  2. Uno strumento che legge il formato del file e scarica il software.

(Per motivi di prestazioni, il formato file per il gestore di pacchetti di Debian è molto più complesso / sfumato, poiché una tipica implementazione di Debian funziona con migliaia di pacchetti distribuiti su migliaia di server, mentre una tipica implementazione di sottomoduli git funziona con forse una dozzina di pacchetti e una manciata di server.Se rivedi la storia precedente di dpkg / apt, scoprirai che le prestazioni sono state un problema di progettazione centrale e un risultato significativo, tuttavia, a livello "informativo" generale, i formati sono simili.)

Il progetto Debian è un esempio particolarmente utile perché - all'interno della comunità FOSS - debian-legal ha una storia particolarmente lunga / una solida reputazione per la valutazione dei problemi di licenza derivanti dal mix di software.

Quindi: se guardiamo al progetto Debian, scopriamo che pubblicano manifesti che fanno riferimento a pacchetti con licenze incompatibili? Sì. Ad esempio, PHP4 è stato concesso in licenza con la "Licenza PHP" che la FSF giudica incompatibile con GPL ( link ). Ecco il manifest:

link

Osserva che questo ha "Build-depends" su "bison". Bison è uno strumento concesso in licenza da FSF sotto licenza GPL.

Se un utente digita "apt-build install php4", la conseguenza sarà che scarica "php4" e "bison", caricando entrambi sullo stesso computer / file system. Abbiamo violato la GPL? No. Perché no? Ognuno di questi punti dovrebbe essere persuasivo individualmente:

  1. La combinazione di pacchetti è stata approvata tramite il processo di Debian.
  2. Abbiamo scaricato solo il software - non abbiamo modificato o ridistribuito il software. Sotto GPL, questa è una distinzione significativa.
  3. La GPL distingue specificamente la modifica / derivazione dalla mera aggregazione e nega la viralità sotto una mera aggregazione.
  4. Il manifest mostra bisonte come "Build-depends" e non "Depends" - per wit, bison è uno strumento build che aiuta a processare php4 (come fa un editor di testo); php4 non include (o nemmeno collega) il codice bisonte; in fase di esecuzione, è possibile eseguire php4 senza eseguire bison.

Se hai scambiato il gestore di pacchetti di Debian con git-submodules qui, cambierebbe improvvisamente da "OK" a "violazione"? No, è sciocco: è lo stesso mix di codici con lo stesso mix di licenze e gli stessi passaggi di compilazione. Tutto ciò che è cambiato è lo strumento di download.

(Nota: niente di ciò significa che il tuo uso specifico dei sottomoduli git con le sue dipendenze specifiche sia accettabile o inaccettabile.Nel nostro esempio di Debian, diversi fattori chiave erano specifici per le licenze e i pacchetti particolari - e così va con qualsiasi cosa.)

    
risposta data 25.10.2014 - 11:26
fonte

Leggi altre domande sui tag