Передача прав на код, дизайн и контент: что важно IT- и gamedev-компаниям

Автор: редакция 4dev.com. Юридический комментарий — Futura Digital. Обновлено: август 2026. Материал носит информационный характер и не является юридической консультацией; правовая база приведена по российскому законодательству, для конкретной ситуации и других юрисдикций нужен профильный юрист.

Оплата работы не передаёт права. Код, арт, музыку, интерфейсы и тексты создаёт исполнитель — и по умолчанию именно у него остаётся исключительное право, пока обратное прямо не закреплено в договоре и не подтверждено документами. По статье 1297 ГК РФ, если результат появился при выполнении работ, но договор его создание прямо не предусматривал, право по умолчанию у подрядчика, а заказчик получает лишь простую лицензию.

Разберём по порядку: кому принадлежат права по умолчанию, чем отчуждение отличается от лицензии, что должно быть в договоре, как фиксируют приёмку и переход прав, как всё это собрать по распределённой команде, что смотрят на IP due diligence и при чём тут IP Box на Кипре. В конце — чек-лист, FAQ по реальным запросам и то, чем на разных участках помогают 4dev.com и юридический партнёр материала Futura Digital.

Коротко

Право переходит к компании, если в договоре есть условие об отчуждении исключительного права, и переход подтверждён документами по конкретному результату.
Разные отношения — разные правила по умолчанию: у штатного сотрудника, подрядчика по заказу и подрядчика, чей результат «побочный», право распределяется по-разному (ст. 1295, 1296 и 1297 ГК РФ).
Личные неимущественные права (авторство, имя) не передаются никогда — но владению исключительным правом это не мешает (ст. 1228 ГК РФ).
Акт закон не требует. Он остаётся удобным способом зафиксировать, что именно принято; ту же роль сегодня выполняют таск-трекер, история коммитов и факт передачи файлов.
Слабое место почти всегда всплывает уже на сделке, раунде или релизе.
IP Box не работает без оформленной передачи прав: льготный режим применяют к той интеллектуальной собственности, которой компания владеет документально.

Почему «оплатил работу» не значит «владею правами»

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

Здесь помогает различать два слоя прав. Личные неимущественные — право авторства и право на имя — остаются за человеком навсегда и не отчуждаются (ст. 1228 ГК РФ): автор кода останется его автором, что бы ни было написано в договоре. А вот исключительное (имущественное) право — то есть право использовать результат, продавать, дорабатывать, запрещать другим — как раз передаётся. Именно оно нужно компании, и именно его чаще всего забывают оформить.

Программный код закон приравнивает к литературному произведению и охраняет как объект авторского права с момента создания, без обязательной регистрации (ст. 1259, 1261 ГК РФ). То же с артом, музыкой, текстами, дизайном интерфейсов. Правовая охрана возникает автоматически, и возникает она у автора. У того, кто заплатил, её нет. Чтобы право оказалось у компании, нужно основание: договор с нужной формулировкой.

Отсюда простое правило, которое стоит запомнить всей команде: получить исходники, макеты и ассеты «в папку» — не то же самое, что получить на них права.

Кому принадлежат права по умолчанию

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

Штатный сотрудник — служебное произведение, ст. 1295

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

Подрядчик, если создание результата — прямой предмет договора, ст. 1296

Кому право по умолчанию: заказчику, если стороны не договорились иначе.
Что делать на практике: всё равно прямо прописать передачу исключительного права и зафиксировать приёмку результата. Формулировки договора могут изменить то, что действует «по умолчанию».

Подрядчик, если результат является побочным по договору работ или услуг, ст. 1297

Кому право по умолчанию: подрядчику; заказчик получает простую лицензию.
Что делать на практике: обязательно включить условие об отчуждении исключительного права. Иначе право останется у исполнителя.

Фрилансер-физлицо по договору авторского заказа, ст. 1288

Кому право по умолчанию: зависит от условий договора. Без прямого отчуждения исключительное право может остаться у автора.
Что делать на практике: явно прописать отчуждение исключительного права в полном объёме.

Внешний исполнитель без письменного договора

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

Контент с участием генеративного ИИ

Кому право по умолчанию: вопрос спорный; у результата, полностью сгенерированного ИИ без творческого вклада человека, нет автора-человека.
Что делать на практике: фиксировать творческий вклад человека, хранить промпты и историю правок, проверять условия используемого сервиса и отдельно закреплять эти вопросы в договоре.

Обратите внимание на строку про статью 1297. Это контринтуитивный момент, на котором спотыкаются даже аккуратные команды: сам факт договора подряда не гарантирует, что права у вас. Если в договоре предмет — «доработать сервис», а разработчик попутно написал новый модуль, право на модуль по умолчанию его. Поэтому юристы советуют не полагаться на «по умолчанию» вообще и закреплять отчуждение прямо — в любом сценарии.

Комментарий Futura Digital. На практике спор возникает из-за расплывчатого предмета договора, без всякого злого умысла. Мы рекомендуем описывать результат максимально конкретно (репозиторий, ветка, перечень ассетов, макеты), отдельно фиксировать отчуждение исключительного права в полном объёме и на весь срок для всех территорий, и подкреплять это документально подтверждённой приёмкой. Для международных команд формулировки подстраиваются под применимое право — правила юрисдикций расходятся.

Передача прав и лицензия: не путать

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

Договор об отчуждении исключительного права (ст. 1234 ГК РФ) передаёт право в полном объёме — как продажа. Лицензионный договор (ст. 1235 ГК РФ) — это аренда: право остаётся у правообладателя, а вы получаете набор разрешённых действий, часто с ограничениями по территории, сроку и способам использования.

Отчуждение исключительного права — ст. 1234

Что происходит с правом: исключительное право полностью переходит к вам.
Кто ещё может использовать: только вы.
Срок и территория: бессрочно, по всему миру.
Можно ли перепродать или внести в сделку: да.
Как это обычно воспринимает инвестор: чистая и понятная структура прав.

Исключительная лицензия

Что происходит с правом: исключительное право остаётся у автора.
Кто ещё может использовать: автор не может выдавать такие же лицензии другим лицам.
Срок и территория: определяются договором.
Можно ли перепродать или внести в сделку: обычно нет без согласия правообладателя.
Как это обычно воспринимает инвестор: могут возникнуть дополнительные вопросы к объёму и условиям лицензии.

Неисключительная лицензия

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

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

Что должно быть в договоре с разработчиком, дизайнером и подрядчиком

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

Минимальный набор условий:

Предмет и состав результата. Не «разработка», а что именно: исходный код и репозиторий, фронтенд и бэкенд, мобильная сборка, макеты UI/UX, спрайты, 3D-модели, треки, тексты. Расплывчатый предмет — прямая дорога к статье 1297.
Отчуждение исключительного права в полном объёме, на весь срок его действия, для всех территорий и всех способов использования, включая переработку и дальнейшую передачу третьим лицам.
Момент перехода. Обычно — момент приёмки результата. Важно, чтобы момент был определён прямо и чтобы способ фиксации приёмки был описан в самом договоре.
Гарантии исполнителя. Результат создан им лично, оригинален, не нарушает прав третьих лиц, не содержит чужих ассетов и open-source-компонентов с несовместимой лицензией без раскрытия.
Ответственность за недостоверность этих гарантий.
Вознаграждение за передачу прав — желательно выделить, а не «растворять» в оплате услуг.

Про открытый код стоит сказать отдельно. Копилефт-лицензии (например, семейство GPL) могут «заражать» ваш продукт требованием раскрыть исходники. Если подрядчик вплёл такой компонент в ядро, проблема всплывёт на due diligence как одна из самых дорогих. Поэтому раскрытие используемых сторонних компонентов и их лицензий стоит вписать в договор как обязанность исполнителя.

Комментарий Futura Digital. Частая ошибка — считать, что достаточно фразы «все права принадлежат заказчику». Но для отчуждения нужны конкретные формулировки про исключительное право и его объём, иначе суд может истолковать условие как лицензию. В соглашениях на разработку ПО мы отдельно проверяем блок про ранее созданные наработки исполнителя (IP-бэкграунд), технологии открытого исходного кода и остаточные знания — именно там чаще всего прячутся дыры.

Как фиксируют приёмку и переход прав

Короткий ответ: закон не требует акта. Требуется, чтобы было видно, какой именно результат принят и когда к компании перешло право на него. Акт — один из способов это показать, и сегодня далеко не единственный.

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

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

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

Здесь и подключается операционная сторона. 4dev.com — платформа для оформления и администрирования работы с распределённой командой исполнителей. Она держит эту цепочку в одном контуре: с каждым исполнителем заключается договор, задачи ставятся с описанием и статусами, по результатам формируются закрывающие документы, а при постановке задачи клиент может закрепить передачу прав на результат. Всё это собирается в единый реестр, где по каждой задаче видно, где право закреплено и подтверждено, а где ещё нет. Один договор с платформой заменяет десятки прямых договоров, а в бухгалтерии остаётся один контрагент и один тип закрывающего документа.

Важная оговорка: 4dev.com отвечает за документальную сторону — договоры, задачи, результаты, приёмку, закрепление прав и реестр. Юридическую корректность формулировок и структуру владения оценивает юрист; в этом материале правовой слой берёт на себя Futura Digital.

Как собрать права по распределённой gamedev-команде

Короткий ответ: разложить продукт на вклады — код, арт, музыка, ассеты, персонажи, интерфейсы, тексты — и по каждому вкладу пройти одну и ту же цепочку: договор → задача → результат → приёмка → отчуждение прав.

Игра или IT-продукт почти никогда не создаются одним человеком. Художники, композиторы, аутсорс-студии, фрилансеры в разных странах — у каждого свой кусок и свой правовой статус. Разберём типовые вклады.

Код (бэкенд, фронтенд, мобильная сборка). Основной актив. Нужно отчуждение по каждому подрядчику плюс контроль компонентов с открытым исходным кодом.
Арт, 3D, анимация, ассеты. Авторское право на изображения; отчуждение обязательно, иначе издатель не примет.
Музыка и звук. Отдельные права на произведение и на фонограмму; со звукорежиссёром и композитором оформляются разные документы.
Персонажи. Визуальный образ охраняется авторским правом с момента создания. «Запатентовать персонажа», как часто спрашивают, нельзя — патент выдают на изобретения, полезные модели и промышленные образцы. Название и логотип игры защищают как товарный знак. То есть у персонажа обычно связка: авторское право на образ плюс, по желанию, товарный знак на имя.
UI/UX-дизайн. Макеты и элементы интерфейса — тоже произведения; отчуждение оформляется так же, как на арт.
Тексты, лендинги, рекламные креативы. Часто забывают: если баннер или ролик сделал подрядчик без передачи прав, использовать его в кампании — уже риск.

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

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

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

IP due diligence: что спросит инвестор и какие red flags он видит

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

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

Красные флаги, которые видит инвестор:

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

Если права на ядро продукта нельзя подтвердить документами, компания не вполне владеет тем, что продаёт. Поэтому дыры лучше видеть заранее, на своём реестре, до чужого due diligence.

В этой части операционный реестр и правовая экспертиза работают в паре. Единый реестр по исполнителям и задачам (его ведёт 4dev.com) показывает статус прав по каждому вкладу и делает подрядную часть готовой к аудиту и due diligence до того, как её спросят. А оценку структуры владения и рисков — то, что нельзя свести к операционной галочке, — проводит юрист.

Комментарий Futura Digital. На due diligence мы смотрим и наличие договоров, и их содержание: реально ли передано исключительное право, покрыты ли все вклады, чист ли open-source. Отдельный блок — структура владения: где юридически «лежит» ИС, совпадает ли это с операционной компанией и планами по налоговым режимам. Разрыв между «кто разрабатывал» и «кто владеет» — самая частая причина, по которой сделка буксует.

IP Box и льготные режимы: при чём тут документы

Короткий ответ: IP Box — это льготный налоговый режим для дохода от интеллектуальной собственности. Применить его можно только к той ИС, которой компания действительно владеет, — а владение подтверждается той самой цепочкой договоров, отчуждений и подтверждённой приёмки. Нет оформленной передачи прав от исполнителей — нет и основания для льготы.

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

С точки зрения 4dev.com здесь всё про документальную базу: платформа помогает собрать по каждому исполнителю договор, закрепление передачи прав и подтверждение приёмки, а реестр показывает, что права закреплены и подтверждены. Саму налоговую структуру, условия режима и подачу документов оценивает налоговый и юридический консультант — это не операционная задача платформы.

Комментарий Futura Digital. Кипр — один из популярных вариантов для IT- и gamedev-компаний из-за режима IP Box: при выполнении условий эффективная ставка на квалифицируемый доход от интеллектуальной собственности снижается ощутимо ниже стандартной ставки налога на прибыль. Но режим требует, чтобы у компании была экономическая собственность на актив, а она доказывается документами о правах, и учитывает связь между расходами на разработку и льготируемым доходом (nexus-подход). На практике мы часто видим обратный порядок: структуру уже построили, а передача прав от подрядчиков не оформлена — и тогда льготу невозможно обосновать при проверке. Поэтому документальную базу собираем заранее, до построения структуры. Конкретные ставки и условия зависят от текущего законодательства и ситуации компании — это тема отдельной консультации.

Как 4dev.com помогает с документами по работе с исполнителями

Короткий ответ: 4dev.com ставит на поток документооборот по подрядчикам — от договора до приёмки и закрепления прав — и собирает всё в один реестр, готовый к проверкам.

Что закрывает платформа:

Один договор вместо сотен. Компания работает с командой, а договорная обвязка с исполнителями остаётся в контуре платформы.
Самостоятельное подключение исполнителя с верификацией: человек проходит шаги сам, платформа проверяет документы и отвечает на его вопросы, не нагружая вашу команду.
Задачи, результаты, приёмка, закрывающие документы в одном процессе, со статусами в реальном времени.
Закрепление передачи прав на результат — по выбору клиента, при постановке задачи; факт фиксируется документально.
Единый реестр по всем исполнителям и задачам: видно, где права закреплены и подтверждены, а где есть пробел. Готовность к аудиту и due diligence.
Ролевая модель и API для команд, которым нужны разграничение доступа и интеграция с внутренними системами.

Чем 4dev.com не является, важно проговорить прямо: это платформа для работы с подрядчиками. Оформление служебных произведений сотрудников, налоговые режимы и правовую экспертизу договоров закрывает не платформа, а профильные специалисты — в этом материале правовую часть ведёт Futura Digital.

Частые ошибки

Считать, что оплата автоматически передаёт права.
Полагаться на «по умолчанию» вместо прямого условия об отчуждении.
Формулировать передачу как «все права у заказчика» без указания на исключительное право и его объём.
Не оставлять никаких следов приёмки: ни закрывающих документов, ни статусов в трекере, ни истории коммитов.
Не проверять open-source и сторонние ассеты.
Откладывать оформление «на потом» — и пытаться проставить в документах прошедшую дату, когда исполнитель уже недоступен.
Строить международную структуру и режим IP Box раньше, чем закрыты документы по правам.

FAQ

Достаточно ли оплатить работу исполнителя, чтобы права перешли компании?

Нет. Оплата закрывает расчёт по договору, но исключительное право переходит только при наличии условия об отчуждении и подтверждённого перехода по конкретному результату. В ряде сценариев (ст. 1297 ГК РФ) право по умолчанию вообще остаётся у исполнителя.

Чем передача прав отличается от лицензии?

При отчуждении (ст. 1234) право уходит к вам целиком и навсегда. При лицензии (ст. 1235) право остаётся у автора, а вам разрешают пользоваться результатом в оговорённых пределах. Для ядра продукта нужно отчуждение.

Нужен ли отдельный договор отчуждения или хватит пункта в основном договоре?

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

Нужен ли акт для передачи прав на код или дизайн?

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

Кому принадлежат права на код, если его написал внешний разработчик?

Зависит от договора. Если создание кода — прямой предмет договора заказа (ст. 1296), право по умолчанию у заказчика; если результат «побочный» (ст. 1297) — у подрядчика. Чтобы не гадать, отчуждение прописывают явно.

Кому принадлежат права на код, написанный с помощью ИИ?

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

Что делать, если старые договоры не содержат передачу прав?

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

Разработчик ушёл, а документы по правам не подписаны. Что делать?

Попытаться оформить отчуждение постфактум — тем же допсоглашением с ретроактивной оговоркой; если контакт потерян — оценить с юристом реальные риски и варианты (переписать спорный модуль, ограничить его роль в продукте, раскрыть покупателю). Универсального «починить одним документом» здесь нет.

Как оформить права на игру, если её делала распределённая команда?

Разложить продукт на вклады (код, арт, музыка, персонажи, интерфейсы, тексты) и по каждому пройти цепочку договор → задача → результат → приёмка → отчуждение. Единый реестр по исполнителям сильно упрощает сборку — этим и помогает 4dev.com.

Как связаны задача, результат, приёмка и передача прав?

Это одна цепочка: задача описывает, что нужно; результат — что сдано; приёмка фиксирует, что результат принят и когда; передача прав закрепляет, что исключительное право на этот результат перешло к компании. Разрывать её опасно — тогда право нельзя привязать к конкретному вкладу.

Можно ли применять IP Box, если права от исполнителей оформлены не полностью?

Рискованно. Льготный режим применяют к ИС, которой компания владеет документально; пробел в передаче прав подрывает основание для льготы. Документы собирают до построения структуры.

Нужно ли регистрировать авторское право на код?

Нет, охрана возникает автоматически с момента создания (ст. 1259 ГК РФ). Добровольная регистрация программы в Роспатенте (ст. 1262) и git-история помогают доказывать авторство и дату, но обязательными не являются.

Чем помогает 4dev.com, а чем — Futura Digital?

4dev.com берёт операционную сторону: договоры с исполнителями, задачи, результаты, приёмку, закрепление передачи прав и единый реестр, готовый к проверкам. Futura Digital закрывает правовой слой: проверка договоров, структура владения правами, IP due diligence и налоговые режимы вроде IP Box.

Итог и чек-лист

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

Чек-лист перед следующим раундом или релизом:

по каждому исполнителю есть письменный договор;
в договоре — условие об отчуждении исключительного права в полном объёме;
в договоре описано, что считается приёмкой и где она фиксируется;
по каждому переданному результату есть след приёмки: закрывающий документ, статус в трекере, коммит или загрузка файлов;
раскрыты и проверены open-source-компоненты и сторонние ассеты;
закрыты старые договоры без передачи прав — допсоглашением с ретроактивной оговоркой;
права на ядро продукта задокументированы до построения международной структуры и режима IP Box;
есть единый реестр, где по каждому вкладу виден статус прав.

Источники: Гражданский кодекс РФ, часть четвёртая (ст. 1228, 1229, 1234, 1235, 1259, 1261, 1262, 1288, 1295, 1296, 1297). Юридический комментарий подготовлен Futura Digital. Данные актуальны на момент публикации; законодательство и налоговые режимы могут меняться.