Dlaczego muszę zachować licencję na oprogramowanie typu open source w katalogu głównym?

Prawie wszystkie licencje na oprogramowanie typu open source wymagają (lub przynajmniej prawnicy sugerują, że wymagają) użytkowników, aby umieścili pełną licencję w katalogu głównym chronionego projektu.

Jeden z prawników, z którym rozmawiałem, sugeruje, że jest to spuścizna epoki CD, kiedy to konieczne było dołączenie pełnej licencji do pudełka z biżuterią.

Ale dzisiaj żyjemy w erze chmur. Dlaczego na przykład nie mogę po prostu hostować pełnej licencji na mojej stronie internetowej i umieścić tytuł + adres URL tej licencji w nagłówku moich plików źródłowych?

Premia: jeśli ogólnie uzgodniono, że ustanowione licencje muszą pozostać nienaruszone w katalogu głównym, dlaczego OSI FSF nie zatwierdziło licencji, do której można odwoływać się za pomocą adresu URL, i co powstrzymuje kogoś przed utworzeniem tej licencji?

— samthebrand
źródło

Jednym z problemów, które przychodzą na myśl, jest to, że adresy URL można zmienić lub przerwać.

— Aaron Kurtzhals

„Internet nie jest wszechobecny” byłby najbardziej oczywistym powodem (nawet jeśli ktoś ma Internet, gdy pobiera twoje oprogramowanie, może nie być dostępny, gdy chce go rozszerzyć / zmodyfikować).

— TZHX

Zastanawiasz się, dlaczego CAŁA LICENCJA POTRZEBUJE BYĆ WŁĄCZONA w katalogu głównym lub dlaczego cała licencja musi być zawarta w rootie?

— DougM

Wskazując tylko, że wydaje się, że mówimy tutaj o fałszywej dychotomii; Pytasz, dlaczego licencja musi być w katalogu głównym i dlaczego nie może być online pod adresem URL? Istnieje trzecia opcja, o której nikt nie jest wspomniany; licencja jest dołączona do oprogramowania, ale znajduje się w katalogu „docs” lub czymś innym, a komentarz w nagłówku plików kodu to odzwierciedla. Zgadzam się z uzasadnionymi powodami, dla których licencja powinna być dołączona do oprogramowania, ale nie kończy się to na przejściu do katalogu docs.

— James

Powodem, dla którego prawie zawsze jest u podstaw, jest łatwość znalezienia. Kiedy pobieram twój projekt, przeglądam katalog główny, a jedną z pierwszych rzeczy, które widzę, jest licencja. To takie proste

— JohnL

Odpowiedzi:

Z GPL FAQ (ale rada dotyczy wszystkich licencji):

Dlaczego GPL wymaga dołączenia kopii GPL do każdej kopii programu?

Dołączenie kopii licencji do utworu jest niezbędne, aby każdy, kto otrzyma kopię programu, mógł wiedzieć, jakie są jego prawa.

Kuszące może być podanie adresu URL, który odnosi się do licencji, zamiast samej licencji. Ale nie możesz być pewien, że adres URL będzie nadal ważny za pięć lub dziesięć lat. Za dwadzieścia lat adresy URL, jakie znamy dzisiaj, mogą już nie istnieć.

Jedynym sposobem, aby upewnić się, że osoby posiadające kopie programu będą nadal mogły zobaczyć licencję, pomimo wszystkich zmian, które nastąpią w sieci, jest dołączenie kopii licencji do programu.

(moje podkreślenie)

W momencie, gdy witryna hostująca licencję przestaje działać lub zmienia ścieżki adresów URL, osoby posiadające kopie oprogramowania nie mogą już sprawdzać, jakie prawa mogą bezpiecznie wykonywać. Załóżmy, że nawet możesz w jakiś sposób zagwarantować, że ten dokładny adres URL będzie zawsze dostępny online: możliwość zweryfikowania przez użytkowników legalności korzystania z Twojego oprogramowania zależy od możliwości połączenia się z tym konkretnym adresem URL. Chociaż ten wymóg może nie być uciążliwy w danym mieście / kraju / planecie, może być uciążliwy w innych miejscach. Nie należy nakładać tego wymogu, zwłaszcza gdy obejście (w tym pełny tekst licencji) jest banalne.

Możesz odpowiedzieć na tę skargę, mówiąc: „Co z tego? Jeśli adres URL spadnie lub nie będzie dostępny, wystarczający będzie jednoznaczny deskryptor, taki jak„ GNU GPL v3 ”. Kopie pełnotekstowe GPL są obfite; użytkownicy mogą przeglądać sama licencja ”. Od razu przychodzi mi na myśl kilka problemów:

Nie uogólnia to na mniej jasne identyfikatory licencji (przychodzi na myśl zwrot „licencja BSD”).
Nie uogólnia to dobrze w przypadku licencji, które są mniej popularne lub zostały dostosowane (przychodzi na myśl „GPL z wyjątkami łączenia”: które wyjątki łączenia?). Jak często musi obowiązywać licencja, aby można było oczekiwać, że użytkownik rzetelnie ją znajdzie po nazwie?
Nadal wymaga to od użytkowników połączenia z Internetem, co może nie być prawdą, nawet jeśli mieli połączenie w momencie, gdy otrzymali oprogramowanie. (I może nie mieli dostępu do Internetu, gdy otrzymali oprogramowanie: „epoka CD” jeszcze się nie skończyła w wielu częściach świata. Jako dodatkowy przypadek rozważmy narodowe populacje, które mają powszechny dostęp do Internetu, ale cenzurują jego znaczną część .) Konsekwencją oprogramowania, które można swobodnie rozpowszechniać, jest to, że odbiorca może nie otrzymać kopii twojego oprogramowania bezpośrednio od ciebie lub przez kanał dystrybucji, którego pierwotnie oczekiwałeś.

Ostatni argument przeciwko linkom do licencji odnotowano poniżej w komentarzu MichaelT: może to pozwolić na dynamiczną, wsteczną zmianę licencji. Można to zrobić celowo, ale można to również zrobić przypadkowo, jeśli zmienisz licencję między wersjami oprogramowania, ale użyjesz tego samego linku do licencji dla obu wersji, w ten sposób blokując starą licencję. Taka zmiana sprawiłaby trudności osobom, które muszą udowodnić, że otrzymały starszą kopię na innej licencji niż obecna wersja.

Dlaczego więc muszę zachować licencję w katalogu głównym projektu?

Nie jestem prawnikiem, ale nigdy nie widziałem żadnego przekonujący argument, że nie potrzeba do utrzymania licencji w katalogu głównym projektu. Nawet GPL, która określa, że licencja musi towarzyszyć każdej kopii utworu, milczy na temat tego, w jaki sposób musi towarzyszyć utworowi. (Może to być spowodowane tym, że GPL można zastosować w kontekstach innych niż oprogramowanie, w których pojęcie „katalogu głównego” nie ma znaczenia.)

Przechowywanie licencji w katalogu głównym jest prawdopodobnie dobrym pomysłem, ponieważ maksymalizuje prawdopodobieństwo, że użytkownik ją zobaczy, a tym samym minimalizuje zarówno frustrację użytkownika, jak i prawdopodobieństwo skarg przeciwko tobie za próbę ukrycia licencji w jakimś niejasnym katalogu. Jeśli masz wiele licencji, sensowniejsze może być umieszczenie ich wszystkich w osobnym folderze i dołączenie oczywistego projektu README zawierającego ścieżki plików umożliwiające znalezienie licencji dla każdego komponentu.

Umieszczanie licencji w katalogu głównym jest przydatną praktyką, ponieważ może ujednoznacznić licencje modułów, które są licencjonowane inaczej niż praca jako całość. Załóżmy, że mój projekt FooProj używa autonomicznego modułu BarMod. FooProj może być na licencji GPL, podczas gdy samodzielny moduł może być na licencji MIT. Kiedy po raz pierwszy otwieram FooProj, widzę kopię GPL w katalogu głównym i rozumiem, że cała praca jest objęta licencją GPL. Kiedy schodzę do folderu BarMod, widzę tam nowy plik licencji i rozumiem, że zawartość tego folderu ma licencję MIT. Oczywiście jest to tylko pomocna pomoc; zawsze należy wyraźnie wskazać licencję na swoje moduły w pliku README, NOTICE lub podobnym pliku.

Podsumowując, korzystanie z katalogu głównego pliku jest kwestią wygody i przejrzystości. Nie widziałem żadnego prawnie wiążącego tekstu licencji typu open source, który by tego wymagał, ani nie znam żadnego powodu, dla którego byłby on wymagany prawem. Twoja licencja powinna być stosunkowo łatwa do odnalezienia przez odbiorcę; uwzględnienie licencji w katalogu głównym projektu jest wystarczające, ale nie konieczne, aby spełnić to kryterium.

— apsillery
źródło

Rozważ także możliwość linku do strony zdalnej dla site.com/foo/license.txt, którą uzyskałeś na licencji BSD, ale od tego czasu została ona ponownie licencjonowana na GPL v3 i to właśnie site.com/foo/license. txt zawiera teraz. Ale pobrana wersja ma inne prawa.

Oznacziłem tę odpowiedź jako poprawną, ponieważ wydaje się ona przedstawiać konwencjonalną i prawną mądrość dotyczącą licencjonowania OSS. To powiedziawszy , to myślenie wydaje mi się nieco paranoiczne w tym świecie, w którym mamy kopię zapasową, z kontrolą wersji, w którym żyjemy. Nie jestem pewien, czy ryzyko sabotażu zawartości URL-a jest większe niż ryzyko przypadkowego usunięcia części licencja zawarta w katalogu głównym. I nawet jeśli ryzyko jest większe, jestem sceptycznie nastawiony do tego, że wspaniale jest zmusić deweloperów do włączenia pełnych licencji do swojego oprogramowania, zamiast, powiedzmy, cytowania zewnętrznych hostowanych licencji w komentarzach do kodu.

— samthebrand,

Do Twojej wiadomości, być może jest to znak nadchodzących kwestii związanych z licencjonowaniem OSS: Creative Commons 4.0 zezwala licencjobiorcom na linkowanie do osobnej strony zawierającej informacje o atrybucji.

— samthebrand

Ale dzisiaj żyjemy w erze chmur. Dlaczego na przykład nie mogę po prostu hostować pełnej licencji na mojej stronie internetowej i umieścić tytuł + adres URL tej licencji w nagłówku moich plików źródłowych?

Istnieją licencje, które na to pozwalają. Na przykład Apache 2.0. Apache 2.0 wymaga tylko, aby każdy plik źródłowy zawierał mały nagłówek wskazujący kanoniczny adres URL licencji Apache 2.0. Nie ma potrzeby odtwarzania pełnej licencji w drzewie źródłowym.

Z samej licencji Apache 2.0:

APPENDIX: How to apply the Apache License to your work

To apply the Apache License to your work, attach the following boilerplate
notice, with the fields enclosed by brackets "[]" replaced with your own 
identifying information. (Don't include the brackets!) The text should be  
enclosed in the appropriate comment syntax for the file format. We also 
recommend that a file or class name and description of purpose be included 
on the same "printed page" as the copyright notice for easier identification 
within third-party archives.

    Copyright [yyyy] [name of copyright owner]

    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
    You may obtain a copy of the License at

        http://www.apache.org/licenses/LICENSE-2.0

    Unless required by applicable law or agreed to in writing, software
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
    limitations under the License.

— Chadversary
źródło

Myślę, że dodatek jest niekompletny lub przynajmniej działa przy założeniu, że już dołączasz kopię licencji. Z samego tekstu 2.0 przy dystrybucji pracy licencjonowanej przez Apache:4.(a) You must give any other recipients of the Work or Derivative Works a copy of this License;

— apsillers

Nie ma wymogu, aby musiał on znajdować się w katalogu głównym projektu. Jest to po prostu najczęstsze miejsce, a zatem pierwsze miejsce, w którym ludzie będą szukać licencji. Co do tego, nawet jeśli nie było to powszechne, nadal prawdopodobnie pierwsze miejsce będą wyglądać ludzie. Ponieważ licencja istnieje na informowanie, ukrywanie informacji nie ma większego sensu.

Jeśli ukryjesz go pod adresem URL, nie ma absolutnej gwarancji, że ten adres URL będzie zawsze dostępny. Jeśli jest to plik w katalogu głównym projektu, z definicji zawsze będzie dostępny.

Krótko mówiąc, jest to najskuteczniejsze i najbardziej przyjazne dla użytkownika miejsce.

— Bryan Oakley
źródło

Katalog główny projektu to pierwsze miejsce, na które można spojrzeć: to wierzchołek drzewa, katalog główny hierarchii folderów. Powinna tam znajdować się cała dokumentacja najwyższego poziomu: readme, licencja itp. Pliki te mogą nakierować czytelnika na głębsze kopanie w innym miejscu projektu, ale root jest pierwszym miejscem, w którym szukam czegokolwiek.