Come affrontare le dipendenze open-source morti?

Question

sto cercando di preparare un progetto per il rilascio open-source ed ho incontrato un problema ... Questo progetto dipende da una serie di componenti open-source, che ho appena archiviati come JAR-files nella mia cartella lib ad oggi. Alcuni di essi risalgono a qualche anno, e almeno di loro da un progetto open-source il cui sito è scomparso e la cui fonte non sono stato in grado di trovare una copia del (la libreria Radeox).

Il mio dilemma è che non so come pacchetto mio progetto quando ho comunicato che ... non dovrei includere il file JAR senza sorgente, perché questo violerebbe i termini della licenza con la quale ho usato il codice me stesso, ma non credo che questo file JAR è facilmente trovabile così anche io non voglio avere un README che dice "trovare questo JAR, buona fortuna!".

Qual è la migliore pratica in questo caso? (Diversa da "mantenere la fonte di tutti i JAR importati da ora in poi!) E secondariamente, qualcuno sa dove posso trovare la fonte di questa particolare libreria?

Grazie!

Answer 1

Il nostro approccio è stato quello di garantire che si acquisisce la fonte quando si acquisiscono i file binari. Poi, esattamente per la ragione che citi, siamo permanentemente archiviamo tutte le nostre dipendenze di terze parti a livello locale. E 'un po' di dolore, dal momento che di utilizzare una libreria di terze parti è un po 'più complessa di quanto semplicemente scaricando il tarball e andare, ma significa che quando una libreria è deprecato, possiamo continuare a soddisfare sia i nostri obblighi del cliente e le nostre quelli legali .

Intendiamoci, noi manteniamo un software che è quasi 15 anni, a questo punto, e alcuni dei nostri pacchetti di terze parti anteriori alla web popolare, così la nostra soluzione potrebbe essere eccessivo per voi.

Ci sono altri vantaggi, anche; abbiamo dovuto rattoppare alcuni di questi prodotti per correggere i bug o aggiungere caratteristiche che manutentori a monte sono stati in grado o non vuole aggiungere, ma che avevamo bisogno, e che si inserisce perfettamente in questa procedura.

Answer 2

Se la licenza dice che dovete includere la fonte, allora è necessario includere la fonte.

Prova a contattare l'autore originale. Forse questo Ohloh link aiuterà. Se non li può raggiungere, forse è possibile ottenere una copia dei sorgenti da un altro progetto che utilizza la libreria. Come ultima risorsa si potrebbe provare di Google Cache o archive.org.

Answer 3

Aggiornamento: Bingo !!

Ecco il Radeox Subversion repository . Spostarsi in basso per http://svn.codehaus.org/ Radeox / main / trunk / src / java / org / Radeox / per il codice sorgente.

All'inizio di ...

Sembra Stephan Schmidt, l'autore, è attualmente in esecuzione di un blog all'indirizzo http://www.codemonkeyism.com . Le sue informazioni di contatto, tra cui e-mail è qui , e una voce dal Agosto 2007 parlato fork del progetto verso Reposita.org (che non sembra essere ancora). Il suo metterlo a ImobilienScout24 l'anno scorso.

Sono sicuro che siete in sintonia con i pericoli di funzione di un morto, di progetto non più mantenuto. Abbiamo appena la purificazione dei software di parecchi tali dipendenze e stiamo dormendo molto meglio. Hanno incluso Axis 1.4 per i servizi web SOAP (abbandonato con gravi bug threading nel 2005), sostituito dalla logica di vaniglia Java; il parser kxml (abbandonata anche nel 2005), sostituito da JAXP; e un client senza nome HTTP (così abbandonati, non siamo riusciti a trovare anche la vecchia sorgente), sostituito da client HTTP Apache. Radeox suona come un caso più difficile, però.

Chiedi consiglio legale, e fare uno sforzo strenuo per trovare la fonte e / o di Stephan, documentando tutto quello che fai. Questo potrebbe essere sufficiente diligenza dovuta per consentire di distribuire i binari mentre si lavora su una strategia di sostituzione.