Micsoda a szerződési felelősség a rendszer- és szoftverfejlesztésben? A módosításokat magyarázzuk

Mit kell tenni jogilag, ha a rendelt rendszer hibát tartalmaz a szállítás után?

A kezelési mód bonyolult, a feldolgozási sebesség lassú, a rendelt funkciók hiányoznak… Ilyen rendszerproblémák esetén a megrendelőként a rendszerfejlesztést végző szállítóval szemben a “szerződéses felelősség” kérdését kell felvetni.

A “szerződéses felelősség” a 2017-es (Heisei 29) polgári törvénykönyv módosításával lett bevezetve, helyettesítve a megszüntetett “hibás teljesítési felelősség” koncepciót. Ezért figyelni kell arra, hogy ez a módosítás hogyan befolyásolja a rendszer- és szoftverfejlesztést.

A szállítás utáni problémák gyakran előfordulnak. Annak érdekében, hogy elkerüljük ezeket a problémákat, ismertetjük a “szerződéses felelősség” tartalmát és a módosítás hatásait.

A szerződési felelősség polgári törvénykönyvi módosítása

A ‘Polgári Törvénykönyv egyes részeinek módosításáról’ szóló törvény, amelyet 2017. június 2-án (Heisei 29) hirdettek ki, 2020. április 1-jén lépett hatályba.

A Polgári Törvénykönyvben a szerződésekkel és hasonlókkal kapcsolatos legfontosabb szabályokat a ‘Követelési jog’ rész tartalmazza.

A Követelési jogot 1896-ban (Meiji 29) hozták létre, és azóta, mintegy 120 évig, szinte semmilyen felülvizsgálat nem történt.

Ezért a mostani módosítás célja, hogy nagymértékű felülvizsgálatot végezzen, hogy megfeleljen a jelenlegi társadalomnak.

A konkrét módosítások számosak, de közülük a szerződési felelősség új fogalmának bevezetése az egyik fő módosítási pont.

Ennek eredményeként, amit korábban ‘hibás teljesítésért való felelősségnek’ hívtak, most ‘szerződési felelősségnek’ nevezik.

Mit jelent a “szerződés nem megfelelősége”

A “szerződés nem megfelelősége” azt jelenti, hogy a szerződésben meghatározott funkciók, minőség, teljesítmény vagy állapot nem áll rendelkezésre a felek megállapodása, a szerződés célja és jellege alapján.

Ezt a “szerződés nem megfelelősége” kifejezést a polgári törvénykönyv módosítása vezette be a korábbi “hiba” helyett.

A rendszer- és szoftverfejlesztésben a “szerződés nem megfelelősége” akkor fordul elő, ha a kész rendszer nem egyezik meg az előre meghatározott specifikációkkal, vagy ha a rendszer vagy szoftver nem rendelkezik a jellegéből adódóan szokásosan elvárt funkciókkal vagy teljesítménnyel.

A “szerződés nem megfelelőségének” megállapításakor a felek megállapodása, a szerződés célja és jellege kerül előtérbe.

Ezért fontos, hogy a rendszer- vagy szoftverfejlesztés célját és a megrendelés körülményeit írásban rögzítsük, és tisztázzuk, milyen elvárásokkal és elképzelésekkel rendelkezett a megrendelő.

Az esetek, amikor a szoftver hibái “szerződéses nem megfelelőségnek” minősülnek

Amikor a szoftver hibája problémát okoz, és a javítás késik

Először is, elképzelhető az a helyzet, amikor a szoftverben nem elhanyagolható hiba keletkezik, és a javítás érdekében vissza kell térni a tervezési szakaszba, vagy más gyors intézkedés nem lehetséges.

Például, ha a bevezetett raktárleltári rendszer keresési folyamata több mint 30 percet vesz igénybe, és ez problémát okoz, és a vevői megkeresésekre kézzel kell készíteni egy külön raktárkönyvet, akkor ez a helyzet a jelenlegi “szerződéses nem megfelelőségnek” minősülő “hiba” kategóriába tartozik. Ezt a tokiói bíróság is elismerte a 2002. április 22-i (Heisei 14) ítéletében.

Amikor a hibák fokozatosan jelentkeznek

Továbbá, elképzelhető az a helyzet is, hogy még ha az egyes hibák kisebbek és a javításuk nem igényel sok időt, a hibák ismétlődően jelentkeznek, és a teljes rendszer hibamentes működésének helyreállítása hosszú időt vesz igénybe.

Például, ha a bevezetett raktárleltári rendszerben ismétlődően jelentkeznek hibák, és nem világos, hogy mennyi hiba fog még jelentkezni a jövőben, és mennyi időbe telik a javításuk, és a rendszer nem használható a normál munkavégzéshez, akkor ezt “szerződéses nem megfelelőségnek” lehetne nevezni.

Az esetek, amikor a szoftver hibái nem minősülnek “szerződésszegésnek”

Amikor azonnal javítást végeznek vagy alternatív intézkedéseket hoznak

A bírósági ítéletek szerint, ha a felhasználók hibákat vagy más problémákat jeleznek, de azokat azonnal kijavítják, vagy a felhasználóval egyeztetve elfogadható alternatív intézkedéseket hoznak, akkor ez nem minősül “hibának” (Tokiói Kerületi Bíróság, 1997. február 18. (Heisei 9)).

A rendszer- és szoftverfejlesztés során lehetetlen olyan programot írni, amelyben egyáltalán nem fordul elő hiba, és elkerülhetetlen, hogy bizonyos problémák felmerüljenek.

Ezért, ha vannak hibák, de azokat azonnal kijavítják vagy más intézkedéseket hoznak, akkor ezeket nem kellene “hibának” tekinteni.

Ez a gondolkodásmód a jelenlegi “szerződésszegés” alatt is érvényes lehet.

Megjegyzendő, hogy az “azonnali” és hasonló ítéletek alapját a rendszerfejlesztés során készített jegyzőkönyvek és egyéb bizonyítékok képezik.

Az ilyen dokumentumok fontosságát a következő cikkben részletesen tárgyaljuk:

https://monolith.law/corporate/the-minutes-in-system-development[ja]

Amikor egy adott személy nem tudja könnyen megérteni a működést

A kezelhetőség és a használhatóság nagymértékben szubjektív, ezért általános felhasználók számára használhatatlan eseteket tekintik “szerződésszegésnek”.

Az, hogy egy adott személy nem tudja könnyen megérteni a működést, önmagában nem minősül “szerződésszegésnek”.

Amikor a hiba a szállító munkáján kívüli okból következik be

Ha a rendszer- vagy szoftverfejlesztő szállító fejlesztési munkájával nem összefüggő okok miatt hiba lép fel, akkor nem mondható, hogy a rendszerben vagy a szoftverben “szerződésszegés” van.

Például, ha a szállító által nem beszerzett hardver hibája miatt lép fel hiba, akkor ez nem minősül “szerződésszegésnek”.

[Kiegészítés] Amikor a felhasználó utasítása miatt hiba lép fel

Ha a felhasználó hibás utasítása miatt hiba lép fel a kész rendszerben vagy szoftverben, akkor még ha a rendszerben vagy a szoftverben “szerződésszegés” is van, a szállító alapvetően nem vállal felelősséget a szerződésszegésért.

Például, ha a vállalati rendszer fejlesztése során a felhasználó hibásan magyarázza el a csak ő által ismert körülményeket, és emiatt hiba lép fel a megállapodott specifikációk alapján fejlesztett szoftverben, akkor a szállítónak nincs felelőssége.

Ez a döntés mögött az a gondolat áll, hogy a szoftverfejlesztés során a megrendelő, azaz a felhasználó is “együttműködési kötelezettséget” vállal. A részletekért lásd az alábbi cikket:

https://monolith.law/corporate/user-obligatory-cooporation[ja]

Az építtetők és vásárlók által szerződésszegési felelősség alapján igénybe vehető jogok

Itt a rendszer- és szoftverfejlesztési szerződésekben előforduló szerződésszegési felelősséget, beleértve a módosításokból adódó változásokat is, fogjuk megvizsgálni.

Javítási igény

Ha a hiba szerződésszegésnek minősül, a megrendelő javítási igényt tehet.

A módosítás előtt, ha a hiba nem volt jelentős, és a javítás aránytalanul magas költségeket igényelt, nem lehetett javítási igényt benyújtani. A módosítás ezt a korlátozást eltörölte.

Ugyanakkor, a módosítás után is, ha a szerződésszegés nem jelentős, és a javítás aránytalanul magas költségeket igényel, a javítás lehetetlensége miatt a javítási igényt nem fogadják el.

Kártérítési igény

Ha a hibás rendszer vagy szoftver miatt a normál üzletmenet nem lehetséges, vagy többletköltségek merülnek fel, a megrendelő kártérítési igényt tehet.

A módosítás előtt, külön megállapodás hiányában, a hibáztatás nélkül is lehetett kártérítési igényt benyújtani.

Az azonban a módosítás következtében megváltozott, hogy ha a teljesítőnek mentesítő okai vannak (az adós hibájának nem tulajdonítható okok), akkor nem lehet kártérítési igényt benyújtani.

Ezért, ha a szállító bizonyítani tudja a mentesítő okokat, nem viseli a kártérítési felelősséget.

Szerződés felbontása

A rendszer vagy szoftver szerződésszegése alapján a fejlesztési szerződést fel lehet bontani.

Egy már bemutatott bírósági ítéletben (Tokiói Kerületi Bíróság, 2002. április 22. (Heszsei 14. év)) a raktárkészlet-lekérdezési rendszer keresési folyamata több mint 30 percet vett igénybe, a feldolgozási idő túl hosszú volt, és a terminál használata is lehetetlenné vált, ezért a bevezetett rendszer használatát fel kellett adni, és a szerződést fel kellett bontani.

A módosítás előtt a szerződést csak akkor lehetett felbontani, ha a hiba miatt “nem lehetett elérni a szerződés célját”. A módosítás ezt a korlátozást eltörölte.

Ugyanakkor, a módosított törvény alapján is, ha a szerződésszegés “enyhe”, a felbontást nem fogadják el, erre figyelni kell.

Díjcsökkentési igény

A díjcsökkentési jogot a módosítás hozta létre.

Ha a rendszerben hiba van, és a megrendelő a javítást kérte, de a javítás nem történt meg jelentős idő elteltével, a megrendelő díjcsökkentési igényt tehet.

A felelősség időtartama

• Javítási igény
• Kártérítési igény
• Szerződés felbontása
• Díjcsökkentési igény

Ezeknek a jogoknak a gyakorlása időben korlátozott.

Konkrétan, a megrendelő csak akkor gyakorolhatja ezeket a jogokat, ha a rendszerben vagy a szoftverben lévő szerződésszegést “egy évvel azután, hogy tudomást szerzett róla” jelzi a szállítónak.

A módosítás előtt a jogok gyakorlásának időtartama a rendszer vagy a szoftver “átadásától számított egy év” volt. Ezért azt mondhatjuk, hogy a módosítás hosszabb időt biztosított a jogok gyakorlására.

Megjegyzendő, hogy ezek az időkorlátok mellett a szerződésszegési felelősség alapján elismert jogokra a elévülési szabályok is alkalmazandók.

Ezért például, ha a rendszer vagy a szoftver átvételétől számított 11 év után értesül először a hibáról, a kártérítési igény és más jogok “tíz év” elévülési időtartamot követően elévülnek, így a szerződésszegést “egy évvel azután, hogy tudomást szerzett róla” jelzi a szállítónak, függetlenül attól, hogy a jogokat gyakorolhatja-e.

Fizetés megtagadása

A megrendelő megtagadhatja a teljes díj kifizetését, amíg a fejlesztő nem végez javítást vagy kártérítést.

A szerződési felelősség figyelembevételével a szerződési rendelkezések fontos pontjai

A szerződési felelősség rendelkezése opcionális, és a felek közötti különleges megállapodásokkal korlátozható a felelősség tartalma, vagy rövidíthető a jogérvényesítési időszak.

Ezért itt bemutatjuk azokat a szerződési rendelkezéseket, amelyekre a rendszer- és szoftverfejlesztés során figyelni kell a szerződési felelősség szempontjából.

1. pont: A szerződési felelősség tárgyát képező események és hatókör

Ha a rendszerrel vagy a szoftverrel kapcsolatban problémák merülnek fel, a megrendelő valószínűleg szerződési felelősséget kíván érvényesíteni a szállítóval szemben.

A szállító azonban nem fogadja el, hogy szerződési felelősséget érvényesítsenek ellene, csak azért, mert valami nem tetszik, még akkor sem, ha az csak egy specifikáció.

Ráadásul a szállító a jogtalan szerződési felelősség érvényesítése miatt jelentősen megemelheti az árajánlatot, ami hátrányos a megrendelő számára.

Ezért fontos, hogy a megrendelő írásban jelezze, milyen céllal és milyen funkciókkal rendelkező rendszert szeretne bevezetni, és hogy ezeket a specifikációkban biztosan tükrözze, hogy tisztázni lehessen a szerződési felelősség tárgyát képező események és hatókört.

Fontos lehet azt is tisztázni, hogy ha a specifikációban meghatározottak szerint szállítják a rendszert vagy a szoftvert, akkor még ha vannak is specifikációs problémák, az nem minősül szerződési felelősségnek.

Ezzel a rendelkezéssel megelőzhető, hogy a megrendelő ízlése szerint a szerződési felelősséget érvényesítsék, annak ellenére, hogy a fejlesztést a specifikációk szerint végezték.

2. pont: A garancia időtartamának tisztázása

A szerződési felelősség jogérvényesítési időszaka nem a termék “átadásakor”, hanem a szerződési felelősség “tudomásulvételétől” számítódik.

Ráadásul, még ha alkalmazható is a külön elévülési idő, annak időtartama legfeljebb “tíz év”, ami hosszú időszakot jelent.

A szállító számára a “tíz év” hosszú időszak alatt történő ingyenes garancia jelentős terhet jelent, és ezt az árajánlat szakaszában hozzá kell adnia.

A megrendelő számára is előnyös lehet a rendszer vagy a szoftver használati idejének megfelelően rugalmasan beállítani a garancia időtartamát, mivel ez költség szempontjából előnyös lehet.

Ezért érdemes lehet a rendszer tartalmától függően rugalmasan beállítani a garancia időtartamát.

3. pont: A szerződési felelősség bekövetkezte esetén a teendők

Ha szerződési felelősség merül fel, a felek közötti megállapodás alapján korlátozhatók a polgári törvénykönyvben elismert jogok közül azok, amelyeket érvényesíteni lehet.

A megrendelőnek meg kell értenie, milyen korlátozások vannak a szerződésben.

Összefoglalás: A “szerződési felelősség” bevonásával készült szerződések készítésében forduljunk ügyvédhez

A Polgári Törvénykönyv módosítása jelentős hatással volt a rendszerek és szoftverek fejlesztésének jogi vonatkozásaira is.

Ha a szállított rendszer hibás, nem lehet egyértelműen megmondani, hogy ez “szerződési felelősség” alá esik-e, és milyen felelősséget lehet feltenni.

Továbbá, a viták megelőzése érdekében elengedhetetlen, hogy a fejlesztési szerződés szakaszában megfelelő konzultációt folytassunk a megrendelő és a szállító között.

Ha kétségei vannak a szerződés készítésével kapcsolatban, kérjük, forduljon szakértő ügyvédhez.