Денис Коваль → Как правильно исключить действие подразумеваемых гарантий в контракте на разработку ПО
Если кто помнит, в первой части своей статьи о гарантиях я упоминал о «подразумеваемых гарантиях» (Implied Warranties), которые автоматически являются частью контрактов на разработку ПО, т.к. они закреплены законодательно. В британском законодательстве эти гарантии закреплены в The Sale of Goods Act 1979 и The Supply of Goods and Services Act 1982. Напомню, что к «Implied Warranties» относятся: 1) Warranty of Title, 2) Infringement Warranty, 3) Warranty of Merchantability, 4) Warranty of fitness for а specific Purpose.Мы говорили о том, что если прямо не исключить действие этих гарантий, то они будут распространяться на правоотношения в рамках этого контракта. Теперь я предлагаю рассмотреть варианты исключения действия этих подразумеваемых гарантий.
В первую очередь стоит отметить, что если мы говорим о праве Великобритании, то все исключения «warranties» должны соответствовать требованиям, которые предъявляет UTCA (Unfair Contract Terms Act 1977). В соответствии с UTCA, некоторые «implied warranties» вообще не могут быть исключены (например, «Warranty of Title»), а некоторые, могут быть исключены только целесообразно — «only if reasonable» (например, «Warranty of fitness for а specific Purpose»). Если суд придет к выводу о том, что условие об исключении гарантии идет в разрез с требованиями этого нормативного акта, то это условие будет считаться недействительным. Во избежание рисков, связанных с нарушением UTCA, и в целях обеспечения исключения максимального числа гарантийных обязательств, разработчик может воспользоваться следующей конструкцией: «Other warranties are excluded to the maximum extent permitted by law».
1. «EXCEPT FOR THE EXPRESS WARRANTIES SPECIFIED IN THIS SECTION, PROVIDER MAKES NO WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE»
Использование заглавных букв при выражении условий об исключении «warranties» — это устоявшаяся контрактная практика в США и Великобритании.
2. «RECIPIENT ACCEPTS THE GOODS “AS IS,” WITH NO REPRESENTATION OR WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE»
Дисклеймер «AS IS» в торговом обороте означает, что товар передается в собственность «как есть», т.е. без каких-либо гарантий.
3. «Provider does not warrant that the Product will perform without error or that it will run without immaterial interruption. Provider provides no warranty regarding, and will have no responsibility for, any claim arising out of: (a) a modification made by Recipient, unless Provider approves such modification in writing; or (b) use of the Product in combination with or on products other than as specified in the Technical Specifications or authorized in writing by Provider»
В этом примере речь идет о том, что нецелесообразно гарантировать, что разработанное ПО является безошибочным продуктом. Дефекты бывают разные и, на мой взгляд, пообещать заказчику то, что ПО свободно от существенных дефектов («material defects»), вполне достаточно.
Естественно, в контракте или в Statement of Work необходимо отразить, что признается существенным дефектом. Классификации дефектов «blocker-major -minor» и точное определение «Acceptance Criteria» будет достаточно для решения этого вопроса.
4. «Provider: (a) will pass through to Recipient any warranty right it receives from any third party provider of System components not authored or manufactured by Provider (“Third Party Components”); and (b) will reasonably cooperate with Recipient in enforcing such rights. Provider provides no warranties, express or implied, with regard to Third Party Components, and Provider will not be liable for any failure of any Third Party Component to function as expected or intended»
В этом примере разработчик не несет ответственность в отношении рисков, связанных с проблемами функционирования компонентов, которые принадлежат третьей стороне.
5. «Provider does not warrant the Software’s interoperability with any computer operating system other than the versions of Windows XP issued by Microsoft Corporation as of the Effective Date»
Здесь заказчик не гарантирует функциональной совместимости с отличными от Windows XP операционными системами.
ВЫВОДЫ:
1) Разработчику необходимо четко определиться со своей позицией относительно тех гарантий, которые он может дать заказчику. Исключение всех гарантий наименее рискованный подход, но заказчик вряд ли согласится платить за продукт, приемлемое функционирование которого не подкреплено никакими правовыми средствами.
2) При этом не стоит использовать весь спектр возможных гарантий. Достаточно целесообразных и необходимых гарантий, которые подходят для вашего конкретного случая и дадут вашему контрагенту уверенность в гарантийной безопасности.
В первую очередь стоит отметить, что если мы говорим о праве Великобритании, то все исключения «warranties» должны соответствовать требованиям, которые предъявляет UTCA (Unfair Contract Terms Act 1977). В соответствии с UTCA, некоторые «implied warranties» вообще не могут быть исключены (например, «Warranty of Title»), а некоторые, могут быть исключены только целесообразно — «only if reasonable» (например, «Warranty of fitness for а specific Purpose»). Если суд придет к выводу о том, что условие об исключении гарантии идет в разрез с требованиями этого нормативного акта, то это условие будет считаться недействительным. Во избежание рисков, связанных с нарушением UTCA, и в целях обеспечения исключения максимального числа гарантийных обязательств, разработчик может воспользоваться следующей конструкцией: «Other warranties are excluded to the maximum extent permitted by law».
Примеры условий об исключении «warranties»:
1. «EXCEPT FOR THE EXPRESS WARRANTIES SPECIFIED IN THIS SECTION, PROVIDER MAKES NO WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTY OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE»
Использование заглавных букв при выражении условий об исключении «warranties» — это устоявшаяся контрактная практика в США и Великобритании.
2. «RECIPIENT ACCEPTS THE GOODS “AS IS,” WITH NO REPRESENTATION OR WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE»
Дисклеймер «AS IS» в торговом обороте означает, что товар передается в собственность «как есть», т.е. без каких-либо гарантий.
3. «Provider does not warrant that the Product will perform without error or that it will run without immaterial interruption. Provider provides no warranty regarding, and will have no responsibility for, any claim arising out of: (a) a modification made by Recipient, unless Provider approves such modification in writing; or (b) use of the Product in combination with or on products other than as specified in the Technical Specifications or authorized in writing by Provider»
В этом примере речь идет о том, что нецелесообразно гарантировать, что разработанное ПО является безошибочным продуктом. Дефекты бывают разные и, на мой взгляд, пообещать заказчику то, что ПО свободно от существенных дефектов («material defects»), вполне достаточно.
Естественно, в контракте или в Statement of Work необходимо отразить, что признается существенным дефектом. Классификации дефектов «blocker-major -minor» и точное определение «Acceptance Criteria» будет достаточно для решения этого вопроса.
4. «Provider: (a) will pass through to Recipient any warranty right it receives from any third party provider of System components not authored or manufactured by Provider (“Third Party Components”); and (b) will reasonably cooperate with Recipient in enforcing such rights. Provider provides no warranties, express or implied, with regard to Third Party Components, and Provider will not be liable for any failure of any Third Party Component to function as expected or intended»
В этом примере разработчик не несет ответственность в отношении рисков, связанных с проблемами функционирования компонентов, которые принадлежат третьей стороне.
5. «Provider does not warrant the Software’s interoperability with any computer operating system other than the versions of Windows XP issued by Microsoft Corporation as of the Effective Date»
Здесь заказчик не гарантирует функциональной совместимости с отличными от Windows XP операционными системами.
ВЫВОДЫ:
1) Разработчику необходимо четко определиться со своей позицией относительно тех гарантий, которые он может дать заказчику. Исключение всех гарантий наименее рискованный подход, но заказчик вряд ли согласится платить за продукт, приемлемое функционирование которого не подкреплено никакими правовыми средствами.
2) При этом не стоит использовать весь спектр возможных гарантий. Достаточно целесообразных и необходимых гарантий, которые подходят для вашего конкретного случая и дадут вашему контрагенту уверенность в гарантийной безопасности.
Гарантией оно может переводиться в контексте страхового права, где оно наоборот является существенным условием договора.
В рамках британского ИТ-права есть значительная особенность в подходе к договорным условиям. Дело в том, что на этапе зарождения ИТ-бизнеса базисом для формирования собственных принципов построения системы новой отрасли права в Британии стал накопившийся опыт США в ИТ-праве. В США «warranty» воспринимается как существенное условие. Это означает, что фактически в британском ИТ-праве «warranties» должны быть поименованы как «conditions — существенные условия», т.к. они действительно являются существенными. Но контрактная практика в сфере информационных технологий пошла по другому пути, пользуясь термином «warranty» в качестве условия «that goes to the heart of the contract ». Да и суд будет обращать внимание на существенность условия, а не на то, как оно поименовано в договоре.