L'uso di built-in specifici GCC è qualificato come incorporazione all'interno di un progetto?

Naviga le tue risposte
7

Comprendo che il collegamento a un programma con licenza GPL richiede che rilasci anche la fonte del tuo programma sotto GPL, mentre la LGPL non lo richiede. La terminologia della (L) GPL è molto chiara su questo. 

#include "gpl_program.h"

significa che dovresti avere la licenza GPL, perché stai collegando al codice GPL. E 

#include "lgpl_program.h"

significa che sei libero di licenziare come preferisci, in modo che non proibisca esplicitamente il collegamento alla fonte LGPL. Ora, la mia domanda su ciò che non è chiaro è:

[begin question]

GCC è concesso in licenza GPL, la compilazione con GCC, non costituisce "integrazione" nel tuo programma, come dice la GPL; l'uso di funzioni incorporate (che sono specifiche di GCC) costituisce "incorporazione" anche se non si è esplicitamente collegato a questo codice di licenza GPL? La mia intuizione mi dice che questa non è l'intenzione, ma la legalità non è sempre intuitiva. Non sono davvero preoccupato, ma sono curioso di sapere se questo potrebbe essere considerato il caso.

[domanda finale]

[inizia da parte]

Il motivo del mio equivoco è che le compilazioni GCC come __builtin_clzl() o __builtin_expect() sono un'API tecnicamente e potrebbe essere implementate in un altro modo. Ad esempio, molti builtin sono stati replicati da LLVM e l'argomento potrebbe essere fatto che non è l'implementazione specifica per GCC. Tuttavia, molti builtin non hanno parallelismi e quando compilati collegheranno il codice GPL con licenza in GCC e non verranno compilati su altri compilatori. Se fai qui l'argomento che l'API potrebbe essere replicata da un altro compilatore, non potresti fare quella affermazione identica su qualsiasi programma a cui ti colleghi, a patto che tu non distribuisca quella fonte?

Capisco di essere un serpente legale a riguardo, ma mi sembra strano che la GPL non sia più specifica. Non vedo questo come uno stratagemma ragionevole per i creatori di software proprietari per aggirare la GPL, in quanto dovrebbero raggruppare il software GPL per farlo funzionare, rimuovendo la loro negabilità plausibile. Tuttavia, non è possibile che se i builtin non costituiscono un collegamento, i sostenitori dell'open source che si oppongono alla GPL potrebbero semplicemente scrivere un prodotto con licenza BSD / MIT / Apache / Apple che si collega a un programma GPL e affermano che intendono scrivere un'interfaccia non GPL identica a quella GPL, preservando la loro licenza BSD fino a quando non viene effettivamente compilata?

[fine a parte]

Scusate per il lato, non pensavo che molte persone avrebbero seguito il motivo per cui mi importa di questo se non dovessi affrontare problemi legali o implicazioni. Non preoccuparti troppo dell'ipotetico, sto solo estrapolando ciò che una risposta alla mia domanda potrebbe implicare.

    
posta DavidJFelix 14.06.2012 - 22:27
fonte

3 risposte

8

Risposta breve: qualsiasi utilizzo di GCC per la compilazione del codice è sempre stato e sarà sempre sicuro.

  1. __builtin_expect() & co. non sono per lo più funzioni ma estensioni di sintassi. Più simile all'operatore + o for parola chiave rispetto alla funzione libreria. Ad esempio __builtin_expect() non genera alcuna istruzione, dice semplicemente al compilatore di ordinare i rami in modo che il caso particolare sia più efficiente dell'altro (la CPU predice il salto in modo particolare, meno salti su quel percorso, ecc.). Anche per quei "builtin" che generano codice, è come qualsiasi altro codice generato dal costrutto del linguaggio primitivo. Costituisce un uso normale del compilatore e l'uso normale non è mai coperto da GPL.
  2. Tuttavia alcuni costrutti linguistici, sia definiti da standard C / C ++ o estensioni GCC, inclusi qualsiasi __builtin * e __sync * e tali possono generare chiamate alla libreria gcc (cioè libgcc.a ). Questa libreria è coperta da GPL, ma viene fornita un'eccezione speciale che consente di collegarlo a qualsiasi codice e di distribuire il file binario risultante con qualsiasi licenza.
  3. La stessa eccezione si applica a GNU stdlibc ++ ( libstdc++.a / libstdc++.so ), quindi sii sicuro anche con la libreria standard C ++.
  4. La libreria C standard (che viene fornita con il sistema operativo, non gcc), GNU libc (nel caso di Linux), è comunque coperta da LGPL, che consente solo dynamic collegamento di codice con licenza diversa. Poiché la libreria C standard contiene l'interfaccia di chiamata di sistema che viene spesso aggiornata per trarre vantaggio dai miglioramenti apportati ai nuovi kernel, non è consigliabile collegarlo sempre in modo dinamico comunque.
risposta data 15.06.2012 - 15:32
fonte
2

Senza ulteriori dettagli, credo che tu abbia risposto alla tua stessa domanda: 

... and when compiled will link GPL licensed code ...

L'atto di collegamento nel codice GPL sta legando il tuo progetto a un progetto GPL.
Vorrei ricontrollare che tu comprendessi correttamente le licenze di questi builtin.

Se la FSF / GNU tenterebbe o meno di perseguire un credito su tale base è una domanda completamente diversa. Sono inclinato verso "non molto probabile".

Sto rivedendo la mia risposta sulla base di ulteriori ricerche. In breve, non penso che ci sia un problema e il tuo codice non dovrebbe essere autorizzato come GPL.

Dalle FAQ:
Uso degli strumenti GNU
System Lib # 1
System Lib # 2
Vedi anche la Sezione 1 della GCC GPL.

I builtin si qualificano come librerie di sistema in quanto abilitano funzioni significative per GCC e forniscono un'implementazione di interfaccia per i vari standard C *. Sono solo estensioni dello strumento.

Molto probabilmente, i builtin sono rilasciati come LGPL, quindi verrai esentato a causa dell'esclusione del collegamento. Anche se non lo sono, sei ancora esente in base all'esenzione dalla libreria di sistema.

    
risposta data 14.06.2012 - 23:15
fonte
0

Se per "funzioni incorporate", vuoi dire cose come strlen() e read() , stai abbaiando dall'albero sbagliato. GCC non fornisce quelli, la libreria C da cui si caricano le intestazioni standard e contro cui si collega il codice. È quella licenza del pacchetto di cui devi preoccuparti.

    
risposta data 15.06.2012 - 03:58
fonte

Leggi altre domande sui tag

Dovrei modificare un'entità con molti parametri o con l'entità stessa? In che modo la terra CHRW produce codici unicode dato che accetta solo 65k di input possibili?