Декларування декількох ліцензій у проекті GitHub

Протягом багатьох років я був великим прихильником розміщення ліцензій на речі, якими ділиться в Інтернеті, щоб іншим було простіше визначити, чи можуть вони повторно використовувати зазначені речі. Перед тим, як GitHub почав акуратно «підштовхувати» своїх користувачів до включення файлів LICENSE до своїх репост, я не знав, як найкраще це зробити з кодом - особливо код, який публічно ділиться на GitHub! - але я намагався добре використовувати файли LICENSE з тих пір.

Зараз я знаходжуся в ситуації, коли я працював над невеликим проектом з деякими іншими людьми, де потрібно згадати кілька ліцензій (завдяки стороннім кодам і бібліотекам, а також некодовим файлам). У той час як мої партнери вирішують проблему досить «неохайно» - мені запропонували «просто поставити код в Інтернеті як є, нікому не буде байдуже» - я б краще зробив це належним чином. Проблема полягає в тому, що я не знаю, як можна згадати кілька (різних) ліцензій на GitHub.

Я бачив кілька різних рішень на GitHub, через що мені важко судити, чи справжня відповідь на дещо інше питання є авторитетною. Що я хотів би знати, це один із наступних - якщо такий є - найбільш поширений, чи є інші, додаткові способи цього зробити.

Створіть один єдиний файл ЛІЦЕНЗІЇ та помістіть описи всіх різних ліцензій. ( Запитання : Чи слід їх розміщувати в певному порядку? Я б почав файл із зазначенням назв усіх ліцензій, що містяться в ньому, для кращого огляду)?
Створіть один файл ліцензії на ліцензію , використовуваної і назвати їх LICENSE.md, LICENSE.LibNameA.md, і LICENSE.AssetsB.mdт.д. , як запропоновано в пов'язаному відповідь. ( Питання : Іменування базуватиметься на назвах проектів? Не ліцензійні імена? Якби я використовував більше ніж одну ліцензію для матеріалів, що внесли власні внески, я б зазначив їх усіх у "головному" LICENSE.md? Якщо ні, що б я зробив замість цього?)
Створіть два файли ЛІЦЕНЗІЇ : один з переліком ліцензій (и) на "основний" вміст, тобто весь код / активи, створені самим; по одному для всіх сторонніх матеріалів. ( Питання, як описано вище : чи існує певна схема іменування, яку ви б використовували, і порядок, в якому перераховували б матеріали сторонніх виробників?)

Нарешті, якщо я правильно зрозумів різні пояснення та проекти GitHub щодо їх API ліцензій, при визначенні ліцензії репо буде враховано лише "основний" файл ЛІЦЕНЗІЇ (хоча я не зміг зрозуміти, яка ліцензія буде обрана якщо згадувалося декілька).

licensing github

— Кей
джерело

Тоді майте README та один чи кілька файлів LICENSE. Це не ракетна наука.

— Роберт Харві

Що стосується пов'язаної сторінки: вона не має нічого спільного з розповсюдженням файлів ліцензій, вона пов'язана з API ліцензій GitHub, який визначає / повідомляє про ліцензію репо. Оскільки я запитував про ліцензування / використання файлів LICENSE на GitHub, зокрема, не з відкритим кодом чи git взагалі, спосіб ретрансляції проекту з відкритим кодом також має значення. "Це не ракетна наука" не особливо корисна, btw., Esp. не в контексті мого питання, зосередженого на GitHub.

— Кей

Я можу припустити, що у вашому README є розділ про ліцензування, просто вказавши, що існує декілька ліцензій та повідомляється для кожної ліцензії, ім'я файлу ЛІЦЕНЗІЇ, в якому він знаходиться?

— Ерік Ейдт

@immibis Я знаю про це, і це зовсім не те, в чому моє питання. Я спеціально просив відповіді щодо того, який спосіб має найбільш сенс для людини (на: GitHub).

— Кей

@immibis: "Жоден компілятор не прочитає цього" - проблема полягає в тому, що строго кажучи, це не відповідає Github. Github використовує автоматичний інструмент для визначення "ліцензії", застосованої до вмісту сховища. Ім’я визначеної таким чином ліцензії буде відображатися в заголовку рядка сховища разом з ще деякою більш загальною інформацією, яка надає відвідувачам основне враження від проекту (наприклад, кількість учасників та релізів).

— АБО Mapper

Відповіді:

Ви можете використовувати будь-який механізм, щоб включити ті ліцензії, які вам подобаються, поки відвідувачеві вашого проекту стане зрозуміло, яка ліцензія застосовується до якої частини проекту.

Моїм уподобанням було б:

Помістіть кожну сторонній бібліотеку, яку ви використовуєте, у власну директорію. Цей каталог повинен містити всі файли, що входять до складу розповсюдження бібліотеки, включаючи файли ліцензії та readme.
У власному файлі ліцензії посилайтеся лише на ліцензію власного коду
У файлі readme свого проекту вкажіть, якими сторонніми бібліотеками ви користуєтесь та під якими ліцензіями поширюється кожна бібліотека. Для отримання повної інформації про ліцензії див. Файл ліцензії в каталозі бібліотеки.

— Барт ван Інген Шенау
джерело

Як би ви обробляли свій власний файл ЛІЦЕНЗІЇ у випадку подвійного ліцензування власного вмісту в цьому сценарії? Тобто, якщо ви використовували різні ліцензії для різних частин проекту (код та медіафайли) або якщо ви хотіли поширити свій код під двома (або більше) різними ліцензіями програмного забезпечення? Внесення додаткової інформації в README має багато сенсу, і це те, що я б також зробив, але мене особливо цікавить, як поводитись з файлами LICENSE на GitHub (які, на мої очі, рекомендується давати відвідувачам / глядачам короткий огляд проекту).

— Кей

Якщо (частини) мого власного коду мають двоякову ліцензію, я додаю до проекту два (або більше) ліцензійних файлів, по одному на кожну ліцензію, і в файлі readme буде зрозуміло, яка ліцензія застосовується в такому випадку.

— Барт ван Інген Шенау

Барт, дякую, що поділився тим, як би ти це зробив - це набагато корисніше, ніж деякі коментарі, які я отримав. :) Тим часом я фактично зв’язався з GitHub з цього приводу, і поки залишаю це питання відкритим на випадок, якщо з цього вийде щось.

— Кей

Коли ви отримаєте відповідь від Github, будь ласка, опублікуйте цю інформацію як самостійну відповідь на це питання.

— Барт ван Інген Шенау

Я точно буду, якщо з ними все нормально, як це може бути цікаво знати і іншим!

— Кей

У презентації творців SPDX ( слайд 12 ) дуже ясно:

Зміст LICENSE:

Apache-2.0 OR GPL-2.0-or-later

Ви можете додати два додаткових файли LICENSE тоді: LICENSE.Apache-2.0і LICENSE.GPL-2.0-or-later.

У всіх випадках README.mdповинен містити ідентифікатор ліцензії SPDX :

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

Ви можете це зробити так:

## 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`

Зауважте, що Apache-2.0 OR GPL-2.0-or-laterі Apache-2.0 AND GPL-2.0-or-laterмає велике значення. Перший означає, що користувач може обирати обидва (що є звичайним випадком!), А другий означає, що користувач повинен дотримуватися обох ліцензій. Дивіться також багаторазове ліцензування у Вікіпедії.

Зауважте, що я тут використовую новий (з 2017-12-28 ) SPDX Список ліцензій 3.0. У версіях 2017 року був GPL-2.0ідентифікатор для GPL 2.0, але не було зрозуміло, чи означає це "лише GPL 2.0" або "GPL 2.0 чи будь-яка пізніша версія".

— коппор
джерело

Зрештою, я зв’язався зі службою підтримки GitHub безпосередньо стосовно мого запитання, і вони сказали, що це нормально, коли я даю зрозуміти, що їх відповіді мають на увазі лише як пропозиції, а не рекомендації.

Наразі наша команда не пропонує жодних конкретних рекомендацій, але ми обов’язково поцікавтеся та оновимо вас, якщо у нас є ще щось, щоб поділитися!

Їх оригінальна відповідь мала таке:

Одна з пропозицій - мати один файл ЛІЦЕНЗІЇ для більшості вашого коду та додати текст ліцензій до решти матеріалів сторонніх сторін у файл README.

Ще один спосіб - кожен шлях має свій власний файл ЛІЦЕНЗІЇ, коли це має сенс. Так, якщо, наприклад, ваш сховище має такий шлях: libs / awesome-lib-v2 /, ви могли б мати libs / awesome-lib-v2 / LICENSE.

В останньому випадку ви можете згадати, що у файлі README та / або у файлі LICENSE у вашому корені.

Ви також можете скористатись одним файлом LICENSE у корені вашого сховища та додати підрозділи для будь-якого сторонніх матеріалів, коду тощо.

— Кей
джерело