Вы заплатили за приложение, но не можете сменить подрядчика: семь проверок

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

Материал подготовила команда 13FOX (tfox.dev). Мы создаём сайты, мобильные приложения и цифровые сервисы для бизнеса и показываем, как принимать продуктовые решения по проверяемым данным.

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

В такой ситуации спор о фразе «права переданы» уже не решает операционную проблему. Бизнесу нужно одновременно подтвердить четыре слоя: юридическое право, фактический контроль, комплект материалов и возможность продолжить продукт другой командой.

Ниже — не универсальная юридическая консультация, а практическая карта вопросов к договору, репозиторию, аккаунтам и акту передачи.

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

Даже подтверждённое исключительное право не откроет закрытый репозиторий и не восстановит ключ подписи. Поэтому проверка состоит из четырёх вопросов: есть ли право, кто контролирует доступы, что фактически передано и сможет ли другая команда продолжить продукт.

Представьте, что договор подтверждает право заказчика, но репозиторий лежит в личном аккаунте разработчика. Юридический слой закрыт, а операционный нет. Теперь обратная ситуация: архив кода скачан, но договор разрешает только пользоваться готовым сервисом. Файлы есть, а полномочий на переработку и передачу новой команде может не быть.

Право Кто и как может использовать, менять и передавать результат.

Контроль Кто управляет репозиторием, магазинами, облаком и доменами.

Комплект Какая версия кода, сборки, данные и документы переданы.

Можно ли продолжить Способна ли независимая команда повторить сборку и выпустить изменение.

Откройте предмет договора и задайте один вопрос: исполнитель обещал передать конкретное приложение или только провести консультации, настройку и поддержку? Затем сравните договор с техническим заданием: совпадают ли версия, модули, дизайн, серверная часть и документация. Чем точнее описан результат, тем меньше спор о том, что попало в акт.

Теперь найдите, что получает заказчик: исключительное право целиком или разрешение пользоваться продуктом. Во втором случае проверьте, можно ли менять код, подключать другую команду, выпускать версии, работать в нужных странах и передать продукт покупателю бизнеса. Автором кода всё равно остаётся человек, который его написал: личное авторство не продаётся.

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

Допустим, подрядчик прислал архив ZIP в день финального расчёта. Внутри есть исходный код, но нет истории изменений, меток релизов и настроек сборки. Новая команда видит состояние на одну дату, однако не понимает, какой код ушёл в магазин, почему приняли спорное решение и где искать исправление.

Рабочая схема проще: репозиторий находится в организации, которую контролирует бизнес, а подрядчик получает нужную роль. Заказчик видит изменения по ходу проекта, может сделать резервную копию и не ждёт «выгрузку исходников» после конфликта. Это не означает, что собственник должен проверять каждую строку. Он контролирует место хранения, владельцев и процедуру восстановления.

История особенно важна при споре о составе этапа: адрес репозитория и точная версия (ветка и отметка релиза) надёжнее фразы «исходный код передан в электронном виде». Но сам доступ к репозиторию не доказывает, что у компании есть исключительное право. Репозиторий подтверждает контроль, договор подтверждает право.

Приложение продолжается за пределами репозитория. Магазин хранит карточку и релизы, облако запускает сервер, домен направляет трафик, сервис уведомлений отправляет сообщения, аналитика показывает события. Если эти активы зарегистрированы на личную почту подрядчика, смена команды превращается в цепочку переговоров и переносов.

Apple и Google допускают перенос приложений или смену владельца при выполнении условий, но такой перенос не равен кнопке «передать всё». Часть отчётов, тестовых групп, связей с интегрированными сервисами и настроек может потребовать отдельной работы. Если открыть аккаунты на компанию в начале, после завершения договора не придётся собирать доступы по частям.

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

Акт полезен, когда отвечает на вопрос «что именно принято». Ссылка «код отправлен заказчику» слаба: репозиторий может измениться через минуту, а архив потеряться среди вложений. Укажите этап и версию так, чтобы третья команда нашла тот же результат.

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

Но акт не лечит договор автоматически. Он не создаёт у исполнителя прав, которых тот не получил от автора, и не превращает лицензию в отчуждение одним словом. Поэтому юрист проверяет основание права, а техническая команда проверяет состав и воспроизводимость. Эти проверки встречаются в акте, но не подменяют друг друга.

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

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

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

Передачу удобно встроить в процесс разработки от идеи до поддержки: обновлять документацию и проверять сборку на каждом значимом этапе, а не собирать их в последний день.

Отметьте каждый пункт одним из четырёх статусов: «подтверждено», «отсутствует», «вопрос подрядчику» или «нужен профильный юрист». Не ставьте галочку по обещанию в чате; приложите документ, роль, ссылку или результат проверки.

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

Например, отдельной строкой запишите: «релиз есть в магазине, но неизвестны его ветка и контрольная версия». Такой пробел можно обсудить без догадок о мотивах команды.

Затем разделите юридические и технические пробелы. Юрист проверяет право и цепочку авторов. Технический специалист сопоставляет релиз с репозиторием, сборками, инфраструктурой и документацией. Получится список пробелов и вопросов к подрядчику вместо общего вердикта «всё плохо».

После этого согласуйте передачу этапами. Сначала восстановите бизнес-контроль над аккаунтами и резервными копиями, затем закройте комплект материалов, выполните независимую тестовую сборку и зафиксируйте версию в акте или дополнительном соглашении. Если продукт опубликован в App Store, отдельный материал о публикации приложения поможет проверить, кто контролирует аккаунт магазина, подпись и выпуск обновлений.

Программа для ЭВМ охраняется авторским правом, включая исходный текст и объектный код. Регистрация для возникновения авторских прав не обязательна. Но дальше пути расходятся: важны не слово «разработка» в переписке, а кто подписал договор и что именно заказали.

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

Когда нужен профильный юрист. Если стороны спорят о праве, исполнителем был автор-физлицо, использованы субподрядчики, программа зарегистрирована или договор противоречит актам и переписке, не полагайтесь на универсальный шаблон. Сначала соберите документы и версии результата, затем передайте их специалисту по интеллектуальным правам.

Не каждый цифровой продукт должен стать исключительной собственностью заказчика. Если бизнес покупает доступ к типовой облачной CRM, готовому модулю или платформе под своим брендом, поставщик зарабатывает на повторном использовании общей системы. Требование передать весь исходный код может не соответствовать модели поставщика и заметно увеличить стоимость.

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

Контрпример помогает провести границу: полное право особенно важно для уникального ядра заказного продукта; переносимость и план выхода нужны почти всегда. Даже если исходники платформы не ваши, данные и бизнес-процесс не должны оказаться заложниками одной учётной записи.

У бизнеса может быть договор о правах и при этом не быть рабочего контроля. И наоборот: доступ к репозиторию сам по себе не подтверждает юридическую цепочку. Поэтому проверка всегда идёт по двум направлениям — документы и техническая воспроизводимость.

Лучший тест передачи выглядит буднично: независимый специалист получает согласованный комплект, собирает тестовую версию, подключает её к разрешённой среде и фиксирует пробелы. Если это невозможно, акт не должен превращать неизвестность в формально закрытый этап.

Материал подготовила команда 13FOX (tfox.dev). Мы помогаем принимать и продолжать мобильные продукты при смене команды; конкретные правовые формулировки следует согласовывать с профильным юристом по документам проекта.