Кому принадлежит программа, написанная по заказу?

По общему правилу Гражданского кодекса исключительное право на программу, созданную по договору заказа, принадлежит заказчику, если в договоре не написано иное (ст. 1296 ГК РФ). Ключевые слова здесь — «если не написано иное»: именно эту оговорку и стоит прочитать в своём договоре до подписания, а не после. Формулировку сверяйте с юристом: у разных схем работы — заказ, подряд, штатные сотрудники, самозанятые — правила разные.

Права на программу и исходный код — это одно и то же?

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

Что просить у подрядчика, чтобы не остаться без кода?

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

Нормально ли, что репозиторий на время гарантии ведёт подрядчик?

Нормально, если это записано и объяснено. Гарантия — обязательство исправлять ошибки за свой счёт, а отвечать можно только за код, который никто не менял параллельно: две копии превращают починку в выяснение, чья строка виновата. Ненормально другое — когда при этом вам не отдают данные, не показывают журнал изменений и отказываются передавать исходники по запросу.

Как выглядит правильная передача исходного кода?

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

Что происходит с гарантией после передачи исходников?

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

Что такое вендор-лок и как его избежать?

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

Где должны храниться данные — у нас или у подрядчика?

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

Кому принадлежит программа, которую написали для вас

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

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

Право на программу: что говорит закон

По общему правилу исключительное право на программу, созданную по договору заказа, принадлежит заказчику, если договором не предусмотрено иное — статья 1296 Гражданского кодекса. То есть по умолчанию закон на вашей стороне, и специально «выбивать» права не нужно.

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

⚠️ Мы не юристы, и эта статья не заменяет консультацию. Схем работы больше одной: заказ, подряд, штатные разработчики (там своя статья — 1295, служебные произведения), самозанятые, подрядчик с субподрядчиками. Что написано в вашем конкретном договоре — вопрос к вашему юристу. Наша задача проще: показать, что спросить до подписания.

Почему права мало: где физически лежит система

Допустим, право ваше — по договору, чёрным по белому. Дальше начинается практика, и вопросы становятся другими.

Где работает система. Если сервер оформлен на подрядчика и оплачивается им, при расставании вы будете просить перенести то, что и так ваше. Сервер, домен и учётная запись у хостинга оформляются на компанию-заказчика — это первое, что стоит проверить, и это ничего не стоит на старте.

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

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

Отсюда и разница между «у нас есть доступ к серверу» и «у нас есть код». Первое не даёт второго.

Чек-лист: что спросить у подрядчика до подписания

Шесть вопросов, которые стоит задать до договора, а не после. Ответ «конечно, всё ваше» на них не считается — нужны формулировки в тексте.

Кому принадлежит исключительное право на программу и на её доработки. Одной строкой в договоре, без отсылок «в соответствии с законодательством».
Как передаются исходники: по какому документу, в какой срок, что входит в архив. Если процедура не описана, в момент нужды она станет переговорами.
Что именно входит в передачу: код, миграции базы, скрипты развёртывания, конфигурации, документация, инструкция «поднять с нуля». Архив без инструкции — это файлы, а не система.
На кого оформлены сервер, домен и учётные записи у хостинга и у внешних сервисов. Проверяется один раз, в начале.
Кто имеет доступ к базе, как он выдан и как отзывается. Хорошо, когда список доступов виден вам на сервере, а не рассказывается словами.
Что происходит с гарантией после передачи кода и на каких условиях возобновляются работы. Это единственный пункт, где честный ответ звучит некомфортно, — и по нему видно, насколько подрядчик готов говорить прямо.

Если заказываете интернет-магазин, к этим шести добавьте девять вопросов о самом магазине: остатки, чеки, маркировка, доставка.

Как выглядит передача исходного кода на практике

Правильная передача — это процедура, а не жест доброй воли. Выглядит она так.

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

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

Архив с документацией. Код, миграции, скрипты развёртывания, конфигурации, техническая документация и бизнес-правила — то есть не только «как собрать», но и «почему сделано так». Второе обычно и есть самое дорогое.

Развёртывание при вас. Копия системы поднимается с нуля на чистом сервере в присутствии ваших специалистов. Это единственная проверка, которая отличает работоспособную систему от папки с файлами, и занимает она час.

Что после передачи происходит с гарантией

Тут начинается место, где подрядчики обычно молчат, а заказчики потом удивляются. Гарантия, как правило, прекращается в момент передачи исходников — независимо от того, правил их кто-нибудь или нет.

Причина не в обиде и не в жадности. Гарантия — обязательство исправлять ошибки продукта за свой счёт. Отвечать за поведение системы можно, пока известно, что в ней работает: одна ветка, одна история изменений, известная версия. После передачи это знание исчезает — код у двух сторон, и проверить, что у вас работает именно переданная версия, уже нельзя.

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

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

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

Лечится это не доверием, а тремя условиями, которые проверяются в первый месяц:

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

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

Как это устроено у нас

Мы отвечаем на этот вопрос так часто, что вынесли ответ на отдельную страницу — «Передача исходного кода и порядок работ»: там подробно, с процедурой передачи, составом архива и границами гарантии.

Коротко: сервер, домены и данные — заказчика; на сервере стоит готовый продукт, а не мастерская; разработка ведётся в приватном репозитории, и каждая правка получает версию и строку в журнале изменений, открытом клиенту. Исходники передаём по письменному запросу, по акту, вместе с документацией — отказать мы не вправе. С момента передачи гарантия прекращается, а дальнейшие работы начинаются с аудита кода: об этом мы говорим до договора, а не после.

Что из этого забрать себе

Главное правило простое: проверяйте не обещания, а оформление. Право описывается в договоре, сервер и домен — в документах хостинга, доступ к базе — в списке учётных записей, документация — тем, что она есть сегодня, а не будет завтра. Всё это проверяется в первый месяц работы и почти ничего не стоит.

И ещё одно, менее очевидное: спросите про гарантию после передачи кода. Ответ на этот вопрос говорит о подрядчике больше, чем всё остальное предложение: здесь нельзя ответить приятно и честно одновременно, и видно, что для него важнее.

А как выглядит эта же логика внутри нашего сервиса «Анализ сайта» — покажем отдельно: ждите анонса в наших каналах в Telegram и MAX.

Коротко: частые вопросы

Кому принадлежит программа, написанная по заказу?: По общему правилу Гражданского кодекса исключительное право на программу, созданную по договору заказа, принадлежит заказчику, если в договоре не написано иное (ст. 1296 ГК РФ). Ключевые слова здесь — «если не написано иное»: именно эту оговорку и стоит прочитать в своём договоре до подписания, а не после. Формулировку сверяйте с юристом: у разных схем работы — заказ, подряд, штатные сотрудники, самозанятые — правила разные.
Права на программу и исходный код — это одно и то же?: Нет, и на этом чаще всего расходятся ожидания. Право — юридическая принадлежность: кто может использовать программу, дорабатывать её и передавать другим. Исходный код — файлы, из которых она собирается. Право может быть вашим, а рабочая копия кода при этом вестись у подрядчика; и наоборот, архив на диске не даёт прав, если о них не написано в договоре.
Что просить у подрядчика, чтобы не остаться без кода?: Шесть пунктов в договоре: кому принадлежит исключительное право; в какой срок и по какой процедуре передаются исходники; что входит в архив передачи (код, миграции, скрипты развёртывания, документация); где физически работает система и кто владеет сервером и доменом; кто имеет доступ к базе и как этот доступ отзывается; что происходит с гарантией после передачи кода.
Нормально ли, что репозиторий на время гарантии ведёт подрядчик?: Нормально, если это записано и объяснено. Гарантия — обязательство исправлять ошибки за свой счёт, а отвечать можно только за код, который никто не менял параллельно: две копии превращают починку в выяснение, чья строка виновата. Ненормально другое — когда при этом вам не отдают данные, не показывают журнал изменений и отказываются передавать исходники по запросу.
Как выглядит правильная передача исходного кода?: Письменный запрос без обоснования — акт приёма-передачи с номером версии и меткой снимка — архив, в котором лежат исходники, миграции базы, скрипты развёртывания, конфигурации и документация с инструкцией «поднять с нуля». Хорошая практика — развернуть копию на чистом сервере при заказчике: это единственная проверка, которая показывает, что передали работоспособную систему, а не папку файлов.
Что происходит с гарантией после передачи исходников?: Обычно она прекращается, и причина не в обиде: с момента передачи подрядчик не может убедиться, что у вас работает именно та версия, которую он написал. Это стоит проговорить заранее, чтобы передача кода не выглядела ссорой. Возобновление работ после неё разумно начинать с оплачиваемого аудита кода — сверки того, что работает у вас, с переданной версией.
Что такое вендор-лок и как его избежать?: Зависимость, при которой систему нельзя забрать у подрядчика без потерь: код у него, данные в его облаке, домен оформлен на него, а документации нет. Избегается не доверием, а тремя условиями: сервер, домен и данные оформлены на вас; выгрузка базы делается без участия подрядчика; документация ведётся по ходу работы, а не пишется при расставании.
Где должны храниться данные — у нас или у подрядчика?: У вас, если речь о корпоративной системе. Сервер оформляется на компанию, база и файлы лежат там же, доступ подрядчика выдаётся на время работ и снимается одной командой. Схема, при которой данные живут в личном кабинете подрядчика, удобна ему и рискованна вам: при расставании выгружать их придётся по доброй воле.