Чтобы не вышло, как с «Рамблером». 7 советов для разработчиков

Защита авторских прав на программы

«Рамблер» пытается получить права на самый популярный веб-сервер в мире — Nginx. Продукт создал бывший сисадмин «Рамблера» Игорь Сысоев, пока работал в компании. Восемь лет у компании не было к бывшему сотруднику претензий. До тех пор, пока американская компания F5 Networks не купила Nginx за 670 миллионов долларов. В офисе Nginx уже прошли обыски. Из-за спора заведено уголовное дело. DEV.BY узнал, как сделать так, чтобы с вами не вышло, как с «Рамблером» — 7 пунктов составила Юлия Сущенко, юрист юридической фирмы «Алейников и Партнеры».

​Что известно по делу:

  • Игорь Сысоев работал в «Рамблере» системным администратором с 2000 по 2011 год.
  • Разработка Nginx была начата в 2000 году,
  • Игорь Ашманов, который в начале нулевых занимал пост исполнительного директора «Рамблер», сообщил, что когда Сысоева принимали на работу, было оговорено, что у него есть свой проект, и он имеет право им заниматься. Ашманов уже предложил Сысоеву помощь по делу Nginx.

— В этом деле, задача «Рамблера» — доказать, что Сысоев создал программу при исполнении своих трудовых обязанностей, — объясняет Юлия Сущенко, юрист юридической фирмы «Алейников и Партнеры». — Схема защиты от подобных заявлений для сотрудника в Беларуси, и в России схожа. Разберем её ниже.

1. Чётко определите, что именно входит в вашу должностную инструкцию

Разработкой Nginx Игорь Сысоев действительно занимался, когда работал в «Рамблере». Но само по себе это не делает Nginx служебным произведением.

И в Беларуси, и в России часто работодатели «цепляются» за то, что программа была создана в рабочее время и упорно доказывают это в суде. Но судебная практика подтверждает: «факт рабочего времени» может использоваться только как косвенное доказательство, не более.

Чтобы понять, входила ли разработка веб-сервера в трудовые обязанности Сысоева, обратимся к фактам. Он работал в «Рамблере» системным администратором. Предположим (как правило, так и есть), его должностная инструкция была стандартной. Читаем: «в соответствии с профессиональным стандартом „Системный администратор информационно-коммуникационных систем“ в обязанности системного администратора не входит разработка программного обеспечения».

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

2. Расскажите начальству, что вы занимаетесь своим проектом, и возьмите письменное согласие

Бывший исполнительный директор «Рамблер» готов подтвердить: Сысоев уведомил компанию, что Nginx — его собственный проект, и компания была с этим согласна. Учитывая известные обстоятельства дела, Nginx — не служебное произведение. Права на него принадлежат Сысоеву. Исключение: если существуют факты, которые остались за кадром.

В идеале, когда устраиваетесь на работу, берите у работодателя письменное согласие, в котором тот подтвердит, что:

  • ему известно, что у вас есть свой проект; 
  • он знаком с основными характеристиками этого проекта; 
  • он согласен с тем, что вы будете им заниматься; 
  • он признает, что исключительные права на любые объекты авторского права, созданные в процессе работы над проектом принадлежат вам.

В более сложных случаях может понадобиться письменное соглашение между работником и нанимателем.

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

Задание может быть письменным и устным. Если наниматель в споре будет ссылаться на устное задание, он сам должен будет доказать, что оно действительно было. На практике сделать это довольно сложно.

Если задание оформлено письменно, следите за тем, что написано в технических требованиях к программе. Хорошо, если это четкое ТЗ.

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

3. Убедитесь, что не нарушаете коммерческую тайну компании 

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

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

«Рамблер» может сослаться на то, что Сысоев использовал идеи, наработки, алгоритмы компании при работе над Nginx. Эти сведения могли составлять коммерческую тайну «Рамблера». Но, как показывает практика, это сложно доказать.

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

Итого:

  1. При трудоустройстве берите у работодателя письменное согласие, в котором он подтвердит, что согласен с тем, что вы работаете над чем-то своим и не претендует на продукт,
  2. Если не успели взять согласие во время работы, попробуйте постфактум, после увольнения. Сохраняйте документы, которые связаны с работой у нанимателя и переписку (их можно будет использовать в последующем),
  3. Работайте над собственным проектом в нерабочее время («свободный график» — отдельная история),
  4. Убедитесь, что не нарушаете коммерческую тайну компании,
  5. При общении с прессой, будьте благоразумны. Пример Сысоева хорош: в СМИ он с самого начала позиционировал продукт как свой. В одном из интервью прямо обозначил, что не считает произведение служебным и объяснил почему,
  6. Хорошо фиксировать рабочие задачи в отдельных программах (Jira, Slack),
  7. Заручитесь поддержкой авторитетного лица, который подтвердит вашу информацию (как Ашманов в кейсе Сысоева).

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

Стартапам необходимо иметь в виду: многие спорные вещи, которые вы не урегулировали между бывшими соавторами или с бывшими работодателями, всё ещё можно исправить, пока стартап готовится к сделке. После того, как вам удастся продать стартап за десятки и сотни миллионов, договориться с «бывшими» станет гораздо сложнее.

В заключение: сам факт того, что «Рамблер» предъявляет подобные требования к Nginx, подрывает стабильность гражданского оборота и уверенность инвесторов в надежности российской юрисдикции, — говорит Юлия.

[customscript]techrocks_custom_after_post_html[/customscript]

[customscript]techrocks_custom_script[/customscript]

1 комментарий к “Чтобы не вышло, как с «Рамблером». 7 советов для разработчиков”

  1. Чёто я не пойму. Если он реально продал свой проект за такие бабки, нафига ж сидеть в этой россии ?
    Бери деньги и едь жить в цивилизованную страну, где тебя никто щемить не будет. Пусть потом ищут и доказывают, если еще найдут.

Оставьте комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Прокрутить вверх