Il missaggio di licenza GPL

La situazione di Joomla è piuttosto brutta e sorto a causa della mancanza di comprensione della licenza da parte dei suoi sviluppatori. Il team di Joomla inizialmente supportava le persone che rilasciavano estensioni proprietarie, quindi molti hanno avuto l'impressione che "è OK".

Non è OK però. Joomla stesso è stato biforcuto da un altro progetto, Mambo, che era anche GPL. Questo fa sì che Joomla richieda la licenza GPL, e non possono semplicemente relicarlo per consentire estensioni proprietarie, senza ottenere una licenza alternativa da Miro (o da adesso, la Mambo Foundation.) Ma ovviamente non era nel loro spirito permettere quello.)

AFAIK, Joomla ha rimosso tutte le estensioni non GPL dalle loro inserzioni da.

Con pochi dubbi, tutte le estensioni proprietarie che invocano il codice di Joomla sono in violazione della GPL. È chiaro però che Joomla non ha alcun interesse a inseguire le violazioni, ma The Mambo Foundation potrebbe ancora farlo (a meno che Joomla non sia stato da allora riscritto per rimuovere la sua dipendenza da Mambo, cosa di cui dubito).

È abbastanza chiaro che anche gli sviluppatori di estensioni non comprendono la licenza. Vedo molte lamentele riguardo alla decisione di rimuovere le estensioni non GPL - gli sviluppatori non capiscono che non è la scelta di Joomla a farlo, ma sono costretti a farlo a causa della licenza.

Quindi per rispondere alle tue domande

Q1: Non possono davvero. La loro distribuzione è una violazione diretta della GPL, e se la cavano perché Joomla non li sta inseguendo. Tuttavia, se hai deciso di ridistribuire uno di questi lavori, l'autore non ha grandi possibilità in tribunale poiché sta violando la GPL, quindi puoi probabilmente rischiare.

D2: anche questa è una violazione della GPL e sei in diritto di eludere eventuali restrizioni.

Q3: non possono. Come altre risposte davvero. Queste sono le affermazioni degli autori, ma hanno davvero poca legittimità.

Per quanto riguarda la tua risposta da un autore di estensione, è piena di merda. La GPL richiede che tutte le opere collegate siano concesse in licenza GPL. (Non solo GPL compatibile, ma GPL).

Ma come già detto sopra, ciò che costituisce il "collegamento" è il limite legale. Quelle estensioni che si basano semplicemente su un servizio non collegato a Joomla sono OK.

Se stai pensando di rilasciare il codice sotto la GPL, lo consiglierei, ma assicurati di non lasciare che le violazioni sfuggano di mano al punto di non ritorno, come è successo con Joomla. È una grande licenza, peccato che l'abbiano contaminata così tanto.

People develop plugin scripts that have to invoke library functionality from the Joomla core in order to function. This surely means that the plugin has to be GPL.

Non necessariamente, dipenderebbe da come sono collegati e, in definitiva, dall'interpretazione del tribunale. Se lavori esclusivamente su interfacce pubblicate e il tuo codice funzionerà con versioni alternative di Joomla, potresti dedurre che non si tratta di un'opera derivata. Più che usare il runtime Java rende il tuo codice soggetto alla licenza di Oracle.

But once purchased the end-user has every right to resell or do with it whatever they like (provided it falls under GPL terms).

Se il codice rientra nella GPL, o perché hanno scelto di renderlo tale - o perché è stato considerato un lavoro derivato

Q1. So, how can people sell non-GPL licensed plugins for Joomla?

Se possono affermare che non si tratta di un'opera derivata.

Q2. How is it acceptable to add some sort of activation system that limits use of the GPL >source? Is this not going against the very goal of GPL?

Non puoi - il punto di una licenza è concedere i diritti, i diritti stabiliti dalla GPL sono molto chiari

Q3. How can a non-GPL licensed plugin for Joomla be restricted to non-commercial use?

Se lo possiedi, scrivi semplicemente "non per uso commerciale". Applicarla è una questione diversa.

Un plugin per una piattaforma specifica, a seconda di quella piattaforma, "erediterebbe" GPL da esso. È un'opera derivata. Se Joomla fosse LGPL, non sarebbe un problema.

Tuttavia, se il plugin è generico - può essere usato con Joomla o qualche piattaforma non GPL, può essere proprietario, non dipende dalla parte libera. Per dare un esempio nella direzione opposta (GPL proprietaria di prevenzione), Debian ha rifiutato di includere l'emulatore di GameBoy, perché non avrebbe eseguito la funzione prevista senza ROM proprietarie. Poi un gioco Gameboy fan-made è stato rilasciato sotto licenza GPL e all'improvviso l'emulatore ha cessato di dipendere strettamente da componenti non liberi e potrebbe essere concesso in licenza come GPL.

Anche allora,

• solo gli autori di Joomla possono denunciarli. Hanno violato la licenza su Joomla, che dipende dal copyright di proprietà degli autori di Joomla.
• possono rilasciare i loro plugin come GPL e venderli ancora. GPL non proibisce le vendite, ma fa una scappatoia dannatamente inutile che i tuoi clienti possono rilasciare liberamente una ricompilazione del tuo prodotto.
• GPL ti offre due opzioni per il rilascio della fonte: 1. Raggruppa la fonte con il prodotto, distribuisci a clienti , 2. Fornisci la fonte a chiunque su richiesta . Se scegli l'opzione 1 e vendi il software, non devi fornire fonti a chi non ha pagato.

Ma alla fine, se l'autore del pezzo della GPL non è interessato a perseguire i violatori, non c'è nulla che li fermi. In sostanza, se le parti di derivazione palesemente derivate sono concesse in licenza arbitraria non GPL, ciò viola la GPL ma non ha alcun effetto fino a quando l'autore del programma che ha scritto la parte GPLd non fa causa agli autori delle parti proprietarie. (peggio ancora se è la stessa persona).

Ci sono dei caveat se la GPL non è originale ma derivata da altri lavori di GPL - quindi la causa potrebbe provenire da più in alto. Ancora, nessuna causa = fai come vuoi.

WordPress ha chiesto tempo fa un problema simile a SFLC. Un estratto della risposta:

On the basis of that version of WordPress, and considering those themes as if they had been added to WordPress by a third party, it is our opinion that the themes presented, and any that are substantially similar, contain elements that are derivative works of the WordPress software as well as elements that are potentially separate works. Specifically, the CSS files and material contained in the images directory of the “default” theme are works separate from the WordPress code. On the other hand, the PHP and HTML code that is intermingled with and operated on by PHP the code derives from the WordPress code.

[...]

The PHP elements, taken together, are clearly derivative of WordPress code. The template is loaded via the include() function. Its contents are combined with the WordPress code in memory to be processed by PHP along with (and completely indistinguishable from) the rest of WordPress. The PHP code consists largely of calls to WordPress functions and sparse, minimal logic to control which WordPress functions are accessed and how many times they will be called. They are derivative of WordPress because every part of them is determined by the content of the WordPress functions they call. As works of authorship, they are designed only to be combined with WordPress into a larger work.

Articolo principale: link .