Назад в блог
Servizi Digitali

Ловушка интеллектуальной собственности в договорах на разработку ПО: кому на самом деле принадлежит ваш код?

24 февраля 2025 г.
2 min чтения
Ловушка интеллектуальной собственности в договорах на разработку ПО: кому на самом деле принадлежит ваш код?

Невидимая проблема в договорах на разработку ПО

Когда предприниматель или профессионал поручает цифровому агентству создание веб-сайта, мобильного приложения или SaaS-платформы, он часто сосредотачивается на сроках, стоимости и функциональности. Однако есть критический аспект, который редко изучается внимательно: пункт об интеллектуальной собственности. Во многих договорах на цифровые услуги клиент предполагает, что, оплачивая разработку, он автоматически получает полное право собственности на исходный код, дизайн и все созданные активы. Реальность часто иная. Многие стандартизированные договоры, составленные самими агентствами, содержат пункты, которые закрепляют за исполнителем исключительное право собственности на программное обеспечение, предоставляя клиенту лишь ограниченную, отзывную и непередаваемую лицензию на использование. Это все равно что купить дом, но иметь только право жить в нем, пока продавец это позволяет.

Как работает договорная ловушка

Ловушка тонка и скрывается в одной-двух строках раздела «Интеллектуальная собственность» или «Права на использование». В договоре может быть указано: «Исполнитель сохраняет все права, правовые титулы и интересы на Программное обеспечение, включая, без ограничения, все права интеллектуальной собственности. Клиент получает неисключительную, непередаваемую, отзывную лицензию на использование Программного обеспечения для своих внутренних бизнес-целей». Эта фраза превращает клиента в простого лицензиата, зависящего от исполнителя в любых изменениях, обновлениях или, что еще хуже, при продаже бизнеса. Если клиент решит сменить исполнителя, он может обнаружить, что не имеет никакого права забрать код с собой. Новый разработчик даже не сможет легально просмотреть исходный код без разрешения старого исполнителя. На практике клиент становится заложником первоначального исполнителя с ослабленной договорной позицией.

Реальные последствия для клиента

  • Привязка к исполнителю: Вы не можете сменить разработчика, не начав все с нуля, потеряв все первоначальные инвестиции.
  • Невозможность перепродажи ПО: Если ваша бизнес-модель включает перепродажу платформы третьим лицам, ограниченная лицензия вам это запретит.
  • Блокировка будущих доработок: Любое изменение должно проходить через исполнителя, который может устанавливать произвольные цены или отказаться их выполнять.
  • Риск отзыва лицензии: В случае спора исполнитель может отозвать лицензию, оставив вас без вашего цифрового продукта.
  • Сложности при due diligence: Если вы ищете инвестиции или хотите продать компанию, покупатели обнаружат, что вам не принадлежит основной актив — программное обеспечение.

Как защитить себя: essential checklist

Прежде чем подписать договор на разработку ПО, убедитесь, что в нем присутствуют следующие элементы:

  • Явный пункт об уступке прав: В договоре должно быть указано, что «Исполнитель уступает Клиенту на исключительной основе и на весь срок действия прав интеллектуальной собственности все права на Программное обеспечение, включая исходный код, документацию, дизайн и алгоритмы».
  • Передача исходного кода: Должна быть предусмотрена обязанность передать полный и рабочий исходный код по завершении проекта без дополнительной платы.
  • Право на модификацию и сублицензирование: Клиент должен иметь право изменять, обновлять, дополнять и сублицензировать программное обеспечение без ограничений.
  • Ограничение лицензии исполнителя: Исполнитель может сохранить за собой лишь ограниченную лицензию на использование ПО для целей обслуживания, но не для перепродажи другим клиентам.
  • Гарантия оригинальности: Исполнитель должен гарантировать, что код является оригинальным и не нарушает права третьих лиц, освобождая клиента от ответственности по любым претензиям.

Случай с библиотеками open source и фреймворками

Еще одна серая зона касается использования компонентов с открытым исходным кодом или фреймворков. Многие договоры не уточняют, основано ли конечное ПО на лицензиях open source (таких как GPL, MIT, Apache) и каковы обязательства по указанию авторства или раскрытию производного кода. Если ваше ПО включает код под лицензией GPL, вы можете быть обязаны раскрыть весь исходный код вашего продукта, фактически сделав его открытым. Полезно, чтобы в договоре были четко указаны лицензии всех используемых сторонних компонентов, а исполнитель обязался не использовать компоненты с ограничительными лицензиями без вашего явного согласия.

Практические советы по переговорам

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

Чек-лист: Безопасен ли ваш договор на разработку ПО?

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

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

Как интерпретировать результаты чек-листа

Интерактивный чек-лист выше — это практический инструмент для быстрой оценки надежности вашего договора на разработку ПО. Каждый пункт представляет собой элемент, отсутствие которого может превратить, казалось бы, справедливое соглашение в договорную ловушку. Давайте подробно разберем каждый пункт, чтобы понять, почему они так важны.

1. Явная передача прав: Без пункта, прямо передающего интеллектуальную собственность заказчику, законным владельцем ПО остается исполнитель. Во многих правовых системах простой заказ индивидуальной разработки не подразумевает автоматической передачи авторских прав. Требуется четкое письменное заявление. Если в договоре говорится о «лицензии», а не о «передаче», будьте осторожны: вы лишь берете ПО взаймы, а не владеете им.

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

3. Право на изменение и сублицензирование: Даже получив право собственности, договор может ограничивать ваши действия с ПО. Например, он может запрещать изменение кода или предоставление сублицензий третьим лицам. Для предпринимателя, желающего перепродавать платформу или интегрировать ее с другими системами, такие ограничения губительны. Право на сублицензирование особенно важно, если ПО предназначено для использования в составе более широкого предложения.

4. Запрет на повторное использование кода: Многие агентства разработки повторно используют код, библиотеки и модули от проекта к проекту. Если нет пункта, ограничивающего такое повторное использование, ваш конкурент может получить практически идентичное ПО, возможно, по более низкой цене. Вы можете разрешить повторное использование, но только при условии согласования снижения цены и если повторно используемый код не составляет основу вашего конкурентного преимущества.

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

6. Гарантия оригинальности и освобождение от ответственности: Если исполнитель использует чужой код без разрешения, вас могут привлечь к суду за нарушение авторских прав. Пункт об освобождении от ответственности обязывает исполнителя защищать вас и возмещать любые убытки, возникшие из-за нарушений прав интеллектуальной собственности. Без такой гарантии весь юридический риск ложится на вас.

Если после заполнения чек-листа не хватает хотя бы одного-двух пунктов, не подписывайте договор, не проконсультировавшись предварительно с профильным юристом. Изменение этих пунктов почти всегда возможно, особенно если исполнитель серьезный и профессиональный. Хороший договор защищает обе стороны и создает основу для долгосрочных отношений. Несбалансированный договор, напротив, — это бомба замедленного действия, которая взорвется в самый неподходящий момент.

NakedPact Logo

Редакционный комитет NakedPact

Статья подготовлена редакцией NakedPact. Наша миссия — анализировать, упрощать и выявлять несправедливые условия и скрытые риски в повседневных договорах для защиты граждан и потребителей.

Источники и правовые ссылки

  • Трудовой кодекс Российской Федерации, Статья 349.3
  • Статья 57 ТК РФ (Содержание трудового договора)
  • Постановления Пленума Верховного Суда РФ по трудовым спорам

Не доверяйте, проверяйте.

Теперь, когда вы знаете о рисках, не подписывайте вслепую. Загрузите контракт в NakedPact, и ИИ найдет скрытые условия. Это 100% бесплатно.

Проанализировать контракт сейчас