Я планировал начать эту статью с информации о том, что всегда существуют значительные сложности при попытках коммерциализировать доработки свободного программного обеспечения, а в качестве показательного примера привести ситуацию с проектом Redis.
Но потом понял, что ситуация с Redis (Redis вновь меняет лицензию) в качестве примера не очень подходит. И не только из-за адской смеси различных используемых в проекте лицензий, но и дополнительной путаницы, возникающей из-за толкования терминов Open Source и Свободное ПО.
Тем более, если судить об итогах работы облачных провайдеров за последний квартал 2019 года, а ведь в основе этого бизнеса тоже лежит преимущественно свободное ПО, то это закрывает вопрос как минимум об одном реально работающем способе коммерциализации свободного программного обеспечения.
Ведь цифры говорят сами за себя. Суммарная выручка облачных провайдеров за последний квартал 2019 года превысила $30 миллиардов долларов. Среди них лидер — Amazon (32.4% рынка), Microsoft Azure почти в два раза меньше (17.6%), далее идут Google Cloud (6%) и Alibaba Cloud (5.4%).
Тем не менее, для компаний меньшего размера, подобный бизнес как правило не достижим. Поэтому для них вопрос коммерциализации доработок свободного программного обеспечения под Copyleft лицензиями (такими, как GPL), может оказаться вполне актуальным.
В данной статье речь идет о свободном программном обеспечении, в том смысле, который вкладывает в него «Фонд свободного программного обеспечения» (Free Software Foundation, FSF).
Его принципы сформулированы 4 свободами:
*) Свободы 1 и 3 требуют наличия исходного кода программы, который должен быть доступен для изучения и изменения. Именно из-за этого часто возникает путаница, так как Open Source как раз и означает открытый исходный код, тогда как понятие Free Software относится к правам на ПО, и для которых наличие исходного кода программы является обязательным, но не единственным требованием.
**) Свобода 2 разрешает распространение программы бесплатно и из-за этого так же возникает путаница с термином Freeware, который как раз и обозначает бесплатную программу, но может относиться к любой программе, не обязательно к свободной.
Таким образом, идея Свободного ПО заключается в предоставлении пользователю соответствующих прав на программное обеспечение, которые правообладатель гарантирует каждому пользователю.
Подобный принцип называется Copyleft, который требует сохранения свобод в производных произведениях и запрещают их уменьшение по сравнению с исходным программным продуктом.
Юридическим языком это сформулировано в GPL (GNU General Public License), которая требует от автора производного произведения сохранения (не уменьшения) свобод по сравнению с исходной программой.
Именно из-за сохранения изначальный свобод, подобные лицензии называют «прилипчивыми» или «вирусными».
Главная проблема с коммерциализацией программного обеспечения под GPL заключается в том, что первый же покупатель, который получит программу или её исходники, вправе сам стать распространителем данной программы и разработчик не может этому никак помешать: www.gnu.org/licenses/gpl-faq.ru.html#DoesTheGPLAllowNDA, www.gnu.org/licenses/gpl-faq.ru.html#DoesTheGPLAllowModNDA
А так как исходники может получить любой официальный пользователь, то после этого любой пользователь может выложить полученное ПО или его исходники в свободный и бесплатный доступ, что безусловно создаст проблемы с возвратом финансов, вложенных в разработку такого программного продукта.
Такой проблемы нет для разрешительных лицензий, таких как BSD, MIT или Apache. Они допускают уменьшение свобод в производных продуктах, поэтому достаточно сменить изначальную свободную лицензию на проприетарную (собственническую) и не открывать исходные тексты программного обеспечения пользователю (заказчику).
Вторая сложность в построении бизнеса на СПО с вирусными лицензиями заключается в том, что полная свобода в управлении правами на программный продукт принадлежит только их владельцу, что совершенно логично.
И только обладателю исключительных прав на программу доступна модель двойного лицензирования, подразумевающая «несвободную» коммерческую лицензию на ПО для бизнес-заказчиков и GPL-совместимую лицензию для представителей сообщества.
Но подобная схема не подходит для вторичных проектов (так называемых «форков») или же проектов, посвященных созданию дополнительных модулей, которые должны работать совместно с GPL кодом, и поэтому тоже обязаны иметь GPL совместимую лицензию.
Согласно разъяснениям Free Software Foundation (FSF), GPL разрешает платное распространение программ www.gnu.org/philosophy/selling.html, www.gnu.org/licenses/gpl-faq.ru.html#DoesTheGPLAllowMoney.
Одновременно, GPL не накладывает на разработчика обязательств публиковать свои доработки для широкой публики: www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
Это делает теоретически возможной бизнес-модель возврата инвестиций в СПО за счёт его платного распространения, когда коммерческая ценность создается за счет монопольного владения программным продуктом, точнее, ограничением доступности его актуальной версии для широкого круга пользователей. По сути, это повторение бизнес модели собственнического ПО, основанного на монопольном владении ресурсом.
Другими словами, необходимо сделать временной лаг между передачей программного продукта заказчику и появлением у заказчика права на дальнейшее распространение купленного ПО в соответствии с GPL лицензией.
Фактически, это временное ограничение свободы на распространение, т.к. в противном случае просто «не будет работать экономика», потому что условием наличия спроса на продукт будет являеться отсутствие доступности более дешёвых (или бесплатных) его аналогов на рынке.
Первый вариант создания временного лага между передачей программного продукта заказчику и появлением у него права на дальнейшее распространение купленных доработок, основан на создании необходимых условий согласно толкованиям пунктов GPL лицензии со стороны самого Free Software Foundation.
Это становится возможно за счет превращения покупателя программного продукта в (со)разработчика: www.gnu.org/licenses/gpl-faq.html#DevelopChangesUnderNDA
Для этого достаточно подписать с покупателем (заказчиком) договор о его работе, например в качестве тестировщика на продуктивных данных, который должен включать и соглашение о нераспространении экземпляров программного продукта на время действия данного контракта.
Схема взаимодействия разработчика с пользователем:
Второй способ создать временной лаг между передачей программного продукта заказчику и появлением у него законного права на его дальнейшее распространение возможен за счёт того, что права на созданную по заказу программу для ЭВМ и, соответственно, возможность её дальнейшего распространения возникают у заказчика только после полного исполнения своих обязательств сторонами договора на доработку ПО.
Схема взаимодействия к компанией-пользователем:
Данные схемы работы были предложены сообществу еще в 2014 году на нескольких конференциях, но перед этим авторы связались с Ричард Столлманом, что бы узнать его мнение о данных способах коммерциализации GPL.
Конечно, он был не в восторге, так как в данной схеме присутствует хоть и временное, но все таки нарушение изначальных свобод: Свободы 2: Распространять копии программы и Свободы 3: Улучшать программу и публиковать эти изменения или весь код программы.
Тем не менее, ему пришлось согласиться, что первый способ с (со)разработчиком не будет нарушать GPL, если только работа пользователя не будет фиктивной. Другими словами, пользователь должен по настоящему работать в соответствии с контрактными обязательствами и эта работа должна реально оплачиваться.
По второму способу, Ричард Столлман считает, что схема нарушает GPLv3, где в явном виде прописано, что лицензия имеет приоритет над контрактными обязательствами. Однако с этим не согласны юристы, так как лицензия «начинает работать» только после перехода прав на результат работы. Поэтому, кто окажется в результате прав, может показать только реальная судебная практика.
Создание любых ограничений на распространение Свободного ПО всегда воспринимается “в штыки” сообществом, даже в том случае, если эти ограничения полностью соответствуют условиям лицензии, не противоречат законодательству и помогает развитию самих свободных проектов.
С другой стороны, отсутствие нормального способа коммерциализации кода под GPL значительно ограничивает привлечение инвестиций и их развитие, т.к. нормальные способы коммерциализации имеются только у владельцев исключительных прав на исходный код.
В результате разработчики вынуждены или заниматься не профильным бизнесом или использовать приемы обхода GPL лицензии, чтобы работала бизнес-модель проприетарного программного обеспечения, основанная на монопольном владении объектом авторского права.
Надеюсь, что данный материал кому-нибудь поможет построить бизнес с использованием свободного программного обеспечения.
Авторы: Александр Рябиков, Сергей Середа, к.э.н.
По материалам конференций:
Open Source Summit
LVEE 2014
Но потом понял, что ситуация с Redis (Redis вновь меняет лицензию) в качестве примера не очень подходит. И не только из-за адской смеси различных используемых в проекте лицензий, но и дополнительной путаницы, возникающей из-за толкования терминов Open Source и Свободное ПО.
Тем более, если судить об итогах работы облачных провайдеров за последний квартал 2019 года, а ведь в основе этого бизнеса тоже лежит преимущественно свободное ПО, то это закрывает вопрос как минимум об одном реально работающем способе коммерциализации свободного программного обеспечения.
Ведь цифры говорят сами за себя. Суммарная выручка облачных провайдеров за последний квартал 2019 года превысила $30 миллиардов долларов. Среди них лидер — Amazon (32.4% рынка), Microsoft Azure почти в два раза меньше (17.6%), далее идут Google Cloud (6%) и Alibaba Cloud (5.4%).
Тем не менее, для компаний меньшего размера, подобный бизнес как правило не достижим. Поэтому для них вопрос коммерциализации доработок свободного программного обеспечения под Copyleft лицензиями (такими, как GPL), может оказаться вполне актуальным.
Предлагаю вашему вниманию практический способ коммерциализация доработок свободного программного обеспечения под Copyleft лицензиями, в том числе применительно к законодательству РФ.
О каких лицензиях идет речь?
В данной статье речь идет о свободном программном обеспечении, в том смысле, который вкладывает в него «Фонд свободного программного обеспечения» (Free Software Foundation, FSF).
Его принципы сформулированы 4 свободами:
- Свобода 0: Запускать программу в любых целях.
- Свобода 1: Изучать программу и изменять ее работу под свои нужды.*
- Свобода 2: Распространять копии программы.**
- Свобода 3: Улучшать программу и публиковать эти изменения или весь код программы в целом.*
*) Свободы 1 и 3 требуют наличия исходного кода программы, который должен быть доступен для изучения и изменения. Именно из-за этого часто возникает путаница, так как Open Source как раз и означает открытый исходный код, тогда как понятие Free Software относится к правам на ПО, и для которых наличие исходного кода программы является обязательным, но не единственным требованием.
**) Свобода 2 разрешает распространение программы бесплатно и из-за этого так же возникает путаница с термином Freeware, который как раз и обозначает бесплатную программу, но может относиться к любой программе, не обязательно к свободной.
Таким образом, идея Свободного ПО заключается в предоставлении пользователю соответствующих прав на программное обеспечение, которые правообладатель гарантирует каждому пользователю.
Подобный принцип называется Copyleft, который требует сохранения свобод в производных произведениях и запрещают их уменьшение по сравнению с исходным программным продуктом.
Юридическим языком это сформулировано в GPL (GNU General Public License), которая требует от автора производного произведения сохранения (не уменьшения) свобод по сравнению с исходной программой.
Именно из-за сохранения изначальный свобод, подобные лицензии называют «прилипчивыми» или «вирусными».
В чем проблема коммерциализации GPL?
Проблема 1
Главная проблема с коммерциализацией программного обеспечения под GPL заключается в том, что первый же покупатель, который получит программу или её исходники, вправе сам стать распространителем данной программы и разработчик не может этому никак помешать: www.gnu.org/licenses/gpl-faq.ru.html#DoesTheGPLAllowNDA, www.gnu.org/licenses/gpl-faq.ru.html#DoesTheGPLAllowModNDA
А так как исходники может получить любой официальный пользователь, то после этого любой пользователь может выложить полученное ПО или его исходники в свободный и бесплатный доступ, что безусловно создаст проблемы с возвратом финансов, вложенных в разработку такого программного продукта.
Такой проблемы нет для разрешительных лицензий, таких как BSD, MIT или Apache. Они допускают уменьшение свобод в производных продуктах, поэтому достаточно сменить изначальную свободную лицензию на проприетарную (собственническую) и не открывать исходные тексты программного обеспечения пользователю (заказчику).
Проблема 2
Вторая сложность в построении бизнеса на СПО с вирусными лицензиями заключается в том, что полная свобода в управлении правами на программный продукт принадлежит только их владельцу, что совершенно логично.
И только обладателю исключительных прав на программу доступна модель двойного лицензирования, подразумевающая «несвободную» коммерческую лицензию на ПО для бизнес-заказчиков и GPL-совместимую лицензию для представителей сообщества.
Но подобная схема не подходит для вторичных проектов (так называемых «форков») или же проектов, посвященных созданию дополнительных модулей, которые должны работать совместно с GPL кодом, и поэтому тоже обязаны иметь GPL совместимую лицензию.
Предлагаемый ниже способ коммерциализации доработок свободного ПО позволяет обойти обозначенные выше проблемы. Он подходит для:
- Вирусных лицензий, таких как GPL.
- Коммерциализации доработок программного обеспечения, когда разработчик не является владельцем исключительных прав на программный продукт.
Когда появляется коммерческая ценность?
Согласно разъяснениям Free Software Foundation (FSF), GPL разрешает платное распространение программ www.gnu.org/philosophy/selling.html, www.gnu.org/licenses/gpl-faq.ru.html#DoesTheGPLAllowMoney.
Одновременно, GPL не накладывает на разработчика обязательств публиковать свои доработки для широкой публики: www.gnu.org/licenses/gpl-faq.html#GPLRequireSourcePostedPublic
Это делает теоретически возможной бизнес-модель возврата инвестиций в СПО за счёт его платного распространения, когда коммерческая ценность создается за счет монопольного владения программным продуктом, точнее, ограничением доступности его актуальной версии для широкого круга пользователей. По сути, это повторение бизнес модели собственнического ПО, основанного на монопольном владении ресурсом.
Другими словами, необходимо сделать временной лаг между передачей программного продукта заказчику и появлением у заказчика права на дальнейшее распространение купленного ПО в соответствии с GPL лицензией.
Фактически, это временное ограничение свободы на распространение, т.к. в противном случае просто «не будет работать экономика», потому что условием наличия спроса на продукт будет являеться отсутствие доступности более дешёвых (или бесплатных) его аналогов на рынке.
Создание временного лага на основе условий лицензии
Первый вариант создания временного лага между передачей программного продукта заказчику и появлением у него права на дальнейшее распространение купленных доработок, основан на создании необходимых условий согласно толкованиям пунктов GPL лицензии со стороны самого Free Software Foundation.
Это становится возможно за счет превращения покупателя программного продукта в (со)разработчика: www.gnu.org/licenses/gpl-faq.html#DevelopChangesUnderNDA
Для этого достаточно подписать с покупателем (заказчиком) договор о его работе, например в качестве тестировщика на продуктивных данных, который должен включать и соглашение о нераспространении экземпляров программного продукта на время действия данного контракта.
Схема взаимодействия разработчика с пользователем:
- Разработчик «продает» пользователю исходный продукт без своих доработок.
- Одновременно разработчик нанимает пользователя (компанию-пользователя) для выполнения работ, связанных с новым кодом, например для тестирования или поиска уязвимостей.
- В соответствии с комментариями FSF в этом случае существует законная возможность ограничить распространение тестируемого кода на время действия соответствующего договора. www.gnu.org/licenses/gpl-faq.html#DevelopChangesUnderNDA
- Время действия такого договора и будет определять временной лаг между передачей доработок заказчику и моментом появления у него права опубликовать их в свободном доступе.
- Разработчик может одновременно работать по такой схеме сразу с несколькими заинтересованными компаниями
Коммерциализация GPL на основе договорного права согласно ГК РФ
Второй способ создать временной лаг между передачей программного продукта заказчику и появлением у него законного права на его дальнейшее распространение возможен за счёт того, что права на созданную по заказу программу для ЭВМ и, соответственно, возможность её дальнейшего распространения возникают у заказчика только после полного исполнения своих обязательств сторонами договора на доработку ПО.
Схема взаимодействия к компанией-пользователем:
- Разработчик заключает с компанией-пользователем договор на доработку исходного продукта, относящегося к свободного программному обеспечению с вирусной лицензией.
- В соответствии с действующим законодательством, существует законная возможность ограничить распространение дорабатываемого кода на время действия соответствующего подрядного договора (статья 712. Право подрядчика на удержание; статья 1296. Программы для ЭВМ и базы данных, созданные по заказу).
- Подобный договор должен подразумевать обязательное наличие этапа опытной или (и) опытно-промышленной эксплуатации. Этот промежуток и будет временным лагом между передачей заказчику доработок и моментом их возможного появления в свободном доступе, т.к. переход права на выполненные доработки станет возможным только после полного выполнения договора подряда.
- Как и в первом случае, разработчик может одновременно работать по такой схеме сразу с несколькими заинтересованными компаниями.
Что говорит об этом Ричард Столлман?
Данные схемы работы были предложены сообществу еще в 2014 году на нескольких конференциях, но перед этим авторы связались с Ричард Столлманом, что бы узнать его мнение о данных способах коммерциализации GPL.
Конечно, он был не в восторге, так как в данной схеме присутствует хоть и временное, но все таки нарушение изначальных свобод: Свободы 2: Распространять копии программы и Свободы 3: Улучшать программу и публиковать эти изменения или весь код программы.
Тем не менее, ему пришлось согласиться, что первый способ с (со)разработчиком не будет нарушать GPL, если только работа пользователя не будет фиктивной. Другими словами, пользователь должен по настоящему работать в соответствии с контрактными обязательствами и эта работа должна реально оплачиваться.
По второму способу, Ричард Столлман считает, что схема нарушает GPLv3, где в явном виде прописано, что лицензия имеет приоритет над контрактными обязательствами. Однако с этим не согласны юристы, так как лицензия «начинает работать» только после перехода прав на результат работы. Поэтому, кто окажется в результате прав, может показать только реальная судебная практика.
В заключение
Создание любых ограничений на распространение Свободного ПО всегда воспринимается “в штыки” сообществом, даже в том случае, если эти ограничения полностью соответствуют условиям лицензии, не противоречат законодательству и помогает развитию самих свободных проектов.
С другой стороны, отсутствие нормального способа коммерциализации кода под GPL значительно ограничивает привлечение инвестиций и их развитие, т.к. нормальные способы коммерциализации имеются только у владельцев исключительных прав на исходный код.
В результате разработчики вынуждены или заниматься не профильным бизнесом или использовать приемы обхода GPL лицензии, чтобы работала бизнес-модель проприетарного программного обеспечения, основанная на монопольном владении объектом авторского права.
Надеюсь, что данный материал кому-нибудь поможет построить бизнес с использованием свободного программного обеспечения.
Авторы: Александр Рябиков, Сергей Середа, к.э.н.
По материалам конференций:
Open Source Summit
LVEE 2014
Буду очень рад любым комментария о вашем опыте коммерциализации свободного программного обеспечения с Copyleft лицензиями.
