Некоторые комментарии по приходящим вопросам о правах разработчиков на разработки.
Всё, что сотрудник в рамках своей работы делает — принадлежит тому, кто эту работу заказал.
(даже необязательно оплатил, но обязательно заказал)
В принципе, возможны и даже прямо допускаются ситуации, когда заказчик отказывается от результата работы в пользу работника, но это должно оформляться отдельными документами, и на практике практически никогда не встречается.
Так как в IT-отрасли результаты работы, у заказчика-работодателя не остаются, а передаются дальше по цепочке партнёрам, и т.д. — вплоть до конечного покупателя-потребителя, необходимо по всей этой цепочке передавать и права на результаты работы самого первого разработчика.
Делается это достаточно просто, — при приёме на работу (в штат), или при заказе работы (по договору), с работником заключается обычный стандартный пакет соглашений (NDA, распорядок, неконкуренция и т.д.), в который (пакет) — входит и «соглашение о служебной разработке».
По этому соглашению, всё, что работник будет разрабатывать, с момента создания — находится в собственности компании-заказчика.
Заключается это соглашение или до, или одновременно с самим договором на разработку.
При найме на работу в любую более-менее серьёзную компанию, все эти соглашения подписываются одним пакетом.
При самостоятельном найме разработчиков (что критически важно для начинающих технологических стартапов), образцы таких соглашений — можно найти в сети, и без особых затруднений самостоятельно адаптировать под конкретную ситуацию.
Единственное, — существует (всего два, правда очень важных) исключения/дополнения этого стандартного правила.
Первое состоит в том, что в случае, если разработка настолько ценна, и критична, что подлежит патентованию, тем более международному, именно на ту часть всей разработки, которая будет патентоваться — надо делать отдельное соглашение, с обязательным указанием факта выкупа заказчиком всех прав на конкретное патентуемое решение.
(цена выкупа значения не имеет, это может быть хоть $1, но этот $1 должен быть оформлен и обязательно выплачен)
Второе состоит в том, что в случае, если важная и критичная часть разработки, подлежит патентованию, и впоследствии будет играть в бизнесе важную роль, а разработчик (один или несколько) — не являются для владельца бизнеса «своими» (например разработчики в стартапе, которых не предполагается в дальнейшем делать совладельцами (например с помощью бонусов)), то в таких случаях применяют более радикальное решение возможных в будущем проблем.
Для этого на каждую конкретную часть и даже шаг разработки (результаты которых потом будут патентоваться и лицензироваться) предварительно оформляют конкретные технические задания на разработку, например в виде служебных записок и приказов.
В этом случае, авторами запатентованных решений будут не непосредственные разработчики, а те лица, которые выдали эти задания.
ПРИМЕР:
Программеру стартапа Иванову сказали сваять утилиту опроса портов, потом стартап (вместе со всеми разработками) был продан сначала первому покупателю, потом второму, и в конце концов, через три года — крупной компании — «микрософту».
Иванов в стартапе проработал всего месяц, но через три года узнав про продажу микрософту,
он может потребовать авторства на патент по способу работы этой утилиты, что повлечёт его авторство во всех последующих международных патентах, и головную боль у микрософта.
Если же основатели стартапа исходно строят его для последующей, через три года продажи, то они не только оформляют Иванова на служебную разработку (см.выше), но и предварительно обговорив с ним задание на ваяние утилиты, и способ её работы, выдадут ему пусть совсем короткое (на четверть листа но письменное) служебное задание, например за подписью технического директора-сооснователя, тогда автором в патенте — будет технический директор, и сложностей с правами на разработку, и авторство по патенту — не возникнет изначально.
PS. Как всегда напоминаем, что все вопросы — только по обычной почте.
Всё, что сотрудник в рамках своей работы делает — принадлежит тому, кто эту работу заказал.
(даже необязательно оплатил, но обязательно заказал)
В принципе, возможны и даже прямо допускаются ситуации, когда заказчик отказывается от результата работы в пользу работника, но это должно оформляться отдельными документами, и на практике практически никогда не встречается.
Так как в IT-отрасли результаты работы, у заказчика-работодателя не остаются, а передаются дальше по цепочке партнёрам, и т.д. — вплоть до конечного покупателя-потребителя, необходимо по всей этой цепочке передавать и права на результаты работы самого первого разработчика.
Делается это достаточно просто, — при приёме на работу (в штат), или при заказе работы (по договору), с работником заключается обычный стандартный пакет соглашений (NDA, распорядок, неконкуренция и т.д.), в который (пакет) — входит и «соглашение о служебной разработке».
По этому соглашению, всё, что работник будет разрабатывать, с момента создания — находится в собственности компании-заказчика.
Заключается это соглашение или до, или одновременно с самим договором на разработку.
При найме на работу в любую более-менее серьёзную компанию, все эти соглашения подписываются одним пакетом.
При самостоятельном найме разработчиков (что критически важно для начинающих технологических стартапов), образцы таких соглашений — можно найти в сети, и без особых затруднений самостоятельно адаптировать под конкретную ситуацию.
Единственное, — существует (всего два, правда очень важных) исключения/дополнения этого стандартного правила.
Первое состоит в том, что в случае, если разработка настолько ценна, и критична, что подлежит патентованию, тем более международному, именно на ту часть всей разработки, которая будет патентоваться — надо делать отдельное соглашение, с обязательным указанием факта выкупа заказчиком всех прав на конкретное патентуемое решение.
(цена выкупа значения не имеет, это может быть хоть $1, но этот $1 должен быть оформлен и обязательно выплачен)
Второе состоит в том, что в случае, если важная и критичная часть разработки, подлежит патентованию, и впоследствии будет играть в бизнесе важную роль, а разработчик (один или несколько) — не являются для владельца бизнеса «своими» (например разработчики в стартапе, которых не предполагается в дальнейшем делать совладельцами (например с помощью бонусов)), то в таких случаях применяют более радикальное решение возможных в будущем проблем.
Для этого на каждую конкретную часть и даже шаг разработки (результаты которых потом будут патентоваться и лицензироваться) предварительно оформляют конкретные технические задания на разработку, например в виде служебных записок и приказов.
В этом случае, авторами запатентованных решений будут не непосредственные разработчики, а те лица, которые выдали эти задания.
ПРИМЕР:
Программеру стартапа Иванову сказали сваять утилиту опроса портов, потом стартап (вместе со всеми разработками) был продан сначала первому покупателю, потом второму, и в конце концов, через три года — крупной компании — «микрософту».
Иванов в стартапе проработал всего месяц, но через три года узнав про продажу микрософту,
он может потребовать авторства на патент по способу работы этой утилиты, что повлечёт его авторство во всех последующих международных патентах, и головную боль у микрософта.
Если же основатели стартапа исходно строят его для последующей, через три года продажи, то они не только оформляют Иванова на служебную разработку (см.выше), но и предварительно обговорив с ним задание на ваяние утилиты, и способ её работы, выдадут ему пусть совсем короткое (на четверть листа но письменное) служебное задание, например за подписью технического директора-сооснователя, тогда автором в патенте — будет технический директор, и сложностей с правами на разработку, и авторство по патенту — не возникнет изначально.
PS. Как всегда напоминаем, что все вопросы — только по обычной почте.