Mis teile kuulub, kui süsteem on valmis: kood, andmed ja sõltuvus arendajast

Süsteem on üle antud, arve on makstud ja poole aasta pärast otsustab ettevõte arendajat vahetada, ja just siis esitatakse küsimus, mis senini kellelegi kiire ei tundunud: kellele kuulub see, mille eest maksti. Vastus Eestis üllatab peaaegu kõiki, kes seda esimest korda kuulevad, sest tasu maksmine arenduse eest iseenesest ei anna tellijale autoriõigust loodud arvutiprogrammile, ja see ei ole õiguslik peensus, vaid vaikimisi kord, mis kehtib iga kord, kui lepingus ei ole midagi muud kirjas.

See artikkel räägib sellest, mis jääb pärast üleandmist teie kätte, ja see ei ole sama küsimus, mida oleme käsitlenud, võrreldes valmistoodangut eritarkvaraga. Seal oli jutt valikust; siin on jutt sellest, mida te käes hoiate, kui valik on juba tehtud ja süsteem töötab. Vastus jaguneb kolmeks: kood ja õigused sellele, andmed koos kohaga, kus need asuvad, ja sõltuvus inimestest, kes süsteemi tunnevad.

Autor on alati inimene, mitte ettevõte

Autoriõiguse seaduse järgi on teose autor füüsiline isik, kes on teose loonud, ja see tähendab, et ettevõte ei ole kunagi autor: autorid on programmeerijad, disainerid ja tekstide autorid, kes süsteemi kallal töötasid. Arvutiprogramme kaitstakse nagu kirjandusteoseid, samamoodi nagu Euroopa Liidu direktiivis 2009/24/EÜ, ja autoriõigus tekib teose loomisega, ilma registreerimiseta, ilma märgita ja sõltumata sellest, kas teos on lõpetatud.

Autoriõigus jaguneb kaheks osaks, mida Eesti seadus nimetab isiklikeks mittevaralisteks õigusteks ja varalisteks õigusteks, ja praktikas on see kogu teema tähtsaim jaotus, sest ainult üks neist saab üldse ettevõttele minna. Varaline osa on see, mida saab teisele loovutada, ja arvutiprogrammi puhul lubab see programmi levitada, kättesaadavaks teha, rentida, reprodutseerida, samuti tõlkida, kohandada või muul viisil ümber töötada ja ümbertöötluse tulemusi reprodutseerida. Isiklik osa jääb autorile kogu eluks ja ei ole kellelegi üleantav, ja just seetõttu ei saa ükski leping kirja panna, et ettevõttest saab autor.

On veel üks piir, mida märgatakse harva, ja see võib osutuda kalliks. Paragrahvi 32 lõige 5, mis annab tööandjale ainulitsentsi kõigi varaliste õiguste teostamiseks, räägib ainult arvutiprogrammist ja andmebaasist; kõige muu kohta, mida projekt loob — disain, dokumentatsioon, tekstid ja juhised — kehtib sama paragrahvi esimene lõige, kus vaikimisi kord on teine: autoril tekib autoriõigus, kuid varalised õigused teose kasutamiseks tööülesannetega ettenähtud eesmärgil ja piirides lähevad üle tööandjale. Praktikas tähendab see, et ühe projekti kahel loodud asjal võivad olla kaks erinevat korda, ja leping, mis räägib ainult tarkvarast, võib jätta disaini kõrvale.

Sellest järelduvad esimesed praktilised tagajärjed, mis tasub mõista enne kõike muud: kui ettevõte tellib süsteemi agentuurilt, on õiguste ahel vähemalt kahe lüli pikk, sest kõigepealt on programmeerijad autorid, siis on agentuur neilt ainulitsentsi saanud või ei ole, ja alles siis saab agentuur teile midagi loovutada. Kui mõni lüli puudub, lubab agentuur rohkem, kui talle kuulub, ja seda märgatakse alles siis, kui keegi hakkab kontrollima.

Töötaja ja tellimus on kaks erinevat vaikimisi korda

Siin on artikli tuum, ja siin viib intuitsioon vales suunas. Autoriõiguse seaduse § 32 lõige 5 sätestab, et arvutiprogrammi autoril, kes loob programmi oma tööülesannete täitmise käigus või järgides tööandjalt saadud juhiseid, tekib autoriõigus sellele programmile, kuid tööandjale kuulub ainulitsents kõigi varaliste õiguste teostamiseks, kui lepingus ei ole ette nähtud teisiti. See on Eesti vastus direktiivi 2009/24/EÜ artikli 2 lõikele 3, ja see kehtib ainult töösuhtes ja ainult arvutiprogrammide ning andmebaaside kohta.

Tellimuse puhul on vaikimisi kord vastupidine, ja just seetõttu ei tohi neid kahte juhtu segamini ajada: Autoriõiguse seaduse § 48 nimetab autorilepingut ehk tellimislepingut kokkuleppeks, millega autor annab teisele poolele üle varalised õigused või loa teost kasutada lepingus ettenähtud ulatuses, aga tasu maksmine ja teose üleandmine iseenesest seda üleandmist ei tee. Töövõtuleping võlaõigusseaduse § 635 järgi ei ütle autoriõiguse kohta midagi, sest see reguleerib töö valmistamist ja üleandmist, mitte õiguste üleminekut.

Pange mõlemad kokku, ja tuleb olukord, kuhu tüüpiline ettevõte satub, ise sellest teadmata: klient tellib süsteemi agentuurilt; programmeerijad on agentuuri töötajad, seega annab § 32 lõige 5 agentuurile ainulitsentsi varaliste õiguste teostamiseks; kliendi ja agentuuri leping on töövõtuleping, mis seda edasi ei loovuta. Tulemuseks on, et klient on tulemuse eest tasunud ja tulemuse kätte saanud, kuid varaline osa on jäänud autoritele ja ainulitsents agentuurile, ja ainus, mis kliendil on, on ebaselge kaudne autoriõiguse litsents kasutada süsteemi selleks otstarbeks, milleks see telliti.

See eksiarvamus — et õigused arvutiprogrammile kuuluvad isikule, kes on selle arenduse tellinud ja tasunud — on levinud, ja Autoriõiguse seadus automaatset varaliste õiguste kuulumist tellijale ette ei näe. Kaudse litsentsi sisu jääb ebaselgeks, ja seda tasub lugeda koos seaduse tekstiga: ilma kirjaliku loovutamise või litsentsita ei lähe varalised õigused tellijale üle.

Failide kättesaamine ei ole õiguste kättesaamine

Teine eeldus, mis paika ei pea, on see, et koodi kättesaamine midagi otsustab, kuid Autoriõiguse seaduse § 57 lõige 2 sätestab, et kui autor võõrandab teose originaali või koopia, ei tähenda see varaliste õiguste üleandmist ega luba teost kasutada, kui lepinguga ei ole kindlaks määratud teisiti. Praktikas tähendab see, et arhiiv kogu lähtekoodiga, ligipääs repositooriumile ja isegi täielik dokumentatsioon ei ole ikka veel sama mis õigus seda koodi kasutada, ümber töötada ja teisele arendajale üle anda.

See toimib ka vastupidi, ja see pool on vähem tuntud, sest ettevõte võib olla saanud varalised õigused hästi kirjutatud lepinguga, aga lähtekoodi siiski mitte kätte, kui lepingus ei olnud eraldi kirjas kohustust see üle anda. Luba ilma failita on sama kasutamatu kui fail ilma loata, seega on lepingus vaja mõlemat, ja need on kaks iseseisvat punkti, mitte üks punkt, mis teist iseenesest sisaldab.

Kui õigused loovutatakse õigesti, nõuab seadus teatavat täpsust, ja see ei ole formaalsus, sest Autoriõiguse seadus lubab varalise osa loovutada või litsentsida ning § 48¹ nõuab, et autorilepingus fikseeritaks muu hulgas üleantavad õigused, kasutusviis ja territoorium ning tähtaeg. Vaikimisi eeldust, et nimetamata territoorium tähendab ainult lepingu sõlmimise riiki, Eestis ei ole. Ettevõttele, kes tegutseb mitmes riigis või kavatseb seal tegutseda, on see otsene põhjus territoorium kirja panna, ja kasutusviis tuleb nimetada, sest ühe viisi sõnastus ei ava teisi.

On veel üks üllatus, mis ootab ettevõtet, kes elab kaudse litsentsiga ja ei ole seda kunagi kirjalikult vormistanud. Autoriõiguse seaduses ei ole kuuekuulist etteteatamisega lõpetamist tähtajatu litsentsi puhul ega reeglit, et sellest loobumine oleks tühine. Lähim reegel — ainulitsentsi või loovutamise ülesütlemine, kui teost kahe aasta jooksul ei kasutata (§ 49³) — ei kehti arvutiprogrammide autorite suhtes (§ 49⁴ lg 3). Ettevõte, kelle ainus alus süsteemi kasutamiseks on kirjutamata kokkulepe, elab seega ebaselge kaudse loaga, mitte kuuekuulise etteteatamise reegli all, ja see ebaselgus ise on põhjus litsents kirja panna.

Isiklikud mittevaralised õigused ja ümbertöötamine

Isiklikku ossa kuuluvad autorsus, nimi, teose puutumatus ja võimalus teos kasutamisest tagasi võtta, ja kõik see jääb autorile, sest ühtegi neist ei saa autori eluajal teisele isikule üle anda. Ettevõttele, kes on süsteemi tellinud, kõlab see alguses ähvardavalt, sest tekib mulje, et endine arendaja võib ühel hetkel nõuda süsteemi peatamist.

Praktikas ei ole see odav hoob, sest Autoriõiguse seadus ei võta arvutiprogrammi autorilt isiklike mittevaraliste õiguste alusel õigust ümbertöötamist keelata ega teost tagasi võtta: need jäävad § 12 järgi autorile. Tagasivõtmine toimub autori kulul ja autor on kohustatud hüvitama kahju, mis tekib isikul, kes teost kasutas. See tähendab, et endine programmeerija ei saa tavalist hooldust odavalt peatada tagasivõtmisega, kuid teose puutumatus — õigus vaidlustada ilma autori nõusolekuta tehtud muudatusi — jääb, ja au ja väärikuse kaitse on sellest eraldi.

Samal ajal on ettevõttele soodne teine norm, mida tasub teada, sest muidu võib seda oodata valelt poolelt. Teavitamiskohustus teose kasutamise kohta ja sellega seotud ülesütlemisõigus, mis teiste teoseliikide puhul lubavad autoril tasu küsimuse juurde tagasi tulla, ei kehti arvutiprogrammide autorite suhtes (§ 49⁴ lg 3, jõus 7. jaanuarist 2022), ja see tähendab, et programmeerija, kes leiab, et süsteem osutus väärtuslikumaks, kui mõlemad pooled ootasid, ei saa sellel alusel lisatasu nõuda.

Alles jäävad õigus olla nimetatud autoriks, teose puutumatus, õigus teos tagasi võtta autori kulul, ja kaitse sellise kasutamise eest, mis kahjustab au ja väärikust. Tähtis on ainult kahte asja mitte segi ajada: ümbertöötamine isikliku mittevaralise õigusena ei ole programmidelt ära võetud, kuid ümbertöötamine varalise osana nõuab endiselt selle omaja luba, seega kui ainulitsents on jäänud agentuurile, on süsteemi ümbertegemiseks endiselt vaja tema nõusolekut.

Mida seadus annab ka ilma hea lepinguta

Isegi ettevõttele, kes ei ole midagi vormistanud, annab seadus mõned võimalused, ja tasub teada, milliseid neist saab lepinguga ära võtta ja milliseid mitte. Autoriõiguse seaduse § 24 lõige 1 lubab arvutiprogrammi õiguspärasel kasutajal programmi reprodutseerida, tõlkida, kohandada või muul viisil ümber töötada ja saadud tulemusi reprodutseerida niivõrd, kui see on vajalik kasutamiseks ettenähtud otstarbel, sealhulgas vigade parandamiseks, kuid see õigus kehtib ainult siis, kui lepinguga ei ole ette nähtud teisiti, seega saab leping selle ära võtta, ja paljud lepingud seda ka teevad.

Varukoopia tegemine on teine juhtum, mida leping ära võtta ei saa, sest § 24 lõige 2 annab õiguspärasele kasutajale õiguse teha programmist varukoopia, kui see on vajalik programmi kasutamiseks või taastamiseks, ja lõige 5 ütleb, et seda ning ideede jälgimist lõike 3 järgi piirav lepingutingimus on tühine. See vastab direktiivi 2009/24/EÜ artikli 5 lõikele 2. Direktiivi artikkel 8 ütleb lisaks, et lepingutingimused, mis on vastuolus artikliga 6 või artikli 5 lõigetes 2 ja 3 ettenähtud eranditega, ei kehti.

Siin tasub olla täpne, sest vahe on peen ja kergesti üle paisutatav: Eesti seadus ütleb varukoopia kohta otse, et piirav tingimus on tühine (§ 24 lg 5), ja ütleb sama pöördprojekteerimise ehk dekompileerimise kohta (§ 25 lg 3). Seega on õige kirjutada, et Autoriõiguse seadus võtab direktiivi artikli 8 siin üle: varukoopiat ei saa lepinguga ära võtta ja dekompileerimist piirav tingimus on samuti tühine.

Dekompileerimine on omakorda lubatud kitsalt ja tingimustega: seda tohib teha, et tagada sõltumatult loodud programmi ühilduvus, kui teave ei ole muul viisil kättesaadav, seda teeb isik, kes on õiguspäraselt omandanud õiguse koopiat kasutada, ja tegevus piirdub osadega, mis on ühilduvuseks vajalikud. Saadud teavet ei tohi kasutada muuks otstarbeks ega olemuselt sarnase toote loomiseks, ja see väljapääs on kasulik, kuid kitsas, ja ükski ettevõte ei taha, et see oleks ainus.

Süsteemis on palju koodi, mis ei saa kunagi teie omaks

Tellimussüsteem ei ole peaaegu kunagi ainult see kood, mille arendaja kirjutas, sest suurem osa mahust tuleb teekidest ja raamistikust, mis olid juba olemas. See kood ei saa teie omandiks kunagi ega üheski lepingus, sest te saate litsentsi selle autoritelt, ja see vahe on tähtis just siis, kui keegi lubab loovutada kõik õigused süsteemile.

Lubavad litsentsid probleemi ei tekita, sest need nõuavad vähe ega piira seda, kuidas valmis süsteemi tohib äritegevuses kasutada. MIT-litsents lubab kasutada, kopeerida, muuta, ühendada, avaldada, levitada ja müüa, kui säilitatakse autoriõiguse teade ja litsents ise, ja tarkvara antakse üle sellisena, nagu see on, ilma garantiideta, Apache 2.0 litsents lisab sellele otsese patendilitsentsi ja nõuab tehtud muudatuste märkimist. Mõlemad sobivad suletud ärisüsteemiga, suurem osa tänapäeva raamistikest on üks neist, ja just seetõttu ei nõua see süsteemi osa tavaliselt mingit jutuajamist.

Copyleft-litsentsid nõuavad tähelepanu, aga mitte paanikat, ja just siin räägitakse kõige sagedamini pooltõdesid, kuigi Vaba Tarkvara Fond kirjutab oma GPL-i küsimuste lehel selgelt, et ettevõte, kes käitab muudetud GPL-programmi oma veebilehel, ei ole kohustatud muudetud lähtekoodi avaldama, sest copyleft-kohustus tekib koopiate üleandmisel teistele, mitte programmi kasutamisel enda juures. Mitme koopia tegemine ja kasutamine ühe organisatsiooni sees ei ole levitamine, kuigi koopiate üleandmine teistele organisatsioonidele, sealhulgas töövõtjatele kasutamiseks väljaspool ettevõtet, juba on.

Erand on Affero litsents, ja just selle § 13 on see, mis inimesi üllatab, sest kui te programmi muudate ja muudetud versioon lubab kasutajatel sellega suhelda kaugelt arvutivõrgu kaudu, siis tuleb neile kasutajatele pakkuda võimalust saada vastav lähtekood. Tingimusi on kaks ja mõlemad on vajalikud: muutmine ja kasutajate kaugsuhtlus, seega ei ole õige öelda, et igasugune Affero litsentsi kasutamine nõuab lähtekoodi avaldamist, ega öelda, et üks selline teek allutab automaatselt kogu süsteemi, sest see sõltub sellest, kuidas komponendid on ühendatud.

Deponeerimine kolmanda isiku juurde ja mida see tegelikult annab

Lähtekoodi deponeerimine on kolmepoolne lahendus, milles arendaja annab lähtekoodi üle neutraalsele hoidjale, kuid hoidja väljastab selle tellijale ainult siis, kui saabub lepingus kirjeldatud juhtum, ja tüüpilised juhtumid on maksejõuetus, tegevuse lõpetamine või oluline hoolduskohustuste täitmata jätmine pärast hoiatust. Eestis ei ole seadust, mis need juhud kindlaks määraks või kas või üles loetleks, seega kehtib siin ainult see, mille pooled ise on kirja pannud, ja seetõttu tuleb deponeerimislepingut lugeda sama tähelepanelikult kui arenduslepingut ennast.

Deponeerimine annab täpselt selle, mis on deponeeritud, ja ainult siis, kui saabub see, mis on kirjeldatud, kuid iseenesest see autoriõigust ei loovuta — selleks tuleb jälle meeles pidada, et failide üleandmine ei ole õiguste loovutamine — ega õpeta süsteemi käitama. Ettevõte NCC Group, kes seda teenust on müünud juba aastakümneid, tunnistab oma materjalides ise: lähtekoodi olemasolu hoidlas on üks asi, oskus see kokku kompileerida on teine, ja just seetõttu müüb sama ettevõte ka deponeeritud sisu kontrolli. See on huvitatud poole hinnang, kuid see on tunnistus oma põhiteenuse nõrgast kohast, ja seetõttu on see kasutatav.

Tänapäeva süsteemidel on ka teine puudus, millel ei ole juriidilise poolega üldse pistmist: kui süsteem töötab teenusena arendaja taristus, siis lähtekood ilma käituskeskkonna, konfiguratsiooni ja andmeteta lahendab väikseima osa probleemist, sest saajale jääb arhiiv, mitte töötav süsteem. Praktikas lahendatakse see puudus, täiendades deponeerimist kokkuleppega selle kohta, kes keskkonna üle võtab ja mis juhtub, kui veebimajutuse arved jäävad maksmata, ja just need punktid deponeerimise tüüpvormidel tavaliselt ei ilmu.

On ka õiguslik takistus, mis ilmneb just maksejõuetuse korral: deponeeritud vara ja selle väljastamine võivad sattuda vastuollu pankrotivara režiimiga, seega just selles olukorras, mille pärast deponeerimist kõige sagedamini ostetakse. Autoriõiguse seadus seda kokkupõrget ei reguleeri. Praktiline järeldus ei ole deponeerimisest loobuda, vaid mitte pidada seda kirjaliku õiguste loovutamise ja lähtekoodi regulaarse väljastamise asendajaks.

Kus asub repositoorium ja kus asuvad andmed

Küsimus sellest, kus asuvad kood ja andmed, otsustab rohkem kui küsimus sellest, kellele need kuuluvad, sest õigused ilma ligipääsuta on aeglane probleem. GitHubi dokumentatsioon kirjeldab selgelt, et organisatsioon on ühine konto, millele kuuluvad repositooriumid, et organisatsioonina sisse logida ei saa, sest inimesed logivad sisse isiklike kontodega, ja et organisatsiooni omanikel on alati ligipääs kõikidele repositooriumidele; repositoorium võib kuuluda nii isiklikule kontole kui organisatsioonile, ja see valik on tähtsam, kui paistab.

Kui repositoorium kuulub arendaja isiklikule kontole, on kliendi ligipääs ainult kaastöötaja ligipääs, mille konto omanik võib iga hetk ära võtta, ja projektist lahkudes võtab ta kaasa ka aadressi. Kui repositoorium kuulub kliendi organisatsioonile, kuhu arendaja on kutsutud liikmeks, tähendab lahkumine ühe ligipääsu eemaldamist ja ei midagi enamat, ja see on üks väheseid asju selles artiklis, mida saab parandada ühe päevaga ja ilma juristita.

Andmed on eraldi küsimus, ja seal ei ole jutt enam autoriõigusest: kui arendaja töötleb isikuandmeid teie nimel, see tähendab käitab tootmiskeskkonda, pääseb ligi klientide või töötajate andmetele või teeb varukoopiaid, olete teie vastutav töötleja ja arendaja on volitatud töötleja isikuandmete kaitse üldmääruse tähenduses. Määruse artikkel 28 nõuab kirjalikku lepingut konkreetsete punktidega: töötlemise ese ja kestus, laad ja eesmärk, andmeliigid ja andmesubjektide kategooriad, samuti vastutava töötleja õigused ja kohustused.

Puhas koodikirjutamine ilma ligipääsuta isikuandmetele artiklit 28 ei käivita, seega ei vaja iga arendusleping andmetöötluslepingut. Piir on lihtne ja kontrollitav: kui arendaja näeb päris kliendiandmeid, on seda vaja, aga kui arendaja töötab ainult testandmetega ja tootmiskeskkonda ei näe, ei ole, ja see ise on argument selle kasuks, et testkeskkond oleks eraldi.

Mida te saate ja mida samal ajal endale võtate

Selle artikli loogika on seni olnud ühepoolne, seega on aus öelda ka teine pool: täielik kontroll tellimussüsteemi üle ei ole ainult võit, vaid ka kohustuste kogum, mis ei kao. Valmistoodangule tagab hoolduse, turvapaigad ja ühilduvuse uute keskkondadega tootja, ja see on kuutasu sees, tellimussüsteemile tagab selle kõik omanik, see tähendab teie, ja see on otsene kulu, mis ilmub igal aastal sõltumata sellest, kas süsteemis midagi muutub.

Teine, mille endale võtate, on süsteemi vananemine, mis koguneb vaikselt ega ilmne millegi poolest, kuni keegi seda otsib. Süsteem toetub keele ja raamistiku versioonidele, millele tootjad määravad toe tähtajad, ja pärast nende tähtaegade lõppu uusi turvanõrkusi enam ei paikata, kuigi süsteem töötab edasi täpselt nagu varem ja ükski ekraan sellest ei hoiata. See ei ole keeld vananenud süsteemi käitada, kuid see on hetk, millest alates riski kannab omanik, ja konkreetsed kuupäevad PHP ja Laraveli puhul oleme koondanud artiklisse selle kohta, mida tähendab PHP ja Laraveli valik, seega siin me neid ei korda.

Kolmas on turg, ja valmisplatvormile on spetsialisti leida suhteliselt kerge, sest neid õpetatakse ja neid on mitu, seevastu tellimussüsteemi tunnevad ainult need, kes selle ehitasid, ja uuel arendajal tuleb jätta aega tutvumiseks, enne kui ta saab midagi turvaliselt muuta. See ei tähenda, et ülevõtmine oleks võimatu, kuid tähendab, et see maksab, ja see kulu ilmub just sel hetkel, kui suhted eelmise arendajaga on juba lõppenud.

Just seetõttu ei ole küsimus sellest, mis teile kuulub, juriidiline formaalsus, vaid küsimus sellest, kui kallis tuleb järgmine valik. Ettevõte, kellel on kirjalik loovutus, lähtekood oma repositooriumis ja nimekiri kasutatud komponentidest, võib otsida uut arendajat nädala jooksul, seevastu ettevõte ilma selle kõigeta selgitab kõigepealt, mida tal üldse tohib teha, ja alles siis hakkab otsima, ja see on vahe positsioonilt rääkimise ja vajadusest rääkimise vahel.

Mis lepingusse kirjutada, kuni veel saab

Kõik eelmised jaotised viivad väikese punktide kogumini, mis tasub lepingusse kirjutada enne töö algust, sest pärast üleandmist on läbirääkimispositsioon palju nõrgem. Esimene on varaliste õiguste loovutamine kirjalikult, nimetades, millised õigused lähevad üle, millisel territooriumil ja kui kauaks, sest autorileping peab need § 48¹ järgi fikseerima. Teine on kinnitus, et agentuur on need saanud oma töötajatelt ja alltöövõtjatelt, sest ilma selle lülita võib loovutus ise olla tühi — eriti seetõttu, et töötaja programmil on tööandjal vaikimisi ainulitsents, mitte õiguste loovutus.

Kolmas on lähtekoodi ja kõige selle, mis on vaja selle kompileerimiseks, regulaarne üleandmine, mitte ühekordne üleandmine projekti lõpus, ja neljas on repositooriumi asukoht teie organisatsiooni kontol juba esimesest päevast. Viies on avatud lähtekoodi komponentide nimekiri koos nende litsentsidega, sest ilma selle nimekirjata ei tea keegi hiljem, mis süsteemis on ja millistel tingimustel; kuues on andmetöötlusleping, kui arendaja näeb päris andmeid, ja seitsmes on kokkulepe selle kohta, mis juhtub keskkondade, võtmete ja ligipääsudega koostöö lõppedes.

Ükski neist punktidest ei nõua pikka teksti, ükski neist ei ole vastuolus hea koostööga, ja ükski aus arendaja ei vaidle nendele vastu, sest need panevad kirja täpselt selle, mida mõlemad pooled niikuinii mõtlevad. Ainus, mida need muudavad, on see, et kokkulepe ei sõltu enam sellest, kas need konkreetsed inimesed kolme aasta pärast veel samas ettevõttes töötavad ja kas keegi mäletab, mis tollal suuliselt öeldi. Neid punkte tasub küsida igalt arendajalt, ka meilt, ja kirjutada need lepingusse enne töö algust. Meie eritarkvara ja ärisüsteemide arenduse leht lubab praegu lähtekoodi, dokumentatsiooni ja taristu konfiguratsiooni üle anda töö lõpus, ja just seetõttu tasub kolmandat punkti selles nimekirjas, see tähendab regulaarset üleandmist töö käigus, arutada eraldi, mitte eeldada, et see on iseenesestmõistetav. Kui soovite, et vaataksime juba olemasoleva lepingu üle, kirjutage meile.