Конфликты в IT почти никогда не начинаются с чьего-то желания навредить. Чаще всего в основе лежит простая неопределённость: кто на самом деле владеет кодом, на каких условиях привлекался дизайнер и что делать, если внутри продукта обнаружился чужой компонент с «вирусной» лицензией. Юридическая проверка IT-проекта тем и отличается от формального комплаенса, что ищет не абстрактные нарушения, а конкретные точки отказа — ситуации, способные остановить разработку или сделать продукт непригодным для инвестиций. Ниже — карта узлов, которые стоит осмотреть до того, как проект выйдет на рынок или попадёт на due diligence.
Права на код: инвентаризация, а не предположения
Первое, что запрашивает инвестор или покупатель, — реестр программных компонентов и подтверждение прав на них. На практике именно здесь обнаруживаются самые дорогие пробелы. Разработчик, нанятый по гражданско-правовому договору, написал модуль, но в договоре нет прямого указания на отчуждение исключительного права. По умолчанию, согласно статье 1288 ГК РФ, заказчик получает право использования на условиях исключительной лицензии на срок, указанный в договоре, а если срок не указан — на пять лет. Это означает, что через пять лет правообладатель может распорядиться тем же кодом по своему усмотрению, а проект рискует остаться без ключевого компонента. Проверка здесь сводится к простому, но жёсткому правилу: на каждый значимый фрагмент кода, созданный внешним исполнителем, должен быть акт приёма-передачи с формулировкой об отчуждении исключительного права в полном объёме.
Сотрудники, работающие по трудовому договору, создают служебные произведения. По статье 1295 ГК РФ исключительное право на служебное произведение принадлежит работодателю, если трудовым или иным договором не предусмотрено иное. Однако это правило работает только при условии, что создание ПО входит в трудовые обязанности работника, зафиксированные в должностной инструкции или трудовом договоре. Если разработчик числится системным администратором, а фактически пишет ядро продукта, презумпция принадлежности прав работодателю может быть оспорена. Поэтому проверка трудовой документации — не бюрократическая формальность, а ключевой этап инвентаризации активов.
Open source: аудит лицензионной совместимости
Использование открытого исходного кода давно стало нормой, но юридические последствия этого выбора до сих пор недооценивают. Копилефтные лицензии, такие как GPL, требуют, чтобы производный продукт распространялся на тех же условиях. Это не означает, что весь коммерческий продукт автоматически становится открытым, но если GPL-компонент встроен в ядро программы статически, суд может признать программу производным произведением. В российской практике споры по GPL пока единичны, но зарубежные прецеденты, например Software Freedom Conservancy против Westinghouse, показывают, что нарушители копилефтных лицензий сталкиваются с судебными запретами на распространение продукта.
Проверка строится на составлении Software Bill of Materials — перечня всех сторонних библиотек, фреймворков и утилит с указанием точной версии и текста лицензии. Особое внимание — компонентам с двойным лицензированием и библиотекам, которые изменили лицензию между версиями. Например, переход проекта с Apache 2.0 на AGPL в новой версии может остаться незамеченным, если разработчик обновил зависимость, не проверив изменившиеся условия. Отдельный риск — использование кода с GitHub без явно указанной лицензии: отсутствие лицензии не означает общественное достояние, по умолчанию действует режим авторско-правовой охраны, и использование такого кода коммерчески рискованно.
Данные пользователей: согласие, локализация, минимизация
Почти любой современный IT-проект собирает данные. Характер сбора определяет применимый режим регулирования. Если проет обрабатывает персональные данные, вступают в силу требования Федерального закона «О персональных данных», включая обязанность локализовать запись, систематизацию, накопление и хранение данных российских граждан на серверах, физически располженных в России (часть 5 статьи 18). Это требование касается не только оператора, но и любого лица, которому оператор поручает обрабтку. Проверка должна подтверить, что серверная инфраструктура сооответствует требованию локализации, а поручения обрабтки третьим лицам оформлены письменно с указанием перечня действий и целей обрабтки.
Пользовательские соглашения и политики конфиденциальности часто копируются из шаблонов без привязки к реальным бизнес-процессам. В ходе проверки стоит сопоставить заявленные цели обрабтки с фактически собираемыми полями: если политика говорит о сборе только email для рассылки, а мобильное приложение запрашивает доступ к геолокации и списку контактов, это классический состав нарушения, за который Роскомнадзор выносит предписания. Отдельно проверяется механим получения согласия: активные действия пользователя (проставление галочки) предпочтительнее молчаливого согласия, которое сложнее доказывать при проверке.
Контент и пользовательская генерация: риски посредника
Если проект предполагает загрузку контента пользователями — изображений, текстов, видео, — возникает вопрос о пределах ответственности информационного посредника. Статья 1253.1 ГК РФ предоставляет иммунитет при соблюдении ряда условий: информационный посредник не инициирует передачу, не изменяет материал и своевременно реагирует на претензии правообладателей. Однако этот иммунитет не абсолютен. Сервисы, которые модерируют контент до публикации, могут быть признаны активными участниками распространения, что повышает риски.
Проверка должна оценить, насколько чётко в пользовательском соглашении прописаны гарантии пользователя о наличии прав на загружаемый контент и объём лицензии, которую пользователь предоставляет сервису. Без такой лицензии даже техническая обрабтка изображения для создания превью может формально считаться нарушением. Полезно также проверить наличие и работоспособность формы для направления жалоб по DMCA или аналогичному локальному механимзу — это один из факторов добросовестности, который учитывают суды.
Договоры с контрагентами: неочевидные разрывы
Помимо договоров на разработку, в проекте всегда есть массив смежных соглашений: договоры с хостинг-провайдерами, CDN-сервисами, платёжными агрегаторами, API-провайдерами. Каждый из них может содержать ограничения, влияющие на бизнес-модель. Наприер, условия использования стороннего API могут запрещать коммерческое использование данных, полученных через этот API, или ограничивать количество запросов так, что при масштабировании проет окажется перед выбором: нарушить договор или остановить рост.
Особого внимания заслуживают соглашения о неразглашении (NDA) с потенциальными инвесторами и партнёрами. Нередко в них включают пункты о переходе прав на результаты интеллектуальной деятельности, созданные в ходе обсуждения. Если в рамкак питч-сессии основатель раскрывает архитектурные решения, а через месяц обнаруживает похожий продукт у контрагента, отсутствие грамотного NDA с ограничением использования раскрытой информации делает защиту крайне затруднительной. Проверка должна выявить, какие именно договоры содержат положения о конфиденциальности и не создают ли они непреднамеренных обременений для проета.
Товарные знаки и домены: защита названия
Название продукта и доменное имя — активы, которые легко потерять на старте, если не провести предварительную проверку. Товарный знак проверяется по открытым реестрам Роспатента на предмет тождественных и сходных до степени смешения обозначений в отношении однородных товаров и услуг. Важно помнить, что для программного обеспечения и онлайн-сервисов ключевыми классами МКТУ обычно являются 9, 42 и 35, но перечень не должен быть избыточным: неиспользование товарного знака в течение трёх лет по любому из заявленных классов создаёт риск досрочного прекращения правовой охраны по требованию заинтересованного лица.
Доменное имя проверяется не только на доступность, но и на историю использования. Домен, ранее занятый сайтом с контрафактным контентом, может сохранять негативные ассоциации у поисковых систем и пользователей. Кроме того, если домен воспроизводит чужой товарный знак или фирменное наименование, владелец рискует столкнуться с иском о защите исключительных прав и требованием о передаче домена. Такие споры рассматриваются и в рамкак административной процедуры UDRP, и в государственных судах.
Структура сделки и корпоративный контур
Юрилическая проверка не ограничивается продуктовым уровнем. Важно, чтобы корпоративная структура владения интеллектуальной собственностью сооответствовала бизнес-логике. Если права на ключевой актив зарегистрированы на физическое лицо — основателя, а операционную деятельность ведёт компания, это создаёт налоговые и юридические риски. При инвестиционной сделке такая ситуация потребует дополнительного структурирования и может повлиять на оценку. Аналогично, если команда распределена по разным юрисдикциям, необходимо проверить, что договоры с разработчиками подчинены праву, которое признаёт конструкцию отчуждения исключительных прав или служебного произведения в том виде, в каком она задумана.
Отдельный сюжет — опционы и мотивационные программы для ключевых сотрудников. Если разработчикам обещаны доли в компании или виртуальные опционы без надлежащего оформления, при выходе сотрудника проет может столкнуться с требованием о выделе доли или выплате компенсации, что парализует оперативное управление. Проверка корпоративных документов и соглашений с командой позволяет выявить такие обещания на ранней стадии и оформить их юридически корректно.
Стоимость исправления юридических ошибок растёт экспоненциально по мере развития проекта. Ошибка, допущенная на этапе прототипа и не выявленная до раунда А, способна обесценить значительную часть вложенных средств. Именно поэтому проверка IT-проекта — это не разовое мероприятие перед сделкой, а непрерывный процесс, встроенный в цикл разработки. Начать стоит с инвентаризации прав на код и аудита лицензий — эти два шага покрывают наибольшее количество рисков, типичных для технологических компаний на ранней стадии.