Proprietære plug-ins for GPL programmer: hva om tolket språk?

stemmer
8

Jeg utvikler en GPL-lisensiert program i Python og trenger å vite om GPL gjør mitt program å bruke proprietære plug-ins. Dette er hva FSF har å si om saken:

Hvis et program utgitt under GPL bruker plug-ins, hva er kravene for lisenser av en plug-in?

Det avhenger av hvordan programmet påkaller sin plug-ins. Hvis programmet bruker gaffel og exec å påkalle plug-ins, så plug-ins er separate programmer, så lisensen for hovedprogrammet gir ingen krav til dem.

Hvis programmet linker dynamisk plug-ins, og de gjør funksjonskall til hverandre og dele datastrukturer, tror vi de danner et enkelt program, som må behandles som en forlengelse av både hovedprogrammet og plug-ins. Dette betyr at plug-ins må utgitt under GPL eller en GPL-kompatibel fri programvare lisens, og at vilkårene i GPL må følges når disse plug-ins er fordelt.

Hvis programmet linker dynamisk plug-ins, men kommunikasjonen mellom dem er begrenset til å påberope seg 'main' funksjon av plug-in med noen alternativer, og venter på det å vende tilbake, er at et grensetilfelle.

Skillet mellom gaffel / exec og dynamisk lenking, foruten å være slags kunstig, ikke bære over til tolket språk: hva om en Python / Perl / Ruby plugin, som blir lastet via importeller execfile?

(Edit: Jeg forstår hvorfor skillet mellom gaffel / exec og dynamisk linking, men det virker som noen som ønsket å være i samsvar med GPL, men gå mot ånden --Jeg don't-- kunne bare bruke gaffel / exec og kommunikasjon mellom å gjøre ganske mye annet).

Den beste løsningen ville være å legge til et unntak fra min lisens eksplisitt tillate bruk av proprietære plugins, men jeg er ikke i stand til å gjøre det siden jeg bruker Qt / PyQt som er GPL.

Publisert på 28/08/2008 klokken 00:26
kilden bruker
På andre språk...                            


3 svar

stemmer
6

han skillet mellom gaffel / exec og dynamisk lenking, foruten å være litt kunstig,

Jeg tror ikke det kunstig i det hele tatt. I utgangspunktet er de bare gjør divisjonen basert på graden av integrering. Hvis programmet har "plugins" som er essensielt ild og glemme uten API nivå integrering, så den resulterende arbeidet er usannsynlig å bli betraktet som en avledet arbeid. Generelt sett en plugin som bare delte / exec'ed ville passe disse kriteriene, selv om det kan være tilfeller hvor det ikke. Denne saken gjelder spesielt hvis "plugin" code ville fungere uavhengig av koden din også.

Dersom, på den annen side, er koden dypt avhengig av GPL'ed arbeid, for eksempel utstrakt ringer APIer, eller tett datastruktur integrasjon, så ting er mer sannsynlig å bli betraktet som en avledet arbeid. Dvs. "plugin" kan ikke på egen hånd uten GPL produkt, og et produkt med denne plugin installert er egentlig et avledet arbeid av GPLed produktet.

Så for å gjøre det litt mer klart, kan de samme prinsippene gjelder for din tolket kode. Dersom tolket kode stoler tungt på dine APIer (eller omvendt) så det ville bli betraktet som en avledet arbeid. Hvis det er bare et skript som utfører på egen hånd med ekstremt lite integrert, så kan det ikke.

Betyr det være mer fornuftig?

Svarte 28/08/2008 kl. 00:33
kilden bruker

stemmer
1

Hvor mye info du deler mellom Plugins og hovedprogrammet? Hvis du gjør noe mer enn bare utfører dem og venter på resultatene (deling ingen data mellom programmet og plugin i prosessen) så du kan sannsynligvis komme unna med dem er proprietær, ellers ville de sannsynligvis må være GPL' d.

Svarte 28/08/2008 kl. 00:33
kilden bruker

stemmer
1

@Daniel

Skillet mellom gaffel / exec og dynamisk lenking, foruten å være slags kunstig, ikke bære over til tolket språk: hva om en Python / Perl / Ruby plugin, som blir lastet via import eller execfile?

Jeg er ikke sikker på at skillet er kunstig. Etter en dynamisk belastning plugin kode deler en henrettelse sammenheng med GPLed kode. Etter en gaffel / exec gjør det ikke.

I anycase vil jeg gjette at importing fører den nye koden for å kjøre i samme utførelse konteksten som GPLed bit, og du bør behandle det som dynamiske koblinger saken. Nei?

Svarte 28/08/2008 kl. 00:32
kilden bruker

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more