Права на код IT-компании в ОАЭ проверяются по цепочке: кто создал результат, на каком основании он передан подрядчику и какие права получила компания. Оплата счета, доступ к Git и передача архива исходников отвечают на разные вопросы; сами по себе они не заменяют проверку прав.
Этот разбор посвящен работе с разработчиками и студиями: выбору правового режима, составу результата, передаче прав и приемке. Лицензирование и налоги при запуске рассмотрены в отдельной статье об IT-компании в Дубае.
Сначала разделите три результата сделки
| Результат | Что он подтверждает | Чего он сам по себе не решает |
|---|---|---|
| Передача кода и доступов | Получены файлы, репозиторий, сборка и управление инфраструктурой | Кто вправе изменять и коммерчески использовать компоненты |
| Приемка этапа | Результат проверен по согласованным критериям | Переданы ли нужные имущественные права и нет ли чужих компонентов |
| Передача прав или лицензия | Определены разрешенные способы использования | Работает ли продукт, воспроизводится ли сборка, переданы ли секреты доступа |
Закройте все три части в договоре и документах исполнения. Например, акт о приемке экрана приложения не описывает права на серверный модуль, а право использовать модуль не гарантирует возможность собрать продукт без аккаунта студии.
Mainland, DIFC и ADGM: не переносите одно правило на все договоры
В федеральном режиме ориентир — Декрет-закон 38/2021 об авторском праве. Статья 28 содержит правила по умолчанию для результата в пользу другого лица и произведения работника, с возможностью иного письменного соглашения. Для работника учитываются связь с бизнесом, поручение и использование ресурсов работодателя. Поэтому неверны обе крайности: «подрядчик всегда сохраняет права» и «оплата любой работы автоматически закрывает все вопросы».
| Режим | Что проверить | Практический вывод |
|---|---|---|
| Применимое федеральное право | Статьи 9 и 28, договор автора, характер заказа и трудовые обязанности | Сопоставить условия по умолчанию с письменными условиями и доказательствами создания |
| DIFC | IP Law 4/2019 и факты employment/work-for-hire; возможное письменное отступление | Не ограничиваться шаблоном для mainland; описать задачи и договорное распределение |
| ADGM | Собственный civil/commercial framework, право договора и применимые нормы к охране результата | Не считать правила DIFC или любой английский закон автоматически перенесенными в ADGM |
Различия DIFC изложены в официальном руководстве по IP Law. ADGM объясняет основу своего правового режима отдельно. Если разработчик находится в другой стране, дополнительно проверяются его трудовые отношения и применимые обязательные нормы. Оговорка о праве договора не позволяет игнорировать всю эту цепочку.
Кто должен подтвердить права: физлицо, студия или субподрядчик
Составьте список создателей и участников: штатный разработчик, фрилансер, агентство, привлеченная студией команда. Если договор подписывает студия, запросите подтверждение ее оснований распоряжаться работой людей. Документы должны охватывать нужный результат, а не лишь название проекта.
- Сопоставьте автора, работодателя или заказчика и компанию, передающую результат.
- Проверьте трудовые задачи, подрядные договоры, письменные передачи и ограничения.
- Уточните, разрешены ли субподрядчики и кто отвечает за пробелы в цепочке прав.
- Отделите созданное для проекта от ранее разработанных библиотек и материалов заказчика.
Для небольшого проекта список может быть коротким, но его стоит зафиксировать до последнего платежа. Обещание студии «все права принадлежат студии» без перечня компонентов и договорных подтверждений сложно проверить при инвестиционной или покупательской проверке.
Как описать передачу имущественных прав
По статье 9 федерального закона передача или лицензирование имущественных прав оформляется письменно с указанием права, цели, срока и места использования; прямо не переданные права сохраняются за автором. Закон ограничивает распоряжение всем будущим интеллектуальным продуктом автора. Формулу «все права на все когда-либо созданное» нельзя использовать вместо точного описания проекта.
В приложении укажите версии и части результата, способы использования, территории, срок, исключительность и возможность передачи прав дальше. Для SaaS обсудите эксплуатацию сервиса, доработку, подключение других подрядчиков и передачу бизнеса. Для поставки продукта клиенту — какие права компания сможет предоставить этому клиенту. Это вопросы для согласования, а не универсальная формулировка на один абзац.
Отдельно согласуйте момент перехода: после оплаты этапа, приемки или другого события, допустимого по применимому праву. Сверьте его с правом использовать промежуточный результат, исправлять дефекты и завершать проект при споре. Если передается только лицензия на прежний модуль студии, ограничения этой лицензии должны позволять намеченную эксплуатацию.
Открытые библиотеки и сторонние материалы
Попросите перечень зависимостей: библиотеки, SDK, шрифты, изображения, шаблоны, платные API и сервисы. Для каждой позиции отметьте версию, источник, лицензию, обязательные уведомления и ограничения. Наличие компонента в публичном репозитории не означает отсутствия условий использования.
Согласуйте порядок добавления новых зависимостей и проверку несовместимых условий. Если подрядчик использует генеративные инструменты, отдельно обсудите разрешенные данные для ввода, условия инструмента и проверку результата. Сам факт генерации не подтверждает оригинальность и чистоту всех прав. Здесь требуется анализ конкретного инструмента и материала, а не гарантия «код без чужих прав».
Приемка: привяжите акт к проверяемой версии
| Вопрос | Что зафиксировать |
|---|---|
| Что передано | Репозиторий, commit/tag, исходники, инструкции сборки, документация и перечень зависимостей |
| Как проверяется | Тестовый сценарий, среда, критерии соответствия, порядок фиксации дефектов |
| Что означает подпись | Принят конкретный объем; отдельно определены права, гарантийные обязанности и нерешенные замечания |
| Что при прекращении | Передача промежуточного результата, доступов и документации, оплата принятого объема, дальнейшее использование |
Перед завершением попросите другого инженера воспроизвести сборку по документации. Если без личного аккаунта подрядчика это невозможно, организационная передача еще не завершена. Доступы к облаку и секретам передаются безопасным способом; пароли не включаются в публичный акт.
Договор и доказательства нужно проверять вместе
Для договоров в применимом федеральном режиме учитывайте новый Civil Transactions Law: он действует с 1 июня 2026 года и заменил Закон 5/1985. Старый шаблон со ссылками на прежние статьи нельзя считать актуальным без проверки. Применимое право и действие норм во времени определяются по конкретному договору.
Храните договор, задания, изменения, согласования зависимостей, акты и подтверждение оплаты в связи с версиями кода. При расхождении важны не только названия файлов, но и содержание поручения, исполнения и распределения прав. Не обещайте инвестору полную цепочку, пока не проверены участники и исключения.
В Taxers можно обсудить юридическую помощь IT-бизнесу и подготовку договоров. Для проекта в ОАЭ подготовьте схему команды, договоры, перечень результатов и сторонних компонентов. Применимость услуги, юрисдикция и объем проверки согласуются отдельно.
FAQ
Достаточно ли счета и акта об оплате?
Она подтверждает расчет, но не раскрывает весь состав прав и компонентов. Проверяются закон, письменные условия, создание результата и договорная цепочка.
Можно ли получить исключительные права на все библиотеки?
Нет общего такого правила. Сторонняя библиотека может использоваться по собственной лицензии; договор должен различать новый результат и допустимое использование чужих компонентов.
