Escrow pentru software conform legislației olandeze: supraviețuiește unui faliment?

Contractul de escrow pentru software vă protejează dacă furnizorul dvs. de software dă faliment sau încetează să își întrețină produsul: un agent independent deține codul sursă și vi-l eliberează atunci când are loc un eveniment convenit. Conform legislației olandeze, funcționează numai dacă acordul este un acord tripartit și licența dvs. de utilizare a codului sursă este acordată în avans, nu la lansare.

Dețineți codul executabil și o licență; furnizorul deține codul sursă, instrumentele de compilare și cunoștințele. Mai jos vă explicăm cum să configurați un escrow astfel încât acesta să fie valabil în conformitate cu Legea olandeză privind falimentul (Faillissementswet, Fw).

Ce este escrow-ul software și ce riscuri acoperă?

Furnizorul depune codul sursă și materialele suport la o terță parte independentă, agentul escrow. Agentul le păstrează până când are loc un eveniment definit, apoi vi le eliberează, astfel încât să puteți menține software-ul în funcțiune.

Riscul constă în continuitate, nu în proprietate. O companie care își desfășoară procesarea comenzilor sau planificarea producției pe baza produsului unui singur furnizor are nevoie de luni de zile pentru a migra, de obicei cu ajutorul furnizorului care pleacă. Contul Escrow vă oferă timp pentru a pleca într-un mod ordonat. Trei situații contează.

• Insolvență. Furnizorul este declarat falimentar, un administrator judiciar (custode) este numit, personalul pleacă și suportul se oprește. Acesta este scenariul pentru care este scris escrow-ul și cel în care legislația olandeză joacă cel mai important rol.
• Întreruperea. Furnizorul retrage produsul, nu mai oferă asistență pentru versiunea dvs. sau este preluat de o companie care nu are niciun interes în instalarea dvs. Acest lucru se întâmplă mai des decât falimentul și adesea lipsește din clauza de reziliere.
• Eșec persistent în întreținere. Furnizorul încă există și încă facturează, dar nu mai remediază defectele, nu mai emite patch-uri de securitate și nu mai menține produsul compatibil cu sistemele de care depinde.

Ar trebui să alegeți un aranjament cu două sau cu trei părți?

Alegeți un acord tripartit. Numai atunci eliberarea este efectuată de o terță parte solvabilă în baza propriului contract, și nu de un furnizor falimentar.

Un acord bipartit este o promisiune în contractul principal că furnizorul va preda codul sursă dacă are loc un eveniment definit. Este ieftin, dar slab. Nimeni nu verifică independent dacă a fost depus sau actualizat ceva. Mai important, după un faliment, îi cereți administratorului judiciar să îndeplinească o obligație din masa falimentului, iar administratorul judiciar nu este obligat să facă acest lucru.

Un acord tripartit adaugă agentul escrow ca parte la contract. Agentul preia custodia depozitului, îl verifică, îl păstrează și vă are obligația directă de a-l elibera. De asemenea, agentul decide dacă a avut loc un eveniment de eliberare. Acest lucru îndepărtează decizia de la un administrator care nu are niciun motiv să vă ajute.

Ce ar trebui să conțină depozitul?

Mult mai mult decât codul sursă în sine. Codul sursă fără instrucțiuni de compilare și o listă de dependențe poate necesita săptămâni de inginerie inversă înainte de a produce software funcțional, iar acest timp nu este disponibil atunci când sistemul dvs. nu este deja suportat.

Depozitele incomplete sunt cea mai frecventă problemă în practică. Tabelul de mai jos prezintă ce conține un depozit util.

Adăugați o obligație de actualizare a depozitului. Un depozit efectuat o singură dată la semnare expiră după una sau două lansări. Legați depozitele de programul de lansări, de exemplu, fiecare lansare majoră sau un interval fix și solicitați să fiți notificat când un depozit întârzie.

Ce nivel de verificare aveți nevoie?

Pentru majoritatea clienților, o analiză completă a documentației reprezintă standardul potrivit. Alegeți un test complet de construire și rulare doar acolo unde o întrerupere ar putea amenința afacerea dumneavoastră.

• Verificare fișier. Agentul confirmă că depozitul este lizibil, nu conține viruși și corespunde unei liste de fișiere. Dovedește că ceva a sosit, nu că funcționează. De unul singur, oferă puțină protecție.
• Completitudinea și revizuirea documentației. Agentul verifică instrucțiunile de compilare și dependențele în raport cu depozitul și raportează lacunele. Acesta identifică problemele comune, cum ar fi pașii de compilare lipsă, dependențele nedocumentate și componentele pe care nu aveți dreptul să le utilizați, la o fracțiune din costul unui test complet.
• Test complet de compilare și rulare. Agentul compilează depozitul într-un mediu curat și îl rulează cu date de testare. Acesta este singurul nivel care dovedește că depozitul funcționează, dar este mai lent, mai scump și trebuie repetat pe măsură ce software-ul se modifică.

Cum redactezi evenimente de lansare care nu pot fi contestate?

Asigurați-vă că fiecare eveniment poate fi verificat dintr-un document sau din trecerea timpului, nu dintr-o judecată despre conduita furnizorului. Agentul escrow trebuie să aplice clauza sub presiune și fără consiliere juridică.

Două alte aspecte fac cea mai mare parte a efortului. În primul rând, plasați sarcina obiecției asupra furnizorului: notificați agentul cu dovezi, furnizorul are o perioadă fixă ​​scurtă pentru a obiecta, iar dacă nu obiectează, agentul renunță la obligații. În al doilea rând, conveniți în prealabil asupra procedurii de contestare, cum ar fi consultanța obligatorie din partea unui expert sau arbitrajul într-un termen scurt. O obiecție costă atunci zile în loc de luni.

Ce se întâmplă cu escrow-ul dacă furnizorul dă faliment?

Administratorul judiciar poate refuza să îndeplinească obligațiile active ale furnizorului, cum ar fi întreținerea și actualizările, dar nu poate revoca o licență acordată înainte de faliment. Prin urmare, funcționarea efectivă a acordului dumneavoastră depinde de modul în care a fost structurat înainte de faliment.

Ce poate refuza administratorul judiciar?

În conformitate cu articolul 37 Fw, puteți acorda administratorului judiciar o perioadă rezonabilă pentru a declara dacă va executa un contract reciproc pe care niciuna dintre părți nu l-a executat integral la momentul falimentului. Dacă administratorul judiciar nu confirmă la timp, își pierde dreptul de a solicita executarea de la dumneavoastră, iar dumneavoastră rămâneți cu o creanță în cadrul falimentului.

Articolul 37 din Fw nu reziliază contractul. Administratorul fiduciar poate refuza întreținerea, asistența, actualizările, găzduirea și alte depozite: obligații active care costă bani succesiunea și ar trebui să vă așteptați ca aceasta să le refuze. Adevărata întrebare este dacă vă poate împiedica și să folosiți ceea ce aveți deja.

Cum a tratat Curtea Supremă problema drepturilor de utilizare în faliment?

Timp de aproximativ un deceniu, răspunsul a fost incert. În cauza Nebula (Curtea Supremă, 3 noiembrie 2006, ECLI:NL:HR:2006:AX8838), Curtea Supremă (Hoge Raad) a hotărât că falimentul nu pune capăt în sine acordurilor existente. A adăugat, însă, că o parte cu drept de utilizare nu poate continua să îl exercite împotriva administratorului judiciar ca și cum nu ar fi avut loc niciun faliment. Mulți interpretează acest lucru ca permițând unui administrator judiciar să anuleze un drept de utilizare existent, ceea ce îi îngrijora pe licențiați.

Această interpretare nu a durat. În cauza ABN AMRO/Berzona (Curtea Supremă, 11 iulie 2014, ECLI:NL:HR:2014:1681), Curtea Supremă a hotărât că falimentul nu are niciun efect asupra acordurilor reciproce existente sau asupra obligațiilor care decurg din acestea. Administratorul judiciar nu are alte puteri decât cele conferite de lege sau de contract; de exemplu, nu poate rezilia un contract de închiriere care este încă în curs de desfășurare.

Situația a fost soluționată în cauza Credit Suisse/Jongepier qq (Curtea Supremă, 23 martie 2018, ECLI:NL:HR:2018:424 ). Administratorul judiciar poate refuza să execute obligația. Falimentul nu îi conferă însă administratorului judiciar puterea de a anula o executare efectuată de debitor înainte de faliment sau de a pune capăt unei executări continue, în măsura în care aceasta constă în tolerarea sau abținerea de la ceva.

Acest ultim punct este decisiv pentru software. O licență este, în esență, angajamentul titularului de drepturi de a tolera utilizarea care altfel ar încălca drepturile de autor, ceea ce reprezintă o continuare a tolerării. Conform jurisprudenței actuale, o licență acordată în mod valabil înainte de faliment supraviețuiește acesteia, iar administratorul judiciar nu o poate revoca. Administratorul judiciar poate refuza tot ce este activ, dar nu poate anula un drept de utilizare pe care îl dețineți deja.

Ce înseamnă asta pentru aranjamentul tău?

Urmează două lucruri. În primul rând, obligația de eliberare trebuie plasată asupra agentului escrow, nu asupra furnizorului. Eliberarea de către agent reprezintă propria sa executare în temeiul propriului contract, iar poziția administratorului judiciar în temeiul articolului 37 Fw se referă la executările datorate de succesiune. O promisiune între două părți, în schimb, necesită executarea de către succesiune, pe care administratorul judiciar o poate refuza.

În al doilea rând, acordați licența în avans, nu la momentul eliberării. Acesta este cel mai important aspect de redactare și îl vom trata mai jos.

Într-o restructurare în temeiul Legii privind confirmarea instanței de către planurile de restructurare extrajudiciară (WHOA), mai degrabă decât într-un faliment, articolul 373 Fw restricționează utilizarea clauzelor care permit unei contrapărți să modifice, să suspende sau să reziliază un contract doar pentru că a început o procedură de restructurare. Modul în care această prevedere afectează un declanșator de eliberare într-un acord de escrow tripartit nu a fost stabilit în jurisprudență. Nu vă bazați pe începerea unei proceduri WHOA ca singurul eveniment de eliberare; combinați-o cu evenimente precum falimentul, întreruperea și neîndeplinirea obligațiilor persistente.

Cum ar trebui structurată licența?

Acordați licența în contract acum, sub rezerva unei condiții prealabile, astfel încât aceasta să intre în vigoare la momentul eliberării. O licență promisă doar la eliberare s-ar putea să nu existe niciodată dacă furnizorul intră în faliment.

Contractul de escrow vă oferă o copie a codului sursă, nu dreptul de a face ceva cu acesta. Codul sursă este protejat de drepturi de autor, iar compilarea, modificarea și rularea acestuia sunt acțiuni care necesită permisiunea titularului drepturilor. Fără o licență care să acopere aceste acțiuni, un depozit eliberat este un folder pe care nu îl puteți utiliza. Combinați contractul de escrow cu o licență care vă permite în mod expres, la lansare, să utilizați, să compilați, să modificați și să dezvoltați în continuare codul sursă și să angajați o terță parte să facă acest lucru pentru dvs. În practică, rareori veți face munca singur.

Momentul decisiv este punctul slab. Dacă evenimentul care generează eliberarea este falimentul în sine, o licență acordată la eliberare ar trebui să fie acordată de un debitor care, de la data hotărârii de faliment, nu mai poate dispune de activele din masa succesorală (articolele 23 și 35 Fw). Administratorul judiciar nu o va acorda în locul dumneavoastră. Credit Suisse/Jongepier protejează o licență pe care o aveți deja, dar nu poate proteja o licență pe care nu ați avut-o niciodată.

În temeiul unei licențe acordate sub rezerva unei condiții suspensive, dreptul există de la data contractului; doar efectul său este amânat. Legislația olandeză este în general receptivă la această structură. În cauza Rabobank/Reuser qq (Curtea Supremă, 3 iunie 2016, ECLI:NL:HR:2016:1046), Curtea Supremă a acceptat că, în cazul în care un drept condiționat fusese creat înainte de faliment, îndeplinirea condiției după faliment producea efecte fără niciun alt act din partea debitorului. Cauza respectivă se referea la un transfer condiționat de bunuri și la un drept de gaj asupra dreptului condiționat. Aplicarea acesteia unei licențe de drept de autor acordate condiționat este susținută în literatura juridică, dar instanțele nu s-au pronunțat încă asupra acesteia.

De asemenea, confirmați în contract că utilizarea materialului eliberat nu necesită niciun alt consimțământ din partea furnizorului sau a administratorului acestuia și că puteți acorda o sublicență unui dezvoltator succesor.

Ce necesită un aranjament SaaS sau cloud?

Mai mult decât codul sursă. Dacă platforma furnizorului se deconectează, pierzi aplicația, mediul în care a rulat și datele tale, iar codul sursă restaurează doar primul dintre acestea, lent. Prin urmare, un acord de continuitate pentru un serviciu trebuie să acopere încă trei aspecte.

• Mediul operațional. Imagini de containere, definiții ale infrastructurii ca și cod, configurare, setări de rețea și securitate și dependențe de execuție: suficiente pentru a reconstrui platforma în altă parte.
• Datele dumneavoastră. Exporturi regulate ale propriilor date într-un format documentat, neproprietar, cu schema de date. Aceste exporturi ar trebui să fie efectuate pe toată durata contractului, nu doar la lansare, deoarece datele pe care nu le puteți citi sunt de puțin folos.
• Relația de găzduire. O modalitate de a prelua contractul furnizorului cu furnizorul său de găzduire sau un acord în baza căruia puteți prelua contul și plăti direct furnizorul.

Există alternative la escrow și cine plătește?

Pentru produsele standard, unde sunteți unul dintre mulți clienți și riscul real este întreruperea producției, mai degrabă decât eșecul, opțiunile mai ușoare oferă adesea o valoare mai bună. Costul escrow-ului este în mod normal suportat de către client.

Trei alternative sunt adesea mai utile. Un drept de ieșire din date , cu exporturi periodice într-un format documentat testat cel puțin o dată, acoperă o mare parte din risc la un cost redus. Un drept la o copie rulantă , o imagine implementabilă pe care o puteți rula pentru o perioadă de tranziție, restabilește serviciul mult mai rapid decât reconstrucția din codul sursă. Plata directă către furnizorul de găzduire menține mediul în funcțiune în timp ce migrați; este cea mai ieftină formă de continuitate în cloud și cea mai adesea trecută cu vederea.

Dacă utilizați escrow, așteptați-vă la o taxă unică de configurare, o taxă anuală de custodie și taxe separate pentru fiecare verificare, în funcție de complexitatea acesteia. Costurile revin de obicei părții care dorește protecție, în mod normal clientul. Un furnizor care oferă escrow ca punct de vânzare le poate suporta. Un acord care acoperă mai mulți clienți ai aceluiași produs distribuie costurile și este adesea compromisul atunci când un furnizor se opune. Solicitați agentului să vă notifice dacă taxele nu sunt plătite, având dreptul de a le plăti dumneavoastră.

Ce ar trebui să verifici ca și client?

Examinați propunerea de escrow împreună cu contractul principal de software. Clauza de licență și evenimentele legate de lansare decid dacă escrow funcționează după un faliment.

• Este un acord tripartit autentic, cu un agent independent care vă datorează o obligație directă de eliberare?
• Este licența de utilizare, compilare, modificare și dezvoltare ulterioară a codului sursă acordată acum, supusă unei condiții prealabile?
• Depozitul include instrucțiuni de compilare, dependențe, chei de licență și documentație, actualizate cu fiecare lansare?
• Poate fi stabilit fiecare eveniment de eliberare dintr-un document, cum ar fi registrul de insolvență sau registrul comerțului KvK?
• Pentru SaaS: sunt acoperite mediul, datele dvs. și relația de găzduire sau doar codul?
• Trebuie agentul să vă anunțe dacă taxele sunt neplătite și le puteți plăti singur?

Ce ar trebui să verificați ca furnizor?

Contractul de escrow vizează drepturile de autor și secretele comerciale. Limitați eliberarea și licența la ceea ce clientul are nevoie pentru continuitate.

• Limitați licența la menținerea și continuarea utilizării proprii de către client, fără dreptul de a comercializa codul.
• Includeți o obligație de confidențialitate pentru client și orice dezvoltator succesor.
• Conveniți asupra unei perioade scurte de obiecții și a unei proceduri rapide de contestare, astfel încât o eliberare abuzivă să poată fi oprită.
• Stabiliți un program de depunere a cererilor pe care îl puteți respecta, legat de ciclul de lansare.
• Verificați cine plătește taxele de configurare, custodie și verificare.

Ce putem face pentru dumneavoastră cu escrow-ul software?

Oferim consultanță în domeniul contractelor software, licențelor și escrow-ului, în calitate de avocați IT pentru clienți și furnizori.

• Analizăm acordul de escrow și contractul principal de software ca un singur pachet.
• Redactăm licența condiționată și evenimentele de eliberare.
• Negociem conținutul depozitului și nivelul de verificare cu furnizorul și agentul escrow.
• Adăugăm clauze de ieșire din date și preluare a găzduirii în contractele SaaS.
• Trimitem notificarea în temeiul articolului 37 Fw și interacționăm cu administratorul judiciar după un faliment.
• Oferim consultanță cu privire la procedura de eliberare și la orice obiecție din partea furnizorului.

Rezumat

• Escrow asigură continuitatea în cazul în care furnizorul dvs. de software dă faliment, dar numai cu un depozit care include instrucțiuni de construire, dependențe și documentație.
• Alegeți un aranjament tripartit, astfel încât un agent escrow solvent să efectueze eliberarea.
• Conform jurisprudenței olandeze, o licență acordată înainte de faliment rămâne în vigoare; administratorul judiciar poate refuza doar executările active.
• Acordați licența acum, sub rezerva unei condiții prealabile, și nu doar la eliberare.
• Pentru SaaS, securizați și mediul operațional, datele și relația de găzduire.

Întrebări frecvente