Uso di librerie LGPL su dispositivi Android (in un unico file .apk chiuso) [duplicato]

Question

Uso di librerie LGPL su dispositivi Android (in un unico file .apk chiuso) [duplicato]

#1 da (3 voti)
#2 da (0 voti)

1

Beh, questa domanda è già stata posta più volte qui.

ma le risposte sono contraddittorie

Ecco perché lo chiedo di nuovo (forse il tempo ha cambiato le cose). Le librerie con licenza LGPL possono essere utilizzate in applicazioni closed source su androidi? In particolare, quando sono collegati in modo dinamico tramite .so. ma all'interno di un singolo pacchetto apk.

questo argomento spiega come questo è possibile e quali misure dovrebbero essere prese. Tuttavia, si dà per scontato che gli utenti siano in grado di riconfezionare il file apk (e quindi aprire il file apk).

Allora questo argomento semplicemente mette in discussione quanto sopra. E la risposta è "non lo fai".

Quindi, cosa può fare se gli utenti del tuo programma (quando gli dai un APK) ottengono la propria versione della libreria, la compilano e la sostituiscono?

(PS: non so se dovrei posizionarlo qui o su StackOverflow, per favore sposta nella posizione migliore)

lgpl android dynamic-linking

posta paul23 31.01.2014 - 13:51

fonte

2 risposte

Leggi altre domande sui tag lgpl android dynamic-linking

Memorizzazione di immagini / file caricati dall'utente in ambiente multi server Emulazione della comunicazione tra Android e microcontrollore tramite thread o servizi o ... altro?

score 3 · Answer 1

La risposta è sì. Ci sono alcuni requisiti specifici e devi leggere e capire per essere sicuro di rispettare. Leggi S4 in particolare.

I requisiti non sono particolarmente onerosi per il collegamento dinamico. Sotto 4 (d) 1, devi solo "usare un meccanismo adatto" e fornire alcune informazioni aggiuntive. C'è un linguaggio nella licenza che suggerisce un tipo di meccanismo adatto, ma si legge come abilitante piuttosto che obbligatorio, quindi un meccanismo equivalente dovrebbe essere sufficiente. C'è un chiaro obbligo che il meccanismo sia fattibile. Ad esempio, un metodo che dipendeva dal riconfezionamento dell'APK potrebbe essere adatto e questo potrebbe precludere la firma o altre misure protettive.

Non è obbligatorio che sia tecnicamente semplice e gli obblighi dell'utente non si estendono all'educazione dell'utente (che si presume abbia le competenze tecniche necessarie), alla fornitura di assistenza attiva o alla modifica della domanda per renderla più facile.

In termini pratici, questo obbligo non si verificherà a meno che o fino a quando un utente specifico non desideri sostituire la libreria fornita con un'altra, magari con una correzione di bug. In tal caso non puoi trattenere le informazioni necessarie per farglielo fare, o intraprendere azioni per ostacolarle, ma se fornire assistenza o offrire un servizio è una decisione commerciale.

Dichiarazione di non responsabilità: non sono un avvocato, ma prendo queste decisioni per conto della mia azienda.

score 0 · Answer 2

Non c'è assolutamente alcuna contraddizione.

La prima domanda a cui ci si collega spiega che è consentito utilizzare librerie con licenza LGPL in applicazioni Android proprietarie a condizione che vengano compilate come librerie condivise separate e che l'applicazione continui a funzionare se l'utente la riconfeziona per soddisfare il Requisito LGPL che l'utente deve avere un modo per utilizzare la versione modificata del codice LGPL.

La seconda domanda riguarda il modo tecnico di impacchettare gli eseguibili, non le librerie nei pacchetti Android e non dice nulla sulla licenza tranne la motivazione. La risposta non è che non sia possibile, ma solo che non funziona come previsto dal richiedente.