О защите интеллектуальной собственности на ПО и бюрократических палках в колесах
Недавно у нас в «Цифре» был небольшой внутренний вебинар по защите интеллектуальной собственности. Тема вызвала неподдельный интерес и много вопросов как со стороны нашей команды разработчиков, так и со стороны менеджмента. Мы попросили наших юристов Алексея Федосеева и Елизавету Дегтярёву на часть из них ответить на Хабре. В один пост у нас всю информацию вместить не получится, поэтому будет несколько. Этот, первый, будет о бюрократии — какими документами нужно обзавестись ИТ-компании, чтобы не получить в последствии конкурентов из числа бывших работников, а также о том, какие права есть у разработчиков и каков порядок их передачи.
Просьба иметь ввиду, что всё, что будет описано далее, касается отношений между работодателем и работниками. С индивидуальными предпринимателями, самозанятыми и просто гражданами, которые оказывают услуги по гражданско-правовым договорам (в народе именуемым «ГПХ»), дела обстоят иначе, и это тема отдельного разговора. Также мы не претендуем на полное раскрытие темы. Спорных моментов хватает и в законе, и в судебной практике, особенно когда речь идет о таком динамично меняющемся продукте, как софт. Так что, здесь мы расскажем в общих чертах только о внутренней документации — какие бумаги должны быть в компании и каково их внутреннее наполнение, а про нюансы — как-нибудь в следующий раз.
Для начала, давайте разберемся, что такое ПО с точки зрения права
ПО — это выраженная в объективной форме совокупность данных и команд, предназначенная для работы компьютерных устройств. Гражданский кодекс говорит о том, что ПО может быть написано на любом языке и в любой форме, включая исходный текст и объектный код.
В момент написания кода у автора-разработчика возникают интеллектуальные права. Вообще интеллектуальные права подразделяются на три вида — исключительные, личные неимущественные и иные права. Иные права нас не интересуют, так как в большинстве своем не применимы к ПО. Для нас важны первые два вида.
Личные неимущественные права — это права, которые остаются за автором навсегда (например, право быть указанным в качестве автора). Они неотчуждаемы, но и зарабатывать на них не получится, поэтому для бизнеса они не интересны.
Исключительное право на ПО. Если объяснять на примерах (да простят нас ученые-цивилисты), то исключительное право можно сравнить с правом собственности на какой-либо объект, например, квартиру. Я, как владелец квартиры, имею возможность свободно использовать ее по своему усмотрению: продавать («отчуждать исключительное право»), сдавать в аренду («лицензировать»), и вообще делать все, что не запрещено законом. Проще говоря, исключительное право позволяет монетизировать ПО, извлекать из него прибыль. И это именно то, в чем бизнес и заинтересован. Но изначально исключительное право на ПО возникает у автора-разработчика, и чтобы оно перешло в руки работодателя, одной доброй воли разработчика недостаточно.
Нельзя просто так взять и просто так взять
Чтобы исключительное право на ПО перешло от разработчиков, которые его написали, к работодателю, последнему нужно подготовить несколько документов. В ведущих ИТ-компаниях, как правило, оперируют следующими шестью:
Трудовой договор. В нем в списке должностных обязанностей должно быть предусмотрено создание служебных произведений (программного обеспечения), а также размер, порядок начисления и выплаты авторского вознаграждения. Да, закон предусматривает вознаграждение для автора в дополнение к его окладу. Размер такой выплаты может быть любым и, по идее, обсуждаем при заключении ТД. Однако, на практике обычно никто его не обсуждает: разработчики, устраивающиеся по ТД, интересуются больше зарплатой, автоматически соглашаясь на размер авторских, предложенный работодателем.
Должностная инструкция. Такой документ обязательно должен быть для каждой позиции в команде разработки. Если сейчас его у вас нет, хорошо бы его завести. В должностной инструкции обязательно должны быть указаны обязанности, связанные с разработкой ПО (написанием исходного текста), а все разработчики должны быть ознакомлены с документом под роспись.
Положение о служебных произведениях. Называться это положение может как угодно, но по сути это такой корпоративный документ, в котором написано, как разработчики должны получать служебные задания, как создавать служебные произведения (в нашем случае ПО), в каком порядке происходит передача исключительных прав к работодателю. Проще говоря, в этом документе описан весь процесс создания ПО — с момента выдачи задания на его разработку до момента постановки на бухгалтерский баланс.
Служебное задание. Перед тем, как разработчик приступит к написанию какого-то ПО, необходимо поставить ему служебное задание. На практике часто служебные задания оформляются в виде приказов генерального директора о начале работ по созданию программного обеспечения и формировании рабочей группы, которая это ПО создаст. Можно ставить служебные задания и в Jira, и в других системах, а также по электронной почте, ограничений на это в законе нет. Но важно понимать, что порядок постановки служебных заданий должен быть описан в положении о служебных произведениях. То есть, если вы желаете ставить задания в Jira, то зафиксируйте это документально. Можно описать несколько способов постановки служебных заданий.
Приказ о завершении создания служебного произведения и постановке его на бухгалтерский баланс в качестве нематериального актива. Из названия этого документа и так все понятно.
Акт передачи исключительного права на служебное произведение. После того, как все указанные выше документы подготовлены, а программа написана, со всеми авторами-разработчиками (то есть членами рабочей группы) подписываются акты, в которых коротко, но ёмко указано, что всё, что создал работник по служебному заданию, принадлежит работодателю, за что работнику причитается авторское вознаграждение в том размере, который установлен трудовым договором.
Теперь дело за малым: выплатить работнику его авторское вознаграждение, зарегистрировать программу для ЭВМ в Роспатенте и реестре российского ПО (при необходимости) и продавать.
Из описания всех вышеперечисленных документов возникает несколько вполне логичных вопросов.
Что будет, если у вас документов нет?
Если не оформить все обозначенные выше жирных шрифтом документы грамотно и вовремя, разработчик будет иметь право использовать написанный им код для разработки собственных продуктов, передать его другой компании, запретить компании-работодателю его использовать, а также, например, потребовать выплаты лицензионного вознаграждения и компенсации за нарушение его права (на сегодняшний день сумма рассчитывается в пределах от 10 тыс. до 5 млн рублей за каждый факт нарушения). В общем, если что-то с документами не так или они отсутствуют, можно считать, что бизнес сам себе воткнул палку в колесо и рискует потерять то, на чем, собственно, зарабатывает.
Что делать, если ПО уже создано, а документы не оформлены?
В таком случае ситуация печальная, но не безвыходная. Если у компании нет конфликтов с разработчиками, можно попытаться подписать с ними документы хотя бы после окончания разработки (а вообще, чем скорее, тем лучше). Хуже обстоит ситуация, если разработчик уже ушел из компании с конфликтом, отказывается что-то подписывать и на базе разработанного ПО создает свое, подозрительно похожее на ваше. В таком случае необходимо собрать все доказательства того, что разработчик создавал софт по указанию компании: данные из репозитория, информацию о постановке задач в Jira, отчеты о работе, переписку. Это не гарантируют защиту интеллектуальной собственности компании, но есть шанс отвоевать созданное ПО в случае необходимости.
Если разработчик в рабочее время создает свое ПО, которое никак не связано с деятельностью компании, может ли компания претендовать на результаты его работы?
Обходя этическую сторону вопроса, отметим, что даже в том случае если разработчик в рабочее время, используя ресурсы компании, пишет собственные программы, не по заданию работодателя, с точки зрения законодательства все исключительные права будут принадлежать этому разработчику. Компания не сможет каким-либо образом претендовать на результаты его работы.
Можно ли разработчику использовать свои старые наработки, созданные по заданию компании, если он поменял работу?
Если у предыдущего работодателя документы, оформляющие разработку служебных произведений, были подготовлены корректно, то нет, разработчик не может использовать код, написанный по заданию предыдущего работодателя. Однако нужно понимать, что идеи законом не охраняются, а одну и ту же программу можно написать по-разному, разным исходным текстом.
Надеемся, что статья была полезной. Есть очень много вопросов касательно интеллектуальной собственности, которые остались за рамками поста (а некоторые из них остаются пока даже за рамками законодательства). В частности, полезно будет рассмотреть правовые основы использования open source. Если эта тема интересна, подготовим отдельный пост.
