Escrow de software conform legislației olandeze

Dacă afacerea ta depinde de software pe care nu l-ai scris tu, depinzi de compania care l-a scris. Tu deții codul obiect și o licență; furnizorul deține codul sursă, procesul de construire și cunoștințele. Această asimetrie este tolerabilă atâta timp cât furnizorul este solvabil și competent și încetează să mai fie așa în momentul în care nu mai este. Escrow-ul pentru software este răspunsul standard, dar funcționează numai dacă este redactat ținând cont de legislația olandeză privind insolvența - iar majoritatea acordurilor nu sunt.

Ce este escrow și riscul pe care îl abordează

Furnizorul depune codul sursă și materialele suport la o terță parte independentă, care le păstrează până când are loc un eveniment definit și apoi le eliberează clientului, care poate utiliza și modifica codul pentru a menține software-ul în funcțiune. Riscul este continuitatea, nu proprietatea: un client care își execută procesarea comenzilor, dosarele pacienților sau planificarea producției pe produsul unui furnizor nu poate trece peste noapte, deoarece migrarea durează luni de zile și, de obicei, are nevoie de ajutorul furnizorului care pleacă. Escrow cumpără timpul necesar pentru a ieși într-un mod ordonat. Trei situații contează:

• Insolvență. Furnizorul este declarat falimentar, este numit un administrator judiciar, personalul pleacă și asistența se oprește. Se scrie scenariul de escrow, pentru care legislația olandeză funcționează cel mai mult.
• Întreruperea. Furnizorul retrage produsul, își încheie versiunea sau este achiziționat de cineva care nu are niciun interes în implementarea produsului. Mai frecvent decât falimentul și adesea exclus din clauza de eliberare.
• Eșec persistent în întreținere. Furnizorul încă există și încă facturează, dar nu mai remediază defectele, nu mai livrează patch-uri de securitate și nu mai menține produsul compatibil cu dependențele sale.

Aranjamente bipartite și tripartite

Un acord bipartit este o promisiune în contractul principal că furnizorul va preda codul sursă dacă are loc un eveniment definit. Este ieftin și slab: nimeni nu verifică independent dacă ceva a fost depus sau menținut la zi și - în mod decisiv - în caz de faliment i se cere administratorului judiciar să îndeplinească o obligație a averii, lucru pe care acesta nu este obligat să îl facă.

Un acord tripartit adaugă un agent escrow ca parte contractantă. Agentul preia custodia, verifică depozitul, îl păstrează și vă datorează o obligație directă de a-l elibera. Acesta este întregul motiv pentru a plăti pentru un astfel de acord: eliberarea devine executare de către o terță parte solvabilă în baza propriului contract, nu de către o avere falită. Agentul decide, de asemenea, dacă a avut loc un eveniment de eliberare, luând acest lucru de la un administrator fiduciar care nu are niciun stimulent să vă ajute.

Ce este de fapt depus

Cea mai frecventă eroare este ilegală. Este vorba de o depunere care conține cod sursă și nimic altceva. Codul sursă singur nu se compilează: predat unui dezvoltator fără instrucțiuni de compilare și fără o listă de dependențe, o bază de cod mare poate necesita săptămâni de inginerie inversă înainte de a produce un fișier binar care rulează - timp pe care nu îl aveți atunci când sistemul nu este deja suportat. O depunere fără instrucțiuni de compilare este lipsită de valoare.

Adăugați o obligație de actualizare. Un depozit făcut o singură dată la semnare expiră în decurs de unul sau două cicluri de lansare. Legați depozitele de programul de lansare - fiecare lansare majoră sau un interval fix - și asumați-vă dreptul de a fi anunțat când unul întârzie.

Verificare: ceea ce plătiți

Cumpărați opțiunea din mijloc de mai jos ca standard și testul complet în care o întrerupere ar fi existențială. Numai verificarea la nivel de fișier este aproape imposibilă.

• Verificare la nivel de 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ă.
• Completitudinea și revizuirea documentației. Agentul verifică instrucțiunile de compilare și dependențele în raport cu depozitul și raportează lacunele. Această opțiune de mijloc este potrivită pentru majoritatea clienților: identifică erorile comune - pași de compilare lipsă, dependențe nedocumentate, o componentă pe care nu aveți dreptul să o 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ă pe baza datelor de testare. Singurul nivel care dovedește că depozitul funcționează, dar este mai lent, mai scump și necesită repetiție pe măsură ce software-ul se modifică.

Evenimente de lansare, redactate astfel încât să nu poată fi contestate

O clauză de eliberare este un declanșator pe care agentul escrow trebuie să îl aplice sub presiune și fără consiliere juridică. Fiecare eveniment ar trebui să poată fi stabilit dintr-un document sau din trecerea timpului, nu dintr-o judecată despre conduita furnizorului.

Două aspecte fac cea mai mare parte a problemei. Puneți sarcina contradicției pe seama furnizorului: clientul notifică agentul cu dovezi, furnizorul are o perioadă fixă ​​scurtă pentru a obiecta, iar în absența unei obiecții, agentul renunță la soluționare. Și stabiliți în avans calea de soluționare a litigiului - hotărâre de expert sau arbitraj într-un termen scurt - astfel încât o obiecție să cumpere zile, nu luni.

Chestiunea insolvenței olandeze

Tot ce este menționat mai sus reprezintă structura contractului. Ceea ce urmează decide dacă acesta este valabil în cazul în care furnizorul este falimentar.

Ce poate refuza administratorul judiciar

Conform art. 37 Fw, în cazul în care un contract reciproc nu a fost executat integral de niciuna dintre părți la momentul hotărârii de faliment, contrapartea poate stabili administratorului judiciar un termen scris rezonabil pentru a declara dacă îl va executa; dacă nu o face, pierde dreptul de a solicita executarea în schimb. Ceea ce nu face art. 37 Fw este să rezilieze contractul sau să acorde administratorului judiciar împuternicirea de a-l rezilia. Contractul rămâne în vigoare; administratorul judiciar pur și simplu nu este obligat să-l execute, iar contrapartea rămâne cu o creanță în cadrul falimentului în temeiul art. 37a Fw.

În cazul software-ului, aceasta înseamnă că administratorul judiciar poate refuza mentenanța, asistența, actualizările, găzduirea și alte depozite: performanțe active care costă bani succesiunea. Așteptați-vă la un refuz. Întrebarea este dacă acest lucru poate merge mai departe și vă poate împiedica să utilizați ceea ce aveți deja.

Nebula, Berzona și Credit Suisse/Jongepier

Timp de un deceniu, acest lucru a fost cu adevărat incert. În cauza Nebula (Hoge Raad, 3 noiembrie 2006, ECLI:NL:HR:2006:AX8838), Curtea Supremă a hotărât că, deși falimentul nu pune capăt în sine acordurilor existente, o contraparte care deține un drept de utilizare nu poate continua să îl exercite împotriva administratorului judiciar ca și cum nu ar fi avut loc niciun faliment; acest lucru ar permite unui creditor să ignore falimentul în detrimentul celorlalți. Aceasta a fost interpretată pe scară largă ca permițând unui administrator judiciar anularea unui drept de utilizare preexistent și i-a alarmat pe licențiați.

Această interpretare nu s-a păstrat. În cauza ABN AMRO/Berzona (Hoge Raad, 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 și nu conferă administratorului nicio putere pe care legea sau contractul nu i-o conferă - de exemplu, acesta nu poate rezilia un contract de închiriere care este încă în vigoare.

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

Această sintagmă este cea care contează pentru software. O licență este, în esență, un angajament al titularului drepturilor de autor de a tolera o utilizare care altfel ar încălca drepturile de autor - o executare continuă constând în tolerare. Prin urmare, conform legislației 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.

Ce înseamnă asta pentru aranjamentul tău

Urmează două lucruri. Obligația de eliberare trebuie păstrată în sarcina agentului escrow, nu a furnizorului: fiind constituită ca o custodie independentă deținută de o terță parte, eliberarea este executarea proprie a agentului, iar puterea administratorului judiciar în temeiul art. 37 Fw se bazează pe executarea datorată de succesiune, mai degrabă decât pe un agent solvabil, în timp ce o promisiune între două părți necesită executarea de către succesiune, pe care administratorul judiciar o poate refuza. Și acordarea licenței în avans, mai degrabă decât la eliberare - cel mai important punct de redactare, tratat mai jos.

Într-o restructurare, mai degrabă decât într-un faliment, art. 373 Fw restricționează recurgerea la clauzele ipso facto - prevederi care permit unei contrapărți să modifice, să suspende sau să rezileze un contract doar pentru că a început o procedură de restructurare. Această restricție operează în procedura schemei, nu în faliment, iar răspunsul la ea este din nou structural: în cazul în care acordul este redactat ca o custodie independentă de către o terță parte, declanșatorul eliberării operează asupra obligației proprii a agentului și nu echivalează cu o prevedere ipso facto care poate fi anulată, nici într-o restructurare WHOA, nici într-un faliment.

Cum trebuie structurată licența

Contractul de escrow vă oferă o copie a codului sursă, nu dreptul de a face ceva cu acesta. Codul sursă este o lucrare protejată; compilarea, modificarea și rularea rezultatului sunt acțiuni restricționate. Fără o licență care să le acopere, un depozit eliberat este un dosar pe care nu îl puteți deschide. Combinați contractul de escrow cu o licență care permite în mod expres clientului, la lansare, să utilizeze, să compileze, să modifice și să dezvolte în continuare codul sursă și să solicite o terță parte să facă acest lucru - în practică, nu veți face munca singur.

Apoi, momentul. O licență acordată la eliberare este fragilă. Dacă evenimentul de eliberare este falimentul în sine, acordarea ar trebui să fie făcută de un debitor care, de la ziua hotărârii de faliment, și-a pierdut puterea de a dispune de activele din masa succesiunii; art. 23 Fw și art. 35 Fw stau în cale, iar administratorul judiciar nu va acorda acordarea în locul dumneavoastră. Credit Suisse/Jongepier înseamnă că administratorul judiciar nu poate revoca o licență pe care ați avut-o deja - dar nu există nimic de revocat dacă nu ați avut niciodată una.

Acordați-o în contractul propriu-zis, înainte de orice insolvență, sub rezerva unei condiții prealabile: acordată acum, producând efecte la un eveniment de eliberare. 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 (Hoge Raad, 3 iunie 2016, ECLI:NL:HR:2016:1046), Curtea Supremă a acceptat că, în cazul în care un drept condiționat a fost creat înainte de faliment, îndeplinirea condiției a produs efecte ulterior, fără niciun alt act din partea debitorului. Cauza respectivă se referea la un transfer condiționat de bunuri și la o gajare asupra dreptului condiționat. Aplicarea acesteia unei licențe de drept de autor acordate condiționat este o extrapolare susținută de literatura juridică, mai degrabă decât un punct de vedere soluționat de instanțe și ar trebui prezentată ca atare.

Confirmați, de asemenea, că utilizarea materialului publicat nu necesită acordul suplimentar din partea furnizorului sau a administratorului său și că este permisă sublicențierea către un dezvoltator succesor.

SaaS și cloud: codul sursă nu este suficient

Pentru software-ul pe care îl rulezi singur, codul sursă plus instrucțiunile de compilare plus o licență reprezintă aproape o soluție completă. Pentru un serviciu, nu este așa. Dacă platforma furnizorului se închide, ai pierdut aplicația, mediul în care a rulat și datele tale — iar codul sursă restaurează doar primele, lent. Un acord de continuitate SaaS trebuie să adauge trei lucruri:

• Mediul operațional. Imagini de containere, definiții ale infrastructurii ca și cod, configurare, setări de rețea și securitate, dependențe de runtime — suficiente pentru a susține platforma în alte părți.
• Datele. Exporturi regulate ale propriilor date într-un format documentat, neproprietar, cu schema. Datele pe care nu le puteți citi nu sunt date pe care le dețineți, iar exporturile ar trebui să ruleze pe toată durata contractului, nu doar la lansare.
• Relația de găzduire. O modalitate de a intra în contractul furnizorului cu furnizorul său de găzduire sau de a notifica furnizorul respectiv că puteți prelua contul și plăti direct.

Alternative și cine plătește

Escrow nu oferă întotdeauna cea mai bună valoare, în special pentru produsele standard, unde sunteți un client printre mii, iar riscul realist este o perioadă de apus a datelor, mai degrabă decât un eșec. Trei opțiuni mai ușoare sunt adesea mai utile: un drept de ieșire din date - exporturi periodice într-un format documentat, testate cel puțin o dată - care acoperă o mare parte din expunere, aproape gratuit; un drept la o copie funcțională , o imagine implementabilă pe care o puteți rula pentru o perioadă de tranziție, restabilind serviciul mult mai rapid decât o reconstrucție; și plata directă către furnizorul de găzduire , menținând mediul în funcțiune în timp ce migrați - cea mai ieftină modalitate de continuitate în cloud și cel mai adesea trecută cu vederea.

În cazul în care utilizați escrow, așteptați-vă la o taxă unică de configurare, o taxă anuală recurentă de custodie și taxe separate pentru fiecare verificare, care cresc în funcție de valoarea cecului. Costul revine celui care dorește protecția, în mod normal clientul, deși un furnizor care oferă escrow ca punct de vânzare îl poate oferi, iar un acord cu mai mulți beneficiari care acoperă mai mulți clienți ai unui singur produs îl distribuie - punctul de sosire obișnuit în care un furnizor se opune. Faceți din neplată ceva ce agentul trebuie să vă notifice, având dreptul de a plăti în locul acesteia.

O listă de verificare pentru negocierea unui acord de escrow

• Este un acord tripartit autentic cu un agent independent care vă datorează o obligație directă de eliberare de răspundere?
• Este licența de utilizare, compilare, modificare și dezvoltare ulterioară a codului sursă acordată acum, sub rezerva unei condiții prealabile, mai degrabă decât promisă la eliberare?
• Lista de depozit include instrucțiuni de compilare, dependențe, chei de licență și documentație, nu doar cod sursă, actualizat la fiecare lansare?
• Ce nivel de verificare este contractat și cât de des se repetă?
• Sunt evenimentele de eliberare determinabile dintr-un document sau din timpul scurs, cu o perioadă scurtă de obiecții și o cale rapidă de contestare?
• Pentru SaaS: sunt acoperite mediul, datele și relația de găzduire sau doar codul?
• Cine plătește, ce se întâmplă dacă furnizorul nu mai plătește și se respectă acordul de escrow legea aplicabilă și clauzele de proprietate intelectuală ale contractului principal?