23 Декабря 2019
Как разработчику обезопасить свой продукт: 7 рекомендаций на примере кейса Rambler-Nginx
Источник: dev.by
В московском офисе IT-компании Nginx прошли обыски по уголовному делу. Как стало известно, «Рамблер» заявил претензии в отношении всемирно известного веб-сервера Nginx. Продукт был разработан Игорем Сысоевым, одним из основателей одноименной компании, когда он еще был сотрудником «Рамблера». По мнению «Рамблера», Nginx был создан работником в служебное время, следовательно, права на программу принадлежат интернет-холдингу.
В комментарии dev.by юрист «Алейников и Партнеры» Юлия Сущенко разобрала возникший спор и выделила 7 рекомендаций для разработчиков, как организовывать работу у нанимателя, чтобы обезопасить свой продукт.
— В этом деле, задача «Рамблера» — доказать, что Сысоев создал программу при исполнении своих трудовых обязанностей. Схема защиты от подобных заявлений для сотрудника в Беларуси, и в России схожа. Разберем её.
Чётко определите, что именно входит в вашу должностную инструкцию
Разработкой Nginx Игорь Сысоев действительно занимался, когда работал в «Рамблере». Но само по себе это не делает Nginx служебным произведением.
И в Беларуси, и в России часто работодатели «цепляются» за то, что программа была создана в рабочее время и упорно доказывают это в суде. Но судебная практика подтверждает: «факт рабочего времени» может использоваться только как косвенное доказательство, не более.
Чтобы понять, входила ли разработка веб-сервера в трудовые обязанности Сысоева, обратимся к фактам. Он работал в «Рамблере» системным администратором. Предположим (как правило, так и есть), его должностная инструкция была стандартной. Читаем: «в соответствии с профессиональным стандартом „Системный администратор информационно-коммуникационных систем“ в обязанности системного администратора не входит разработка программного обеспечения».
Если трудовые обязанности совпадают с тем, что вы делаете в своем личном проекте, доказывать в суде, что проект принадлежит вам, будет сложнее. Но есть выход.
Расскажите начальству, что вы занимаетесь своим проектом, и возьмите письменное согласие
Бывший исполнительный директор «Рамблер» готов подтвердить: Сысоев уведомил компанию, что Nginx — его собственный проект, и компания была с этим согласна. Учитывая известные обстоятельства дела, Nginx — не служебное произведение. Права на него принадлежат Сысоеву. Исключение: если существуют факты, которые остались за кадром.
В идеале, когда устраиваетесь на работу, берите у работодателя письменное согласие, в котором тот подтвердит, что:
- ему известно, что у вас есть свой проект;
- он знаком с основными характеристиками этого проекта;
- он согласен с тем, что вы будете им заниматься;
- он признает, что исключительные права на любые объекты авторского права, созданные в процессе работы над проектом принадлежат вам.
В более сложных случаях может понадобиться письменное соглашение между работником и нанимателем.
В Беларуси есть ещё один критерий, по которому произведение можно признать служебным: когда оно создано по заданию нанимателя.
Задание может быть письменным и устным. Если наниматель в споре будет ссылаться на устное задание, он сам должен будет доказать, что оно действительно было. На практике сделать это довольно сложно.
Если задание оформлено письменно, следите за тем, что написано в технических требованиях к программе. Хорошо, если это четкое ТЗ.
Избегайте расплывчатых формулировок вроде «разработка мобильного приложения под операционную систему iOS». В этом случае будет сложно доказать, что под «разработкой» имелась в виду не та программа, которую вы делали для себя.
Убедитесь, что не нарушаете коммерческую тайну компании
Работодатель может зайти с ещё одной стороны: защищать не права на программу, а права на коммерческую тайну.
К коммерческой тайне можно отнести информацию, которая имеет действительную или потенциальную коммерческую ценность, потому что неизвестна третьим лицам. К этой информации у третьих лиц нет свободного доступа на законном основании, и в отношении неё обладатель «ввел режим коммерческой тайны». Идею нового продукта можно отнести к такой информации.
«Рамблер» может сослаться на то, что Сысоев использовал идеи, наработки, алгоритмы компании при работе над Nginx. Эти сведения могли составлять коммерческую тайну «Рамблера». Но, как показывает практика, это сложно доказать.
Чтобы защитить свои идеи в режиме коммерческой тайны, недостаточно просто доказать их неизвестность, ценность и прочее. Важно подтвердить, что компания установила режим коммерческой тайны. Это можно сделать только формально, в документе. Нет документа — работодатель не будет иметь права на защиту конфиденциальной информации.
Итого — рекомендации
- При трудоустройстве берите у работодателя письменное согласие, в котором он подтвердит, что согласен с тем, что вы работаете над чем-то своим и не претендует на продукт;
- Если не успели взять согласие во время работы, попробуйте постфактум, после увольнения. Сохраняйте документы, которые связаны с работой у нанимателя и переписку (их можно будет использовать в последующем);
- Работайте над собственным проектом в нерабочее время («свободный график» — отдельная история);
- Убедитесь, что не нарушаете коммерческую тайну компании;
- При общении с прессой, будьте благоразумны. Пример Сысоева хорош: в СМИ он с самого начала позиционировал продукт как свой. В одном из интервью прямо обозначил, что не считает произведение служебным и объяснил почему;
- Хорошо фиксировать рабочие задачи в отдельных программах (Jira, Slack);
- Заручитесь поддержкой авторитетного лица, который подтвердит вашу информацию (как Ашманов в кейсе Сысоева);
Покупателям при покупке стартапов следует проводить тщательный технический и правовой due diligence. Важно обратить внимание на выявленные по его результатам документы и информацию в отношении ключевого кода / продукта таргета. Они могут иметь существенное значение и для сделки, и для последующего владения компанией / продуктом.
Стартапам необходимо иметь в виду: многие спорные вещи, которые вы не урегулировали между бывшими соавторами или с бывшими работодателями, всё ещё можно исправить, пока стартап готовится к сделке. После того, как вам удастся продать стартап за десятки и сотни миллионов, договориться с «бывшими» станет гораздо сложнее.