A SZOFTVERKÉSZÍTŐ JOGI FELELŐSSÉGE A FELHASZNÁLÓK FELÉ

Írta: Turai Katalin

2002.12.06.

1
Tartalom:

BEVEZETŐ 1

A SZOFTVERÉRTÉKESÍTÉS LEHETSÉGES MÓDJAI 1

Dobozos s zoftver 1

Egyéni szoftverek 1

Testre szabott szoftverek 1

SZOFTVERÉRTÉKESÍTÉSI SZERZŐDÉS ELEMZÉSE EGYEDI, MEGRENDELÉSRE GYÁRTOTT

SZOFTVER ESETÉN 1

A szerződés létrejötte 1
Tévedés 1

A SZOFTVERFELHASZNÁLÁSI SZERZŐDÉS TELJESÍTÉSÉNEK MENETE 1

Átadás 1
Milyen jogokat adhat át a fejlesztő? 1
A jogszavatosság kérdése 1
A forráskód visszatartás következményei 1

Elfogadás 1
A szavatolt minőség kérdése 1

A hibás teljesítés sajátos szerzői jogi jogkövetkezménye: a kijavításra való visszaadás 1

Mikor indokolt a kijavítási igény? 1
Az együttműködési kötelezettség 1
A kijavítási idő 1

Elállás díjazás nélkül, vagy mérsékelt díjazással 1

A softwarekkel kapcsolatban előforduló minőségi hibák természete 1
A hibák keletkezése 1
A teszteléssel kapcsolatos problémák 1
Saphena Computing v Allied Collection Agencies 1

2
 St Albans DC v International Computers Ltd. (ICL) 1
Eurodynamic 1

Részteljesítés 1

A hibás teljesítés következményei 1

A szoftverfejlesztési szerződés jellege 1

A SZERZŐDÉSES FELELŐSSÉG KIZÁRÁSA 1

SZERZŐDÉSEN KÍVÜLI FELELŐSSÉG ESETEI: 1

I. TERMÉKFELELŐSSÉG 1
Bevezető 1

A termékfelelősség feltételei 1

Termék-e a szoftver? 1

II KLASSZIKUS KÁRTÉRÍTÉSI FELELŐSSÉG 1

3
Bevezető

- a dolgozat témája – nem a statikus, szerzői jogi oldal, hanem az értékesítés

- a szoftver, mint a szerződés közvetett tárgya, sajátos annyiban, hogy szellemi alkotás,
tehát többnyire a felhasználó nem szerez tulajdonjogot rá, hanem csak felhasználási
engedélyt és így a szerzővel hosszú távú jogviszonyba kerül. Ez a jogviszony leginkább
a bérlethez hasonlít, hiszen a használó rendelkezési jogát a szerző („tulajdonos”) jogai
folyamatosan korlátozzák és meghatározzák, és ha a felhasználó szerződésszegő módon
használja a szoftvert akkor, végső esetben a nála lévő műpéldány megsemmisítésére is
kötelezhető.

- a szoftver jogi sajátossága nem merül ki abban, hogy szellemi alkotásként a szerzői jogi
törvény hatály alá esik, hanem mint szerzői mű is sajátos. A legtöbb művészeti és
tudományos alkotással ellentétben, ugyanis a szoftver többnyire előre jól meghatározott
gyakorlati funkciók ellátására jön létre. A szoftver funkcionális volta, viszont kihat a
szerző és a felhasználó viszonyára. A felhasználó ugyanis kifejezetten azért szerzi be a
szoftvert , hogy azt bizonyos feladatok ellátására használni tudja, éppen ezért csak akkor
köt szerződést, ha a szoftver megalkotója a funkcionális működtetés lehetőségét számára
garantálja. Ebből kifolyólag, nemcsak a felhasználónak kell vállalnia, hogy a beszerzett
szoftvert jogszerűen használja, hanem az alkotóra is többletkötelezettségek hárulnak,
amennyiben a használat időtartamára garantálni kell, hogy a szoftver rendeltetésszerűen
működik, használható.

- További jogi kérdéseket vet fel, a felek viszonya vonatkozásában, ha a szerződést nem
egy már létező műre, hanem még létrehozandó alkotásra kötik, ez esetben a mű
elkészültéig a felek szoros együttműködésére van szükség, mely leginkább a Ptk.
vállalkozási szerződésében rendezett viszonyra hasonlít, ám a felek közötti viszonyt
explicit módon mégis csak egy felhasználási szerződés rendezi.

4
A szoftverértékesítés lehetséges módjai

Dobozos szoftver

A kereskedelmi forgalomban megtalálható dobozos szoftver vásárlása esetén, a terméket

képező anyagi hordozó és az azon lévő program jogi megítélése eltérő. Míg a vásárló az
adathordozó lemezen tulajdonjogot szerez, az azon lévő program használatára felhasználói
engedélyt kap. Míg az adásvételi szerződés a vevő és az eladó között ráutaló magatartással is
létrejöhet, a felhasználói engedélyt főszabály szerint írásos felhasználási szerződés keretében
kellene a vevőnek a szerzőtől megkapnia. Mivel ez a tömeges terjesztés során csak nagy
nehézségek árán kivitelezhető, a Szjt kivételképpen megengedi dobozos szoftver esetén,
hogy a felhasználási szerződést ne kelljen írásba foglalni. Ez a megoldás a szerzői
jogvédelem kérdését annyiban oldja meg, amennyiben feltételezzük, hogy a vevő ráutaló
magatartással a szoftver dobozán olvasható licencia engedély kikötéseit elfogadja. A
csomagoláson olvasható engedély rendszerint kijelöli a felhasználás korlátait, így azt is, hogy
a felhasználó a szoftvert harmadik személyre nem ruházhatja át. Ennek köszönhetően a
könyvek esetében alkalmazott jogkimerülés intézménye szoftvereknél nem érvényesül. Amíg
a könyv vásárlója nem szerez felhasználási jogot, hiszen a műpéldány elolvasása szerzői
jogot nem sért, a szoftver vevője csak felhasználási engedéllyel együtt vásárolhat olyan árut,
amit legálisan tud is használni. (Ennek technikai oka van, szoftver csak másolás útján
“olvasható”.)
A szoftverfuttatás felhasználási engedélyhez kötöttsége vezet oda tehát, hogy míg a
papíralapú szerzői műveknek van másodlagos piaca, a szoftvereknek (jogszerűen) nincs.

A szerző felelősségét dobozos termék esetén a termékfelelősség körében fogom tárgyalni,

abból kiindulva, hogy tömegcikk esetén többnyire, a szerző és a végfelhasználó között
szerződéses kapcsolat nincs.

Egyéni szoftverek

Egyéni szoftverről, akkor beszélünk, ha a fejlesztő közvetlenül a megrendelő igényei szerint

készíti el az adott művet. Ebben az esetben a felhasználó és a szerző felhasználási szerződést
kötnek a jövőben megalkotandó műre, és viszonyukat optimális esetben, részletekbe menő

5
tárgyalások eredményeképpen kimerítően szabályozzák.

Testre szabott szoftverek

Ebbe a típusba tartozó szoftverek esetén, a fejlesztő egy már elkészült művön végez kisebb
átalakításokat, a megrendelő igényeihez mérten.
A megrendelő ebben az esetben sincs feltétlenül kapcsolatban az általa igényelt szoftver
szerzőivel csak a fejlesztő céggel. Amennyiben a fejlesztők nem a saját művüket módosítják,
erre megelőzően engedélyt kaptak az eredeti szerzőtől. A végfelhasználó ilyenkor két külön
licenciát kap, egyet az eredeti termék használatára az eredeti szerzőtől, a másikat a testre
szabott mű felhasználására közvetlenül a fejlesztőtől.

Szoftverértékesítési szerződés elemzése egyedi, megrendelésre gyártott szoftver esetén

Amint azt a fentiekben vázoltam e szerződési forma esetén van leginkább szükség a
szerző és a felhasználó szoros és hosszan tartó együttműködésére, épp ezért ezen szerződések
igénylik a leginkább a minden részletre kiterjedő kidolgozást, és ezekkel kapcsolatban merül
fel a legtöbb jogvita. Az egyedileg gyártott szoftverek magas költségére tekintettel az ide
tartozó esetek kerülnek többnyire a bíróságok elé is.
A fejezetben kronologikus sorrendben veszem végig a szerződéses kapcsolat
folyamatát, és az egyes stációknál kitérek a gyakran előforduló problémákra.

A szerződés létrejötte

Tévedés

Gyakori vita forrása, hogy a felek drasztikusan eltérő szakmai hátteréből kifolyólag csak
látszólag jön létre akarategység a szerződés tárgyát illetően.
International Business Machines v Catamore Enterprises Inc
CORP 153,154

Az ügyfél azt hiszi, kész programot (gépi kód ) kap, holott csak egy rendszertervet (systems design) rendelt meg.

6
A szoftverfelhasználási szerződés teljesítésének menete

Átadás

Milyen jogokat adhat át a fejlesztő?

Jogátruházás – előnye, hátránya

- kizárólagos, nem kizázólagos felhasználási jog.

A jogszavatosság kérdése

Ptk adásvétellel analóg módon szükséges

A forráskód visszatartás következményei

A szoftverfejlesztők megrendelőiknek többnyire felhasználási szerződés keretében

endegélyeznek használati jogokat, de nem ruházzák át a szoftverrel kapcsolatos vagyoni,
szerzői jogi jogosultságokat. Éppen ezért a szoftver többnyire tárgykód formában kerül a
felhasználóhoz, míg a forráskód a fejlesztőnél marad. Ennek gyakorlati következménye, hogy
a felhasználó a szoftvert használni ugyan tudja, de módosítani vagy “frissíteni “ már nem.
(Maintain) A felhasználó így a használat egész tartamára függővé válik a fejlesztőtől ezen
szolgáltatások tekintetében. (Igaz a gyakrabban használt szoftverek esetében, vannak már
külső, harmadik személy karbantartó cégek is, de a speciális egyedi rendszerekhez ezek
nem nyúlnak.) Így tehát, ha a fejlesztő megszűnik, vagy valamilyen más okból nem tudja
többé a szükséges változtatásokat végrehajtani, az a felhasználóra nézve súlyos
következményekkel jár, melyek elhárítására bevett megoldás a forráskód letétbe helyezése.
A probléma másik gyakori megoldási módja a visszafejtés, -dekompiláció, azaz a forráskód
visszafejtése a tárgykódból. A visszafejtéssel kapcsolatban azonban egyrészt gyakorlati
probléma, hogy nagy szakértelmet kíván, így a felhasználó kénytelen extra költségekbe verni
magát, és szakembert keresni a munka elvégzésére, másrészt, ha sikerül is a visszafejtés, az
így nyert forráskódot jogszerűen csak annyiban lehet felhasználni, amennyiben az a szoftver
rendeltetésszerű működéséhez szükséges, de már új funkciók létesítése, bármilyen
szoftvermódosítás, ami túllép a hibajavításon, a szerzői jogok megsértésének minősül. A
Szoftverirányelv elfogadása előtt, maga a dekompiláció is jogsértő volt, sok szerződés
kifejezetten tiltotta, de mára a felhasználók érdekében, az Irányelv az ilyen tilalmakat
érvénytelennek minősíti. (Szoftverirányelv 5/1- Az Irányelv nyomán ezt az Szjt .. szakasza is
kimondja.)

7
Elfogadás

A szavatolt minőség kérdése

Az átadással kapcsolatos kérdéskörnek egyik vetülete, hogy milyen jogokat szerez a

felhasználó a kapott szoftveren. Az átadás másik sarkalatos pontja, az hogy milyen minőségű
szoftvert köteles a megrendelő elfogadni. Azaz milyen minőségi követelményeknek kell a
szoftvernek eleget tennie, ahhoz, hogy a fejlesztőnek járjon a kiszabott díj. Mi számít
szerződésszerű teljesítésnek?

A szoftverekre, elsődlegesen a Szjt. szabályai irányadóak, és azokban a kérdésekben,

amelyekről e törvény nem rendelkezik háttérszabályként lép be a Ptk.
A teljesítés minőségével kapcsolatban a Szjt. kifejezetten nem rendelkezik, így a kötelmi
általános rész ide vonatkozó szakaszai alkalmazandóak (BH 1992/6. 389.). Ezek szerint a
szerződéseket a tartalmuknak megfelelően, a megszabott helyen és időben , a megállapított
minőség szerint kell teljesíteni. Továbbá a szolgáltatásnak alkalmasnak kell lennie arra, hogy
azt rendeltetésének, illetőleg a szerződésben kikötött vagy egyébként a kötelezett által ismert
célnak megfelelően lehessen felhasználni. (Ptk 277/1)

A hibás teljesítés sajátos szerzői jogi jogkövetkezménye: a kijavításra való visszaadás

Mivel a jövőben megalkotandó művekre kötött szerződések esetében, - amilyen a

szoftverfejlesztési szerződés is, a mű felhasználásra való alkalmassága szükségképpen
bizonytalan, az Szjt szabályozza az elkészített mű elfogadását, és lehetővé teszi a kijavításra
való visszaadást.
Jövőben megalkotandó műre vonatkozó szerződés esetén, az átadott szoftver
elfogadásáról, a felhasználó az átadástól számított négy hónapon belül köteles nyilatkozni.
(Szjt 49/1, 60/4)
Amennyiben a művet kijavításra visszaadják, ez a határidő a kijavított mű átadásától
újra kezdődik, és mivel jövőben megalkotandó művek esetén, az elkészült művet a
szerzőnek kijavítás végett ismételten is vissza lehet adni (Szjt 49/2), az átadás - el nem
fogadás - újabb átadás - újabb el nem fogadás köre könnyen ördögivé válhat. Ennek
elkerülésére a törvény két megszorító feltételt köt ki: - a kijavítási igénynek indokoltnak kell

8
lennie és a kijavításra megfelelő határidőt kell tűzni. Ha a szerző a kijavítást határidőre nem
végzi el, a felhasználó a szerződéstől dífizetés kötelezettsége nélkül elállhat. (Szjt. 49/3)
Ha a szerző végül, a póthatáridőre sem tud a kijavítási igénynek eleget téve teljesíteni, a
felhsználó elállhat.

Mikor indokolt a kijavítási igény?

A kijavítási igény akkor indokolt, ha a szolgáltatás az imént idézett Ptk. -beli főszabály
szerint ( 277/1) hibás teljesítésnek minősül. Ezzel kapcsolatban különösen két kitétel adhat a
szoftverek vonatkozásában vitára okot, mégpedig, - egyrészt az, hogy a szolgáltatásnak a
szerződésben meghatározott minőségűnek kell lennie, - másrészt pedig az, hogy alkalmasnak
kell lennie a felhsználó mindazon céljaira, amiről a kötelezettnek tudomása volt.
A szerződésben meghatározott minőség
- része –e a szerződésnek az előzetes reklám, mi képezi részét?
- core és nem core funkciók ?
A megrendelő céljaira való alkalmasság
A 277/1 szakasz utolsó fordulatára - miszerint a szolgáltatásnak a kötelezett által
egyébként ismert célra is alkalmasnak kell lennie, a jogosult csak abban az esetben tud
sikeresen hivatkozni, ha ezt bizonyítani is tudja. A szolgáltatás alkalmatlanságát ugyanis,
jogvita esetén, a Pp. 164/1 alapján, a felhasználónak kell bizonyítania.. Tekintettel arra, hogy
a felhasználási szerződésnél formai követelmény az írásbeliség, a bíróságok megkövetelik,
hogy a szolgáltatásra vonatkozó minőségi meghatározások is az írott szerződés részét
képezzék. A minőségmeghatározáskor megkövetelt részletesség szemléltetésére idézem a
következő példát:

BH 1992.389
Xxx az eset eleje

A Legfelsőbb bíróság az első fokon meghozott ítéletet és indoklását helybenhagyta.

A bíróság a felperes felhasználó szerzői díj visszatérítése iránti keresetét azzal az indoklással
utasította vissza, hogy:
- A felek szerződése nem tartalmazta a megalkotandó szoftverrel szemben támasztott
követelményeket, ezért a felperes nem hivatzkozhat arra, hogy a mű alkalmatlan az általa

9
megkívánt rendeltetésnek megfelelő használatra.
Habár a szóbanforgó esetben a szerződés a program rendeltetését megjelölte, nevezetesen,
hogy a a szolgáltatás olyan számítógépi program és a hozzá tartozó dokumentáció
elkészítésére vonatkozik, amely a Commodore 610 vagy PC típusú számítógépen biztosítani
fogja a felperes számlázási rendelésállományával és árukészletével öszzefüggő adatok
nyilvántartását, a bíróság ennyi specifikálást nem tartott elegendőnek.
“A felek szerződése nem tartalmazta, hogy a felperes milyen adatokból, milyen pénzügyi,
gazdasági algoritmusok alkalmazásával, milyen tartalmú és külalakú eredményeket kívánt
kapni, továbbá mely adatokat és eredményeket kívánt tárolni.”
A sikeres bizonyításhoz tehát a bíróság a támasztott követelmények egyértelmű, részletes,
írásbeli meghatározását kívánja meg.
K: Szerző javára történő értelmezés itt is???

Az együttműködési kötelezettség

A szerződés fogyatékosságain túl a bíróság a teljesítéssel kapcsolatos dokumentáció

hiányosságát is kifogásolta:
“hiányoznak a részteljesítések átadásáról szóló jegyzőkönyvek, hiányoznak az üzemelés
hibáit rögzítő feljegyzések, nem állapítható meg, hogy az alperesek pontosan milyen
javításokat végeztek, és a mágneslemez példányainak mindegyik peres félnél való
megsemmisülése, valamint a forráskód hiánya miatt a szerződés nem megfelelő teljesítésének
a megítélése bizonytalan.”
Szoftverfejlesztési szerződéseknél felek hosszú időn át tartó, aktív együttműködése
nélkülözhetetlen feltétele a megrendelő céljaira is alkalmas teljesítésnek. A bíróságok erre a
hosszabb időn át fennálló, kölcsönösen kiszolgáltatott helyzetre tekintettel követelik
meg, hogy a felek csak akkor hivatkozzanak a másik szerződésszegésére, ha a saját
együttműködési kötelezettségüknek eleget tettek, és ezt bizonyítani is tudják.

BH 1989/102

A felek “Fejlesztési - Vállalkozási keretszerződés” című megállapodásukban vállalták, hogy

az alperes termelésirányítási és elszámolási rendszerének korszerűsítése érdekében, hosszabb
távon együtt fognak működni. A felperes vállalta, mind a gazdasági- információs folyamatok

10
átsrtukturálását, az újonnan létrehozott korszerű munkamegosztásnak megfelelő rendszerterv
elkészítését, és az ennek megvalósításához szükséges programozási célfeladatok elvégzését.
Az alperes a teljesítésben való aktív részvétel körében, a vállalati ismeretek biztosítását és a
megvalósítás tárgyi és személyi feltételeinek megteremtését vállalta. Ezen túl a felek
kölcsönös szerződéskötési kötelezettség mellett arról is rendelkeztek, hogy az egyes fázisokra
résszerződéseket kötnek. Továbbá, hogy a köttelezett által készített rendszerterv tartami
felülvizsgálatát közös zsüri fogja elvégezni.
A 83 decemberében kötött szerződés teljesítésének határidejét 84 decemberében határozták
meg azzal, hogy 85 januárjára a rendszer üzemképes lesz, és azon az alperes a számítógépes
felgolgozást megkezdheti.
A díjazással kapcsolatban részletfizetésben állapodtak meg, miszerint a fejlesztő a
szerződéskötéskor a díj 30 %át, a zsüri jegyzőkönyv felvétele után a díj 40%át kapja kézhez,
míg a maradék 30%ot az alperes a sikeres próbaüzemeltetés után fogja megfizetni. A
kikötött díjat összegszerűen is előre meghatározták.
A megvalósulás az eredeti tervekhez képest sokat késett, ugyanis a rendszerterv 85-
ben került átadásra, a számítógépi programok egy része pedig 86-ban, az alperes eddigre, az
eredetileg kikötött díjnak mintegy felét fizette meg.
A felperesek kereseti kérelmükben azt állították, hogy a szerződés teljesítése az alperesnek
felróható okból meghiúsult, és az alperes köteles az addig nyújtott szolgáltatások után járó
díjat megfizetni, ami az eredetileg kikötött összegnek körülbelül a 80%a lett volna.
Az alperes védekezésében kifejtette, hogy mivel a felperes az 1987 március 31-re módosított
teljesítési határidőre sem szolgáltatta a szerződésben kitűzött cél elérésére alkalmas anyagot, a
szerződéstől elállt. A kifizetett díj visszatérítése után viszontkeresetet terjesztett elő.
A bíróság első fokon a felperes kereseti kérelmét elutasította, és a viszontkereset
alapján kötelezte őket a kapott díj visszafizetésére is. A bíróság indoklásában a szakértői
véleményre hivatkozott, miszerint:
a felperesek kötelezettségeiket nem teljesítették, nem szolgáltattak szoftver , így a jogosultnak
sem volt miről elfogadó nyilatkozatot tenni. A szakértői véleményben az is szerepelt, hogy az
“alperes a az együttműködés során a minka végtéséhez minden tőle telhető segítséget
megadott.”
A felperes fellebbezésében sérelmezte, hogy a bíróság figyelmen kívül hagyta a
Keretszerződés együttműködési köteklezettségről rendelkező részeit, - álláspontjuk szerint az
alperes mulasztásai okozták a teljesítési határidő módosítását és tették lehetetlenné a
szerződés maradéktalan teljesítését.

11
 A Legfelső Bírósáag az első fokon meghozott ítélet hatályon kívül helyezését és új
eljárás lefolyttatását rendelte el. Indoklása szerint:
A jövóben megalkotandó szerzői jogi védelem alatt álló művek elkészítése általában a
megrendelő útmutatásai szerint történik. A felhasználó gazdálkodási rendszerzét érintő
szoftveralkotás elkészítése pedis szükségszerűen igényli a felhsználó által ellátott szervezési,
üzemeltetési, és egyéb adatfeldolgozási falyamatoknak a megismerését a szerző részéról.
Az első fokú bíróság ezért alaptalanul mellőzte annak viysgálatát, hogy az aalperest milyen
együttműködési kötelezettség terhelte, és ennek milyen mértékben tett eleget. Nem volt
mellőzhető továbbá, annak felderítése sem, hogy a kölcsönösen vállalt szerződéskötési
kötelezettség ellenére a szerződéskötések az egyes fázisokra miért maradtak el, és ez milyen
hatással volt a felprese teljesítésére.
A ptk 277/szakasza rendelkezik arról, hogy a feleknek a szerződés teljesítése érdekében
együtt kell működniük, így a felperes szerződésszegésének megítélése az alperes
együttműködési kötelezettségének megállapításától nem független kérdés.
Erre tekintettel az újabb eljárás során az első fokú bíróságnak tüzetesen fel kell derítenie a
tényállást, a felek együttműködésével, teljesítéssel összefüggő tevékenységével kapcsolatban.
A határozat kitért az első fokon alkalmazott szakértői véleményre is, és megállapította, hogy
a tények részletekbe menő felderítése nélkül, a szakértő megállapítása, miszerint az alperes
“minden tőle telhető segítséget megadott”.

A felhasználó tehát csak akkor állhat el a a szerződéstől díj fizetése nélkül, ha a teljesítés
érdekében , úgy járt el ahogy az az adott helyzetben elvárható volt, ennek ellenére a teljesített
szolgáltatás hibásnak bizonyult, ezek után a szerzőt, megfelelő határidő tűzésével kijavításra
felhívta, és kijavítást a szerző az újabb határidőre sem végzi el. A visszaadás indokoltsága és
az együttműködési kötelezettség elemzése után, most a megfelelő határidő szabásával
kapcsolatban felmerülő problémákra térnék rá..

A kijavítási idő

A kijavításra való visszaadásra is vonatkozik a Ptk 5§-ban rendeltetésszerű joggyakorlás

elve, éppen ezért a kijavításra tűzött határidőnek megfelelőnek kell lennie. A határidő, akkor
megfelelő, ha a kért javítás terjedelmével összhangban van. A LB (BH 1983.16. számú)

12
döntésében rámutatott arra, hogy a felhasználó nem gyakorolhatja, a sikertelen kijavítás
esetére fennálló elállási jogát, amennyiben a kijavításra nyilvánvalóan túl rövid időt ad a
szerzőnek. A szóbanforgó eset egy kiadói szerződéssel volt kapcsolatos, ahol javítás címén a
kiadó szinte a könyv teljes átírását kívánta volna meg, és minderre a szerzőnek 20 napot
biztosított. Egy könyv koncepciót is érintő átdolgozása esetén ez laikus szemmel nézve is túl
(már már rosszhiszeműen) rövid határidőnek bizonyul. Szoftverek esetében az indokolt
hosszúságú határidő megállapítása nemigen lehetséges a laikus számára, mindenesetre az elv
ezekre a szerződésekre is megáll.

Szjt 49/3
Ha a szerző a kijavítást alapos ok nélkül megtagadja, a felhasználó a szerződéstől díjfizetési
kötelezettség nélkül elállhat.
Mi számít alapos oknak?
Az alapos ok fennállta többnyire az együtműködési kötelezettség valamilyen megszegésére
vezethető vissza, így:
- alapos ok ha a kijavítási kérelem nem részletezi kellő mértékben a kijavítandó részeket. Így
alapos oknak számított, amikor a megrendelő a belsőépítész terveit, azzal adta vissza, hogy az
nem kivitelezhető, anélkül, hogy konkrétan megjelölte volna mire terjedjen ki a javítás. BH
1992.524

Alapos oknak számít az is, ha a kijavítás címén kért átdolgozás majdnem egy új mű
elkészítését jelentené. (BH 1983/16. A kiadó a megrendelt könyv koncepciót is érintő átírását
követelte.) Ez az eset szoftverszerződéseknél különösen gyakran előfordul, ugyanis nagyon
sokszor a megrendelő tesztelés közben ébred rá, hogy a szoftvert még további, eddig meg
nem jelölt feladatokra is szeretné használni.
Ha a kijavítási kérelem a szerződésben meg nem jelölt felhasználásra való alkalmasság
elérésére irányul, az nem más, mint burkolt szerződésmódosítás. Az ilyen kérés nemcsak
jogi, hanem technikai problémákat is felvet. A fejlesztő ugyanis vagy az eredeti rendszert
módosítja, és azt kockáztatja, hogy a rendszer lassul, újabb kis hibákat produkál, és
legrosszabb esetben “összeomlik”, vagy teljesen új struktúrájú programot kell létrehoznia. A
vevő viszont nem érti, hogy miért is kell neki egy munkáért kétszeres díjat fizetnie, vagy
pedig a módosított program lassúságára fog panaszkodni. Ha a szerző kerek perec megtagadja
a kért funkciól beépítését, a felek közötti kapcsolatot az is megrontja. A megoldást csak az
jelentheti, ha a szerződéskötés idején a felek fokozottan együttműködnek, a megrendelő

13
szükségleteinek és lehetőségeinek a feltérképrzésekor, és meggyőződnek róla, hogy a
megrendelő valóban azt kérte, ami az igényeinek megfelel. Valamint, hogy tudatában volt
annak, mi az a funkció, amit esetlegesen az adott tevékenységéhez kapcsolódóan kérhetett
volna még, de megfontolt szándékkal nem kérte. Ehhez természetesen nem elegendő, a
szakember informatikai tudása, a rendszer megtervetéséhez a mmegrendelőnek is részletes
tájékoztatást kell adnia saját munkafolyamatairól, működéséről. Ezen kívül érdemes a
megrendelő figyelmét arra is felhívni, hogy a programok utólagos módosítgatása, csak szűk
keretek között lehetséges, úgyhogy fontos, hogy már az eredeti terv minden lényeges funkciót
tartalmazzon.

Elállás díjazás nélkül, vagy mérsékelt díjazással

Ha a mű a javítás után sem alkalmas a felhasználásra, a szerzőt csak mérsékelt díjazás illeti
meg.(49/4 )

Ha a kijavítás a felek együttműködése ellenére sem éri el a kívánatos célt, a szerzőt

mérsékelt díjazás illeti meg. Tehát főszabály szerint a kockázat megoszlik a két fél között, ami
művészeti alkotások, tudományos művek tekintetében érthető. Ám szoftverek esetén, ahol a a
fejlesztő vállalja, hogy egy bizonyos funkció ellátára képes szoftvert hoz létre, akkor ez a
vállalás azt is magában kell, hogy foglalja, hogy a fejlesztő képes az adott funkciókat ellátó
szoftver létrehozására. Ellentétben például egy filmhez írt zenével, ahol ahol a mű
alkalmasságának megítélése pusztán ízlésbeli kérdéseken is múlhat, a szoftver elsősorban
nem esztétikai , hanem funkcionális értékkel bíró alkotás, és mint ilyen a megítélése is előre
kiszámítható. (Hiszen nem a “szépsége”, hanem a funkcióra való alkalmassága lesz
elfogadáskor a döntó szempont.) Éppen ezért a fejlesztő a rendeltetésére alkalmas mű
létrehozásáért szigorúbban kellene, hogy feleljen, mint adott esetben a zeneszerző. Ha a
fejlesztő egy olyan rendszer elkészítését vállalja, ahol eleve nagy a kockázata annak, hogy
az adott rendszert nem lesz képes létrehozni, tehát előre láthatóan, a megrendelő rovására
fog kísérletezni, és ezt a másik féllel nem közli, akkor a szerződéses partner
megtévesztéséről van szó. Ha a fejlesztő nem szándékosan, de gondatlanságból nem méri fel a
feladat terjedelmét, akkor a másik felet a saját szakértelme kérdésében tévedésben tartja. A
szerződés mindkét esetben megtámadhatóvá válik, és a jogosultnak kártérítési igénye
keletkezik. Ehhez képest érdemes végiggondolni a szerzőnek járó mérsékelt díjazás összegét.

14
Az, hogy a filmhez megírt zene, a rendezőnek végül mégsem tetszik, a zeneszerzőnek nem
felróható, és méltánytalan volna a díját ezért tetemesen csökkenteni, míg a szoftver
alkalmatlansága többnyire visszavezethető valamilyen a szerzőnek is felróható okra.
Amennyiben ez az ok a culpa in contrehendo körébe tartozik, vizsgálandó, hogy miért nem
sikerült a feleknek eredményesen felmérni a fejlesztőre váró feladatot, és ezek szerint kell a
díjat mérsékelni.

Hasonló jellegű kockázatmegosztást találunk a vállalkozói szerződéseknél, ha a szolgáltatás

mindkét fél érdekkörében, vagy érdekkörén kívül felmerülő ok miatt válik lehetetlenné. Ami
azt fejezi ki, hogy nem egyik vagy másik félnek felróható, vagy egyik vagy másik fél által
megelőzhető okról van szó. Az alkalmatlan szoftver készítése véleményem szerint nem
tartozik ebbe a kategóriába. (Míg a filmrendezőnek nemtetsző,de a zeneszerző legjobb tudása
szerint megírt filmzene például már ilyen lehet.)

A fentiek összegzéseképpen, ha a szoftver valamely alapvető funkciójának nem képes eleget

tenni, akkor indokolt lenne, az eredményért ugyanúgy felelnie, mint a vállalkozási szerződés
kötelezettjének. Másfelől egy szoftver rendszer számtalan olyan hibát produkál, ami nem
minősül alapvetőnek, és idővel javítható.

A szoftverek hibáinak sajátosságai

A softwarekkel kapcsolatban előforduló minőségi hibák természete

A hibák keletkezése

A tömegesen gyártott árucikkekkel kapcsolatban előforduló hibák, hiányosságok két módon

jöhetnek létre, vagy a tervezéskor, vagy a gyártás folyamán. Mivel tervezési hiba esetén
az összes termék hibás, a hiba meglétét gyakran csak nehezen, többé- kevésbé hasonló
termékekre való hivatkozással lehet bizonyítani.. (pl. gyógyszeripar)
Ezzel szemben a gyártási szakaszban létrejövő hibáknál, többnyire csak néhány termék sérül,
és a hiányosságot, a többi azonos termékkel való összemérés során egyértelműen bizonyítani
lehet.
Softwarek gyártásának (digitális másolás) sajátossága, hogy minden egyes termék identikus,

15
így csak a nehezebben bizonyítható tervezési hibával lehet számolni. A vevőnek tehát vagy
más gyártók hasonló termékeire, vagy pedig általános ipari (szakmai) standardekre kell
hivatkoznia.

A teszteléssel kapcsolatos problémák

Az előzetes tesztelés soha nem terjedhet ki a felhasználás minden lehetséges módjára.

Mindig lesznek olyan hibák, amelyek a felhasználás során csak esetlegesen, bizonyos
tényezők együttállása esetén lépnek fel. Ezért a software iparban általánosan elfogadott
gyakorlat, hogy potenciális hibákat tartalmazó terméket dobnak piacra, majd a vevők
visszajelzései nyomán készítenek el újabb és újabb verziókat. Nyílt titok, hogy hibátlan
software nincs, a tesztelés egy részét a felhasználó maga végzi.

Az alábbiakban ismertetett angol eset, azt

Saphena Computing v Allied Collection Agencies

- hibás telj, szerződésszegés/ kis hiba

A felperes S. egy kisebb szoftverfejlesztéssel foglalkozó vállalat, egyedi megrendelésre
készített saját fejlesztésű, illetve testre szabott szoftvereket. Az alperes ACA egy
adóbehajtásra specializálódott cég.
A felek között létrejött első szerződés értelmében S. szoftvereket szolgáltatott az alperes
ACA-nak. Az első teljesítésre 1985 februárjában került sor, és néhány kisebb, sikeresen
kijavított hibát leszámítva, a szoftver 1985 májusáig kielégítően működött. Augusztusban a
felek újabb szerződést kötöttek további szoftverek szállítására. Az új szoftverek célja, a már
meglévő rendszer frissítése lett volna. Installálásuk közben kiderült azonban, hogy a már
meglévő és az új szoftver nem teljesen kompatibilis, így kisebb változtatásokat kell
végrehajtani, ráadásul a megrendelő is újabb kívánságokkal állt elő. S. megpróbálta elvégezni
a szükséges javításokat és a kívánt módosításokat, ám 86 februárjára mindkét fél számára
nyilvánvaló volt, hogy a rendszer nem működik megfelelően.
Február 11-én a felek szóban megállapodtak, hogy a szerződést megszüntetik. Ezek után
A.egy másik céget bízott meg a rendszer üzemképessé tételével. A munka folyamán, a
forráskód lemásolására is sor került, ami miatt S. szerzői jogainak megsértésére hivatkozva
pert indított A. ellen. S. a perben többek között azt is állította, hogy A felmondása nem volt
jogszerű. A vitatta S állításait, és viszontkeresetében a hibás teljesítésből fakadó kárának

16
megtérítését kérte.
A bíróság mindkét fokon a szerzőknek adott igazat, azzal, hogy ugyan valóban vitathatatlan,
hogy a szolgáltatás február 11-én a szerződés megszüntetésének idején, nem volt alkalmas az
A. céljainak megfelelő használatra, és hogy e tekintetben a szerzők felelőssége fennáll, de a
rendszer alapjában véve üzemelt és további javítások után, ne kizárt, hogy a felperes
céljainak is megfelelt volna. Az adott pillanatban tehát, a felhasználó cégnek még nem volt
joga díjfizetés nélkül elállni a szerződéstől. A Lordok Házának indoklása szerint:
a szoftver nem olyan dolog, melynek átadása egyetlen alkalommal történik, hanem azt
szükségszerűen tesztelni kell, és a tesztelés erdményétől függően lehet csak a hibákat
kijavítani és a szükséges kisebb változtatásokat elvégezni.
Mivel a felek nem kötötték ki precízen, hogy pontosan milyen minőségű legyen a szolgáltatott
dolog, milyen hosszú lesz a tesztelési és a kijavításra adott idő, a bíróság úgy ítélte meg, hogy
a szerződés egyoldalú megszüntetésével a felhasználó lehetetlenné tette a fejlesztő számára,
hogy az a jelentkező hibákat kijavítsa, és így felmondását úgy kell értelmezni, mint ha a
rendszert az adott állapotában elfogadta volna, anélkül, hogy az az eredetileg megjelölt cél
ellátására alkalmas lett volna. A fejlesztőknek így munkájuk ellenértékeként méltányos
díjazás jár, és mentesülnek a kötelezettség alól, hogy a rendszeren további javításokat
végezzenek.

St Albans DC v International Computers Ltd. (ICL)

Míg a Saphena esetben a felhasználó elvesztette a pert, mivel egy használható, ám a kívánt
minőséget el nem érő rendszer további javítását lehetetlenné tette, a jelen esetben a
fejlesztő rovására döntött a bíróság, ugyanis az átadott rendszer egy alapvetó funkcióját nem
tudta hibátlanull végrehajtani a kikötött határidőre. Érdemes ugyan hozzátenni, hogy az adott
határidő szerinti hibátlan teljesítés a jogosult kifejezett kikötése volt.
Tényállás: (az eset leírása)
St. Albans helyi önkormányzata korszerűsíteni kívánta ügyvitelét, ennek érdekében ICL-lel
komplex egyéni rendszer fejlesztésére és installálására kötött szerződést. Az szerződéskötés
előzménye, hogy Margaret Thatcher kormányzata 1990 -es hatállyal bevezette az
önkormányzati fejadót, ami a helyi önkormányzatok részéről meglehetős ellenkezést váltott
ki. Az adó elszabotálásának megelőzésére, a kormányzat rendkívül szigorú határidőket
szabott, az adóbeszedés különféle fázisainak teljesítésére, a késedelembe eső
önkormányzatokat pedig jelentős bírságokkal sújtotta. A megyék, így St. Albans is a gyors és

17
pontos adóadminisztrációt számítógépes rendszer segítségével kívánták megoldani. Annál is
inkább, mivel a fejadó, viszonylagos egyszerűségének köszönhetően, - különösen jól
adminisztrálható gépi programmal. ICL egy tekintélyesebb fejlesztő vállalat, üzletet
szimatolva a dologban, ekkor a piacon reklámozni kezdte “Az ICL Megoldás” nevű temékét,
amely saját állításai szerint alkalmas a helyi önkormányzatok igényeinek kiszolgálására. Az
ajánlatot, az ICL, azzal próbálta különösen vonzóvá tenni e jelentkkező önkormányzatok
számára, hogy tudomásukra hozta: - habár a rendszer pillanatnyilag nem rendelkezik a fejadó
kiszámításához, és beszedéséhez szükséges funkciókkal, ezeknek a feladatoknak a
beprogramozására egy 70 fős profi fejlesztő gárdát fog alkalmazni, és így azok, már a
speciális egyedi igényeket, az önkormányzatok konkrét kívánságait is figyelembe véve fogják
a feladatot megoldani. Ennek hatására, számos önkormányzat , így St Albans is szerződést
kötött ICL-lel. A szerződésben részletteljesítést kötöttek ki, megjelölve a határidőket,
amikorra az egyes funkcióknak működniük kell. A szerződés külön hangsúlyozta, hogy a
fejadóval kapcsolatos feladatok elvégzésére a jogszabályban megadott határidőkre a
rendszernek alkalmasnak kell lennie. A rendszernek teljes egészében 1990 februárjára kellett
elkészülnie, míg a fejadó beszedéséhez szükséges első művelet végrehajtására, nevezetesen az
adóköteles lakosok összeszámlálására 1989 decemberére kellett alkalmasnak lennie.
A decemberi összeszámlálás során azonban, a rendszer valamilyen kisebb hibából kifolyólag
három ezerrel több adózót számlált, a tényleges adókötelesek számánál. Ebből kifolyólag, St
Albans bevételei magasabbnak látszottak a valódinál, és igy jelentősebb mennziságű központi
támogatástól esett el, ráadásul, nagyobb mennyiságű adót is utalt át a regionális
költségvetésbe, mint jogszerűen kellett volna. Az önkormánnyzat veszteségei, több mint 1, 3
millió angol font, meghaladták a fejlesztőknek járó díjat. St. Albans szerződésszegés miatt
pert indított, és kárának megtérítését követelte.
Az ICL védekezésében arrra hivatkozott, hogy a rendszernek teljes egészében csak 1990-re
kellett elkészülnie, és a félkész, még fejlesztés alatt álló mű esetében teermészetes, hogy
előfordulnak javításra szoruló hibák. Álláspontja szerint, akkor amikor a felperes
részteljesítések elfogadásába belegyezett, egyben azt is elfogadta, hogy a közbenső
időpontokban, egy nem teljesen kész, még hibákat, és hiányosságokat tartalmazó rendszert
vesz át..
A bíróság a fenti érvelést elutasította, indoklása szerint, mivel a szerződés pontosan
megjelölte, hogy az egyes határidőkre, milyen alapvető funkcióknak kell feltétlenül
működniük, a rendeltetésszerű használatra a maguk alapfeladatának körében a
rlszrendszereknek is alkalmasnak kellett volna lenniük. Mivel pedig a szerződésben

18
kifejezetten kikötötték, hogy a fejadóval kapcsolatos műveletek elvégzése a jogszabályi
határidőkre alapvető fontosságú, és az alperes ezen követelmény teljesítését kifejezetten is
vállalta, a hibás teljesítés következményei alól a fenti érveléssel nem mentesülhet.

Eurodynamic

nem minden hiba sz szegés, de ha nem lehet kijavítani azzá válhat, Ptk 277/1 a szben
megszabott minőség szerint kell szolgáltatni

Ha a szerző a kijavítást alapos ok nélkül megtagadja vagy határidőre nem végzi el, a
felhasználó a szerződéstől díjfizetés kötelezettsége nélkül elállhat. (Szjt 49/3)

Ha a mű a javítás után sem alkalmas a felhasználásra, a szerzőt csak mérsékelt díjazás illeti
meg.(49/4 )

Részteljesítés

kis hiba kijavítási idő, tesztelés, Szjt, magyar esetek, Watford?

A hibás teljesítés következményei

Nemteljesítés/ hibás teljesítés, core és nem core funkciók,

szavatossági kötelezettségek (törvényi szavatosság/ a szerződésben vállalt szavatosság?)
késedelem,
kártérítési kötelezettség

19
A szoftverfejlesztési szerződés jellege

vegyes jelleg,
Szjt: ha a mű rendeltetésére kijavítás után sem alkalmas, a szerzőt mérsékelt díjazás illeti.
A törvény megosztja a kockázatot a két fél között. Az elmaradt eredmény kihatásal lesz a
szerző díjazására, mert csak csökkentett díjazásban részesül, ugyanakkor felelőssége nem
olyan szigorú, mint a vállalkozóké. Ezzel a kockázaatmegosztással a jogalkotó, helyesen a
feladat kísérleti jellegét méltányolj, mint . ahogyan a kutatási szerződésben is lehetőség van
rá, hogy a kutatónak a díj a munka eredménytelen befejezése esetén is járjon. Szoftverek
eseténa rendszer terjedelmétól, bonyolultságától, a feladat jellegétól függóen , nagy számban
jelentkeznek olyan tényezők, amelyeket nem lehet pontosan előre jelezni, és kiszámítani.
Úgyhogy az adott feladattól függően sokszor, eredetileg ne kiszámítható, hogy valóban
mindaz a használat, amit a megrendelő elképzel, hatékonyan egyszerre megvalósítható. A
gyakorlatba ezt a kérdést a szerződő felek úgy szokták megoldaani, hogy alpa és kiegészítő
funkciók kategóriáiba sorolják a megrendelő igényeit, éés a fejlesztó vállalja, hogy az alap, a
rendster működéséhez elengedetlenül szüksége sfunkciók működni fognak, ezek hiányában a
szerződésszegés nmeteljesítésnek minősül, míg a kegészítő, kényelmi funkciókra nézveee
csak annzit vállal, hogy azokból megvalósít, annyit amennyit csk bír,,,de egy minimálisan
meghatározott számút mindenképpen. Ha a kiegészítő funkciók nem működnek, az nem
nemteljesítés lesz, hanem csak hibás teljesítés. Ehhez képest, ha a fejlesztő alapfunkciót nem
tud kijavítás után sem átadni, elesik a díjtól. Ha kiegészító funkciót nem bír működdésképessé
tenni, akkor csak a díj egy kisebb hányadáról kell lemondania.
Mindazonáltal az angolszász gyakorlatban ismert megfontolás, hogy a sok kicsi hiba
összeadódva nemteljesítést eredményez. Saphena?
A késedelem a fent említett határidők után nemteljesítésnek számít.

Kutatási szerződés
412/1 Kutatási szerződés alappján a vállalkozó kutatómunka végzésére, a megrendeló pedig
díj fizetésére köteles. A felek megállapodhatnak abban, hogy a díj a munka
eredménytelen befejezése esetén is jár.
414/A
A kutatási szerződésre a külön nem szabályozott kérdésekben a vállalkozási szerződés
általános szabályait, illeetőleg a megbízási szerződésre vonatkozó rendelkezéseket kell

20
megfelelően alkalmazni.

Vállalkozási
391/1 A vállalkozó a munkát saját költségén végzi el.
397/1 A díj (ha jogszabály kivételt nem tesz) teljesítéskor esedékes.

Megbízási szerződés

478/1 Főszabály: A megbízó díj fizetésére köteles

/2 A megbízott a díját akkor is követelheti, ha eljárása nem vezetett eredményre. A
megbízó a díjat csökkentheti, illetőleg kifizetését megtagadhatja, ha bizonyítja, hogy az
eredmény részben vagy egészben olyan okból maradt el, amelyért a megbízott felelős.
/3 Ha a szerződés a megbízás teljesítése előtt szűnt meg, a megbította díjnak
tevékenységgével aránzoy részét követelheti.
/4 A díj a szerződés megszűnésekor esedékes.

A szerződéses felelősség kizárása

A szoftverszerződések egyik sajátos, gyakran előforduló szakasza a szerződésszegéből fakadó

kárfelelősséget kizáró vagy korlátozó klauzula. A kikötés az angolszász jogterületen az ilyen
típúsú szerződések állandó eleme. Azért van rá szükség, mert a szoftverek egyrészt könnyen
használhatóak olyan célra, amit a gyártó előre nem látott, másrészt pedig a szoftverek
üzletvezetésben betöltött szerepe jelentős, és könnyen előfordulhat, hogy a szoftver hibája
miatt egy- egy vállalatnál oyan veszteség keletkezik, ami a fejlesztő céget kártérítés esetén
csődbe vinné. Egy táblázatkezelő programot a házi költségvetés elkészítésétől a
multinacionális vállalatok könyveléséig ezerféleképpen lehet használni, a hibából fakadó
esetleges kárt szinte lehetetlen kiszámítani és ezért a tömegesen forgalmazott
szoftvercsomagok esetén ez az árba sem kalkulálható be. Az egyedi, összetett rendszereknél
a felelősségkorlátozás mellett szól az az érv is, hogy a sok szoftverből álló rendszerben
gyakran nehéz megállapítani, melyik program mennyiben okozott gondot.
A fejlesztési feladatok egy részénél, pedig a újszerűségük indokolhatja a korlátozást,
hasonlóan a Ptk-ban szabályozott kutatási szerődéshez.

21
A felelősségkorlátozás érvényességét mind a kontinentális, mi az angolszász jogrendszer
másként bírálja el, ha egyedi szerződésről és másként, ha fogyasztóról van szó. (Igaz a
fogyasztó fogalma nem egészen azonos.)

A szerződésszegésért való felelősség kizárásának a magyar jogban törvényi korlátai vannak.

Egyrészt mindenkire vonatkoznak a Ptk 314. szakaszában megfogalmazott tilalmak, másrészt
a fogyasztóvédelem és a tisztességtelen általános szerződési feltételek körében találunk
korlátokat.

Amennyiben a szerződés hasonló szakértelemmel bíró cégek között jön létre, a törvényi
beavatkozás szűkebb körű, így vonatkozik a Ptk 314(1) szakasza, miszerint.
A szándékosan, súlyos gondatlansággal, vagy bűncselekménnyel okozott, továbbá az életet,
testi épséget, egészséget megkárosító szerződésszegésért való felelősséget nem lehet kizárni.
(2) A szerződésszegésért való felelősséget - ha jogszabály másként nem rendelkezik - nem
lehet kizárni és korlátozni, kivéve ha az ezzel járó hátrányt az ellenszolgáltatás megfelelő
csökkentése vagy egyéb előny kiegyenlíti. (Kommentár)

Másfelől pedig, ammennyiben a szerződés az egyik fél á.sz.f -jei alapján jött létre a kikötés
megtámadható, azon az alapon, hogy indokolatlanul egyoldalú előnyt biztosít.
Magyar á.sz.f-re vonatkozó szabályozás:

209/C Általános szerződési feltételnek minősül az a feltétel, amelyet az egyik fél több
szerződés megkötése céljából egyoldalúan, előre meghatároz. és amelynek meghatározásában
a másik fél nem működhetett közre.

209/D Az általános szerződési feltételt használó felet terheli annak bizonyítása, hogy a feltétel
meghatározásában a másik fél közreműködött. (- az angol jogban azt kell bizonyítani, hogy a
feltétel nem tisztességtelen (azt is?))

A bírósági az ászf létét tágan értelmezi, így általános sz fnek ítélt azt is, amikor a felek úgz
kötöttek szerződést, hogy az egyik ászf-jeit vették alapul de a tárgyalások során, ha a másik
fél véleménye eltért, at eltérést ez megengedte. BH...
Angol gyak . hasonlóan értelmezi a á.sz.f létét. Attól ,hogy tárgyalnak róla, attól még á.sz.f.

22
Felelősségkorlátozás körében vállalkozó felelősség korlátozását a bíróság nem tartotta
tisztességtelennek, amikor az cssak a neki fel nem róható károkat zárta ki. BH

Mivel a magyar bírósági gyakorlatban a szoftver- szerződéssel kapcsolatban a

felelősségkorlátozás problematikájára példát nem találtam, egy angol bíróság érvelését
fogom bemutani a kikötés tisztességtelenné nyilvánításának kérdésében.

Watford Electronics Ltd v Sanderson CFL Ltd (2001)

Tényállás:
Felperes W. Ltd. integrált, testreszabott szoftver-rendzser elkészítésére kötött szerződést, az
alperes S Ltd-vel. W maga is egy számítástechnikai termékekkel kereskedő cég, amely főként
postai úton kereskedik. W., A növekvő vállalat igényeinek megfelelően, elsősorban a postai
megrendelések , a raktárral való kommunikáció és a számviteli feladatok bonyolítására
alkalmas rendszert szándékozott vásárolni. E célból megkereste S Ltd-t és tárgyalásokba
bocsátkoztak. W. Választása azért esett S.-re, mivel az már korábban piacra dobott egy
“Mailbrain” elnevezésű saját terméket, amelyet kifejezetten postai úton megrendelhető
termékek ismertetésére és reklámozására fejlesztettek ki. Ez önmagában nem fedte le W.
igényeit,de összekapcsolható volt, egy Genasys nevű termékkel, amely alkalmas volt a
többi megjelölt funkció ellátására (vásárlások nyilvántartása, könyvviteli feladatok).
A felek több hónapos tárgyalás után, 92 nyarán kötöttek egymásssal szerződést.
Kötelezettségeiket, azok természete szerint, három különböző dokumentumba foglaták:
a, egy adás-vételi szerződésbe
b, egy szoftver-felhasználási szerződésbe és
c, egy a módosított szoftverre vonatkozó felhasználási szerződésbe.

A szerződés Sanderson CFL általános szerződési feltételeire épült, melyek között szerepelt
két, a hibás teljesítésből fakadö kárt korlátozó klauzula is. Az egyik a hibás teljesítésből
fakadó következményes kárt zárta ki, a másik pedig a közvetlen kárért fizethető összeget
korlátozta a hibás szoftverért, illetve szolgáltatásért kifizetett ár összegéig. A rendszert W.
közel egy évig próbálta használni, de az a kisebb javítások után sem működött kielégítően.
Egy év után S Ltd. az egész rendszert újból megvizsgálta és azt, tanácsolta W-nek, hogy újabb
hardver üzembe helyezésére van szükség ahhoz, hogy a rendszer zavartalanul funkcionálni

23
tudjon. W. újabb hardvert vásárolt és S további módosításokat eszközölt, de a rendszer
továbbra sem működött megfelelően. W. ekkor egy másik céggel új rendszer megalkotáására
szerződést kötött, S-t pedig beperelte, és követelte a hibás teljesítésből fakadó kára
megtérítését.

W. keresetében arra hivatkozott, hogy

1. Az S. által ajánlott rendszer nem volt alkalmas arra, hogy a rendeltetési célját betöltse,
azaz S. őt e tekintetben megtévesztette
2. A rendszert késve adták át
3. A rendszer soha ne működött kielégítően
4. És S. nem volt rá képes, hogy a jelzett hibákat ésszerű időn belül kijavítsa.

Az alperes védekezésében nem tagadta, hogy szerződésszegést követett el, viszont a

felelősségkorlátozö klauzulákra hivatkozva vitatta, hogy kártérítéssel tartozna.

Első fokon a bíróság a felelősségkorlátozó szakaszokat tisztességtelennek, s így

érvénytelennek titulálta, S-t pedig a követelt kártérítési összeg megfizetésére kötelezte.

S. Fellebezésében a szakaszok tisztességtelenné minősítését vitatta, és a másodfokú bíróság e

kérdésben az első fokú ítéletet megváltoztatta. A továbbiakban a másodfokú bíróság érvelését
közlöm:
Vonatkozó jogszabályi háttér:
Jelen esetben, mint a 1977-es Tisztességtelen Szerződési Feltételekről szóló törvény
alkalmazandó, melynek deklarált célja, hogy
“korlátot szabjon, a felek azon törekvésének, hogy a nemteljesítésből fakadó polgári jogi
felelősség alól szerződéses klauzulákkal kibújjanak.”
A törvény 3(2) szakasza a felelősségkorlátozásról a következőket írja:
Ha az egyik fél a másik írott általános szerződési feltételei szerint lép szerződésre a másik fél
a szerződés valamely kikötésére hivatkozva
-(a) nem zárhatja ki vagy korlátozhatja a saját szerződésszegésével kapcsolatban fennálló
semmilyen felelősségét, ...hacsak bizonyítani nem tudja , hogy az adott korlátozás eleget tesz
az ésszerűség kritériumának.

A szerződési kikötésnek a felek által a szerződéskötéskor ismert vagy előre látott

24
körülményekre tekintettel kell ésszerűnek lennie.
Az ésszerűségre hivatkozó félnek kell az ésszerűséget bizonyítania.
A minősítést a következő szempontokra figyelemmel kell elvégezni (az ésszerűségi teszt
kritériumai) :
- tekintettel kell lenni a forrásokra, amelyek a felelősség korlátozó félnek rendelkezésére
álltak az esetlegesen bekövetkező helytállás tekintetében, a klauzula kikötésekor, (b) ideértve
a biztosítás-kötés lehetőségét is.
- a felek viszonylagos alkupozícióira, - többek között, arra is hogy a jogosultnak milyen egyéb
lehetőségei lettek volna a szolgáltatás beszerzésére
- valamilyen előnyért cserében, egyezett-e bele a fél a kikötés elfogadásába
- ismerte -e a vevő a klauzulát és annak alkalmazási körét a gyakorlatban (tekintettel a
kereskedelmi szokásokra, és a felek korábbi kapcsolatára)
- a szolgáltatott dolog a vevő megrendelésére , vagy speciális igényeit figyelembe véve
készült-e?
- az adott üzletágban szokásos gyakorlat-e?

A kikötés elbírálása a jelen esetben:

A két felelősségkorlátozó klauzula érvényességét külön, külön kell vizsgálni.
Ezek szerint egyrészt:
- sem a cég ,sem a Vevő nem felel a másik félnél felmerülő következményes károk
tekintetében
- másrészt a Cég kártérítés címén legfeljebb a kártérítési igény alapjául szolgáló
szolgáltatás árának erejéig tartozik helytállni.

A klauzulák csak a szavatossági kikötésekkel együttolvasva nyerik el valódi értelmüket.

Az alperes sszavatosságot vállalt, azért, hogy a szoftver (cég által módosított változata) a
specifikációnak megfelelően fog működni.
Továbbá a szerződés a kötelezett felelősségét illetően tartalmaz mégegy gondossági
klauzulát is, mely szerint:
“ a cég vállalja, hogy a minden rendelkezésére állö eszközzel azon lesz, hogy
szerződésszerűen teljesítsen, és ezzel a másik félnél felmerüló hibás teljesítésből fakadó
esetleges károkat minimalizálja.”

Az elsőfokú bíróság értelmezésében ez a gondossági klauzula semmitmondó, a

25
gyakorlatban szinte semmiféle jelentősége sincs.
A felsőbb bíróság azonban arra az álláspontra helyezkedett, hogy a gondossági kikötés oly
módon változtatja meg a felelősségkorlátozó rendelkezés értelmét, hogy ammennyiben S.
valóban mindent megtett a teljesítés érdekében, akkor a következményes károk W-t terhelik
De, ha S. nem a vállalt maximális gondossággal járt el, akkor Watson a következményes kárt
is érvényesítheti, ugyanis S. Nem tett eleget a szerződésben vállalt kötelezettségének.

Tehát, ha a szoftver nem működik a szavatolt módon, S-nek bizonyítania kell, hogy a
szavatolt működés érdekében valóban mindent megtett, különben nem szabadul a
következményes károk alól sem.
Tehát a magyar esethez hasonlóan az angol bíróság is felróhatósági alapon közelített
felelősségkorlátozáshoz, és megengedi a nem felróható módon okozott kárt kizárását, illetve
korlátozását..
BH

A bíróság továbbá azt is hangsúlyozta, hogy különbséget kell tenni azon kár közt, amit
Watson azért szenved el , mert a szoftver nem működik a szavatolt módon, és azon kár között,
ami abból fakad, hogy a szoftver ugyan a szavatolt - tehát a felhasználói kézikönyvnek
megfelelő módon működött - ám ez a működés nem fedte le Watson valós szükségleteit. Ez
utóbbi probléma, ha egyáltalán S. Ltd - nek felróható, akkor a megtévesztés körébe tartozik,
tehát nem a szerződés teljesítésével, hanem a szerződéskötéskor fennálló együttműköddési
kötelezettség megszegésével kapcsolatos probléma. (“Culpa in contrahendo”), és mint ilyen ,
nem tartozik a szerződéses felelősséget korlátozó klauzula hatálya alá.

A tsiztességteelennek minősítés szempontjait végigvenni.’

1 alkupoyíció stb.
A Felek megítélése
Watford maga is üzletszerűen foglalkozott szoftverkereskedelemmel, és ő is alkalmazott
felelősségkorlátozó klauzulát ügyfeleivel szemben a szerződéseiben. Épp ezért nem tehető fel,
hogy Watson ne értette volna ezen klauzula értelmét vagy jelentőségét.
Mi több Watson saját szerződései azt is tartalmazzák, hogy amennyiben az ügyfél ezt kívánja,
és hajlandó ezért felárat fizetni, Watson vállalja, hogy a hibás teljesítésből fakadó minden kár
tekintetében biztosítást köt és azért helytáll. (Feltéve, hogy van biztosítás a piacon.)
Tehát Watson egy tapasztalt, és a szakmában káratos üzletember. Watson a klauzula tartalmát

26
és annak jelentőségét jól ismerte, továbbá azzal is tisztában volt , hogy felár ellenében a
tejesítésre biztosítás köthető, és korlátozás megszüntetése elérhető.
Ami a piacot illeti, S. Helyzete nem volt annzira domináns, hogy W ne tudott volna jelentős
árrrendegménzt kicsikarni nála.
Watson tárgyalásai során a klauzulák értelmét a gongossági szint megemelésével módosítani
tudta.
Következésképp:
Nincs arra szükség, hogy a bíróság a felek viszonyába jelentősen beavatkozzon és a
szerződést módosítsa - azaz részlegesen érvénytelenné nyilvánítsa.

Relevancia a magyar gyakorlat számára

Mindkét jogrendszer lehetővé teszi á.sz.f megtámadását gazdálkodó szervezetek egymás
közötti kapcsolatában is. A Ptk a felelősségkorlátozó klauzulákról kifejezetten nem szól,
ellentétben az Unfair Contract Terms Act-tel, ami az ilyen klauzulát kifejezetten
megtámadhatóvá teszi, és érvényben tartását, ahhoz köti, hogy az azt alaklamazó fél
bizonnyítani tudja a feltétel ésszerűségét az adott körülmények között. Az ésszerűség
megállapításához, azután számos szempontot találunk, amelyek részben átfedik a Ptk szerint
alkalmazandó elveket is. Így az angol jog is figyelembe veszi, hogy részesült-e valamilyen
előnyben a korlátozó klauzulával szembesülő fél, cserében azért, hogy a kikötést elfogadja.
Az angol bíróság 1. fokon azt hangsúlyozta, hogy Watsonnak nem volt választási lehetősége a
felelősségkorlátozó á.sz.f. elfogadása tekintetében , és bár kapott ugyan árrrengedményt, azt
nem a klauzula elfogadására tekintettel kapta, hanem attól függetlenül.
A 2. Fok ezzel szemben azzal érvelt, hogy Watford, ha kivetetni nem is tudta, azt azért elérte,
hogy a klauzula értelme a fokozott gondosság kikötésével módosuljon, továbbá a sikeres
árengedmény elérése, és Watford saját tapsztaltsága a szoftverszerződések terén mind arra
utalnak, hogy Watford tisztában volt vele milyen kockázatot vállal és saját belátása szerint
kötötte a szerződést a fenti feltételekkel. A klauzula tehát érvényes.

A többi szempont, - a felek rendelkezésére álló forrásoknak, az adott piac szerkezetének, a

biztosításkötés lehetőségének a vizsgálata, nincs nevesítve a magyar jogalkalmazó számára,
de mind olyan szempont, amit a magyar bíróság a kikötés indokoltságának a keretében
vizsgálhat.

27
.A biztosítási elv
Az eset körülményeiből következik, hogy előre látható, a nemteljesítés vagy hibás teljesítés
egész bizonyosan ú.n következményes kárt fog okozni - azaz elmaradt hasznot és más egyéb
költségeket. Ezek összegét Watson tudja jobban megebcsülni és így a nemteljesítésből fakadó
kárra ő tud előnyösebben biztosítást kötni. Érthető tehát, hogy a kötelezett a kockázatot
Watsonra akarja telepíteni, hiszen az esetlegesen bekövetkező kár összegét mégcsak
megbecsülni sem tudja, s így nyilván az árbe beépíteni sem. Ezzel szemben Watson tud
ugyan összegszerűen becsülni, de nem tudhatja, mekkora a hiba bekövetkeztésnek kockázata.
Az optimális kockázatelosztás érdekében tehát a feleknek együtt kell működniük, mégpedig
oly módon, hogy:
a, a felhasználó- jogosult Watson előre jelzi S-nek, hogy mekkora kárral járna egy adott
időszakra az üzletkiesés, és ennek, valamint saját korábbi tapasztalatainak a hasonló
komplexitású rendszerek hibaszázalékáról, birtokában a fejlesztő köt biztosítást, és a
biztosítási díj a szerződésben felárként megjelenik
b, a felhasználó köt biztosítást, de erre tekintettel alacsonyabb árat fizet a szolgáltatásért.
Tekintettel arra, hogy a piacon melyik típusú biztosítás van inkább jelen, és melyik köthető
meg előnyösebb feltételekkel, az optimális megoldáshoz, a feleknek mindenképpen közösen
kell eldönteniük azt, hogy melyik utat választják. A saját á.sz.feltételeit alkalmazó féltől, tehát
legalább az elvárható, hogy választási lehetőséget engedjen a két út közül. (Mint ahogyan azt
egyébként Watson teszi)
Megjegyezzük még, hogy a klauzula érvényességével együtt is Sandersont szerződésen kívüli
kárfelelősség terheli, amennyiben Watfordot a szerződés megkötése előtt megtévesztette a
szerződés tárgya ( - a rendszer alkalmassága) tekintetében.

Nézetem szerint a Ptk-tól eltérő kockázatmegosztás esetlegesen tisztességtelenné

nyilvánításakor a fenti gondolatmenetet a magyar gyakorlatban is alkalmazható, hiszen a
biztosítási elv, illetve a felek tényleges lehetősége a saját kockázatvállalásuk alakítására,
minden paicgazdaságaban meghatározó szempontok. Igaz, arra, hogy Magyarországon
hasonló, a vállalkozó hibás teljesítésévelel összefüggő kárra biztosítást lehessen kötni, még
valószínűleg várni kell.

Fogyasztói szerződések

28
Fogyasztói szerződések és általános szerződési feltétel esetén a felelősség kizáró klauzula
tisztességtelennek minősülhet.

A feltétlenül tisztességtelen kikötések kategóriájába tartoznak különösen a következők:

Korm r. 1/1
c, a fogyasztót teljesítésre kötelezi, abban az esetben is , ha a gazdálkodó szervezet nem
teljesíti a szerződését,
I, kizárja vagy korlátozza a a fogyasztó jogszabályon vagy a felek közötti megállapodáson
alapuló jogait a gazdálkodó szervezet szerződésszegése esetén

A vélelmezetten tisztességtelen kikötések kategóriájába tartozik különösen az olyan kikötés,

amely: (Korm r 2)
e, lehetővé teszi, hogy a gazdálkodó szervezet egyoldalúan , alapos ok nélkül
aszerződésbeen meghatározott tulajdonságú szolgáltatástól eltérően teljesítsen
g, gazdálkodó szervezetnek aránytalanul hosszú vagy nem megfelelően meghatározott
határidőt biztosít szolgáltatása teljesítésére
h, kizárja vagy korlátozza a fogyasztó joggszabályon alapuló jogait a gazdálkodó szervezet
szerződésszegése esetén

Intézményes fogyasztóvédelem keretében reális eltérítő erő lehet. A mai napig nincs
gyakorlata??
USA stb

xxx
A kártérítés mértéke
(355/1) mégpedig teljes kártérítéssel: vagyoni és nem vagyoni
(355/4) Kártérítés címén a károsult vagyonábanbeállott értékcsökkenést és az elmaradt
vagyoni előnyt, továbbá azt a kárpótlást vagy költséget kell megtéríteni, amely a károsultat ért
vagyoni és nem vagyoni hátrány csökkentéséhez és kiküszöböléséhez szükséges.

Ám míg:

339(2) A bíróság a kárért felelős személyt rendkívüli méltánylást érdemlő körülmények

alapján a felelősség alól részben mentesítheti. (kommentár)

29
318(1) Szerződésszegéssel okozott kár esetén a kártérítés mérséklésének nincs helye.

A kártérítés mértéke
- Ha a kár a szerződés megszegéséből fakad a jogosultat lehet, hogy a felelősségkorlátozó
klauzula miatt nem tudja kártérítési igényét érvényesíteni. Ha a szerződés érvénytelen és a
károkozás szerződésen kívüli felelősséget von maga után, a kár érvényesíthtő, ám a bíróság
rendkívüli máltánylást kívánó körülmény ek fennállta esetén a kártérítés mértékét
tetszőlegesen csökkentheti.
- a kár nagyságával, fajtájával kapcsolatos előrelátás?
- a kártérítés funkciói: kármegelőzés, kockázatmegosztás

Kutatási szerződés
Ptk 413/4 A vállalkozó a szerződésben kikötheti kártérítési felelősségének korlátozását.
xxx

Magyar á.sz.f-re vonatkozó szabályozás:

209/C Általános szerződési feltételnek minősül az a feltétel, amelyet az egyik fél több
szerződés megkötése céljából egyoldalúan, előre meghatároz.és amelynek
maghatározásában a másik fél nem működhetett közre.
209/D Az általános szerződési feltételt használó felet terheli annak bizonyítása, hogy a feltétel
meghatározásában a másik fél közreműködött. - az angol joggba azt kell bizonyítani, hogy a
feltétel nem tisztességtelen (azt is?)
- S. kikötése a Ptk szerint is á.sz.f - ám indokolatlan egyoldalú előnynek minősül-e?
Mi a magyar gyak? Mik a kritériumok?

209B Tisztességtelen az á.sz.f, ha a jóhiszeműség követelménzének megsértésével a

feleknek a szerződésből eredő jogosultságait és kötelezettségeit egyoldalúan és indokolatlanul
az egyik fél hátrányára állapítja meg.
2, ... különösen, ha:
a, a szerződésre irányadó lényeges rendelkezéstől jelentősen eltér
b, összeegyeztethhetetlen a szerződés tárgyával illetve rendeltetésével.
(3) A feltétel tisztességtelen voltának megállapításakor vizsgálni kell a szerződéskötéskor
fennálló minden olyan körülményt, aamely a szerződés megkötésére vezetett, továbbá a

30
kikötött szolgáltatás természetét, az érintett feltételnek a szerződés más feltételeivel vagy más
szerződésekkel való kapcsolatát.

A hibás teljesítésből fakadó szerződésen kívüli felelősség

Felelősségi címek: szerződéses, sze-en kívüli, termék

Szerződésen kívüli felelősség esetei:

I. Termékfelelõsség

Bevezetõ

Szemben az egyedi megrendelésre készített számítógépes programokkal, a dobozos

szoftverek felhasználói legtöbbször nincsenek szerződéses viszonyban a szerzőkkel. Mégis
ilyen esetekben is felmerül a szerzők felelőssége a programok által okozott kárért akár a
termékfelelősség, akár pedig a hagyományos szerződésen kívüli károkozás körében. Egyedi
megrendelésre gyártott szoftverek esetében ugyancsak előfordulhat, hogy a szoftver által
irányított gép kárt okoz harmadik személyeknek. Jelen pillanatban sem Magyarországon, sem
a fenti problémákkal elméleti szinten régebb óta foglalkozó angolszász országokban nincs
sem jogszabály, sem jelentősebb esetanyag kifejezetten a szoftverek által okozott
szerződésen kívüli károk rendezéséről. Éppen ezért e fejezetben a termékfelelősség
vonatkozó kérdéseinél, és a következő, -klasszikus károkozói felelősséggel foglalkozóban,
nem az alig létező gyakorlatot, hanem inkább a jogfejlődés lehetséges irányait igyekszem
felvázolni.

31
A termékfelelősség feltételei

Magyarországon a termékfelelősséget az EK Tanácsának 1985- ös Termékfelelősségi

Irányelvét átültető 1993. évi X. törvény szabályozza, háttérjogszabályként pedig a Ptk.
irányadó. A törvény 1.§-a értelmezi a termék fogalmát. Ezek szerint:
1§ (1) termék: minden ingó dolog - akkor is, ha utóbb más ingó vagy ingatlan alkotórészévé
vált.
A törvény hatálya alá tartozik a villamosenergia is, ezzel szemben jogpolitikai okokból a
törvény hatálya nem terjed ki pl. a mezőgazdasági őstermékekre és egyes más termékekre.

A törvénytől eltérően, az irányelv definíciójában a dolog szó nem szerepel, a minden ingó,
helyén a minden "mozgatható" - all movables kifejezés áll, ami azért szignifikáns, mert nem
olyan hagyományos terminus technikus, mint az ingó/ingatlan (dolog) fogalma a magyar
nyelvben, ezek helyén a hagyományos jogi angol, a personal chattel, personal property/ real
property felosztást alkalmazza. Az eltérés következménye, hogy a szakirodalomban
megindulhatott a találgatás, vajon terméknek csak a hagyományos dolog kategóriába
illeszkedő áruk számítanak vagy a fogalom bizonyos körülmények fennállta esetén
kiterjeszthető az áruként megjelenő információra is.

Xxx A kiterjesztő értelmezés határai: tv adással kapcsolatos példa

xxx További vitára okot adó feltételek:
ok-okozati összefüggés
hiba
tech-tud mentesülés

Termék-e a szoftver?

Az 1985-ös termékfelelősségi irányelv már megalkotása idején is nagy szakmai vitákat

váltott ki a tekintetben, hogy hogyan kezelendőek a hibás információkat közvetítő termékek.

“Sajátos problémák merülnek fel azon iparágak körében, amelyek információt tartalmazó
termékeket gyártanak, így könyvet, lemezt, kazettát, szoftvert... Úgy tűnik, hogy az Irányelvet
nem szándékoztak az információ hibáira is kiterjeszteni, ugyanakkor szoftverek esetében
lényeges, hogy a szoftvert tartalmazó gépek gyártói, ne mentesüljenek a termékfelelősség
alól, azzal, hogy a hibát a szoftver tartalmazta. “

32
Utóbb ezt, az aggályt az Irányelv alkalmazásához kiadott kommentár eloszlatta, miszerint,
amennyiben a számítógépi program hibája miatt, az azt alkalmazó termék kárt okoz, a
felelősség a terméket gyártóra hárul. Ezzel implicit módon a magyarázat azt is tagadja,
hogy a szoftver önmagában termék lenne.
A szakirodalomban folyó vitának ez azonban nem vetett véget, és az álláspontok a mai napig
megoszlanak a kérdésben. Az alábbiakban az angolszász irodalomban található főbb
irányzatokat ismertetem.

A skála egyik végén találjuk a szoftvert tisztán információnak tekintő nézetet, mely
szerint a szoftver szolgáltatása, valamilyen információt adó szolgáltatással, például tanácsadói
szolgáltatással analóg, és így arra nem terjedhet ki a termék fogalma.
Jane Stapelton a termékfelelősségi irányelv problematikus kérdéseit analizálva így ír erről:
Az irányelv kommentátorainak egy része elképzelhetőnek tartja, hogy az Európai Bíróság
rugalmasan fogja értelmezni a termék fogalmát, és nemcsak az árunak minősülő dolgokat
értik majd termék alatt, hanem mindent , ami olyan, mint a hibás áru. Ebből következőleg fel
kell tennünk a kérdést, hogy mi az, ami a hibás szoftvert a hibás áruhoz teszi hasonlatossá. Ha
erre a kérdésre a Bíróság meggyőző választ akar adni, akkor előzetesen azt kell tisztáznia,
hogy mi az, ami a hibás “áruk” által okozott kárigényeket sajátossá teszi. A tömegméretekben
való termelés nem adja meg a választ, hiszen az Irányelv által szabályozott termékfelelősség
nemcsak a tömegesen termelt árucikkekre vonatkozik. Ráadásul, az olyan nem áruk, mint a
térkép és a szoftver tömegesen előállíthatóak, és sérülés okozására képesek. Az sem állja
meg a helyét, hogy amennyiben a termék hibáira összpontosítunk, az előállító magatartását
nem kell vizsgálni: - kell.

...

A tiszta információ szemléletet jónéhány szempontból éri kritika, éspedig:

- technológiai szempontból
- az áru /szolgáltatás felosztás helyességét vitatva (Ennek hol van a példája???)
- pragmatikusan, az okozott kár elosztásának indokoltsága felől.

Technológiai szempontból tömören, annyit kell megjegyezni, hogy az újabb és újabb

mikrochip gyártó technológiáknak köszönhetően, a választóvonal szoftver és hardver között
egyre jobban elmosódik.

33
Pragmatikus szempontból kiindulva a Winfield és Jolowicz féle kártérítési jogi szakkönyv
megfontolandónak tartja következő példát:
Ha egy repülő azért csapódik a földnek, mert az automatikus leszállás vezérlő egyik
alkatrésze bizonyos hőfok felett nem működik, akkor vajon tényleg jelentősége van-e annak,
hogy az alkatrész, azért nem működik, mert az említett hőfokon meghibásodott, vagy azért,
mert eleve úgy programozták, hogy csak bizonyos hőfok határok között működjön.

A példa arra világít rá, hogy a szoftver nem tiszta információ, hanem olyan, ami valamilyen
funkció betöltésére szolgál. A szoftvert a funkció ellátására tervezik, és hibái többnyire
tervezési hibák. Az eredmény szempontjából nézve nincs jelentősége annak, hogy egy
hagyományos vezérlőmű van rosszul megtervezve, vagy pedig a szoftver irányította. A
szoftver tehát nem a tévesen adott tanáccsal, vagy a tévesen megadott adattal rokon, hanem a
rosszul megtervezett árucikkel.

Az áru versus szolgáltatás vita

Fleming: Termék bármilyen áru és az elektromos áram is lehet, ideértve az alkotórészeket is.
Ugyanakkor egy kiadvány tartalmaként megjelenő információ nem termék. Ahogy a
szolgáltatás nyújtása sem az. A tervező nem felel úgy az általa készített hibás tervrajzért,
mint a gyártó a hibás termékért. A félreérthető, vagy nem kielégítő használati utasítás miatt,
hibás terméknek minősül az amúgy hibátlan áru, a számítógépnek hibás utasításokat adó
szoftver mégsem termék. Mi az oka az áruk és szolgáltatások ilyen szigorú
megkülönböztetésének, amikor a fogyasztók védelme, az egyik esetében éppolyan indokolt,
mint a másikéban? A megkülönböztetést nehéz elméletileg megindokolni. Az okok
esetlegesek és pragmatikusak:

- Először is ott van az áruk adásvételéhez kapcsolódó szavatosság intézménye, amiből a

vonatkozó amerikai kártérítési jog fejlődése annak idején elindult.
- Ennél jelentékenyebb az a szempont, hogy a professzionális szolgáltatások , azért vétetnek
ki a szigorúbb felelőssági körből, mert azok egyszerre csak egy ügyfélnek nyújtják
“terméküket”, és így a felelősség költségét nem lehet olyan szépen elosztani, mint a
futószalagon gyártott termékeknél.

Az utóbbi megfontolás vezet arra, hogy különbözően húzzuk meg a dobozos és az egyedi
szoftverek esetén fennálló felelősség határait.

34
(Simon Whittaker könyvében e kérdéssel részletesebben is foglalkozik:)
Terméknek kellene-e tekintenünk a számítógépi programokat a Direktíva céljára? Az angol
elemzők éppencsak, hogy megfogalmazták ezt a kérdést, de a válasz kidolgozásával az
amerikai szakirodalom előbbre jár, noha még egyetlen amerikai bíróság sem hozott döntést
kifejezetten abban a kérdésben, hogy szoftver esetében fennállnak-e az objektív felelősség
feltételei.
Az amerikai kommentátorok egyetértenek abban, hogy a kérdés megválaszolásához, azt kell
vizsgálni, fennállnak-e az objektív felelősség kiterjesztésének szükségessége szoftver
esetében is. Az objektív felelősség kiterjesztésének három leggyakrabban emlegetett indoka,
hogy:
- a termék bejut a kereskedelem “vérkeringésébe”
- a gyártónak több lehetősége van a kockázatok kontrollálására, mint bárki másnak
- a gyártó a balesetek költségét az árba beépítve teríteni tudja.
Azaz az amerikai bíróságok rendszerint a fenti indokok valamelyikére hivatkoznak, amikor
jogértelmezésükkel az objektív felelősség határait az ingó dolgokon túlra terjesztik.

A fentiek fényében a számítógépi programok két nagy típusát, - nevezetesen a standard

szoftvert és az egyedi megrendelésre készülőt, megviszgálva, azt állapíthatjuk meg, hogy míg
a standard szoftverek esetében az említett indokok fennállnak, az egyedieknél nem.
Az egyedi megrendelésre írodott program nemigen kerül be a kereskedelmi vérkeringésbe,
hiszen csak egyetlen felhasználó kapja. Ebből következően a gyártó a kockázati költséget
sem tudja teríteni, és így viselése tekintetében nincs előnyösebb helyzetben a fogyasztónál.
Végezetül, ami a baleset bekövetkeztének a befolyásolását illeti, igaz ugyan, hogy a program
elkészítésének kontrollja végső sorban tervezője kezében van, de azt is figyelembe kell venni,
hogy egyedi rendszerek létrehozásakor a megrendelő aktív közreműködése a tervezési
szakaszban elengedhetetlenül szükséges.
xxx
Ezzel szemben a dobozos szoftverek Közösségi forgalma éppen úgy zajlik, mint bármilyen
más tömegcikké, így tehát az áruk szabad mozgását proponáló versenyjogi elvek rájuk épp
annyira vonatkoznak, mint a többi árucikkre. Egyedi szoftverek esetében, kereskedelmi
forgalom híján, az áruk szabad mozgásáról sem beszélhetünk, ugyanakkor az országonként
eltérő felelősségi szabályok alkalmazása befolyásolni fogja a tagországok szoftverfejlesztői
közötti versenyt. Ez azonban már nem az áruk, hanem a szolgáltatások szabad mozgásának,
végső soron a letelepedési szabadságnak a kérdése. Természetesen a közös piacnak ez is egy

35
fontos vetülete, és az Európai Bíróság nemegyszer értelmezte a közösségi jogot úgy, hogy egy
adott jogszabályt “a közös piacot megteremtő rendelkezések összeségének” kontextusában
vizsgált.
xx
Talán a Bizottság álláspontjának bizonyítékául szolgálhat az a válasz, amit az
Európai Parlament egyik képviselőjének az írásbeli kérdésére adtak. A kérdés így szólt:
Kiterjed -e az termékfelelősségi irányelv hatálya a számítógépek szoftvereire is?
A bizottság egyöntetűen válaszolt: mivel a definíció úgy fogalmaz, hogy minden termék, ami
ingó, akkor is ha alkotórészként be van építve egy másik ingóba, (vagy egy ingatlanba), a
szoftver terméknek számít.
Xx
Ok-okozati összefüggés
xxx

Mikor hibás egy termék?

A hiba fogalma a törvény szerint:
2. § (1) A termék akkor hibás, ha nem nyújtja azt a biztonságot, amely általában elvárható,
figyelemmel különösen a termék rendeltetésére, ésszerűen várható használatára, a termékkel
kapcsolatos tájékoztatásra, a termék forgalomba hozatalának időpontjára, a tudomány és a
technika állására.
(2) A terméket nem teszi hibássá önmagában az a tény, hogy később nagyobb biztonságot
nyújtó termék kerül a forgalomba.

A törvény 2. paragrafusa az Irányelv 6. szakaszát veszi át kisebb eltérésekkel, - az angol

megfogalmazás az "általában elvárható" kifejezés helyén szó szerint a következőt mondja:
Egy termék akkor hibás, ha nem nyújtja azt a biztonságot, amit egy személy jogosan elvárhat
(a person is entitled to expect). A megfogalmazás az angol jogi nyelv kontextusában azért
érdekes, mert nem alkalmazza a náluk bevett "ésszerűen elvárható" formulát (does not provide
the safety which can be reasonably expected.). Ez a szóhasználat a 77-es Strasbourgi
Konvenció nyelvezetét követi, amelyet a hivatalos kommentár annak idején a
következőképpen magyarázott:
A szakértői bizottság szándékosan nem használta az ésszerűen elvárható formulát. Az egy
személy, nem a terméket konkrétan használó személy elvárásaira utal, nem az adott fogyasztó
vagy az adott sérült személyéhez igazodik, hanem objektív mércét kíván felállítani.

36
Ahogyan a jogosan elvárható kifejezés is, többet jelent a törvényesen elvárhatónál. Azaz a
gyártó nem mentesül, azzal , hogy az előállításra vonatkozó minden jogszabályt és előírást
betartott.
A bizottság azért nem használta az "ésszerű" kifejezést, mivel ez a kifejezés a fogyasztó jogait
szűkítené, hiszen az ésszerűség hagyományosan tekintettel van olyan költség tényezőkre, és
egyéb elvárhatósági szempontokra is, amelyek termékfelelősség esetén nem vizsgálandóak.

A kommentár szövegének megértéséhez adalékul szolgál, hogy bitonyos hagyományosan

emelt szintű felelősségi rezsimek esetén használatos az ésszerűségi mérce. Így például a
munkáltató felelősségét a munkahely biztonságáért,az angol ...Code úgy határozza meg, hogy
a munkavállalók biztonságát az "ésszerűen megvalósítható" szinten kell garantálni. A
megfogalmazás mögött egy költség/előny analízis teszt rejlik, amit a termékfelelősség
megállapításakor tudatosan zártak ki. Azaz rosszul értelmezi az a bíróság a termékhiba
fogalmát, amely a termék forgalomba hozatalához fűződő előnyöket és a ráfordított
költséget figyelembe veszi...?.. A termékfelelősség nem gondossági, hanem objektív
felelősség.

A fenti gondolatmenetnek akkor van különösen jelentősége, amikor számba vesszük a

kimentési lehetőségeket:
7§ A gyártó mentesül az e törvényben meghatározott felelősség alól, ha bizonyítja, hogy:
(d) a termék általa történő forgalomba hozatala időpontjában a hiba a tudomány és a
technika állása szerint nem volt felismerhető.

A taxatívan felsorolt kimentési okok közül, a tudomány és technika állására való hivatkozás
az, ahol a gyártó magatartását kimondottan vizsgálni kell, és így lehetőség nyílhat valamifajta
felróhatósági mérce becsempészésére.

Annak mérlegelésekor, hogy a gyártó megfelelően járt-e el a tudomány és technika

vívmányainak alkalmazása terén, a bíróság többféle módon gondolkodhat.

Ha a gyártó azt állítja, hogy a hiba nem volt felismerhető, ez jelentheti egyrészt azt, hogy a
hiba maga ismert ugyan, csak a tudomány és a technika állása szerint nincs olyan vizsgálati
módszer, amellyel 100%-ban kiszűrhető lenne, - ilyen volt az az eset, amikor egy doboz

37
konzervborsóban hernyót találtak, és a gyártó védekezésében előadta, hogy ő a legkorszerűbb
minőségellenőrző rendszereket használja, amelynek révén az évi 20 millió doboz borsó közül
mindössze 4 tartalmazott hernyót, és ennél jobb eredményt a tudomány és a technika állása
szerint manapság lehetetlen elérni. Mire a bíróság kifejtette, hogy az adott hibaszázalékot
valóban kitűnőnek tartja, és egyáltalán nem vethető semmilyen mulasztás a gyártó szemére,
ám a fenti védekezés nem a statisztikailag le nem csökkenthető hibák kimentésére nyújt
lehetőséget, hanem csak az olyanokéra, amelyek a tudomány és a technika állása szerint az
előállításkor még egyáltalán nem ismertek. Azaz a nem felsimerhető kifejezést , úgy kell
érteni, hogy a hibafajta nem ismert és ezért nem felismerhető.

Ám ebben az utóbbi értelemben vett nem felsimerhetőséget is még tovább kell

szűkíteni:

Idézet a Strasbourgi Konvenció kommentárjából:

Egyes szakértők arra az álláspontra helyezkedtek, hogy a fejlesztési kockázatra való
hivatkozás a technikailag fejlett termékek esetében kimentési alapul kellene, hogy
szolgáljon, ellenkező esetben a jogi szabályozás a kutatás és fejlesztés, illetve az új termékek
piacra dobásának kerékkötőjévé válhat.
Ezzel a véleménnyel szemben hangzott el az az érv, hogy egy ilyen kivétel az egész
konvenciót haszontalanná tenné, hiszen az egyezmény által kialakított objektív
fellelősségvállalás helyett, így a gyártónak lehetősége nyílna rá, hogy felróhatósági alapon
kimentse magát.
Ezen felül, ha a fejlesztési kockázat a károkozás következményei alól mentesítene, az arra
bátoríthatná a vállalatokat, hogy a fogyasztót “laboratóriumi patkány”-nak használják.

A bizottság végül azt a következtetést vonta le, hogy a fejlesztési kockázat viselésének
megosztása jogpolitikai döntés, a költséget lehet a fogyasztóra vagy a gyártóra terhelni, és
részben vagy egészben akár az egész társadalomra is.

A bizottság a maga részéről a kimentés lehetősége ellen tört lándzsát.

Ám ez az állásfoglalás korántsem talált minden tagállamban helyeslésre, így a jelenlegi

Irányelv immáron lehetővé tesz kimentést, azzal, hogy az egyes tagállamok, belátásuk szerint

38
szigoríthatják alkalmazását.

Problémát okozott azonban, amikor az angol parlament nem szigorította, hanem vélhetően
könnyebbé tette a mentesülést, azzal, hogy az Irányelv szövegét a következőképpen ültette
át:
a gyártó kimentheti magát ha bizonyítani tudja, hogy a a tudomány és a technika állása
szerint a termék hibája olyan jellegű volt, hogy a forgalomba hozatal idején azt más, azonos
kategóriájú terméket előállító gyártó sem ismerhette volna fel.
Az átültetést ért kritika szerint, ez a szakasz így a szakmai standerdeket és nem
önmagában a tudomány és a technika állását veszi alapul. A Bizottság emiatt Nagy-Britanniát
be is perelte a Bíróság előtt, és így az ügy kapcsán a Bírósági Főügyész? irányadó
jogértelmezést bocsátott ki:
Az Irányelv egy olyan objektív felelősségi intézményt kíván megvalósítani, amely immáron
nem abszolút, hanem korlátozott jellegű, - tiszteletben tartva a kockázatok károsult és
gyártó közötti méltányos megosztásának elvét. Ezek szerint a gyártónak kell viselnie az
összes előre becsülhető kockázati költséget, de nem a fejlesztési kockázatot, amely jellegénél
fogva kiszámíthatatlan. Éppen ezért az Irányelv értelmében a károsultnak bizonyítania kell a
kár felmerülésének tényét, a termék hibás voltát, és a kettő közötti okozati összefüggést, de
nem kell, hogy mindez a gyártónak felróható legyen. Ugyanakkor a gyártó kimentheti magát
azzal, hogy a tudomány és a technika állása szerint a terméket forgalomba hozatalának
időpontjában nem lehetett hibásnak tekinteni.
Ezzel kapcsolatban rá kell mutatnunk arra, hogy mivel az Irányelv csak a tudomány és a
technika állását említi, nincs szó annak a vizsgálatáról, hogy mi a kérdéses időpontban a
szokásos ipari gyakorlat. Más szavakkal, a gyártó esetleges mentesülésére semmilyen
kihatással nincs az a tény, hogy az adott időpontban, iparágában senki más sem teszi meg a
szükséges intézkedéseket az áruk nagyobb biztonságának elérésére, feltéve, hogy tudományos
ismereteink szerint létezhetnének ilyen intézkedések.

A költség aspektusok tehát a vizsgálandó körön kívülre esnek, mint ahogyan az sem
releváns, hogy az adott gyártó nem tudott lépést tartani a technikai haladással, és a
szakirodalomban fellelhető eredményekkel. Úgy gondolom, hogy a gyártó tudásszintjének
az adott terület legmagasabb szakértői tudása kell mércéül szolgáljon.

39
 Itt jegyezném med, hogy a mérce kikristályosításához szükséges még a tudományos és
technikai ismeretek fogalmát tovább pontosítani.
A tudományos kultúra fejlődése nem lineáris abból a szempontból, hogy az új
felfedezéseket megszületésükkor gyakran a tudományos közösség nagy része
megbízhatatlannak, megalapozatlannak tartja, idővel azonban az új tudás egyre szélesebb és
szélesebb körben válik elfogadottá, míg végül szinte egyöntetűen mindenki a hívévé válik.
Éppen ezért nagyon is lehetséges, hogy valamely termék piacra dobásakor egy-egy
elszigetelt hang figyelmeztet az áru potenciális veszélyeire, míg a tudományos többség
biztonságosnak tartja. A kérdés az, hogy egy ilyen ambivalens helyzetben, amikor a kockázat
nem is biztos, hogy fennáll, és létezését a többség csak utólag ismerheti majd el, egy ilyen
helyzetben hivatkozhat-e a gyártó a a tudomány és a technika meglévő szintjére.
Nézetem szerint a fenti kérdésre tagadó válszt kell adnunk. A tudományos ismeretek állását
nem lehet a többségi szakvéleménnyel azonosítani, hanem a legelőrehaladottabb kutatások
eredményeivel.
xx
Ez a Bizottság által javasolt értelmezés van leginkább összhangban a Közösségi szabályok
mögött húzódó célokkal, a gyártónak kell az előre látható kockázatokat viselnie, amelyekkel
szemben meg tudja védeni magát, akár úgy, hogy a kutatás és fejlesztésbe invesztálva
megelőző intézkedéseket tesz, akár úgy , hogy felelősségbiztosítást köt a termékei által
okozott kárra.
Ha a tudományos szakvélemények tömegében egy is van, amely a várható kockázatra
figyelmeztet, a gyártó többé nem hivatkozhat arra, hogy a kockázat nem volt előre látható,
és mint ilyen kívül esik a termékfelelősség körén.

A tárgyalt kérdéshez természetesen szorosan kapcsolódik az ismeretek elérhetőségének a

problematikája. Tagadhatatlan, hogy az információáramlást objektív tényezők befolyásolják,
mint például a hely, ahol az eredmény született, a nyelv, amelyen megíródott, a folyóiratok
példányszáma, amelyekben publikálták...

Mindezeket összefoglalva, azt mondhatjuk, hogy a tudomány és a technika állása szerinti

ismeretek alatt a tudományos közösségben cirkuláló összes ismeretet kell érteni, ésszerű
módon figyelembe véve azonban, az információ áramlás tényleges kegetőségeit.

40
 A fentiek fényében a szoftverekről a következő mondható el:
A szoftver hibája többnyire tervezési hiba. ( Nehézkesen alkalmazható az at érv, hogy a hiba
nem volt felismerhető, amikor az nem az embertől függetlenül létezett, hanem az ember által
létrehozott.) Hibái, a hibalehetőség értelemben véve ismertek, hiszen köztudott, hogy
hibátlan szoftver nem létezik, ám a konkrét, adott körülmények között fellépő és a a termék
biztonságát veszélyeztető hiba természetesen ismeretlen. Kiszűrhetőek-e a tudomány és a
technika állása szerint az ilyen hibák. Ha a válasz nemleges, a gyártó érvelhet azzal, hogy
mivel csak a kockázat volt ismert, de a tudomány és a technika állása szerint a veszélyt
elhárítani nem lehet, a termék nem hibás, hanem csak olyan, amilyenre amilyenre jelenleg az
emberi technika képes.
Ha viszont létezik olyan teszt, amellyel a hiba kiszűrhető, a védekezés már nem áll meg. A
valóság az, hogy tesztelni elméletileg a végtelenségig lehet, a gyakorlatban azonban nyilván
nem. A megfelelő tesztelés kérdése tehát újfent ésszerűségi, gondossági, felróhatósági
kérdéssé válik, ami ellentmond az objektív felelősség követelményének.

Az ellentmondás feloldására nyilvánvaló megoldás nincsen. Jogpolitikai kérdés marad,

hogy a szoftveripar fejlődéséhez, szükség van-e valóban a termékfelelősség alól mentesülést
engedő hivatkozásra. Jelen pillanatban a tagországok egy része nem enged kimentést, és így
az oda exportálóknak az ott felmerülő károk tekintetében vállalniuk kell a fejlesztési kockázat
költségeit is. Nem szabad elfelejteni azt sem, hogy szerződéses viszonyban, a szavatossági
felelősség körében hasonló kimentési ok nem létezik. Végül az is szem előtt tartandó, hogy a
termékfelelősség hatálya annyiban eleve korlátozott, hogy a gyártó csak a felhasználó
személyében és a termék által közvetlenül megkárosított dologban esett kár megtérítésére
köteles, de sem a termékben magában felmerülő értékcsökkenés, sem az egyéb típusú károk
megtérítésére nem.

41
II Klasszikus kártérítési felelősség

A termékfelelősség alapján történő igényérvényesítés akkor áll nyitva szoftver által

megkárosított személyek előtt, ha a termék hibája következtében testi épségük sérült, vagy
egy dologban következett be fizikai kár. (E feltételeken kívül az Irányelv által biztosított
igényérvényesítésnek feltételel még, hogy a kár összegee minimálisan elérje a 10 ezer
forintot.)

A szoftver viszont természetszerűleg efféle sérülések okozására önmagában nem képes. Nem
a szoftver maga okoz sérülést, hanem a szoftver által irányított gép, vagy az arra támaszkodó
ember.

Mivel a szoftver fő funkciója az információ feldolgotás kezelés, szoftverhibák tipikus

megjelenési formája a téves, hiányos információ kibocsátása, vagy egyszerűen az információ
elveszítése.

Előfordul, hogy a téves információ balesetekhhez vezet, ám ennél jóval gyakoribb a gazdasági
kár. Az értékkel bíró információ elvszítése, eltorzulása pedig önmagában is kár jelent, de
ezekre a nap mint nap előforduló esetkre, a termékfelelősség nem terjed ki. A károsult,
amennyiben a fejlesztővel nincs közvetlen szerződéses kapcsolatban, ilyenkor kártérítési
igénnyel léphet fel ellene. Programok fagynak le, megírt munkák vesznek el, határidős
feladatok nem készülnek szoftverhibák miatt, az ebből fakadó kártérítési igény érvényesítése
mégis szinte példa nélkül való.
Magyarországon és Angliában eleddig egyetlen ilyen esetet sem publikáltak, és Amerikában
is, ahol a személyi számítógépek használata a legelterjedtebb, és ahol a büntető kártérítés
intézménye jóval inkább motivál pereskedésre, is csak szórványosan fordultak elő ilyen
esetek.

Ennek a jelenségnek az okát elsősorban a károsult előtt tornyosuló bizonyítási

nehézségekben, másodsorban pedig a licenciába becsempészett felelősségkorlátozó
klauzulákban lelhetjük.

Bizonyítási nehézségek a szoftverkárral kapcsolatban

42
A kártérítési felelősség fennálltának Ptk-ban szabályozott öt feltétele közül, a károsultnak kell
bizonyítania:
- a kár bekövetkeztét
- azt, hogy a károkozó tanusított olyan magatartást, ami a kárt előidézhette
- és azt, hogy a kár és az állítólagos károkozó magatartása között (adekvát) ok-okozati
összefüggés van.
A károkozó bizonyíthatja, hogy a kárt nem felróhatóan okozta.
A törvény pedig vélelmezi, hogy amennyiben, nincsen a jogellenességet kizáró ok, a
károkozás jogellenes volt. A jogellenességet kizáró ok fennálltát a károkozó bizonyíthatja.

Szoftverek által okozott kár természetéből következően a fenti konstrukció nyomán a

károsultnak különös nehézséget okozhat az ok-okozati kapcsolat fennállta, és az, hogy a
fejlesztő a felróhatóság hiányára hivatkozva, viszonylag könnyen ki tudja menteni magát.

Az ok-okozati összefüggés

A károsult közrehatása

A szoftver által okozott kár bekövetkezte mindig azon is múlik, hogy a szoftver által
szolgáltatott információt, az azt megkapó személy hogyan kezeli. Felmerül a kérdés, hogy
amennyiben a felhasználó tud a szoftverhiba kockázatáról, mennyiben köteles biztosítási
intézkedéseket tenni.

A kellő körültekintés szintjét általános érvénnyel nem lehet meghatározni, de bizonyos

élethelyzetekre van szabályozás.

Fokozott biztonságot igénylő rendszerek

Gyakran kerülnek szoftverek alkalmazásra, olyan helyzetekben, amikor a biztonságnak,a
hibátlan teljesítésnek elsőrendű fontossága van. Az ilyen fokozott biztonságot igénylő
létesítményekben, abból kell kiindulni, hogy a szoftver hibát kizárni nem lehet, csak a
következményeit megelőzni. Éppen ezért a fokozott biztonságot igényló létesítményeknél
standard előírás kell, hogy legyen párhuzamos rendszerek szolgálatba állítása, ígz ha az egyik

43
valamiért nnem üzemképes,,,a másik azonnal helyettesíteni tudja. Repüpőgépeken, a
légiirányításban, atomerőműveknél ezek az óvintézkedések már a kötelező gyakorlattá váltak,
ám vannak olyan kritikus biztonságot igénylő területek, ahol még nem előírásszerű az efféle
körültekintés.

Nagy port vert fel Angliában az az eset, amikor a londoni mentőszolgálat riasztáskijelző
rendszerének hibájából, jónéhány beérkezett segélykérő hívásra nem küldtek ki mentőautót. A
történtek után a kritika csak részben irányult a szoftverkészítők ellen, legalább ilyen
mértékben hibáztatták a mentőszolgálat óvatlanságát, amiért nem volt alternatív híváskijelző
rendszere, és amiért a rendszer használatának tesztelésére nem szántak elég időt.

Gyógyászati alkalmazás
Az angol bíróségi gyakorlat nnehezen ítél meg rosszul sikerült kezelés miatt kártérítést , mivel
a sérelem okaként többnyire nem a rossz kezelést, ahnem a betegséget tekintik. Ettől
függtelenül van olyan eset, amikor valóban maga akezelés okoz sérülést, ilyen votl az
amikor a szoftver hibája miatt sugárkezelésben részesülő betegek az előírtnál lényegesen
nagyobb dózist kaptak.

Tanácsadó szolgálatok
Vitatott a szoftverkészítők felelőssége abban az esetben is, amikor tanácsadó cégek a hibásan
feldolgozott adatok fényében téves információt adnak megrendelőiknek. Az amerikai ...
esteben amikor az adótanácsadó a stámítógépi program hibája folytén számolta el ügyfele
adóját, a bíróság nem fejlesztőt, hanem a tanácsadőt tartotta a kár okozójának, mivel
túlságosan megbított a gép eredményeiben. Jóllehet a tanácsadó bizonyítani tudta, hogy a
számítógép eredmények utánaszámolása olyan időigényes feladat, hogy az a piaci viszonyok
között élet szerűtlen volna, a bíróság úgy ítélte meg, hogy ha kisebb hibákat a szakember nem
is vesz észre nagyobb eltéréseknek a “kellő körültekintés mellett” fel kell tűnniük, ezért a kár
nem hárítható át a fejlesztőre. ...

Az elõreláthatóság - Foreseeability
Részben az ok- okozati összefüggés meglétével kapcsolatban merül fel az a probléma, hogy
sok szoftver rendkívül változatos módon felhasználható, és míg a fejlesztõ elõre láthat

44
bizonyos alkalmazásokat, mások számára is teljesen váratlanok. Jó példa erre a
táblázatkezelõ szoftverek alkalmazása, ahol a fejlesztõk többnyire tisztában vannak vele, hogy
a program hibái esetleges nayagi veszteségekhez vezetnek, és ehhez mérten próbálják
megfelelõen biztonságossá tenni a program mûködését. Ám az már nem elvárható a
fejlesztõtõl, hogy gondoljon arra is, a táblázatkezelõt kórházban ápolt szívbetegek adatainak
feldolgozására használják, és a hiba emberek halálába kerülhet. Az ilyen speciális
alkalmazásokhoz speciális biztonsági eszközök beépítése szükséges a programba, amit a
fejlesztõ ne fog magától értetõdõen beépíteni. Sajnos jelenleg a felhasználók sokszor
nincsenek annak tudatában, hogy extra biztonságot kívánó igényeikhez extra biztonságot
nyújtó szofvert kell beszerezniük, illetev megrendelniük, és így sok kár származik abból, hogy
a felhsználó nem a neki megfelelõ szoftvert szerzi be. Az elõre nem látható felhsználási mód
tehát, egyrészt problematikussá teszi az ok-okozati összefüggést, másrészt kiiktatja a
felróhatóságot. A kártérítési intézmény célja a kár bekövetkeztének megelõzése és a
méltányos kárallokáció, mind a megelõzés mind a méltányosság szempontjából az a
legmegfelelõbb megoldás, ha a megrendelõ körültekintõen szerzi be a számára szükséges
szoftvereszközt, és a fejlesztõ csak azon kockázatok viselésében kénytelen szerepet
vállalni, amelyeket elõre láthatott és a szükséglet tudatában kivédhetett.

Felróhatóság
A bíróságoknak különösen nehéz feladata van, amikor egy olyan speciális szakértelmet
kívánó területen, mint a szoftverfejlesztés, meg kell határozniuk az elvárható gondosság
kritériumait. Egyértelmű szakmai standerdek és iránymutatások hiányában ez szinte
lehetetlen. A bíróság nem tehet mást, mint hogy vakon bízik a szakértői véleményben, ám a
munka jellegéből következően a szakértő is sokszor csak találgatni tud. Az elvárható szakmai
gondosság indikátora lehet az ISO szabványok alkalmazása, illetve a részletes, alapos
dokumentáció elkészítése, ám ezeknek az indikátoroknak a megléte korántsem nevezhető
döntő bizonyítéknak a gondosság tekintetében. Így nem ritka, hogy a felkért szakértők
véleménye szöges ellentétben van egymással, mint ahogyan az sem, hogy maga a szakértői
vélemény hibás.
Lloyd -szakértő probléma
Reed/IT szakmai standerd plusz
- mi várható el egy úttörő iparágban
- mi várható el a szaktekintélytől

45
Spec. Károkozási fajta: A megtévesztés

Computer Law, Lloyd

szerzõdéskötéskor
szerzõdésben, azon kívül

A felelõsség kizárása

A felelõsség kizárásáról at egyedi szoftverfejlesztési szerzõdések vonatkozásában már volt

szó, ám nem beszéltün még arról az estrõl, amikor a szerzõ a dobozos áru csomagolásán
feltüntetett licencia engedélyben zárja ki kártérítési felelõsségét.
Amerikában hosszas vita tárgya volt, hogy az ilyen klauzulák vajon érvényesek -e. A
felhasználó ugyanis úgy fogadott el szerzõdési feltételeket, hogy azok tartalmát nem is imerte.
A dobozon csak annyi szerepelt, hogy a csomagolás feltétptése a belül lévõ licencia szerzõdés
feltételeinek elfogadását jelenti, ám maguk a feltétlelek cssaka papír belsõ oldalán
szerpeltek, sígz csak felbontás után voltak olvashatóak. A látatlanban elfogadott kikötés mind
a magyar, mind az angolszász jog szerint semmis, ám sok fogyasztónak jogi ismeretek
hiányában ennyi is elég, hogy az igényérvényesítésssel meg se próbálkozzon.
Ezen kívül a felelõsségkizárásnak, létezik egy olyan olvasata is, miszerint a a
felelõsségkizárás mint szerzõdési klauzula érvénytelen ugyan,de mint figyelmeztés adekvát
módja a gondossági kötelem teljesítésének. Azaz a figyelmeztetés birtokában a felhsználónak
tudnia kell, hogy nem bízhat meg abszolút mértékben a gép eredményeiben, és így a szerzõ
nem azzal tesz eleget a tóle elvárhetó gondosságank, hoyg hibátlan programot ír, - ilyesmi,
amint azt már fentebb kifejtettük eleve nem lehetséges eleve nem lehetséges, hanem azzal,
hogy a hibalehetõségre felhívta a fogyasztó figyelmét.

Ilyen körülmények között nem csoda, ha ritkán keeerül csak sor perindításra, habár ahogy a
szoftverek egyre nagyobb jelentőségre tesznek szert a mindennapi éleet során, az ilyen irányú
pereskedés volumene is várhhatóan nőni fog.

46
(általánosan elvárható, előrelátás
- kórházi eset
rendkívüli méltánylást érdemlő körülmények - kommentár - ezek milyen jellegűek??)

Itt megintcsak nem lehet egyelőre még a magyar gyakból példát felhozni, így újfent angol és
amerikai esetekre fogok támaszkodni.

Ehhez azonban nélkülözhetetlen az angol kárfelelősség feltételeinek rövid ismertetése, és a

kritériumok egybevetése.
1. Gondossági kötelem megléte
2. A fenti kötelezettség megszegése
3. A kár bekövetkezte a kötelezettség megszegéséből fakadóan
4. A kár nem lehet túl távoli következménye a kötelességszegésnek
5. A kárnak olyan természetűnek kell lennie, amire a törvény megítéli a kártérítést

1. Előre láthatóság
2. Felróhatóság
- gondatlanság
Különböző formái
- túlságosan bízik a szoftverben
- nem használja 27.21
3. Okság
27.22

47
Kimentési lehtőségek:
- közrehatás

Az alvállalkozó felelőssége

48