Договор на разработку программного обеспечения

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

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

Автор статьи

Миронова Ольга

Опыт более 15 лет

Ведущий юрист

Специализируется на защите интеллектуальной собственности, регистрации товарных знаков, антимонопольном праве и представлении интересов клиентов в ФАС.

Получить консультацию

Наши услуги:

Консультация юриста со специализацией в IT / IP;

Разработка договора на создание ПО;

Подготовка лицензионного договора на предоставление ПО;

Регистрация ПО в Роспатенте, в реестре отечественного ПО, цифровое депонирование;

Внедрение режима служебных произведений;

Защита коммерческой тайны;

Правовой аудит интеллектуальной собственности бизнеса.

Стоимость услуг

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

На практике именно на этапе подготовки договора закладываются риски, которые впоследствии могут «аукнуться» при использовании ПО:

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

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

1. Какой договор необходимо заключить?

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

Наиболее часто встречаются следующие виды договоров:

• договор подряда;
• договор авторского заказа;
• договор возмездного оказания услуг;
• договор на выполнение научно-исследовательских, опытно-конструкторских и технологических работ (далее – договор НИОКР).

Договор авторского заказа

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

Иные особенности этого типа договора, которые необходимо учитывать:

• Наличие льготного срока для доработки в величине ¼ части общего срока, если соглашением сторон не установлен более длительный срок. Такая льгота связана с тем, что автор – человек и может заболеть / иметь иные уважительные причины для невозможности продолжать творческую работу.
• Презумпция возмездности договора.
• Ограниченная ответственность автора – не больше суммы реального ущерба, при этом никакой упущенной выгоды и повышенных штрафов.
• Ограниченное регулирование законом – в ГК РФ этому типу договоров отведено только 3 статьи. Соответственно, остаются неурегулированными многие важные аспекты:
• распределение прав на созданное ПО;
• приемка заказчиком результатов деятельности автора-программиста;
• гарантии качества;
• распределение расходов в случае выявившейся в процессе исполнения договора необходимости дополнительных работ и т.д.

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

Договор оказания услуг

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

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

В рамках такого договора исполнитель отвечает не за результат, а за надлежащее оказание услуг, только за свои действия по разработке.

В таком договоре в общем виде описываются те задачи, которые ставятся перед привлеченным специалистом, например, «оказание содействия в разработке модуля системы…».

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

Договор подряда

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

В этом договоре ключевой аспект – наличие результата работы и передача его заказчику.

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

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

Договор на выполнение научно-исследовательских работ (НИОКР)

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

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

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

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

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

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

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

2. Что необходимо обязательно предусмотреть в договоре?

А) Предмет договора

Он определяется посредством указания на требования к функционалу программы.

Предмет договора не может быть сформулирован через абстрактные размытые формулировки.

Требования к ПО можно разделить на следующие виды:

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

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

На что следует обращать внимание при подготовке ТЗ:

• Требования должны быть максимально детализированы и сформулированы конкретно. Не стоит использовать оценочные категории и формулировки типа «эффективный», «оптимизированный», «достаточный», «устойчивый».
• Каждое требование должно отвечать критерию проверяемости. Это значит, что требование должно быть сформулировано таким образом, чтобы позволять на этапе тестирования/приемки однозначно определить, было ли данное требование реализовано.
• Каждому требованию рекомендуем присваивать идентификатор – так будет легче ориентироваться в них дальше.

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

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

Б) Сроки работ по разработке ПО

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

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

В) Качество результата

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

Можно выделить два основных подхода к определению качества ПО:

• соответствие программы определенным требованиям;
• пригодность программы к использованию.

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

Соответствие программы указанным требованиям обеспечивается путем её тестирования на различных этапах разработки.

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

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

Г) Распределение прав на созданную программу

Условие о распределении прав на разработанное ПО является одним из наиболее важных элементов договора.

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

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

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

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

Профильный юрист со специализацией в IP-праве и IT-праве поможет:

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

Юридическое сопровождение на этапе разработки договора может сэкономить компании огромное количество ресурсов и избежать конфликтов и нарушения прав.

Читать по теме:

Гайд: как работодателю защитить свои права на программы, создаваемые работниками

Как составить лицензионный договор на ПО: пошаговый гайд

Позвоните нам по телефону горячей линии 8 (495) 509-41-19

Заполните заявку на консультацию

Напишите электронное письмо на адрес etalon@etalon-cons.ru