Deklarowanie wielu licencji w projekcie GitHub

Od lat jestem wielkim fanem umieszczania licencji na rzeczy udostępniane online, aby ułatwić innym ustalenie, czy i jak mogą ponownie wykorzystać te rzeczy. Zanim GitHub zaczął delikatnie „wypychać” swoich użytkowników do dołączania plików LICENSE do ich repozytoriów, tak naprawdę nie wiedziałem, jak najlepiej to zrobić za pomocą kodu - szczególnie kodu udostępnianego publicznie na GitHub! - ale od tego czasu starałem się dobrze wykorzystywać pliki LICENCJI.

Jestem teraz w sytuacji, gdy pracowałem nad małym projektem z kilkoma innymi ludźmi, który wymaga wzmianki o kilku licencjach (z powodu kodu i bibliotek innych firm, a także plików innych niż kod). Podczas gdy moi partnerzy zajmują się tym problemem raczej „niechlujnie” - zasugerowano, że „po prostu umieszczam kod w obecnej postaci, nikogo to nie obchodzi” - wolałbym zrobić to właściwie. Problem w tym, że nie wiem, jak należy wspomnieć o kilku (różnych) licencjach na GitHub.

Widziałem kilka różnych rozwiązań na GitHub, dlatego trudno mi ocenić, czy ta odpowiedź na nieco inne pytanie jest autorytatywna. Chciałbym wiedzieć, który z poniższych - jeśli w ogóle - jest najczęstszy lub czy istnieją inne, dodatkowe sposoby na zrobienie tego.

1. Utwórz jeden plik LICENCJA i umieść tam opisy wszystkich różnych licencji. ( Pytania : Czy powinny być ułożone w określonej kolejności? Czy zacznę od podania nazw wszystkich zawartych w nich licencji, aby uzyskać lepszy przegląd)?
2. Tworzenie jednego pliku licencja na licencji używanych i wymienić je LICENSE.md, LICENSE.LibNameA.md, LICENSE.AssetsB.mditd., Jak sugeruje się w połączonej odpowiedzi. ( Pytanie : Nazewnictwo opierałoby się na nazwach projektów? Nie nazwach licencji? Gdybym użył więcej niż jednej licencji na materiał z własnym wkładem, czy wymieniłbym je wszystkie w „głównej” LICENSE.md? Jeśli nie, co zrobiłbym zamiast tego?)
3. Utwórz dwa pliki LICENCJI : jeden zawierający listę licencji na zawartość „główną”, tj. Cały utworzony przez siebie kod / zasoby; jeden na wszystkie materiały stron trzecich. ( Pytania jak wyżej : czy jest jakiś konkretny schemat nazewnictwa, którego należy użyć, i kolejność, w jakiej należy wymienić materiały stron trzecich?)

Wreszcie, jeśli poprawnie zrozumiałem różne wyjaśnienia i projekty GitHub dotyczące ich API licencji, tylko „główny” plik LICENCJI zostanie wzięty pod uwagę przy określaniu licencji repo (chociaż nie byłem w stanie ustalić, która licencja zostanie wybrana jeśli wymieniono kilka).

Możesz użyć dowolnego mechanizmu, aby uwzględnić te licencje, które ci się podobają, pod warunkiem, że osoba odwiedzająca projekt stanie się jasna, która licencja dotyczy danej części projektu.

Moje preferencje to:

• Umieść każdą bibliotekę innej firmy, której używasz, we własnym katalogu. Ten katalog powinien zawierać wszystkie pliki będące częścią dystrybucji biblioteki, w tym pliki licencji i readme.
• We własnym pliku licencji należy odnosić się tylko do licencji własnego kodu
• W pliku readme swojego projektu podaj, z jakich bibliotek zewnętrznych korzystasz i na jakiej licencji dystrybuowana jest każda biblioteka. Szczegółowe informacje na temat licencji znajdują się w pliku licencji w katalogu biblioteki.

W prezentacji twórców SPDX ( slajd 12 ) jest bardzo jasne:

Zawartość LICENSE:

Apache-2.0 OR GPL-2.0-or-later

Następnie możesz dodać dwa dodatkowe pliki LICENCJI: LICENSE.Apache-2.0i LICENSE.GPL-2.0-or-later.

We wszystkich przypadkach README.mdpowinien zawierać identyfikator licencji SPDX :

SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later

Możesz to zrobić w ten sposób:

## License

This work is dual-licensed under Apache 2.0 and GPL 2.0 (or any later version).
You can choose between one of them if you use this work.

`SPDX-License-Identifier: Apache-2.0 OR GPL-2.0-or-later`

Należy pamiętać, że Apache-2.0 OR GPL-2.0-or-lateri Apache-2.0 AND GPL-2.0-or-laterrobi dużą różnicę. Pierwsza z nich oznacza, że ​​użytkownik może wybierać między obydwoma (co jest normalnym przypadkiem!), A druga oznacza, że ​​użytkownik musi przestrzegać obu licencji. Zobacz także wiele licencji na Wikipedii.

Pamiętaj, że korzystam z nowej (na dzień 28.12.2017 ) SPDX License List 3.0 tutaj. Wersje 2017 miały GPL-2.0identyfikator GPL 2.0, ale nie było jasne, czy to oznacza „tylko GPL 2.0”, czy „GPL 2.0 lub jakąkolwiek późniejszą wersję”.

W końcu skontaktowałem się bezpośrednio z pomocą techniczną GitHub w sprawie mojego pytania, a oni powiedzieli, że można je cytować, jeśli wyjaśnię, że ich odpowiedzi miały jedynie charakter sugestii, a nie zaleceń.

Nasz zespół nie ma obecnie żadnych konkretnych rekomendacji do zaoferowania, ale postaramy się zapytać i zaktualizować, jeśli mamy coś jeszcze do przekazania!

Ich pierwotna odpowiedź miała następujące oferty:

Jedną z sugestii jest posiadanie jednego pliku LICENCJI dla większości kodu i dodanie tekstu licencji na pozostałe materiały stron trzecich w pliku README.

Innym sposobem jest, aby każda ścieżka miała własny plik LICENCJA, gdy ma to sens. Jeśli na przykład twoje repozytorium ma następującą ścieżkę: libs / awesome-lib-v2 / możesz mieć libs / awesome-lib-v2 / LICENCJA.

W tym drugim przypadku możesz wspomnieć o tym w pliku README i / lub pliku LICENSE w katalogu głównym.

Możesz również rozważyć użycie tylko jednego pliku LICENCJI w katalogu głównym repozytorium i dodać podrozdziały do ​​wszelkich materiałów, kodu itp. Innych firm.