Szoftverletéti szerződés holland törvények szerint

Ha az üzleted olyan szoftvertől függ, amelyet nem te írtál, akkor attól a cégtől függsz, amelyik írta. Te birtoklod a tárgykódot és a licencet; a beszállító birtokolja a forráskódot, a build folyamatot és a tudást. Ez az aszimmetria addig tolerálható, amíg a beszállító fizetőképes és kompetens, és abban a pillanatban megszűnik az lenni, amikor már nem az. A szoftverletéti számlák a standard megoldás, de csak akkor működik, ha a holland fizetésképtelenségi törvényeket szem előtt tartva fogalmazzák meg – és a legtöbb megállapodás nem az.

Mi a letéti számlázás és milyen kockázatokat kezel?

A beszállító letétbe helyezi a forráskódot és a támogató anyagokat egy független harmadik félnél, amely egy meghatározott esemény bekövetkeztéig őrzi azokat, majd átadja azokat az ügyfélnek, aki felhasználhatja és módosíthatja a kódot a szoftver működésének fenntartása érdekében. A kockázat a folytonosság, nem a tulajdonjog: egy ügyfél, aki a megrendelések feldolgozását, a betegnyilvántartást vagy a termeléstervezést egy beszállító termékén futtatja, nem tud egyik napról a másikra váltani, mert a migráció hónapokig tart, és általában a távozó beszállító segítségére van szükség. A letéti szerződés megvásárolja az időt a rendezett kilépéshez. Három helyzet számít:

• Fizetésképtelenség. A beszállítót csődbe mentették, vagyonkezelőt neveztek ki, a személyzet távozott, és a támogatás leállt. A letéti számlára vonatkozó forgatókönyvet írták elő, és itt működik a legtöbbet a holland jog.
• Megszakítás. A szállító kivonja a terméket a forgalomból, lemondja a verziódat, vagy olyan személy vásárolja fel, akinek nincs érdeke a telepítésedben. Gyakoribb, mint a csőd, és gyakran kimarad a kiadási záradékból.
• Állandó karbantartási mulasztás. A beszállító továbbra is létezik és továbbra is számláz, de már nem javítja a hibákat, nem szállít biztonsági javításokat, és nem tartja kompatibilisen a terméket a függőségeivel.

Kétoldalú és háromoldalú megállapodások

A kétoldalú megállapodás egy ígéret a fő szerződésben, miszerint a szállító átadja a forráskódot, ha egy meghatározott esemény bekövetkezik. Olcsó és gyenge: senki sem ellenőrzi függetlenül, hogy bármit is letétbe helyeztek vagy naprakészen tartottak-e, és – döntően – csőd esetén a vagyonkezelőt arra kéred, hogy teljesítsen egy kötelezettséget a hagyatékból, amire nem köteles.

Egy háromoldalú megállapodásban egy letéti ügynököt szerződtetnek. Az ügynök átveszi a letétet, ellenőrzi a letétet, megtartja azt, és közvetlen kötelezettsége van Önnek annak felszabadítására. Ez az egyetlen oka annak, hogy fizetni kell érte: a felszabadítás egy fizetőképes harmadik fél általi teljesítést jelent a saját szerződése alapján, nem pedig egy csődvagyon által. Az ügynök dönti el azt is, hogy bekövetkezett-e felszabadítási esemény, elveszi ezt a lehetőséget egy vagyonkezelőtől, akinek nincs ösztönzője a segítségére.

Ami valójában letétbe kerül

A leggyakoribb hiba nem legális. Ez egy olyan beküldés, amely forráskódot tartalmaz és semmi mást. A forráskód önmagában nem fordul le: ha egy fejlesztőnek átadják fordítási utasítások és függőségi lista nélkül, egy nagy kódbázis hetekig tartó visszafejtése is eltarthat, mire egy futó bináris fájlt eredményez – ez az idő nincs, amikor a rendszer már nem támogatott. A fordítási utasítások nélküli beküldés értéktelen.

Frissítési kötelezettség bevezetése. Az aláíráskor egyszer befizetett összeg egy vagy két kiadási cikluson belül lejár. A befizetéseket kösd a kiadási ütemtervhez – minden nagyobb kiadáshoz vagy egy fix intervallumhoz –, és tartsd fenn a jogodat, hogy értesítést kapj, ha késel.

Ellenőrzés: amiért fizet

Alapértelmezés szerint a középső opciót vedd meg, és a teljes tesztet, ahol egy esetleges kimaradás létező lenne. A fájlszintű ellenőrzés önmagában szinte semmit sem ér.

• Fájl szintű ellenőrzés. Az ügynök megerősíti, hogy a beküldött anyag olvasható, vírusmentes és egyezik a fájllistával. Ez azt bizonyítja, hogy valami megérkezett, nem azt, hogy működik.
• Teljesség és dokumentáció felülvizsgálata. Az ügynök ellenőrzi a build utasításokat és függőségeket a deponált tartalommal szemben, és jelenti a hiányosságokat. Ez a középső lehetőség a legtöbb ügyfél számára megfelelő: a gyakori hibákat – hiányzó build lépéseket, nem dokumentált függőségeket, olyan komponenseket, amelyek használatára nincs jogod – egy teljes teszt költségének töredékéért kiszűri.
• Teljes körű build és teszt futtatása. Az ügynök egy tiszta környezetben összeállítja a befizetést, és tesztadatokkal futtatja le. Ez az egyetlen szint, amely bizonyítja a befizetés működését, de lassabb, drágább, és ismétlést igényel a szoftver változásai miatt.

Megjelenési események, úgy megírva, hogy ne lehessen róluk vitatkozni

A feloldási záradék egy olyan kiváltó ok, amelyet a letéti ügynöknek nyomás alatt és jogi tanácsadás nélkül kell alkalmaznia. Minden eseménynek dokumentumból vagy az idő múlásából kell megállapíthatónak lennie, nem pedig a szállító magatartásáról alkotott ítéletből.

Két pont végzi el a munka nagy részét. Az ellentmondás terhét a szállítóra kell hárítani: az ügyfél bizonyítékokkal értesíti az ügynököt, a szállítónak rövid, fix ideje van kifogást emelni, kifogás hiányában pedig az ügynök eláll. És előre rögzíteni kell a vita útját – szakértői döntés vagy rövid határidővel rendezett választottbírósági eljárás –, így egy kifogás napokat, nem pedig hónapokat vásárol.

A holland fizetésképtelenségi kérdés

A fentiek mind szerződéses konstrukciók. A következők döntik el, hogy érvényesek-e, ha a szállító csődbe megy.

Amit a vagyonkezelő megtagadhat

A 37. Fw. cikk értelmében, amennyiben egy kölcsönös szerződést a csődeljárás megindításának időpontjában egyik fél sem teljesített teljes mértékben, a másik fél ésszerű írásbeli határidőt állapíthat meg a vagyonfelügyelőnek, hogy nyilatkozzon arról, hogy teljesíti-e a szerződést; ha nem teljesíti, elveszíti a jogát, hogy cserébe teljesítést követeljen. A 37. Fw. cikk nem szünteti meg a szerződést, és nem ad felhatalmazást a vagyonfelügyelőnek a felmondásra. A szerződés fennmarad; a vagyonfelügyelő egyszerűen nem köteles teljesíteni, és a másik félnek a 37a. Fw. cikk értelmében csődeljárási követelése marad.

Szoftverek esetében ez azt jelenti, hogy a vagyonkezelő megtagadhatja a karbantartást, a támogatást, a frissítéseket, a tárhelyet és a további befizetéseket: ezek az aktív szolgáltatások pénzbe kerülnek a hagyatéknak. Számítson az elutasításra. A kérdés az, hogy mehet-e tovább, és megakadályozhatja-e a már meglévő eszközeinek használatát.

Nebula, Berzona és Credit Suisse/Jongepier

Egy évtizedig ez valóban bizonytalan volt. A Nebula- ügyben (Hoge Raad, 2006. november 3., ECLI:NL:HR:2006:AX8838) a Legfelsőbb Bíróság kimondta, hogy bár a csőd önmagában nem szünteti meg a meglévő megállapodásokat, a használati joggal rendelkező másik fél nem gyakorolhatja azt a vagyonkezelővel szemben úgy, mintha nem történt volna csőd; ez lehetővé tenné az egyik hitelező számára, hogy a többiek kárára figyelmen kívül hagyja a csődöt. Széles körben úgy értelmezték, hogy a vagyonkezelő félretehet egy korábban meglévő használati jogot, és ez aggodalomra adott okot az engedélyeseknek.

Ez az olvasat nem maradt fenn. Az ABN AMRO/Berzona ügyben (Hoge Raad, 2014. július 11., ECLI:NL:HR:2014:1681) a Legfelsőbb Bíróság kimondta, hogy a csődnek nincs hatása a meglévő kölcsönös megállapodásokra vagy az azokból eredő kötelezettségekre, és a vagyonkezelőnek nem ad olyan jogkört, amelyet a törvény vagy a szerződés nem biztosít számára – például nem szüntethet meg egy még folyamatban lévő bérleti szerződést.

A helyzetet a Credit Suisse/Jongepier qq ügyben rendezték (Hoge Raad, 2018. március 23., ECLI:NL:HR:2018:424). A vagyonfelügyelő passzívan megtagadhatja a teljesítést, de a csőd nem jogosítja fel arra, hogy visszavonja az adós által a csőd előtt teljesített teljesítést, sem arra, hogy megszüntesse a folyamatos teljesítést, amennyiben az valaminek a tűrésében vagy attól való tartózkodásában áll.

Ez a kifejezés számít a szoftverek esetében. A licenc lényegében a jogosult kötelezettségvállalása arra, hogy eltűri a szerzői jogokat egyébként sértő használatot – egy folyamatos teljesítmény, amely a tűrésből áll. A jelenlegi jogszabályok szerint tehát a csődeljárás előtt érvényesen megadott licenc hatályban marad, és a vagyonfelügyelő nem vonhatja vissza. A vagyonfelügyelő mindent megtagadhat, ami aktív, de nem kapcsolhatja ki a meglévő használati jogot.

Mit jelent ez az elrendezésed szempontjából?

Két dolog következik ebből. A felszabadítási kötelezettséget továbbra is a letéti ügynöknek kell fenntartani, nem pedig a szállítónak: egy harmadik fél által kezelt független letétként létrehozva a felszabadítás a megbízott saját teljesítménye, és a vagyonkezelőnek a 37. cikk szerinti hatásköre a hagyaték által fizetendő teljesítésekre vonatkozik, nem pedig a fizetőképes ügynökre, míg a kétoldalú ígéret a hagyaték általi teljesítést követeli meg, amelyet a vagyonkezelő elutasíthat. És az engedélyt előre, ne pedig a felszabadításkor kell megadni – ez a legfontosabb megfogalmazási pont, amelyet alább tárgyalunk.

A 373 Fw. cikk inkább átszervezés, mint csődeljárás esetén korlátozza az ipso facto záradékokra való támaszkodást – olyan rendelkezésekre, amelyek lehetővé teszik a másik fél számára a szerződés módosítását, felfüggesztését vagy megszüntetését pusztán azért, mert átszervezési eljárás indult. Ez a korlátozás a rendszereljárásban érvényes, nem pedig csődeljárásban, és a válasz ismét strukturális: ha a megállapodást egy harmadik fél független letétkezelésként fogalmazza meg, a feloldó kiváltó ok a megbízott saját kötelezettségére vonatkozik, és nem minősül ipso facto rendelkezésnek, amelyet akár egy WHOA átszervezése során, akárcsak egy csődeljárásban.

Hogyan kell felépíteni a licencet

A Letéti Szolgáltatás a forráskód másolatát adja, nem pedig a jogot arra, hogy bármit is kezdj vele. A forráskód védett mű; fordítása, módosítása és az eredmény futtatása korlátozott cselekmények. Licenc nélkül a felszabadított letét egy olyan mappa, amelyet nem nyithatsz meg. Párosítsd a letéti szolgáltatást egy olyan licenccel, amely kifejezetten feljogosítja az ügyfelet a kiadáskor a forráskód használatára, fordítására, módosítására és továbbfejlesztésére, valamint arra, hogy ezt harmadik féllel végeztesse el – a gyakorlatban nem fogod magad elvégezni a munkát.

Aztán az időzítés. A mentesítéskor megadott engedély ingatag. Ha a mentesítési esemény maga a csőd, akkor az engedélyt annak az adósnak kellene megadnia, aki a csődeljárás napjától elvesztette a vagyonban lévő vagyon feletti rendelkezésre vonatkozó jogkörét; a 23. és a 35. cikk az útban van, és a vagyonkezelő nem fogja megadni az engedélyt az Ön helyett. A Credit Suisse/Jongepier azt jelenti, hogy a vagyonkezelő nem vonhatja vissza a már meglévő engedélyt – de nincs mit visszavonni, ha soha nem volt ilyen.

Magában a szerződésben, bármilyen fizetésképtelenség előtt, egy előzetes feltételhez kötötten kell megadni: most megadva, egy jogfeladási esemény bekövetkeztével hatályba lépve. A jog a szerződés napjától létezik; csak a hatálya halasztott. A holland jog általában fogékony erre a struktúrára. A Rabobank/Reuser ügyben (Hoge Raad, 2016. június 3., ECLI:NL:HR:2016:1046) a Legfelsőbb Bíróság elfogadta, hogy amennyiben egy feltételes jogot a csőd előtt hoztak létre, a feltétel utólagos teljesítése az adós további cselekménye nélkül hatályba lép. Ez az eset a javak feltételes átruházására és a feltételes jogra vonatkozó zálogjogra vonatkozott. Ennek feltételesen megadott szerzői jogi licencre való alkalmazása a jogirodalomban alátámasztott extrapoláció, nem pedig a bíróságok által eldöntött pont, és így is kell bemutatni.

Azt is meg kell erősíteni, hogy a kiadott anyag felhasználásához nincs szükség a szállító vagy annak megbízottjának további hozzájárulására, és hogy a jogutód fejlesztőnek történő allicencezés megengedett.

SaaS és felhő: a forráskód nem elég

Egy saját magad által üzemeltetett szoftver esetében a forráskód, a build utasítások és a licenc majdnem teljes választ ad. Egy szolgáltatás esetében ez nem az. Ha a szállító platformja elsötétül, akkor elveszíted az alkalmazást, a környezetet, amelyben futott, és az adataidat is – a forráskód pedig csak az elsőt állítja vissza, lassan. Egy SaaS folytonossági megoldásnak három dolgot kell hozzáadnia:

• A működési környezet. Konténerképek, infrastruktúra-kód definíciók, konfiguráció, hálózati és biztonsági beállítások, futásidejű függőségek – elég ahhoz, hogy a platform máshol is megállja a helyét.
• Az adatok. Saját adataid rendszeres exportálása dokumentált, nem védett formátumban, a sémával együtt. Azok az adatok, amelyeket nem tudsz elolvasni, nem a te adatod, és az exportálásnak a szerződés teljes időtartama alatt futnia kell, nem csak a kiadáskor.
• A vendéglátói kapcsolat. Egy mód, amellyel beléphetsz a szállító és a tárhelyszolgáltató közötti szerződésbe, vagy értesítheted a szolgáltatót arról, hogy átveheted a fiókot és közvetlenül fizethetsz.

Alternatívák, és ki fizet?

A letéti számlázás nem mindig a legjobb ár-érték arányú megoldás, különösen a standard termékek esetében, ahol Ön egy ügyfél a több ezer közül, és a reális kockázat inkább a lejárat, mint a kudarc. Három könnyebb lehetőség gyakran hasznosabb: az adatok kilépési joga – időszakos exportálás dokumentált formátumban, legalább egyszer tesztelve –, amely a kockázatok nagy részét szinte ingyenesen lefedi; a futó példányhoz való jog , egy telepíthető rendszerkép, amelyet átmenetileg futtathat, így a szolgáltatás sokkal gyorsabban helyreállítható, mint egy újjáépítés; és a közvetlen fizetés a tárhelyszolgáltatónak , amely a környezet működését biztosítja a migráció alatt – a legolcsóbb felhőfolytonosság, amelyet leggyakrabban figyelmen kívül hagynak.

Amennyiben letéti számlát használ, számítson egyszeri beállítási díjra, rendszeres éves letéti díjra és külön díjakra minden ellenőrzés után, amelyek az ellenőrzés mélységével arányosak. A költségeket az viseli, aki szeretné a védelmet, általában az ügyfél, bár egy letéti számlát értékesítési pontként kínáló szállító is igénybe veheti, és egy több kedvezményezettre kiterjedő, egy termék több ügyfelét lefedő megállapodás szétteríti a költségeket – ez a szokásos kikötési pont, ahol a szállító ellenáll. A fizetés elmaradását az ügynöknek értesítenie kell Önt, és joga van helyette fizetni.

Ellenőrzőlista letéti megállapodás tárgyalásához

• Valódi háromoldalú megállapodásról van szó egy független ügynökkel, aki közvetlen kiadási kötelezettséggel tartozik Önnek?
• A forráskód használatára, fordítására, módosítására és továbbfejlesztésére vonatkozó engedély megadva van? Most, előzetes feltételhez kötött, ahelyett, hogy a megjelenéskor ígérték volna?
• A letéti lista tartalmazza a fordítási utasításokat, függőségeket, licenckulcsokat és dokumentációt, nem csak a forráskódot, minden kiadáskor frissítve?
• Milyen ellenőrzési szintre vonatkozik a szerződés, és milyen gyakran ismétlik meg?
• A kiadási események dokumentumból vagy az idő múlásából határozhatók meg, rövid kifogásolási időszakkal és gyors vitarendezési eljárással?
• SaaS esetén: a környezet, az adatok és a tárhelyszolgáltatási kapcsolat is le van fedve, vagy csak a kód?
• Ki fizet, mi történik, ha a szállító leállítja a fizetést, és a letéti megállapodás megfelel-e a fő szerződés irányadó jogszabályainak és a szellemi tulajdonjogokra vonatkozó záradékoknak?