http://www.pcweek.ru/foss/article/detail.php?ID=164583
Бизнес и СПО: модель коммерциализации программных доработок
Автор: Александр Рябиков, Сергей Середа
26.06.2014

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

В то же время, согласно разъяснениям (и даже призывам) Free Software Foundation (FSF), GPL вполне допускает платное распространение программ и не требует от разработчика делать исходные коды своих разработок доступными широкой публике, что делает теоретически возможной бизнес-модель возврата инвестиций в СПО за счёт его платного распространения. К сожалению, участие FSF на этом заканчивается, напоминая известный анекдот про предложение мышам, чтобы чувствовать себя в безопасности, стать ёжиками, но без пояснений, как это сделать.

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

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

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

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

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

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

По итогам также проведённого юридического анализа были разработано два возможных решения этой задачи, которые мы и представляем на суд читателя.
Решение, «подсказанное» FSF

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

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

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

1. Разработчик «продает» компании-пользователю исходный продукт без своих доработок. Полученные средства идут на компенсацию затрат на них (доработки).

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

3. В соответствии с комментариями FSF и действующим законодательством (статья 1280. Свободное воспроизведение программ для ЭВМ и баз данных. Декомпилирование программ для ЭВМ; статья 728. Возвращение подрядчиком имущества, переданного заказчиком) в этом случае существует законная возможность ограничить распространение тестируемого кода на время действия соответствующего договора.

4. Время действия этого договора и будет определять временной лаг между началом распространения доработок СПО и моментом его появления в свободном доступе. Для достижения целей бизнес-модели этот срок может составлять, например, от 6 до 12 мес.

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

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

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

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

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

1. Разработчик заключает с компанией-пользователем договор на доработку исходного продукта, относящегося к СПО. Цена договора ниже полной стоимости работ в N раз, где N — ожидаемое число компаний-пользователей, между которыми будут разделены затраты на оплату полной стоимости работ.

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

3. Время действия этого договора и будет определять временной лаг между началом распространения доработок СПО и моментом его появления в свободном доступе.

4. Договор подразумевает обязательное наличие этапа опытной или (и) опытно-промышленной эксплуатации сроком, например, от 6 до 12 мес.

5. Разработчик может одновременно работать по такой схеме сразу с несколькими заинтересованными компаниями.
«Моральное обоснование» предлагаемой бизнес-модели

• Необходим слом стереотипа «На СПО невозможно заработать».

• Движение СПО должно само себя поддерживать, что и происходит по всем направлениям за исключением финансового.

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

• Жизнеспособная бизнес-модель развития СПО — единственный способ уйти от финансирования за счет пожертвований и обеспечить независимое воспроизводство проектов СПО.

Минусы бизнес-модели

• Требуется заключение особым образом составленных договоров.

• Повышается фрагментация кода СПО.

• Потенциально возможны злоупотребления (договор на 100 лет).

Плюсы бизнес-модели

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

• Появляется возможность разделить затраты на разработку между произвольным числом заинтересованных компаний, причём не одновременно, что существенно повысит платежеспособный спрос на доработку СПО в сегменте B2B.

• Процесс развития СПО станет самовоспроизводящимся за счёт экономической мотивации (а не только голого энтузиазма) участников.

Авторы будут рады конструктивной критике и предложениям читателей и призывают к активному обсуждению поднятой темы всеми заинтересованными сторонами и экспертным сообществом.

Об авторах: Александр Рябиков — председатель Фонда «Адемпиере», Сергей Середа — к. э. н., руководитель направлений «Экономика» и «Интеллектуальная собственность» Фонда «Адемпиере».