Коммерциализаия СПО под GPL лицензией

Фонд поддержки и развития делового свободного программного обеспечения “Адемпиере”

Авторы:
Александр Рябиков,
Сергей Середа, к.э.н.,

Коммерциализаия СПО под GPL лицензией

Как известно, “свободные” лицензии дают конечным пользователям полную свободу, в том числе и свободу распространять конечный программный продукт наравне с разработчиком. А это означает, что каждый раз, когда разработчик продаёт копию ПО под “свободной” лицензией, он создает себе конкурента. Принято считать, что невозможно зарабатывать деньги непосредственно на доработке и распространении свободного программного обеспечения, распространяемого на условиях GPL или совместимых с нею лицензий. Описываемые в литературе и применяемые на практике бизнес-модели практически безусловно предполагают бесплатное (или за символическую плату) распространение таких программ. В противоположность этому, наличие “традиционной” (на жаргоне называемой “проприетарной”) лицензии позволяет зарабатывать непосредственно на распространении программного обеспечения.

Обладателю исключительных прав на программу ещё доступна модель двойного лицензирования, подразумевающая “несвободную” коммерческую лицензию на ПО для бизнес-заказчиков и GPL-совместимую лицензию для представителей сообщества. Для всех же вторичных проектов (так называемых “форков”) подобная возможность исключена. Любые доработки кода для ПО, выпущенного под GPL, могут быть выпущены только под этой же или совместимой “вирусной” лицензией, а замена GPL на несовместимую лицензию допускается только с согласия всех обладателей исключительных прав на программу.

С учетом этого, считается, что зарабатывать на Free Software, не являясь обладателем прав на оригинальный продукт, можно либо оказывая сервисные услуги (сопровождение, документирование, обучение и т.п.), либо компонуя его с собственными разработками с закрытым исходным кодом, способом, который допускается используемой свободной лицензией.

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

Суть бизнес-модели сводится к созданию условий, аналогичных “традиционному” модели распространения программного обеспечения, т.е. к “продаже” доработанного продукта сразу нескольким покупателям, что даст возможность окупить понесенные затраты на доработку СПО за счет их многократной продажи. Такой эффект достигается за счет создания временного лага между началом продаж доработанного программного продукта и моментом его размещения в свободном доступе для бесплатной загрузки, что позволяет разработчику стать, на какое-то время, единственным продавцом, у кого эти доработки можно будет приобрести.

Особенность предлагаемой модели заключается в том, что при этом не происходит ни изменения, ни нарушения условий “вирусного” лицензионного соглашения – эффективное ограничение распространения продукта определяется договором между хозяйствующими субъектами и вытекает из процесса выполнения заказных программных разработок.

1. Решение, «подсказанное» Free Software Foundation (FSF)

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

Часто забываемые факты о GPL

• GPL допускает платное распространение программ (http://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLAllowMoney).
• GPL не требует от разработчика делать исходные коды своих разработок доступными широкой публике (http://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLRequireAvailabilityToPublic)
• Разработчик не вправе запрещать Заказчику дальнейшее распространение ПО (http://www.gnu.org/licenses/gpl‑faq.en.html#DoesTheGPLAllowNDA и http://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLAllowModNDA)
• GPL позволяет Заказчику запретить разработчику распространять результаты заказной разработки (http://www.gnu.org/licenses/gpl-faq.en.html#DevelopChangesUnderNDA).

Сценарий по «подсказке» FSF

Исходная ситуация: Разработчиком доработан GPL продукт, есть компания-пользователь, желающая внедрить доработанный продукт, но не готовая оплатить полную стоимость доработки, Разработчику необходимо обеспечить возврат инвестиций в доработку, но есть риск, что компания-пользователь опубликует доработки, как только получит к ним доступ.

Предлагаемая схема взаимодействия к компанией-пользователем:

• Разработчик продает компании-пользователю исходный продукт без своих доработок.
• Разработчик нанимает компанию-пользователя для выполнения работ, связанных с новым кодом, в частности, для тестирования.
• В соответствии с комментариями FSF (#DevelopChangesUnderNDA) существует законная возможность ограничить распространение тестируемого кода на время действия соответствующего договора.
• Время действия этого договора и будет определять временной лаг между началом распространения доработок GPL продукта и моментом его появления в свободном доступе.
• Разработчик может одновременно работать по такой схеме сразу с несколькими заинтересованными компаниями.

2. Решение на основе договорного права

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

Сценарий на основе договорного права

Исходная ситуация: Разработчиком доработан GPL продукт (разработчик готов его доработать), есть компания-пользователь, желающая внедрить доработанный продукт, но не готовая оплатить полную стоимость доработки, Разработчику необходимо обеспечить возврат инвестиций в доработку, но есть риск, что компания-пользователь опубликует доработки, как только получит к ним доступ.

Предлагаемая схема взаимодействия к компанией-пользователем:

• Разработчик заключает с компанией-пользователем договор на доработку исходного GPL продукта.
• В соответствии с действующим законодательством РФ (Статья 712. Право подрядчика на удержание, Статья 1296. Программы для ЭВМ и базы данных, созданные по заказу), в этом случае существует законная возможность ограничить распространение тестируемого кода на время действия соответствующего договора.
• Время действия этого договора и будет определять временной лаг между началом распространения доработок продукта под GPL лицензией и моментом его появления в свободном доступе.
• Разработчик может одновременно работать по такой схеме сразу с несколькими заинтересованными компаниями.

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

По мнению авторов, регулируя длительность временного лага между началом продаж доработанного программного продукта и моментом его размещения в свободном доступе для бесплатной загрузки, в зависимости от типа, сложности, популярности и иных характеристик дорабатываемого программного продукта, можно обеспечить возврат инвестиций в его развитие, достаточный для поддержания коммерческого предприятия. При этом, за счет заключения подобных договоров с несколькими (в идеале – со многими) пользователями-заказчиками будет также обеспечено и разделение затрат между ними (в отличие от схемы bounty source, в рамках которой доработка целиком оплачивается одним заказчиком).

Конечно, наложение любых ограничений на распространение СПО может быть воспринято “в штыки” сообществом и, возможно, потребуются определенные усилия, что бы сторонники двух диаметрально противоположных точек зрения на способы распространения ПО смогли оценить положительные и отрицательные стороны от такого “нововведения”. Тем не менее, описанная бизнес-модель полностью основана на законе и не нарушает ни одного положения о защите интеллектуальной собственности. Более того, она, по сути, является просто специализированной модификацией широко применяемой в корпоративном секторе стандартной модели заказной разработки ПО.

Мы обсудили с Ричардом Столлманом эти способы и он сделал важные замечания к описываемым моделям:

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

Насчет первого способа, Ричард конечно не в восторге, но нарушение GPL будет в том случае, если работа пользователя будет фиктивной. Другими словами, пользователь должен по настоящему работать в соответствии с контрактными обязательствами и эта работа должна реально оплачиваться.

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

Данная методика коммерциализации СПО с GPL лицензией была представлена на Russian Open Source Summit 2014. Материалы доклада в виде статьи на сайте PCWEEK: http://www.pcweek.ru/foss/article/detail.php?ID=164583

Дополнительные материалы

Слайды доклада на LVEE 2014