¿Cómo lidiar con dependencias de código abierto muertas?

Question

Estoy tratando de preparar un proyecto para el lanzamiento de código abierto y me he encontrado con un problema ... Este proyecto depende de una cantidad de componentes de código abierto que acabo de almacenar como archivos JAR en mi directorio lib para fecha. Algunos de ellos datan de hace unos años, y al menos de ellos es de un proyecto de código abierto cuyo sitio ha desaparecido y de cuya fuente no he podido encontrar una copia (la biblioteca de Radeox).

Mi dilema es que no sé cómo empacar mi proyecto cuando lo lanzo ... No debería incluir el archivo JAR sin fuente porque eso violaría los términos de la licencia bajo la cual utilicé el codificar yo mismo, pero no creo que este archivo JAR se pueda encontrar fácilmente, así que tampoco quiero tener un archivo README que diga "¡encuentra este JAR, buena suerte!".

¿Cuál es la mejor práctica en este caso? (Distinto de "mantener la fuente de todos los archivos JAR que importe a partir de ahora!) Y en segundo lugar, ¿alguien sabe donde puedo encontrar la fuente para esta biblioteca particular?

Gracias!

Answer 1

Nuestro enfoque ha sido garantizar que adquirimos la fuente cuando adquirimos los binarios. Entonces, exactamente por la razón que citan, archivamos permanentemente todas nuestras dependencias de terceros localmente. Es un poco molesto, ya que usar una biblioteca de terceros es un poco más complejo que simplemente descargar el archivo e ir, pero significa que cuando una biblioteca está en desuso, podemos seguir cumpliendo con nuestras obligaciones y las legales. .

Tenga en cuenta que mantenemos un software que tiene casi 15 años de antigüedad en este momento, y algunos de nuestros paquetes de terceros son anteriores a la popular web, por lo que nuestra solución podría ser excesiva para usted.

También hay otras ventajas; hemos tenido que parchear algunos de estos productos para corregir errores o agregar funciones que los proveedores iniciales no pudieron o no quisieron agregar, pero que necesitábamos y que se adaptan perfectamente a este procedimiento.

Answer 2

Si la licencia dice que usted tiene para incluir la fuente, debe incluir la fuente.

Puede ser útil this Ohloh link. Si no puede contactarlos, puede obtener una copia de la fuente de otro proyecto que use la fuente biblioteca. Como último recurso, puede probar Google's cache o archive.org.

Answer 3

Actualización: ¡¡Bingo !!

Aquí está la Radeox Subversion repository. Navegue hasta http://svn.codehaus.org/radeox/main/trunk/src/java/org/radeox/ para el código fuente.

principios ...

Parece que Stephan Schmidt, el autor Actualmente, se está ejecutando un blog en http://www.codemonkeyism.com. Su información de contacto, incluido el correo electrónico es here, y una entrada de August 2007 se refirió a la posibilidad de reordenar el proyecto a Reposita.org (que no parece estar todavía). Su presentations lo puso en ImobilienScout24 el año pasado.

Estoy seguro de que estás en sintonía con los peligros de depender de un proyecto muerto y sin mantenimiento. Simplemente purgamos nuestro software de varias de esas dependencias y estamos durmiendo mucho mejor. Incluyeron Axis 1.4 para servicios web SOAP (abandonados con serios errores de enhebrado en 2005), reemplazados por la lógica vainilla de Java; el analizador kxml (también abandonado en 2005), reemplazado por JAXP; y un cliente HTTP sin nombre (tan abandonado que no pudimos encontrar incluso la fuente anterior), reemplazado por Apache HTTP Client. Sin embargo, Radeox suena como un caso más difícil.

Obtenga asesoramiento legal, y haga un esfuerzo extenuante para encontrar la fuente y/o Stephan, documentando todo lo que hace. Eso podría ser suficiente debido a la diligencia para permitirle distribuir binarios mientras trabaja en una estrategia de reemplazo.