«Этот код написал я — заплатите мне 10 млн!» Почему ваш сотрудник может выиграть спор по авторским правам
Расскажем о типичной ситуации, с которой к нам в патентное бюро Checkmate недавно обратился клиент. Почему типичная? Потому что может задеть каждую IT-компанию и любую другую студию, где генерируют объекты интеллектуальной собственности (название, логотип, прогр…
77 показов
2.2K2.2K открытий
Поделюсь своим скромным опытом:
1. Чтобы произведение было служебным, обязанности по программированию должны быть в трудовом договоре и должностной инструкции. Точка. Никакие договоренности, служебные задания и прочие активности (за исключением, конечно, самостоятельного договора авторского заказа), не включенные в ТД и ДИ - не являются основанием для признания произведения служебным. Мое дело дошло до ВС и, казалось бы, в иске отказали. Но в определении апелляции, несмотря на заблуждение суда по целому ряду моментов, было четко указано, что произведение служебным не является.
2. Сам факт того, что работник делал что-то на оборудовании работодателя и в рабочее время, возможно даже в ущерб должностным обязанностям - ничего не говорит о служебности. Работодатель может наказать рублем и трудоустройство, может взыскать ущерб и попытаться пойти дальше в эту сторону, но исключительные права в порядке 1295 он точно не приобретет.
3. Доказывать факт служебности произведения должен именно работодатель. Даже если работодатель принесет коммиты с хэшем (напишу далее) и акты приемки-передачи, то именно работодатель должен обосновать природу этого кода.
Первые 3 пункта подтверждаются пунктом 104 этого документа: http://www.consultant.ru/document/cons_doc_LAW_323470/ee07ed989eace60044215bd4b9b812f99a2f6919/ .
4. При этом при соблюдении пункта 1 отсутствие авторских выплат, само по себе, не является основанием для отказа в признании служебности произведения. Это - нарушение, которое может быть оспорено в суде и суд заставит работодателя заплатить, но если работник должен был создать произведение в рамках должностных обязанностей - это принадлежит работодателю.
* продолжение в комментариях к этой записи
Что стоит делать:
1. Необходим трудовой договор, в котором четко указан должность (все эти пункты, что работодателю принадлежит все, что сделал работник - в части объектов авторских прав - просто пшик) и, главное, должностная инструкция, в которой подробно описано все важное: принимает участие в построении архитектуры приложения, разрабатывает прототипы и наброски, пишет программный код, включая сопутствующие библиотеки, участвует/рисует графику, разрабатывает документацию, маркетинговые материалы и т.п. Ингридиенты и степень подробности можно варьировать по вкусу.
Это очень важно, потому что, как правильно сказали выше, если человека наняли писать обработчики событий в IoT, а потом заставили писать dapp'ы - это не совсем этично (хотя при достаточно абстрактной ДИ - вполне возможно).
2. Нужно управлять разработкой. Не "А сделайте хорошо", а идти по всем этапам разработки ПО, чтобы в случае суда можно было рассказать всю историю и показать, что какой-то конкретный фрагмент кода возник не просто так, а потому что он часть продукта компании. А если вдруг работник что-то разработал вне рамок основного продукта, на который его нанимали, (см. выше про dapp'ы), то при условии соблюдения пункта 1 все может стать очень сложно.
3. Необходимо фиксировать результат разработки, при этом где именно это сделано - не имеет особого значения. Конечно, доверия к локально развернутому репозиторию, который можно попробовать подредактировать, или к MS Exchange, где можно нахимичить с письмами - не очень много. Но подделка доказательств - это очень серьезное преступление, да и обвинение другой стороны в подделке может подвести под статью. Поэтому только совсем отчаянные представители, либо наличие серьезных доказательств подделки - могут подтолкнуть к оспариванию настоящих доказательств.
Вероятно существует очень много способов фиксации факта разработки ПО, но лично мне наиболее правильным кажется:
А. Четкая регламентация процесса разработки. Например, задачи ставятся в Jira, разработка кода ведется в VS Code, репозиторий в GitLab, коммиты ежедневно со ссылкой на задачу, мерджи - по приказу с фиксацией цифрового отпечатка коммита.
Б. Необходимо разработать стандартную шапку файлов исходного кода/watermark исходников графики и т.д., а в процессе вливания результатов в основную ветку - проверять наличие/корректность шапки. Как уже упоминалось выше, разработчик, который будет обрабатывать pull/merge request'ы - не является соавтором, поэтому он должен быть более мотивировам контролировать эти моменты.
В. Документировать факт существования кода со штампом в любой момент времении. По-видимому, самый правильный способ - это документирование commit hash (или кастумный механизм контрольной суммы) в виде печатного/электронного приказа и ознакомление с ним работника под подпись. Нет смысла это делать под каждый коммит, но на уровне минорных релизов - вполне стоит. Этот hash гарантирует существование кода в таком виде, а также кто именно и когда его отправил. Подделать содержание и всю цепочку зафиксированного в момент времени хэша невозможно, и любой эксперт, привлеченный в суд, подтвердит факт существования контента со всеми метаданными.
Г. Выплачивать справедливое авторское вознаграждение за совершенно конкретный объем переданной интеллектуальной собственности (это может быть как 100 р. за строку кода, так и что-то типа "Один оклад за версию, зафиксированную приказом (упомянутым выше)"). Это будет еще один аргумент для суда - работник не просто сделал все вышеперечисленное, но еще и принимал каждый месяц в расчетном листке сумму за осязаемый объем выполненной работы. Ведь не сильно добросовестный работник может заявить: "Коммиты за меня делал мой работодатель под моей учеткой, а на самом деле это мой код, который я разработал на компьютере для себя". Но тут уже к вопросу о фальсификации.
Д. Ну и самое экзотическое - можно всячески поощрять участие работников в конференциях, написание статей про проект от имени работодателя. Так не возникнет никаких сомнений, что работник занимался этим проектом в рамках своих обязанностей и понимал это.
При этом обеим сторонам не будет лишним учитывать подпункт 3 пункта 3 статьи 1280 ГК РФ. Если работник разработал код для работодателя, решив сложные алгоритмические задачи (а алгоритмы - не объект авторского права согласно 1259 ГК РФ, тут только в патентное право уходить), а потом сделал свое такое же - то хоть это и не прямо указано в ГК, но может вполне стать основанием для спора.