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

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

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

В последние годы, по данным аналитических агентств, объем мирового рынка разработки ПО превысил 500 миллиардов долларов США и продолжает расти двузначными темпами. В России этот рынок также демонстрирует устойчивую положительную динамику, несмотря на внешние вызовы. Это обусловливает острую необходимость в глубоком понимании механизмов правового регулирования, которые обеспечивают эффективность, прозрачность и защиту интересов всех сторон, участвующих в процессе создания цифровых решений.

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

Для достижения поставленной цели были сформулированы следующие задачи:

1. Раскрыть правовую природу и сущность контракта на разработку ПО, определить его место в системе гражданско-правовых договоров.
2. Выявить ключевые элементы и существенные условия, без которых договор может быть признан незаключенным или недействительным.
3. Проанализировать вопрос интеллектуальных прав на создаваемое ПО: от момента их возникновения до передачи и лицензирования.
4. Детально рассмотреть аспекты качества, сроков и стоимости разработки, а также механизмы их контроля и изменения.
5. Изучить особенности процесса приемки-передачи ПО, включая тестирование и устранение дефектов.
6. Выявить основные риски для заказчика и разработчика при заключении и исполнении контракта, а также предложить способы их минимизации.
7. Рассмотреть особенности разрешения споров и ответственности сторон.
8. Обозначить актуальные проблемы и перспективы развития правового регулирования контрактов на разработку ПО в РФ.

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

Правовая природа и сущность контракта на разработку программного обеспечения

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

Место контракта на разработку ПО в системе гражданско-правовых договоров

Традиционно контракт на разработку программного обеспечения рассматривается как договор подряда или договор возмездного оказания услуг в соответствии с положениями Гражданского кодекса Российской Федерации (ГК РФ). Выбор конкретного типа договора зависит от характера предмета и ожидаемого результата.

Если результатом деятельности разработчика является создание нового, индивидуально-определенного программного продукта (программа для ЭВМ, база данных), который имеет материальное выражение (даже если оно лишь на носителях или в облаке) и может быть передан заказчику, то наиболее подходящей квалификацией является договор подряда (Глава 37 ГК РФ). В этом случае ключевым аспектом является достижение конкретного, овеществленного результата, обладающего определенными свойствами и функциями, который затем будет передан заказчику. Заказчик, в свою очередь, получает право собственности на этот продукт или исключительное право на его использование.

В тех случаях, когда речь идет о консультационных услугах, технической поддержке, кастомизации существующего ПО без создания нового объекта интеллектуальной собственности, или абонентском обслуживании, контракт скорее будет квалифицироваться как договор возмездного оказания услуг (Глава 39 ГК РФ). Здесь акцент делается на процессе деятельности, а не на конечном материальном результате. Однако на практике большинство контрактов на разработку ПО сочетают в себе элементы обоих видов, что иногда приводит к сложностям в квалификации и применении норм. Судебная практика нередко приходит к выводу о смешанном характере таких договоров.

Важно также упомянуть о договоре авторского заказа (ст. 1288 ГК РФ), который является специфическим видом договора, регулирующим создание произведения науки, литературы или искусства по заказу. Поскольку программы для ЭВМ и базы данных охраняются как литературные произведения, договор авторского заказа теоретически может применяться. Однако на практике он используется реже, чем подряд или услуги, поскольку его положения не всегда адекватно отражают сложный, многоэтапный и коллективный характер разработки ПО, а также специфику передачи исключительных прав. Осознание этого нюанса позволяет избежать неоправданного усложнения договорной структуры.

Специфика предмета контракта: программное обеспечение как объект правоотношений

Программное обеспечение, будучи продуктом интеллектуального труда, обладает рядом уникальных характеристик, которые формируют специфику его правового регулирования:

1. Нематериальность: ПО само по себе не имеет физической формы, оно проявляется в коде, алгоритмах и функциональных возможностях. Это отличает его от традиционных объектов договора подряда, таких как здание или станок.
2. Двойственная природа: ПО является одновременно и объектом интеллектуальной собственности (программа для ЭВМ или база данных, охраняемая авторским правом), и товаром/услугой в гражданском обороте. Эта двойственность требует особого внимания к регулированию исключительных прав.
3. Сложность и многокомпонентность: Современное ПО зачастую представляет собой сложную систему, состоящую из множества модулей, библиотек, интерфейсов, баз данных, что усложняет его описание, тестирование и оценку.
4. Динамичность и изменчивость: Разработка ПО – это итеративный процесс, в ходе которого требования могут меняться, что требует гибкости в договорных отношениях и механизмов внесения изменений.
5. Возможность воспроизведения и распространения: В отличие от физических объектов, ПО может быть легко скопировано и распространено, что делает вопросы защиты авторских прав критически важными.

В контексте российского законодательства, программа для ЭВМ (ст. 1261 ГК РФ) и база данных (ст. 1260 ГК РФ) охраняются как объекты авторского права. Это означает, что на них распространяется правовой режим, аналогичный литературным произведениям. Авторское право на ПО возникает в силу факта его создания и не требует регистрации, хотя регистрация в Роспатенте возможна и может служить дополнительным доказательством авторства и даты создания.

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

Существенные условия и ключевые положения договора

Как любой гражданско-правовой договор, контракт на разработку ПО должен содержать существенные условия, без которых он будет считаться незаключенным. Для договора подряда существенными являются предмет и срок (ст. 702 ГК РФ). Для договора возмездного оказания услуг — также предмет и срок (ст. 779 ГК РФ).

1. Предмет договора: Это наиболее важный и сложный элемент. Он должен максимально точно описывать, что именно должно быть разработано.
   • Для ПО это означает детальное описание функциональных требований, технических характеристик, архитектуры, используемых технологий, языка программирования, а также ожидаемого результата (например, веб-приложение для электронной коммерции, мобильное приложение для учета товаров, корпоративная информационная система).
   • Часто предмет договора детализируется в техническом задании (ТЗ), которое является неотъемлемой частью контракта. ТЗ должно быть максимально подробным и однозначным, чтобы исключить разночтения и споры на этапе исполнения. В нем указываются:
     • Цели и задачи создания ПО.
     • Функциональные и нефункциональные требования (производительность, безопасность, удобство использования).
     • Стек технологий и используемые стандарты.
     • Требования к интерфейсу пользователя.
     • Объем работ и этапы разработки.
     • Требования к документации (пользовательская, техническая).
2. Срок исполнения: Должен быть четко определен. Это может быть как общий срок выполнения всех работ, так и поэтапные сроки с указанием дат начала и окончания каждого этапа. В IT-проектах, особенно крупных, часто используется поэтапный подход с промежуточными актами сдачи-приемки.
3. Цена договора: Хотя цена не является существенным условием для подряда или услуг, ее отсутствие на практике приводит к неопределенности и спорам. Цена может быть твердой (фиксированной), приблизительной или рассчитываться по модели «time & material» (потраченное время и материалы). Для крупных проектов часто предусматривается поэтапная оплата или оплата по достижении определенных вех.
4. Интеллектуальные права: Один из наиболее критичных аспектов. Контракт должен четко определять, кому принадлежат исключительные права на созданное ПО:
   • Переходят ли исключительные права к заказчику в полном объеме?
   • Приобретает ли заказчик лицензию на использование ПО? Если да, то какая это лицензия (простая неисключительная, исключительная), на какой срок, на какой территории и в каких пределах?
   • Принадлежат ли какие-либо права разработчику, например, на используемые им библиотеки или фреймворки?
   • Важно также урегулировать вопросы, связанные с исходным кодом, передачей прав на внесение изменений и доработок.
5. Порядок сдачи-приемки работ: Должен быть детально описан, включая процедуры тестирования, устранения дефектов, сроки рассмотрения актов и подписания.
6. Ответственность сторон: За нарушение сроков, качества, конфиденциальности, непередачу прав. Обычно предусматриваются штрафы, пени, возмещение убытков.
7. Конфиденциальность: Часто разработка ПО связана с доступом к чувствительной информации заказчика, поэтому положения о неразглашении конфиденциальных данных являются обязательными.

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

Интеллектуальные права на программное обеспечение

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

Возникновение и правовая охрана программ для ЭВМ и баз данных

В российском законодательстве программы для ЭВМ и базы данных охраняются как литературные произведения (статьи 1260, 1261 Гражданского кодекса РФ). Это означает, что на них распространяется весь комплекс норм авторского права.

Авторское право на программу для ЭВМ или базу данных возникает в момент ее создания. Для этого не требуется никакая регистрация, депонирование или соблюдение иных формальностей. Главное условие — это объективная форма выражения и творческий характер. Исходный код, объектный код, подготовительные материалы (например, блок-схемы, дизайн-документы) — все это является частью охраняемого произведения.

Несмотря на то, что регистрация не является обязательной, Федеральная служба по интеллектуальной собственности (Роспатент) предоставляет возможность государственной регистрации программы для ЭВМ или базы данных. Такая регистрация носит уведомительный характер, но может сыграть важную роль в случае судебных споров, поскольку свидетельство о регистрации будет являться сильным доказательством авторства и даты создания объекта интеллектуальной собственности. Для заказчика наличие такой регистрации может быть дополнительной гарантией его прав, а для разработчика — подтверждением его компетенций и добросовестности.

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

Передача исключительных прав: договорные механизмы

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

В контексте контракта на разработку ПО существует несколько основных механизмов передачи исключительных прав:

1. Договор об отчуждении исключительного права (ст. 1234 ГК РФ): Это наиболее полный способ передачи прав, при котором заказчик становится единственным и полноправным правообладателем на созданное ПО. Исключительное право переходит к заказчику в полном объеме, и разработчик (автор) утрачивает возможность использовать это ПО каким-либо образом, кроме как в специально оговоренных случаях. Такой договор должен быть заключен в письменной форме.
2. Лицензионный договор (ст. 1235 ГК РФ): В этом случае исключительное право остается у разработчика, но он предоставляет заказчику право использования ПО в определенных пределах. Лицензии могут быть:
   • Простая (неисключительная) лицензия: Заказчик получает право использовать ПО, но разработчик сохраняет за собой право предоставлять аналогичные лицензии другим лицам.
   • Исключительная лицензия: Заказчик получает право использования ПО без сохранения за лицензиаром (разработчиком) права выдачи лицензий другим лицам. В этом случае только заказчик имеет право использовать ПО в оговоренных пределах.

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

3. Служебное произведение (ст. 1295 ГК РФ): Если ПО создается штатным сотрудником разработчика в рамках его трудовых обязанностей, то исключительное право на такое произведение изначально принадлежит работодателю (разработчику), если иное не предусмотрено договором между ними. Это значительно упрощает процесс передачи прав от разработчика к заказчику, так как разработчик уже является правообладателем.

Ключевые аспекты, которые должны быть отражены в контракте:

• Четкое указание, кому переходят исключительные права: Это должно быть прописано однозначно, чтобы избежать двусмысленности.
• Момент перехода прав: Обычно связывается с моментом полной оплаты и подписания акта сдачи-приемки работ.
• Объем передаваемых прав: Включает ли он исходный код, документацию, право на модификацию, распространение, создание производных произведений?
• Использование открытого исходного кода (Open Source): Если при разработке используются компоненты с открытым исходным кодом, необходимо четко указать, какие лицензии применяются к этим компонентам (например, GNU GPL, MIT License), и как это влияет на права заказчика. Несоблюдение условий Open Source лицензий может привести к серьезн��м юридическим последствиям.
• Гарантии разработчика: Разработчик должен гарантировать, что созданное ПО является оригинальным, не нарушает прав третьих лиц и соответствует всем заявленным требованиям.

Недостаточная проработка вопросов интеллектуальных прав является одной из наиболее распространенных причин споров в сфере IT-разработки. Заказчик, инвестируя значительные средства, стремится получить полный контроль над продуктом, в то время как разработчик может быть заинтересован в сохранении прав на отдельные модули или наработки для их дальнейшего использования. Баланс этих интересов должен быть тщательно проработан в договоре.

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

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

Формирование требований к качеству и функционалу ПО

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

Ключевые инструменты для формирования требований:

1. Техническое задание (ТЗ): Это основной документ, детально описывающий все аспекты разрабатываемого ПО. ТЗ должно быть максимально полным, однозначным и исключать двойные толкования. В нем прописываются:
   • Функциональные требования: Что именно должна делать программа (например, «система должна позволять пользователю регистрировать заказы», «приложение должно отображать аналитику продаж»).
   • Нефункциональные требования: Как должна работать программа (например, «система должна обрабатывать не менее 1000 запросов в секунду», «время отклика не должно превышать 2 секунды», «приложение должно быть совместимо с операционными системами iOS 15+ и Android 10+»).
   • Требования к производительности, безопасности, надежности, удобству использования (юзабилити).
   • Архитектурные требования: Используемые технологии, языки программирования, базы данных, сторонние сервисы, интеграции.
   • Требования к интерфейсу пользователя (UI/UX).
   • Требования к документации: Какая документация должна быть предоставлена (пользовательские руководства, техническая документация, описание API).
   • Критерии приемки: Четкие метрики, по которым будет оцениваться соответствие готового продукта заявленным требованиям.

   ТЗ, как правило, является неотъемлемой частью контракта и прикладывается к нему. Любые изменения в ТЗ должны оформляться дополнительными соглашениями.

2. Проектная документация: Кроме ТЗ, могут быть разработаны и другие документы, детализирующие требования: спецификации требований (SRS), пользовательские истории (user stories), макеты интерфейсов (wireframes), прототипы. Все эти документы должны быть согласованы и утверждены обеими сторонами.

Обеспечение качества:

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

• Этапы разработки и промежуточная приемка: Разделение проекта на этапы с регулярной сдачей и приемкой результатов позволяет выявлять и устранять дефекты на ранних стадиях.
• Методологии тестирования: Указание на виды тестирования (функциональное, нагрузочное, интеграционное, юзабилити) и кто их проводит.
• Гарантийный период: После сдачи и приемки ПО должен быть установлен гарантийный период, в течение которого разработчик обязуется устранять выявленные ошибки и дефекты за свой счет.

Установление сроков и их гибкое управление

Сроки — это один из самых чувствительных параметров в IT-проектах. Несоблюдение сроков может привести к серьезным финансовым потерям для заказчика и испортить репутацию разработчика.

Основные подходы к установлению сроков:

• Фиксированные сроки: Указывается дата начала и дата окончания всего проекта, а также даты окончания промежуточных этапов. Этот подход чаще используется для проектов с четко определенным и стабильным ТЗ.
• Гибкие сроки: Применяются в проектах, использующих гибкие методологии разработки (Agile, Scrum). В этом случае фиксируются сроки для итераций (спринтов), а общий срок проекта может быть более динамичным, зависящим от бэклога и приоритетов.

Механизмы управления сроками:

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

Определение стоимости и порядок расчетов

Цена контракта на разработку ПО может быть сформирована по-разному, и выбор оптимальной модели зависит от уровня определенности требований и предпочтений сторон.

Основные модели формирования стоимости:

1. Фиксированная цена (Fixed Price): Заказчик платит заранее оговоренную сумму за весь объем работ. Эта модель подходит для проектов с очень четко определенным ТЗ и минимальной вероятностью изменений. Риск перерасхода несет разработчик.
2. Time & Material (T&M): Оплата производится за фактически отработанное время сотрудников разработчика и использованные материалы (лицензии, сторонние сервисы). Эта модель обеспечивает гибкость и подходит для проектов с меняющимися требованиями или на ранних стадиях, когда ТЗ еще не до конца сформировано. Риск перерасхода несет заказчик.
3. Смешанные модели: Комбинация Fixed Price для определенных этапов и T&M для других, или Fixed Price с опцией T&M для дополнительных работ.

Порядок расчетов:

• Предоплата: Частичная оплата до начала работ.
• Поэтапная оплата: Оплата по завершении каждого этапа после подписания акта сдачи-приемки. Это наиболее распространенный и безопасный для обеих сторон подход, так как он привязывает оплату к фактическому результату.
• Окончательный расчет: Производится после полной сдачи всего проекта и подписания финального акта.

Что важно учесть в контракте:

• Валюта расчетов и порядок пересчета: Если цена указана в иностранной валюте, но расчеты производятся в рублях, необходимо четко определить курс пересчета (например, курс ЦБ РФ на дату оплаты).
• НДС: Указать, включен ли НДС в стоимость.
• Дополнительные расходы: Определить, кто несет расходы на лицензии, сторонние сервисы, командировки, если они требуются.
• Изменение стоимости: Процедура пересмотра цены в случае изменения объема работ или других условий, требующих дополнительных затрат (например, согласование допсоглашения).

Примерная структура оплаты по этапам может выглядеть так:

• 20% — по подписании контракта и утверждении ТЗ.
• 30% — по завершении этапа проектирования и утверждении архитектуры.
• 30% — по завершении этапа разработки основных модулей и прохождения приемочного тестирования.
• 20% — по завершении всего проекта, подписании финального акта сдачи-приемки и передаче всей документации.

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

Приемка-передача программного обеспечения: от тестирования до устранения дефектов

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

Процедура сдачи-приемки работ и ее этапы

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

1. Уведомление о готовности: Разработчик, завершив очередной этап работ или весь проект в целом, направляет заказчику уведомление о готовности к сдаче. К уведомлению прилагается акт сдачи-приемки работ и, при необходимости, другая сопроводительная документация (например, инструкции по установке, описание тестовых сценариев).
2. Передача документации и материалов: Разработчик передает заказчику все необходимое для приемки: исходный код, объектный код, скомпилированные версии ПО, техническую и пользовательскую документацию, результаты тестирования.
3. Приемочное тестирование (тестирование заказчиком): Заказчику предоставляется определенный срок (например, 10-15 рабочих дней, как это часто встречается на практике) для проведения собственного тестирования разработанного ПО на соответствие требованиям, изложенным в техническом задании. Это тестирование может включать:
   • Функциональное тестирование: Проверка всех заявленных функций.
   • Интеграционное тестирование: Проверка взаимодействия с другими системами.
   • Тестирование производительности: Оценка скорости работы и обработки данных.
   • Юзабилити-тестирование: Оценка удобства и интуитивности интерфейса.
4. Составление акта сдачи-приемки: По результатам тестирования заказчик либо подписывает акт сдачи-приемки без замечаний, либо направляет разработчику мотивированный отказ от подписания акта с перечнем выявленных недостатков (дефектов).

Выявление и устранение дефектов: гарантийные обязательства

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

Основные положения, регулирующие дефекты:

1. Перечень дефектов (баг-репорт): Если заказчик выявляет недостатки, он составляет акт с перечнем дефектов. В идеале, этот перечень должен быть структурирован и содержать следующую информацию по каждому дефекту:
   • Описание дефекта.
   • Шаги для воспроизведения.
   • Ожидаемое поведение.
   • Фактическое поведение.
   • Скриншоты или видео (при необходимости).
   • Присвоенный приоритет (критический, высокий, средний, низкий).
2. Сроки устранения дефектов: Контракт должен устанавливать сроки, в течение которых разработчик обязуется устранить выявленные дефекты. Эти сроки могут зависеть от приоритета дефекта (например, критические — 24 часа, высокие — 3 дня, средние — 7 дней).
3. Повторная приемка: После устранения дефектов разработчик вновь уведомляет заказчика о готовности, и процедура приемки повторяется.
4. Гарантийный период: После окончательной сдачи-приемки ПО (подписания финального акта) начинается гарантийный период. В течение этого периода разработчик обязуется устранять любые выявленные дефекты, которые не были обнаружены в процессе приемочного тестирования, за свой счет. Длительность гарантийного периода может варьироваться (от 3 месяцев до 1 года) и должна быть четко прописана в договоре. В течение этого срока, если иное не установлено договором, заказчик может в одностороннем порядке требовать устранения дефектов.
5. Классификация дефектов: Иногда контракт предусматривает классификацию дефектов по степени их критичности и устанавливает разные правила для их устранения. Например, наличие критических дефектов может быть основанием для отказа от приемки всего этапа, тогда как незначительные дефекты могут быть зафиксированы, но не препятствовать подписанию акта, с условием их устранения в оговоренный срок.

Последствия отказа от приемки

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

• Задержка оплаты: До момента подписания акта заказчик может приостановить оплату соответствующего этапа работ.
• Штрафные санкции: Если отказ от приемки обусловлен существенными нарушениями со стороны разработчика (например, неработоспособность ключевого функционала), это может повлечь за собой применение штрафных санкций, предусмотренных контрактом.
• Расторжение договора: В случае систематических или неустранимых дефектов, либо длительной невозможности сдать работу, заказчик может иметь право на расторжение договора и взыскание убытков.

С другой стороны, если заказчик необоснованно уклоняется от приемки или не предоставляет мотивированный отказ в установленные сроки, это может быть приравнено к приемке работ. Контракт должен предусматривать, что в таком случае акт считается подписанным, а работы принятыми. Как же избежать этих последствий, если одна из сторон демонстрирует недобросовестность?

Пример формулировки в контракте:

Заказчик обязуется рассмотреть переданные результаты работ и подписать акт сдачи-приемки или предоставить мотивированный отказ в течение 10 (Десяти) рабочих дней с даты получения уведомления от Исполнителя. В случае непредставления мотивированного отказа в указанный срок, работы считаются принятыми Заказчиком в полном объеме, а Акт сдачи-приемки подлежит подписанию Заказчиком.

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

Риски и ответственность сторон: минимизация угроз в процессе разработки ПО

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

Основные риски для заказчика и разработчика

Риски для Заказчика:

1. Несоответствие ПО ожиданиям/требованиям: Разработанное ПО не выполняет заявленных функций, работает некорректно или не соответствует нефункциональным требованиям (производительность, безопасность).
   • Причина: Недостаточно детальное ТЗ, неверное понимание требований разработчиком, отсутствие эффективного контроля качества.
2. Срыв сроков: Задержка сдачи проекта или отдельных этапов, что приводит к упущенной выгоде, задержке запуска продуктов или сервисов.
   • Причина: Недооценка сложности, отсутствие необходимых ресурсов, изменение требований, неэффективное управление проектом.
3. Увеличение стоимости: Проект выходит за рамки первоначального бюджета.
   • Причина: Изменение требований, скрытые работы, некорректная оценка, модель T&M без жесткого контроля.
4. Неполучение исключительных прав: Разработчик не передает (или передает не полностью) исключительные права на ПО, что ставит под угрозу его дальнейшее использование и коммерциализацию.
   • Причина: Нечеткие формулировки в контракте, использование сторонних библиотек без надлежащих лицензий, спор об авторстве.
5. Неработоспособность ПО после внедрения: ПО функционирует некорректно в реальной производственной среде, что может привести к сбоям в бизнес-процессах.
   • Причина: Недостаточное тестирование, несовместимость с инфраструктурой заказчика, ошибки в коде.
6. Нарушение конфиденциальности: Разработчик разглашает конфиденциальную информацию заказчика.
   • Причина: Отсутствие или несоблюдение NDA (соглашения о неразглашении).
7. Зависимость от разработчика (Vendor Lock-in): Сложность перехода к другому разработчику или самостоятельной поддержке из-за отсутствия документации, доступа к исходному коду или специфических технологий.

Риски для Разработчика:

1. Несвоевременная оплата или отказ от оплаты: Заказчик задерживает платежи или полностью отказывается от них.
   • Причина: Неудовлетворенность качеством, финансовые трудности заказчика, необоснованный отказ от приемки.
2. Частые изменения требований (Scope Creep): Заказчик постоянно вносит новые требования, не желая оплачивать дополнительные работы.
   • Причина: Недостаточная проработка ТЗ, отс��тствие четкой процедуры управления изменениями.
3. Необоснованный отказ от приемки: Заказчик отказывается подписывать акты без веских причин, затягивая процесс.
   • Причина: Некорректное понимание критериев приемки, желание получить дополнительные доработки без оплаты.
4. Некорректное использование ПО заказчиком: Заказчик использует ПО способами, не предусмотренными контрактом, или без соблюдения инструкций, что приводит к сбоям и последующим претензиям к разработчику.
   • Причина: Недостаточная подготовка персонала заказчика, отсутствие обучения.
5. Ответственность за нарушение прав третьих лиц: Если в процессе разработки были использованы компоненты, нарушающие чьи-либо исключительные права.
   • Причина: Недостаточная проверка компонентов, недобросовестность сотрудников.
6. Убытки из-за форс-мажора: Непредвиденные обстоятельства (стихийные бедствия, санкции, пандемии) делают невозможным исполнение обязательств.

Ответственность сторон и способы ее минимизации

Гражданское законодательство РФ предусматривает различные формы ответственности за неисполнение или ненадлежащее исполнение обязательств. В контракте на разработку ПО важно конкретизировать эти нормы.

Виды ответственности:

1. Неустойка (штрафы и пени):
   • За просрочку: Наиболее распространенная форма. Заказчик может потребовать от разработчика уплаты пени за каждый день просрочки (например, 0,1% от стоимости этапа/проекта). Разработчик также может предусмотреть пени за просрочку оплаты со стороны заказчика.
   • За некачественное выполнение: Штраф за выявленные существенные дефекты, которые не были устранены в срок.
   • За нарушение конфиденциальности: Фиксированный штраф за разглашение конфиденциальной информации.
2. Возмещение убытков: Включает реальный ущерб (расходы, которые сторона понесла или должна будет понести) и упущенную выгоду (доходы, которые сторона могла бы получить, если бы обязательство было исполнено надлежащим образом). В IT-контрактах часто ограничивается размер возмещаемых убытков (например, не более стоимости контракта), особенно в части упущенной выгоды, поскольку ее сложно доказать.
3. Расторжение договора: В случае существенного нарушения условий одной из сторон другая сторона может расторгнуть договор и требовать возмещения убытков.

Способы минимизации рисков и ответственности:

1. Детальное ТЗ и управление изменениями:
   • Для заказчика: Максимально полно и однозначно описать требования.
   • Для разработчика: Убедиться, что ТЗ понятно, реально выполнимо и согласовано.
   • Обязательное закрепление процедуры внесения изменений в ТЗ через дополнительные соглашения с пересмотром сроков и стоимости.
2. Поэтапная приемка и оплата: Позволяет заказчику контролировать процесс и минимизировать риски потери всей суммы в случае неудачи. Для разработчика это обеспечивает регулярный приток средств.
3. Четкое регулирование интеллектуальных прав: В договоре об отчуждении прав или лицензионном договоре необходимо подробно прописать, что передается, на каких условиях и в каком объеме.
4. Гарантийные обязательства и SLA (Service Level Agreement):
   • Гарантийный период: Обязательное включение в контракт срока, в течение которого разработчик устраняет дефекты за свой счет.
   • SLA: Если ПО требует дальнейшей поддержки, SLA четко определяет параметры поддержки (время реакции на инциденты, время устранения, доступность системы).
5. Ограничение ответственности: Для разработчика важно предусмотреть в контракте ограничение размера ответственности (например, суммой контракта), за исключением случаев умысла или грубой неосторожности.
6. Конфиденциальность: Заключение отдельного соглашения о неразглашении (NDA) или включение соответствующих положений в основной договор.
7. Форс-мажор: Определение обстоятельств непреодолимой силы, которые освобождают стороны от ответственности за неисполнение обязательств.
8. Выбор правовой системы и порядка разрешения споров: Указание применимого права (российское) и порядка разрешения споров (арбитражный суд, медиация).

Пример ограничения ответственности:

Общая ответственность Исполнителя по настоящему Договору за любое нарушение, а также по всем претензиям в отношении настоящего Договора, не может превышать сумму, равную [указать сумму или процент от стоимости Договора], за исключением случаев умышленного нарушения обязательств или неправомерного использования интеллектуальной собственности.

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

Разрешение споров и судебная практика в сфере разработки ПО

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

Досудебное урегулирование споров: медиация и претензионный порядок

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

1. Претензионный порядок: В большинстве договоров, особенно между юридическими лицами, предусматривается обязательный претензионный порядок. Это означает, что сторона, чьи права нарушены, должна направить письменную претензию другой стороне с изложением своих требований и обоснований. Срок для ответа на претензию (обычно 10-30 дней) также указывается в договоре. Только после соблюдения этого порядка можно обращаться в суд.
   

   Пример формулировки: «Все споры и разногласия, возникающие из настоящего Договора или в связи с ним, подлежат разрешению путем переговоров. В случае невозможности достижения согласия путем переговоров, Стороны обязаны соблюсти досудебный претензионный порядок. Претензия должна быть направлена в письменной форме и рассмотрена в течение 15 (Пятнадцати) рабочих дней с даты ее получения. При неполучении ответа или отказе в удовлетворении претензии, спор может быть передан на рассмотрение в суд».

2. Переговоры и рабочие совещания: Регулярные встречи и переговоры на различных уровнях (проектные менеджеры, руководители отделов, юристы) могут помочь разрешить разногласия до того, как они перерастут в полноценный спор.
3. Медиация: Это относительно новый для России, но активно развивающийся способ альтернативного разрешения споров (Федеральный закон от 27.07.2010 № 193-ФЗ «Об альтернативной процедуре урегулирования споров с участием посредника (процедуре медиации)»). Медиатор — независимое, беспристрастное лицо, которое помогает сторонам найти взаимоприемлемое решение. Медиация может быть особенно эффективна в сложных IT-проектах, где требуется техническая экспертиза и сохранение партнерских отношений.

Судебная практика по контрактам на разработку ПО

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

Типичные категории споров:

1. Споры о качестве ПО и соответствии ТЗ: Одна из самых распространенных категорий. Заказчик утверждает, что ПО не соответствует заявленным требованиям, содержит ошибки или неработоспособно. Разработчик, в свою очередь, может настаивать на выполнении работ в соответствии с ТЗ.
   • Ключевую роль играет: Детализация ТЗ, акты приемки-передачи, результаты тестирования, экспертные заключения. Суды часто назначают судебные экспертизы для оценки качества и функциональности ПО.
   • Пример: Заказчик отказался принимать ПО из-за «многочисленных ошибок». Разработчик представил доказательства соответствия ТЗ, а экспертное заключение показало, что большинство «ошибок» являются либо новыми требованиями заказчика, либо особенностями функционирования, предусмотренными ТЗ. Суд встал на сторону разработчика.
2. Споры о сроках и взыскании неустойки: Заказчик требует уплаты пени за просрочку, разработчик оспаривает факт просрочки или размер неустойки.
   • Ключевую роль играет: Календарный план-график, даты подписания актов, уведомления о готовности, процедура внесения изменений. Суды могут снизить размер неустойки, если она явно несоразмерна последствиям нарушения (ст. 333 ГК РФ).
3. Споры об оплате и неосновательном обогащении: Разработчик требует оплаты за выполненные работы, заказчик отказывается платить. Или, наоборот, заказчик требует возврата аванса из-за невыполнения работ.
   • Ключевую роль играет: Акты сдачи-приемки, доказательства фактического выполнения работ, переписка сторон. Суды часто обращают внимание на то, подписывал ли заказчик акты, даже с замечаниями, или полностью игнорировал их.
4. Споры об интеллектуальных правах: Кто является правообладателем ПО, кто имеет право на его использование, модификацию, распространение.
   • Ключевую роль играет: Четкие формулировки в контракте об отчуждении или лицензировании прав, наличие регистрации ПО в Роспатенте. Суды тщательно анализируют формулировки договора и факт создания ПО в рамках служебного задания.
5. Споры о конфиденциальности: Нарушение условий NDA.
   • Ключевую роль играет: Факт разглашения информации, доказательства ее конфиденциального характера, размер убытков.

Важные выводы из судебной практики:

• Детализация решает: Чем подробнее описаны предмет договора, ТЗ, сроки, критерии приемки, порядок внесения изменений, тем меньше шансов на спор и выше вероятность успешной защиты в суде.
• Документальное оформление: Важно тщательно фиксировать все этапы работ, переписку, протоколы совещаний, акты сдачи-приемки (даже с разногласиями). Электронная переписка может быть признана доказательством, но должна быть правильно оформлена.
• Экспертиза: В сложных технических спорах суды часто прибегают к помощи независимых экспертов для оценки качества ПО, его соответствия ТЗ и определения объема выполненных работ.
• Ограничение ответственности: Суды, как правило, признают условия об ограничении ответственности, если они не противоречат императивным нормам закона и не являются чрезмерно обременительными для одной из сторон.
• Соблюдение претензионного порядка: Несоблюдение досудебного порядка может привести к оставлению иска без рассмотрения.

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

Заключение

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

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

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

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

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

Список использованной литературы

1. Федеральный закон от 25.02.1999 г. № 39-ФЗ «Об инвестиционной деятельности в Российской Федерации, осуществляемой в форме капитальных вложений» (последняя редакция). Документы системы ГАРАНТ. URL: https://base.garant.ru/12114756/ (дата обращения: 13.10.2025).
2. Федеральный закон от 09.07.1999 г. № 160-ФЗ «Об иностранных инвестициях в Российской Федерации». МИД России. URL: https://www.mid.ru/ru/foreign_policy/legal_documents/1559902/ (дата обращения: 13.10.2025).
3. Федеральный закон от 10.12.2003 г. № 173-ФЗ «О валютном регулировании и валютном контроле» (ред. от 30.10.2007 г.). Справочно-правовая система «Консультант плюс».
4. Федеральный закон от 30.12.1995 г. № 225-ФЗ «О соглашениях о разделе продукции» (ред. от 29.12.2004 г.). Справочно-правовая система «Консультант плюс».
5. Федеральный закон от 29.10.1998 г. № 164-ФЗ «О финансовой аренде (лизинге) (ред. от 25.07.2006 г.). Справочно-правовая система «Консультант плюс».
6. Федеральный закон от 29.11.2001 N 156-ФЗ (ред. от 28.12.2024) «Об инвестиционных фондах» (с изм. и доп., вступ. в силу с 01.03.2025). Е-ДОСЬЕ. URL: https://e-dosie.ru/zakon/federalnyj-zakon-ot-29-11-2001-n-156-fz-ob-investicionnyh-fondah-red-ot-28-12-2024-s-izmeneniyami-i-dopolneniyami-vstup-v-silu-s-01-03-2025/ (дата обращения: 13.10.2025).
7. Закон РСФСР от 26.06.1991 г. № 1488-1 «Об инвестиционной деятельности в РСФСР» (ред. от 10.01.2003 г.). Справочно-правовая система «Консультант плюс».
8. Федеральный закон от 05.03.1999 N 46-ФЗ «О защите прав и законных интересов инвесторов на рынке ценных бумаг» (последняя редакция). КонсультантПлюс. URL: https://www.consultant.ru/document/cons_doc_LAW_22247/ (дата обращения: 13.10.2025).
9. Федеральный закон «О рынке ценных бумаг» от 22.04.1996 N 39-ФЗ (последняя редакция). КонсультантПлюс. URL: https://www.consultant.ru/document/cons_doc_LAW_9949/ (дата обращения: 13.10.2025).
10. Богатырев А.Г. Инвестиционное право. М., 1992. 270 с.
11. Богуславский М.М. Иностранные инвестиции: правовое регулирование. М., 1996. 320 с.
12. Бочаров В.В. Финансово-кредитные методы регулирования рынка инвестиций. М.: Финансы и статистика, 1993. 640 с.
13. Бублик В.А. Гражданско-правовое регулирование внешнеэкономической деятельности в РФ: проблемы теории, законотворчества и правоприменения. Екатеринбург: Изд-во УрГЮА, 1999. 286 с.
14. Витрянский В.В. Договор аренды и его виды. М.: Статут, 2000. 420 с.
15. Власова А.Ю. Категория «инвестиции» в российском законодательстве. Внешнеторговое право. 2007. № 1. 65 с.
16. Гильманов Э.М. Инвестиционная деятельность государства в расходах бюджета Российской Федерации. Финансовое право. 2007. № 10. 96 с.
17. Гинатулин А.Р. Паевые инвестиционные фонды как одна из форм привлечения инвестиций. Право и экономика. 2006. № 1. 72 с.
18. Жилинский С.С. Понятие «инвестиции» в современном российском законодательстве. Законодательство. 2005. № 3. 80 с.
19. Краткий юридический словарь / Под ред. А.Н. Азриляна. М.: Институт новой экономики, 2005. 580 с.
20. Коммерческое право: Учебник. Ч. 2. / Под ред. В.Ф. Попондопуло, В.Ф. Яковлевой. М.: Юристъ, 2002. 340 с.
21. Михайлов Е.В., Рожков Ю.В. Финансово-кредитные методы регулирования инвестиционных рынков. Л.: ЛФЭИ, 1991. 232 с.
22. Пономарева Е.Н. Правовая природа и сущность понятий «субъекты коллективного инвестирования» и «формы коллективного инвестирования». Законодательство и экономика. 2008. № 2. 80 с.
23. Потапова Ю.В. Правовое регулирование инвестиционной деятельности в субъектах Российской Федерации: Автореф. дис. канд. юрид. наук. М., 2003.
24. Предпринимательское право в рыночной экономике / Отв. ред. Е.П. Губин, П.Г. Лахно. М.: ООО «Новая Правовая культура», 2004. С. 128.
25. Фархутдинов И.З., Трапезников В.А. Инвестиционное право: учеб.-практ. пособие. М.: «Волтерс Клувер», 2006. 460 с.
26. Чеченов А.А. Инвестиционный процесс: проблемы и методы его активизации. Нальчик, 2001. 175 с.
27. Инвестиции и инвестиционная деятельность: определение и виды. БрокерКредитСервис. URL: https://bcs.ru/express/blog/chto-takoe-investitsii-i-investitsionnaia-deiatelnost (дата обращения: 13.10.2025).
28. К вопросу об определении понятия инвестиции в законодательстве и науке. КиберЛенинка. URL: https://cyberleninka.ru/article/n/k-voprosu-ob-opredelenii-ponyatiya-investitsii-v-zakonodatelstve-i-nauke (дата обращения: 13.10.2025).
29. Правовое регулирование инвестиционной деятельности в России. Юридическое бюро. URL: https://pravovoe-bureau.ru/blog/pravovoe-regulirovanie-investitsionnoy-deyatelnosti-v-rossii (дата обращения: 13.10.2025).
30. Судебная практика, связанная с инвестиционной деятельностью в капитальном строительстве. Князев и партнеры. URL: https://knyazev.ru/publikatsii/sudebnaya-praktika-svyazannaya-s-investitsionnoy-deyatelnostyu-v-kapitalnom-stroitelstve/ (дата обращения: 13.10.2025).
31. Федеральный закон о инвестиционной деятельности — основные положения и правила. URL: https://zakonoved.su/federalnyiy-zakon-ob-investitsionnoy-deyatelsnosti-v-rossiyskoy-federatsii-osushhestvlyaemoy-v-forme-kapitalnyih-vlozheniy.html (дата обращения: 13.10.2025).
32. Тенденции судебной практики в спорах частных инвесторов и публично-правовых образований при реализации совместных инвестиционных проектов. Denuo Legal. URL: https://denuo.legal/insights/judicial-practice-trends-in-disputes-between-private-investors-and-public-law-entities-in-joint-investment-projects/ (дата обращения: 13.10.2025).
33. Правовое регулирование действий иностранных инвесторов в России в после марта 2022 года. URL: https://cila.ru/novosti/pravovoe-regulirovanie-deystviy-inostrannyih-investorov-v-rossii-v-posle-marta-2022-goda/ (дата обращения: 13.10.2025).
34. Актуальные вопросы правового регулирования инвестиционной деятельности в Российской Федерации. ЭКОНОМИКА. ПРАВО. ОБЩЕСТВО. URL: https://elibrary.ru/item.asp?id=48421035 (дата обращения: 13.10.2025).
35. Верховным Судом РФ обобщена судебная практика по вопросам разрешения судами споров, связанных с применением законодательства об иностранных инвестициях и защитой прав иностранных инвесторов. КонсультантПлюс. URL: https://www.consultant.ru/law/hotdocs/50215.html (дата обращения: 13.10.2025).
36. Верховный Суд РФ подтвердил, что договор об инвестиционной деятельности был заключен для сокрытия реализации недвижимости. ФНС России. URL: https://www.nalog.gov.ru/rn77/news/activities_fts/7951336/ (дата обращения: 13.10.2025).
37. Инвестиционное законодательство и практика разрешения споров. Арбитражные споры. URL: https://arbitr.ru/analytics/articles/233089/ (дата обращения: 13.10.2025).