Короткий ответ: платёж не равен полному контролю
Кому принадлежат права на исходный код приложения, нельзя определить по банковской выписке. Сначала посмотрите, с кем подписан договор, что именно заказали и не записали ли стороны другое. Если создание программы заказали исполнителю, который сам не является автором, по общему правилу исключительное право получает заказчик, если договор не говорит иначе. Для автора-фрилансера, штатной разработки и кода, появившегося при других работах, правила отличаются.
Даже подтверждённое исключительное право не откроет закрытый репозиторий и не восстановит ключ подписи. Поэтому проверка состоит из четырёх вопросов: есть ли право, кто контролирует доступы, что фактически передано и сможет ли другая команда продолжить продукт.
Почему закон не даёт один ответ для любого договора
Программа для ЭВМ охраняется авторским правом, включая исходный текст и объектный код. Регистрация для возникновения авторских прав не обязательна. Но дальше пути расходятся: важны не слово «разработка» в переписке, а кто подписал договор и что именно заказали.
| Ситуация | Базовое правило | Что проверить |
|---|---|---|
| Подрядчик, который сам не автор, создаёт приложение по заказу | Право у заказчика, если договор не установил иное | Предмет договора, исключения, момент и состав результата |
| Код возник при выполнении других работ | Право может остаться у исполнителя, если договор не установил иное | Было ли создание программы прямо предусмотрено заданием |
| Договор заключён с самим автором | Действуют правила авторского заказа и условия о праве | Отчуждение права или лицензия, форма и вознаграждение |
| Код написали сотрудники исполнителя | Нужна непрерывная цепочка прав от авторов к стороне договора | Трудовые обязанности, задания, договоры и гарантии исполнителя |
| Использованы прежние модули и чужие библиотеки | У каждого компонента сохраняется свой правовой режим | Перечень компонентов, лицензии и пределы передачи |
Два похожих проекта могут дать противоположный ответ из-за одной строки в предмете договора или статуса исполнителя. Поэтому фразы «без пункта всё принадлежит разработчику» и «после оплаты всё автоматически ваше» одинаково опасны: обе пропускают факты, от которых зависит решение.
Когда нужен профильный юрист. Если стороны спорят о праве, исполнителем был автор-физлицо, использованы субподрядчики, программа зарегистрирована или договор противоречит актам и переписке, не полагайтесь на универсальный шаблон. Сначала соберите документы и версии результата, затем передайте их специалисту по интеллектуальным правам.
Четыре слоя для смены команды: право, контроль, комплект и продолжение
Представьте, что договор подтверждает право заказчика, но репозиторий лежит в личном аккаунте разработчика. Юридический слой закрыт, а операционный нет. Теперь обратная ситуация: архив кода скачан, но договор разрешает только пользоваться готовым сервисом. Файлы есть, а полномочий на переработку и передачу новой команде может не быть.
Право
Кто и как может использовать, менять и передавать результат.
Контроль
Кто управляет репозиторием, магазинами, облаком и доменами.
Комплект
Какая версия кода, сборки, данные и документы переданы.
Можно ли продолжить
Способна ли независимая команда повторить сборку и выпустить изменение.
Как читать договор: не искать одну волшебную фразу
Откройте предмет договора и задайте один вопрос: исполнитель обещал передать конкретное приложение или только провести консультации, настройку и поддержку? Затем сравните договор с техническим заданием: совпадают ли версия, модули, дизайн, серверная часть и документация. Чем точнее описан результат, тем меньше спор о том, что попало в акт.
Теперь найдите, что получает заказчик: исключительное право целиком или разрешение пользоваться продуктом. Во втором случае проверьте, можно ли менять код, подключать другую команду, выпускать версии, работать в нужных странах и передать продукт покупателю бизнеса. Автором кода всё равно остаётся человек, который его написал: личное авторство не продаётся.
Семь вопросов к условиям о правах
- Какой результат идентифицирован: приложение, сервер, дизайн, база данных, документация?
- Кому принадлежит исключительное право и нет ли в договоре противоположного исключения?
- Когда возникает или переходит право: по этапам, после оплаты, при подписании акта или иначе?
- Входит ли вознаграждение за право в цену и согласована ли модель для всех сторон?
- Может ли исполнитель использовать результат повторно и где проходит граница уникального кода?
- Гарантирует ли исполнитель права от сотрудников и субподрядчиков?
- Как учтены прежние модули, открытые библиотеки, шрифты, изображения и платные наборы инструментов?
Не пытайтесь превратить этот список в договор самостоятельно. Его задача: показать пробелы до юридической проверки. Хорошая формулировка должна учитывать реальные стороны и модель проекта, а не только красиво звучать в приложении к смете.
Репозиторий: архив исходников не заменяет историю проекта
Допустим, подрядчик прислал архив ZIP в день финального расчёта. Внутри есть исходный код, но нет истории изменений, меток релизов и настроек сборки. Новая команда видит состояние на одну дату, однако не понимает, какой код ушёл в магазин, почему приняли спорное решение и где искать исправление.
Рабочая схема проще: репозиторий находится в организации, которую контролирует бизнес, а подрядчик получает нужную роль. Заказчик видит изменения по ходу проекта, может сделать резервную копию и не ждёт «выгрузку исходников» после конфликта. Это не означает, что собственник должен проверять каждую строку. Он контролирует место хранения, владельцев и процедуру восстановления.
Что проверить в репозитории
- у компании есть административный доступ, привязанный не к одному сотруднику;
- видны история изменений, ветки и метка версии, которая соответствует релизу;
- описаны команды сборки, версии инструментов и переменные окружения без публикации секретов;
- серверная часть, миграции базы и инфраструктурные файлы учтены отдельно от мобильного интерфейса;
- есть перечень сторонних библиотек и сервисов, от которых зависит сборка;
- резервная копия проверяется восстановлением, а не фактом скачивания архива.
История особенно важна при споре о составе этапа: адрес репозитория и точная версия (ветка и отметка релиза) надёжнее фразы «исходный код передан в электронном виде». Но сам доступ к репозиторию не доказывает, что у компании есть исключительное право. Репозиторий подтверждает контроль, договор подтверждает право.
Аккаунты, ключи и облако: продукт шире исходного кода
Приложение продолжается за пределами репозитория. Магазин хранит карточку и релизы, облако запускает сервер, домен направляет трафик, сервис уведомлений отправляет сообщения, аналитика показывает события. Если эти активы зарегистрированы на личную почту подрядчика, смена команды превращается в цепочку переговоров и переносов.
| Актив | Что должно контролировать юрлицо | Проверка передачи |
|---|---|---|
| App Store, Google Play, RuStore | Организацию, владельца аккаунта, резервные контакты и роли | Вход, полномочия на релиз, договоры и уведомления |
| Подпись и сборка | Процедуру доступа к сертификатам, ключам и автоматической сборке | Сборка тестовой версии и план замены скомпрометированного секрета |
| Облако и база | Платёжный профиль, администраторов, резервные копии и журналы | Развёртывание тестовой среды и восстановление копии |
| Домен, почта, аналитика, уведомления | Регистратора, корпоративные адреса, владельцев проектов и интеграций | Роли, срок оплаты, восстановление и тестовый сигнал |
Apple и Google допускают перенос приложений или смену владельца при выполнении условий, но такой перенос не равен кнопке «передать всё». Часть отчётов, тестовых групп, связей с интегрированными сервисами и настроек может потребовать отдельной работы. Если открыть аккаунты на компанию в начале, после завершения договора не придётся собирать доступы по частям.
Секреты не вставляют в акт или письмо. В документе фиксируют состав, ответственную сторону и безопасную процедуру передачи. Сами пароли, закрытые ключи и токены передают через контролируемое хранилище, после чего лишние доступы отзывают, а чувствительные данные при необходимости меняют.
Акт передачи: инвентаризация, а не магическое заклинание
Акт полезен, когда отвечает на вопрос «что именно принято». Ссылка «код отправлен заказчику» слаба: репозиторий может измениться через минуту, а архив потеряться среди вложений. Укажите этап и версию так, чтобы третья команда нашла тот же результат.
В акте или приложенной ведомости обычно указывают договор и задание, адрес репозитория, ветку и отметку версии, перечень сборок и документации, аккаунты и роли, способ передачи секретов, результат проверки и открытые замечания. Если передаётся архив, полезна контрольная сумма: она помогает подтвердить, что стороны говорят об одном файле.
Но акт не лечит договор автоматически. Он не создаёт у исполнителя прав, которых тот не получил от автора, и не превращает лицензию в отчуждение одним словом. Поэтому юрист проверяет основание права, а техническая команда проверяет состав и воспроизводимость. Эти проверки встречаются в акте, но не подменяют друг друга.
Остальные риски сметы и приёмки собраны в отдельном разборе как бюджет разработки утекает через условия договора.
Главная проверка передачи: независимая команда продолжает продукт
Представьте нового разработчика, который не участвовал в проекте. Ему дают репозиторий, документацию и доступ к тестовой среде, но не устные подсказки прежней команды. Он должен понять, как подготовить окружение, собрать приложение, применить миграции и выпустить безопасную тестовую версию.
- Клонировать. Получить код и историю из контролируемого репозитория.
- Собрать. Установить зафиксированные версии инструментов и получить воспроизводимую сборку.
- Развернуть. Поднять тестовую серверную среду и применить миграции без доступа к боевым данным.
- Проверить. Пройти ключевой пользовательский сценарий и сверить версию с актом.
- Изменить. Внести безопасную правку и пройти путь до тестового релиза.
Сбой на любом шаге превращается в конкретный пункт передачи: не хватает инструкции, доступа, файла конфигурации, миграции или роли. Такой результат полезнее заверения «все исходники у вас». Он показывает цену смены команды до того, как эта смена станет срочной.
Передачу удобно встроить в процесс разработки от идеи до поддержки: обновлять документацию и проверять сборку на каждом значимом этапе, а не собирать их в последний день.
Когда полное отчуждение кода не нужно
Не каждый цифровой продукт должен стать исключительной собственностью заказчика. Если бизнес покупает доступ к типовой облачной CRM, готовому модулю или платформе под своим брендом, поставщик зарабатывает на повторном использовании общей системы. Требование передать весь исходный код может не соответствовать модели поставщика и заметно увеличить стоимость.
Тогда честное решение состоит в лицензии с понятными границами. Проверьте, кто владеет данными, можно ли выгрузить их в пригодном формате, что произойдёт при прекращении оплаты, как долго доступна работа и поддержка, можно ли перенести домен и интеграции, что случится с уникальными доработками. Для критичной системы иногда обсуждают депонирование исходников и условия доступа к ним при конкретном событии, но это отдельная юридическая и техническая конструкция.
Контрпример помогает провести границу: полное право особенно важно для уникального ядра заказного продукта; переносимость и план выхода нужны почти всегда. Даже если исходники платформы не ваши, данные и бизнес-процесс не должны оказаться заложниками одной учётной записи.
Чек-лист: 7 проверок перед сменой команды
Отметьте каждый пункт одним из четырёх статусов: «подтверждено», «отсутствует», «вопрос подрядчику» или «нужен профильный юрист». Не ставьте галочку по обещанию в чате; приложите документ, роль, ссылку или результат проверки.
Что делать, если приложение уже оплачено
Сначала не обвиняйте подрядчика. Разрыв мог возникнуть из-за слабой процедуры, а не злого умысла. Соберите договор, приложения, задания, акты, счета, ссылки на репозитории, сведения об аккаунтах и список работающих сред. Не пересылайте пароли и персональные данные в общую таблицу.
Например, отдельной строкой запишите: «релиз есть в магазине, но неизвестны его ветка и контрольная версия». Такой пробел можно обсудить без догадок о мотивах команды.
Затем разделите юридические и технические пробелы. Юрист проверяет право и цепочку авторов. Технический специалист сопоставляет релиз с репозиторием, сборками, инфраструктурой и документацией. Получится список пробелов и вопросов к подрядчику вместо общего вердикта «всё плохо».
После этого согласуйте передачу этапами. Сначала восстановите бизнес-контроль над аккаунтами и резервными копиями, затем закройте комплект материалов, выполните независимую тестовую сборку и зафиксируйте версию в акте или дополнительном соглашении. Если продукт опубликован в App Store, отдельный материал о публикации приложения поможет проверить, кто контролирует аккаунт магазина, подпись и выпуск обновлений.
Правовая основа и официальные источники
Правовые и платформенные сведения проверены 10 августа 2026 года. Ссылки ниже помогают понять механизм, но конкретный договор и спор требуют анализа документов.
- ГК РФ, статья 1261: программа для ЭВМ, исходный текст и объектный код.
- ГК РФ, статья 1296: произведение, созданное по заказу, и статья 1288: авторский заказ.
- ГК РФ, статья 1297: произведение, созданное при выполнении работ.
- ГК РФ, статья 1295: служебное произведение и статья 1234: отчуждение исключительного права.
- Apple: перенос приложения, кода и сборочных материалов в App Store Connect.
- Google Play: перенос приложения в другой аккаунт разработчика.
- GitHub: передача контроля над организацией.
FAQ
Кому принадлежит исходный код приложения после разработки?
В России ответ зависит от сторон, предмета и условий договора. Если создание программы заказали исполнителю, который сам не является автором, по общему правилу исключительное право получает заказчик, если договор не говорит иначе. Для договора с автором, служебного произведения и результата, возникшего при других работах, правила отличаются. Поэтому проверяют не только оплату, но и договор и обстоятельства создания кода.
Передаются ли права на код автоматически после оплаты?
Оплата сама по себе не даёт универсального ответа. Момент возникновения или перехода права зависит от применимого правила и договора; отдельно нужно подтвердить, какой результат создан и передан. Платёж, акт, пункт о правах и идентификация версии работают вместе, но не заменяют друг друга.
Достаточно ли получить архив с исходным кодом?
Нет, если бизнес должен продолжать продукт. Архив не подтверждает исключительное право, может не содержать историю изменений и не даёт доступ к магазинам, облаку, сборкам, данным, ключам и документации. Полноту передачи проверяет независимая сборка и развёртывание тестовой версии.
Что указать в акте передачи исходного кода?
Обычно в акте указывают договор и этап, адрес репозитория, ветку и точную версию, перечень переданных материалов и доступов, способ безопасной передачи секретов, результаты проверки, замечания и дату. Конкретную формулировку о правах должен сверить профильный юрист: акт не исправляет противоречивый договор автоматически.
Может ли разработчик повторно использовать части приложения?
Это зависит от договора, применимого режима и происхождения компонентов. Полезно заранее разделить уникальный код продукта, прежние наработки исполнителя, открытые библиотеки, платные наборы инструментов и сервисы. Для каждого слоя фиксируют право использования, ограничения и возможность передачи новой команде.
Всегда ли заказчику нужны исключительные права на весь код?
Нет. При покупке типового облачного сервиса, решения под брендом заказчика или стандартного модуля лицензия может быть экономически разумнее полного отчуждения. Тогда критичны пределы лицензии, доступ и экспорт данных, продолжение работы при смене поставщика, срок поддержки и план выхода. Уникальное ядро заказного продукта и типовой компонент можно оформить по-разному.
Соберите вопросы к подрядчику до следующего платежа
Первый шаг: оставьте контакт. Сначала договоримся о безопасном канале и объёме проверки. После этого можно передать обезличенный фрагмент условий о правах и список материалов или доступов. Не отправляйте пароли, ключи, персональные данные, коммерческие секреты и полный договор через неподтверждённый канал.
Что сделаем: в первом разговоре объясним, какие данные нужны для четырёх статусов: «подтверждено», «отсутствует», «вопрос подрядчику», «требуется профильный юрист». Результатом проверки станет карта следующего разговора с командой, а не обещание решить юридический спор без документов.