Вернуться на сайт

Справочник по лицензированию

К оглавлению

Часть 3. ОСОБЕННОСТИ ЛИЦЕНЗИРОВАНИЯ И ПРАВИЛА ОФОРМЛЕНИЯ НЕКОТОРЫХ ПРОГРАММНЫХ ПРОДУКТОВ, РАСПРОСТРАНЯЕМЫХ НА ОСНОВЕ СВОБОДНЫХ ЛИЦЕНЗИЙ 2

3.1 Понятие и особенности свободных лицензий
3.2 Основные открытые программные продукты и их лицензии
3.3 Основные виды свободных лицензий
3.4 Краткая характеристика отдельных видов свободных лицензий
3.5 Заключение лицензионного договора на условиях свободной лицензии
3.6 Ключевые риски, связанные с использованием свободных лицензий


3.1 Понятие и особенности свободных лицензий

Бурное развитие сети Интернет в последние десятилетия обусловило появление новых подходов к созданию и распространению программного обеспечения. Одним из наиболее значительных событий в этой области является появление модели распространения программного обеспечения с открытым исходным кодом (free/open source software, FOSS или OSS), распространяемого на условиях лицензий, обычно именуемых в литературе и на практике «свободными лицензиями».

Ключевые признаки свободной лицензии содержатся в дефинициях, выработанных двумя основными организациями, которые координируют деятельность в сфере пропаганды и продвижения свободного ПО. К ним относится Фонд свободного программного обеспечения (Free Software Foundation), основанный в 1985 г. Ричардом Столлманом (далее – FSF) и Инициатива открытого исходного кода (Open Source Initiative), основанная в 1998 г. Эриком Реймондом и Брюсом Перенсом (далее – OSI).

Дефиниция FSF:

С точки зрения FSF свободным может считаться ПО (и соответственно лицензия, на условиях которой оно распространяется), при условии, что лицензия предоставляет 4 основных свободы (http://www.gnu.org/philosophy/free-sw.html):
1) свобода запуска программы для любых целей;
2) свобода изучения устройства программы и ее адаптации для собственных нужд;
3) свобода распространения копий программы;
4) свобода внесения улучшений в программу и их распространения на пользу сообщества.

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

Указанные идеи были отражены в ряде свободный лицензий, разработанных FSF: General Public License и Lesser General Public License, которые существуют в различных версиях.

Дефиниция OSI

С точки зрения OSI, свободная лицензия должна отвечать не четырем, а десяти условиям (http://opensource.org/osd):

1) Свободное распространение. Лицензия не должна ограничивать какую-либо из сторон в праве осуществлять дальнейшее распространение копии программы в том числе в составе сборок вместе с иными компьютерными программами. При этом не допустимо взимание роялти или иной платы за предоставление такого права.

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

3) Производные произведения. Лицензионное соглашение должно предусматривать право лицензиата вносить изменения в программу и создавать производные программы, а также лицензировать модифицированную версию на условиях первоначальной лицензии. Здесь кроется основное отличие от GPL-подобных лицензий FSF: условие о лицензировании производной программы на условиях первоначальной лицензии носит диспозитивный характер и не является обязательным для квалификации лицензии в качестве свободной по стандартам OSI.

4) Чистота исходного кода. Лицензия может требовать, чтобы модифицированная программа распространялась под иным именем или номером версии, чем первоначальная. Указанное положение направлено на защиту репутации первоначального автора, поскольку их репутация может пострадать в случае внесения распространения низкокачественных изменений под их именем.

5) Отсутствие дискриминации по отношению к определенным лицам или группам лиц. Лицензия не может ограничивать право использования программного продукта только определенными категориями лиц, например, некоммерческими организациями или запрещать его использование коммерческими организациями.

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

7) Распространение лицензии. Права, предоставляемые лицензией, должны распространяться на всех лиц, которым программа была передана. При этом такие права должны предоставляться таким приобретателям без необходимости совершения с их стороны каких-либо дополнительных действий или подписания каких-либо дополнительных соглашений.

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

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

10) Лицензия должна быть технологически нейтральной. Ее предоставление не должно быть «привязано» к определенной технологии или интерфейсу. В частности, она не может существовать исключительно в форме click-wrap license, поскольку такая лицензия предполагает использование графического пользовательского интерфейса и будет несовместима с интерфейсом в виде командной строки

Принципиальных отличий в между дефинициями свободных лицензий, предложенными двумя указанными организациями, нет. Основные отличия сводятся к тому, что, с одной стороны, дефиниция open source initiative является более развернутой за счет большей детализации включенных в нее признаков, а с другой – более гибкой за счет включения в понятие свободных тех лицензий, которые таковыми не считаются FSF. Последнее различие вызвано идеологическими разногласиями между FSF и OSI, которые вкратце можно свести к тому, что для FSF движение за свободное ПО представляют собой своего рода «крестовый поход» против производителей коммерческого ПО, в то время как для OSI свободные лицензии – это особая методология разработки ПО, которая может представлять интерес и для производителей коммерческого ПО. Как следствие, дефиниция OSI не предполагает безусловной обязанности лицензиата, реализующего право на модификацию первоначальной программы, распространять модифицированную версию на тех же самых условиях, что и первоначальная (т.н. «вирусные» условия). Такой лицензиат может выбрать иной вид свободной лицензии или даже распространять ее на условиях классической коммерческой лицензии. Следует подчеркнуть, что указанные различия имеют смысл только для тех пользователей свободного ПО, которые используют его для разработки собственных программных продуктов. Для обычных пользователей указанные тонкости различий между дефинициями свободных лицензий особого значения не имеют: любая свободная лицензия, удовлетворяющая признакам любой из указанных дефиниций, дает максимум необходимых правомочий для такого пользователя.

Ключевые отличия свободных лицензий от классических коммерческих лицензий можно проиллюстрировать следующим образом:

  Классические коммерческие лицензии Свободные лицензии
Объем предоставляемых лицензией прав Как правило, весьма скуп и ограничен правом на установку и использование программы лицензиатом в соответствии с принятыми метриками и ограничениями. Права на переработку, создание и дальнейшее распространение экземпляров не предоставляются. Реализация предоставленных прав может быть ограничена определенными территориями, целями или сферами деятельности (например, территорией определенных стран, использованием исключительно в некоммерческих целях, или запретами на использование в определенных индустриях). Пользователю предоставляется широкий объем правомочий на недискриминационной основе:
  1. Неограниченное право на использование программы без ограничения целями или сферами деятельности;
  2. право создание и свободное распространение копий программы;
  3. право на модификацию программы (создание производных программ на ее основе)
  4. право на распространение модифицированной программы
(http://www.gnu.org/philosophy/free-sw.html; http://opensource.org/osd)
Наличие доступа к исходному коду Как правило, отсутствует. Программа распространяется в скомпилированном виде. Сохранение исходного кода втайне позволяет правообладателю сохранять монополию над программой:
  1. держать под контролем разработку ее последующих версий;
  2. иметь дополнительный поток прибыли от оказания услуг поддержки программы;
  3. затруднять доступ конкурентов к инновационным идеям программы.
Возможность получения доступа к тексту исходного кода является существенным признаком любой свободной лицензии. Такой доступ необходим для обеспечения реализации правомочия на модификацию программы.
Наличие лицензионного вознаграждения Предоставление прав обычно осуществляется на возмездной основе – при условии уплаты лицензионного вознаграждения Реализация прав, предоставленных в рамках свободных лицензий, не требует уплаты каких-либо лицензионных вознаграждений (п. 1 дефиниции open source: http://opensource.org/osd). Тем не менее, это не означает невозможности возмездной реализации экземпляров со свободными программами или оказания сопутствующих услуг на возмездной основе (внедрение, поддержка, обучение и пр.). Однако в таких случаях предметом оплаты выступает именно экземпляр (услуга) как таковой, а не права пользования свободным ПО


3.2 Основные открытые программные продукты и их лицензии


Программа Лицензия
Ядро ОС Linux GPL
ОС FreeBSD и ее модификации OpenBSD, DragonflyBSD BSD
Окружение рабочего стола KDE GPL
Окружение рабочего стола GNOME GPL
Текстовый редактор OpenOffice.org Writer LGPL
Электронные таблицы OpenOffice.org Calc LGPL
Мультимедийные презентации OpenOffice.org Impress LGPL
Средство работы с базами данных OpenOffice.org Base LGPL
Редактор блок-схем и векторной графики OpenOffice.org Draw LGPL
Почтовый клиент Mozilla Thunderbird MPL
Редактор растровой графики GIMP GPL
Редактор векторной графики Inkscape GPL
Издательское приложение Scribus GPL
Среда для запуска программ, работающих в среде MS Windows Win32API Wine LGPL
Антивирусное ПО ClamAV GPL
Apache веб-сервер Apache software license
СУБД MySQL GPL
PostgreSQL BSD

3.3 Основные виды свободных лицензий

В настоящее время существует около 70 свободных лицензий, признанных и сертифицированных в качестве таковых Инициативой открытого исходного кода (http://opensource.org/licenses/alphabetical). Все указанные лицензии можно условно разделить на две основных категории: разрешительные лицензии (permissive, academic) и взаимные лицензии (reciprocal, viral, copyleft). Наиболее типичными примерами либеральных лицензий являются BSD, MIT, Apache, в взаимных - GPL, LGPL, MPL.

Ключевыми элементами разрешительных лицензий являются: 1) обязанность сохранения существующих уведомлений об авторском праве; 2) недопустимость использования имен авторов (правообладателей) для продвижения производных программ; 3) дисклеймер об исключении гарантий и ответственности за качество и результаты использования ПО.

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

3.4 Краткая характеристика отдельных видов свободных лицензий3.

Berkley Software Distribution License, BSD («Программная лицензия университета Беркли»)

Текст данной лицензии был разработан в университете Беркли и приобрел широкую известность благодаря распространению на его основе UNIX-подобной операционной системы BSD. Текст лицензии достаточно лаконичен и прост в прочтении. Лицензия BSD состоит из трех основных частей. Первая часть представляет собой уведомление об авторском праве: указание автора и даты создания программы. Вторая часть лицензии описывает предоставляемые лицензиату права (объем лицензии) и условия их предоставления. Лицензиату «разрешается дальнейшее распространение и использование как в форме исходного кода, так и в форме объектного кода, как с модификациями, так и без них, при соблюдении следующих условий…». BSD-лицензия предусматривает следующие условия предоставления лицензии: 1) при дальнейшем распространении программы в форме исходного кода должны быть сохранены уведомления об авторском праве, уведомление об исключении гарантий и ответственности; 2) в случае распространения программы в объектном коде вышеперечисленные сведения должны быть воспроизведены в документации и (или) иных сопроводительных документах (то есть фактически копия первоначальной лицензии должна сопровождать такую программу); 3) Имена автора и (или) лиц, осуществивших вклад в проект не должны быть использованы для рекламы и продвижения продуктов, созданных на основе данной программы в отсутствие их письменного согласия.

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

Apache License v. 2.0

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

Права, предоставляемые в рамках данной лицензии, включают в себя правомочия на воспроизведение, создание производных произведений, публичный показ, публичное исполнение, сублицензирование и распространение программы в первоначальном или модифицированном виде, как в форме исходного кода, так и в форме объектного кода. Лицензия является безотзывной, выдается на весь срок действия исключительного права (perperual) и не имеет ограничений по территории (worldwide) (ст. 2). Лицензия Apache 2.0 предусматривает, что любой вклад, внесенный в проект, подчиняется условиям данной лицензии (ст. 5). Дальнейшее распространение программы допускается при условии сохранения уведомлений об авторском праве, а также предоставления копии данной лицензии получателям. В отличие от BSD Apache 2.0 лицензия требует, чтобы сделанные изменения (модификации) были выделены, что направлено на защиту репутации первоначальных авторов от «низкокачественных» модификаций программы. В духе разрешительных лицензий, Apache 2.0 содержит прямое указание на возможность дальнейшего распространения модифицированной программы на иных лицензионных условиях (ст. 4). Данная лицензия предоставляет возможность свободного использования программы для создания собственных классических решений, не возлагая обязательств по предоставлению исходного кода, запретов на взимание лицензионных платежей за предоставление соответствующих прав.

GNU General Public License, GPL («Генеральная публичная лицензия»). В настоящее время наиболее распространенной является GPL ver. 2, на основе которой, в частности, распространяется Linux.

GPL-лицензия предоставляет права копирования экземпляров программы в исходном коде (воспроизведения – в контексте российского законодательства) и их последующего распространения в неизменном виде при условии: 1) указания на каждом экземпляре всех необходимых уведомлений об авторском праве, 2) оговорки об исключении гарантий и ответственности, а также 3) предоставления получателям экземпляра копии данной лицензии. Если программа распространяется в форме объектного кода, то помимо выполнения вышеуказанных условий, к такой программе должен быть приложен исходный код либо должна быть предоставлена возможность его получения заинтересованным лицом по его требованию (ст. 3 (а) и (b)).

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

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

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

Права, предоставляемые в рамках GPLv.3, конкретизируются в данной лицензии посредством вышеуказанных терминов. Лицензиату предоставлено неограниченное право запуска и использования программы в той степени, при которой не осуществляется создание условий для ее воспроизведения третьими лицами. Причем третьи лица могут получать доступ и вносить изменения в программу, действуя исключительно в интересах лицензиата и действуя тем самым от его имени (Ст. 2). Последнее условие расширяет возможности оказания консалтинговыми компаниями услуг по кастомизации свободного программного обеспечения под нужды конкретного клиента, так как в таком случае не потребуется открытие исходного кода такого рода частных модификаций.

Что же касается правомочия лицензиата на создание третьим лицам условий для воспроизведения программы, то условия его реализации не претерпели существенных изменений, по сравнению с предыдущей версией GPL. Если такие условия создаются в отношении первоначальной программы (без изменений внесенных лицензиатом), то лицензиат обязан сохранить все существующие уведомления об авторском праве, ссылки на лицензию и приложить ее копию (ст. 4). Если же речь идет о создании условий для воспроизведения модифицированной версии программы, то она должна быть также лицензирована на условиях GPLv.3 с указанием на то, что она была модифицирована и даты такой модификации (ст. 5).

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

Lesser General Public License, LGPL («Малая генеральная публичная лицензия»)

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

Ключевое значение в данной лицензии имеет дифференцированное отношение к модифицированной программе (библиотеке), которая подобно тому, как это имеет место в GPL должна распространяться на тех же условиях, что и первоначальная билиотека (т.е. LGPL) и программе, которая использует библиотеку (a work that uses the library, ст. 5), в отношении которой данное правило не действует. Условия распространения такой программы прописаны отдельно (ст. 6). Они включают в себя: 1) необходимость указания факта использования библиотеки, лицензируемой на условиях LGPL, и приложения копии такой лицензии; 2) обязанность упоминания авторов такой библиотеки в случае упоминания авторов иных частей такой программы; 3) обязанность создать условия при которых заинтересованный пользователь мог бы внести изменения в библиотеку, используемую в рамках такой программы. LGPL перечисляет возможные варианты, как это можно сделать (п. а – е ст. 6).

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

Mozilla Public License, MPL

Данная лицензия была разработана юристами компании Netscape в связи с чем отдельные положения напоминают классические коммерческие лицензии.

MPL является интересным гибридом идей, заложенных в GPL и разрешительных лицензиях вроде BSD. Ее основная идея заключается в следующем. В случае создания и распространения модификаций одного или нескольких файлов, содержащих первоначальный код либо ранее сделанные модификации к нему, такие модифицированные файлы должны быть также лицензированы на условиях MPL. Ключевое значение здесь имеет тот факт, что указанная обязанность распространяются только на файлы, содержащие первоначальный код либо модификации к нему. Иные файлы не охватываются ею, даже если вся программа в совокупности может быть квалифицирована в качестве производного произведения8. Таким образом, GPL-подобное обязательство по распространению модифицированной программы на условиях первоначальной лицензии в MPL имеет существенно более узкую сферу применения, делая пригодным использование кода, лицензируемого на условиях MPL, при создании классических коммерческих продуктов, используя его в качестве «кирпичиков» при разработке программного обеспечения. Программа, построенная с использованием таких кирпичиков (Larger work, «большая программа» в терминологии MPL), может распространяться на любых условиях, в том числе и классической коммерческой лицензии. С некоторой долей условности можно сказать, что MPL представляет собой лицензию, которая применяется к файлам, а не к программам в целом. Это обеспечивает определенность и предсказуемость правового режима произведенных изменений, которая отсутствует у GPL, использующей чрезмерно широкое понимание «модификаций».

3.5 Заключение лицензионного договора на условиях свободной лицензии

Пользователь приобретает статус лицензиата свободной лицензии в силу факта начала использования соответствующей программы. Исходный код любой программы должен содержать в начале текст сведения об авторе, а также применяемой лицензии. Также текст лицензии может содержаться в папке с файлами программы, как правило, под названием license.txt. С текстом свободной лицензии при желании можно ознакомиться на веб-сайте OSI. Поскольку в отсутствие согласия правообладателя, выраженного в условиях лицензионного договора, правомерное использование компьютерной программы невозможно, последующее начало использования программы (ее установка, запуск, модификация, распространение и т.д.) свидетельствует о принятии соответствующих условий лицензии, выраженных посредством отсылки к стадартизированным текстам свободных лицензий, признанных соответствующей критериям open source со стороны сообщества в лице OSI. Указанный способ заключения лицензионного договора является своего рода сложившейся практикой (обычаем) в сфере open source. Указанная практика не противоречит российскому законодательству, которое в п. 5 ст. 1286ГК РФ прямо предусматривает возможность заключения лицензионного договора началом использования программы: «Лицензионный договор с пользователем о предоставлении ему простой (неисключительной) лицензии на использование программы для ЭВМ или базы данных может быть заключен в упрощенном порядке. Лицензионный договор, заключаемый в упрощенном порядке, является договором присоединения, условия которого, в частности, могут быть изложены на приобретаемом экземпляре программы для ЭВМ или базы данных либо на упаковке такого экземпляра, а также в электронном виде (пункт 2 статьи 434). Начало использования программы для ЭВМ или базы данных пользователем, как оно определяется указанными условиями, означает его согласие на заключение договора. В этом случае письменная форма договора считается соблюденной.». Новая редакция статьи прямо предусматривает, что условия лицензионного договора могут быть предусмотрены, помимо прочего, и в электронном виде, что имеет непосредственное значение для свободных лицензий, поскольку их условия в подавляющем большинстве случаев как раз и существуют в такой форме (например, размещены на сайте соответствующего open source проекта или в виде файла на жестком диске с программой). Таким образом, отсутствие лицензионных условий на «бумажном» носителе не свидетельствует об отсутствии заключенного лицензионного договора, такие условия могут быть изложены и в иных формах.

В качестве доказательства лицензионного использования программного обеспечения, распространяемого на условиях свободных лицензий, могут выступать сведения о лицензии, относящейся к категории open source, которые могут содержаться, в зависимости от программы:

Для того, чтобы убедиться в том, что соответствующая программа распространяется именно на условиях свободной лицензии, обозначенной в ней, возможно обращение на сайт open source проекта, в рамках которого она была создана. Например, офисный пакет Apache OpenOffice распространяется на условиях Apache License ver. 2.0, информация об этом содержится на сайте проекта: http://www.openoffice.org/license.html"

Наиболее полный перечень лицензий open source и их условий – на сайте OSI: http://opensource.org/licenses/alphabetical.

Необходимо помнить, что поскольку свободные лицензии и связанные с ними open source проекты берут свое начало из-за рубежа (преимущественно из США), то лицензиаром будет иностранное лицо. В таком случае к такой свободной лицензии будет применяться иностранное право (как правило, право страны лицензиара – п. 8 ст. 1211 ГК РФ, поскольку все open source лицензии предусматривают возможность использования программы на территории всех стран мира). Следовательно, практически все вопросы, связанные с договором, будут определяться в соответствии с требованиями иностранного права, а не российского ГК РФ. В соответствии со ст. 1215 ГК РФ правом, подлежащим применению к договору, определяются, в частности:

1) толкование договора;
2) права и обязанности сторон договора;
3) исполнение договора;
4) последствия неисполнения или ненадлежащего исполнения договора;
5) прекращение договора;
6) последствия недействительности договора.

Таким образом, круг существенных условий договора, действительность прав и обязанностей сторон надо будет определять в соответствии с законодательством США, которое в общем и целом признает действительными условия большинства свободных лицензий, в том числе GPL9. Можно забыть в таких случаях про формализм ст. 1235 ГК РФ о перечне существенных условий лицензионного договора и многие иные статьи ГК РФ.

Также необходимо отметить, что использование русского языка в тексте договора не является необходимым условием его действительности в соответствии с гражданским законодательством РФ. Оно не содержит специальных оснований признания недействительными договоров, заключенных как с иностранными лицами, так и между российскими лицами, исполненных на иностранном языке. Существуют определенные положения законодательства РФ о государственном языке, которые предписывают использование русского языка в делопроизводстве10. Однако положения ст. 168 ГК РФ о недействительности сделки не соответствующей закону не применимы в данном случае, особенно после недавно внесенных изменений в данную статью:

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

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

Указанные выводы подтверждаются и судебной практикой:

«законодательство Российской Федерации не запрещает организациям заключать договоры с иностранными контрагентами на иностранном языке» (Постановление ФАС Московского округа от 13.11.2008 N КА-А41/10639-08)

«Указанная норма неприменима к договорам, заключаемым с иностранными контрагентами, поскольку данные договоры не относятся к документам делопроизводства и согласно международным нормам составляются на иностранном языке» (Постановление Девятого арбитражного апелляционного суда от 06.04.2006)

Поправками в ГК РФ также была решена проблема, связанная с безвозмездным характером свободных лицензий. Как известно, все они не предполагают уплаты лицензионного вознаграждения за предоставляемые права (п. 1 дефиниции OSI), что, однако, не исключает возможности взимания платы за сами экземпляры (носители) с программой, а также сопутствующие услуги (установка, поддержка, обучение и пр.). Однако, по общему правилу, безвозмездные отношения между коммерческими организациями запрещены (пп. 4 п. 1 ст. 575 ГК РФ), в связи с чем в юридической литературе высказывались мнения о недействительности заключенных между коммерческими организациями свободных лицензий. В настоящее время можно считать этот вопрос решенным, поскольку в ГК РФ было внесено прямое пояснение по данному вопросу. Согласно п. 5.1 ст. 1235 ГК РФ, «не допускается безвозмездное предоставление права использования результата интеллектуальной деятельности или средства индивидуализации в отношениях между коммерческими организациями на территории всего мира и на весь срок действия исключительного права на условиях исключительной лицензии, если настоящим Кодексом не установлено иное». Поскольку все свободные лицензии являются неисключительными, их заключение между коммерческими организациями не запрещено даже при явно выраженной безвозмездности.

Наконец, следует отметить, что поправками в часть 4 ГК РФ было введено понятие «открытой лицензии» (ст. 1286.1 ГК РФ). В соответствии с данной статьей под открытой лицензией на произведение литературы науки и искусства (в том числе и программного обеспечения как разновидность произведения литературы с точки зрения авторского права) понимается лицензионный договор, заключаемый в упрощенном порядке и по модели договора присоединения. Несмотря на то, что формулировки соответствующих положений далеки от идеала (отсутствует научно выверенное определение понятия «открытой лицензии», отличающей ее от иных видов лицензионных соглашений; предусматривается возможность наличия возмездных открытых лицензий, что противоречит сути open source и общепринятой дефиниции и др.14), сам факт введения подобной категории на уровень закона можно расценить положительно в условиях российских реалий.

Однако и без специальных положений ГК РФ об открытых лицензиях, свободные лицензии уже признаются в отечественной судебной практике «без осуждения».

Постановление 13 Арбитражного апелляционного суда от 28.05.2015 по делу № А56-73686/2014: «В состав исходного кода спорных программ входит исходный код иного свободно распространяемого программного обеспечения, при этом все авторские права принадлежат иным правообладателям. В соответствии с международным правом и законодательством РФ в данном случае программное обеспечение может распространяться исключительно как свободно распространяемое программное обеспечение».

Решение Арбитражного суда г. Москвы от 28 января 2013 г. по делу № А40-100662/12: «Утверждение Ответчика о том, что в ресторане «Full Free джаз & гриль» часто играет потоковая музыка из сети интернет, то есть используется интернет-радио, также распространяющее произведения по лицензии «Creative Commons», никоим образом не делает исполнение фонограмм через интернет-радио непубличным, и, кроме того, никаким образом не может рассматриваться в контексте действующего законодательства в сфере смежных прав, поскольку относится к сфере, регулируемой авторским правом». В данном случае речь идет о свободной лицензии Creative Commons, которая обычно используется для лицензирования литературных произведений, фотографий и музыки, а не программного обеспечения. Но, по существу, она основана на тех же принципах, что и свободные лицензии в сфере программного обеспечения, в связи с чем указание суда о том, что такая лицензия не только не является недействительной, но и должна рассматриваться в контексте авторского права, представляет ценность и для анализа open source лицензий.

Существуют и иные решения судов, в которых свободные лицензии на ПО (GNU GPL) упоминаются «без признаков осуждения»: (см. например, Определение Санкт-Петербургского городского суда от 22.11.2012 N 33-16052/2012; Постановление ФАС Московского округа от 12.02.2010 N КА-А40/136-10 по делу N А40-115399/09-93-1024).

Таким образом, свободная лицензия представляет собой договор, заключение которого вполне укладывается в рамки российского законодательства, но который в большинстве случаев должен оцениваться через призму законодательства США (как страны лицензиара)13.

3.6 Ключевые риски, связанные с использованием свободных лицензий.

Указанные риски можно разделить на две большие группы:

Риски, связанные с использованием свободного ПО в деятельности компании.

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

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

С тех пор имело место немало обсуждений на сей счет, однако в настоящее время их можно считать во многом устаревшими. Причин тому несколько. Во-первых, прошло достаточно времени и open source, и свободное ПО перестало восприниматься в качестве чего-то маргинального. Термин «свободное ПО» стали широко использоваться в различных правовых актах. Во-вторых, появилось официальное разъяснение Министерства экономического развития РФ, которое «благословило» использование свободных лицензий и GPL в частности. Речь идет о письме Министерства экономического развития РФ от 5 мая 2009 г. N Д05-2235 "Об использовании свободного программного обеспечения», в котором было прямо сказано, что «использование свободного программного обеспечения не может являться основанием для применения санкций и создания препятствий в осуществлении предпринимательской деятельности при контроле за соблюдением авторских прав».

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

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

Риски, связанные с использованием свободного ПО при разработке собственных программных продуктов

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

Основная проблема заключается в том, что при наличии порядка 70 свободных лицензий, многие из них несовместимы между собой. Иными словами, сочетание фрагментов кода, распространяемого на условиях GPL, BSD, MPL и Apache лицензий может оказаться юридически невозможным. Сам факт использования GPL кода будет требовать применение к итоговой программе GPL лицензии, в то время как это будет противоречить MPL лицензии, которая будет требовать применение MPL к измененным файлам. В условиях, когда какой-либо фрагмент кода программы используется с нарушением условий его лицензирования, весь результирующий программный продукт приобретает сомнительный правовой статус. Это может иметь значение при последующей коммерциализации программы, особенно, если она будет осуществляться с привлечением зарубежных партнеров, которые традиционно уделяют много внимания юридической чистоте продукта. Но еще большее значение это будет иметь в тех случаях, когда разработчиком программы заинтересуется крупная иностранная компания и захочет его приобрести. Сопутствующий M&A процесс due diligence включает в себя анализ исходного кода программы, в том числе с привлечением специализированных организаций (например, компании Black Duck и ей подобных, которые могут просканировать код и определить его происхождение). Наличие нарушений лицензионного соглашения при разработке программы может послужить основанием для существенного снижения цены или даже отказа от сделки. Так что различного рода стартапам, рассчитывающим на интерес со стороны крупных игроков рынка IT, следует особое внимание уделить качеству кода своих программных продуктов.

Разумеется, существует и формальный риск предъявления претензий со стороны правообладателя (автора GPL программы) или его уполномоченного представителя (для GPL лицензий – это FSF). Существует ряд судебных споров (пока только зарубежных), которые обычно заканчивались капитуляцией нарушителя. См. подробнее: http://gpl-violations.org. Даже если в итоге и не будет присуждена значительная компенсация, ущерб репутации в сообществе open source будет весьма значительным.

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

Для достижения указанной цели целесообразно внедрение в компании политики использования open source. В частности, обязанность программистов фиксировать происхождение кода, а также загружать вместе с ним те лицензии, которые его сопровождают. Она также может содержать перечни лицензий, которые можно использовать без согласования с юристами (как правило, это все либеральные лицензии) и которые требуют такого согласования11.

В некоторых случаях целесообразно проведение анализа (сканирования) программного кода с помощью автоматизированных средств (в т. ч. с привлечением специализированных компаний, например Black Duck Software Inc.; Palamida, Inc.).

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


2От составителей справочника: текст подготовлен к.ю.н. Савельевым А.И., юрисконсультом IBM Россия/СНГ, старшим научным сотрудником НИУ «ВШЭ». Высказанные суждения являются личным мнением автора и могут не совпадать с официальной позицией компании IBM.

3Более подробный анализ см.: Савельев А.И. Лицензирование программного обеспечения в России. Законодательство и практика. М.: Инфотропик, 2012.

4 http://www.apache.org/

5http://source.android.com/source/licenses.html

6Lindberg V. Intellectual Property and Open Source. Sebastopol: O'Reilly, 2008. P. 212-213.

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

8 Rosen L. Open Source Licensing: Software Freedom and Intellectual Property Law. Prentice Hall. 2005. P. 147.

9 Jaсobsen v. Katzer 535 F. 3d 1373, 1378-79 (Fed. Cir. 2008); Reddy H. Jacobsen v. Katzer: The Federal Circuit Weighs in on the Enforceability of Free and Open Source Software Licenses // Berkeley Technology Law Journal, 2009. N 24. P. 319. Wallace v. IBM, 467 F.3d 1104 (7th Cir. 2006);

10 ч. 1 ст. 3 ФЗ от 01.06.2005 N 53-ФЗ "О государственном языке Российской Федерации"

11 См. подробнее: Heather J. Meeker. The Open Source Alternative. Understanding the Risks and Leveraging Opportunities. John Wiley & Sons. 2008.

13 См. подробнее: Савельев А.И. Лицензирование программного обеспечения в России. Законодательство и практика. М.: Инфотропик, 2012.

14 См., подробнее: Савельев А.И. Свободные лицензии на программное обеспечение в контексте реформы гражданского законодательства // Вестник гражданского права. 2012. N 4. С. 75 - 101.


<< Предыдущая          Следующая >>