Cегодня сложно представить компанию, в которой бы активно не использовались программы для ЭВМ. Не являются исключением банки и финансовые организации, для которых программы для ЭВМ в составе информационных систем и ИТ-услуги на их основе — неотъемлемая часть и во многом залог успешного бизнеса.
В этой связи многие банки не только приобретают и используют лицензионное программное обеспечение и заказные разработки, но и развивают собственную разработку. Поэтому вопросы правовой защиты программного обеспечения во всём многообразии ситуаций их создания и использования становятся как никогда актуальными, в том числе для банков. Об этом свидетельствуют и рекомендации Банка России, который в качестве одной из угроз информационной безопасности называет утрату прав (лицензий) на использование отдельных видов программ[1].
Какие вопросы необходимо учитывать банкам и другим компаниям в процессе разработки и использования программного обеспечения? В настоящей статье авторы дают ответ на этот вопрос, обобщая многолетний опыт юридического сопровождения «софтверных» проектов.
Статья изложена в виде небольших разделов, каждый из которых освещает отдельный «проблемный» вопрос, на который необходимо обратить внимание, чтобы не потерять права на программу или не оказаться в ситуации нарушения прав третьих лиц.
Стоит отметить, что в статье освещаются основные вопросы, но, конечно же, далеко не все. Так, отдельный интерес представляют вопросы создания и использования баз данных, которые остались за рамками настоящего материала.
1. ПРАВОВОЙ РЕЖИМ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ
Как показывает практика, у правообладателей не всегда есть понимание правового режима программного обеспечения, то есть того, какие элементы программы охраняются, а какие — нет, какое использование программы является нарушением.
Между тем, потенциальный правообладатель должен понимать правовой режим программ.
С точки зрения права, программа для ЭВМ — это объект авторского права, который по своему правовому режиму приравнен к литературному произведению. В этой связи, по общему правилу, охраняемой частью программы является форма, то есть код (исходный и объектный), и аудиовизуальные отображения, порождаемые программой. Содержание/суть программы (к ним, например, может быть отнесен функционал программы) авторским правом не охраняются. Это означает, что, вероятно, в большинстве случаев нарушением прав на программу будет признаваться буквальное или почти буквальное копирование кода (аудиовизуальных отображений). Правовой статус технических элементов, например, алгоритмов и логики, которая заложена в коде (вернее, идей и принципов построения этих алгоритмов), до конца не определён. Учитывая специфику авторско-правовой защиты, есть основания полагать, что такие элементы не всегда будут охраняться.
Чтобы суть правовой охраны объектов авторского права была понятнее, можно привести следующий пример. Если в литературном произведении изложен рецепт приготовления блюда (пусть даже очень оригинального), использование такого рецепта для приготовления блюда не будет считаться нарушением. Нарушением будет являться копирование текста, при условии, что такой текст является оригинальным результатом творческого труда.
Авторское право не охраняет идеи, концепции, принципы, методы, процессы, системы, способы, решения технических, организационных или иных задач, открытия, факты, языки программирования (п. 5 ст. 1259 ГК РФ). Например, на этом основании российские суды отказали в иске испанской компании к Первому каналу за использование формата телепередачи «Один в один». Суд по интеллектуальным правам следующим образом мотивировал своё решение: «Производственная библия является литературным произведением. В нём описано содержание телепередачи «Ваше лицо кажется мне знакомым» (перечислены её основные элементы, технология производства, принципы кастинга, технического оснащения, расположение камер и иные технические вопросы, в т. ч. расписание репетиций, примеров грима). Данное произведение включает в себя как охраняемые элементы (фотографии, логотип, схема), так и не охраняемые (концепции, идеи, принципы, методы, способы).
Суду не представлено доказательств того, что в спорной программе использовалось указанное литературное произведение или его часть. Как и доказательств того, что при её создании были использованы какие-либо части программы «Один в один». Ответчиком не отрицается факт использования идеи, метода. Вместе с тем, использование идеи, концепции нарушением авторского права в смысле ГК РФ не является»[2].
Патентное право, в отличие от авторского права, охраняет содержание решения, а не его форму.
Поэтому, если правообладатель понимает, что в конкретной программе особую ценность представляют принципы построения алгоритма/логики или иное техническое решение, необходимо задуматься о патентовании.
Яркой иллюстрацией того, как суды могут толковать предмет правовой охраны программ, является следующий судебный спор[3]. Новозеландская компания OTOY New Zealand Limited, правообладатель программы для рендеринга, обратилась с иском о нарушении к компании Пинксофт — российскому разработчику аналогичной по функционалу программы. В итоговом решении суд по результатам экспертизы отказал в удовлетворении иска на том основании, что буквального совпадения в исходном коде программ не было обнаружено. То, что в обеих программах используется один алгоритм обработки данных не свидетельствует о нарушении: «…законодательство не запрещает реализацию двумя разными программами для ЭВМ полностью или частично одного и того же алгоритма обработки данных, либо использование такого алгоритма в одном из множества модулей программ, такие программы не могут признаваться воспроизведёнными (скопированными) либо переработанными (модифицированными), если они имеют существенно разные исходные тексты/коды программ, о чём свидетельствуют метрики эксперта»[4]. Если бы у новозеландской компании был патент на алгоритм, действующий на территории России и защищающий алгоритм, она смогла бы предотвратить использование этого алгоритма на основании патентного права.
Указанный судебный спор связан с самостоятельной ёмкой задачей, на которую стоит обращать внимание при разработке и использовании программ для ЭВМ. Это оформление служебных разработок, то есть разработок, которые создаются работниками в пределах установленных для них трудовых обязанностей. Дело в том, что основателем российской компании-ответчика в указанном выше споре являлся бывший работник новозеландской компании, который, уйдя от работодателя, успешно занялся собственным делом, создав конкурирующую программу с похожим функционалом. Причём истец приводил аргументы о том, что бывший работник заимствовал разработки, созданные им в период трудоустройства у истца, но доказать ничего не смог.
2. ОФОРМЛЕНИЕ И УЧЁТ ПРАВ НА СЛУЖЕБНЫЕ РАЗРАБОТКИ
Существует распространённое заблуждение о том, что все разработки, которые создаются работниками компании, включая программы, автоматически принадлежат компании.
На самом деле, это не совсем так. Чтобы права принадлежали работодателю, необходимо правильно оформить трудовые отношения с работниками и документы по созданию программ. Трудовая функция работника должна недвусмысленно предусматривать обязанность по созданию программ (написанию кода, разработке интерфейса и т. д.). Если у работника неоднозначное название должности, в трудовом договоре, должностной инструкции и иных документах прямо не указано, что в обязанности работника входит создание программ, то работодатель попадает в зону риска: разработки, созданные этим работником, могут быть признаны неслужебными.
Здесь стоит привести примеры из судебной практики. В одном из дел суд посчитал, что права на программу, созданную работником, принадлежат не работодателю, а работнику, потому что последний был принят на должность «дизайнера-верстальщика», в обязанности которого не входит создание программ[5]. Интересно, что работник, по сути, в рабочее время занимался в основном созданием программы.
Из последних споров можно вспомнить спор между компанией ООО «Интервим» (дочерняя компания Veeam Software) и её бывшим работником[6]. Работнику удалось отсудить в первой инстанции у бывшего работодателя двадцать три миллиона рублей за незаконное использование его программы[7]. Поскольку судебное заседание по этому спору было закрытым, не все детали по нему доступны. Однако, как следует из открытых источников, в том числе публичных выступлений самого работника, у него не было явной должностной обязанности по созданию программ, частично программа создавалась до трудоустройства. Поэтому созданную работником программу работодатель мог использовать только на основании договора с работником.
Особую сложность представляют случаи совместной разработки программ работниками из разных, но аффилированных компаний.
Казалось бы, какие могут возникать проблемы в такой ситуации. Ведь компании группы вряд ли будут предъявлять друг другу иски. Однако сложности могут возникнуть, например, при продаже программы (или компании, для которой такая программа является основным активом). Неопределённая ситуация с правами на программу[8] может негативно сказаться на потенциальной сделке. Чтобы избежать каких-либо рисков при совместной разработке работниками группы компаний, необходимо заранее структурировать такие проекты и детально определять в договорах между компаниями права сторон на результаты работ.
Наконец, стоит отметить, что оформление прав на служебные разработки не устраняет все потенциальные риски, связанные с правами на собственные разработки. Крайне важным элементом является учёт собственных разработок, без которого сложно доказывать их служебный характер. При возникновении судебного спора (в том числе о правах на служебные программы) именно сторона, имеющая солидную доказательную базу, выигрывает спор. Учёт служебных программ может быть организован как в традиционной документальной форме, так и в электронном виде. Здесь законодательство и судебная практика не предъявляют особых требований. Главное, чтобы можно было соотнести конкретную разработку с соответствующими работниками и их трудовыми обязанностями.
3. НЕЗАКОННОЕ ИСПОЛЬЗОВАНИЕ ПРОГРАММ И ИНЫХ ОБЪЕКТОВ ИНТЕЛЛЕКТУАЛЬНОЙ СОБСТВЕННОСТИ ТРЕТЬИХ ЛИЦ
Следующая распространённая проблема, с которой сталкиваются компании — это незаконное использование программ третьих лиц, в том числе в собственных разработках.
Рассмотрим две ситуации нарушения прав третьих лиц: а) нарушение условий лицензионных договоров при использовании программ третьих лиц и б) использование чужих программ в собственных разработках.
Эти случаи незаконного использования программ третьих лиц имеют разные причины и последствия. В этой связи имеет смысл рассматривать их отдельно.
3.1. Нарушение условий лицензионных договоров
Как правило, незаконное использование лицензируемых продуктов возникает вследствие недостаточного учёта прав на программы третьих лиц, которые используются в хозяйственной деятельности. Особенно это актуально для больших компаний, которые используют много разных программ. В такой ситуации можно «упустить» истёкший срок лицензии или допустить большее количество пользователей, чем разрешено лицензией.
Условия лицензирования некоторых программных продуктов не всегда могут быть понятны, особенно для ИТ-специалистов. Нередко, помимо самого лицензионного договора, который подписывается сторонами, обязательными являются условия различных стандартных правил и положений, на которые по тексту договора есть ссылка. Как правило, такие стандартные документы публикуются на сайте компании-правообладателя программы.
В большей степени сложность вызывает интерпретация положений лицензии о способах использования программы (хотя, конечно, во многом сложности интерпретации зависят от специфики программы). Часто компании сталкиваются с проблемой невозможности внесения изменений в код программы, в том числе в целях адаптации и интеграции этой программы с разными устройствами и другими программами.
3.2. Незаконное использование в собственной разработке
Чаще всего незаконное использование чужого кода в собственной разработке возникает в связи с тем, что работники используют собственные разработки или разработки, которые они создавали в период трудоустройства у предыдущего работодателя.
Здесь важно отметить, что какие-то элементы, например, идеи/принципы построения технических решений использовать можно (о чём было сказано выше), но при этом они не должны представлять объект, защищаемый в качестве конфиденциальной информации прошлого работодателя. Несомненно, нельзя копировать исходный код без законных оснований.
Но ошибиться может каждый и использовать чужой код могут не только работники, но и разработчики, которым компании поручают разработку программ по договору заказа.
Какие риски таит даже не очень значительное на первый взгляд заимствование? Риск заключается в том, что правообладатель переработанной программы не сможет использовать программу, которую создали его работники (исполнители по договору). Таким образом, он оказывается в ситуации наличия у него «парализованных» прав. В дополнение, правообладатели заимствованных элементов могут предъявлять иски о нарушении исключительных прав.
Вопросы использования переработанных программ для ЭВМ также актуальны в сфере использования программ для ЭВМ из Единого реестра российских программ для электронных вычислительных машин и баз данных[9], когда некоторые из зарегистрированных программ представляют собой переработку аналогов, не находящихся в этом реестре. Здесь ключевым правовым вопросом становится квалификация пределов переработки исходных объектов и то, действительно ли в ходе неё создавался самостоятельный объект интеллектуальных прав.
Судебная практика показывает, что незаконное использование в собственной разработке чаще всего возникает именно потому, что работники и контролирующие разработку менеджеры не очень внимательно относятся к заимствованиям. Если формулировать иначе, отсутствует достаточный контроль над тем, что именно используется в разработке.
Здесь можно привести два примера из судебной практики.
В первом случае истец обратился в суд, потому что его бывшие работники использовали части принадлежащих ему программного кода и пользовательской документации в разработках для нового работодателя[10]. Суд согласился с доводами истца и удовлетворил иск. В этом споре интересно то, что суды анализировали использование не только самой программы, но и руководства пользователя.
Во втором случае тоже фигурировали бывшие работники истца, но решение было вынесено в пользу ответчика, т. к. совпадения в кодах программ были вызваны объективными факторами, а не незаконным заимствованием[11]. Обе программы были созданы на основе платформы 1С: Предприятие 7.7.
4. ИСПОЛЬЗОВАНИЕ ПРОГРАММ С ОТКРЫТЫМ ИСХОДНЫМ КОДОМ
Последний вопрос, который будет рассмотрен в настоящем обзоре ключевых вопросов в сфере защиты и использования программ, это использование Open Source Software — программ с открытым исходным кодом (далее для краткости — «с открытым кодом»). При использовании таких программ необходимо учитывать несколько моментов.
Во-первых, программа с открытым кодом — это программа, которая имеет правообладателей и распространяется по лицензионному соглашению. Такое лицензионное соглашение, открытая лицензия (в России она регулируется ст. 1286.1 ГК РФ), имеет юридические особенности. Между тем, требования такой лицензии необходимо соблюдать, как и требования любой другой лицензии. Нарушение условий открытой лицензии может повлечь юридическую ответственность и запрет на использование программы.
Зарубежная судебная практика о нарушении условий открытых лицензий является более развитой, чем российская. Так, интерес представляет дело, рассмотренное ещё 10 лет назад во Франции, где был спор между поставщиком компьютерного оборудования со встроенной программой для ЭВМ и покупателем такого оборудования. Покупатель заявлял о нарушении договорных условий, в том числе[12], в связи с непредставлением поставщиком и разработчиком оборудования исходного кода программ и удалением текстов лицензии вопреки требованиям GNU GPL. Апелляционный суд Парижа поддержал доводы покупателя о нарушении условий GNU GPL[13].
Во-вторых, программы с открытым кодом могут содержать условия, которые являются обременительными для конкретного проекта или компании. Например, использование в разработке кода, распространяемого по strong copyleft-лицензии, впоследствии будет означать необходимость предоставления исходного кода, а также прав на модификацию и последующее распространение всем пользователям этой разработки. Некоторые лицензии предусматривают иностранное применимое право и подсудность иностранным судам. Например, лицензия Red Hat предусматривает право Англии и подсудность английским судам, что означает необходимость юридического анализа, исходя из соответствующих национальных норм.
Наконец, стоит отметить, что существуют особенности, которые связаны с правовым режимом открытых лицензий. Например, в части гарантий лицензионной чистоты, распоряжения правами на продукт переработки, который содержит элементы открытого кода. Полноценное рассмотрение этих особенностей в рамках настоящей статьи не проводится, их рассмотрение может быть предметом отдельной статьи.
Главный вывод, который можно сделать из настоящего раздела, состоит в том, что в силу массового распространения и популярности программных решений на базе открытого кода, им необходимо уделять отдельное внимание.
5. Выводы: разработка и использование программ для ЭВМ как предмет для юридического бизнес-процесса
Очевидно, что в крупном технологически развитом бизнесе, к которому относится в т. ч. большинство банков, много авторов и разработчиков, которые, несомненно, без злого умысла (за исключением редких ситуаций):
Увы, немало «ответственных» менеджеров в организациях, при этом:
Всё это может происходить в больших холдингах, где много организаций, подрядчиков и информационных систем, где в потоках информации в них всех можно легко потеряться.
Это означает, что единственным методологически правильным ответом, на всё возрастающие юридические риски в сфере оборота программного обеспечения, является построение специального бизнес-процесса по защите и управлению правами на программы для ЭВМ, а также другие объекты интеллектуальной собственности (ИС), в рамках которого происходит:
***
Не имея целью раскрыть в рамках настоящей статьи особенности указанного бизнес-процесса, нужно отметить, что его «сердцем» должен быть реестр объектов ИС и прав на них. А сам процесс должен быть автоматизирован с обязательной интеграцией с существующими информационными системами — от сред разработки программ до систем бухгалтерского учёта.
[1] См., например, Ф. Я. Дзержинский «Об опасности иностранного ПО и рекомендациях Банка России», BIS Journal № 4(15)/2014.
[2] Постановление Суда по интеллектуальным правам от 8 мая 2015 г. № С01–320/2015 по делу № А40–84902/2014.
[3] Апелляционное определение Московского городского суда от 16.05.2018 по делу No.33–15686/2018.
[4] Решение Московского городского суда от 5 декабря 2017 г. по делу No.33–15686/2018.
[5] Решение Псковского городского суда по делу № 2–2496/2011.
[6] См. информацию по этому спору, например, https://300.pravo.ru/
[7] На момент написания настоящей статьи решение суда первой инстанции было отменено судом второй инстанции, однако окончательный исход дела еще не определен.
[8] Если в разработке участвуют работники разных компаний, ни одну из этих копаний невозможно назвать единственным правообладателем (за исключением случаев, когда отношения между этими компаниями имели надлежащее договорное оформление, что на практике является довольно редкой ситуацией).
[9] Реестр создан в соответствии со статьёй 12.1 Федерального закона «Об информации, информационных технологиях и о защите информации».
[10] Постановление СИП от 31 мая 2017 г. по делу № А40–141340/2015.
[11] Постановление СИП от 17 марта 2017 г. по делу № А27–6440/2013.
[12] Названное дело было комплексным и вопросы правомерного использования программ с открытым кодом были не единственными, которые рассматривались в рамках дела
[13] Решение Апелляционного суда Парижа 04/24298 от 16.09.2009 (http://fsffrance.org/news/arret-ca-paris‑16.09.2009.pdf).
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных
Отправляя данную форму вы соглашаетесь с политикой конфиденциальности персональных данных