Бизнес vs. разработчики: кому принадлежат права на ПО и как все делать правильно сразу, чтобы потом не было мучительно больно

Бизнес vs. разработчики: кому принадлежат права на ПО и как все делать правильно сразу, чтобы потом не было мучительно больно
Фото: Unsplash

Вопрос, кому принадлежат интеллектуальные права на разработанный программистом в найме продукт, на прошлой неделе превратился в настоящую драму. В офисе компании Nginx прошли обыски, а у ее основателей изъяли телефоны, — все потому, что в начале 2000-х основатель работал сисадмином в «Рамблере» и именно тогда начал создавать свой стартап. В 2019 году корпорация решила, что права на Nginx принадлежат ей. Сейчас «Рамблер» дал задний ход и намерен отозвать заявление о возбуждении уголовного дела. Но чем все закончится, пока неизвестно. Бывают и зеркальные ситуации: когда иски и притязания исходят от разработчиков ПО, а компании несут ощутимые убытки. Чтобы избежать неприятностей, и программистам, и заказчикам важно знать, как правильно сохранить за собой (или передать другой стороне) права на продукт. Рассказываем о самых распространенных проблемах в этой области и о том, как их предупредить.

Если вы — компания

Бизнес часто привлекает к разработке ПО не только штатных сотрудников, но и фрилансеров (например для написания каких-то отдельных блоков и модулей). При этом некоторые компании забывают вовремя «забрать» себе права на продукт или просто не придают этому значения. Подобная беспечность может привести к серьезным проблемам, например таким.

Кто-то взял и запретил вашей компании продавать ПО клиентам или потребовал за это денег. Так бывает, когда продукт создавали несколько сотрудников, а свои права на него по каким-то причинам вам не передали. Когда компания уже зарабатывает на ПО, один из разработчиков присылает вам письмо с требованием прекратить продавать его интеллектуальную собственность. Либо еще хуже: пишет напрямую вашему клиенту и заявляет, что вы торгуете контрафактом. Крупные покупатели чаще всего не хотят скандалов и с большой вероятностью откажутся от вашего продукта и найдут ему замену.

От клиента вы узнаете, что кто-то предложил ему продукт, похожий на ваш, но по лучшей цене. Вскоре становится понятно, что это ваши бывшие сотрудники (или подрядчики) торгуют «вашим» же ПО. Продукт вы считаете своим, потому что «платили этим ребятам зарплату и вообще взрастили их с институтской скамьи». Пишете претензию и просите юристов пресечь «незаконные продажи», но те изучают документы и выясняют: вы не забрали права у программистов продукт официально принадлежит им.

Вы решили привлечь средства в компанию, но инвестор изучил вашу документацию и ушел. Первый вопрос, который задает себе человек, собирающийся вложить деньги: «Что я покупаю?» Его юрист непременно потребует документально подтвердить, что все активы компании действительно принадлежат вам (нет документов нет сделки). Да, иногда инвестор соглашается вложиться в стартап с подобными рисками, но фаундера попросят прописать в договоре, что никакие части кода не нарушают чужих прав. В противном случае сделку придется отменить, а деньги вернуть.

Что делать?

1. Чтобы законно показывать или продавать любой код, текст, картинку и дизайн, вам понадобится т. н. исключительное право на произведение. Такое право отдают насовсем (отчуждают) или передают в пользование «по лицензии».

2. Если разработчик находится с вами в трудовых отношениях:

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

во внутренних документах стартапа («локальных нормативных актах») создайте Положение о служебных произведениях и укажите в нем, как именно ставится задание и принимается результат;

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

3. С внешним разработчиком заключайте договор авторского заказа (если это просто физическое лицо) или договор оказания услуг (если это команда, работающая в рамках одного ООО). В документах обязательно пропишите, что наряду с результатом разработки вы получаете права на него, это два разных блага, и за каждое нужно платить.

4. Важно заранее предусмотреть, как именно вы будете забирать код от разработчиков. Поскольку авторское право защищает именно форму объекта (то, как он реализован), важно, чтобы эта передача была неизменяемой. Грубо говоря, файл в аттаче почты более-менее ОК, а GoogleDoc нет (если документ поменяют, доказать что-либо суду будет непросто).

5. Авторское вознаграждение разработчику нужно оплатить отдельно от его заработной платы (если он работает по трудовому договору) или от гонорара по договору авторского заказа (если привлекаете фрилансера). В наименовании платежа лучше четко прописать, что это плата за «отчуждение исключительного права» на разработанный продукт.

Если вы — программист

Разработчики (как штатные, так и фрилансеры) тоже могут сильно пострадать из-за незнания законодательства в сфере авторских прав. Вот что с вами может произойти, если подписывать документы не глядя.

В свободное от работы время вы создали собственный продукт, но потом не можете им пользоваться. Например, в компании разрабатывали приложение для мам, а параллельно с друзьями делали софт для собаководов. При этом вы честно не использовали ни строчки кода из приложения работодателя, но «юзали» рабочий компьютер (а сисадмины легко докажут, что вы делали это в рабочее время). В этом случае высока вероятность, что приложение у вас заберут, — свои права на него защитить не удастся.

Заказчик по каким-то причинам не заплатил вам за код, но продать его кому-то другому или использовать самостоятельно нельзя. Такая ситуация возможна, если еще во время разработки вы не глядя подписали «какие-то документы». По этим бумагам вы вполне могли передать все права заказчику.

Вы кастомизировали свой core-продукт под конкретного заказчика, а затем столкнулись с проблемами при следующем заказе. Подобное может случиться, если вы по ошибке передадите клиенту полностью права не только на обновление под него, но и на сам core-продукт.

Что делать?

1. Не держитесь за права просто ради «пусть будут» — вы можете здесь и сейчас продать их и получить больше денег. С самого начала оговорите с заказчиком объем передачи прав. Вот какие возможны варианты:

— только заказчик может использовать ПО (самый дорогой вариант: у вас забирают все права);

— наряду с заказчиком использовать ПО можете и вы, но без права продажи (исключительная лицензия);

— заказчик использует ПО, но вы по-прежнему можете его продавать (неисключительная лицензия на ваши права).

Прежде чем передать права, четко определите для себя потенциал и перспективы продукта: что вы собираетесь с ним делать в будущем? После этого решите, какой объем прав вы готовы отдать и за сколько.

2. Если вы фрилансер — внимательно ознакомьтесь с договором авторского заказа и всеми остальными документами, которые вам предложат подписать. А если работаете в штате — изучите, что написано в трудовом договоре, должностной инструкции и внутренних положениях компании об интеллектуальных правах, служебных произведениях и правилах внутреннего распорядка. Если вы разрабатываете собственный продукт в свободное от работы время, важно, чтобы он не был предметом вашего служебного задания. Иными словами: убедитесь, что работодатель или заказчик не просил вас сделать что-то похожее. Более того, для своего личного проекта нельзя брать даже отдельно написанные вами для компании модули. Разрабатывайте полностью отдельный и новый продукт.

3. При создании личного проекта не используйте ресурсы работодателя (например компьютеры и прочую оргтехнику). Возможно, права у вас потом и не отберут, но нервы точно попортят. Использовать чужие мощности — незаконно.

4. Четко фиксируйте в документах, на что и в каком объеме вы передаете права. Например, свой core-продукт можно передавать по неисключительной лицензии (у вас остается возможность и дальше делать с ним что угодно). А на программную «надстройку» — отчуждать заказчику свое исключительное право в полном объеме (ведь эту работу вы делали специально для него).