Вероятно существует очень много способов фиксации факта разработки ПО, но лично мне наиболее правильным кажется:
А. Четкая регламентация процесса разработки. Например, задачи ставятся в Jira, разработка кода ведется в VS Code, репозиторий в GitLab, коммиты ежедневно со ссылкой на задачу, мерджи - по приказу с фиксацией цифрового отпечатка коммита.
Б. Необходимо разработать стандартную шапку файлов исходного кода/watermark исходников графики и т.д., а в процессе вливания результатов в основную ветку - проверять наличие/корректность шапки. Как уже упоминалось выше, разработчик, который будет обрабатывать pull/merge request'ы - не является соавтором, поэтому он должен быть более мотивировам контролировать эти моменты.
В. Документировать факт существования кода со штампом в любой момент времении. По-видимому, самый правильный способ - это документирование commit hash (или кастумный механизм контрольной суммы) в виде печатного/электронного приказа и ознакомление с ним работника под подпись. Нет смысла это делать под каждый коммит, но на уровне минорных релизов - вполне стоит. Этот hash гарантирует существование кода в таком виде, а также кто именно и когда его отправил. Подделать содержание и всю цепочку зафиксированного в момент времени хэша невозможно, и любой эксперт, привлеченный в суд, подтвердит факт существования контента со всеми метаданными.
Г. Выплачивать справедливое авторское вознаграждение за совершенно конкретный объем переданной интеллектуальной собственности (это может быть как 100 р. за строку кода, так и что-то типа "Один оклад за версию, зафиксированную приказом (упомянутым выше)"). Это будет еще один аргумент для суда - работник не просто сделал все вышеперечисленное, но еще и принимал каждый месяц в расчетном листке сумму за осязаемый объем выполненной работы. Ведь не сильно добросовестный работник может заявить: "Коммиты за меня делал мой работодатель под моей учеткой, а на самом деле это мой код, который я разработал на компьютере для себя". Но тут уже к вопросу о фальсификации.
Д. Ну и самое экзотическое - можно всячески поощрять участие работников в конференциях, написание статей про проект от имени работодателя. Так не возникнет никаких сомнений, что работник занимался этим проектом в рамках своих обязанностей и понимал это.
При этом обеим сторонам не будет лишним учитывать подпункт 3 пункта 3 статьи 1280 ГК РФ. Если работник разработал код для работодателя, решив сложные алгоритмические задачи (а алгоритмы - не объект авторского права согласно 1259 ГК РФ, тут только в патентное право уходить), а потом сделал свое такое же - то хоть это и не прямо указано в ГК, но может вполне стать основанием для спора.
Что стоит делать:
1. Необходим трудовой договор, в котором четко указан должность (все эти пункты, что работодателю принадлежит все, что сделал работник - в части объектов авторских прав - просто пшик) и, главное, должностная инструкция, в которой подробно описано все важное: принимает участие в построении архитектуры приложения, разрабатывает прототипы и наброски, пишет программный код, включая сопутствующие библиотеки, участвует/рисует графику, разрабатывает документацию, маркетинговые материалы и т.п. Ингридиенты и степень подробности можно варьировать по вкусу.
Это очень важно, потому что, как правильно сказали выше, если человека наняли писать обработчики событий в IoT, а потом заставили писать dapp'ы - это не совсем этично (хотя при достаточно абстрактной ДИ - вполне возможно).
2. Нужно управлять разработкой. Не "А сделайте хорошо", а идти по всем этапам разработки ПО, чтобы в случае суда можно было рассказать всю историю и показать, что какой-то конкретный фрагмент кода возник не просто так, а потому что он часть продукта компании. А если вдруг работник что-то разработал вне рамок основного продукта, на который его нанимали, (см. выше про dapp'ы), то при условии соблюдения пункта 1 все может стать очень сложно.
3. Необходимо фиксировать результат разработки, при этом где именно это сделано - не имеет особого значения. Конечно, доверия к локально развернутому репозиторию, который можно попробовать подредактировать, или к MS Exchange, где можно нахимичить с письмами - не очень много. Но подделка доказательств - это очень серьезное преступление, да и обвинение другой стороны в подделке может подвести под статью. Поэтому только совсем отчаянные представители, либо наличие серьезных доказательств подделки - могут подтолкнуть к оспариванию настоящих доказательств.
Поделюсь своим скромным опытом:
1. Чтобы произведение было служебным, обязанности по программированию должны быть в трудовом договоре и должностной инструкции. Точка. Никакие договоренности, служебные задания и прочие активности (за исключением, конечно, самостоятельного договора авторского заказа), не включенные в ТД и ДИ - не являются основанием для признания произведения служебным. Мое дело дошло до ВС и, казалось бы, в иске отказали. Но в определении апелляции, несмотря на заблуждение суда по целому ряду моментов, было четко указано, что произведение служебным не является.
2. Сам факт того, что работник делал что-то на оборудовании работодателя и в рабочее время, возможно даже в ущерб должностным обязанностям - ничего не говорит о служебности. Работодатель может наказать рублем и трудоустройство, может взыскать ущерб и попытаться пойти дальше в эту сторону, но исключительные права в порядке 1295 он точно не приобретет.
3. Доказывать факт служебности произведения должен именно работодатель. Даже если работодатель принесет коммиты с хэшем (напишу далее) и акты приемки-передачи, то именно работодатель должен обосновать природу этого кода.
Первые 3 пункта подтверждаются пунктом 104 этого документа: http://www.consultant.ru/document/cons_doc_LAW_323470/ee07ed989eace60044215bd4b9b812f99a2f6919/ .
4. При этом при соблюдении пункта 1 отсутствие авторских выплат, само по себе, не является основанием для отказа в признании служебности произведения. Это - нарушение, которое может быть оспорено в суде и суд заставит работодателя заплатить, но если работник должен был создать произведение в рамках должностных обязанностей - это принадлежит работодателю.
* продолжение в комментариях к этой записи
Стоит отметить, что, отказывая в иске по совершенно надуманным основаниям и, как Вы верно сказали, запутавшись в свободных лицензиях и использовании облачных провайдеров (а может просто не захотели, чтобы физлицу досталась компенсация), - произведение служебным не признали.
Судья первой инстанции довольно четко опровергла все "аргументы" - от попытки переврать факты о том, что "бОльшая часть кода разрабатывалсь в рабочее время" (они ссылались на дату создания и изменения файлов с исходниками, еще и перекосив это самоее "бОльшее"), приводили различные переписки с сотрудниками по поводу разработки контента (выставляя их разработкой самой платформы - даже судья указала, что это не так), даже притащили аффидевит и полуаффидевит (чей - сказать не могу, потому что дело рассматривалось в закрытом режиме), в котором рассуждалось о том, как я хорошо работал, но ни слова о том, что у меня были такие обязанности.
И в конце концов - в решении было написано, что по вопросу служебного произведения позиция ответчика была противоречивой и постоянно менялась.
Венцом позиции представителя работодателя было заявление в апелляционном суде (цитата по памяти, все никак не заставлю себя переслушать запись и найти): "Да, у него в обязанностях программирования не было. Но мы же не знаем, чем будет человек заниматься, когда его нанимаем!".
Отдельным ответом напишу об извлеченном уроке по служебности произведения.
ИМХО, довольно просто:
1. Как только это что-то, выраженное на любом языке программирования (статья 1261 ГК РФ) - пусть даже батник или какой-то метаязык (даже древний Лого) - это объект авторского права и он защищается
2. Если идея оформлена в виде статьи, а кто-то возьмет и опубликует ее у себя на сайте в чистом или слегка измененном виде, да еще и без ссылки (хотя описание идеи вряд ли подпадает под исключения об использовании без согласия автора) - это нарушение. Но в данном случае защищается не сама идея, а ее литературная форма.
Интересный кейс был с очень известным американским фокусником Теллером (он еще известен как отец Эми в Теории большого взрыва). Фокусы не защищаются авторским правом, но он зарегистрировал сценарную постановку, и когда другой фокусник не просто разгадал секрет, а повторил весь сюжет - Теллер его и засудил.
Но если кто-то прочтет эту статью и реализует алгоритм полностью по-своему, то предъявить ему будет нечего.
3. Еще можно защитить реализацию конкретных интерфейсов, поскольку они являются порождаемыми аудиовизуальными материалами и входят в состав программы для ЭВМ (статья 1261). Даже набросок UI, если он сделан достаточно детально, можно попытаться использовать (попытаться - потому что в спорной ситуации степень сходства наброска и реализации будет решать суд или привлеченный им эксперт).
Ну и наконец, можно попробовать запатентовать программу. В чистом виде программы для ЭВМ не патентуются, но если придумать какое-то техническое решение, частью которого будет программа - тогда возможности есть.
Спасибо :) я попытался дополнить один важный аспект, который теперь нужно обязательно учитывать
+ начать использовать в течение 3 лет, иначе все вернется работнику :-)
И обязательно прописанные обязанности по программированию в должностной инструкции, иначе сам факт служебных заданий на разработку библиотеки кода у, например, шеф-повара не означает создания служебного произведения. А то потом адвокаты работодателя будут кричать в суде: "когда мы человека на работу берем, мы же не знаем, чем он заниматься будет" :)
Достаточно использовать трекер/репозиторий (Jira/Git), прописать внутренние правила, что трекер - это официальное средство постановки служебных заданий, а репозиторий - это официальное хранилище и источник кода для продукта, раз в период делать резервные копии и каким-либо образом фиксировать SHA-256 хэш этого архива - по сути самый простой вариант цифрового отпечатка (подписывать протокол с командой разработки, заверять у нотариуса, загружать в Archive.org и т.п.) - тогда в любой момент времени можно показать динамику развития, если возникнет спорный вопрос. Никаких особенных затрат не будет, ведь эти продукты и так используются.
Anton Mamichev
Реализовать алгоритм в виде программного кода можно множеством различных способов. Т.е., если я придумал алгоритм и реализовал его работодателю одним способом (в рамках ДИ), а потом пришел домой и написал свой код совершенно другим способом, для другой платформы и (но не обязательно) на другом языке - то это будут два объекта авторского права.
В пп.3 п.3 ст.1280 интересен следующий фрагмент: "информация, полученная в результате декомпилирования, <...> не может использоваться для разработки программы для ЭВМ, по своему виду существенно схожей с декомпилируемой программой для ЭВМ<...>".
"По своему виду" звучит довольно двусмысленно, но видимо имеется в виду, что если я получил доступ к одному исходному коду, изучил его (в статье разрешается цель интеграции), а потом сделал свою, в которой есть существенные пересечения - то это незаконно.
Аналогию вижу в том, что если штатный программист написал библиотеку, которая в явном виде не видна в продукте (например, компилируется в машинный код или работает на бэкенде для веб-приложений), но реализует важную часть, то программист не может взять ее в чистом или очень приближенном виде.
Именно поэтому, кстати, при желании пересоздать какой-то продукт, который был официально признан служебным, нужно описать его в виде идей и, возможно, непатентованных алгоритмов, а затем нанять программистов, которые никогда не видели оригинального исходного кода. Хорошо описано в сериале "Halt and Catch Fire" - про создание Compaq.