Deklarowanie wielu licencji w projekcie GitHub

28

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).

Kay
źródło
2
Więc miej plik README i jeden lub więcej plików LICENCJI. To nie jest nauka o rakietach.
Robert Harvey,
4
Jeśli chodzi o linkowaną stronę: nie ma ona nic wspólnego z dystrybucją plików licencyjnych, musi mieć interfejs API licencji GitHub, który określa / raportuje licencję repo. Jak pytałam o licencji / wykorzystywania plików licencji na GitHub konkretnie, a nie otwartego źródła lub git ogólnie, sposób projekt open source jest „wcielił” być licencjonowany na nie jest zbyt istotne. „To nie jest nauka o rakietach” nie jest szczególnie pomocne, przy okazji. nie w kontekście mojego pytania dotyczącego GitHub.
Kay
2
Mogę zasugerować, że plik README zawiera sekcję dotyczącą licencjonowania, stwierdzając po prostu, że istnieje wiele licencji i informując o każdej licencji, nazwę pliku LICENCJI, w którym się znajduje?
Erik Eidt,
3
@immibis Jestem tego świadomy i wcale nie o to chodziło w moim pytaniu. W szczególności prosiłem o odpowiedź dotyczącą tego, „jaki sposób ma sens dla ludzi” (na: GitHub).
Kay,
3
@immibis: „Żaden kompilator tego nie przeczyta” - problem polega na tym, że ściśle mówiąc, nie jest to prawdą w przypadku Github. Github korzysta z automatycznego narzędzia do określania licencji „zastosowanej” do zawartości repozytorium. Nazwa tak ustalonej licencji zostanie następnie wyświetlona na pasku tytułu repozytorium, wraz z kilkoma bardziej ogólnymi informacjami, które zapewnią odwiedzającym podstawowe wrażenie na temat projektu (np. Liczba autorów i wydań).
LUB Mapper

Odpowiedzi:

15

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.
Bart van Ingen Schenau
źródło
1
Jak poradziłbyś sobie z własnym plikiem LICENCJI w przypadku podwójnego licencjonowania własnych treści w tym scenariuszu? Tj. Jeśli używałeś różnych licencji dla różnych części projektu (kod kontra pliki multimedialne) lub jeśli chciałeś rozpowszechniać swój kod na dwóch (lub więcej) różnych licencjach na oprogramowanie? Umieszczanie dodatkowych informacji w pliku README ma sens i tak też bym zrobił, ale szczególnie interesuje mnie, jak radzić sobie z plikami LICENCYJNYMI w serwisie GitHub (które, moim zdaniem, są zachęcane do udostępniania odwiedzającym / widzom szybki przegląd projektu).
Kay,
1
Jeśli (części) mojego kodu są licencjonowane podwójnie, dodam dwa (lub więcej) pliki licencji do projektu, po jednym dla każdej licencji, i wyjaśnię w pliku readme, która licencja ma zastosowanie w danym przypadku.
Bart van Ingen Schenau,
1
Bart, dzięki za podzielenie się tym, jak to zrobiłeś - to o wiele bardziej pomocne niż niektóre komentarze, które otrzymałem. :) Tymczasem faktycznie skontaktowałem się z GitHub w tej sprawie i pozostawię to pytanie na razie otwarte, na wypadek, gdyby coś z tego wynikło.
Kay
2
Gdy otrzymasz odpowiedź od Github, prześlij tę informację jako odpowiedź na to pytanie.
Bart van Ingen Schenau,
1
Zdecydowanie tak zrobię, jeśli będzie to dla nich w porządku, ponieważ może być interesujące wiedzieć także dla innych!
Kay
12

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ę”.

koppor
źródło
4

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.

Kay
źródło