La LGPL mi consente di farlo?

Sto progettando di sviluppare un software commerciale usando un software LGPL.

Nel software LGPL che sto usando alcune funzioni in una classe non sono completamente implementate. Voglio modificare il codice LGPL in modo che la classe e le funzioni non implementate siano rese visibili all'esterno della dll aggiungendo dllexport davanti alla classe e aggiungendo una parola chiave virtuale davanti alla funzione.

Quindi ho intenzione di implementare quelle funzioni nel mio software proprietario. Sono pronto a distribuire il codice LGPL modificato ma non un software proprietario che implementa le funzioni nel modo che desidero.

Ciò viola i termini e le condizioni LGPL?

Questa è una domanda complessa, ma credo che ciò che proponi non sia permesso.

Si sta suggerendo ganci aggiungendo nella libreria per rendere più facile per voi di sottoclasse la biblioteca e, quindi, per lo meno. per bypassare lo spirito della LGPL.

Il problema è che se sottoclassi una classe soggetta alla licenza LGPL nel tuo codice, il tuo lavoro diventa un'opera basata sulla libreria , piuttosto che un'opera che utilizza la libreria, il che significa che il tuo codice è un derivato lavoro che rientra nella sezione 2 ( LGPL v2.1 ) anziché in uno coperto nella sezione 6 ( LGPL v2.1 ). Cioè diventa soggetto alla LGPL !

Penso che Stephen Colebourne fornisca un buon riassunto su javalobby.

Non sono un grande fan delle discussioni istintive con i tuoi suggerimenti di avvocato , ma in questo caso penso che varrebbe la pena farlo se hai intenzione di procedere con questo, altrimenti potresti ricevere una brutta lettera dal Software Libero Team legale della Fondazione .

In alternativa, potresti chiedere direttamente alla FSF . Dalla loro pagina di contatto :

Per domande su licenze per software libero e copyright

Consulta le domande frequenti sulle licenze , l' elenco delle licenze , le informazioni generali sul copyleft e le pagine correlate . Se rimangono domande, inviare un'e-mail a <licensing@gnu.org>.

Per inciso, nella domanda correlata Reflection e LGPL , gbjbaanb risponde con la prospettiva LGPL 3.0 .

Standard Non sono un disclaimer di avvocato.

LGPL richiede che le modifiche al codice sorgente della libreria siano distribuite a chiunque abbia utilizzato il codice. Essa non richiede che il codice, che usa la libreria, sia open source e rilasciato sotto la stessa licenza.

Wikipedia per una descrizione più dettagliata, ma non legale, di LGPL, inclusa una sezione sull'eredità di classe .

"Voglio modificare il codice LGPL ..." questo dice abbastanza che devi rilasciare qualsiasi di quel codice modificato. Quindi estendere il fatto che l'estensione del codice modificato sia un'opera derivata è controversa e in tal caso diventa soggetta alla LGPL.

Quello che sembra che tu stia cercando di fare è aggirare la LGPL, che in questo caso con queste tecniche non puoi.

Se si tratta di un lavoro derivato, i termini del programma devono consentire "modifica per uso proprio del cliente e reverse engineering per il debug di tali modifiche". Se un'opera che utilizza un programma LGPL è un'opera derivata o meno è un problema legale.

Ma se quello che stai cercando di fare è aggirare la LGPL, contatterò la FSF come raccomandato da Mark Booth .

La mia ipotesi: (ma IANAL) dovresti rilasciare come open source la libreria modificata come codice LGPL e quindi rilasciarla in un programma commerciale. Funzionerebbe. Effettivamente finiresti per avere un fork open source della libreria in giro e poi venderai un front-end per questo.

Ma come molti altri hanno giustamente affermato, chiedi al FSF : è uno scenario patologico intrigante che hai lì; potrebbero chiedersi quanto fai se è applicabile o no. (o almeno preoccuparsene abbastanza da pubblicare una voce FAQ sull'argomento)

https://www.gnu.org/licenses/lgpl-java.html

Se si distribuisce un'applicazione Java che importa librerie LGPL, è facile aderire alla LGPL. La licenza dell'applicazione deve consentire agli utenti di modificare la libreria e decodificare il codice per eseguire il debug di queste modifiche. Ciò non significa che è necessario fornire il codice sorgente o eventuali dettagli sugli interni dell'applicazione. Naturalmente, alcune modifiche che gli utenti possono apportare alla libreria potrebbero interrompere l'interfaccia, rendendo la libreria incapace di funzionare con l'applicazione. Non devi preoccuparti di questo: le persone che modificano la libreria sono responsabili del suo funzionamento.

In breve, non vi è alcun problema con l'ereditarietà finché non si modifica il codice della libreria stesso, ma anche se lo si modifica, è necessario rilasciare solo il codice modificato della libreria, non il codice dell'applicazione.