Ohjelmiston escrow-tili Alankomaiden lain mukaan

Jos yrityksesi on riippuvainen ohjelmistosta, jota et ole itse kirjoittanut, olet riippuvainen yrityksestä, joka kirjoitti. Sinulla on objektikoodi ja lisenssi; toimittajalla on lähdekoodi, kehitysprosessi ja tietämys. Tämä epäsymmetria on siedettävää niin kauan kuin toimittaja on maksukykyinen ja pätevä, ja se lakkaa olemasta sitä heti, kun se ei ole. Ohjelmiston escrow-tili on vakioratkaisu, mutta se toimii vain, jos se on laadittu Alankomaiden maksukyvyttömyyslainsäädäntö mielessä pitäen – ja useimmat järjestelyt eivät ole.

Mikä on escrow ja mihin riskeihin se liittyy

Toimittaja tallettaa lähdekoodin ja tukimateriaalit riippumattomalle kolmannelle osapuolelle, joka säilyttää niitä, kunnes määritelty tapahtuma tapahtuu, ja luovuttaa ne sitten asiakkaalle, joka voi käyttää ja muokata koodia pitääkseen ohjelmiston käynnissä. Riski on jatkuvuus, ei omistajuus: asiakas, joka suorittaa tilausten käsittelyä, potilastietoja tai tuotantosuunnittelua yhden toimittajan tuotteella, ei voi vaihtaa toimittajaa yhdessä yössä, koska migraatio kestää kuukausia ja tarvitsee yleensä lähtevän toimittajan apua. Escrow ostaa aikaa poistua järjestelmästä hallitusti. Kolme tilannetta on merkityksellisiä:

• Maksukyvyttömyys. Toimittaja julistetaan konkurssiin, pesänhoitaja määrätään, henkilökunta lähtee ja tuki lakkaa. Escrow-skenaario on laadittu tätä varten, ja Alankomaiden laki toimii parhaiten.
• Lopettaminen. Toimittaja vetää tuotteen pois markkinoilta, vanhentaa versiosi tai joutuu jonkun sellaisen omistukseen, jolla ei ole kiinnostusta käyttöönottoosi. Yleisempi kuin konkurssi, ja usein jätetään pois vapautuslausekkeesta.
• Jatkuva kyvyttömyys ylläpitää. Toimittaja on edelleen olemassa ja laskuttaa edelleen, mutta ei enää korjaa vikoja, lähetä tietoturvapäivityksiä tai pidä tuotetta yhteensopivana riippuvuuksiensa kanssa.

Kaksi- ja kolmen osapuolen järjestelyt

Kahden osapuolen järjestely on pääsopimuksessa lupaus, että toimittaja luovuttaa lähdekoodin, jos määritelty tapahtuma tapahtuu. Se on halpa ja heikko: kukaan ei riippumattomasti tarkista, että mitään on talletettu tai että sitä pidetään ajan tasalla, ja – ratkaisevasti – konkurssitilanteessa pyydät pesänhoitajaa suorittamaan konkurssipesän velvoitteen, johon se ei ole velvollinen.

Kolmikantasopimuksessa sopimuspuoleksi lisätään escrow - agentti. Agentti ottaa talletuksen haltuunsa, tarkistaa sen, säilyttää sitä ja on sinulle suorassa velvoitteessa vapauttaa se. Juuri siksi hänestä kannattaa maksaa: vapauttamisesta tulee maksukykyisen kolmannen osapuolen, ei konkurssipesän, suorittama suoritus oman sopimuksensa nojalla. Agentti myös päättää, onko vapautustapahtuma tapahtunut, jolloin pesänhoitajan tehtäväksi jää ilman kannustimia auttaa sinua.

Mitä todellisuudessa talletetaan

Yleisin virhe ei ole laillinen. Se on talletus, joka sisältää lähdekoodia eikä mitään muuta. Pelkkä lähdekoodi ei käänny: jos suuri koodikanta annetaan kehittäjälle ilman käännösohjeita ja riippuvuusluetteloa, sen takaisinmallinnukseen voi kulua viikkoja ennen kuin se tuottaa toimivan binääritiedoston – aikaa, jota sinulla ei ole, kun järjestelmää ei jo tueta. Talletus ilman käännösohjeita on arvoton.

Lisää päivitysvelvoite. Kerran allekirjoituksen yhteydessä tehty talletus vanhenee julkaisusyklin tai kahden sisällä. Sido talletukset julkaisuaikatauluun – jokaiseen merkittävään julkaisuun tai kiinteään aikaan – ja pidä itselläsi oikeus saada tieto myöhästymisestä.

Vahvistus: mistä maksat

Osta vakiona alla oleva keskimmäinen vaihtoehto ja täysi testi, jossa katkos olisi eksistentiaalinen. Pelkkä tiedostotason tarkistus on lähellä sitä, että et osta mitään.

• Tiedostotason tarkistus. Agentti vahvistaa, että talletus on luettavissa, virukseton ja vastaa tiedostoluetteloa. Se todistaa, että jokin on saapunut, ei sitä, että se toimii.
• Täydellisyyden ja dokumentaation tarkastus. Agentti tarkistaa koontiohjeet ja riippuvuudet talletettua tiedostoa vasten ja raportoi aukot. Tämä keskimmäinen vaihtoehto sopii useimmille asiakkaille: se havaitsee yleisimmät virheet – puuttuvat koontivaiheet, dokumentoimattomat riippuvuudet ja komponentin, jota sinulla ei ole oikeutta käyttää – murto-osalla täyden testin hinnasta.
• Täysi koonti ja testiajo. Agentti kokoaa talletuksen puhtaassa ympäristössä ja ajaa sen testidataa vasten. Tämä on ainoa taso, joka todistaa talletuksen toimivuuden, mutta se on hitaampi, kalliimpi ja vaatii toistoa ohjelmiston muuttuessa.

Julkaisutapahtumat, jotka on suunniteltu niin, ettei niistä voida väitellä

Vapautuslauseke on laukaiseva tekijä, jota escrow-agentin on sovellettava paineen alla ja ilman oikeudellista neuvontaa. Jokainen tapahtuma tulisi voida todeta asiakirjasta tai ajan kulumisesta, ei toimittajan toimintaa koskevasta arviosta.

Kaksi asiaa hoitaa suurimman osan työstä. Riitautusten taakka on asetettava toimittajalle: asiakas ilmoittaa asiasta edustajalle todisteineen, toimittajalla on lyhyt määräaika vastustaa asiaa, ja jos vastustusta ei esitä, edustaja vapauttaa itsensä. Ja riidanratkaisumenettelystä sovitaan etukäteen – asiantuntijan päätös tai välimiesmenettely lyhyessä aikataulussa – joten vastalauseella ostetaan päiviä, ei kuukausia.

Alankomaiden maksukyvyttömyyskysymys

Kaikki yllä oleva on sopimussuunnittelua. Seuraavat seikat ratkaisevat, onko sopimus voimassa, jos toimittaja on konkurssissa.

Mitä edunvalvoja voi kieltäytyä

37 Fw artiklan mukaan, jos vastavuoroista sopimusta ei ole kumpikaan osapuoli täyttänyt kokonaisuudessaan konkurssimääräyksen antamishetkellä, vastapuoli voi asettaa konkurssipesän hoitajalle kohtuullisen kirjallisen määräajan ilmoittaa, aikooko se täyttää sopimuksen. Jos se ei aio täyttää sopimusta, se menettää oikeuden vaatia vastineeksi sen täyttämistä. 37 Fw artikla ei kuitenkaan irtisano sopimusta eikä anna konkurssipesän hoitajalle valtuuksia purkaa sitä. Sopimus on kuitenkin edelleen voimassa; konkurssipesän hoitaja ei ole velvollinen täyttämään sopimusta, ja vastapuolelle jää saatava konkurssimenettelyssä 37a Fw artiklan nojalla.

Ohjelmistojen osalta tämä tarkoittaa, että pesänhoitaja voi kieltäytyä ylläpidosta, tuesta, päivityksistä, hostingista ja lisätalletuksista: aktiivisista suorituksista, jotka maksavat kuolinpesälle rahaa. Varaudu kieltäytymiseen. Kysymys kuuluu, voidaanko se mennä pidemmälle ja estää sinua käyttämästä sitä, mitä sinulla jo on.

Nebula, Berzona ja Credit Suisse/Jongepier

Kymmenen vuotta tämä oli aidosti epävarmaa. Nebula- tapauksessa (Hoge Raad, 3. marraskuuta 2006, ECLI:NL:HR:2006:AX8838) korkein oikeus totesi, että vaikka konkurssi itsessään ei päätä olemassa olevia sopimuksia, käyttöoikeuden haltija ei voi jatkaa sen käyttämistä konkurssin haltijaa vastaan ​​ikään kuin konkurssia ei olisi tapahtunut; se antaisi yhden velkojan jättää konkurssin huomiotta muiden kustannuksella. Tätä tulkittiin yleisesti niin, että konkurssin haltija voisi kumota olemassa olevan käyttöoikeuden, ja se huolestutti lisenssinhaltijoita.

Tuo tulkinta ei säilynyt. ABN AMRO/Berzona -tapauksessa (Hoge Raad, 11. heinäkuuta 2014, ECLI:NL:HR:2014:1681) korkein oikeus totesi, että konkurssilla ei ole vaikutusta olemassa oleviin vastavuoroisiin sopimuksiin tai niistä johtuviin velvoitteisiin, eikä se anna pesänhoitajalle mitään sellaista valtaa, jota laki tai sopimus ei sille anna – se ei voi esimerkiksi irtisanoa voimassa olevaa vuokrasopimusta.

Asia ratkaistiin asiassa Credit Suisse/Jongepier qq (Hoge Raad, 23. maaliskuuta 2018, ECLI:NL:HR:2018:424). Pesänhoitaja voi passiivisesti kieltäytyä suorituksesta, mutta konkurssi ei anna hänelle valtuuksia perua velallisen ennen konkurssia antamaa suoritusta eikä lopettaa jatkuvaa suoritusta siltä osin kuin se tarkoittaa jonkin sietämistä tai jostakin pidättäytymistä.

Tuo lause on ohjelmistojen kannalta tärkeä. Lisenssi on pohjimmiltaan oikeudenhaltijan sitoumus sietää käyttöä, joka muutoin loukkaisi tekijänoikeutta – jatkuva suoritus, joka koostuu sietämisestä. Nykyisen lain mukaan siis ennen konkurssia pätevästi myönnetty lisenssi jää voimaan, eikä konkurssipesän hoitaja voi peruuttaa sitä. Konkurssipesän hoitaja voi kieltäytyä kaikesta aktiivisesta, mutta ei voi peruuttaa hallussa olevaa käyttöoikeutta.

Mitä se tarkoittaa järjestelyllesi

Kaksi asiaa seuraa. Vapautusvelvollisuus säilytetään escrow-agentilla, ei toimittajalla: jos kyseessä on itsenäinen kolmannen osapuolen hallussa oleva säilytys, vapautus on agentin oma suoritus, ja uskotun miehen valta artiklan 37 Fw nojalla kohdistuu kuolinpesän suorituksiin eikä maksukykyisen agentin suorituksiin, kun taas kahden osapuolen lupaus edellyttää kuolinpesän suorittamista, josta uskottu miehen on kieltäydyttävä. Ja lisenssi myönnetään etukäteen eikä vapautuksen yhteydessä – tärkein yksittäinen muotoilukohta, jota käsitellään jäljempänä.

Saneerauksessa, ei konkurssissa, artikla 373 Fw rajoittaa ipso facto -lausekkeiden käyttöä – määräyksiä, jotka antavat vastapuolelle mahdollisuuden muuttaa, keskeyttää tai irtisanoa sopimuksen pelkästään siksi, että saneerausmenettely on aloitettu. Tämä rajoitus toimii järjestelymenettelyssä, ei konkurssissa, ja vastaus siihen on jälleen rakenteellinen: jos järjestely on laadittu kolmannen osapuolen itsenäisenä säilytysjärjestelynä, vapautusmekanismi toimii asiamiehen oman velvoitteen perusteella eikä ole ipso facto -määräys, joka voitaisiin kumota WHOA-saneerauksessa sen enempää kuin konkurssissakaan.

Miten lisenssin tulee olla jäsennelty

Escrow antaa sinulle kopion lähdekoodista, ei oikeutta tehdä sillä mitään. Lähdekoodi on suojattu teos; sen kääntäminen, muokkaaminen ja tuloksen suorittaminen ovat rajoitettuja toimia. Ilman niitä kattavaa lisenssiä vapautettu talletus on kansio, jota et saa avata. Yhdistä escrow lisenssiin, joka nimenomaisesti sallii asiakkaan luovutuksen yhteydessä käyttää, kääntää, muokata ja kehittää edelleen lähdekoodia ja teettää tämän kolmannen osapuolen tehtäväksi – käytännössä et tee työtä itse.

Sitten ajoitus. Vapautumisen yhteydessä myönnetty lupa on hauras. Jos vapautustapahtuma on itse konkurssi, luvan myöntää velallinen, joka konkurssipäätöksen päivästä lähtien on menettänyt vallan määrätä konkurssipesään kuuluvista varoista; 23 § ja 35 § ovat esteenä, eikä pesänhoitaja myönnä lupaa puolestasi. Credit Suisse/Jongepier tarkoittaa, että pesänhoitaja ei voi peruuttaa jo ollutta lupaa – mutta ei ole mitään peruutettavaa, jos sinulla ei ole koskaan ollut sellaista.

Myönnä se itse sopimuksessa ennen mahdollista maksukyvyttömyyttä tietyllä ennakkoehdolla: myönnetään nyt ja se tulee voimaan vapautustapahtuman yhteydessä. Oikeus on olemassa sopimuspäivästä lähtien; vain sen vaikutus on lykätty. Alankomaiden laki on yleensä suvaitsevainen tälle rakenteelle. Rabobank/Reuser- tapauksessa (Hoge Raad, 3. kesäkuuta 2016, ECLI:NL:HR:2016:1046) korkein oikeus hyväksyi, että jos ehdollinen oikeus luotiin ennen konkurssia, ehdon täyttyminen myöhemmin tuli voimaan ilman velallisen lisätoimia. Kyseinen tapaus koski ehdollista omaisuuden luovutusta ja panttia ehdolliseen oikeuteen. Sen soveltaminen ehdollisesti myönnettyyn tekijänoikeuslisenssiin on oikeuskirjallisuudessa tuettu ekstrapolointi eikä tuomioistuinten ratkaisema näkökohta, ja se tulisi esittää sellaisena.

Vahvista myös, että julkaistun materiaalin käyttö ei vaadi toimittajan tai sen edunvalvojan erillistä suostumusta ja että alilisensointi seuraajakehittäjälle on sallittua.

SaaS ja pilvi: lähdekoodi ei riitä

Itse ajettavan ohjelmiston lähdekoodi, käännösohjeet ja lisenssi ovat lähes täydellinen vastaus. Palvelun tapauksessa näin ei ole. Jos toimittajan alusta katoaa, olet menettänyt sovelluksen, ympäristön, jossa se suoritettiin, ja tietosi – ja lähdekoodi palauttaa vain ensimmäisen, hitaasti. SaaS-jatkuvuusjärjestelyn on lisättävä kolme asiaa:

• Toimintaympäristö. Säiliökuvat, infrastruktuurikoodimääritelmät, konfigurointi, verkko- ja suojausasetukset, ajonaikaiset riippuvuudet – riittävästi alustan tukemiseksi muualla.
• Tiedot. Säännölliset omien tietojesi viennit dokumentoidussa, ei-omistussuojatussa muodossa skeeman mukana. Tieto, jota et voi lukea, ei ole omaa tietoa, ja vientien tulisi jatkua koko sopimuksen ajan, ei vain julkaisun yhteydessä.
• Isännöintisuhde. Reitti toimittajan sopimuksen tekemiseen sen hosting-palveluntarjoajan kanssa tai ilmoitus kyseiselle palveluntarjoajalle, että voit ottaa tilin haltuusi ja maksaa suoraan.

Vaihtoehtoja ja kuka maksaa

Escrow-tili ei ole aina paras vaihtoehto, varsinkaan vakiotuotteissa, joissa olet yksi asiakas tuhansien joukossa ja realistinen riski on pikemminkin auringonlasku kuin epäonnistuminen. Kolme kevyempää vaihtoehtoa ovat usein hyödyllisempiä: oikeus tietojen luovutukseen – säännölliset viennit dokumentoidussa muodossa, testattuina ainakin kerran – jotka kattavat suurimman osan riskistä lähes ilmaiseksi; oikeus käynnissä olevaan kopioon , käyttöönottokelpoiseen levykuvaan, jota voit käyttää siirtymäkauden ajan, mikä palauttaa palvelun paljon nopeammin kuin uudelleenrakentaminen; ja suora maksu hosting-palveluntarjoajalle , joka pitää ympäristön käynnissä migraation aikana – halvin pilvipalvelun jatkuvuus, joka usein unohdetaan.

Jos käytät escrow-palvelua, veloitetaan kertaluonteinen perustamismaksu, toistuva vuosittainen säilytysmaksu ja erillisiä maksuja varmennusta kohden, jotka skaalautuvat tarkastuksen syvyyden mukaan. Kustannukset jäävät suojauksen haluavan henkilön maksettavaksi, yleensä asiakkaan, vaikka toimittaja, joka tarjoaa escrow-palvelua myyntivalttina, voi tarjota sitä. Usean edunsaajan järjestely, joka kattaa useita yhden tuotteen asiakkaita, levittää kustannuksia – tavanomainen piste, jossa toimittaja vastustaa maksua. Tee maksamatta jättämisestä asiamies, jonka on ilmoitettava sinulle, ja hänellä on oikeus maksaa sen sijaan.

Tarkistuslista escrow-järjestelyn neuvottelemiseen

• Onko kyseessä aito kolmen osapuolen sopimus riippumattoman edustajan kanssa, joka on velvollinen luovuttamaan sinulle suoraan?
• Myönnetäänkö lähdekoodin käyttö-, kääntämis-, muokkaus- ja jatkokehityslupa? nyt, ennakkoedellytyksen alaisena, eikä luvattuna julkaisun yhteydessä?
• Sisältääkö tallennuslista käännösohjeet, riippuvuudet, lisenssiavaimet ja dokumentaation, ei pelkästään lähdekoodia, päivitettynä jokaisessa julkaisussa?
• Millä varmennustasolla sopimus tehdään ja kuinka usein se toistetaan?
• Ovatko julkaisutapahtumat määritettävissä asiakirjasta vai ajan kulumisesta, lyhyellä vastalauseiden esittämisajalla ja nopealla kiistanratkaisumenettelyllä?
• SaaS-palvelun osalta: katetaanko ympäristö, data ja hosting-suhde vai vain koodi?
• Kuka maksaa, mitä tapahtuu, jos toimittaja lakkaa maksamasta, ja onko escrow-sopimus pääsopimuksen sovellettavan lain ja immateriaalioikeuslausekkeiden mukainen?