Денис Коваль →  Гарантия работоспособности ПО в англоязычном контракте

Я юрист ИТ-компании, которая занимается разработкой мобильных приложений и базируется в СНГ, и по роду своей деятельности тесно связан с процессом подписания контрактов с Заказчиками, которые в последнее время все чаще и чаще норовят не согласиться с условиями нашего «шаблонного контракта». Вот и теперь очередной британский Заказчик требует пересмотра состава гарантийных обязательств, которые мы обычно предлагаем. Для удобства заказчика применимым правом выбрано английское право, что подразумевает определенные трудности при согласовании таких сложных условий как гарантии.

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

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

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

Сначала немного теории:
«Что же такое гарантия в британском ИТ-праве?»

Warranty – договорное обязательство. Этот термин типичен для законодательства стран общей системы права. Посредством «warranty» один из контрагентов гарантирует то, что определенный факт действительности либо факт, который будет иметь место в будущем, является правдой.
К общепринятым гарантиям можно отнести:
Warranty of Function –гарантия работоспособности;
Warranty of title – это гарантия на чистоту правового титула при передаче права собственности на продукт (разработчик имеет право оказывать такую услугу);
Infringement Warranty – гарантия отсутствия нарушений чьих-либо авторских прав в процессе разработки;
Warranty of merchantability – гарантия пригодности продукта к использованию;
Warranty of fitness for а specific purpose – «цели Заказчика будут достигнуты»;
Warranty as to Capacity – гарантия того, что разработчик полномочен подписывать юридические документы;
Warranties as to Viruses and Disabling Code – гарантия вирусной безопасности продукта;
Warranty of Compatibility – это гарантия совместимости технических средств сторон.

При этом среди общих гарантий в особую группу можно выделить «подразумеваемые гарантии» (Implied Warranties), которые автоматически являются частью контрактов на разработку ПО. Если прямо не исключить действие этих гарантий, то они будут распространяться на правоотношения в рамках этого контракта. К «Implied Warranties», например, относятся: 1) Warranty of Title, 2) Infringement Warranty, 3) Warranty of Merchantability, 4) Warranty of fitness for а specific Purpose.

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

Пора перейти от теории к практике. В дальнейшем я подробнее расскажу обо всех видах гарантий, а начать предлагаю с самой популярной:Warranty of Function(Гарантия работоспособности). В моем случае не было разногласий с Заказчиком по поводу этой гарантии, но я предлагаю отнестись к ней внимательно и разобрать несколько формулировок.

Примеры удачных формулировок:
1. «Provider warrants that, during the one year period following delivery, the Software will perform materially as described in the technical specifications set fifth in Exhibit A»
2. «Provider warrants that, during the first 180 days after installation, each New Module will perform substantial conformance to its documentation issued by Provider under the heading “Official Product Documentation”»

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

Формулировка в Удачном примере №1 успешно справилась с этой задачей. Этот пример также удачен тем, что пользуется термином «materially (существенно)». Этот термин защищает разработчика ПО от рисков, связанных с проблемами и обязательствами, возникающими при выявлении незначительных (косметических) дефектов Заказчиком. Естественно, стоит серьезно отнестись к составлению технической спецификации в части о писания функционала, т.к. Удачный пример № 1 доверяет спецификации и презюмирует, что она составлена качественно и отражает действительные намерения сторон.

Удачный пример №2 идет еще дальше и пользуется условным ярлыком «Official Product Documentation», который проставляется на необходимой документации и объединяет в себе пакет всех относимых к продукту документов. Стоит отметить, что это мера представляет собой отличный пример систематизации проектного документооборота. Удачный пример №2 также примечателен своей превентивной конструкцией «substantial conformance – существенное соответствие». Действительно, мы не можем быть уверены в том, что продукт будет функционировать идеально в соответствии с проектной документацией по окончании разработки. Цель эта конструкции — добавить гибкости в гарантию работоспособности в целом.

На практике можно встретиться с такими неудачными формулировками как:
•«Provider represents and warrants that the Software will be in good working order» — Что в этом случае « good working order » и чем оно описывается? Такая формулировка слишком размыта и своей неопределенностью несет в себе кучу рисков претензий со стороны Заказчика.
• «Provider represents and warrants that the Software will perform according to its documentation» — Что подразумевается под « Software documentation »? Под « Software documentation » можно понимать неограниченное число документов, которые связаны с процессом разработки продукта. Но что будет, если мы включим сюда и переписку с менеджерами по продажам или бизнес-аналитиками? Письмо, в том числе и электронное, является документом и относится к продукту. Но нужно ли нам, чтобы ПО функционировало в соответствии с положениями, которые изложены в переписке? Думаю, что нет, ведь мы не так серьезно относимся к написанию письма, как, например, к составлению технической спецификации. В письме можно пообещать много или чего-то недообещать, а затем придется доказывать, что спецификация имеет большую юридическую силу, чем письмо. Ведь вряд ли кто-то включает письма в иерархию проектной документации и прописывает правила приоритетности в отношении писем.

Также гарантия работоспособности может адресоваться конкретным требованиям, которые прописываются в ее контексте. Например: «Provider warrants that no Deliverable, when installed, will impair the System’s ability to process purchase and sales transactions at the speeds set forth in Exhibit C».

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

Эту гарантию однозначно стоит включать в контракт, т.к. вряд ли Заказчик пойдет на подписание контракта, не будучи уверенным в том, что ПО заработает и будет работать в дальнейшем или у него хотя бы будет правовое средство защиты в случае провала. При этом стоит лимитировать гарантийные сроки (например, «the first 180 days after installation»), вы ведь не хотите иметь бессрочную головную боль за продукт, который был разработан еще в прошлом десятилетии и давно уже всеми забыт.

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