Kas Jums priklauso, kai sistema parengta: kodas, duomenys ir priklausomybė nuo kūrėjo

Sistema perduota, sąskaita apmokėta, ir po pusmečio įmonė nusprendžia keisti kūrėją, ir būtent tada užduodamas klausimas, kuris iki tol niekam neatrodo skubus: kam priklauso tai, už ką buvo sumokėta. Atsakymas Lietuvoje nustebina beveik visus, kurie jį girdi pirmą kartą, nes apmokėjimas už kūrimą pats savaime neduoda užsakovui autorių teisių į sukurtą kompiuterių programą, ir tai nėra teisinis niuansas, o numatytoji taisyklė, kuri veikia kaskart, kai sutartyje nieko kito neįrašyta.

Šis straipsnis yra apie tai, kas lieka Jūsų rankose po perdavimo, ir tai nėra tas pats klausimas, kurį esame nagrinėję lygindami standartinį produktą su individualia programine įranga. Ten kalbėta apie tai, ką rinktis; čia kalbama apie tai, ką Jūs laikote rankose, kai pasirinkimas jau padarytas ir sistema veikia. Atsakymas skyla į tris dalis: kodas ir teisės į jį, duomenys kartu su vieta, kur jie saugomi, ir priklausomybė nuo žmonių, kurie sistemą pažįsta.

Autorius visada yra žmogus, o ne įmonė

Autorių teisių ir gretutinių teisių įstatymo prasme autorius yra fizinis asmuo, kurio kūrybinės veiklos rezultatas yra konkretus kūrinys, ir tai reiškia, kad įmonė niekada nėra autorius: autoriai yra programuotojai, dizaineriai ir tekstų autoriai, kurie prie sistemos dirbo. Kompiuterių programos saugomos kaip literatūros kūriniai, kaip ir Europos Sąjungos direktyvoje 2009/24/EB, o autorių teisės atsiranda tą akimirką, kai kūrinys sukurtas, be registracijos, be ženklo ir nepriklausomai nuo to, ar darbas baigtas.

Autorių teisės skyla į dvi dalis, kurias Lietuvos įstatymas vadina asmeninėmis neturtinėmis ir turtinėmis teisėmis, ir praktikoje tai yra svarbiausias skirstymas visoje šioje temoje, nes tik viena iš jų apskritai gali atitekti įmonei. Turtinė dalis yra ta, kurią galima perduoti kitam, ir kompiuterių programos atveju ji leidžia programą atgaminti, platinti, nuomoti, versti, adaptuoti ar kitaip perdirbti ir padaryti viešai prieinamą. Asmeninė neturtinė dalis lieka autoriui visą gyvenimą ir nėra perduodama niekam, ir būtent todėl jokia sutartis negali įrašyti, kad įmonė tampa autoriumi.

Yra dar viena riba, kurią pastebi retai, ir ji gali pasirodyti brangi. Dešimto straipsnio antroji dalis, kuri turtines teises atiduoda darbdaviui, kalba tik apie kompiuterių programą, o viskam kitam, ką projektas sukuria, tai yra dizainui, dokumentacijai, tekstams ir instrukcijoms, taikoma 9 straipsnio 2 dalis, kur numatytoji taisyklė kitokia: turtinės teisės penkeriems metams pereina darbdaviui, jei sutartyje nenumatyta kitaip, ir po to grįžta autoriui. Praktiškai tai reiškia, kad vieno projekto rėmuose dviem sukurtiems dalykams gali būti du skirtingi turėtojai ir du skirtingi terminai, o sutartis, kuri kalba tik apie programinę įrangą, dizainą gali palikti nuošalyje.

Iš to kyla pirmosios praktinės pasekmės, kurias verta suprasti pirmiausia: kai įmonė užsako sistemą iš agentūros, teisių grandinė yra bent dviejų grandžių ilgio, nes pirmiausia programuotojai yra autoriai, tada agentūra yra arba nėra įgijusi iš jų turtinę dalį, ir tik tada agentūra gali ką nors perduoti Jums. Jei kurios nors grandies trūksta, agentūra žada daugiau, nei jai priklauso, ir tai pastebima tik tada, kai kas nors ima tikrinti.

Darbuotojas ir užsakymas yra dvi skirtingos numatytosios taisyklės

Čia yra straipsnio branduolys, ir čia intuicija veda neteisinga kryptimi. Autorių teisių ir gretutinių teisių įstatymo 10 straipsnio 2 dalis nustato, kad jei darbuotojas sukūrė kompiuterių programą atlikdamas tarnybines pareigas ar darbo funkcijas, turtinės teisės priklauso darbdaviui, jei sutartyje nenumatyta kitaip. Tai Lietuvos atsakymas į direktyvos 2009/24/EB 2 straipsnio 3 dalį, ir jis taikomas tik darbo santykiams ir tik kompiuterių programoms.

Užsakymo atveju vaizdas kitoks, ir būtent todėl abiejų atvejų negalima maišyti: 41 straipsnis reguliuoja autorinę kūrinio užsakymo sutartį ir nustato, kad autorius įsipareigoja sukurti sutarties sąlygas atitinkantį kūrinį ir perduoti užsakovui sutartyje nurodytas turtines teises arba suteikti teises naudoti kūrinį nurodant naudojimo būdą, o užsakovas — sumokėti autorinį atlyginimą. Tai vis dar nėra automatinis teisių perėjimas vien nuo apmokėjimo, nes sutartis turi įvardyti teises, bet pats įvardytas sutarčių tipas perdavimą apima. Rangos sutartis pagal Civilinio kodekso 6.644 straipsnį apie autorių teises nesako nieko, nes ji reguliuoja darbo atlikimą ir rezultato perdavimą, o ne teisių apyvartą; 39 straipsnio 3 dalis papildo, kad sutartys, kurių dalykas nėra turtinių teisių perdavimas ar suteikimas, nelaikomos autorinėmis.

Sudėkite abu kartu, ir išeina situacija, į kurią tipiška įmonė patenka net to nežinodama: klientas užsako sistemą agentūrai; programuotojai yra agentūros darbuotojai, todėl 10 straipsnio 2 dalis turtinę dalį atiduoda agentūrai; kliento ir agentūros sutartis paprastai yra rangos sutartis, kuri jos toliau neperduoda. Rezultatas toks, kad klientas yra sumokėjęs už rezultatą ir rezultatą gavęs, bet turtinė dalis likusi agentūroje, ir vienintelis dalykas, kurį klientas turi, yra neaiški numanoma autorių teisių licencija naudoti sistemą tam tikslui, kuriam ji buvo užsakyta.

Pats įstatymo tekstas tą klaidingą vaizdą paneigia: 10 straipsnio 2 dalis, 39 straipsnio 3 dalis ir 41 straipsnis kartu reiškia, kad teisės į kompiuterių programą nepriklauso tam, kas ją užsakė ir apmokėjo, vien todėl, kad užsakė ir apmokėjo. Numanomos licencijos turinys lieka neaiškus, ir kadangi čia kalbama ne apie agentūros pažadą, o apie tai, ką įstatymas daro, kai sutartis tyli, verta skaityti būtent įstatymo tekstą, o ne tai, kas „savaime aišku“ po sąskaitos apmokėjimo.

Failų gavimas nėra teisių gavimas

Antra prielaida, kuri neišlaiko patikros, yra ta, kad kodo gavimas ką nors išsprendžia, bet Autorių teisių ir gretutinių teisių įstatymo 50 straipsnio 1 dalis nustato, kad autorių teisės į kūrinį nesiejamos su nuosavybės teise į materialųjį objektą, kuriuo tas kūrinys išreikštas, ir kad objekto perdavimas pats savaime nereiškia turtinių teisių perdavimo ar licencijos. Praktikoje tai reiškia, kad archyvas su visu išeities kodu, prieiga prie saugyklos ir net visa dokumentacija vis tiek nėra tas pats, kas teisės tą kodą naudoti, perdirbti ir perduoti kitam kūrėjui.

Tai veikia ir priešinga kryptimi, ir ši pusė mažiau žinoma, nes įmonė gali būti įgijusi turtines teises gerai parašyta sutartimi, bet taip ir negavusi išeities kodo, jei sutartyje nebuvo atskirai įrašyta pareiga jį perduoti. Leidimas be failo yra tiek pat nenaudingas kaip failas be leidimo, todėl sutartyje reikia abiejų, ir tai du savarankiški punktai, o ne vienas punktas, kuris kitą apima pats savaime.

Kai teisės perduodamos tinkamai, įstatymas reikalauja tam tikro tikslumo, ir tai nėra formalumas, nes Autorių teisių ir gretutinių teisių įstatymas leidžia turtinę dalį perduoti arba licencijuoti, leisdamas sutartyje nurodyti ir teritoriją, ir terminą, bet nustato ir numatytąją taisyklę tam, kas nutinka, jei teritorija nepaminėta: laikoma, kad turtinės teisės perduotos ar suteiktos Lietuvos Respublikos teritorijoje. Įmonei, kuri veikia keliose valstybėse arba planuoja ten veikti, tai tiesioginė priežastis teritoriją įrašyti; be to, 40 straipsnio 3 dalis laiko teises perduotomis tik dėl sutartyje nurodytų naudojimo būdų, o jei būdai nenurodyti — tik dėl tų, kurie būtini sutarties tikslui, todėl formulė apie vieną naudojimo būdą neatveria kitų.

Yra dar vienas siurprizas, kuris laukia įmonės, gyvenančios su numanoma licencija ir niekada jos neįforminusios raštu. Šešių mėnesių nutraukimo, nuo kurio negalima išsisukti net abiem šalims to norint, Lietuvos įstatymas neturi. Jei autorinėje sutartyje nenurodytas terminas, 40 straipsnio 2 dalis leidžia bet kuriai šaliai sutartį nutraukti prieš vienerius metus raštu įspėjus. Jei autorinės sutarties iš viso nėra, 39 straipsnio 3 dalis sako, kad tokia sutartis nėra autorinė, ir numanomo leidimo turinys lieka neaiškus — tai ne vienerių metų laikrodis, o teisės, kurios taip ir nebuvo įvardytos. Įmonė, kurios vienintelis pagrindas sistemai naudoti yra nerašytas susitarimas, todėl gyvena ne su įstatymo laikrodžiu, o be įvardytos teisės.

Asmeninės neturtinės teisės ir tai, ko jos neuždraudžia

Į asmeninę neturtinę dalį įeina autorystė, vardas ir kūrinio neliečiamybė, ir visa tai lieka autoriui, nes nė vieno iš šių elementų negalima perduoti kitam asmeniui autoriaus gyvenimo metu. Lietuvos įstatymas nenumato teisės atšaukti kūrinį iš naudojimo. Įmonei, užsakiusiai sistemą, tai iš pradžių skamba grėsmingai, nes kyla įspūdis, kad buvęs kūrėjas kurią nors akimirką gali reikalauti sistemą sustabdyti.

Praktikoje taip nėra, ir priežastis yra 14 straipsnio 3 dalis, galiojanti nuo 2006 metų, o ne 2023 metų naujovė: kompiuterių programų ir duomenų bazių autoriaus asmeninės neturtinės teisės negali būti naudojamos taip, kad nepagrįstai suvaržytų turtinių teisių turėtojo teisę savo nuožiūra adaptuoti, keisti ir platinti šiuos kūrinius, išskyrus atvejus, kai tokie veiksmai pažeistų autoriaus garbę ar reputaciją. Tai reiškia, kad buvęs programuotojas negali sustabdyti nei įprastos priežiūros, nei perrašymo asmeniniais neturtiniais pagrindais, ir būtent ši dalis įmonei būtų buvusi pavojinga.

Perkeldama DSM direktyvą 2022 metais, Lietuva įrašė dar vieną įmonei palankią normą, kurią verta žinoti, nes priešingu atveju jos galima tikėtis iš neteisingos pusės. 40¹ straipsnis dėl teisės gauti informaciją apie kūrinio panaudojimą ir 40² straipsnis dėl teisės reikalauti papildomo atlyginimo, kai pradinis atlygis pasirodo neproporcingai mažas palyginti su vėlesnėmis pajamomis, netaikomi, kai autorius yra kompiuterių programos kūrėjas, ir tai reiškia, kad programuotojas, kuris mano, kad sistema pasirodė vertingesnė, nei abi šalys tikėjosi, šiuo pagrindu papildomo atlygio prašyti negali.

Kas lieka, yra galimybė būti nurodytam kaip autoriui ir apsauga nuo tokio kūrinio naudojimo, kuris kenkia garbei ir reputacijai, ir tai gerokai mažesnė rizika, su kuria galima gyventi. Svarbu tik nesupainioti dviejų dalykų: perdirbimas kaip asmeninių neturtinių teisių klausimas nebėra kliūtis, bet perdirbimas kaip turtinė dalis vis tiek reikalauja jos turėtojo leidimo, todėl, jei turtinė dalis likusi agentūroje, sistemos perrašymui vis tiek reikalingas jos sutikimas.

Ką įstatymas duoda ir be geros sutarties

Net įmonei, kuri nieko neįformino, įstatymas duoda keletą galimybių, ir verta žinoti, kurių iš jų sutartis atimti negali. Autorių teisių ir gretutinių teisių įstatymo 30 straipsnio 1 dalis leidžia asmeniui, turinčiam teisę naudoti programą, pasidaryti kopijas ar adaptuoti programą tiek, kiek tai būtina naudotis ja pagal paskirtį, kuriai ji buvo įsigyta, įskaitant klaidų taisymą. Ketvirtoji to paties straipsnio dalis nustato, kad sutartys, trukdančios atlikti 1 ir 2 dalyse nurodytus veiksmus, negalioja, todėl šios teisės sutartis atimti negali, nors daugelyje sutarčių vis dar bandoma rašyti kitaip.

Atsarginės kopijos pasidarymas čia yra tos pačios 30 straipsnio 1 dalies antras punktas, o ne atskira išimtis, kurią sutartis galėtų palikti ramybėje: kopiją galima pasidaryti, jei teisėtai įsigyta programa būtų prarasta, sunaikinta ar taptų netinkama naudoti, ir 30 straipsnio 4 dalis šią teisę taip pat saugo nuo sutarties. Tai atitinka direktyvos 2009/24/EB 5 straipsnio 2 dalį. Direktyvos 8 straipsnis be to nustato, kad sutarties nuostatos, prieštaraujančios 6 straipsniui arba 5 straipsnio 2 ir 3 dalyse numatytoms išimtims, negalioja.

Čia verta būti tiksliems, nes skirtumas smulkus ir lengvai perdedamas: Lietuvos įstatymas tiek atsarginės kopijos, tiek dekompiliavimo straipsnyje turi atskirą sakinį, kad trukdančios sutartys negalioja — 30 straipsnio 4 dalis ir 31 straipsnio 3 dalis. Todėl teisinga rašyti, kad Lietuvos įstatymas direktyvos 8 straipsnį šiose išimtyse perima, ir kad sutartis, draudžianti kopijas pagal paskirtį, atsarginę kopiją, programos veikimo stebėjimą ar dekompiliavimą suderinamumui, yra negaliojanti.

Dekompiliavimas savo ruožtu leidžiamas siaurai ir su sąlygomis: jį galima atlikti, kad būtų užtikrintas savarankiškai sukurtos programos suderinamumas, jei informacija kitaip nėra prieinama, tai daro asmuo, teisėtai įgijęs teisę naudoti kopiją, ir veiksmas apsiriboja tomis dalimis, kurios suderinamumui reikalingos. Gautos informacijos negalima naudoti kitiems tikslams ar tokiam produktui kurti, kuris yra iš esmės panašus, ir šis kelias naudingas, bet siauras, ir jokia įmonė nenori, kad jis būtų vienintelis.

Sistemoje yra daug kodo, kuris niekada nebus Jūsų

Individuali sistema beveik niekada nėra tik tas kodas, kurį parašė kūrėjas, nes didžioji apimties dalis ateina iš bibliotekų ir karkaso, kurie jau egzistavo. Tas kodas niekada ir jokia sutartimi netampa Jūsų, nes Jūs gaunate licenciją iš jo autorių, ir šis skirtumas svarbus būtent tada, kai kas nors žada perduoti visas teises į sistemą.

Permisyviosios licencijos (angl. permissive) problemos nekelia, nes jos reikalauja nedaug ir neriboja to, kaip gatavą sistemą galima naudoti komercinėje veikloje. MIT licencija leidžia naudoti, kopijuoti, keisti, sujungti, skelbti, platinti ir parduoti, jei tik išsaugomas autorių teisių pranešimas ir pati licencija, o programinė įranga perduodama tokia, kokia yra, be garantijų, o Apache 2.0 licencija prie to prideda tiesioginę patentų licenciją ir reikalauja pažymėti padarytus pakeitimus. Abi suderinamos su uždara komercine sistema, didžioji dalis šiuolaikinių karkasų yra viena iš jų, ir būtent todėl ši sistemos dalis paprastai jokių derybų nereikalauja.

Copyleft licencijos reikalauja dėmesio, bet ne panikos, ir būtent čia dažniausiai pasakojamos pusiau tiesos, nors Laisvosios programinės įrangos fondas savo GPL klausimų puslapyje aiškiai rašo, kad įmonė, kuri savo interneto svetainėje vykdo pakeistą GPL programą, nėra verčiama skelbti pakeisto išeities kodo, nes copyleft pareiga atsiranda perduodant kopijas kitiems, o ne naudojant programą pas save. Kelių kopijų pasidarymas ir naudojimas vienos organizacijos viduje nėra platinimas, nors kopijų perdavimas kitoms organizacijoms, įskaitant rangovus naudojimui už įmonės ribų, jau yra.

Išimtis yra Affero licencija, ir būtent jos tinklo sąveikos sąlyga (AGPL §13) yra tai, kas žmones nustebina, nes jei Jūs programą pakeičiate ir pakeista versija leidžia naudotojams su ja susisiekti nuotoliniu būdu kompiuterių tinklu, tada šiems naudotojams turi būti pasiūlyta galimybė gauti atitinkamą išeities kodą. Sąlygos dvi ir abi reikalingos: pakeitimas ir nuotolinė naudotojų sąveika, todėl neteisinga sakyti, kad bet koks Affero licencijos naudojimas reikalauja išeities kodo skelbimo, ir neteisinga sakyti, kad viena tokia biblioteka automatiškai pajungia visą sistemą, nes tai priklauso nuo to, kaip komponentai sujungti.

Depozitas pas trečiąją šalį ir ką jis iš tikrųjų duoda

Išeities kodo depozitas (angl. source code escrow) yra trišalis sprendimas, kuriame kūrėjas perduoda išeities kodą neutraliam saugotojui, o saugotojas jį išduoda užsakovui tik tada, jei įvyksta sutartyje aprašytas atvejis, ir tipiški atvejai yra nemokumas, veiklos pabaiga arba esminis priežiūros įsipareigojimų nevykdymas po įspėjimo. Lietuvoje nėra įstatymo, kuris šiuos atvejus nustatytų ar bent išvardytų, todėl viskas, kas čia veikia, yra tai, ką šalys pačios yra parašiusios, ir todėl depozito sutartį reikia skaityti taip pat atidžiai kaip pačią kūrimo sutartį.

Depozitas duoda būtent tai, kas deponuota, ir tik tada, kai įvyksta tai, kas aprašyta, bet pats savaime jis autorių teisių neperduoda, nes čia vėl reikia prisiminti 50 straipsnį, ir jis neišmoko sistemos paleisti. Bendrovė NCC Group, kuri šią paslaugą parduoda jau dešimtmečius, savo medžiagoje pripažįsta pati: išeities kodo buvimas saugykloje yra viena, o gebėjimas jį sukompiliuoti — kita, ir būtent todėl ta pati bendrovė parduoda ir deponuoto turinio patikrą. Tai suinteresuotos šalies vertinimas, bet tai prisipažinimas dėl savo pagrindinės paslaugos silpnos vietos, ir todėl jis panaudojamas.

Šiuolaikinėms sistemoms yra ir antra spraga, kuri su teisine puse visai nesusijusi: jei sistema veikia kaip paslauga kūrėjo infrastruktūroje, tada išeities kodas be paleidimo aplinkos, konfigūracijos ir duomenų išsprendžia mažiausią problemos dalį, nes gavėjui lieka archyvas, o ne veikianti sistema. Praktikai šį trūkumą sprendžia papildydami depozitą susitarimu, kas perima aplinką ir kas nutinka, jei sąskaitos už talpinimą lieka neapmokėtos, ir būtent šių punktų depozito standartinėse formose paprastai nebūna.

Yra ir teisinė kliūtis: nemokumo procese deponuotas turtas ir jo išdavimas gali susikirsti su bankroto masės režimu, tai yra būtent tuo atveju, dėl kurio depozitas dažniausiai ir perkamas. Praktinė išvada nėra atsisakyti depozito, bet nelaikyti jo rašytinio teisių perdavimo ir reguliaraus išeities kodo išdavimo pakaitalu.

Kur yra saugykla ir kur yra duomenys

Klausimas, kur yra kodas ir duomenys, išsprendžia daugiau nei klausimas, kam jie priklauso, nes teisės be prieigos yra lėta problema. GitHub dokumentacija aiškiai aprašo, kad organizacija yra bendra paskyra, kuriai priklauso saugyklos, kad į organizaciją prisijungti negalima, nes žmonės jungiasi asmeninėmis paskyromis, ir kad organizacijos paskyros valdytojai visada turi prieigą prie visų saugyklų; saugykla gali priklausyti ir asmeninei paskyrai, ir organizacijai, ir šis pasirinkimas svarbesnis, nei atrodo.

Jei saugykla priklauso kūrėjo asmeninei paskyrai, tada kliento prieiga tėra kviesto nario prieiga, kurią paskyros valdytojas gali atimti bet kurią akimirką, ir išeidamas iš projekto jis pasiima ir patį adresą. Jei saugykla priklauso kliento organizacijos paskyrai, į kurią kūrėjas pakviestas kaip narys, tada išėjimas reiškia vienos prieigos nuėmimą ir nieko daugiau, ir tai vienas iš retų dalykų šiame straipsnyje, kurį galima sutvarkyti per vieną dieną ir be teisininko.

Duomenys yra atskiras klausimas, ir ten kalba jau ne apie autorių teises: jei kūrėjas tvarko asmens duomenis Jūsų vardu, tai yra, paleidžia gamybos aplinką, prieina prie klientų ar darbuotojų duomenų arba daro atsargines kopijas, tada Jūs esate duomenų valdytojas, o kūrėjas — duomenų tvarkytojas Bendrojo duomenų apsaugos reglamento prasme. Reglamento 28 straipsnis reikalauja rašytinės sutarties su konkrečiais punktais: tvarkymo dalykas ir trukmė, pobūdis ir tikslas, duomenų rūšys ir duomenų subjektų kategorijos, taip pat valdytojo teisės ir pareigos.

Vien kodo rašymo darbas be prieigos prie asmens duomenų 28 straipsnio neįjungia, todėl ne kiekvienai kūrimo sutarčiai reikia duomenų tvarkymo sutarties. Riba paprasta ir patikrinama: jei kūrėjas gali matyti tikrus klientų duomenis, tada reikia, o jei kūrėjas dirba tik su bandomaisiais duomenimis ir gamybos aplinkos nemato, tada nereikia, ir tai savaime yra argumentas už tai, kad bandomoji aplinka būtų atskira.

Ką Jūs gaunate ir ką kartu prisiimate

Šio straipsnio logika iki šiol buvo vienpusė, todėl sąžininga pasakyti ir kitą pusę: visapusiška individualios sistemos kontrolė nėra tik nauda, bet ir įsipareigojimų visuma, kuri neišnyksta. Standartinei programinei įrangai priežiūrą, saugumo pataisas ir suderinamumą su naujomis aplinkomis užtikrina gamintojas, ir tai įskaičiuota į prenumeratos mokestį, o individualiai sistemai visa tai užtikrina savininkas, tai yra Jūs, ir tai tiesioginės išlaidos, kurios atsiranda kiekvienais metais nepriklausomai nuo to, ar sistemoje kas nors keičiasi.

Antra, ką prisiimate, yra sistemos senėjimas, kuris kaupiasi tyliai ir neišduoda savęs jokiu būdu, kol kas nors jo neieško. Sistema remiasi kalbos ir karkaso versijomis, kurioms gamintojai nustato palaikymo terminus, ir po šių terminų pabaigos nauji pažeidžiamumai nebepataisomi, nors sistema toliau veikia lygiai taip pat kaip anksčiau ir joks ekranas apie tai neįspėja. Tai nėra draudimas paleisti pasenusią sistemą, bet tai akimirka, kurioje riziką perima savininkas, o konkrečias datas PHP ir Laravel atveju esame surinkę straipsnyje apie tai, ką reiškia pasirinkti PHP ir Laravel, todėl čia jų nekartojame.

Trečia yra rinka, ir standartinei platformai specialistą rasti palyginti lengva, nes juos moko ir jų yra keli, o individualią sistemą pažįsta tik tie, kurie ją statė, ir naujam kūrėjui reikia skirti laiko susipažinimui, kol jis gali ką nors keisti saugiai. Tai nereiškia, kad perėmimas neįmanomas, bet reiškia, kad jis kainuoja, ir ši kaina atsiranda būtent tada, kai santykiai su ankstesniu kūrėju jau pasibaigę.

Būtent todėl klausimas, kas Jums priklauso, nėra teisinis formalumas, o klausimas, kiek brangiai kainuos kitas pasirinkimas. Įmonė su rašytiniu perdavimu, išeities kodu savo saugykloje ir sąrašu naudotų komponentų gali ieškoti naujo kūrėjo per savaitę, o įmonė be viso to pirmiausia išsiaiškina, ką jai apskritai galima daryti, ir tik tada ima ieškoti, ir tai skirtumas tarp pokalbio iš pozicijos ir pokalbio iš būtinybės.

Ką įrašyti į sutartį, kol dar galima

Visos ankstesnės dalys veda prie nedidelio punktų rinkinio, kurį verta įrašyti į sutartį prieš pradedant darbą, nes po perdavimo derybų pozicija gerokai silpnesnė. Pirmas yra turtinių teisių perdavimas raštu, nurodant, kurios teisės pereina, kokioje teritorijoje ir kokiam terminui, nes jei teritorija nenurodyta, įstatymas laiko teises perduotomis tik Lietuvos Respublikos teritorijoje. Antras yra patvirtinimas, kad agentūra tai yra įgijusi iš savo darbuotojų ir subrangovų, nes be šios grandies pats perdavimas gali būti tuščias.

Trečias yra išeities kodo ir visko, ko reikia jam sukompiliuoti, reguliarus perdavimas, o ne vienkartinis perdavimas projekto pabaigoje, ir ketvirtas — saugyklos buvimas Jūsų organizacijos paskyroje jau nuo pirmos dienos. Penktas yra atvirojo kodo komponentų sąrašas su jų licencijomis, nes be šio sąrašo niekas vėliau nežinos, kas sistemoje yra ir kokiomis sąlygomis; šeštas yra duomenų tvarkymo sutartis, jei kūrėjas matys tikrus duomenis, ir septintas — susitarimas, kas nutinka su aplinkomis, raktais ir prieigomis bendradarbiavimo pabaigoje.

Nė vienas iš šių punktų nereikalauja ilgo teksto, nė vienas nėra prieštaravimas geram bendradarbiavimui, ir joks sąžiningas kūrėjas prieš juos neprieštarauja, nes jie užrašo būtent tai, ką abi šalys ir taip galvoja. Vienintelis dalykas, kurį jie pakeičia, yra tai, kad susitarimas nebepriklauso nuo to, ar konkretūs žmonės po trejų metų dar dirba toje pačioje įmonėje ir ar kas nors prisimena, kas tada buvo pasakyta žodžiu. Šių punktų verta prašyti iš bet kurio kūrėjo, ir iš mūsų taip pat, ir įrašyti juos į sutartį prieš pradedant darbą. Mūsų individualios programinės įrangos kūrimo puslapis šiuo metu žada išeities kodą, dokumentaciją ir infrastruktūros konfigūraciją perduoti darbo pabaigoje, ir būtent todėl trečią punktą šiame sąraše, tai yra reguliarų perdavimą darbo eigoje, verta aptarti atskirai, o ne manyti, kad tai savaime aišku. Jei norite, kad peržiūrėtume jau esamą sutartį, susisiekite su mumis.