Открыть список
Как стать автором
Обновить

Комментарии 58

Одновременно разработчик нанимает пользователя (компанию-пользователя) для выполнения работ, связанных с новым кодом, например для тестирования или поиска уязвимостей.

И теперь разработчик будет вынужден платить зарплату пользователю, как своему сотруднику.

Да, все так.
В случае с одиночным пользователем это действительно не выгодно.
А вот для B2B сегмента, где пользователем выступает бизнес, это вполне подходит.
В данной статье указаны действия со стороны заказчика. А если данным приложением/продуктом будет пользоваться уже конечный пользователь (допустим оно даже бесплатное). Пользователь должен/и/или может знать что оно GPL? Может ли пользователь запросить предоставить ему код или нет (у кого? у разрабочиков? у заказчиков?).

Или это всё таки проблема заказчика — получать исходный код по запросу, или с задержкой, согласно заключенных договоров?
Слишком много одновременных допущений. Если речь идет о бизнесе, то давайте говорить только о платных приложения (доработках).

Пользователь GPL продукта имеет право запросить его исходный код.
Однако в случае B2B, пользователем (заказчиком доработок) будет является организация, несмотря на то, что за монитором все равно сидит конечный пользователь.

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

Заказчик запросил разработку приложения/сайта (и т.п.).
Разработчик при разработке использовал какие-то компоненты с лицензиями GPL, которые были слинкованы с его приложением/сайтом и т.п…
Результат оплаченной работы был выложен в маркет приложений.

Конечный пользователь (скачивающий приложение) на свой телефон, компьютер, браузер, может ли знать о том, что это GPL и запрашивать код или нет?
Конечный пользователь должен знать о лицензии, под которой распространяется скачиваемое ПО.

Но немного непонятно, кто выложил результат в маркет приложений?
Разработчик или Заказчик после получения результатов?

Если выложил Заказчик, то конечный пользователь должен запрашивать у него, т.к. Разработчик тут не причем.

А если результат работы выложил Разработчик, то нужно знать, это было сделано с согласия Заказчика, который оплачивал данные работы или же Разработчик так поступил без согласования с Заказчиком?

Интересный подход, но вы не первый с такой идеей, например у onivim (редактор на основе vim) бизнес-модель построена на временном лаге между продажей проприетарного продукта клиенту и отправкой изменений в опен-сорс, лаг составляет 18 месяцев.

У них временной лаг формируется за счет двойного лицензирования:
However, we value open source — and to that end, we've implemented a 'time-delay' open source license. Each commit that makes it to master will be dual-licensed under the permissive MIT license after 18 months. We maintain a separate repo containing the MIT licensed code, which is sync'd daily.

любой пользователь может выложить полученное ПО или его исходники в свободный и бесплатный доступ, что безусловно создаст проблемы с возвратом финансов, вложенных в разработку такого программного продукта

В мире копилефт-софта, первый заказчик оплачивает всю работу.


лицензия «начинает работать» только после перехода прав на результат работы

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

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

Следует помнить, что GPL имеет проверку целостности в восьмом пункте. Думаю, он сильно осложнит любые манипуляции, основанные на локальных юрисдикциях.
Не буду спорить, возможно.
Предложенная схема как раз позволяет распределить затраты одновременно на несколько заказчиков.

Зачем? Почему бы не избежать сложностей с применением лицензии?

Как насчет того, что бы было дешевле для отдельно взятого заказчика?

Это уже сказано выше. Я хочу понимать, в каких случаях имеет смысл брать на себя юридические риски, чтобы уменьшить стоимость решения для каждого конкретного заказчика. Я далёк от бизнеса и могу не видеть очевидных для вас преимуществ такого распределения.

Хороший вопрос. Но тут как раз все просто.

Если Заказчик может оплатить доработки в одиночку, то он так и делает.
Вот только в этом случае ему нет никакого резона этим наработками делиться с другими желающими, которые вполне могут быть его конкурентами.

И даже когда Разработчик спонсирует подобные работы, то ему так же нет резона выкладывает код в свободный доступ.

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

Вот резон. Когда Заказчик оплатил доработки, он заплатил деньгами только за эти доработки. А за исходный софт он заплатил не деньгами, а лицензированием.

Конечно, Заказчик может заплатить деньгами за то и другое, заказав разработку нового ПО с теми же функциями. Однако это станет дороже. Поэтому часть оплаты Заказчик делает натурой, программой.

Он делится, чтобы не платить деньгами за разработку с нуля. Кооперация здесь работает изначально, уже с того момента, когда Заказчик впервые применил свободное ПО.
Согласно условиям GPL, Заказчик имеет право получить исходный код доработок по первому требованию без каких либо условий.

И я не понимаю, что означают фразы «А за исходный софт он заплатил не деньгами, а лицензированием.» и «Поэтому часть оплаты Заказчик делает натурой, программой.»
Можете привести реальный пример данных финансовых отношений?
Они означают, что Заказчик не оплатил создание исходной программы деньгами, зато оплатил это создание, лицензируя свою добавку. Вместо того, чтобы передать авторам программы деньги за их работу, Заказчик передал им свой код за их работу.
Они означают, что Заказчик не оплатил создание исходной программы деньгами, зато оплатил это создание, лицензируя свою добавку.
Тут нет экономических взаимоотношений, т.к. Заказчик берет исходную программу даром вне зависимости от своих дальнейших намерений что-то кому-то передать.

Вместо того, чтобы передать авторам программы деньги за их работу, Заказчик передал им свой код за их работу.
Подождите, если Заказчик сам пишет код, то это Разработчик.
А если код пишет Разработчик по заданию Заказчика, а Заказчик расплачивается с ним, его же написанным кодом, то тут очень интересная экономика получается ;-)
В соответствии с комментариями FSF в этом случае существует законная возможность ограничить распространение тестируемого кода на время действия соответствующего договора.

А если заказчик после получения продукта разорвёт соответствующий договор и сразу запросит исходники?

А кто мешает в договоре прописать неустойку при досрочном расторжении договора?
И на каком основании заказчик будет требовать исходники, если он сам и расторг договор?
И на каком основании заказчик будет требовать исходники, если он сам и расторг договор?

А, то есть в договоре будет стоять что-то типа «при досрочном разрыве контракта со стороны тестировщика, он обязан удалить все свои копии продукта».

Похоже действительно сработает. Тем более, при современном подходе «тяп-ляп и в продакшн», каждый пользователь — тестировщик. :)
Мне вот больше всегда был интересен такой момент. Допустим, есть программа, которую я написал, и распространяю, одновременно под GPL, и под коммерческой лицензией. Один из пользователей GPL версии нашёл баг, исправил его, и прислал мне патч. Если я приму этот патч, то он ведь тоже под GPL? И я лишаюсь возможности распространять дальнейшие версии под коммерческой лицензией? Получается, единственный способ развивать такой продукт — делать это в одиночку? А если у меня будет юридическое лицо, и программу пишут штатные сотрудники? Могут ли они впоследствии предъявить какие-то претензии к двойному лицензированию?
Это очень легко обходится, если при передаче патча передаются и права на него. И тогда уже вы, как его владелец, вольны делать с ним что угодно, в том числе выпустить под двойной лицензией.
Или просто пункт c галочкой: «При отправке патча пользователь соглашается на его включение в коммерческую версию».

И по такой схеме работают большинство компаний.
НЛО прилетело и опубликовало эту надпись здесь
Как по мне, то термин «пиратство» значительно более крутая придумка копирастов.
Ну тогда уже называйте своими именами — пермиссивная лицензия, если уж GPL вирусная. А то получается однобокая субъективщина судя по используемым определениям.
Слово «пермиссивная», это англицизм и он мне не нравится.
Тогда уж лучше «разрешительная» ;-)
Опять же, если сослаться на википедию, откуда вы взяли слово «разрешительный»(потому как в русскоязычной IT среде такой термин не употребляют, вместо него — пермиссивный, безо всяких переводов), то ясно откуда ноги растут у названия «вирусный». Хотя такие лицензии принято называть копилефт, о чем вы вскользь упомянули.
Их принято называть и так и эдак, причем без негативной коннотации www.gnu.org/philosophy/vaccination.en.html
Но на сайте GNU и FSF действительно не используется термин viral.
Поэтому правильнее будет использовать термит Copyleft.
НЛО прилетело и опубликовало эту надпись здесь
Понятие «вирусная лицензия» описано в самой статье.
НЛО прилетело и опубликовало эту надпись здесь

А как назвать лицензию, которую нельзя вырубить из исходного кода?

НЛО прилетело и опубликовало эту надпись здесь
Может ли производитель программы под лицензией GPL, «обойти» её таким образом: открыть (компонент, связующий компоненты — «прокси» между разными лицензиями), выпустив его под лицензией GPL v2 (позволяющая использовать бинарные модули без открытия кода). Далее согласно GPL v2, открыть исходный код данного модуля.
А саму программу, в виде бинарного модуля, которая подключается к GPL v2, уже можно и не открывать и не лицензировать под GPL?

Самый известный пример — ядро линукс под GPL v2, получающие бинарные блобы прошивок и драйверов под железо.
Использование промежуточной лицензии, только не GPL v2, а LGPL www.gnu.org/licenses/lgpl-3.0 (https://ru.wikipedia.org/wiki/GNU_Lesser_General_Public_License), это стандартный способ связывания проприетарного и свободно ПО, где есть четкое разделение кода на модули.

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

Про AGPL (Affero) ничего к сожалению не рассказано… Вот там действительно ад для бизнеса.

Это действительно так:
Стандартная общественная лицензия GNU Афферо — модифицированная версия обычной GNU GPL версии 3. В ней добавлено одно требование: если вы выполняете измененную программу на сервере и даете другим пользователям общаться на нем с этой программой, ваш сервер должен также позволять им получить исходный текст, соответствующий той модифицированной версии программы, которая выполняется на сервере.
Но много ли вы знаете проектов, которые выходят под этой лицензией?
ваш сервер должен также позволять им получить исходный текст

Ссылка на гит считается?

Да, если он содержит действительно актуальную версию серверного приложения.

Ну, например вот список: https://en.wikipedia.org/wiki/List_of_software_under_the_GNU_AGPL


Там парочка приватных клаудов, ghostscript и т.п. Пока меня это лично не задевает, но всякое может случится.


С кодом, который выложен под BSD, но запатентован, уже встречался.

Спасибо за список! Специально не искал, но теперь буду знать о его наличии.

И теперь задумался. Ведь не так уж мало проектов под этой лицензией.
Более того, наверно четверть из них я знаю, а с некоторыми даже и работал (хотя на лицензию не обращал внимания, т.к. на тот момент это не требовалось)
Оба варианта интересны, но я сомневаюсь, что хоть одна более или менее крупная и адекватная компания в Россий (как заказчик) захочет ввязаться в такую аферу с другой компанией (типа разработчиком — модификатором gpl софта)
А почему использован термин «афера»?
Вы где-то увидели нарушение лицензии или законодательства?

Или считаете, у нас уже все настолько привыкли заимствовать код в нарушение GPL и жить «по понятиям», что это будет меньшим злом по сравнению с юридически правильным оформлением договора?
Ну вот смотрите, пример из жизни. Я работаю в компании А, беру GPLv2 продукт, дорабатываю и хочу продать компании Б только бинарную версию (без исходников разумеется). Компания Б — это крупный Российский ритейл. Компания А предоставляет уже компании Б какие-то ИТ услуги, ИТ-аутсорсинг. Изначально А не планировала вести бизнес с Б по какой-то другой модели и у А не было этого модифицированного ПО (было свое — убогое).
А тут получается, что А нужно заключить с Б какой-то там доп. договор о доработке какого-то ПО, какого? За каким чертом компании Б ввязываться в доработку какого-то ПО? Б говорит — мы не хотим чтобы Вы что-то дорабатывали, продайте нам свой продукт, мы его будем использовать, и? Приплыли. Если А продает Б модифицированный GPL продукт, то на следующий день они попросят его исходный код и А будет обязана его отдать — приплыли.
В компании Б тоже не дураки работают, они наверняка знают все эти фишки с СПО.
Вот и попробуйте заработать на GPL.
беру GPLv2 продукт, дорабатываю и хочу продать компании Б только бинарную версию (без исходников разумеется).
продайте нам свой продукт, мы его будем использовать, и? Приплыли.

А с чего вы взяли, что «взяв GPLv2 продукт», он вдруг стал вашим? Из-на получения исходников права на продукт к вам не перешли.
Поэтому Б совершенно правы, требуя у вас модифицированные исходники. Ровно для защиты пользователей от подобных схем GPL и создавался.

Но, с помощью способа, изложенного в статье, у вас появляется возможность работать без нарушения лицензии. Вы как и прежде будете обязаны передавать исходники, но дальше Заказчика они какое-то время не пойдут.
А с чего вы взяли, что «взяв GPLv2 продукт», он вдруг стал вашим? Из-на получения исходников права на продукт к вам не перешли.


Интеллектуальные права не перешли, тут спору нет. Но как Вы тогда объясните метод создания форка проекта, далее смены имени проекта и дальнейшее его существование и даже продажу наработок. Да код этого форка остается открытым и доступным всем, но по сути прав у них на код никаких нет, они трудятся что называется в пустую? Завтра к ним придет изначальный владелец интеллектуальных прав и скажет: «Прикрывайте лавочку, код мой» и он будет прав?

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


То есть все равно, даже если мы подпишем договор о доработке, опишем тестовый период 12 мес. и в эти 12 мес. с меня могут запросить код и я должен его буду отдать? Если так, то где гарантия, что этот код не выложат в сеть, ведь это GPL?
но по сути прав у них на код никаких нет, они трудятся что называется в пустую? Завтра к ним придет изначальный владелец интеллектуальных прав и скажет: «Прикрывайте лавочку, код мой» и он будет прав?
Нет, не прав. GPL защищает и от такого поворота событий. Изначальный владелец не может начать «крутить педали назад». Поэтому ранее полученный код так и останется у вас. Причем лично ваши наработки, будут только вашими.

То есть все равно, даже если мы подпишем договор о доработке, опишем тестовый период 12 мес. и в эти 12 мес. с меня могут запросить код и я должен его буду отдать?
Код должны будете отдать.

Если так, то где гарантия, что этот код не выложат в сеть, ведь это GPL?
Как гарантировать сохранность кода от публикации в сети написано в статье.
Как гарантировать сохранность кода от публикации в сети написано в статье.


ну то есть вот:

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


То есть я черным по белому в договоре должен написать: На период тестовой обкатки доработанного софта Вы не вправе его передавать третьим лицам ни под каким предлогом?

Какая-то странная схема получается. Тогда вопрос: А что будет если заказчик захочет сократить срок обкатки, под соусом все отлично работает, меня устраивает? Да, Вы скажите это юридические тонкости, как напишите договор так и будет, но этот сценарий возможен.
А что будет в случае досрочного расторжения договора стороной заказчик до исполнения срока обкатки, ну скажем через 1 месяц? Они получат право выложить код?
Да, как напишите. Например так:
«Заказчик принимает на себя обязательства провести тестирование программного продукта в течение 12 месяцев.
Во время выполнения своих контрактных обязательств, обязуется не разглашать переданную ему материалы в соответствии с подписанным соглашением о не разглашении.
В случае досрочного расторжения договора, Заказчик обязуется выплатить неустойку в размере ...».
Спасибо за разъяснения. Теперь появился некоторый просвет.
А мне вот интересно, на сколько легальна «схема», которую я встречаю:
  1. Делаем некий тул bicycle
  2. Открываем это под opensource свободно
  3. Собираем коммьюнити, развиваем проект
  4. Пользуемся балагами сервисов, который предоставляют опенсорсным проектам плюшки бесплатно (ci/bugtracker/wiki/tools/etc)
  5. Покупаем торговую марку «My Bicycle» и вешаем на бинарники коммерческую лицензию.


Как результат: исходники вот они, все «белые и пушистые». Но как только ты эти исходники собрал — бинарник под лицензией. И тут тонкая грань, что сам по себе бинарник может и не быть под лицензией, но его имя — трейдмарк и просто так пользоваться этим нельзя. Толку от исходников, если на выходе «тыква»? Форкать и бегать sed-ом…
Сразу на ум приходят TrueCrypt и Drupal.
И так делают очень даже многие.
Но с помощью торговой марки нельзя защитить исходники, только название проекта.
В том смысле, что коммерческая лицензия никак не зависит от наличия торговой марки.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.