Как бороться с мертвыми открытыми исходниками? - PullRequest
6 голосов
/ 27 мая 2009

Я пытаюсь подготовить проект к выпуску с открытым исходным кодом и столкнулся с проблемой ... Этот проект зависит от ряда компонентов с открытым исходным кодом, которые я только что сохранил в виде JAR-файлов в своем каталоге lib на свидание. Некоторые из них датируются несколькими годами, и, по крайней мере, они принадлежат проекту с открытым исходным кодом, сайт которого исчез, и источник которого я не смог найти (библиотека Radeox).

Моя дилемма в том, что я не знаю, как упаковать свой проект при его выпуске ... Я не должен включать JAR-файл без исходного кода, потому что это нарушило бы условия лицензии, под которой я использовал код сам, но я не думаю, что этот файл JAR легко найти, поэтому я также не хочу иметь README с надписью «найди этот JAR, удачи!».

Какая лучшая практика в этом случае? (кроме "сохранить источник всех JAR-файлов, которые вы импортируете с этого момента!) И во-вторых, кто-нибудь знает, где я могу найти источник для этой конкретной библиотеки?

Спасибо!

Ответы [ 3 ]

3 голосов
/ 27 мая 2009

Обновление: Бинго !!

Вот хранилище Radeox Subversion . Перейдите к http://svn.codehaus.org/radeox/main/trunk/src/java/org/radeox/ для получения исходного кода.

Ранее ...

Похоже, Стефан Шмидт, автор, в настоящее время ведет блог на http://www.codemonkeyism.com. Его контактная информация, включая адрес электронной почты здесь и запись от Август 2007 говорил о переносе проекта на Reposita.org (который, похоже, еще не запущен). Его презентации поместили его на ImobilienScout24 в прошлом году.

Я уверен, что вы настроены на опасность зависеть от мертвого, необслуживаемого проекта. Мы только что очистили наше программное обеспечение от нескольких таких зависимостей и спим намного лучше. Они включали в себя Axis 1.4 для веб-сервисов SOAP (в 2005 г. из-за серьезных ошибок в потоках) их заменили ванильной Java-логикой; синтаксический анализатор kxml (также отмененный в 2005 г.), замененный JAXP; и HTTP-клиент без имени (настолько заброшенный, что мы не смогли найти даже старый источник), замененный HTTP-клиентом Apache. Radeox звучит как более сложный случай.

Получите юридическую консультацию и приложите огромные усилия, чтобы найти источник и / или Стефана, документируя все, что вы делаете. Этого может быть достаточно из-за старательности, чтобы позволить вам распространять двоичные файлы во время работы над стратегией замены.

3 голосов
/ 27 мая 2009

Если в лицензии указано, что вы должны включить источник, то вы должны включить источник.

Попробуйте связаться с авторами оригинала. Может быть эта ссылка Ohloh поможет. Если вы не можете связаться с ними, возможно, вы можете получить копию источника из другого проекта, который использует библиотеку. В крайнем случае вы можете попробовать кеш Google или archive.org.

2 голосов
/ 27 мая 2009

Наш подход состоял в том, чтобы гарантировать, что мы приобретаем источник, когда мы приобретаем двоичные файлы. Затем, именно по той причине, на которую вы ссылаетесь, мы постоянно архивируем все наши сторонние зависимости локально. Это немного болезненно, поскольку использовать стороннюю библиотеку немного сложнее, чем просто скачать архив и начать работу, но это означает, что когда библиотека устарела, мы можем продолжать выполнять как наши обязательства перед клиентами, так и юридические. ,

Обратите внимание, что на данный момент мы поддерживаем программное обеспечение, которому уже почти 15 лет, а некоторые из наших сторонних пакетов предшествуют популярной сети, поэтому наше решение может оказаться для вас излишним.

Есть и другие преимущества; нам пришлось исправлять некоторые из этих продуктов, чтобы исправлять ошибки или добавлять функции, которые сторонние разработчики не могли или не хотели добавлять, но которые нам были нужны, и это органично вписывается в эту процедуру.

...