Програмпластинка: как бизнесу не попасть впросак с использованием открытого кода
Кому принадлежит право на служебный код
Российский IT-рынок делает все большую ставку на открытый код (оpen-source software, OSS) и совместную разработку. Так, «Яндекс» недавно запустил SourceCraft, свой аналог популярной платформы GitHub, где обещает выкладывать исходники ключевых проектов; VK намерен раскрыть исходные коды своих программ для широкой аудитории, а deep‑tech‑стартапы публикуют библиотеки сразу в открытом доступе, надеясь собрать вокруг них комьюнити и идеи.
Сейчас, согласно закону, если разработчик устроен в компанию по трудовому договору, все права на созданные им продукты в рамках своих служебных обязанностей принадлежат работодателю. Поэтому зачастую бизнес уверен: если разработка велась в рабочее время — все права принадлежат компании. Но российская судебная практика не столь однозначна. Споры последних лет показывают: если компания не может подтвердить, что у сотрудника было четкое задание, право на продукт может остаться за разработчиком.
Например, если ПО создано в нерабочее время или обеденный перерыв и без связи с конкретными трудовыми задачами, все права на такую разработку будут принадлежать автору. Так, в одном из подобных дел суд по интеллектуальным правам указал, что, поскольку на разработку не было служебного задания, а также отсутствовали акты приемки-передачи служебного произведения, весь созданный работником код должен принадлежать именно ему.
Таким образом, бизнесу стоит озаботиться тем, чтобы исключительные права на ПО перешли от разработчиков к работодателю. Как правило, для этих целей в ведущих IT-компаниях разрабатывают целый комплекс документов:
- трудовой договор, в котором фиксируется, что разработчик занимается созданием служебного программного обеспечения. Также очень важно прописать размер и порядок выплаты авторского вознаграждения (да, это отдельная выплата работнику, в довесок к окладу);
- должностные инструкции работников, описывающие все трудовые процессы для каждой должности;
- положение о служебных произведениях и постановке служебных заданий — этот документ должен регламентировать порядок и способ постановки служебных заданий, приемку выполненных работ;
- служебные задания. Закон не устанавливает ограничений на способы постановки служебных заданий разработчикам — они могут оформляться через Jira, другие таск-трекеры, в мессенджерах или по электронной почте. Однако важно, чтобы выбранный порядок был закреплен во внутреннем положении о служебных произведениях. Рекомендуется перечислить все способы постановки задач, которые компания планирует использовать;
- акты приемки-передачи служебного произведения. После того как все указанные выше документы подготовлены, а программа написана, со всеми авторами-разработчиками (то есть членами рабочей группы) подписываются акты.
Теперь дело за малым: выплатить работнику его авторское вознаграждение, зарегистрировать программу для ЭВМ в Роспатенте и реестре российского ПО (при необходимости) и продавать.
Что с лицензиями на open source?
Открытый код используют практически все, но не все знают, что это может повлечь за собой определенные проблемы. Во-первых, его применение не означает абсолютной свободы действий в отношении конечного продукта. Open source лицензии имеют свои условия, и использование открытого кода в составе своей разработки предполагает их соблюдение, среди которых может быть: обязательное указание авторства, требование распространять производные работы под аналогичной лицензией (например, GPL), что может означать запрет на продажу конечного продукта, и другие ограничения. Бизнес должен внимательно анализировать условия лицензий и обеспечивать их соблюдение при интеграции компонентов open source-разработчиков в свои продукты, чтобы избежать возможных проблем — вполне может оказаться так, что компания заплатит огромные средства за разработку продукта, который впоследствии невозможно будет продавать.
Во-вторых, решения open source должны быть значительно доработаны, чтобы в результате появился новый, самостоятельный продукт, имеющий важное практическое значение, на который возникнут исключительные права. И изменения продукта должны быть не только заметны по качеству, но и могут измеряться количественно — например, если 20–30% кода стало новым по сравнению с оригиналом. Также это может быть добавление новых модулей или серьезная переработка функционала программы.
Незначительные правки в решения на базе open source грозят тем, что компания не сможет претендовать на исключительные права. Для защиты интересов бизнеса рекомендуется тщательно документировать процесс разработки с использованием открытого кода, обратить особое внимание на то, под какими лицензиями распространяется этот открытый код, какие они накладывают ограничения, а также следить за тем, чтобы переработка открытого кода была существенной.
Как включить open source в реестр российского ПО
Включение софта в реестр российского ПО Минцифры дает правообладателям возможность использовать меры государственной поддержки: освобождает от уплаты НДС при продаже программных продуктов, приоритет при участии в государственных закупках, а также право получать гранты на внедрение созданного ПО.
Правила включения в реестр Минцифры гласят:
- компания-резидент России должна владеть исключительными правами на весь продукт;
- ограничения открытых лицензий не должны препятствовать распространению ПО на территории России.
Таким образом, использование открытых лицензий может стать существенным препятствием для разработчиков при включении продуктов в реестр. Минцифры требует, чтобы компания владела исключительными правами, то есть внесла «существенные творческие изменения» в открытый код, а использование программного обеспечения в России не должно нарушать условия open source лицензий, на основании которых распространялись его компоненты.
Кроме того, нужно иметь в виду, что в текстах лицензий могут содержаться экспортные (санкционные) ограничения. Особенно этот риск вероятен, если юрисдикциями правообладателя компонента являются страны–члены Европейского союза и США. Некоторые правообладатели open source объявили о прекращении коммерциализации своего программного обеспечения для лицензиатов из России, и это является препятствием для использования производного от их продуктов ПО на территории России.
Надо понимать, что, хотя использование open source ускоряет разработку ПО, это не отменяет необходимости следить за соблюдением законодательства об авторском праве. Чтобы проект не превратился в юридическую мину замедленного действия, бизнесу крайне необходимо следить за процессом создания служебных произведений, вести реестр использованных OSS‑компонентов и условий их лицензий, документировать весь процесс разработки ПО. Тогда открытый код станет ценным активом, а не препятствием для коммерциализации созданного продукта.
Мнение редакции может не совпадать с точкой зрения автора