如何处理死的开源依赖项？
我正在尝试为开源版本准备一个项目，但遇到了问题...该项目依赖于许多开源组件，迄今为止我刚刚将这些组件作为 JAR 文件存储在我的 lib 目录中。 其中一些可以追溯到几年前，至少其中来自一个开源项目，该项目的网站已经消失，而且我无法找到其源代码（Radeox 库）。
我的困境是，当我发布项目时，我不知道如何打包它...我不应该包含没有源代码的 JAR 文件，因为这会违反我自己使用代码的许可证条款，但是我认为这个 JAR 文件不容易找到，所以我也不希望有一个自述文件说“找到这个 JAR，祝你好运！”。
在这种情况下，最佳做法是什么？ （除了“保留从现在开始导入的所有 JAR 的源代码！）其次，有谁知道我在哪里可以找到这个特定库的源代码？
谢谢！
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!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
如果许可证规定您必须包含源代码，那么您必须包含源代码。
尝试联系原作者。 也许这个 Ohloh 链接会有所帮助。 如果您无法联系到他们，也许您可以从使用该库的另一个项目获取源代码的副本。 作为最后的手段，您可以尝试 Google 缓存 或 archive.org。
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.
更新：Bingo!!
这是 Radeox Subversion 存储库。 向下导航到 http://svn.codehaus.org/ radeox/main/trunk/src/java/org/radeox/ 获取源代码。
早些时候...
看起来作者 Stephan Schmidt 目前正在 http:// /www.codemonkeyism.com。 他的联系信息（包括电子邮件）位于此处，以及来自 2007 年 8 月 谈到将项目分叉到Reposita.org（似乎还没有启动）。 去年，他的演示让他参加了 ImobilienScout24。
我相信您已经意识到依赖一个已死的、无人维护的项目的危险。 我们刚刚清除了软件中的几个此类依赖项，并且睡得更好了。 其中包括用于 SOAP Web 服务的 Axis 1.4（由于严重的线程错误而于 2005 年被放弃），并被普通的 Java 逻辑所取代； kxml 解析器（也于 2005 年废弃），由 JAXP 取代； 以及一个无名的 HTTP 客户端（已经被废弃了，我们甚至找不到旧的源代码），被 Apache HTTP 客户端取代。 不过 Radeox 听起来像是一个更困难的情况。
获取法律建议，并努力寻找消息来源和/或斯蒂芬，记录你所做的一切。 这可能足以让您在制定替换策略时分发二进制文件。
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.
我们的方法是确保在获取二进制文件时获取源代码。 然后，正是出于您引用的原因，我们在本地永久存档所有第三方依赖项。 这有点痛苦，因为使用第三方库比简单地下载 tarball 并运行要复杂一些，但这意味着当库被弃用时，我们可以继续履行我们的客户义务和法律义务。
请注意，我们目前维护的软件已有近 15 年的历史，而且我们的一些第三方软件包早于流行的网络，因此我们的解决方案对您来说可能有点大材小用。
还有其他优点； 我们必须修补其中一些产品来修复错误或添加上游维护人员无法或不愿意添加但我们需要的功能，并且这与此过程无缝契合。
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.