Jak radzić sobie z martwymi zależnościami open-source?

Question

Próbuję przygotować projekt do wydania open source i mam problem ... Ten projekt zależy od wielu składników open-source, które właśnie zapisałem jako pliki JAR w moim katalogu lib do data. Niektóre z nich pochodzą sprzed kilku lat, a przynajmniej pochodzą z projektu o otwartym kodzie źródłowym, którego witryna zniknęła i której źródła nie udało mi się znaleźć kopii (biblioteki Radeox).

Moim dylematem jest to, że nie wiem, jak spakować mój projekt, kiedy go wypuszczę ... Nie powinienem dołączać pliku JAR bez źródła, ponieważ naruszałoby to warunki licencji, w której użyłem koduję się, ale nie sądzę, że ten plik JAR można łatwo znaleźć, więc nie chcę też README, który mówi "znajdź to JAR, powodzenia!".

Jaka jest najlepsza praktyka w tym przypadku? (Inne niż „zachować źródło wszystkich JAR importowanych od teraz!), A po drugie, czy ktoś wie gdzie mogę znaleźć źródła dla tej konkretnej biblioteki?

Answer 1

Nasze podejście polegało na zapewnieniu, że pozyskamy źródło po nabyciu plików binarnych. Następnie, z dokładnie tego powodu, który cytujesz, trwale archiwizujemy wszystkie nasze niezależne zależności. To trochę kłopotliwe, ponieważ korzystanie z biblioteki stron trzecich jest nieco bardziej skomplikowane niż zwykłe pobieranie archiwum i uruchamianie, ale oznacza to, że gdy biblioteka jest przestarzała, możemy nadal spełniać zarówno nasze zobowiązania klienta, jak i nasze prawne. .

Pamiętaj, że w tym momencie utrzymujemy oprogramowanie, które ma już prawie 15 lat, a niektóre z naszych pakietów zewnętrznych sprzed popularnych witryn internetowych, więc nasze rozwiązanie może być dla Ciebie przesadzone.

Są też inne zalety; musieliśmy załatać niektóre z tych produktów w celu naprawienia błędów lub dodania funkcji, których poprzedni opiekunowie nie mogli lub nie chcą dodać, ale których potrzebowaliśmy i które idealnie pasują do tej procedury.

Answer 2

Jeśli licencja mówi masz Dzięki! aby dołączyć źródło, musisz podać źródło:

Jeśli chcesz skontaktować się z oryginalnymi autorami, może pomoże Ci this Ohloh link. Jeśli nie możesz ich uzyskać, możesz uzyskać kopię źródła z innego projektu, który korzysta z W ostateczności możesz wypróbować: Google's cache lub archive.org

Answer 3

Aktualizacja: Bingo !!

Oto Radeox Subversion repository. Przejdź do opcji http://svn.codehaus.org/radeox/main/trunk/src/java/org/radeox/ dla kodu źródłowego.

Wcześniej ...

Wygląda Stephan Schmidt, autor, jest obecnie uruchomiony blog w http://www.codemonkeyism.com. Jego dane kontaktowe, w tym adres e-mail, to: here, a wpis z August 2007 mówił o przeniesieniu projektu do witryny Reposita.org (która prawdopodobnie nie jest jeszcze dostępna). Jego presentations umieścił go w ImobilienScout24 w zeszłym roku.

Jestem pewien, że dostroiłeś się do niebezpieczeństw zależnych od martwego, nieśmiertelnego projektu. Po prostu oczyściliśmy nasze oprogramowanie z kilku takich zależności i śpimy dużo lepiej. Obejmowały one oś 1.4 dla usług sieciowych SOAP (porzuconych z poważnymi błędami w wątkach w 2005 r.), Zastąpionych przez logikę wanilii Java; parser kxml (również opuszczony w 2005), zastąpiony przez JAXP; i klient HTTP bez nazwy (tak porzucony, że nie mogliśmy znaleźć nawet starego źródła), zastąpiony przez klienta HTTP Apache. Radeox brzmi jednak jak trudniejszy przypadek.

Uzyskaj poradę prawną i usilnie staraj się znaleźć źródło i/lub Stephan, dokumentując wszystko, co robisz. To może wystarczyć, aby przeprowadzić dystrybucję plików binarnych podczas pracy nad strategią wymiany.