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

Условия договора на разработку ПО

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

1. Глоссарий.
2. Предмет договора.
3. Модели и методологии разработки ПО.
4. Документация. Техническое задание и его изменение, дополнение.
5. Вознаграждение и порядок его формирования.
6. Срок выполнения работ.
7. Распределение обязанностей по приобретению материалов (в том числе ПО) для разработки.
8. Использование иного кода и объектов ИС в продукте (открытое ПО, Pre-existing IP). Проверка совместимости лицензий на Open Source.
9. Соблюдение прав авторов и предоставление заказчику данных об авторах.
10. Патенты на разработанное ПО.
11. Контроль качества.
12. Порядок разработки и сдачи промежуточных вариантов.
13. Приемка и участие заказчика в приемке.
14. Порядок перехода прав на продукт.
15. Передача исходного кода.
16. Заверения и гарантии.
17. Порядок взаимодействия сторон и каналы связи.
18. Лица, уполномоченные на принятие решений.

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

Глоссарий

В сфере IT используются специфические термины и понятия, поэтому для понимания сторон, а также для конкретного использования понятий следует определить в договоре содержание терминов. Ряд терминов содержатся в ТНПА (ГОСТ, СТБ и пр.), часть выработаны практикой. Целесообразно закрепить в договоре определение и содержание следующих понятий:

— техническое задание (Statement of work) (с раскрытием его краткого содержания);

— конфиденциальная информация (с указанием списка информации и содержащих ее документов, а также срока сохранения конфиденциальности и условий обеспечения конфиденциальности);

— отчетный период — период, за который должна быть выполнена определенная часть (этап) работы и предоставлен ее результат заказчику;

— библиотека кода (Code Library) — сборник подпрограмм или объектов, используемых для разработки программного обеспечения;

— релиз (Release) — выпуск финальной версии программного продукта, готового к использованию и/или тиражированию;

— репозиторий (хранилище) — место, где хранятся и поддерживаются какие-либо данные;

— front-end — интерфейс взаимодействия между пользователем и основной программно-аппаратной частью продукта;

— back-end — основная программно-аппаратная часть продукта;

— баг (bug) — ошибка, дефект программы.

Справочно.
Наиболее популярными среди репозиториев являются GitHub, GitLab, Bitbucket, Beanstalk, Amazon Cloud Drive, Codebase, Gitolite, Heroku, Microsoft Azure, RhodeCode, Subversion, Team Foundation Server.

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

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

Часто разработка ПО регулируется договором возмездного оказания услуг, поскольку ПО передается в нематериальном виде (например, при загрузке готового ПО в облачное хранилище). Однако нормы ГК о договоре подряда не предусматривают обязательную «материальность» результата работ. Договор возмездного оказания услуг направлен на выполнение определенных действий без гарантии достижения результата, в то время как договор подряда направлен на выполнение работы с достижением и передачей результата. То есть при отсутствии разработанного ПО договор не будет считаться исполненным. Таким образом, договор подряда в большей степени соответствует интересам заказчика, который платит за результат, а не за выполнение разработчиком некоторого набора задач.

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

При формулировании предмета договора сторонам необходимо определить результат выполняемых работ (название продукта и его назначение). Если на этапе заключения договора название продукта еще неизвестно, стороны могут указать предварительное (рабочее) название ПО. При отсутствии рабочего названия следует дать краткое описание ПО, например: «Компьютерная программа — развлекательное приложение для мобильных устройств, предназначенное для редактирования изображений». Сторонам также рекомендуется указать назначение продукта вне зависимости от того, насколько детально будет сформулировано техническое задание (ТЗ) на разработку. Согласно п. 1 ст. 674 ГК результат работ должен в пределах разумного срока быть пригодным для установленного договором использования, а если такое использование договором не преду-смотрено — для обычного использования результата работы такого рода. Таким образом, указание назначения продукта защищает интересы заказчика, а также дает подрядчику дополнительную информацию о продукте. Это особенно важно в случае, когда определенные нюансы продукта не были учтены в ТЗ.

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

Модели и методологии разработки ПО

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

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

Согласно подп. 5.2.4.2 п. 5 СТБ/ИСО МЭК 12207-2003 «Информационные технологии. Процессы жизненного цикла программных средств» поставщик должен выбрать модель жизненного цикла программных средств, если она не оговорена в договоре, в соответствии с областью применения, объемом и сложностью проекта. Таким образом, хотя условие об указании используемой при разработке ПО (как части цикла разработки ПО) модели жизненного цикла не является обязательным условием договора, для понимания процедуры разработки ПО стоит указать, как будет строиться работа исполнителя.

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

Выделяют следующие основные модели жизненного цикла ПО: водопадная модель (waterfall, каскадная модель), V-образная модель, исследовательское программирование, спиральная модель, инкрементная модель, итеративная модель.

Результатом существования указанных моделей являются методологии разработки ПО. Среди наиболее популярных методологий выделяются следующие: Agile, Scrum, Kanban, Rational Unified Process (RUP), OpenUP, Rapid Application Development (RAD), Extreme Programming (XP) и др.

Используемая модель и методология напрямую могут влиять на следующие факторы:

1. Способ формирования цены (Fixed price чаще встречается при модели waterfall, где зачастую бывают строгие бюджеты, в то время как Time and material(-s) более характерна для гибких моделей (хотя и там имеет место Fixed price)).

2. Участие заказчика в процессе разработки ПО. Степень участия заказчика или его представителя во многом определяется используемой методологией. Так, например, при использовании методологии Scrum появляется такая фигура, как Product Owner (представитель заказчика), который выполняет одну из главных ролей в проекте и должен постоянно взаимодействовать с разработчиками, участвовать в демонстрациях, формировать (участвовать в формировании) Product vision и Product backlog, предъявлять список требований к продукту.

Справочно.
Product Vision (видение продукта) — документ, ясно описывающий концепцию продукта, его видение заказчиком.
Product backlog (невыполненная работа по продукту) — список работ и задач по продукту, которые необходимо выполнить команде.

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

4. Передача промежуточных результатов работ (модулей, версий ПО) заказчику.

Техническое задание и его изменение, дополнение

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

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

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

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

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

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

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

— ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы»;

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

— ГОСТ 19.201-78 «Техническое задание. Требования к содержанию и оформлению»;

— 29148-2011 — ISO/IEC/IEEE International Standard — Systems and software engineering — Life cycle processes — Requirements engineering.

Справочно.
29148-2011 — ISO/IEC/IEEE International Standard — Systems and software engineering — Life cycle processes — Requirements engineering — методика составления спецификаций требований к программному обеспечению, рекомендуемая Институтом инженеров по электротехнике и радиоэлектронике (IEEE) и т.д.

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

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

Вознаграждение и порядок его формирования

Можно выделить два основных способа формирования цены:

1) Fixed price (фиксированная цена);

2) Time and material(-s) (время и материалы).

Справочно.
Time and material(-s) — способ определения цены за продукт, при котором оплачиваются человеко-часы (с учетом рейтов) разработчика(ов), и иных затрат, необходимых для создания продукта (покупка лицензий на фреймворки и пр.).

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

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

В соответствии со ст. 43 Закона Республики Беларусь от 17.05.2011 № 262-З «Об авторском праве и смежных правах» (далее — Закон) договор уступки исключительного права должен содержать условие о размере вознаграждения или о порядке его определения либо прямое указание на безвозмездность. В данном случае безвозмездность может быть квалифицирована как дарение или спонсорская помощь, поэтому остановимся на варианте возмездной уступки.

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

Можно выделить два способа определения возмездности:

1) прямое указание на размер стоимости уступки;

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

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

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

Отметим, что стороны вправе договориться о безвозмездности лицензии (п. 4 ст. 44 Закона). Исключение составляют договоры, заключенные между коммерческими организациями: в соответствии с ч. 2 п. 1 ст. 985 ГК между такими юридическими лицами не допускается заключение безвозмездного лицензионного договора.

Срок выполнения работ

В соответствии с ч. 1 п. 1 ст. 662 ГК в договоре подряда указываются начальный и конечный сроки выполнения работы. По согласованию между сторонами в договоре могут быть предусмотрены также сроки начала и завершения отдельных этапов работы (промежуточные сроки).

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

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

Стороны могут согласовывать сроки разными способами, например, указывая точные даты начала и окончания работ, или устанавливая длительность выполнения работ и точку отсчета в виде наступления определенного события (передача документации, оплата очередного этапа работ), или предусматривая события, с которыми будут связаны начало и окончание работ.

Распределение обязанностей по приобретению материалов (в том числе ПО) для разработки

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

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

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

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

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

Использование иного кода и объектов ИС в софте (открытое ПО, Pre-existing IP)

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

Справочно.
В ТЗ следует включить дополнительное требование к разрабатываемому ПО: оно должно качественно работать в составе более крупного ПО или автоматизированной системы.

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

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

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

— Apache License 2.0;

— MIT license;

— GNU General Public License (GPL) (версия 3 этой лицензии обозначается GNU GPLv3);

— ISC License (ISC).

Справочно.
Полный перечень открытых лицензий для разных объектов интеллектуальной собственности (компьютерные программы, изображения, шрифты и т.д.) доступен на сайте Open Source Initiative по адресу: http://opensource.org.

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

В договоре сторонам следует указать, имеет ли разработчик право использовать открытое ПО при выполнении работ. Если такое право разработчику предоставлено, необходимо уточнить тип свободной лицензии, которой вправе воспользоваться разработчик. Использование некоторых свободных лицензий ограничивает заказчика в возможности использовать разработанный продукт по собственному усмотрению. Так, например, в соответствии с лицензией GNU General Public License пользователю (разработчику, заказчику) предоставлено право воспроизводить, перерабатывать и распространять исходное ПО, в том числе на коммерческой основе. Однако при этом правообладатель обязан предоставить всем пользователям производного продукта все вышеперечисленные права, что может быть несовместимо с планами заказчика по использованию продукта.

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

Контроль качества

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

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

— лицо, уполномоченное на контроль качества (таким лицом может быть третье лицо, обладающее достаточной квалификацией);

— критерии, инструменты, методики для оценки качества работ (могут содержаться в ТЗ или ином документе).

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

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

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

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

Приемка и участие заказчика в приемке

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

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

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

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

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

Справочно.
Баг (bug) – ошибка, дефект программы. Градация важности (severity) бага:
1) блокирующая (blocker);
2) критическая(critical);
3) значительная (major);
4) незначительная (minor);
5) тривиальная (trivial).
Градация приоритета (priority) бага:
1) высокий (high);
2) средний (medium);
3) низкий (low).

В договоре стоит указать:

— порядок передачи заказчику продукта;

— срок для тестирования или «гарантийный» срок для выявления дефектов;

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

— порядок уведомления разработчика о выявленных заказчиком багах;

— порядок и сроки устранения багов.

Целесообразно также указывать критерии (или их примерный список), в соответствии с которыми заказчик может признать ПО некачественным.

Документация

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

1) документация, создаваемая для разработки ПО:

— Requirements (техническое задание (ТЗ));

— Product Vision (концепция);

— Software Requirements Specification (требования к ПО);

— Software Architecture Document (архитектура ПО);

2) документация, создаваемая в процессе разработки ПО:

— изменения в ТЗ;

— промежуточная приемо-сдаточная документация;

— встроенная в ПО документация;

— пользовательская документация (руководство для конечных пользователей, системных администраторов и др.);

3) документация по завершении разработки ПО:

— документы по приемке ПО по качеству;

— приемо-сдаточная документация;

— маркетинговая (при необходимости).

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

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

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

Соблюдение прав авторов и предоставление заказчику данных об авторах

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

Справочно.
Право на имя — право использовать или разрешать использовать произведение под подлинным именем автора, вымышленным именем (псевдонимом) или без обозначения имени (анонимно) (ч. 3 п. 1 ст. 15 Закона Республики Беларусь от 17.05.2011 № 262-З «Об авторском праве и смежных правах»).

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

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

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

Патенты на разработанное ПО

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

Порядок перехода исключительного права на продукт

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

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

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

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

Передача исходного кода

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

Справочно.
Log, log-file (журнал регистрации, лог-файл) — это файлы, содержащие системную информацию (записи) о событиях в программе, действиях пользователя в ней.

На практике сложились следующие основные способы передачи файлов:

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

2) посредством удаленной загрузки файлов с исходным кодом на сервер заказчика;

3) посредством передачи файлов с исходным кодом через электронную почту или иные средства связи;

4) путем передачи материального носителя с записанными файлами (оформляется как передача материальных ценностей и опосредуется оформлением накладной).

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

Заверения и гарантии

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

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

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

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

В Республике Беларусь институт заверений об обстоятельствах полноценно могут использовать лишь резиденты Парка высоких технологий (далее — ПВТ), учредители (участники) и собственники имущества резидентов ПВТ (в отношениях как с иностранными, так и с белорусскими контрагентами) (ч. 4 подп. 5.4 п. 5 Декрета Президента Республики Беларусь от 21.12.2017 № 8 «О развитии цифровой экономики»). При этом договор может предусматривать не только возмещение имущественных потерь, но и взыскание неустойки.

Иные белорусские компании также вправе включать заверения об обстоятельствах в договор (в том числе для дальнейшего его толкования). Однако необходимо учитывать, что п. 1 ст. 14 ГК связывает возмещение убытков с нарушением права. То есть пострадавшая сторона не получит возмещение убытков, причиненных недостоверностью заверений, если не докажет, что недостоверность заверений является также нарушением права.

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

— самих сторон (о том, что сторона надлежащим образом создана и действует, имеет необходимые разрешения (лицензии) для выполнения работ (оказания услуг) и т.д.);

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

— договора (о том, что каждая сторона приняла решение о заключении сделки в соответствии с корпоративными процедурами, что сделка согласована с соответствующим государственным органом и т.д.).

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

Порядок взаимодействия сторон и каналы связи

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

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

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

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

Лица, уполномоченные на принятие решений

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

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

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

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

1) каждая из сторон уверена в том, что информация исходит непосредственно от контрагента и ее не нужно перепроверять;

2) все запросы разных специалистов одной стороны проходят через единый канал, поэтому их проще отслеживать;

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

Рекомендация.
В договоре следует предусмотреть процедуру и сроки уведомления контрагента о назначении иного уполномоченного на принятие решения лица.

Definition:
Product vision — document describing the concept of the product, the vision of the customer.
The user documentation — the user documentation (manual/guide) describes how to use the program.
Log, log file — files containing system information (records) about events in the program, user actions in it.
Representations and warranties — a set of representations (statements) about the circumstances that are important for the conclusion of the contract, its execution or termination.
Business analyst — a business analyst is an intermediary between a customer of a software product and software developers. Business analyst identifies customer’s needs, analyzes them and brings them to developers.
Customer relationship management — application software (web application) for organizations designed to automate interaction with clients.