Использование разных лицензий для разных веток одного репозитория
У меня есть репозиторий Git со средним проектом на GitHub. Поскольку некоторые компоненты зависят от библиотек GPL, репозиторий в настоящее время также находится под лицензией GPL. Однако библиотека под лицензией GPL используется только некоторыми компонентами (которые могут быть изолированы), а остальная часть проекта вполне может использоваться без этих компонентов. Поэтому я хочу лицензировать все, что не зависит от каких-либо библиотек GPL, под лицензией MIT. Каковы лучшие практики для этого?
Моя идея состоит в том, чтобы иметь две разные ветки: одна ветка содержит полный код и распространяется под лицензией GPL. Другая ветвь удаляет все функциональные возможности, зависящие от кода GPL, и распространяется под лицензией MIT. Возможно ли и / или распространено ли иметь разные лицензии для разных веток одного и того же репозитория? Если нет, то какие альтернативы лучше?
Может ли быть проблемой то, что технически полная история этой новой ветки без лицензии GPL когда-то включала код GPL? Или это нормально, если весь GPL-код будет удален из этой ветки, прежде чем я добавлю новый файл лицензии MIT в ветку?
Обратите внимание, что этот вопрос в чем-то похож, но мне кажется, что мой больше касается технической реализации . То есть я могу просто поместить два разных файла LICENSE в корневой каталог репозитория, в зависимости от того, в какой ветке мы сейчас находимся?
Ответы
Ветви Git не очень хорошо подходят для поддержки разных «редакций» одного и того же проекта, потому что нет хорошего способа поделиться изменениями между ветвями без их полного слияния. Поэтому просто по техническим причинам я настоятельно рекомендую вам не использовать ветки с другой лицензией. Такие ветки также не очень заметны для пользователей.
Вместо этого храните весь код в одной основной ветке, но храните код с разной лицензией в разных папках и четко укажите, какой код под какой лицензией.
GPL не требует, чтобы любой последующий код находился под GPL. Это требует, чтобы любые производные работы (в целом) находились под той же лицензией GPL. Но это может быть удовлетворено, если любые компоненты, которые вы написали сами, находятся под лицензией, совместимой с GPL, такой как MIT. Во избежание сомнений вы также можете использовать двойную лицензию на эти компоненты как «MIT или GPL». Это важно для несовместимых лицензий, например, «только для Apache-2.0 или GPL-2.0».
Таким образом, лучше всего было бы отделить части под GPL от частей, которые вы написали полностью самостоятельно, и использовать ЛИЦЕНЗИЮ верхнего уровня, чтобы описать, какие части доступны по какой лицензии. Если вы хотите сделать это предельно точно, вы даже можете принять машиночитаемый copyrightформат файлов Debian, который связывает глобальные шаблоны с лицензиями. Вы можете хранить полный текст лицензии либо в тот же файл лицензии, или , может быть , как отдельные файлы , такие как LICENSE.GPL.txt, LICENSE.MIT.txtили в соответствующих каталогах.
Поскольку в настоящее время вы предлагаете весь код под GPL, перемещение MIT для некоторых частей потребует повторного лицензирования . Это тривиально, если вы единственный участник, потому что вы, как единственный правообладатель, можете выдавать лицензии, как хотите. Но если есть другие участники, вам нужно будет получить их согласие на перелицензирование или удалить их вклад (что может быть чрезвычайно сложно, потому что обычно требуется переписать компонент, начиная с последнего состояния перед вкладом под GPL). Я не думаю, что имеет значение то, что в истории Git будут показаны те же файлы, что и под GPL, даже после перелицензирования. Старая лицензия все еще действительна для этих старых версий, новая лицензия все еще действительна для этих новых версий.