LINUX.ORG.RU

Лицензирование интерфейса плагина

 , ,


1

1

Привет!

Есть проект (не мой) под лицензией GPL 3, в котором я хочу часть функциональности вынести в плагин и оформить это в виде подключаемых во время запуска библиотек. Для этого будут созданы заголовочники с описанием интерфейса плагина.

И тут возникло несколько вопросов по лицензированию:

  1. Если заголовочники интерфейса под GPL, то должен ли сторонний разработчик плагина тоже использовать GPL?
  2. Если ответ по первому пункту положительный, то можно ли в рамках текущего проекта для вновь созданных заголовочники указать другую лицензию, скажем LGPL или MIT?

https://www.gnu.org/licenses/gpl-faq.html#GPLPlugins
https://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins

If the main program and the plugins are a single combined program then this means you must license the plug-in under the GPL or a GPL-compatible free software license and distribute it with source code in a GPL-compliant way.

можно ли в рамках текущего проекта для вновь созданных заголовочники указать другую лицензию, скажем LGPL или MIT?

Можно, они совместимые, но дело не столько в заголовочнике, сколько в линковке. Сам плагин тоже должен быть под GPL-совместимой лицензией.

xaizek ★★★★★
()
Ответ на: комментарий от xaizek

«single combined program» надо понимать в том смысле, что плагин предназначен для одной программы?

можно ли в рамках текущего проекта для вновь созданных заголовочники указать другую лицензию, скажем LGPL или MIT?

Можно, они совместимые

Насколько я раскурил GPL v.2, вновь созданные файлы должны иметь ту же лицензию, что и весь проект, но при этом я как автор могу навесить на эти файлы и другие лицензии. GPL v.3 гораздо витееватей и без литра не разобраться.

Сам плагин тоже должен быть под GPL-совместимой лицензией.

Ну это я уже понял, GPL – липкая фигня.

Но всё же интересен такой вопрос – распространяется ли лицензия API на реализацию этого API.

RussianWarShip
() автор топика
Ответ на: комментарий от RussianWarShip

«single combined program» надо понимать в том смысле, что плагин предназначен для одной программы?

Нет, это значит, что плагин и основная программа образуют единую сущность, если они взаимодействуют нетривиальным образом.

Насколько я раскурил GPL v.2, вновь созданные файлы должны иметь ту же лицензию, что и весь проект, но при этом я как автор могу навесить на эти файлы и другие лицензии.

«combined program» должна иметь GPL, но куски могут быть под разными лицензиями, но совместимыми с GPL.

GPL v.3 гораздо витееватей и без литра не разобраться.

Не думаю, что там что-то из этого поменяли.

Но всё же интересен такой вопрос – распространяется ли лицензия API на реализацию этого API.

Тут сложно, но не думаю. Google c Oracle не по этому поводу сидились? Google, вроде, выиграл возможность реализовать независимое идентичное API.

xaizek ★★★★★
()
Ответ на: комментарий от RussianWarShip

Что должен или не должен делать сторонний разработчик плагина очень зависит от архитектуры продукта и политики проекта. Как пример - можно сделать возможность писать плагины на bash или COBOL например, или С#, и никто не заставит стороннего разработчика такого плагина придерживаться GPL v. xxx. Обычно делается страница с политикой проекта, если он такой большой, с плагинами, и там расписывается что плагинописатель сего проекта должен открывать и что нет. То есть автор проекта должен сам сформулировать правила для сторонних разработчиков, а не GNU Foundation.

spring
()
Последнее исправление: spring (всего исправлений: 2)
Ответ на: комментарий от spring

То есть автор проекта должен сам сформулировать правила для сторонних разработчиков, а не GNU Foundation.

Выбор лицензии для проекта – это и есть свод правил для разработчиков. Если же я начну выставлять дополнительные условия, это может сделать меня нарушителем GPL.

RussianWarShip
() автор топика
Ответ на: комментарий от RussianWarShip

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

spring
()
Последнее исправление: spring (всего исправлений: 2)
7 июля 2022 г.

да, хедеры должны быть по GPL, как и тот, кто их жрет.

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

Тогда клиент сможет сам скачать себе этот опенсорсный GPL код и юзать тебе (и себе) на радость.

max_lapshin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.