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