Depozitë Softuerike sipas Ligjit Holandez

Nëse biznesi juaj varet nga softueri që nuk e keni shkruar ju, ju vareni nga kompania që e ka shkruar. Ju zotëroni kodin e objektit dhe një licencë; furnizuesi zotëron kodin burimor, rrjedhën e ndërtimit dhe njohuritë. Kjo asimetri është e tolerueshme ndërsa furnizuesi është solvent dhe kompetent, dhe pushon së qeni i tillë në momentin që nuk është më. Depozitimi i softuerit është përgjigjja standarde, por funksionon vetëm nëse hartohet duke pasur parasysh ligjin holandez të falimentimit - dhe shumica e marrëveshjeve nuk janë.

Çfarë është depozita e papaguar dhe rreziku që trajton

Furnizuesi depoziton kodin burimor dhe materialet mbështetëse te një palë e tretë e pavarur, e cila i mban ato derisa të ndodhë një ngjarje e përcaktuar dhe më pas ia lëshon ato klientit, i cili mund ta përdorë dhe modifikojë kodin për ta mbajtur softuerin në punë. Rreziku është vazhdimësia, jo pronësia: një klient që drejton përpunimin e porosive, të dhënat e pacientëve ose planifikimin e prodhimit në produktin e një furnizuesi nuk mund të kalojë brenda natës, sepse migrimi zgjat muaj dhe zakonisht ka nevojë për ndihmën e furnizuesit që largohet. Depozita e përkohshme blen kohën për t'u larguar në një mënyrë të rregullt. Tri situata kanë rëndësi:

• Paaftësia paguese. Furnizuesi shpallet i falimentuar, emërohet një administrator, stafi largohet dhe mbështetja ndërpritet. Skenari i depozitës në ruajtje është hartuar për të dhe ku funksionon më shumë ligji holandez.
• Ndërprerje. Furnizuesi tërheq produktin, anulon versionin tuaj ose blihet nga dikush që nuk ka interes në vendosjen tuaj. Më e zakonshme se falimentimi dhe shpesh lihet jashtë klauzolës së lirimit.
• Dështim i vazhdueshëm për të mirëmbajtur. Furnizuesi ekziston ende dhe ende lëshon fatura, por nuk rregullon më defektet, nuk dërgon arna sigurie ose nuk e mban produktin të pajtueshëm me varësitë e tij.

Marrëveshjet dypalëshe dhe trepalëshe

Një marrëveshje dypalëshe është një premtim në kontratën kryesore se furnizuesi do të dorëzojë kodin burimor nëse ndodh një ngjarje e përcaktuar. Është e lirë dhe e dobët: askush nuk kontrollon në mënyrë të pavarur nëse diçka është depozituar ose është mbajtur e azhurnuar, dhe - në mënyrë vendimtare - në rast falimentimi ju i kërkoni administratorit të përmbushë një detyrim të pasurisë, gjë që ai nuk është i detyruar ta bëjë.

Një marrëveshje trepalëshe shton një agjent të depozitës si palë kontraktuese. Agjenti merr kujdestarinë, kontrollon depozitën, e mban atë dhe ju ka një detyrim të drejtpërdrejtë për ta liruar atë. Kjo është e gjithë arsyeja për të paguar për një të tillë: lirimi bëhet përmbushje nga një palë e tretë me aftësi paguese sipas kontratës së saj, jo nga një pasuri e falimentuar. Agjenti gjithashtu vendos nëse ka ndodhur një ngjarje lirimi, duke ia hequr atë një administratori pa asnjë nxitje për t'ju ndihmuar.

Çfarë depozitohet në të vërtetë

Dështimi më i zakonshëm nuk është i ligjshëm. Është një depozitë që përmban kod burimor dhe asgjë tjetër. Kodi burimor vetëm nuk kompilohet: nëse i jepet një zhvilluesi pa udhëzime ndërtimi dhe pa listë varësish, një bazë e madhe kodi mund të kërkojë javë të tëra inxhinierie të kundërt përpara se të japë një skedar binar që funksionon — kohë që nuk e keni kur sistemi nuk mbështetet tashmë. Një depozitë pa udhëzime ndërtimi është e pavlerë.

Shtoni një detyrim përditësimi. Një depozitë e bërë një herë në momentin e nënshkrimit skadon brenda një ose dy ciklish publikimi. Lidhni depozitat me orarin e publikimit - çdo publikim të madh ose një interval të caktuar - dhe merrni të drejtën të njoftoheni kur një i tillë është me vonesë.

Verifikimi: për çfarë po paguani

Bli opsionin e mesëm më poshtë si standard, dhe testin e plotë aty ku një ndërprerje do të ishte ekzistenciale. Vetëm kontrolli në nivel skedari është pothuajse sikur nuk blen asgjë.

• Kontroll në nivel skedari. Agjenti konfirmon që depozita është e lexueshme, pa viruse dhe përputhet me një listë skedarësh. Kjo vërteton që diçka ka mbërritur, jo që funksionon.
• Plotësia dhe shqyrtimi i dokumentacionit. Agjenti kontrollon udhëzimet dhe varësitë e ndërtimit kundrejt depozitës dhe raporton boshllëqet. Ky opsion i mesëm është i duhuri për shumicën e klientëve: ai kap dështimet e zakonshme - hapat e ndërtimit që mungojnë, varësitë e padokumentuara, një komponent që nuk keni të drejtë ta përdorni - me një kosto shumë më të ulët se një test i plotë.
• Test i plotë i ndërtimit dhe ekzekutimit. Agjenti e përpilon depozitën në një mjedis të pastër dhe e ekzekuton atë në të dhënat e testimit. I vetmi nivel që vërteton se depozita funksionon, por më i ngadaltë, më i shtrenjtë dhe që ka nevojë për përsëritje ndërsa softueri ndryshon.

Ngjarjet e publikimit, të hartuara në mënyrë që të mos mund të debatohen rreth tyre

Një klauzolë lirimi është një shkas që agjenti i depozitës duhet ta aplikojë nën presion dhe pa këshilla ligjore. Çdo ngjarje duhet të jetë e përcaktueshme nga një dokument ose kalimi i kohës, jo nga një gjykim në lidhje me sjelljen e furnizuesit.

Dy pika bëjnë pjesën më të madhe të punës. Ia ngarkojnë barrën e kundërshtimit furnizuesit: klienti njofton agjentin me prova, furnizuesi ka një periudhë të shkurtër të caktuar për të kundërshtuar dhe, në mungesë të kundërshtimit, agjenti e lëshon. Dhe përcaktoni paraprakisht rrugën e mosmarrëveshjes - përcaktimin e ekspertit ose arbitrazhin në një afat të shkurtër kohor - në mënyrë që një kundërshtim të blejë ditë, jo muaj.

Çështja e falimentimit holandez

Çdo gjë më sipër është hartim kontrate. Ajo që vijon përcakton nëse ajo është e vlefshme kur furnizuesi falimenton.

Çfarë mund të refuzojë administratori

Sipas nenit 37 Fw, kur një kontratë reciproke nuk është ekzekutuar plotësisht nga asnjëra palë në kohën e urdhrit të falimentimit, pala tjetër mund t'i caktojë administratorit një afat të arsyeshëm me shkrim për të deklaruar nëse do ta ekzekutojë; nëse nuk e bën, humbet të drejtën për të kërkuar ekzekutim në këmbim. Ajo që nuk bën neni 37 Fw është ndërprerja e kontratës ose dhënia e administratorit të drejtës për ta ndërprerë. Kontrata mbetet në fuqi; administratori thjesht nuk është i detyruar ta ekzekutojë, dhe pala tjetër mbetet me një kërkesë në falimentim sipas nenit 37a Fw.

Për softuerët, kjo do të thotë që administruesi mund të refuzojë mirëmbajtjen, mbështetjen, përditësimet, strehimin dhe depozitat e mëtejshme: performanca aktive që i kushtojnë para pasurisë. Prisni refuzim. Pyetja është nëse mund të shkojë më tej dhe t'ju ndalojë të përdorni atë që keni tashmë.

Nebula, berzona dhe Credit Suisse/Jongepier

Për një dekadë kjo ishte vërtet e pasigurt. Në çështjen Nebula (Hoge Raad, 3 nëntor 2006, ECLI:NL:HR:2006:AX8838) Gjykata e Lartë vendosi që, megjithëse falimentimi në vetvete nuk i ndërpret marrëveshjet ekzistuese, një palë tjetër që mban një të drejtë përdorimi nuk mund të vazhdonte ta ushtronte atë kundër administratorit sikur të mos kishte ndodhur falimentim; kjo do t'i lejonte një kreditori të shpërfillte falimentimin në kurriz të të tjerëve. U interpretua gjerësisht si lejimi i një administratori të linte mënjanë një të drejtë përdorimi paraprakisht, dhe kjo i alarmoi licencuesit.

Ky interpretim nuk mbijetoi. Në çështjen ABN AMRO/Berzona (Hoge Raad, 11 korrik 2014, ECLI:NL:HR:2014:1681), Gjykata e Lartë vendosi që falimentimi nuk ka efekt në marrëveshjet ekzistuese reciproke ose detyrimet që rrjedhin prej tyre, dhe nuk i jep administratorit asnjë fuqi që ligji ose kontrata nuk ia japin - për shembull, ai nuk mund të ndërpresë një kontratë qiraje që është ende në fuqi.

Pozicioni u zgjidh në çështjen Credit Suisse/Jongepier qq (Hoge Raad, 23 Mars 2018, ECLI:NL:HR:2018:424). Administratori mund të refuzojë në mënyrë pasive të përmbushë detyrimet, por falimentimi nuk i jep atij fuqinë për të anuluar një përmbushje të kryer nga debitori para falimentimit, as për të përfunduar një përmbushje të vazhdueshme për aq sa ajo konsiston në tolerimin ose përmbajten nga diçka.

Kjo frazë është ajo që ka rëndësi për softuerin. Një licencë është në thelb një angazhim nga mbajtësi i të drejtës për të toleruar përdorimin që përndryshe do të shkelte të drejtën e autorit - një performancë e vazhdueshme që konsiston në tolerimin. Sipas ligjit aktual, pra, një licencë e dhënë në mënyrë të vlefshme para falimentimit mbetet në fuqi dhe administratori nuk mund ta revokojë atë. Administratori mund të refuzojë gjithçka aktive, por nuk mund të shkëpusë një të drejtë përdorimi që ju keni.

Çfarë do të thotë kjo për marrëveshjen tuaj

Dy gjëra vijojnë. Detyrimi i lirimit duhet të mbahet mbi agjentin e depozitës, jo mbi furnizuesin: i krijuar si një kujdestari e pavarur e mbajtur nga një palë e tretë, lirimi është përmbushje e vetë agjentit dhe fuqia e administratorit sipas nenit 37 Fw përqendrohet te përmbushjet e detyruara nga pasuria dhe jo te një agjent me aftësi paguese, ndërsa një premtim dypalësh kërkon përmbushje nga pasuria, të cilën administratori mund ta refuzojë. Dhe të japë licencën paraprakisht në vend që të lirohet - pika e vetme më e rëndësishme e hartimit, e trajtuar më poshtë.

Në një ristrukturim dhe jo në një falimentim, neni 373 Fw kufizon mbështetjen në klauzolat ipso facto - dispozita që i lejojnë një pale tjetër të ndryshojë, pezullojë ose ndërpresë një kontratë vetëm sepse ka filluar një procedurë ristrukturimi. Ky kufizim vepron në procedurën e skemës, jo në falimentim, dhe përgjigjja për të është përsëri strukturore: kur marrëveshja hartohet si një kujdestari e pavarur nga një palë e tretë, shkaktari i lirimit vepron mbi detyrimin e vetë agjentit dhe nuk përbën një dispozitë ipso facto të hapur për t'u lënë mënjanë, në një ristrukturim WHOA ashtu siç nuk bëhet në një falimentim.

Si duhet të strukturohet licenca

Depozita e depozitës ju jep një kopje të kodit burimor, jo të drejtën për të bërë asgjë me të. Kodi burimor është një vepër e mbrojtur; përpilimi i tij, modifikimi i tij dhe ekzekutimi i rezultatit janë veprime të kufizuara. Pa një licencë që i mbulon ato, një depozitë e lëshuar është një dosje që nuk mund ta hapni. Bashkoni depozitën e depozitës me një licencë që i lejon shprehimisht klientit, pas lëshimit, të përdorë, përpilojë, modifikojë dhe zhvillojë më tej kodin burimor, dhe që kjo të bëhet nga një palë e tretë - në praktikë nuk do ta bëni vetë punën.

Pastaj koha. Një licencë e dhënë me lirim është e brishtë. Nëse ngjarja e lirimit është vetë falimentimi, dhënia do të duhet të bëhet nga një debitor i cili, që nga dita e urdhrit të falimentimit, ka humbur të drejtën për të disponuar asetet në pasuri; nenet 23 Fw dhe 35 Fw pengojnë dhe administratori nuk do ta bëjë dhënien për ju. Credit Suisse/Jongepier do të thotë që administratori nuk mund të revokojë një licencë që e keni pasur tashmë - por nuk ka asgjë për të revokuar nëse nuk e keni pasur kurrë një të tillë.

Jepjani atë në vetë kontratën, para çdo falimentimi, në varësi të një kushti paraprak: jepet tani, duke hyrë në fuqi në një ngjarje lirimi. E drejta ekziston që nga data e kontratës; vetëm efekti i saj shtyhet. Ligji holandez në përgjithësi është i hapur ndaj kësaj strukture. Në çështjen Rabobank/Reuser (Hoge Raad, 3 qershor 2016, ECLI:NL:HR:2016:1046) Gjykata Supreme pranoi se kur një e drejtë e kushtëzuar krijohej para falimentimit, përmbushja e kushtit më pas hynte në fuqi pa ndonjë veprim të mëtejshëm nga debitori. Ky rast kishte të bënte me një transferim të kushtëzuar të mallrave dhe një peng mbi të drejtën e kushtëzuar. Zbatimi i tij në një licencë të të drejtës së autorit të dhënë me kusht është një ekstrapolim i mbështetur në literaturën ligjore dhe jo një pikë e vendosur nga gjykatat, dhe duhet të paraqitet si i tillë.

Konfirmoni gjithashtu se përdorimi i materialit të publikuar nuk ka nevojë për pëlqim të mëtejshëm nga furnizuesi ose administratori i tij, dhe se lejohet nënlicencimi për një zhvillues pasardhës.

SaaS dhe cloud: kodi burimor nuk është i mjaftueshëm

Për softuerët që përdorni vetë, kodi burimor plus udhëzimet e ndërtimit plus një licencë është afër një përgjigjeje të plotë. Për një shërbim nuk është. Nëse platforma e furnizuesit errësohet, ju keni humbur aplikacionin, mjedisin në të cilin është ekzekutuar dhe të dhënat tuaja - dhe kodi burimor rikthen vetëm të parën, ngadalë. Një marrëveshje vazhdimësie SaaS duhet të shtojë tre gjëra:

• Mjedisi operativ. Imazhet e kontejnerëve, përkufizimet e infrastrukturës-si-kod, konfigurimi, cilësimet e rrjetit dhe të sigurisë, varësitë e kohës së ekzekutimit — të mjaftueshme për ta mbështetur platformën diku tjetër.
• Të dhënat. Eksporte të rregullta të të dhënave tuaja në një format të dokumentuar, jo-pronësor, me skemën. Të dhënat që nuk mund t'i lexoni nuk janë të dhëna që i keni, dhe eksportet duhet të kryhen gjatë gjithë kontratës, jo vetëm në momentin e publikimit.
• Marrëdhënia pritëse. Një rrugë për të hyrë në kontratën e furnizuesit me ofruesin e tij të hostimit, ose njoftim për atë ofrues se ju mund të merrni përsipër llogarinë dhe të paguani drejtpërdrejt.

Alternativat dhe kush paguan

Depozita e garancisë nuk është gjithmonë vlera më e mirë, veçanërisht për produktet standarde ku jeni një klient midis mijërave dhe rreziku real është një perëndim dielli sesa një dështim. Tre opsione më të lehta janë shpesh më të dobishme: një e drejtë daljeje të të dhënave - eksportime periodike në një format të dokumentuar, të testuara të paktën një herë - që mbulojnë pjesën më të madhe të ekspozimit pothuajse pa asnjë kosto; një e drejtë për një kopje të ekzekutueshme , një imazh të zbatueshëm që mund ta ekzekutoni për një periudhë kalimtare, duke rikthyer shërbimin shumë më shpejt se një rindërtim; dhe pagesë direkte te ofruesi i hostimit , duke e mbajtur mjedisin në funksion ndërsa migroni - vazhdimësia më e lirë e cloud-it, dhe më shpesh e anashkaluar.

Kur përdorni depozitë në ruajtje, prisni një tarifë të vetme konfigurimi, një tarifë vjetore të përsëritur të kujdestarisë dhe tarifa të ndara për verifikim që shkallëzohen me thellësinë e çekut. Kostoja i takon kujtdo që dëshiron mbrojtjen, normalisht klientit, megjithëse një furnizues që ofron depozitë në ruajtje si pikë shitjeje mund ta mbajë atë, dhe një marrëveshje me shumë përfitues që mbulon disa klientë të një produkti e shpërndan atë - pika e zakonshme e uljes ku një furnizues reziston. Bëjeni mospagesën diçka që agjenti duhet t'ju njoftojë, me të drejtën për të paguar në vend të saj.

Një listë kontrolli për negocimin e një marrëveshjeje për depozitë në llogari të palëve të treta

• A është një marrëveshje e vërtetë trepalëshe me një agjent të pavarur që ju detyron të lironi drejtpërdrejti?
• A është dhënë licenca për të përdorur, përpiluar, modifikuar dhe zhvilluar më tej kodin burimor? tani, i nënshtruar një kushti paraprak, në vend që të premtohej me lirimin?
• A përfshin lista e depozitave udhëzime ndërtimi, varësi, çelësa licence dhe dokumentacion, jo vetëm kod burimor, të përditësuar në çdo version?
• Çfarë niveli verifikimi është kontraktuar dhe sa shpesh përsëritet?
• A janë ngjarjet e publikimit të përcaktueshme nga një dokument apo nga kalimi i kohës, me një periudhë të shkurtër kundërshtimi dhe një rrugë të shpejtë mosmarrëveshjeje?
• Për SaaS: a mbulohen mjedisi, të dhënat dhe marrëdhënia e hostimit, apo vetëm kodi?
• Kush paguan, çfarë ndodh nëse furnizuesi ndalon së paguari dhe a përputhet marrëveshja e depozitës me ligjin që rregullon kontratën kryesore dhe klauzolat e pronësisë intelektuale?