Devo gestire le licenze di dipendenze immediate?

Question

Devo gestire le licenze di dipendenze immediate?

#1 da (4 voti)

5

Supponiamo che all'interno del mio progetto basato su GPLv3 io stia usando una singola libreria chiamata a-lib.jar. Quel jar stesso è concesso in licenza usando la licenza Apache v2, quindi dovrei essere a posto con GPL purché rispetti i termini di Apache v2 (che include fondamentalmente il file di licenza).

Ora, quando guardo il file a-lib.jar che sto usando, vedo che sta usando molte altre dipendenze (racchiuse in a-lib.jar):

b-lib.jar
c-lib.jar
d-lib.jar

Tutti sono concessi in licenza su licenze open source, ma le licenze possono essere diverse. Es .:

b-lib.jar è concesso in licenza sotto MIT
c-lib.jar è concesso in licenza con Apache v2
d-lib.jar è concesso in licenza con una licenza open source "personalizzata"

Il file risultante che vorrei rilasciare sarebbe quindi questo:

myproject.jar
|--a-lib.jar
   |--b-lib.jar
   |--c-lib.jar
   |--d-lib.jar

La mia domanda è: al fine di evitare problemi legali, devo rispettare tutti i termini delle dipendenze della libreria da cui dipende il mio progetto? Per esempio. devo posizionare qualche file AVVISO da qualche parte, dicendo che sto usando b-lib.jar e che è sotto il MIT? Poi ancora: puoi giocare a quel gioco per sempre: b-lib.jar può anche includere altre licenze di terze parti e così via.

Devo controllare OGNI SINGOLO componente e rispettare i suoi termini, anche se il mio software non lo sta usando, ma invece una lib che sto usando lo sta usando? O sto bene se mi prendo cura delle dipendenze dei miei progetti e non devo preoccuparmi delle dipendenze di terze parti? (L'idea di base dietro sarebbe che il creatore di a-lib.jar che lo ha rilasciato sotto apache v2 sia responsabile del suo contenuto).

Inoltre: la situazione dell'esempio sopra è diversa se le dipendenze di terze parti non sono child-jars all'interno di a-lib.jar ma invece a-lib verrebbe consegnata come progetto maven con dipendenze a b- lib, c-lib e d-lib e quelle dipendenze di terze parti sarebbero impacchettate direttamente nel mio progetto * .jar file? Quindi il file risultante sarebbe:

myproject.jar
|--a-lib.jar
|--b-lib.jar
|--c-lib.jar
|--d-lib.jar

licensing dependencies legal

posta masi 09.01.2015 - 21:55

fonte

1 risposta

Leggi altre domande sui tag licensing dependencies legal

Arresto del Javascript sul lato client da trasformare in un monolite Questi due scenari sarebbero buoni candidati per un database NoSQL?

score 4 · Answer 1

Sopravvivere a volte il pericoloso scenario delle licenze open source può essere difficile, ma è necessario rispettare il motivo per cui i programmatori concedono in licenza il loro software in primo luogo. Nella maggior parte dei casi scrivono software open source per gentilezza del loro cuore. Non vengono pagati per questo. Hanno una calda sensazione confusa dal fatto che possano aver contribuito qualcosa di valore alla società.

Mi sono seduto a innumerevoli ore di presentazioni di proprietà intellettuale al lavoro e ho una bella matrice colorata sulla mia scrivania che descrive le licenze buone e cattive per la creazione di software proprietario (sì, ho venduto la mia anima e sono stato pagato per scrivere software ). Generalmente ci atteniamo alle librerie software con licenza MIT e BSD perché non sono contagiose.

Potrei facilmente raccomandare che ti interessi semplicemente con la licenza delle tue dipendenze immediate ma ti esponi a un rischio. Di solito i programmatori si preoccupano di assicurarsi che la loro licenza sia compatibile con le dipendenze (come si dovrebbe fare), ma nel caso in cui si trovassero in errore potrebbero aver commesso un errore.

La linea di fondo è questa, se intendi fare soldi con il software che scrivi, devi assicurarti di avere il permesso di dire vendere il lavoro ad altre persone, implicito nelle licenze che spediscono con le loro librerie.