LINUX.ORG.RU

Разработка софта в мире GNU GPL

 ,


1

1

Добрый день, уважаемый Всем!

Возник вопрос по теме следующий: есть мир свободно-распространяемого софта под лицензией GNU GPL и не важной какой версии. Если я беру исходные тексты любой программы, модифицирую их (не трогая копирайты или лефты немодифицированных участков исходников) и получаю на выходе бины, которые собираюсь продавать кому-то, то в соответствии с правилами лицензии GNU GPL, я обязан вместе с бинами поставить и исходные тексты, из которых эти бины получились (кстати как это можно проверить?). С этим всё ясно и понятно.

Но как быть, если я собираюсь разработать софт с нуля, не основываясь на модификации исходников чьей-то программы, и также продавать этот софт другой стороне? Софт будет работать под Линуксом (Debian или CentOS), а это GNU GPL. Соответственно должна ли моя разработка быть выпущена также под лицензией GNU GPL?

ПС: разрабатываемый софт будет использовать вызовы функций API системных библиотек под лицензией GPL/LGPL.

Спасибо.

Но как быть, если я собираюсь разработать софт с нуля, не основываясь на модификации исходников чьей-то программы, и также продавать этот софт другой стороне? Софт будет работать под Линуксом (Debian или CentOS), а это GNU GPL.

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

anonymous ()

Но как быть, если я собираюсь разработать софт с нуля, не основываясь на модификации исходников чьей-то программы, и также продавать этот софт другой стороне? Софт будет работать под Линуксом (Debian или CentOS), а это GNU GPL. Соответственно должна ли моя разработка быть выпущена также под лицензией GNU GPL?

Нет, не должна.

Deleted ()
Ответ на: комментарий от anonymous

Не, мне не надо добавляться в репы и уровень востребованности моего софта меня не очень волнует. Забыл упомянуть в начальном сообщении о такой особенности, что разрабатываемый мной софт будет работать не просто в «воздухе» под Дебиан или ЦентОСью. Планируется, что он будет юзать API известного софта под GNU GPL. Как в этом случае?

Ramirezkiv2 ()
Ответ на: комментарий от Deleted

Забыл упомянуть в начальном сообщении о такой особенности, что разрабатываемый мной софт будет работать не просто в «воздухе» под Дебиан или ЦентОСью. Планируется, что он будет юзать API известного софта под GNU GPL. Как в этом случае?

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

Планируется, что он будет юзать API известного софта под GNU GPL. Как в этом случае?

Значит ты используешь гну гпл софт для своего софта. Смотри, какие есть условия для такого использования. Все просто.

anonymous ()
Ответ на: комментарий от Ramirezkiv2

Забыл упомянуть в начальном сообщении

Его можно редактировать.

он будет юзать API известного софта под GNU GPL

Что за API? Какая-то библиотека? Под какой именно она лицензией? Если LGPL, то там дополнительные условия, но исходники можно не раскрывать.

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

Забыл упомянуть в начальном сообщении о такой особенности, что разрабатываемый мной софт будет работать не просто в «воздухе» под Дебиан или ЦентОСью. Планируется, что он будет юзать API известного софта под GNU GPL. Как в этом случае?

Если GPL, то ты не можешь проприетарным кодом линковаться к нему.

Если LGPL, то ты можешь проприетарным кодом линковаться к нему динамической линковкой. Если линкуешься статически, то обязан поставлять объектные модули, чтобы пользователь мог их при желании линковать к модифицированному LGPL-коду.

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

Понятия, честно говоря не имею какая там линковка будет - софт только планируется разработать и написать код. В Сях включу заголовки и буду звать функции - какая линковка? Насколько я знаю LGPL позволяет не раскрывать код разрабатываемого пропиетарного софта в случае создания только библиотек (кодеков например - где применяется ноу-хау), а не всего софта включая службы, беки, фронты и прочие ГУИ.

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

У них лежат обе лицензии LGPL и GPL, в их коде LGPL в комментариях. Я так понимаю, что они используют GNU lib, а она под GPL, значит libvirt в целом как производная работа тоже должна быть как GPL по-идее.

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

А какже тогда LGPL? Хотя какая разница? Всё равно он только для разработки библиотек, а не всего софта. Однако непонятно как другие конторы, использующие libvirt могут выпускать свой софт под лицензией Apache license, которая разрешает закрывать разрабатываемый софт.

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

Цитата с сайта: https://www.gnu.org/licenses/gpl-faq.ru.html#IfLibraryIsGPL

Вопрос: Если библиотека выпускается на условиях GPL (не LGPL), значит ли это, что любая программа, которая ею пользуется, должна выпускаться на условиях GPL или совместимой с GPL лицензии? (#IfLibraryIsGPL)

Ответ: Да, потому что программа в действительности объединяется с библиотекой. Таким образом, условия GPL распространяются на всю комбинацию. Программные модули, которые связываются с библиотекой, могут быть под различными совместимыми с GPL лицензиями, но произведение в целом должно лицензироваться по GPL. См. также Что означают слова “лицензия совместима с GPL”?

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

Цитата с сайта: https://www.gnu.org/licenses/gpl-faq.ru.html#IfLibraryIsGPL

Вопрос: Отличаются ли требования GPL к статической компоновке модулей с произведением, на которое распространяется GPL, от требований к динамической компоновке? (#GPLStaticVsDynamic)

Ответ: Нет. Компоновка произведения, на которое распространяется GPL, статическая или динамическая, с другими модулями, приводит к появлению комбинированного произведения, производного от этого произведения под GPL. Таким образом, условия Стандартной общественной лицензии GNU распространяются на всю комбинацию. См. также наш ответ на вопрос о применении несовместимых с GPL библиотек.

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

Цитата с сайта: https://www.gnu.org/licenses/gpl-faq.ru.html#IfLibraryIsGPL

Вопрос: Отличаются ли требования LGPL к статической компоновке модулей с произведением, на которое распространяется LGPL, от требований к динамической компоновке? (#LGPLStaticVsDynamic)

Ответ: С точки зрения удовлетворения условиям LGPL (любой существующей на данный момент версии: 2, 2.1 или 3),

(1) Если вы статически компонуете с библиотекой под LGPL, вы должны предоставить свое приложение в формате объектного кода (не обязательно исходного текста), с тем чтобы у пользователя была возможность изменить библиотеку и перекомпоновать приложение.

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

Ramirezkiv2 ()

Теперь остаётся выяснить - вызов из разрабатываемого ПО функций API системного софта под лицензией GPL/LGPL - является ли случаем получения комбинированного результата или нет?

Если является, то в моём случае я не смогу закрыть свои исходники при распространении своего софта.

А если не является, то смогу.

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

Однако непонятно как другие конторы, использующие libvirt могут выпускать свой софт под лицензией Apache license, которая разрешает закрывать разрабатываемый софт.

Так же как libvirt лицензирована под LGPL, хотя по факту GPL. Это чтобы их код можно было брать и переиспользовать в других местах. И так они могут свой код с libvirt выкладывать под любой лицензией, которая совместима с GPL.

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

Хотя в README вот это:

License
-------

The libvirt C API is distributed under the terms of GNU Lesser General
Public License, version 2.1 (or later). Some parts of the code that are
not part of the C library may have the more restrictive GNU General
Public License, version 2.1 (or later). See the files `COPYING.LESSER`
and `COPYING` for full license terms & conditions.
Т.е. GNU lib, видимо, в утилитах используется, а не в самой библиотеке. Тогда она под LGPL.

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

Т.е. GNU lib, видимо, в утилитах используется, а не в самой библиотеке. Тогда она под LGPL.

LGPL предназначена для разработки библиотек. В моём случае она не удовлетворяет мои запросы - она не позволит закрыть мне мои исходники на GUI, службы и прочее при продаже/распространении.

Ramirezkiv2 ()
Ответ на: комментарий от anonymous

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

Немного не понял - где «там»? Я не хочу лицензировать ничего чужого, мне надо закрыть только своё. Кстати, от кого и как можно получить по шапке? Как и кто узнает, если я исходники не предоставлю и скажу, что всё что я поставляю - только моё пропиетарное? Просто интересно.

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

Если чужая библиотека под LGPL, ты просто линкуешься к ней и не паришься. Для этого LGPL и придумана.

Вот если она под GPL, то ночью к тебе явится Столлман и будет до утра заставлять отлаживать код емакса в наказание.

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

Если чужая библиотека под LGPL, ты просто линкуешься к ней и не паришься. Для этого LGPL и придумана.

Мысль понятна, только вот хотелось бы ещё увидеть, где это прописано в тексте лицензии LGPL, что можно линковаться и не париться.

Также ещё не понятно, если я обращаюсь к функциям заимствованного софта под LGPL2.0 из своей проги, включением заголовков через директиву include в сях - является это линкованием или это комбинация софта моего и LGPL'ного?

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

Мысль понятна, только вот хотелось бы ещё увидеть, где это прописано в тексте лицензии LGPL

Ты её прочти, там всё ясно написано английским по белому.

включением заголовков через директиву include в сях - является это линкованием или это комбинация софта моего и LGPL'ного?

Раздел 3:

3. Object Code Incorporating Material from Library Header Files.

The object code form of an Application may incorporate material from a header file that is part of the Library. You may convey such object code under terms of your choice, provided that, if the incorporated material is not limited to numerical parameters, data structure layouts and accessors, or small macros, inline functions and templates (ten or fewer lines in length), you do both of the following:

a) Give prominent notice with each copy of the object code that the Library is used in it and that the Library and its use are covered by this License. b) Accompany the object code with a copy of the GNU GPL and this license document.

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

LGPL предназначена для разработки библиотек.

Это лишь основное предназначение. Всё она удовлетворяет. devzero дело говорит. FAQ и сам текст лицензии помогут прояснит детали (там надо ещё разрешать пользователю декомпиляцию с целью отладки библиотек под LGPL, например).

xaizek ★★★★★ ()

Просто если ты не будешь разрабатывать софт под GPL или хотя бы LGPL, тебя обзовут мудозвоном и пидаром. А в остальном - твои дела.

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

Ладно. Спасибо за ответы я понял. Ещё один вопросик в догоночку: если я беру и пересобираю Linux через make menuconfig просто исключая определённые функциональные возможности без изменения и правки исходников линукса, чтобы сделать дистрибутив более легковесным под свои задачи, докладываю к полученному бинарники своих разработок и получаю загрузочный дистрибутив, то в конечном итоге полученное «творение» являться будет чем? Это будет считаться модификацией исходных текстов линукса?

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

Не думаю, что это будет модификацией. Хотя может конфиг с опциями сборки ядра надо предоставлять, не уверен, но его и скрывать особо нечего. А так само ядро, утилиты и проприетарная программа будут считаться отдельными частями и могут быть под разными лицензиями. Понятие производной работы в целом несколько расплывчатое, но взаимодействие через универсальные интерфейсы (API ядра, конвеер, сокеты, терминал) не создают производную работу.

xaizek ★★★★★ ()