Como lidar com dependências de código aberto mortos?

Question

Eu estou tentando preparar um projeto para a liberação de código aberto e ter executado em um problema ... Este projeto depende de uma série de componentes de código aberto que eu acabei armazenado como JAR-arquivos no meu diretório lib Até a presente data. Alguns deles datam de alguns anos, e pelo menos um deles é de um projeto de código aberto cujo site desapareceu e cuja fonte não fui capaz de encontrar uma cópia do (a biblioteca Radeox).

Meu dilema é que eu não sei como empacotar o meu projeto quando eu soltá-lo ... Eu não devia incluir o arquivo JAR sem fonte porque isso violaria os termos da licença sob a qual eu usei o código eu mesmo, mas eu não acho que esse arquivo JAR é facilmente encontrável então eu também não quero ter um README que diz "encontrar este JAR, boa sorte!".

O que é a melhor prática neste caso? (Diferente de "manter a fonte de todos os JARs de importar a partir de agora!) E, secundariamente, alguém sabe onde eu posso encontrar a fonte para esta biblioteca particular?

Obrigado!

Answer 1

A nossa abordagem tem sido garantir que adquirimos a fonte quando adquirimos os binários. Então, para exatamente a razão que você citar, nós permanentemente arquivar todas as nossas dependências de terceiros localmente. É um pouco de dor, uma vez que usar uma biblioteca de terceiros é um pouco mais complexa do que simplesmente baixar o arquivo e indo, mas isso significa que quando uma biblioteca está obsoleta, podemos continuar a satisfazer ambas as nossas obrigações de clientes e nossos queridos legais .

Mind você, mantemos software que é quase 15 anos de idade, neste ponto, e alguns dos nossos pacotes de terceiros anteriores à web popular, por isso a nossa solução pode ser um exagero para você.

Há outras vantagens, também; nós tivemos que corrigir alguns desses produtos para fixar bugs ou adicionar características que os mantenedores têm sido incapazes ou não dispostos a acrescentar, mas que precisávamos, e que se encaixa perfeitamente a este procedimento.

Answer 2

Se a licença diz que você tem que incluir a fonte, então você tem que incluir a fonte.

Tente entrar em contato com os autores originais. Talvez este Ohloh ligação vai ajudar. Se você não pode alcançá-los, talvez você pode obter uma cópia da fonte de outro projeto que usa a biblioteca. Como último recurso, você pode tentar cache do Google ou archive.org.

Answer 3

Update: Bingo !!

Aqui está o Radeox Subversion repositório . Navegue para baixo para http://svn.codehaus.org/ radeox / main / trunk / src / java / org / radeox / para o código-fonte.

Mais cedo ...

Looks como Stephan Schmidt, o autor, está executando um blog em http://www.codemonkeyism.com . Sua informações de contato, incluindo e-mail é aqui , e uma entrada de agosto 2007 falou sobre a bifurcação do projeto sobre a Reposita.org (que não parece ser até até o momento). Sua apresentações o colocaram em ImobilienScout24 ano passado.

Eu tenho certeza que você está em sintonia com os perigos de depender de um projeto morto, não mantido. Nós apenas purgado nosso software de várias dessas dependências e estão dormindo muito melhor. Eles incluíram Axis 1.4 para serviços web SOAP de (abandonado com erros de threading graves em 2005), substituído pela lógica Java baunilha; o analisador kXML (também abandonou em 2005), substituído por JAXP; e um cliente HTTP sem nome (tão abandonada não foi possível encontrar até mesmo a velha fonte), substituído por Apache HTTP cliente. sons Radeox como um caso mais difícil embora.

Obter aconselhamento jurídico, e fazer um esforço árduo para encontrar a fonte e / ou Stephan, documentando tudo que você faz. Isso pode ser suficiente due dilligence para que você possa distribuir binários quando você trabalhar em uma estratégia de substituição.