How to deal with dead open-source dependencies?

Question

I'm trying to prep a project for open-source release and have run into a problem... This project depends on a number of open-source components which I've just stored as JAR-files in my lib directory to date. Some of them date back a few years, and at least of them is from an open-source project whose site has disappeared and whose source I haven't been able to find a copy of (the Radeox library).

My dilemma is that I don't know how to package my project when I release it... I shouldn't include the JAR-file without source because that would violate the terms of the license under which I used the code myself, but I don't think that this JAR file is easily findable so I also don't want to have a README that says "find this JAR, good luck!".

What is the best practice in this case? (other than "keep the source of all JARs you import from now on!) And secondarily, does anyone know where I can find the source for this particular library?

Thanks!

Answer 1

If the license says you have to include the source then you have to include the source.

Try contacting the original authors. Maybe this Ohloh link will help. If you can't reach them, maybe you can get a copy of the source from another project that uses the library. As a last resort you could try Google's cache or archive.org.

Answer 2

Update: Bingo!!

Here's the Radeox Subversion repository. Navigate down to http://svn.codehaus.org/radeox/main/trunk/src/java/org/radeox/ for the source code.

Earlier ...

Looks like Stephan Schmidt, the author, is currently running a blog at http://www.codemonkeyism.com. His contact information, including email is here, and an entry from August 2007 talked about forking the project over to Reposita.org (which doesn't seem to be up yet). His presentations put him at ImobilienScout24 last year.

I'm sure you're attuned to the dangers of depending on a dead, unmaintained project. We just purged our software of several such dependencies and are sleeping much better. They included Axis 1.4 for SOAP web services (abandoned with serious threading bugs in 2005), replaced by vanilla Java logic; the kxml parser (also abandoned in 2005), replaced by JAXP; and a no-name HTTP client (so abandoned we couldn't find even the old source), replaced by Apache HTTP Client. Radeox sounds like a more difficult case though.

Get legal advice, and make a strenuous effort to find the source and/or Stephan, documenting everything you do. That might be enough due dilligence to enable you to distribute binaries while you work on a replacement strategy.

Answer 3

Our approach has been to ensure that we acquire the source when we acquire the binaries. Then, for exactly the reason you cite, we permanently archive all of our third-party dependencies locally. It's a bit of a pain, since to use a third party library is a bit more complex than simply downloading the tarball and going, but it means that when a library is deprecated, we can continue to meet both our client obligations and our legal ones.

Mind you, we maintain software that is nearly 15 years old at this point, and some of our third party packages predate the popular web, so our solution might be overkill for you.

There are other advantages, too; we've had to patch some of these products to fix bugs or add features that upstream maintainers have been unable or unwilling to add, but that we needed, and that fits seamlessly into this procedure.