Просмотр исходного текста страницы Коммерциализация СПО под GPL лицензией (Александр Рябиков, OSSDEVCONF-2014)

== Аннотация ==
;Докладчик: {{Speaker|Александр Рябиков}}
<blockquote>
Отсутствие  нормального  способа  коммерциализации  свободного
программного обеспечения значительно ограничивает привлечение инвестиций  в  развитие  свободных  программных  проектов  с  вирусными лицензиями, т. к. нормальные способы коммерциализации имеются только у владельцев исключительных прав на исходный код. Все остальные разработчики вынуждены или заниматься не профильным
бизнесом или использовать приемы обхода GPL лицензии, что бы работала бизнес модель проприетарного программного обеспечения, основанная на монопольном владении объектом авторского права. Но в последнем случае не получает развития свободный проект. Предлагается новый способ коммерциализации доработок свободного программного обеспечения, разрабатываемых под «вирусными» GPL лицензиями, который позволит инвесторам вернут вложенные средства, а сообществу получить ощутимый вклад в развитии свободных проектов.
</blockquote>

== Видео ==

{{vimeoembed|106435809|800|450}}
{{youtubelink|goJOE5Pqheo}}{{letscomment}}
<!-- pollholder --> 
== Слайды ==
[[File:Коммерциализация СПО под GPL лицензией (Александр Рябиков, OSSDEVCONF-2014).pdf|left|page=-|256px]]

{{----}}

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

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

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

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

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

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

=== Коммерциализация GPL на основе условий лицензии ===

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

Схема взаимодействия к компанией-пользователем:
* 1.  Компания  разработчик  не  выкладывает  продукт  в  свободный  доступ,  т.к.  GPL  этого  не  требует [http://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLRequireAvailabilityToPublic]

* 2.  Разработчик «продает» компании-пользователю исходный продукт без своих доработок на основании того, что GPL допускает платное распространение программ [http://www.gnu.org/licenses/gpl-faq.en.html#DoesTheGPLAllowMoney]
* 3.  Одновременно, разработчик нанимает компанию-пользователя для  выполнения  работ,  связанных  с  новым  кодом,  например, для тестирования. В этом случае возникает законная возможность  ограничить  распространение тестируемого  кода  на время действия соответствующего договора, т. к. GPL позволяет запретить наемному работнику распространять результаты заказной разработки [http://www.gnu.org/licenses/gpl-faq.en.html#DevelopChangesUnderNDA]
* 4.  Время действия такого договора и будет определять временной лаг между началом распространения GPL доработок и моментом их их возможного появления в свободном доступе.
* 5.  Разработчик может одновременно работать по такой схеме сразу с несколькими заинтересованными компаниями.

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

=== Коммерциализация GPL на основе договорного права ===

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

Схема взаимодействия к компанией-пользователем:
* 1.  Разработчик заключает с компанией-пользователем договор на доработку исходного продукта с GPL лицензией.
* 2.  В соответствии с действующим законодательством (статья 712. Право подрядчика на удержание; статья 1296. Программы для ЭВМ и базы данных, созданные по заказу), в этом случае существует законная возможность ограничить распространение дорабатываемого кода на время действия соответствующего подрядного договора.
* 3.  Договор  подразумевает  обязательное  наличие  этапа  опытной или (и) опытно-промышленной эксплуатации, что и будет временным лагом между началом распространения доработок СПО и моментом их появления в свободном доступе. т.к. это возможно только после перехода права собственности на ПО.
* 4.  Разработчик может одновременно работать по такой схеме сразу с несколькими заинтересованными компаниями.

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

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

=== В заключении ===
Наложение любых ограничений на распространение СПО всегда воспринимается  «в  штыки»  сообществом,  даже  в  том  случае,  если ограничения полностью соответствуют условиям лицензии и не противоречат законодательству.

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

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

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

== Примечания и отзывы ==
<!-- <blockquote>[©]</blockquote> -->

<references/>

[[Category:OSSDEVCONF-2014]]
[[Category:Бизнес и СПО]]
[[Категория:Open-source и законы]]

<!-- topub -->
{{stats|disqus_comments=0|refresh_time=2021-08-31T17:21:39.556270|vimeo_comments=0|vimeo_plays=96|youtube_comments=2|youtube_plays=72}}