OEM-соглашения, подписки, «облака».

Аббревиатура «OEM» (от англ. Original equipment manufacturer-

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

Суть OEM-схем (применительно к программам) такова: в силу различных причин (например, для расширения функциональных возможностей программы и т.п.) происходит объединение нескольких программ, и к конечному потребителю они попадают уже «в связке», единым продуктом. Существует несколько аналогичных схем, под аббревиатурами ISV (Independent software vendor), VAR (Value-added reseller) и др., но для единообразия в тексте данной работы, назовем ОЕМ-схемой любую, предусматривающую объединение продукта (в том числе программного) одного производителя с продуктом другого.

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

компьютерных программ), целесообразно обращаться к OEM- поставщику . В таком случае, именно производитель OEM-решений заключает все необходимые лицензионные договоры, тем самым собирая воедино необходимые интеллектуальные права, чтобы предоставить пользователю готовое решение, отвечающее его запросам. При этом пользователь не заключает и не согласует несколько (иногда десятки) различных договоров с ^{[87] [88]}

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

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

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

Обобщая, программное обеспечение может быть передано для использования в ОЕМ-схеме по трем основным вариантам:

1. Передача по лицензионному договору. Такой способ, согласно ГК РФ, является основным, предусмотренным для использования программ любыми способами, в том числе и включением одного продукта в другой. К нему прибегают отечественные производители и часть зарубежных. Четвертая часть ГК РФ довольно гибко подходит к вопросам написания способов использования программы (допускаются не только способы, прямо предусмотренные ГК РФ в ч. 2 ст. 1270, но и другие, не противоречащие законодательству и понятные сторонам договора), что позволяет «выписать» ясную и «красивую» ОЕМ-схему. По мнению автора, именно лицензионный договор позволяет наиболее четко описать взаимодействие сторон OEM- партнерства, и рекомендуется к приоритетному использованию на территории России.

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

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

Обычно они ограничиваются неким декларативным документом или указанием на официальном сайте, разрешающим использование. Увы, согласно законодательству РФ, такие документы не всегда имеют все требуемые атрибуты и зачастую работать по ним можно только потому, что мало кто захочет предъявлять претензии. На данный момент в нашей стране предприняты определенные шаги по «легализации» открытых лицензий, в том числе, таких как GNU GPL, что позволяет более «чисто» взаимодействовать с зарубежными правообладателями программного обеспечения, распространяющими свою продукцию под их условиями. Стоит сказать, что речь не идет о каком-либо включении известных западных лицензий в текст ГК РФ, однако их использование должно стать более прозрачным и понятным. Подробнее на этом вопросе автор останавливается в третьей главе исследования.

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

При формировании OEM-соглашения важным также будет и определение того, кому будут принадлежать интеллектуальные права на итоговое решение. Можно выделить следующие варианты (условные обозначения: А - продукт, производимый приобретателем; В - компонент, приобретенный по ОЕМ - схеме, С - итоговый продукт).

Вариант 1: А+В = С, по результатам соглашения сторон возникает отдельное произведение, правообладателем которого становится

производитель компонента А или B (иные варианты распределения прав на итоговое произведение, допустим, переход исключительного права на него к компании-дистрибьютору, также возможны). Приведем пример: компания- производитель музыкального проигрывателя-каталогизатора заключает

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

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

Вариант 3: А+В = А - Наименование исходного продукта не меняется, не возникает отдельного нового произведения, и появляется специальная версия исходного продукта, с расширенным функционалом за счет ОЕМ- компоненты. В качестве примера приведем пример из практики автора, когда в результате заключения соответствующего OEM-соглашения к базовому программному продукту - операционной системе был добавлен модуль стороннего производства, отвечающий за криптографию по стандартам, предусмотренным российскими руководящими документами в области информационной безопасности.

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

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

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

Кроме того, с юридической точки зрения, OEM позволяет привнести на рынок иностранные программы по договору, полностью соответствующему российскому законодательству, заключённому с российским поставщиком, что расширяет возможную сферу их реализации. Благодаря использованию OEM-лицензирования устраняются существующие сложности в применении открытых лицензий на территории России, а юристы получают возможность использовать прозрачные и четкие конструкции соглашений, без отсылок к не всегда известному и понятному праву других государств. Существуют и противники данного метода (например, М. Брауде-Золотарев), однако их доводы, как правило, основываются на идеологических причинах или желании изоляционного пути развития области компьютерных программ, что не может считаться позитивным.

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

Подписка: Под «подписочным» (от англ. “subscription” - подписка) обычно подразумевают такой способ приобретения программы, когда пользователь оплачивает какие-либо услуги (техническая поддержка, абонентское обслуживание) срочного или объемного характера (не более Y месяцев обновлений, не более Х запросов), и в дополнение к ним безвозмездно приобретает срочную же лицензию на обслуживаемую программу. Текст лицензии при этом может содержаться как в договоре об оказании услуг, как приложение, так и находиться в отдельном документе или быть «оберточным». Таким образом, пока подписка оплачена - сохраняет свое действие и лицензия, но при этом первичная роль отводится именно приобретению услуги. По истечению срока действия подписки, лицензия, как правило, отзывается, но данный принцип не является обязательным и зависит от существенности оказываемых услуг и их влияния на функционирование программных продуктов. В качестве примера программ, лицензия на которые не отзывается по истечению срока действия подписки, можно привести ОС Red Hat Linux , и коммерческую версию справочно-правовой системы «Консультант Плюс» (лицензия не публичная). По истечению подписки обе эти программы теряют возможность обновления, что существенно уменьшает их функциональность в будущем. Для примера обратной ситуации, когда лицензия прекращается вместе с окончанием срока действия подписки, можно упомянуть систему электронного управления контентом Alfresco, условия использования которой изложены на сайте правообладателя^{[89] [90]. По истечении срока подписки пользователь, продолжающий использование программы, считается}

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

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

«Облака»: Для понимания этой схемы проанализируем такую ситуацию: время от времени организации необходимо использовать специализированную программу с высокой стоимостью лицензионных отчислений, но ее использование требуется не настолько часто, чтобы ее приобретение оказалось экономически выгодным (к примеру, отправлять налоговую отчетность, обрабатывать некие данные, получение которых занимает дольше времени, чем обработка, моделировать ситуации на основе результатов исследований и т.п.). Также, используемая программа может быть требовательной к специфичному аппаратному обеспечению или среде исполнения. В этом случае на помощь могут прийти так называемые «облачные» решения (от англ. cloud solutions). Суть этой схемы заключается в том, что для обработки данных пользователя на время предоставляется удаленный доступ к программным ресурсам поставщика облачных услуг, т.е. услуг по обработке данных пользователя на программно-аппаратных средствах лицензиата программы. Как правило, предоставляется либо конкретное приложение (SaaS - Software as a service - приложение как услуга) или операционная система (PaaS - Platform as a service - платформа как услуга)^{[91] [92]}, в любом случае, поставщик таких «облачных» решений (если он не является правообладателем) выступает перед правообладателем конкретной программы в роли лицензиата, приобретая необходимые лицензии. И именно поставщик отвечает за соблюдение условий использования программы, как правило, получая специальные условия, допускающие использование программ «в облаке». Это - не прокат в его классическом понимании, когда на время предоставляется экземпляр программы или оборудование с установленным на нём программным обеспечением, а именно услуга по обработке данных заказчика на средствах исполнителя.

Как отмечается А.М. Вилиновым, «пользователю облачных сервисов нет необходимости заботиться о ресурсах своего программного обеспечения и оборудования: облака позволяют запускать программы ... используя

92

мощности и вычислительные ресурсы удаленных машин ».

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

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

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

Тема «облаков» является очень актуальной и порождает множество дискуссий и вопросов по сей день. Недаром, два доклада на секции «VII Международного форума «Интеллектуальная собственность - XXI век»», посвященной правовой охране компьютерных программ, так или иначе затрагивали облачные вычисления и проблемы, возникающие в связи с их использованием. «Елена Войниканис посвятила выступление новым

стратегиям регулирования, используемым государством и бизнесом. Большое влияние на подход к авторскому праву, по ее словам, оказало внедрение облачных технологий. Кроме того, новые технологии приводят к необходимости изменения договорной базы, поскольку пользователи не приобретают непосредственно экземпляр программы, а значит, имеют дело не с товаром, а с услугой, а Александр Савельев отметил, что облачная модель дистрибуции вызывает дискуссии в профессиональном сообществе; эксперт представил вниманию участников секции весь спектр существующих мнений по проблеме Software-as-a-Service. В частности, есть позиция, что это часть лицензионного договора, другие утверждают, что имеет место непоименованный договор. Разногласия накладывают свой отпечаток на структурирование договорных отношений, когда дело касается облачных

- 94

технологий. ». ^{[93] [94]}

Позднее А.И. Савельев конкретизировал свою точку зрения на тип договорных отношений, применимых к «облачному типу использования и распространения программы», и высказался за то, что в облаках применяется особый способ использования, названный им «предоставление удаленного доступа к программе посредством сети Интернет», и применение лицензионного договора для регламентации использования программы получателем облачных услуг в таком случае является некорректным. Аргументация при этом стоится на том, кто именно «контролирует» экземпляр программы, и что «именно SaaS - провайдер осуществляет использование программы в авторско-правовом смысле этого слова... но пользователь не осуществляет использование экземпляра программы каким бы то ни было способом, требующим вмешательства авторского права. он лишь потребляет ту услугу, которую предоставляет ему то лицо, которое действительно его использует^[95]». Потому предлагается использовать в «облаках» лишь договоры об оказании различных услуг или непоименованные договоры. Подобная категоричность и другие представленные аргументы (такие как отсылки к перечню примеров способов использования) выглядят несколько искусственными, поскольку, исходя из определения программы для ЭВМ в ГК РФ, цель использования программы - в получении определенного результата (т.е. получения определенных данных или обработки данных и т.д.), и именно возможность воспользоваться плодами этого результата есть основная цель использования компьютерной программы, а вовсе не контроль над экземпляром. Именно управление программой является ее использованием по основному назначению, исходя из технической сущности программы, а возможность использовать в дальнейшем результат ее работы - результатом, подтверждающим использование. При этом большинство поставщиков облачных услуг указывают, что не могут воспользоваться результатами работы программ, находящихся под управлением пользователей, согласно положениям о конфиденциальности и имеющимся мерам по обеспечению идентификации и аутентификации.

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

Учитывая, что облачные технологии в законодательстве не определены конкретно, существует множество понятий, используемых сообществом и участниками рынка, определяющих конкретные категории «облаков». В связи с этим стоит отметить статью И.А. Нестеровой, посвященную как раз адаптации терминологии, устоявшейся на западном рынке к российским реалиям^{[96] [97]. Однако, доводы об обязательном законодательном регулировании этой области от того же автора выглядят несколько преждевременным, т.к. описанные в статье проблемы облачных технологий касаются взаимодействия с контрольными и правоохранительными органами, а значит, требуют изменения методологической базы таких органов, а не нового законодательства. При этом, как справедливо на наш взгляд отмечает А. Лейба, «существует неопределенность в части юридической квалификации отношений в связи с использованием в РФ «облачных» сервисов, поскольку в действующем законодательстве РФ не учтены их особенности и регулируются преимущественно оффлайновые (традиционные)}

технологии ». Действительно, некоторое регулирование использования облачных схем находит свое отражение, например, в Федеральном законе № 152-ФЗ от 27.07.2006 «О персональных данных», однако предмет регулирования данного закона все же напрямую к компьютерным программам не относится. При этом, можно рассчитывать на позитивные изменения в данной сфере уже в обозримой перспективе: распоряжением Правительства РФ от 30.12.2013 N 2602-р утвержден план мероприятий «Развитие отрасли информационных технологий», в котором совершенствованию законодательства Российской Федерации (в виде подготовки проектов нормативно-правовых актов) для обеспечения развития облачных вычислений посвящен отдельный пункт, с указанием IV квартала 2105 года как отчетного^{[98] [99]}.

Не утихают различные дискуссии на эту тему и в сети интернет. В качестве примера, фонд свободного программного обеспечения (Free Software foundation, FSF) в лице известного и одиозного активиста Ричарда Столлмана (Richard Stallman) относится к облачным услугам крайне негативно, подвергая сомнению их безопасность и надежность: «В случае услуги вместо программы у пользователя нет даже исполняемого файла программы, которая проводит его вычисления: он находится на чужом сервере, где пользователи его не видят и не осязают. Таким образом, для них невозможно проверить, чем в действительности занята программа, и

99

невозможно изменить ее ».

Существуют государственные инициативы в этой области. Так, например, ОАО «Ростелеком» вкладывает очень серьезные средства в развитие Национальной облачной платформы. «Национальная облачная платформа — это комплекс интегрированных информационных систем, предназначенный для предоставления органам исполнительной власти различного уровня, органам местного самоуправления, коммерческим организациям и физическим лицам услуг по модели облачных вычислений^[100]». Несмотря на то, что оператор такого национального облака характеризует свою деятельность как оказание услуг, для обеспечения этой деятельности приобретается как оборудование, так и лицензии на использование программ^[101], что подтверждает изложенную в данном разделе позицию автора о сущности и специфике облачных услуг.

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

2.2.