Чендлер; Партнер Rechtsanwälte Закон за договор за софтвер Барања за изведба во случај на неприфатеност
Во претходниот напис од 2010 година веќе известувавме за случајот со ГЛО од 25 март 2010 година (Az. VII ZR 224/08). Оваа тема е сè уште актуелна со нашите клиенти. Затоа, би сакал да погледнам уште еднаш во пресудата и да разјаснам дали давателот на ИТ-услуги мора да биде задоволен од самото барање да го исполни правилно договорот без да има индиции за тоа кој дел од софтверот сè уште не работи правилно.
Барање за извршување според законот за договори за работа
Во случај на договор за работа и услуги, изведувачот, односно давателот на ИТ услуги, го произведува софтверот во согласност со спецификацијата (доколку е достапен, во спротивно во согласност со договорите меѓу двете договорни страни).
Ова се одвива во одредена временска рамка. Доколку ова е надминато и клиентот на софтверот стане нетрпелив, тој во одреден момент ќе одреди рок за завршување на договорната услуга.
Ефективно барање за изведба
Ако клиентот има ефективно барање за изведба, ако му каже само на давателот на ИТ услуги: "Ве молиме, исполнете го договорот до xxx, во спротивно ќе се повлечеме од договорот"?
ГОБ вели: Во основа да.
Затоа што за разлика од жалба, што е само после прифаќањето се одвива, и кој мора да ја опише специфичната грешка, оди пред прифаќањето само на барањето за обезбедување на услугата како што е договорено.
Но
Што ако давателот на ИТ услуги смета дека тие го создале и имплементирале софтверот во согласност со договорот, односно дека правилно го исполниле договорот? Дали клиентот сè уште може да се повика на барањето: „Ве молиме, исполнете го договорот до xxx, во спротивно ќе се повлечеме од договорот“? Како давателот на ИТ услуги треба правилно да го исполни договорот ако тој дури и не знае што е проблемот?
Некои наши колеги се чини дека го гледаат тоа поинаку, но јас тврдам дека ова барање ќебе Не доволен!
Во случајот на Федералниот суд на правдата од 25.03.2010 година, ИТ давателот на услуги исто така побара пред прифаќањето многу специфичен опис на секој одделен дефект, т.е. специфичното отстапување на реалната состојба од целната состојба. Разбирливо е што ГЛО стави крај на ова барање. Како треба клиентот да го опише секој индивидуален дефект ако тој дури и не го прифатил софтверот дека е во согласност со договорот? Само по прифаќањето, софтверот станува конкретен за клиентот.
Во поединечни случаи, сепак, можеби не е доволно само да се побара исполнување на договорот ако давателот на ИТ услуги очигледно и од негова гледна точка легитимно претпостави дека тој го исполнил договорот. Тогаш, купувачот мора барем да каже која функционалност сè уште не е во согласност со договорот.
Според мое мислење, ова може да се заклучи од пресудата на ГОБ дискутирана овде, која вели:
„Тој [давателот на ИТ услуги] треба да може да одлучи дали сака да ги преземе последиците од несоодветно исполнување или со преземање мерки во рокот. Вистина е, сепак, дека барањето за изведба не може да ја исполни оваа намена и е неефикасно, ако претприемачот, според него, ја извршил услугата во целост и не може да забележи од поплаката покрената зошто клиентот не прифаќа дека е во согласност со договорот.
Сепак, спротивно на мислењето на апелациониот суд, од ова не може да се извлече заклучок дека барањето за извршување со рок е веќе неефикасно доколку клиентот детално не ги наведе недостатоците во изведбата. Ова го опфаќа барањето за барање за изведба, бидејќи клиентот често не е во можност да го стори тоа поради недостаток на сопствена експертиза.
Наместо тоа, доволно е, ако во овој случај се жали на функционалноста што недостасува. Соодветно на тоа, Федералниот суд на правдата го разгледа барањето за комплетирање на основната верзија на софтвер во договорениот опфат како доволно, без од клиентот да се бара да наведе постоечки дефекти во софтверот “.
Исто така, БГ објави:
„Може да има случаи кога Земајќи ги предвид посебните договорни односи и проблемите со спроведувањето на договорот, потребна е дополнителна спецификација на барањето за извршување може да биде. Овде нема таков случај.
Според истовремената презентација на страните во кратките извештаи од 30 мај 2008 година и 18 јули 2008 година, проектот напредуваше досега што не само што беше создаден концепт за адаптација на софтверот, туку прототип веќе беше развиен и инсталиран. Во согласност со „[…] договорот“ од 28 јули 2004 година, развојот на „пилотот“ способен за прифаќање и последователното „ширење“ за целата организација на [купувачот] сè уште чекаа. Ова беше лесно видливо за обвинетиот како развивач на проект. Покрај тоа, според тврдењето на тужителот, странките може да се претпостави во отсуство на спротивни наоди од апелациониот суд, Во заеднички водениот список беше заведено кои грешки треба да се отстранат. Не беше потребно да се повикаме на списокот со грешки што беше актуелен кога беше напишано писмото од 5 октомври 2004 година. Обвинетиот бил свесен за оваа листа; претходните списоци со грешки беа забележително застарени ".
Ова му го разјаснило на давателот на ИТ услуги во случајот на Федералниот суд на правдата зошто клиентот претпоставувал дека договорот сè уште не е исполнет. Во овој конкретен случај, како што експресно објаснува БГ, немаше потреба да се наведуваат грешките на софтверот во барањето за изведба.
Само затоа што ГОБ во својот водечки принцип појаснува дека нема потреба да се наведат детални недостатоци во писмо за официјално известување пред да се прифати софтверот, не значи дека тоа важи за секој случај. Не станува збор само за водечките принципи во пресудите, туку и за причините за одлуката. И, овие не значат дека клиентот треба само да побара исполнување на договорот без повеќе детали. Исто така, тоа би било апсолутно непрактично.
Во оваа смисла: среќна нова година.
Контакт
Крамер и партнер mbB Хамбург
Mönckebergstrasse 10 (Баркоф)
20095 година Хамбург
Телефон: 040 - 349 603 39
Факс: 040 - 349 603 20
Е-пошта: [email protected]
Филијала:
Крамер и партнер mbB Берлин
Ул. Рахел-Хирш-Ул. 10
10557 Берлин
Телефон: 030 - 5900 838 13