Чей софт? Спор Rambler и Nginx вскрыл частые ошибки бизнеса и разработчиков

Мария Ортинская

Патентный поверенный, адвокат, управляющий партнер патентно-юридической компании IPStyle



 

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

Поводом для обысков стали претензии Rambler Group. По ее мнению, веб-сервер Nginx – это служебное произведение его бывшего сотрудника – Игоря Сысоева, со-основателя Nginx. В частности, работая некогда в Rambler, он разрабатывал софт в рабочее время, на рабочем компьютере и, соответственно, софт является служебным произведением и любое его использование без согласия Rambler нарушает исключительные права компании.

У представителей IT-комьюнити и сторонников Nginx такая позиция Rambler вызывает ряд вопросов. Например, почему претензии предъявляются лишь через 15 лет? Почему в должностные обязанности системного администратора (не программиста) входила разработка софта?

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

Пять выводов, которые могут сделать из данной ситуации представители бизнеса (независимо от географии) и избежать подобных споров:

1. Принимаете сотрудника на работу, нашли партнера или, наоборот, принимаете офер компании – обсудите существующие разработки двух сторон: компании и сотрудника. Кому принадлежат права сейчас? Кто, за чей счет будет продолжать разработку? Естественно, такие договоренности следует зафиксировать в письменном виде.

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

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

4. Работа с подрядчиками. Часто, особенно при создании изобретений, возникает необходимость передать разработку, чертежи сторонней компании – например, научному институту или клиенту. Обязательно фиксируйте такую передачу прав, правильно формулируйте предмет договора – тестирование вашего оборудование. И прописывайте, кому принадлежат результаты. Кажется, это итак очевидно, но на практике был спор, когда научный институт подал заявку на патентование изобретения на свое имя, руководствуясь тем, что сделал самое главное – дал заключение, что созданный заказчиком способ работает и достигает заявленных технических результатов. Да, спор был решен мирным путем, но риски судебных разбирательств были велики.

5. Группа авторов, изобретателей. Важно в командной работе определить – кто и за что отвечает, какая работа приводит к созданию IP-прав, а какая – всего лишь техническая. Например, обработка фотографий приводит ли к соавторству на фотографию? Или подготовка сервера, на котором будет разворачиваться программное обеспечение? Иными словами, важно четко разграничить технические функции и те, которые приводят к созданию IP-объекта, проговорить со всеми участниками процесса, а желательно – еще и зафиксировать письменно. Таким образом, можно уменьшить риски для бизнеса и нивелировать претензии: тестировщика – на соавторство компьютерной программы, ассистента художника – на иллюстрацию.

НАПИСАТИ ВІДПОВІДЬ

Коментуйте, будь-ласка!
Будь ласка введіть ваше ім'я