Всім, кому я винен, я прощаю: спори IT-компаній з замовниками

ЛІГА:ЗАКОН Бізнес, 29 січня 2021 р.

Олена Мічуріна

Стаття on-line 

Аналіз судової практики 

Недобросовісні замовники не втомлюються вигадувати приводи, які переслідують єдину мету: заплатити менше, а в ідеалі - не заплатити нічого. Перелік таких приводів у сфері IT поповнюється новинками щорічно, але більшість із них є варіаціями на тему «воно не працює». В даній статті пропонується розглянути кілька цікавих кейсів, досвід яких може бути корисним у нескінченній війні між бажанням заробити і ще більшим бажанням не платити.

Хто є хто: важливість визначення реальної правової природи взаємовідносин

При оформленні відносин з клієнтами важливо називати речі своїми іменами: підряд не слід обзивати послугами, а комплексний договір не варто спрощувати до поставки.

Легковажне ставлення до назви договору визначає курс не тільки подальших взаємин сторін, а й може спричинити серйозні труднощі в разі виникнення спору. Яскравим прикладом тому служить справа N910/13245/14, яка двічі пройшла через вертикаль судових інстанцій і після шести років розгляду нарешті завершилася остаточним рішенням Верховного Суду в 2021 році.

Компанія-розробник звернулася із позовом до замовника, який успішно прийняв програмне забезпечення і так само успішно відмовився його оплачувати. Незважаючи на начебто простоту ситуації, позивачу довелося геть нелегко: ні підписані сторонами акти прийому-передачі, ні відсутність у замовника будь-яких претензій у розумні строки, ні 14 томів документації, наданих позивачем, не стали вирішальними для суду, який відповідач переконував у своїй правоті одним-єдиним аргументом - «воно не працює». Проблема крилася в тому, що виконавець і замовник, оформлюючи досить складні взаємини з виконання і передачі багатофазного комплексу робіт і їх результатів, назвали все це «договором про надання послуг». При цьому предметом договору були роботи з налагодження та впровадження комплексної автоматизованої системи на обладнанні замовника, а також розробка і передача замовнику супровідної технічної та описової документації на програмне забезпечення.

Таким чином, метою замовника при укладенні договору було одержання конкретного матеріального уречевленого результату, віддільного від виконавця, а не сам процес налагодження та впровадження, хоча і ці опції були необхідною умовою коректної роботи програми. Інші умови договору також вказували на його реальну правову природу, оскільки фактично повністю копіювали положення Цивільного кодексу України, що регулюють підряд, включаючи зобов'язання виконавця щодо передачі матеріального результату замовникові, гарантійні зобов'язання, право замовника вимагати надання проміжних результатів робіт і т.д.

Виходячи з умов, укладений сторонами договір був комплексною угодою, що включає, перш за все, виконання робіт і передачу результату таких робіт замовнику, а значить, повинен регулюватися нормами ЦК України, які відповідають його суті, а не назві. З урахуванням того, що замовник був незадоволений матеріальним результатом - а саме роботою програмного забезпечення, у цій частині до правовідносин необхідно застосовувати норми ЦК України, які регулюють правовідносини підряду, а не послуг.

Для даної справи це мало вирішальне значення, оскільки норми ЦК України, які регулюють відносини з надання послуг і виконання робіт, значно відрізняються в розрізі встановлення факту належного виконання зобов'язань: в рамках взаємин підряду здача і приймання роботи є юридично зобов'язуючими діями замовника і підрядника щодо один одного. Тобто «здавання-приймання» роботи - це не тільки надання результату роботи замовнику, огляд цього результату, вручення результату і надання гарантій на нього, але з юридичної точки зору - визнання підряду виконаним.

Як не дивно, але визначення реальної правової природи взаємовідносин сторін і застосування відповідних норм ЦК України відбулося лише на другому «колі» розгляду справи в суді апеляційної інстанції, але саме це стало ключем до прийняття законного і дійсно обґрунтованого рішення.

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

Як є: чи не порушує положення договору про надання ПО на умовах «AS IS» норми ЦК України

Ще одним цікавим прикладом на тему «воно не працює» стала справа №910/17889/19. В рамках даної справи до суду звернувся покупець з позовом до постачальника програмної продукції про визнання недійсним пункту договору про надання покупцеві програмної продукції на умовах «як є» (принцип «AS IS»). Згідно з цією умовою, постачальник відмовляється від надання будь-яких гарантій і підтверджень, явних умов або тих, які маються на увазі, обов'язкових чи інших, в тому числі, без обмеження, будь-яких гарантій щодо товарної якості або придатності для конкретної мети. Зокрема, постачальник не гарантує і не заявляє, що програмна продукція буде працювати без збоїв і помилок, або що дефекти в програмному забезпеченні можуть бути виправлені або будуть виправлені.

Позивач вважав, що такий пункт договору суперечить меті, правовій природі договору і умовам щодо технічної підтримки поставленого програмного забезпечення, згідно з якими відповідач забезпечує безперебійне функціонування програмної продукції і відновлення її роботи після технічних збоїв. Позивач також стверджував, що даний пункт суперечить нормам ст. 673 Цивільного кодексу України, згідно з якими продавець зобов'язаний надати покупцеві товар, якість якого відповідає умовам договору, а в разі відсутності в договорі умов щодо якості товару, продавець зобов'язаний передати товар, придатний для мети, з якою такий товар звичайно використовується.

В обґрунтування своїх доводів позивач вказував на технічні збої і помилки в роботі поставленої відповідачем програмної продукції. Крім того вказав, що саме відповідач готував проект договору, а значить, від самого початку мав намір поставити позивачеві неякісну програмну продукцію, отримати грошові кошти і зняти з себе відповідальність.

Однак доводи позивача не викликали ентузіазму в суду - у позові було відмовлено. А ось причини відмови варті уваги.

По-перше, суд вказав, що позивачем не представлено жодних належних та допустимих доказів як технічних збоїв і помилок в роботі програмної продукції, так і причинно-наслідкового зв'язку між такими технічними збоями і помилками, та якістю поставленої йому відповідачем програмної продукції.

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

По-третє, суд звернув увагу позивача на загальний порядок укладення господарських договорів, визначений Цивільним кодексом України: в разі заперечень щодо окремих умов договору, сторона, яка одержала проект договору, складає протокол розбіжностей, про що робиться застереження в договорі, і в двадцятиденний строк надсилає іншій стороні два примірники протоколу розбіжностей разом з підписаним договором. З огляду на те, що ніяких розбіжностей при укладенні договору з боку замовника не спостерігалося, то і заявляти про них в суді - безпідставно.

Підсумки банальні: свобода - це не тільки про право, а й про відповідальність, а в розрізі договорів про відповідальність краще думати до, а не після їх укладення.

Як не треба: істотні порушення договору

У процесі тривалої взаємодії, що складається зазвичай при виконанні складних комплексних договорів, трапляється так, що порушення договору допускають і замовник (в частині оплати, погоджень, підписання актів і т.п.), і виконавець (невиконання, порушення термінів і т.д.), результатом чого є взаємні претензії. В результаті одна зі сторін, втомившись від обтяжливих взаємовідносин, може спробувати вийти з них шляхом розірвання договору. Однак більшість таких договорів не передбачають права розірвання в односторонньому порядку і тоді все, що залишається, - йти до суду, посилаючись на істотні порушення договору, допущені контрагентом. Однак справи такого типу впираються в поняття «суттєвості», а позивачі традиційно не забезпечують свої вимоги переконливою доказовою базою.

Прикладом є справа №910/2683/19, в рамках якої замовник звернувся до виконавця з позовом про розірвання договору та стягнення сплаченої суми. В обґрунтування своїх вимог посилався на те, що між сторонами укладено договір на надання комплексних послуг. Відповідач порушив узяті на себе зобов'язання за договором в частині розробки Інтернет-сайту, не виконав в повному обсязі передбачені договором роботи, не забезпечив позивачеві залучення потенційних клієнтів. Такі порушення позивач вважав суттєвими, в зв'язку з чим просив розірвати договір і стягнути сплачені за нього кошти.

З огляду на абстрактність норми ст. 651 Цивільного кодексу України, яка встановлює, що істотним є таке порушення стороною договору, коли внаслідок завданої цим шкоди друга сторона значною мірою позбавляється того, на що вона розраховувала при укладенні договору, суд в кожному конкретному випадку вирішує, чи мали місце обставини, якими обґрунтовуються вимоги позивача і якими доказами вони підтверджуються.

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

І тут традиційно виникає проблема: позивачі не обтяжують себе наданням доказової бази в розрізі наявності шкоди, встановлення причинно-наслідкового зв'язку шкоди і дій (бездіяльності) відповідача, розрахунку розміру такої шкоди і його співставленням з тим, на що розраховував позивач при укладенні договору. Очевидно, що наявність таких фактів і проведення розрахунків могли бути підтверджені відповідною експертизою, без якої твердження позивача залишаються лише його особистою думкою.

Так, в рамках описуваної справи позивач, посилаючись на наявність у виконаних відповідачем роботах недоліків і недоробок, не вказав в чому полягають ці недоліки і яким чином вони перешкоджають використанню результатів робіт. Належні та допустимі докази суттєвості недоліків і невідповідності результату виконаної відповідачем роботи вимогам, що звичайно ставляться до цих робіт (з огляду на те, що вимоги до цих робіт в спірному договорі не було визначено), а також докази непридатності цих робіт для їх використання в матеріалах справи відсутні. При цьому суд не прийняв і аргументи позивача щодо відсутності підписаного акту прийому-передачі виконаних робіт: оскільки складання і надання відповідачем позивачу акту прийому-передачі програмного продукту залежить від узгодження позивачем виконаних відповідачем робіт по розробці цього продукту, посилання позивача на відсутність актів, які він сам же і не погоджує без надання доказів суттєвості виявлених в цьому продукті недоліків, як на обставину, що підтверджує факт невиконання відповідачем зобов'язань за спірним договором, є безпідставними.

У результаті суд дійшов висновку про те, що позивач не довів факту істотного порушення відповідачем спірного договору, а також того, що внаслідок порушень відповідачем умов спірного договору позивач в значній мірі втратив те, на що розраховував при укладенні спірного договору, зокрема факт втрати можливості отримати розроблений Інтернет-сайт і потенційних клієнтів.

Підсумовуючи, варто зазначити, що експертиза - цариця доказів в подібного роду справах у сфері IT. У зв'язку зі складністю договорів і самого продукту, що надається IT-компаніями, традиційно великою кількістю додаткових угод, недостатніми або вкрай розпливчастими формулюваннями правових норм, якими регулюються правовідносини замовників і виконавців в даній сфері, експертиза може стати тим самим належним і допустимим доказом, який забезпечить обґрунтованість правової позиції та отримання справедливого судового рішення.