Preciso lidar com licenças de dependências imediatas?

Question

Preciso lidar com licenças de dependências imediatas?

#1 resposta do (4 votos)

5

Vamos supor que dentro do meu projeto que é baseado em GPLv3 eu esteja usando uma única biblioteca chamada a-lib.jar. Esse jar em si é licenciado usando a licença do Apache v2, então eu devo estar bem com o GPL, desde que eu respeite os termos do Apache v2 (basicamente incluindo o arquivo de licença).

Agora, quando olho para o a-lib.jar que estou usando, vejo que ele está usando muitas outras dependências (compactadas em a-lib.jar):

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

Todos eles são licenciados em licenças de código aberto, mas as licenças podem ser diferentes. Por exemplo:

b-lib.jar está licenciado no MIT
c-lib.jar está licenciado sob o Apache v2
O d-lib.jar é licenciado sob uma licença de código aberto "customizada"

O arquivo resultante que gostaria de liberar ficaria assim:

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

Minha pergunta é: para evitar problemas legais, tenho que cumprir todos os termos das dependências da biblioteca das quais meu projeto depende? Por exemplo. tenho que colocar algum arquivo de NOTIFICAÇÃO em algum lugar, dizendo que estou usando o b-lib.jar e que ele está sob o MIT? Então, novamente: você pode jogar esse jogo para sempre: b-lib.jar também pode incluir outras licenças de terceiros e assim por diante.

Preciso verificar todos os componentes e cumprir os termos, mesmo que o software MY não esteja sendo usado, mas, em vez disso, um lib que estou usando está usando-o? Ou eu estou bem se eu apenas cuidar das dependências dos meus projetos e não precisar me preocupar com dependências de terceiros? (A idéia básica por trás disso é que o criador do a-lib.jar que o liberou sob o apache v2 é responsável por seu conteúdo).

Além disso: a situação do exemplo acima é diferente se as dependências de terceiros não forem child-jars dentro do a-lib.jar mas, em vez disso, a-lib seria entregue como um projeto maven com dependências para b-a. lib, c-lib e d-lib e as dependências de terceiros seriam empacotadas diretamente no meu arquivo * .jar do projeto? Então, o arquivo resultante seria:

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

licensing dependencies legal

por masi 09.01.2015 / 21:55

fonte

1 resposta

Tags licensing dependencies legal

Como sei quando refatorar as chamadas de consulta de banco de dados global e quando deixá-las em paz? Esses dois cenários seriam bons candidatos para um banco de dados NoSQL?

score 4 · Answer 1

Sobreviver ao cenário traiçoeiro das licenças de código aberto pode ser difícil às vezes, mas você deve respeitar o motivo pelo qual os programadores licenciam seu software em primeiro lugar. Na maioria dos casos, eles escrevem softwares de código aberto com a gentileza de seus corações. Eles não são pagos por isso. Eles têm uma sensação de conforto porque podem ter contribuído com algo de valor para a sociedade.

Tenho assistido a incontáveis horas de apresentações de propriedade intelectual no trabalho e tenho uma bela matriz colorida na minha mesa descrevendo boas e más licenças para a criação de software proprietário (sim, eu vendi minha alma e sou pago para escrever software). ). Geralmente, nos limitamos às bibliotecas de software licenciado do MIT e do BSD porque elas não são infecciosas.

Eu poderia facilmente recomendar que você simplesmente se preocupe com o licenciamento de suas dependências imediatas, mas se exponha a um risco. Normalmente, os programadores devem ter o cuidado de garantir que o licenciamento seja compatível com dependências (como você deveria estar fazendo), mas, caso isso aconteça, podem ter cometido um erro.

O resultado é este, se você pretende ganhar dinheiro com o software que você escreve, você precisa ter certeza de que tem permissão para vender o trabalho de outras pessoas, implícito nas licenças que eles entregam com suas bibliotecas.