Вернуться к блогу
В разработке программного обеспечения принято обсуждать технологии, сроки и внешний вид системы. Но есть вопрос, который руководители компаний и ИТ-директоры часто откладывают на потом – юридическая архитектура продукта. В результате бизнес получает готовую систему, которая ему юридически не принадлежит или оказывается «заперт» в такой инфраструктуре, из которой ее невозможно извлечь без участия старого подрядчика.
Если вы вложили миллионы рублей в разработку, но ваш договор – это стандартная «рыба» из интернета, ваш продукт – это не актив, а бомба замедленного действия. В этом материале мы разберем, как выстроить работу так, чтобы код стал вашим безусловным имуществом.
Один из серьезных рисков – использование в вашем проекте чужих программных компонентов, условия использования которых несовместимы с вашим бизнесом. Разработчики часто применяют готовые решения с открытым кодом, чтобы не создавать всё с нуля. Это обычная практика, но здесь скрыта опасность.
В чем заключается риск? Есть разные типы условий использования открытого кода:
Свободные условия: Они позволяют использовать код в коммерческих продуктах без обязательства раскрывать, как устроен ваш проект. Это стандарт нашей работы.
Обязывающие условия: Они работают как «вирус». Если в ваш закрытый корпоративный проект попадает такой компонент, условия использования такого кода могут обязать вас опубликовать исходный код всего вашего продукта в открытом доступе.
Для бизнеса это грозит фактическим раскрытием всех наработок, применяемых в продукте. Представьте ситуацию: вы инвестировали годы в уникальные алгоритмы, а из-за одной случайно подключенной библиотеки обязаны предоставить доступ к своим секретам конкурентам.
Как мы в Amiga предотвращаем эти угрозы:
Проверка используемых компонентов: На этапе планирования мы проводим полную проверку всех сторонних инструментов.
Фиксация состава: Мы ведем строгую документацию, где указано, что именно и на каких условиях было использовано. Если какой-то инструмент не соответствует требованиям безопасности или нашей политики, мы находим аналог или создаем свое решение.
Гарантия отсутствия прав третьих лиц: В договоре мы фиксируем пункт, по которому исполнитель берет на себя юридическую ответственность за то, что поставляемый код не нарушает авторских прав и может быть легально использован заказчиком в коммерческих целях.
На заметку руководителю:
При обсуждении этого пункта с юристом, попросите убедиться, что ответственность подрядчика покрывает не только прямой ущерб, но и все возможные расходы, связанные с претензиями правообладателей – включая судебные издержки и затраты на замену программного обеспечения. Это ваша главная страховка от рисков.
Некоторые агентства оставляют за собой права на «базовые модули», «типовые шаблоны» или «ядро системы». Они говорят: «Мы это уже создавали для других проектов, это наше решение». В итоге вы получаете лишь право на использование (лицензию), а не право собственности. Если вы решите сменить команду, агентство может заявить: «Код ваш, но без наших модулей он работать не будет». Это создает критическую зависимость от этого агентства.
Мы проводим жесткое разделение в договоре:
Результаты работы: Это уникальная логика, алгоритмы, интерфейсы и решения, написанные под ваши задачи. Все права на них переходят заказчику в момент подписания акта и оплаты. Это ваша собственность.
Инструментарий: Это общие библиотеки и наши типовые наработки (например, шаблоны для входа в систему), которые не уникальны для вашего проекта. Мы не требуем за них никаких дополнительных выплат, но и не ограничиваем вас в их использовании.
На заметку руководителю:
Проследите, чтобы определение «инструментария» было максимально узким. Важно, чтобы подрядчик не мог расширить этот список до такой степени, что уникальная бизнес-логика вашего проекта окажется юридически «подвешенной» и лишенной статуса полноценного результата работы.
Частая ошибка бизнеса – считать, что владение кодом равно владению продуктом. Современный софт живет в облачных хранилищах и на серверах. Если доступы к ним находятся только у подрядчика, вы зависите от него критически.
Почему права администратора у подрядчика – это юридическая дыра: Если конкретный разработчик имеет бесконтрольный доступ к базе данных, где хранятся данные ваших клиентов, вы несете полную ответственность перед этими клиентами и законом за любые его действия. Если произойдет утечка, доказать в суде, что это был внешний взлом, а не ошибка инженера подрядчика, практически невозможно.
Наши правила безопасности:
Разделение сред: Мы никогда не работаем в «боевой» среде напрямую. У нас есть три изолированных контура – для разработки, для проверки (тестирования) и основной «боевой» контур. Это исключает случайное удаление данных или остановку системы.
Минимальные доступы: Разработчик получает доступ только к тем частям системы, которые нужны для выполнения конкретной задачи. Никаких «главных» прав у исполнителя быть не должно.
Журнал действий: Мы фиксируем все обращения к серверной инфраструктуре. Заказчик всегда может увидеть, кто, когда и зачем заходил на сервер.
Порядок отзыва прав: В договоре должна быть четкая процедура закрытия доступов при завершении работ или увольнении сотрудника подрядчика.
На заметку руководителю:
Обязательно включите в договор пункт об ответственности подрядчика за несвоевременное предоставление или закрытие доступов. Это критически важно для соблюдения требований регуляторов и защиты персональных данных ваших клиентов.
Большинство договоров о неразглашении – это формальные документы, которые не работают на практике. Они написаны общими фразами, что делает невозможным доказать факт утечки и взыскать реальный ущерб через суд.
Что мы меняем в соглашении для реальной защиты:
Четкое определение случая: Мы прописываем алгоритм – что именно считается утечкой, как мы о ней узнаем и в какой срок (максимум 24 часа) подрядчик обязан сообщить нам об этом.
Ответственность: Мы фиксируем ответственность не только за передачу данных третьим лицам, но и за попытки скрыть инцидент.
Техническое приложение: Это самая важная часть. В соглашении должен быть регламент работы с ключами доступа и учетными записями.
На заметку руководителю:
Убедитесь, что в соглашении прямо прописано ваше право проводить аудит безопасности у подрядчика. Вы должны иметь возможность проверить, как именно хранятся ваши данные и доступы, либо силами своих специалистов, либо с привлечением независимых экспертов.
Многие воспринимают приемку как проверку «работает кнопка или нет». На самом деле, это официальный момент передачи ответственности от исполнителя к вам.
Как правильно принимать проект:
Технический отчет: Подрядчик передает не только готовый продукт, но и отчеты о проверках безопасности кода.
Техническая документация: Отсутствие инструкций – это долг, который можно трактовать как невыполнение условий договора. Мы сдаем проект только при наличии полного описания системы.
Проверка соответствия: Мы проводим аудит кода на соответствие стандартам безопасности. Если код не проходит проверку, проект не считается завершенным.
Гарантийный период: В договоре прописывается, что гарантия не покрывает самостоятельные изменения, внесенные заказчиком, но полностью покрывает ошибки, допущенные из-за отступления от задания.
На заметку руководителю:
При приемке важно четко отделить ответственность за ошибки в коде от ответственности за работу сторонних сервисов или изменения, которые вы вносите самостоятельно после сдачи проекта. Это избавит вас от споров о стабильности системы в будущем.
Многие владельцы бизнеса смотрят на «технический долг» (неаккуратный код, написанный «на скорую руку») как на чисто техническую проблему. Но с точки зрения бизнеса – это юридический риск. Если ваш продукт построен на временных решениях, которые не позволяют закрыть уязвимости, вы не можете гарантировать стабильную работу системы перед своими клиентами.
В чем юридическая ловушка: Если в договоре с вашим клиентом прописаны гарантии качества работы системы (например, доступность сервиса 99,9% времени), а ваш подрядчик оставил в коде критические ошибки, которые приводят к падению системы – вы нарушаете договор. Доказать вину разработчика будет крайне сложно, если в договоре с ним качество кода не было определено как стандарт.
Как мы в Amiga решаем эту проблему: Мы вводим понятие «стандарта кодирования» в приложении к договору. Сдаем проект не просто «рабочим», а соответствующим современным стандартам безопасности и пожеланиям заказчика. Это дает вам юридическое основание требовать устранения дефектов, даже если внешне всё кажется стабильным.
На заметку руководителю:
Если в договоре прописаны стандарты безопасности (например, OWASP), проследите, чтобы они были указаны как обязательные требования к качеству результата, а не просто как «пожелания». Только так вы сможете требовать их соблюдения в суде.
Разберем ситуацию, которая часто случается при продаже бизнеса или привлечении инвестиций.
Ситуация: Компания готовится к привлечению инвестиций. Инвестор запрашивает реестр прав на интеллектуальную собственность.
Что выясняется в ходе аудита:
Часть важных модулей была написана фрилансерами, которые не подписали документы о передаче прав. Юридически права остались у них.
В системе нашли компоненты с открытыми лицензиями, требующими раскрытия исходного кода.
Результат: Сделка срывается. Инвесторы отказываются вкладывать деньги в актив, который может быть отозван правообладателями. Стартапу приходится тратить несколько месяцев и огромные бюджеты на переписывание системы с нуля.
Урок: Защита активов – это не трата времени. Это фундамент, без которого ваш бизнес невозможно масштабировать или продать.
Расставание – этап, на котором большинство подрядчиков перестает отвечать на звонки. У вас нет доступов, нет финальной документации, а код остался «в руках» исполнителя.
Что должно быть в финальном протоколе передачи:
Акт передачи прав: Документ, подтверждающий, что все исходные коды, ключи и доступы переданы заказчику.
Свидетельство об удалении: Подрядчик обязан предоставить акт об удалении всех копий вашего кода и данных со своих серверов и персональных устройств сотрудников. Это критически важно для защиты коммерческой тайны.
Сверка доступов: Вы должны лично (или через своего технического руководителя) подтвердить смену всех главных паролей и закрытие учетных записей подрядчика в системах управления проектом.
Если в вашем текущем договоре нет этих пунктов, ваш бизнес находится в зоне риска. Проверьте документ вместе с вашим юристом:
Гарантия отсутствия прав третьих лиц: Подрядчик прямо гарантирует, что код не нарушает авторских прав других правообладателей. Важно: прописана ли обязанность подрядчика компенсировать ваши расходы в случае претензий со стороны третьих лиц?
Момент перехода прав: Четко прописано: «Исключительные права на результат выполненных работ переходят к заказчику в момент подписания акта и оплаты».
Перечень передаваемого: Есть ли пункт о передаче документации, исходных кодов в читаемом виде и всех ключей доступа?
Регламент доступов: Прописан ли порядок выдачи, контроля и самое важное – моментального отзыва доступов к серверам и базам данных?
Ответственность за качество (стандарты): Прописано ли соответствие кода стандартам безопасности (например, отсутствие критических уязвимостей)? Без этого «технический долг» остается вашей проблемой, а не подрядчика.
Порядок расторжения: Что происходит с вашими данными, если вы решили разойтись? (Обязательное условие – полное удаление данных подрядчиком и подтверждение этого официальным актом об уничтожении информации).
Соглашение о неразглашении (NDA): Есть ли у вас отдельное техническое приложение к NDA, регламентирующее работу с ключами доступа и персональными данными?
На заметку руководителю:
Все эти пункты должны иметь в договоре обязательный характер. Если подрядчик отказывается фиксировать ответственность за качество кода или порядок удаления данных при расторжении – это серьезный сигнал, чтобы еще раз оценить риски партнерства с такой компанией.
Заказная разработка в 2026 году – это партнерство, в котором юридическая гигиена стоит на первом месте. Когда мы в Amiga подписываем договор, то понимаем: мы не просто пишем функции, а строим вашу капитализацию.
Если вы выбираете подрядчика – не смотрите только на портфолио с «красивыми кнопками». Смотрите на то, как компания оформляет документы, как передает права и защищает ваши данные. Профессионализм в разработке – это способность не только написать рабочий код, но и сделать так, чтобы этот код завтра стал вашим безусловным юридическим активом.
Разбор разницы между «оплатой услуг» и «передачей исключительных прав». Почему без специального пункта в договоре право остается за исполнителем (по умолчанию по ГК РФ).
Какие формулировки обязательны: переход прав в момент подписания акта, отсутствие обременений, гарантии авторства.
Риски GPL-лицензий и почему важно требовать от разработчиков отчет о сторонних библиотеках (Software Bill of Materials – SBOM).
Почему инфраструктура – это часть архитектуры защиты прав. Как зафиксировать право доступа и физического обладания кодом до начала работ.
Актуальность вопроса: кому принадлежит сгенерированный код и как юридически закрепить его принадлежность заказчику в доп. соглашениях.
Что делать, если над одним модулем работали и внутренние сотрудники, и внешняя команда. Как избежать споров о соавторстве.
Риск использования проприетарных технологий или самописных фреймворков исполнителя, которые невозможно обслуживать без участия автора.
Почему без ТЗ, архитектурных схем и истории версий (Git) доказать права на уникальные решения практически невозможно в случае суда.
Чек-лист: смена владельца в Git, передача ключей доступа, очистка от лишних аккаунтов, удаление «бекдоров» (скрытых доступов).
Юридические рычаги давления: как прописать санкции за нарушение интеллектуальных прав в договоре, не доводя дело до полноценного судебного разбирательства.
