Правовые аспекты создания производного программного обеспечения
Автор: Анастасия Нерчинская — юрист, эксперт образовательной платформы Moscow Digital School
Большая часть существующего в обороте программного обеспечение («ПО») является производным от других программных компонентов. Как правило, даже в рамках эксклюзивных отношений по заказной разработке ПО не создается «с нуля». При этом в отличие от других объектов авторского права[1] почти все компьютерные программы находятся в процессе постоянного изменения и развития[2], в результате чего в определенный момент может появиться новый объект – производная программа.
Чтобы не пропустить новые материалы «MDS Media», подписывайтесь на наш телеграм-канал
Изменения, вносимые в программы для ЭВМ на протяжении их жизненного цикла, далеко не всегда обусловлены какими-то системными факторами. Во многих IT-компаниях существует детализированный продуктовый бэклог, отражающий направления развития ПО на ближайшую или даже отдаленную перспективу. В то же время многие модификации софта могут носить совершенно случайный характер. Например, при необходимости срочного исправления ошибок (hotfix) или в связи с «внезапным озарением» разработчика.
ПРОБЛЕМЫ ПРАВОВОГО РЕГУЛИРОВАНИЯ ПРОИЗВОДНОСТИ ПО
Текущее правовое регулирование создания производных компьютерных программ не отличается особой системностью и понятностью. В данной области существует серьезная правовая неопределенность как на уровне законодательства, так и в судебной практике. При этом, представляется, что именно сфера правоприменения (а не законодатель) должна выработать четкие подходы и правила в регулировании такого рода вопросов.
Практическая сложность при решении правовых вопросов, связанных с переработкой компьютерных программ, возникает, в первую очередь, «благодаря» очевидной коллизии, заложенной в ГК РФ в рамках понятийного аппарата. Так, в соответствии с пдп. 9 п. 2 ст. 1270 ГК РФ под переработкой произведения понимается создание производного произведения. В отношении ПО тут же сделано уточнение – под переработкой (модификацией) программ для ЭВМ понимаются любые их изменения за исключением адаптации.
При этом ни законодательство, ни судебная практика не конкретизируют, какими должны быть «любые изменения» с точки зрения их объема и характера. Также, несмотря на то, что ГК РФ и ППВС № 10[3] явно «намекают» на то, что модификация ПО является процессом создания производной программы, а не результатом такой деятельности, в судебной практике, а также непосредственно в среде практикующих юристов, часто можно столкнуться с обратным подходом. Что, конечно, не добавляет ясности при раскрытии содержания понятий «модификация» и «производная программа».
Буквальное толкование приведенных выше норм ГК привело к широкому распространению следующей крайне спорной позиции. Если по прямому указанию ГК РФ переработка (в т. ч. модификация ПО) – это создание производного произведения, а в отношении ПО таковой признается любое изменение ПО, то для создания производной программы (со всеми вытекающими правовыми последствиями) достаточно будет внести в оригинальное ПО те самые «любые изменения». При этом, как упоминалось выше, на практике почти повсеместно понятия «модификация» и «производное ПО» отождествляются.
Такой подход представляется неверным, не отражающим существо законодательного регулирования правоотношений по созданию производного ПО, а его применение на практике чревато большим количеством злоупотреблений и ошибок.
Другие акты законодательства также не способствуют лучшему пониманию смысла соответствующих правовых категорий. Например, НК РФ применительно к программам для ЭВМ наряду с понятием «модификация» оперирует термином «обновление»[4]. В судебной практике ситуация еще более противоречивая. Судьи при рассмотрении споров, в которых затрагиваются аспекты модификаций и производности ПО, часто употребляют такие слова как «доработка», «релиз», «версия» и т.п., не раскрывая их содержания и нередко искажая правовой смысл понятия «производное произведение».
Следует отметить, что в правоприменительной практике по вопросам, посвященным производному ПО, отсутствует не только единообразие, но и в принципе какой-либо понятный, системный подход. В первую очередь это касается установления факта и момента создания производного ПО, определения условий и критериев его возникновения, правил оборота прав на него.
Разъяснения ППВС № 10, к сожалению, не только не добавили ясности в регулирование вопросов о производных компьютерных программах, но и в некотором смысле усугубили ситуацию. Готовящийся Обзор практики Суда по интеллектуальным правам по вопросам, возникающим при применении норм ГК РФ о правовой охране программ для ЭВМ и баз данных, проект которого на дату написания настоящей статьи размещен на сайте журнала СИП[5], в части модификаций компьютерных программ посвящен исключительно вопросам плагиата путем неавторизованной модификации, а не проблематике производного ПО.
Таким образом, на данный момент практически отсутствуют какие-либо репрезентативные примеры судебных актов, содержащие комплексный анализ вопросов производности ПО, на которые можно было бы ориентироваться и взять за основу при формирования единообразного подхода в сфере практического применения.
Все это привело к тому, что участники коммерческого оборота не имеют четкого представления о том, что такое производное ПО, где «заканчивается» одна (оригинальная) программа и «начинается» другая, созданная на ее основе.
ПРИЗНАКИ И КРИТЕРИИ СОЗДАНИЯ НОВОЙ (ПРОИЗВОДНОЙ) ПРОГРАММЫ ДЛЯ ЭВМ
ППВС № 10[6], дословно воспроизведя положение абз. 3 п. 31 утратившего силу ППВС / ВАС РФ №5/29[7], предусматривающее, что переработка произведения предполагает создание нового (производного) произведения на основе уже существующего, не уточняет, при каких обстоятельствах и в какой момент производное произведение будет считаться созданным, а в каких случаях – нет.
В одном из решений суд предложил следующее определение процесса переработки произведения[8]: «переработкой является заимствование или копирование элементов или части оригинального произведения в производном произведении. Копирование и заимствование в данном случае процессы активные и означают, что автору производного произведения известно об оригинальном произведении и он это оригинальное произведение в том или ином виде изменил, дополнил, обработал или просто скопировал часть оригинального произведения, добавив им лично созданные элементы, что и позволило ему создать новое произведение на основе уже существующего.»[9]
В другом деле суд отметил, что «при создании производного произведения происходит определенное заимствование элементов оригинального произведения, но при этом производное произведение воплощается в иной внешней форме, что придает ему творческую самостоятельность.»[10]
В качестве еще одной иллюстрации процесса создания производного произведения можно привести следующее решение суда: «в сети Интернет он [ответчик] выбирает из числа находящихся в свободном доступе базовые изображения, которые он в последующем дополняет и видоизменяет(…)элементами, получаемыми им также из числа находящихся в свободном доступе...».[11] В практике встречаются и другие подобные примеры.
Анализ приведенных фрагментов судебных актов позволяет сделать вывод, что в рамках создания производного произведения всегда имеет место процесс заимствования (в том числе путем прямого копирования) модификатором части элементов[12] оригинального произведения (в том числе – нелитеральных[13]), с добавлением им некоторого количества новых элементов, которые могут быть созданы разными способами, в том числе – путем обработки, видоизменения других элементов оригинального произведения.
Далее кратко проанализированы основные признаки (критерии) и условия, при соблюдении которых, по мнению автора, можно будет констатировать факт создания производной компьютерной программы.
1. Внесение определенного объема изменений в оригинальное ПО
В какие формы оригинального ПО могут или должны вносить изменения в процессе его переработки[14]? Обычно при создании производного ПО изменения вносятся в исходный текст программы. «Производность произведения подтверждается данными(…)о функциональных возможностях последней версии программы, о её дополнениях, изменениях, модификациях, исправленных ошибках, для осуществления чего необходимо внесение соответствующих изменений в исходный текст (код) программы(…)«Дополнение» и «Переработка» программного продукта предполагает фактически написание нового исходного кода продукта.»[15].
Однако на практике нередко возникают ситуации, когда требуется изменить именно (или только) «внешний вид» ПО (т.н. front-end), то есть ту его форму, которая отвечает за визуальные отображения. С одной стороны, каких-либо принципиальных возражений против такого подхода нет[16]. Однако единичные примеры из судебной практики показывают, что изменений только аудиовизуальной формы ПО (например, графического дизайна) может быть недостаточно для квалификации программы в качестве производной[17].
Возможно ли изменить ПО в форме объектного кода? Формально – да. Принципиальная возможность декомпиляции говорит сама за себя. При этом следует помнить, что техническая экспертиза путем сравнения объектных кодов программ (в отсутствие у истца доступа к исходному тексту ПО[18], полученного в результате декомпиляции ответчиком), позволит установить только факт внесения изменений, а не их детальное «смысловое» содержание[19]. Также очевидно, что изменить ПО в форме объектного кода намного сложнее. Для этого программисты должны обладать специальными навыками, но даже в этом случае качество такой работы не гарантировано. В связи с этим, представляется, что для создания полноценного производного ПО не имеет смысла вносить изменения ПО в форму объектного кода.
2. «За исключением адаптации»
В силу прямого указания ГК РФ при квалификации ПО в качестве производного должна быть исключена его адаптация. ГК определяет адаптацию как процесс внесения изменений в ПО исключительно в целях функционирования ПО на конкретных технических средствах пользователя или под управлением конкретных программ пользователя[20]. «…Создание в процессе выполнения работ по разработке(…)биллинговой системы на базе внедряемого программного обеспечения конкретных функциональных возможностей системы является адаптацией программы, то есть исключительно в целях функционирования программы для ЭВМ и базы данных на технических средствах ОАО «Кировэнергосбыт» и только для данной организации»[21].
Нередко комплекс действий по адаптации ПО может полностью совпадать с объемом изменений, вносимых в ПО при его модификации. Основным отличием одного процесса от другого является именно узкоцелевой характер изменений ПО в рамках адаптации. При этом не имеет значения, производится ли адаптация непосредственно в IT-контуре заказчика (пользователя) или имеет форму обновлений (например, собранных в патчи на территории разработчика-исполнителя, которые передаются пользователю программы по каналу связи).
При адаптации обычно изменяется конфигурация и настройки ПО, исправляются явные ошибки. В отношении адаптации в судебной практике выработаны устойчивые подходы. Например, в ряде решений прослеживается единообразная позиция о том, что новая конфигурация ПО не является новой программой. «… Внесение изменений[22] во все модули или только в отдельные блоки программы не приводит к появлению новой программы. Инспекция, подтверждая позицию Общества, говорит лишь о «новой конфигурации», а не о новой программе.»[23]
В другом деле суд, констатируя наличие адаптации, пришел к выводу о том, «что налогоплательщиком не было создано новое программное обеспечение, фактически выполненные работы были направлены на практическое применение программы, ее адаптацию и доработку конкретно для работы в обществе(…)отсутствует создание нового программного продукта, а имеют место расходы на доработку и адаптацию (настройку) программных продуктов под нужды Общества.»[24]
На примере приведенного выше судебного акта также может быть проиллюстрировано содержание действий по адаптации: «Обществу были оказаны услуги по анализу и адаптации программного обеспечения к уже имеющейся учетной информации в системе;(…)были осуществлены совмещение системных форматов программного обеспечения с уже используемыми приложениями, иные услуги по интеграции программного обеспечения в системные ресурсы Общества;(…)все работы по доработке производились уже после начала использования программного продукта, были направлены на повышение эффективности использования учетной системы «Галактика» в рамках деятельности Общества».
Действия по адаптации ПО (вне зависимости от их объема и характера) в силу специально установленных законом ограничений не могут привести к созданию производной программы. В отношении таких изменений, даже если они созданы личным трудом человека, ГК установил принципиальную невозможность авторско-правовой охраны. Таким образом, если совокупность действий по адаптации в конечном итоге получит некую объективную форму выражения (например, написанные скрипты, записи в настройках и т.п.), они не могут быть квалифицированы как произведение (ПО), в том числе производное.
Таким образом, чтобы определить, «дотягивает» ли объем планируемых изменений ПО до производной программы, необходимо убедиться, что они не носят характера адаптации. В рамках данной статьи нет возможности подробнее рассмотреть процесс адаптации. Данный вопрос хорошо проиллюстрирован в многочисленных судебных актах
3. Неразрывная связь с базовым ПО (не создано принципиально новое ПО)
Во многих судебных актах встречается указание на один из главных признаков переработки объекта авторского права, – узнаваемость оригинального произведения в производном. При решении вопроса о том, была ли в результате переработки ПО создана новая (производная) программа, данный критерий является одним из ключевых. В противном случае доказать, что производное ПО было создано на основе другого, как того требует п. 95 ППВС №10, будет невозможно.
«…При переработке произведение видоизменяется, когда его форма частично заменяется другими элементами. Но при этом само произведение, взятое в оригинальной, первоначальной форме, используется, остается узнаваемым.»[25] Это означает, что в производном произведении должна явным образом прослеживаться часть (но не 100%[26]) оригинального произведения (по смыслу п. 7 ст. 1259 ГК РФ и п. 87 ППВС № 10). То есть такая часть оригинального ПО, которая «в отрыве» от целостной программы сохраняет в себе определенный творческий элемент и набор черт, позволяющих сделать уверенный вывод о принадлежности такой части ПО к оригинальной программе в целом. Пусть не всегда эксплицитно, но в мотивировке судебных актов встречаются и другие аргументы, подтверждающие данный вывод.
Например, в одном из решений суд указал, что «…автором Минеевой Т.И. фактически осуществлено написание нового самостоятельного произведения, с использованием определенной части материала, ранее входившего в иное учебное издание(…)что не может расцениваться как издание тождественного произведения.»[27] В другом деле было отмечено, что «…для производного произведения принципиальное значение имеет общий образ переработанного произведения и его сходство(…)с первоначальным (исходным) произведением»[28].
В некоторых решениях суда также отмечается, что в рамках переработки не должен быть создан принципиально новый объект. «…Модификация исходной программы(…)может содержать новые решения, реализацию новых требований и новые функции, создающая новый объект авторского права, но не создающая принципиально нового программного продукта и не меняющая первоначального назначения программы.»[29]
В другом деле применительно к произведению изобразительного искусства суд указал, что «…под переработкой в данном случае понимается заимствование сюжета, композиционной схемы, системы организации живописного пространства, формальных принципов, ритмической системы, системы освещения и колорита художественного произведения с допущением небольших изменений, не приводящих к принципиально новому восприятию изображения[30]».
Приведенные примеры подтверждают ранее высказанный тезис о том, что в производном объекте оригинальное произведение должно оставаться узнаваемым. В противном случае при создании принципиально нового[31] объекта «связь» с оригиналом будет полностью утрачена, а следовательно, установить производность ПО будет невозможно.
Что подразумевается под узнаваемостью оригинального произведения в производном? Как отмечалось выше, в производном произведении (в частности, ПО) должны сохраниться какие-либо части оригинального произведения. С учетом содержания действующих критериев охраноспособности частей произведения[32] в производном ПО должны присутствовать такие элементы оригинальной программы, которые могут быть юридически квалифицированы как ее части, имеющие самостоятельную авторско-правовую охрану. В силу этого такие части оригинального ПО «в составе» производного ПО могут быть защищены от правопритязаний третьих лиц, включая модификатора. То есть в рамках производного ПО авторские права на такие части оригинального ПО безусловно сохраняются за автором (правообладателем) оригинальной программы и не переходят к автору производного ПО.
Чем больше глубина переработки программы, тем сложнее определить ПО (его части), взятое за основу. «…Полностью исключать возможность создания одной программы на базе другой нельзя, но тогда надо признать, что исходная программа была глубоко переработана»[33]. Следовательно, если модификатор настолько «увлечется» переработкой, что в результате от оригинального ПО останется лишь его «неузнаваемая» или нетворческая часть[34], можно будет ставить вопрос не о производности, а о создании принципиально нового самостоятельного ПО, несмотря на то, что автор «вдохновлялся» или пытался использовать в качестве основы оригинальное ПО.
4. Творческий характер изменений
Данный критерий также является одним из главных при определении производности ПО. Производные произведения относятся к объектам авторских прав[35], следовательно, к ним в полной мере применяются соответствующие критерии охраноспособности. Производное ПО должно быть создано творческим трудом его автора (модификатора).
Наличие в произведении творческого элемента (вклада) определяется (верифицируется) судом[36] на основе критериев, выработанных правовой доктриной. Законодательство их не устанавливает, и, как представляется, в силу объективной невозможности «не должно» этого делать. Таким критерием в отношении объектов авторского права, по общему правилу, является независимость (автономность, самостоятельность) создания или переработки соответствующего объекта. При этом наличие творческого элемента презюмируется – производное ПО считается соответствующим данному критерию, пока не доказано иное.
Как определить независимость создания производного ПО? «…Ключевым критерием независимости создания двух программных продуктов является отсутствие значимых совпадений во всех исходных текстах (кодах программ), за исключением: используемых стандартных библиотек и шаблонов, канонических фрагментов кода и наименований переменных, используемых в общедоступной документации и учебно-методической литературе.»[37].
Данный подход наиболее репрезентативен в рамках споров о плагиате, где ключевым фактором, влияющим на исход дела, является установление неслучайного характера совпадений кода. Применительно к спорам по вопросам производности ПО данный подход также может быть применен с учетом определенной его «адаптации». Дело в том, что при создании производного ПО, как было рассмотрено выше, вполне допускаются «неслучайные» совпадения в кодах оригинального и переработанного ПО (как раз отсутствие таковых будет критичным для установления факта производности).
Таким образом, при создании производного ПО некоторые части оригинального ПО могут быть заимствованы (в том числе, путем прямого копирования) модификатором. Допустимый объем таких заимствований является оценочным (то есть не является принципиальным), но представляется, что он не должен быть очень существенным. В первую очередь, это относится к масштабному заимствованию из оригинального ПО «условно творческих», а также полностью неохраняемых элементов, которые использовал автор оригинального произведения[38]. Связано это с тем, что если часть оригинального ПО внутри производной программы будет состоять из большого количества «общедоступных» компонентов, это не столько поставит под сомнение ее творческое начало (под риском утраты ее охраноспособности в рамках производного ПО), сколько «нарушит» свойство узнаваемости (то, что общедоступно, может быть узнаваемо во многих продуктах помимо ПО, положенного в основу переработки)[39].
Основными такими «условно творческими» и «нетворческими» элементами являются следующие:
(1) образцы и примеры кода, которые широко используются в образовательных целях («…все использованные приемы многократно описаны в общедоступных учебниках web-программирования»[40]);
(2) общедоступные компоненты ПО с открытым исходным кодом[41];
(3) совпадения, обусловленные рутинными и шаблонными процедурами и операциями, характерными для используемого языка программирования или интегрированной программной среды;
(4) совпадения кода встроенных модулей ПО, генерируемых функционалом используемых платформ, в том числе системами на основе «искусственного интеллекта» («…основная же масса кода создаётся генератором исходных текстов и не содержит каких-либо характерных для конкретного разработчика авторских «трюков», которые обычно и позволяют определить авторство в программах на других языках программирования.»)[42]
То есть, все те фрагменты кода, которые при минимальных усилиях широко доступны каждому.
Чтобы производное ПО в целом прошло «творческий тест», имеет смысл руководствоваться следующим правилом. В переработанной части модифицируемого ПО (то есть в том объеме изменений, которые необходимы в соответствии с рассмотренным ранее критерием №1) автор должен добавить определенный набор элементов «от себя лично» (т. н. чистый код). В некоторых судебных актах такие изменения называются принципиальными. При этом автору производного ПО не следует ограничиваться использованием уже готовых фрагментов кода (вне зависимости от того, кто является их автором), в том числе взятых из указанных выше общедоступных источников, а также совершением стандартных операций линкования и интеграции готовых компонентов.
Иными словами, в том объеме изменений, которые модификатор добавляет в оригинальное ПО не должно быть значительного объема неслучайных совпадений[43] с оригинальным произведением (в идеале в добавленной модификатором части кода каких-либо совпадений с оригинальным ПО не должно быть вообще). В связи с этим следует подробнее остановиться на паре менее очевидных моментов, когда совпадения все-таки могут быть признаны случайными, не влияющими на риск признания соответствующих изменений «нетворческими» или тождественными фрагментам оригинального ПО.
Если «дополненная» часть производного ПО будет очень похожа на соответствующую часть оригинального ПО по причине миграции разработчиков[44], такие совпадения также могут быть признаны созданными независимо от оригинального ПО (в данном случае автор оригинального произведения может совпадать в одном лице с автором производного)[45]. Однако, в такой ситуации будет существенно осложнен процесс доказывания независимости создания производного ПО, поэтому лучше избегать подобных сценариев.
Также совпадения в коде могут иметь место в силу т.н. «естественной схожести» (то есть, когда выбор решения у программиста, может быть, и есть, но он не велик). «…Базы данных различны по организации хранения данных, а схожесть их не выходит за пределы естественной схожести баз данных, хранящих схожую информацию, в связи с чем эксперт не делает вывод о том, что базы данных Общества являются прямыми подмножествами баз Компании(…)выявленная схожесть не выходит за рамки естественной схожести программ, разработанных в одной и той же системе программирования для решения одной и той же на задачи на одной и той же аппаратуре.»[46]
«Поскольку количество совпадений в кодах приложений и баз данных незначительно и объясняется естественными причинами (общей сферой автоматизации, принятыми в сфере программистов обозначениями и стандартными программистскими решениями), схожесть внешнего вида программ объясняется одинаковыми потребностями пользователей, не найдено явных признаков заимствования и имеются отличия в архитектуре, экспертом сделан вывод, что программа «QuartFarm» была разработана самостоятельно без переработки каких-либо частей программы «Аптека-Урал»»[47].
Таким образом, если судья не обнаружит определенной «новизны» модифицированной части ПО («…при этом указанные расхождения не образуют элемента новизны применительно к исходному коду «Alerts»[48]), такое ПО может не быть квалифицировано как производное. При этом какой-то особой креативности, оригинальности или новизны (с точки зрения принципиальной неповторимости элементов при параллельном творчестве) для целей признания ПО производным не требуется[49].
5. СУЩЕСТВО ИЗМЕНЕНИЙ (КАЧЕСТВЕННЫЙ КРИТЕРИЙ)
Понятие «изменение», которым оперирует легальное определение модификации, с очевидностью предполагает отклонения как «в плюс» (например, добавление нового кода), так и в обратную сторону (например, удаление каких-то элементов из оригинального ПО). Тем не менее, на практике сложился единообразный подход, согласно которому чтобы программа могла считаться производной, она явным образом должна содержать в себе какие-то качественные («поведенческие») элементы, которых не существовало в оригинальной программе[50]. Иными словами, принято считать, что производная программа должна быть чем-то лучше («быстрее», «умнее») оригинальной. Например, производное ПО может быть дополнено новыми модулями[51], дополнительным функционалом, элементами, позволяющими решать дополнительные задачи[52] и т.п. При этом, чем очевиднее будет презентация таких новых возможностей программы, тем проще будет доказать ее производный характер.
В рамках данной статьи не представляется возможным показать все многообразие примеров из судебной практики, иллюстрирующих содержание таких качественных элементов. По итогу ее обобщения можно сделать вывод, что «улучшение» оригинальной программы может выражаться в изменении следующих его характеристик:
(1) функциональные (расширяются полезные возможности ПО, явно ощутимые для пользователя);
(2) технические (программа быстрее работает, оптимизирован процесс обмена данными, сокращен объем занимаемой памяти);
(3) эксплуатационные (требуется меньше временных или технических ресурсов для адаптации, внедрения и техподдержки ПО);
(4) экономические (стоимость процессов по поддержке ПО снижается). Обычно на практике при создании т.н. новой коммерческой версии программы имеет место сочетание указанных изменений, так как некоторые из них являются взаимозависимыми.
Следует помнить, что характер (содержание) таких изменений лежит за рамками правовой плоскости. Однако юристам нужно позаботиться о том, чтобы в случае спора была возможность явным образом продемонстрировать наличие в продукте соответствующих изменений и доказать их качественный «смысл». Само по себе наличие технических изменений в ПО, которые (вне зависимости от их объема) не придают программе каких-то новых свойств или «навыков», будет квалифицировано просто как модификация, не порождающая нового объекта.
6. ВТОРОСТЕПЕННЫЕ КРИТЕРИИ ПРОИЗВОДНОСТИ ПО
Некоторые суды оценивают соответствие ПО или его частей ряду других критериев, которые, по их мнению, свидетельствуют о создании производной программы. В частности, иногда применяется количественный критерий – сколько добавления в коде «весят» в определенных «единицах» измерения[53]. Иногда при применении данного критерия суды, ориентируясь на экспертные заключения, упоминают о существенности[54] или значительности изменений в коде, говоря о таковых в «количественном» контексте.
Другие суды (особенно это характерно для налоговых споров, в рамках которых оценивается возможность постановки изменений в коде на учет в качестве нематериального актива или оценке правомерности применения определенных налоговых льгот) оценивают возможность использования сделанных модификатором изменений отдельно от некого «ядра» (части оригинального ПО). «Патч расширений не является самостоятельным объектом, не может быть самостоятельно использован, то есть не является объектом (выделенным или отделенным (индивидуализированным) активом), способным приносить экономическую выгоду(…)Следовательно, вывод Инспекции о создании нематериального актива не подтвержден»[55].
Также существует мнение о том, что дополнительным критерием производности ПО является постоянный характер изменений, добавленных модификатором. Это совершенно очевидный признак производного ПО, поскольку, в противном случае, не соблюдался бы ряд изложенных выше критериев, поэтому не имеет большого смысла выделать его в качестве основного.
Представляется, что данные критерии, безусловно, могут быть учтены судом в качестве косвенно свидетельствующих о создании производного ПО и использоваться в дополнение к основным, рассмотренным выше. Но сами по себе он не являются основополагающими для выводов о производности компьютерных программ.
К сожалению, приходится констатировать, что далеко не все существующее ПО, которое позиционируется как производное, соответствует указанным выше критериям. Если цена вопроса высока, оценку на соответствие ПО как объекта инвестиций признакам производности, следует проводить «на берегу», не создавая потенциально конфликтной ситуации на случай, если дело дойдет до суда.
[1] За исключением баз данных, которые в этом контексте схожи с ПО.
[2] В противном случае компьютерная программа очень быстро морально устаревает, утрачивает свойства совместимости с созависимыми компонентами и в итоге перестает быть конкурентоспособной.
[3] Абз. 4 п. 87 Постановления Пленума Верховного Суда Российской Федерации № 10 от 23 апреля 2019 года (далее – «ППВС № 10»).
[4] Ч. 2 п. 1 ст. 174.2 НК РФ, пп. 19 п. 2 ст. 346.5 НК РФ и др. При этом правила п. 1 ст. 11 НК РФ в данном случае фактически не применимы, поскольку понятие «обновление» не определено ни в одной из отраслей законодательства и раскрывается лишь на уровне отдельных подзаконных актов по стандартизации и сертификации.
[5] http://ipcmagazine.ru/official-cronicle/review-of-the-practice-of-the-intellectual-property-rights-court-on-issues-arising-from-the-application-of-the-norms-of-the-civil-code-of-the-russian-federation-on-the-legal-protection-of-computer-programs-and-databases
[6] Абз. 4 п. 87 ППВС №10.
[7] Постановление Пленума Верховного Суда РФ № 5, Пленума ВАС РФ № 29 от 26.03.2009 «О некоторых вопросах, возникших в связи с введением в действие части четвертой Гражданского кодекса Российской Федерации».
[8] Дело рассматривалось в отношении иного объекта авторских прав, но выводы вполне могут быть применимы и к ПО.
[9] Постановление Десятого арбитражного апелляционного суда от 01.09.2020 № 10АП-577/2020, 10АП-1039/2020 по делу № А41-51287/2019.
[10] Постановление Суда по интеллектуальным правам от 12.09.2019 № С01-291/2018 по делу № А41-54653/2017.
[11] Постановление Девятого арбитражного апелляционного суда от 21.11.2019 № 09АП-52987/2019-ГК по делу № А40-77822/2018.
[12] При воспроизведении 100% оригинального произведения «в составе» другого ПО последнее не может быть квалифицировано как производное от оригинального
[13] Например, структура хранения данных.
[14] Напомним, что существует 4 основных формы ПО: исходный текст, объектный код, подготовительные материалы, полученные в ходе разработки ПО, а также аудиовизуальные отображения ПО (две последние формы ПО в ППВС №10 (абз. 4 п. 81) почему-то именуются «частями» ПО).
[15] Решение Октябрьского районного суда г. Ижевска №2-1868/2015 год 13 марта 2015 года. Разумеется, в данном случае такими сведениями подтверждается (и не прямо, а косвенно) не производность ПО, а только содержание (характер) изменений в оригинальное ПО.
[16] За исключением, пожалуй, одного возражения – front-end ПО не должен быть реализован исключительно с помощью средств HTML или CSS, поскольку данные языки разметки и каскадных таблиц стилей формально не являются языками программирования. При использовании других языков, например, react, java script и т.п. – это будет вполне допустимо.
[17] Постановление Девятого арбитражного апелляционного суда от 06.03.2019 № 09АП-6538/2019-ГК по делу № А40-181017/18.
[18] Различия устанавливаются по дате создания, контрольной сумме, побайтовому сравнению в целом, количеству байт, занимаемых файлами в памяти и т. д.
[19] Что, безусловно, может помочь истцу в рамках спора о плагиате, но вряд ли факт изменений, установленных в рамках сравнения только объектных кодов ПО, может выступать сильным аргументом в пользу создания производного ПО.
[20] Пдп. 9 п. 2 ст. 1270 ГК РФ.
[21] Постановление Второго арбитражного апелляционного суда от 05.08.2016 № 02АП-4118/2016 по делу № А28-9466/2015.
[22] В рассматриваемом случае изменения не приводили к созданию дополнительного функционала.
[23] Решение арбитражного суда Кемеровской области от 29 августа 2012 года по делу № А27-10302/2012.
[24] Постановление Семнадцатого арбитражного апелляционного суда от 22.01.2015 № 17АП-16780/2014-АК по делу № А71-5707/2014.
[25] Постановление Десятого арбитражного апелляционного суда от 01.09.2020 № 10АП-577/2020, 10АП-1039/2020 по делу № А41-51287/2019; Постановление Одиннадцатого арбитражного апелляционного суда от 9 июля 2019 г. по делу № А72-20288/2018; Постановление Суда по интеллектуальным правам от 16.01.2018 № С01-929/2017 по делу № А40-207329/2015.
[26] Т.е. модификатор при переработке воздействует на оригинальное ПО «изнутри», а не «снаружи».
[27] Постановление Тринадцатого арбитражного апелляционного суда от 17.08.2010 по делу № А56-1900/2010.
[28] Постановление ФАС Уральского округа от 01.09.2011 № Ф09-5444/11 по делу № А60-45012/2010.
[29] Это был довод заявителя, но суд с ним согласился и положил в основу мотивировочной части (Постановление Девятого арбитражного апелляционного суда от 11.03.2013 № 09АП-3533/2013-АК по делу № А40-130312/12-140-876).
[30] Апелляционное определение Московского городского суда от 16.11.2018 по делу № 33-50588/2018.
[31] Тот факт, что производное ПО нередко называют «новой» программой упомянутого выше значения не меняет; в данном контексте «новое» ПО означает лишь «еще один» объект авторских прав, которым является производное произведение.
[32] П. 81 ППВС №10.
[33] Постановление Четырнадцатого арбитражного апелляционного суда от 04.09.2020 № 14АП-5315/2020, 14АП-5658/2020 по делу № А05-12896/2018.
[34] При этом неважно, какой она будет иметь «вес» в строках или процентах кода.
[35] Пдп. 1 ч. 2 ст. 1259 ГК РФ.
[36] А не техническими экспертами (как полагают некоторые исследователи), и тем более не самим автором.
[37] Постановление Тринадцатого арбитражного апелляционного суда от 11.10.2019 № 13АП-6241/2019 по делу № А56-75305/2018.
[38] При этом следует помнить, чтобы части оригинального произведения, сохранившиеся в производном, получили охраноспособность, таких «условно творческих» и неохраняемых элементов в указанных частях должно быть минимальное количество.
[39] Из похожей логики исходит и ППВС № 10 (абз. 3 п. 95), именуя такие компоненты «одной и той же исходной информацией», использование которой не может быть квалифицировано как совпадение неслучайного характера, что крайне важно в спорах по делам о плагиате.
[40] Постановление Девятого арбитражного апелляционного суда от 26.12.2014 № 09АП-47286/2014-ГК по делу № А40-164273/2012.
[41] Сами по себе такие компоненты, разумеется, могут обладать признаками творчества и быть охраноспособными (факт их нахождения в открытом доступе сам по себе не приводит к прекращению авторско-правовой охраны). Но в силу их широкой доступности, по мнению автора, они вряд ли могут претендовать на роль основного «творческого компонента» при создании или переработке ПО.
[42] Решение Арбитражного суда г. Москвы от 27 октября 2016 года по делу № А40-141340/15-15-1130.
[43] Чем больше их будет в «добавленной» части производного ПО, тем больше вероятность банального воспроизведения большей части оригинального ПО, или включение в состав добавленного кода многих «нетворческих» элементов.
[44] О чем следует сообщить эксперту, если будет проводиться экспертиза.
[45] При переходе на другую работу работник в силу естественных причин продолжает писать ПО так же, как он это делал раньше (всегда, на любых работах), у него в течение длительного времени сохраняется собственный «стиль», он совершает характерные для него ошибки, которые будут каждый раз «воспроизводиться» при любых его новых вполне самостоятельных разработках. В данном случае невозможно будет судить о плагиате/прямом заимствовании (неслучайном совпадении кода) или о нетворческом (несамостоятельном) характере создаваемого ПО. Такие выводы также иногда справедливы и применительно к коллегам, которые очень тесно работали в одной команде разработки, учились друг у друга и «пишут» ПО похожим образом.
[46] Постановление Четырнадцатого арбитражного апелляционного суда от 04.09.2020 № 14АП-5315/2020, 14АП-5658/2020 по делу № А05-12896/2018.
[47] Постановление ФАС Уральского округа от 11.07.2013 № Ф09-6382/13 по делу № А60-27815/2012.
[48] Постановление Тринадцатого арбитражного апелляционного суда от 28.06.2011 по делу № А56-69593/2010.
[49] Абз. 3 п. 80 ППВС № 10.
[50] То есть, скорее всего, удаления каких-либо компонентов, «ухудшения», «обеднения» ПО по сравнению с оригинальным, будет недостаточно для признания производности (хотя объективно, такие действия тоже считаются изменением ПО), и необходимо будет добавить часть новых элементов в кодовую базу.
[51] Постановление Пятого арбитражного апелляционного суда от 11 апреля 2016 г. № 05АП-1818/2016; Постановление Девятого арбитражного апелляционного суда от 18.02.2016 № 09АП-60035/2015 по делу № А40-45539/13.
[52] Постановление Девятого арбитражного апелляционного суда от 13.10.2016 N 09АП-46547/2016-ГК по делу N А40-154016/2014.
[53] Как правило, таковыми «единицами измерения» выступают количество строк кода в абсолютном или процентном выражении, а также количество совершенных разработчиком «коммитов» («кнопка» и одноименное действие по вводу программистом фрагмента исходного текста в кодовую базу, свидетельствующие о факте внесения изменений в исходный текст.)
[54] Постановление Девятого арбитражного апелляционного суда от 21.03.2012 N 09АП-4406/2012-АК по делу N А40-94654/11-91-407.
[55] Постановление Второго арбитражного апелляционного суда от 05.08.2016 N 02АП-4118/2016 по делу N А28-9466/2015.
