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

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

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

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).

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

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

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

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

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

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

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

Окончание статьи читайте в следующем номере журнала.