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

28

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

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

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

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

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

Кей
источник
2
Таким образом, есть README и один или несколько файлов LICENSE. Это не ракетостроение.
Роберт Харви
4
Что касается связанной страницы: она не имеет никакого отношения к распространению файлов лицензий, это связано с API лицензий GitHub, который определяет / сообщает о лицензии репо. Поскольку я спрашивал о лицензировании / использовании файлов LICENSE на GitHub, а не с открытым исходным кодом или git в целом, то, как проект с открытым исходным кодом «изображается» для лицензирования, также имеет значение. «Это не ракетостроение» не особенно полезно, кстати, особенно. не в контексте моего GitHub-ориентированного вопроса.
Кей
2
Я мог бы предположить, что в вашем README есть раздел о лицензировании, в котором просто указывается, что существует несколько лицензий, и для каждой лицензии указывается имя файла LICENSE, в котором он находится?
Эрик Эйдт
3
@immibis Я знаю об этом, и это совсем не то, о чем был мой вопрос. Я специально просил дать ответ относительно того, «какой путь имеет наибольшее значение для людей» (на: GitHub).
Кей
3
@immibis: «Ни один компилятор не будет читать его» - проблема в том, что, строго говоря, это не относится к Github. Github использует автоматический инструмент для определения «лицензии», применяемой к содержимому репозитория. Имя определенной таким образом лицензии будет затем отображаться в строке заголовка репозитория вместе с некоторой более общей информацией, которая дает посетителям общее представление о проекте (например, количество участников и выпусков).
ИЛИ Mapper

Ответы:

15

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

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

  • Поместите каждую стороннюю библиотеку, которую вы используете, в отдельный каталог. Этот каталог должен содержать все файлы, которые являются частью дистрибутива библиотеки, включая файлы лицензии и readme.
  • В вашем собственном файле лицензии, обратитесь только к лицензии вашего собственного кода
  • В файле readme вашего проекта укажите, какие сторонние библиотеки вы используете и под какой лицензией распространяется каждая библиотека. Для получения полной информации о лицензии обратитесь к файлу лицензии в каталоге библиотеки.
Барт ван Инген Шенау
источник
1
Как бы вы обработали свой собственный файл LICENSE в случае двойного лицензирования собственного содержимого в этом сценарии? То есть, если вы использовали разные лицензии для разных частей проекта (код или файлы мультимедиа) или если вы хотели распространять свой код под двумя (или более) разными лицензиями на программное обеспечение? Размещение дополнительной информации в README имеет большой смысл и является тем, чем я бы занимался, но меня особенно интересует, как обращаться с файлами LICENSE на GitHub (который, на мой взгляд, рекомендуется давать посетителям / зрителям краткий обзор проекта).
Кей
1
Если (части) моего собственного кода имеют двойную лицензию, я бы добавил в проект два (или более) файла лицензии, по одному на каждую лицензию, и в файле readme ясно указал, какая лицензия применяется в каком случае.
Барт ван Инген Шенау
1
Барт, спасибо, что поделился, как ты это сделаешь - это намного полезнее, чем некоторые из моих комментариев. :) Между тем я действительно связался с GitHub по этому поводу и пока оставлю этот вопрос открытым, если что-нибудь из этого получится.
Кей
2
Когда вы получите ответ от Github, опубликуйте эту информацию в качестве самостоятельного ответа на этот вопрос.
Барт ван Инген Шенау
1
Я определенно буду, если с ними все в порядке, так как это может быть интересно узнать и другим!
Кей
12

В презентации создателей 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 или любую более позднюю версию».

koppor
источник
4

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

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

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

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

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

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

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

Кей
источник