Как стать автором
Обновить
145.53

Коммитите в опенсорсе, работая разработчиком? Разбираемся с правами (привет, nginx)

Время на прочтение10 мин
Количество просмотров15K


Ситуация с правами на код в Российской Федерации довольно интересная: по закону разработчик (физлицо) защищён очень и очень сильно. Нужно как-то весьма прилично косякнуть, чтобы оказаться неправым. А вот работодателю нужно довольно много и кропотливо бегать с бубном и бумагами, чтобы получить права на тот самый код, который пишется на его же зарплату.

Давайте рассмотрим, что говорят законы о правах на код с обеих сторон:

  • Когда и какие права возникают у вас (как физлица) на код.
  • Как правильно устроена передача имущественных прав на код работодателю.
  • Тимлид, который делал ревью, — он соавтор или кто?
  • Можно ли коммитить в свой pet-project с рабочего компьютера в рабочее время?
  • Какой геморрой предстоит пройти, чтобы правильно использовать код, если вы его заказали?

И так далее.

Поехали!

— Что такое авторские права на код?


В ГК про авторские права написано в главе 70. Если очень коротко, то код — это программа для ЭВМ. По правовому режиму она приравнивается к произведениям науки, литературы и искусства. Это как если бы вы написали рассказ или особо удачный стих.

Автором такого произведения (программы для ЭВМ) может быть только физлицо. Юрлицо не может ничего написать: всегда есть какой-то человек, который и был автором. Или несколько человек, если код писался вдвоём-втроём-вдесятером. Тогда они называются соавторами.

Авторские права возникают в момент создания произведения. Их не нужно нигде регистрировать или как-то подтверждать (хотя, если хочется, можно потом и зарегистрировать). Реестр прав на ПО, который ведёт Роспатент, решает задачу не возникновения права, а доказательства того, что именно вы обладаете правами на ПО. Данные этого реестра могут рассматриваться в суде в ходе разбирательств о том, кто же правообладатель, но никогда не будут 100 % гарантией вашего успеха.

У авторов (или соавторов, если работал коллектив) возникают личные неимущественные права и имущественные. Личные неимущественные — это право авторства, право на имя, право на неприкосновенность произведения и право на его обнародование. Их нельзя отчуждать никоим образом. Любой договор передачи этих авторских прав будет признан ничтожным по текущему законодательству. Передавать можно только имущественное право на ПО, которое по-другому называется исключительным правом. Кроме того, если вы обладаете исключительным правом или получили разрешение правообладателя, то можно продавать лицензии на ПО.

— Если я передал имущественное (исключительное) право, то как реализуются личные неимущественные?


Предположим, у вас подписаны договор и ещё стопка бумаг (про них — дальше), которые говорят о том, что вы разработали что-то по заданию работодателя, создали произведение — программу для ЭВМ — и сразу же передаёте исключительное право на него. То есть написали код, и теперь им может распоряжаться работодатель. Но при этом у вас сохраняются неимущественные права: вы можете говорить всем, что написали этот код, вы можете добиваться того, чтобы ваше произведение было подписано где-то в программе (хоть в дебрях, но чтобы это можно было увидеть), и вы можете говорить, что если кто-то добавил в ваш прекрасный код свой грязный баг, то это уже не ваш код. Потому что ваш и только ваш он в полностью неизменном прекрасном первозданном виде.

Что происходит, если на базе вашего кода кто-то написал свой новый? Про это — чуть позже.

Важно то, что если вы вдруг захотите передать право на имя, то не сможете этого сделать.

Личные неимущественные права охраняются бессрочно, а исключительное право — 70 лет (плюс время до 1 января следующего года) с момента смерти последнего соавтора. В течение этих 70 лет, когда вы уже мертвы, ваши интересы может защищать любое лицо: оно может обратиться в суд и сказать, что ваши права нарушены. Тогда злоумышленника накажут.

— Означает ли это, что можно использовать код в портфолио?


Нет, если у вас нет исключительного права на код или лицензии на такое использование, то вы можете только говорить публично, что написали его, но не демонстрировать сам этот код.

— Можно ли использовать код без указания имени автора?


Да. Право на имя означает, что автор может потребовать указания авторства и требует этого по умолчанию. Но в принципе вы можете разрешить не подписывать ваш код. На практике это часто происходит при передаче кода работодателю, при передаче фотографий в различные издания и так далее.

— Кто такие соавторы? Мой тимлид — соавтор?


Автором считается только тот человек, который собственноручно писал код. Если кто-то помогал созданию произведения, но не писал, — это не автор. Только техническое, консультационное, материальное, организационное содействие никак не помогает этим содействующим стать авторами произведения. То есть если вам дали материалы для написания кода (не другой код, а, например, среду разработки, ноутбук, стул и стол), если вас консультировали по коду или ставили задачи (даже очень подробно), но ничего в нём не меняли, — автор всё равно только вы. Это имеет прямое отношение к ревью: если вы отдали свой код на ревью тимлиду, а он только объяснил вам, где вы глубоко неправы, то он не автор. Но если он начал вносить изменения в код, то он становится соавтором. И степень вашего с ним участия с правовой точки зрения становится условно одинаковой: считается, что законченное произведение не могло бы появиться без усилий каждого из вас, даже если объём работ был сильно разный. Правда, такое правило действует только по умолчанию. Так что, если вам такая уравниловка не нравится, вы можете заключить соглашение с соавторами об ином.

При этом важно понимать, что о соавторстве можно говорить только в том случае, когда несколько человек пишут одну и ту же версию одной и той же программы. Если же кто-то изменяет готовое ПО, уже написанное вами ранее, то вы не становитесь соавторами, потому что вы авторы двух разных программ (подробнее об этом — ниже).

Кстати, если код для вас написал не человек, а ИИ, у вас могут возникнуть проблемы с признанием вообще каких бы то ни было прав на такой код. Наше государство (да и не только наше) пока однозначно не решило, как относиться к генерируемым кодам. Будем надеяться, что в ближайшем будущем ситуация прояснится.

— Как квантуется код? Если каждый писал отдельную функцию, а потом получилось большое приложение, то мы авторы отдельных произведений или одного общего?


Здесь всё зависит от того, что будет признано произведением: всё вместе будет считаться единым произведением или же отдельные части будут признаны разным ПО. На практике это зависит от многих вещей, в том числе от задачи, которую ставит работодатель. Чаще всего речь идёт про целостное произведение, то есть все разработчики первой версии в конечном итоге окажутся соавторами. Но надо учитывать, что даже в таком случае один из соавторов может использовать написанную лично им часть по своему усмотрению, если эта часть имеет самостоятельное значение.

Со следующими версиями ПО ситуация чуть интереснее.

— Что происходит, если на базе моего кода кто-то написал свой новый?


Есть смежные права, это когда великий композитор Иоганн Себастьян Бах написал музыку, а Иван Пупкин её исполнил в гараже на шампурах и крышке от кастрюли. В этом случае физлицо Бах имеет право на музыку, а физлицо Иван — на смежное произведение, то есть чужую музыку в своём уникальном авторском исполнении на шампурах и крышке. Но, как вы понимаете, нашего FAQ это не особо касается, потому что мы обсуждаем именно изменения ПО.

Если в ваш код вносятся какие-то изменения другим разработчиком — получается производное произведение. Чтобы создавать производное произведение, надо иметь исключительное право на то произведение, которое лежит в основе, или получить право на переработку первоначального произведения, купив соответствующую лицензию. Свободно перерабатывать можно также ПО, находящееся в общественном достоянии.

После внесения изменений произведений становится два: старое и только что созданное новое — производное — произведение. Это создаёт одну интересную особенность охраны прав разработчиков, про которую мы поговорим ниже.

— Кто такой правообладатель?


Правообладатель — это тот, у кого есть исключительное право. Если автором может быть только физлицо, то правообладателем может быть кто угодно: физлицо, юрлицо, субъект Федерации или вообще страна.

Исключительное право на программу для ЭВМ — это возможность использовать ПО и код на него любым способом, который только можно представить.

Иногда правообладателем также называют того, кто использует произведение по лицензии, но с точки зрения ГК термин «правообладатель» относится только к владельцу исключительных прав.

Вы можете заключить с правообладателем лицензионный договор, чтобы получить возможность использовать произведение какими-то определёнными способами в каком-то регионе и на какой-то срок.

— Означает ли наличие трудового договора то, что весь мой код принадлежит работодателю?


Нет, одного трудового договора недостаточно. В трудовых отношениях работодателю для появления у него исключительного права нужно доказать, что работник создал произведение в рамках выполнения своей трудовой функции.

И дальше начинается цепочка из документов, которые надо оформлять для правильной передачи исключительного права работодателю. Но даже если пройти её до конца и обложиться бумагами по всем правилам, то это не гарантирует на все 100 % того, что суд встанет на сторону работодателя. Равно как нет безусловной гарантии, что если вообще ничего не делать, то суд встанет на сторону работника. Вопрос правильного оформления — это вопрос снижения рисков. Скажем так, по моей оценке, можно на 99 % быть уверенными в том, что всё будет в порядке, если сделать всё до конца.

Но наличие в трудовом договоре фразы, что «исключительное право на служебные произведения возникает у работодателя», пока ещё ничего вообще не даёт работодателю.

— Если есть трудовой договор, где указана должность — программист?


Уже чуть больше шансов, но они всё ещё низки, потому что не указано, что именно вы делаете. Возможно, вас нанимали писать код для АСУ ТП, а вы написали код для управления видеокамерой в кабинете секретарши шефа. Если вам такая задача прямо не ставилась работодателем, то это было хобби, а не рабочая деятельность.

— ОК, а трудового договора с должностью плюс должностных обязанностей?


Нет, потому что там не указано, какой именно код и по какому ТЗ вы должны писать. Например, если вы админ и написали код для какой-то автоматизации, то это вообще не значит, что вы должны были это делать: с точки зрения закона это как принести собранный собственноручно дома прибор и использовать его на работе. Очень упрощая, конечно.

— А что тогда нужно?


  1. Трудовой договор с указанием должности.
  2. Должностная инструкция с указанием того, что вы среди всего прочего должны создавать служебные произведения — программы для ЭВМ.
  3. Служебное задание на то, чтобы создать какое-то произведение. Это самое настоящее ТЗ (подробное или не очень, но с критериями, что вы должны делать), по которому можно понять, что вы делали именно то, что нужно было работодателю. В служебном задании должны быть ФИО работника, фраза про «создать ПО с такими-то функциями», сами эти функции и другие требования к ПО, рабочее название (если есть), срок создания, фраза про «результат передать работодателю», дата.
  4. Отчёт о выполнении задания. Отчёт пишется так: создал в соответствии со служебным заданием таким-то произведение с такими-то функциями, срок создания.
  5. Акт приёма-передачи, когда вы взяли своё служебное произведение и передали его юрлицу по этому самому служебному заданию. В идеальном мире к акту должна быть приложена распечатка кода и тоже заверена подписями.
  6. Неплохо было бы также принять в компании какой-нибудь регламент, в котором будет подробно расписана вся эта цепочка.

Чем больше пунктов выполняет работодатель, тем больше шансов, что в суде программа для ЭВМ будет признана принадлежащей ему.

— И что, всё время носиться с бумагами?


Да. Мы, например, носимся. И вам рекомендуем как минимум для первых версий.

— Почему для первых версий?


Потому что я обещал одну интересную особенность производных произведений. Помните, что любое (ну или почти любое) изменение кода порождает новый объект — производное произведение? А помните, что для этого нужно иметь имущественное право или лицензию с правом переработки на исходное ПО? Ну так вот, если работник допилил или использовал в своей программе какой-то код, а потом у него возникли трения с работодателем, то уже работнику придётся доказывать, что он имел право модифицировать исходное произведение. Если первый раз все бумаги были правильно оформлены, то есть не особо много шансов, что за ним признают право беспрепятственно использовать все следующие версии.

То есть если компания пять лет делает одну и ту же программу, то нужно на каждое изменение (а это мельче релиза и мельче спринта) делать набор бумаг с актами приёма-передачи и вот этим вот всем. Независимо от того, пошла фича в релиз или нет. Но иногда этим после появления первого законченного произведения не заморачиваются, потому что в суде разработчику нужно будет объяснить, что он не украл изначальный код.

— Если это не трудовой договор, а договор ГПХ?


Договор ГПХ — это гражданско-правовой договор. Как правило, речь идёт о договоре подряда и договоре авторского заказа (два в одном). Если ваш подрядчик не «физик», а организация, то будет применяться статья не о договоре авторского заказа, а о произведении, созданном по заказу. Почти то же самое, но есть нюансы. Когда вы заказываете произведение у фрилансера или подрядчика, нужно подписывать аналогичный набор документов. Правда, у некоторых будут немного другие названия: ГПХ вместо трудового договора, ТЗ вместо служебного задания. Должностная инструкция, понятно, не нужна вообще, отчёт — тоже. Как и с трудовым: нет 100 % гарантии, что суд встанет на чью-то сторону однозначно, так как всегда могут быть какие-то подводные камни. Но вы можете снизить ваши риски практически до нуля.

С получением прав от подрядчика есть ещё один важный момент: вам нужно убедиться, что подрядчик сам получил права у своих работников. То есть в идеале надо запросить весь набор документов из списка выше. Вполне вероятно, что вам его просто так не представят, поэтому не помешает прописать соответствующую обязанность подрядчика в договоре при заключении.

Если подрядчик не оформил переход прав от работников себе, то он не может передавать эти права вам (поскольку они у него и не возникали). Вы можете дальше судиться с ним за убытки, но права на код вы не получите. Вскрыться это может в любой момент при жизни разработчика и ещё 70 с небольшим лет.

— Если я с 10:00 до 18:00 работаю в компании, а дома пишу опенсорс-проект, то где какие права?


Всё то, что не относится к служебному заданию, — ваше. Напомню, по закону разработчику почти не нужно доказывать свои права на произведение, наоборот, это работодателю нужно доказывать правильную передачу прав от работника. В описанной ситуации, скорее всего, как-то оформлены права на служебные произведения, поэтому на работе вы делаете код под передачу имущественных прав работодателю, а дома — свой собственный.

— Если я делаю это на рабочем компьютере?


В большинстве случаев абсолютно неважно, что и где вы делали. Можно коммитить в опенсорсе в рабочее время с рабочего компьютера, можно писать свои проекты. Поскольку вам не ставил такую задачу работодатель, вопросы к правам на код не возникнут. Возникнут вопросы, чем вы занимаетесь в рабочее время. Но отлынивание от служебных обязанностей (а это именно оно) никак не создаёт права на то, что во время этого отлынивания было произведено.

Ещё я слышал про такой юридический лайфхак: работодатели прописывают, что сохранение кода на рабочей станции, являющейся имуществом работодателя, приравнивается к акцепту передачи прав на этот код. Но, по-моему, его действенность вызывает вопросы.

— Если я передал исключительные имущественные права в общественное пользование, то я могу создавать производное произведение?


Да, вы точно можете. Хотя возможность свободной передачи своего ПО в public domain по российскому законодательству как минимум небесспорна.

— Так, у меня ещё вопросы…


Задавайте вопросы в комментариях или по почте earkhipov@croc.ru.

Отдельно отмечу, что мы часто видим «жертв цифровизации», которым подрядчики неверно передают код. Вот в посте моего коллеги есть несколько жизненных примеров, какого размера может быть ущерб.
Теги:
Хабы:
Всего голосов 65: ↑65 и ↓0+65
Комментарии78

Публикации

Информация

Сайт
croc.ru
Дата регистрации
Дата основания
Численность
1 001–5 000 человек
Местоположение
Россия