Объявление нескольких лицензий в проекте GitHub

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

Сейчас я нахожусь в ситуации, когда я работал над небольшим проектом с некоторыми другими людьми, который требует упоминания нескольких лицензий (из-за стороннего кода и библиотек, а также файлов без кода). В то время как мои партнеры относятся к этой проблеме довольно «небрежно» - было предложено, чтобы я «просто поместил код онлайн как есть, никто не будет заботиться» - я бы предпочел сделать это правильно. Проблема в том, что я не знаю, как можно упомянуть несколько (разных) лицензий на GitHub.

Я видел несколько разных решений на GitHub, поэтому мне трудно судить, является ли этот ответ на немного другой вопрос авторитетным. То, что я хотел бы знать, это то, что из следующего - если есть - является наиболее распространенным, или, если есть другие, дополнительные способы сделать это.

1. Создайте один файл LICENSE и поместите в него описания всех различных лицензий. ( Вопросы : должны ли они быть размещены в определенном порядке? Начну ли я с упоминания имен всех лицензий, содержащихся в них, для лучшего обзора)?
2. Создайте один файл лицензии на лицензию , используемой и назвать их LICENSE.md, LICENSE.LibNameA.md, и LICENSE.AssetsB.mdт.д. , как предложено в связанном ответ. ( Вопрос : наименование будет основываться на именах проектов? Не на именах лицензий. Если бы я использовал более одной лицензии для материалов, представленных самостоятельно, я бы упомянул их все в «основном» LICENSE.md? Если нет, что бы я делал вместо этого?)
3. Создайте два файла LICENSE : один список лицензий для «основного» содержимого, т. Е. Весь код / ​​активы, которые он сам создал; один для всех сторонних материалов. ( Вопросы, как указано выше : есть ли конкретная схема именования, которую можно использовать, и порядок, в котором будут перечислены материалы третьих сторон?)

Наконец, если я правильно понял различные пояснения и проекты GitHub, касающиеся их API лицензий, при определении лицензии репо будет учитываться только «основной» файл LICENSE (хотя я не смог выяснить, какая лицензия будет выбрана) если бы несколько было упомянуто).

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

Мое предпочтение будет:

• Поместите каждую стороннюю библиотеку, которую вы используете, в отдельный каталог. Этот каталог должен содержать все файлы, которые являются частью дистрибутива библиотеки, включая файлы лицензии и readme.
• В вашем собственном файле лицензии, обратитесь только к лицензии вашего собственного кода
• В файле readme вашего проекта укажите, какие сторонние библиотеки вы используете и под какой лицензией распространяется каждая библиотека. Для получения полной информации о лицензии обратитесь к файлу лицензии в каталоге библиотеки.

В презентации создателей SPDX ( слайд 12 ) это очень ясно:

Содержание LICENSE:

Apache-2.0 OR GPL-2.0-or-later

Затем вы можете добавить два дополнительных файла ЛИЦЕНЗИИ: 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 по поводу моего вопроса, и они сказали, что можно цитировать их, если я поясню, что их ответы предназначены только для предложений, а не для рекомендаций.

В настоящее время наша команда не имеет каких-либо конкретных рекомендаций, но мы обязательно проконсультируем вас и проинформируем вас, если у нас есть что-то еще, чем можно поделиться!

Их первоначальный ответ содержал следующее:

Одно из предложений - иметь один файл LICENSE для большей части вашего кода и добавить текст лицензий для остальных материалов третьих лиц в ваш файл README.

Другой способ - для каждого пути иметь свой собственный файл LICENSE, когда это имеет смысл. Так что, если, например, ваш репозиторий имеет следующий путь: libs / awesome-lib-v2 /, у вас может быть libs / awesome-lib-v2 / LICENSE.

В последнем случае вы можете указать это в файле README и / или в файле LICENSE в корневом каталоге.

Вы также можете рассмотреть возможность использования только одного файла LICENSE в корне вашего репозитория и добавить подразделы для любого стороннего материала, кода и так далее.