Kas Jums pieder, kad sistēma ir gatava: kods, dati un atkarība no izstrādātāja

Sistēma ir nodota, rēķins ir apmaksāts, un pēc pusgada uzņēmums nolemj mainīt izstrādātāju, un tieši tajā brīdī tiek uzdots jautājums, kas līdz šim nevienam nešķita steidzams: kam pieder tas, par ko tika samaksāts. Atbilde Latvijā pārsteidz gandrīz visus, kas to dzird pirmo reizi, jo samaksa par izstrādi pati par sevi nedod pasūtītājam autortiesības uz izveidoto datorprogrammu, un tas nav juridisks smalkums, bet noklusējums, kas darbojas ikreiz, kad līgumā nekas cits nav ierakstīts.

Šis raksts ir par to, kas paliek Jūsu rokās pēc nodošanas, un tas nav tas pats jautājums, kuru esam aplūkojuši, salīdzinot gatavu produktu ar pasūtījuma programmatūru. Tur runa bija par to, ko izvēlēties; šeit runa ir par to, ko Jūs turat rokās, kad izvēle jau ir izdarīta un sistēma strādā. Atbilde sadalās trijās daļās: kods un tiesības uz to, dati kopā ar vietu, kur tie glabājas, un atkarība no cilvēkiem, kuri sistēmu pazīst.

Autors vienmēr ir cilvēks, nevis uzņēmums

Autortiesību likuma izpratnē autors ir fiziskā persona, kuras radošās darbības rezultātā konkrētais darbs ir radīts, un tas nozīmē, ka uzņēmums nekad nav autors: autori ir programmētāji, dizaineri un tekstu autori, kas pie sistēmas strādāja. Datorprogrammas ir aizsargātas kā literāri darbi, tāpat kā Eiropas Savienības Direktīvā 2009/24/EK, un autortiesības rodas brīdī, kad darbs ir radīts, bez reģistrācijas, bez atzīmes un neatkarīgi no tā, vai darbs ir pabeigts.

Autortiesības sadalās divās daļās, kuras Latvijas likums nosauc par personiskajām un mantiskajām tiesībām, un praksē tas ir svarīgākais sadalījums visā šajā tēmā, jo tikai viena no tām vispār var nonākt pie uzņēmuma. Mantiskā daļa ir tā, kuru var nodot citam, un datorprogrammas gadījumā tā ļauj programmu izplatīt, padarīt pieejamu, iznomāt, reproducēt, kā arī tulkot, pielāgot vai citādi pārveidot un reproducēt pārveidojuma rezultātus. Personiskā daļa paliek pie autora visu mūžu un nav atsavināma nevienam, un tieši tāpēc neviens līgums nevar ierakstīt, ka uzņēmums kļūst par autoru.

Ir vēl viena robeža, kuru pamana reti, un tā var izrādīties dārga. Divpadsmitā panta otrā daļa, kas mantiskās tiesības nogādā darba devējam, runā tikai par datorprogrammu, savukārt visam pārējam, ko projekts rada, proti, dizainam, dokumentācijai, tekstiem un instrukcijām, piemēro tā paša panta pirmo daļu, kur noklusējums ir citāds: tās paliek pie autora, un darba devējs iegūst tikai mērķim ierobežotu izmantošanu. Praktiski tas nozīmē, ka viena projekta ietvaros divām radītajām lietām var būt divi dažādi īpašnieki, un līgums, kas runā tikai par programmatūru, dizainu var atstāt ārpusē.

No tā izriet pirmās praktiskās sekas, kuras ir vērts saprast pirms visa pārējā: kad uzņēmums pasūta sistēmu no aģentūras, tiesību ķēde ir vismaz divu posmu gara, jo vispirms programmētāji ir autori, tad aģentūra ir vai nav ieguvusi no viņiem mantisko daļu, un tikai tad aģentūra var kaut ko nodot Jums. Ja kāds posms trūkst, aģentūra sola vairāk, nekā tai pieder, un to pamana tikai tad, kad kāds sāk pārbaudīt.

Darbinieks un pasūtījums ir divi dažādi noklusējumi

Šeit ir raksta kodols, un šī ir tā vieta, kur intuīcija ved nepareizā virzienā. Autortiesību likuma 12. panta otrā daļa nosaka, ka gadījumā, ja darbinieks ir radījis datorprogrammu, pildot darba uzdevumu, visa mantiskā daļa pieder darba devējam, ja vien līgumā nav noteikts citādi. Tā ir Latvijas atbilde uz Direktīvas 2009/24/EK 2. panta trešo daļu, un tā attiecas tikai uz darba attiecībām un tikai uz datorprogrammām.

Pasūtījuma gadījumā noklusējums ir pretējs, un tieši tāpēc abus gadījumus nedrīkst jaukt: Autortiesību likuma 13. pants regulē autora līgumu par pasūtītu darbu un nosaka, ka autoram jāizpilda pasūtītais darbs un jānodod tas pasūtītājam izmantošanai, bet tas ne ar vienu vārdu nesaka, ka mantiskā daļa pārietu pasūtītājam. Uzņēmuma līgums pēc Civillikuma 2212. panta par autortiesībām nesaka neko vispār, jo tas regulē darba izpildi un nodošanu, nevis tiesību apriti.

Salieciet abus kopā, un iznāk situācija, kurā tipisks uzņēmums nonāk, pat par to nezinot: klients pasūta sistēmu aģentūrai; programmētāji ir aģentūras darbinieki, tāpēc 12. panta otrā daļa mantisko daļu nogādā aģentūrā; klienta un aģentūras līgums ir uzņēmuma līgums, kas to tālāk nepārnes. Rezultātā klients ir samaksājis par rezultātu un saņēmis rezultātu, bet mantiskā daļa ir palikusi pie aģentūras, un vienīgais, kas klientam ir, ir neskaidra netieša licence lietot sistēmu tam nolūkam, kādam tā tika pasūtīta.

Zvērinātu advokātu birojs COBALT to 2024. gadā formulēja tieši, rakstot, ka maldīgs ir priekšstats, ka tiesības uz datorprogrammu pieder personai, kas ir pasūtījusi un apmaksājusi tās izstrādi, un ka Autortiesību likums neparedz automātisku tiesību piederību pasūtītājam. Birojs Sorainen gadu iepriekš norādīja uz to pašu, piebilstot, ka netiešas licences saturs paliek neskaidrs, un, tā kā abi ir juridiskie biroji, kuri pārdod līgumu sagatavošanu, viņu vērtējumu ir vērts lasīt kopā ar likuma tekstu, un šajā gadījumā likuma teksts viņus apstiprina.

Failu saņemšana nav tiesību saņemšana

Otrs pieņēmums, kas neiztur pārbaudi, ir tāds, ka koda saņemšana kaut ko izšķir, bet Autortiesību likuma 16. panta trešā daļa nosaka, ka mantiskās tiesības nav saistītas ar īpašuma tiesībām uz lietu un ka lietas valdījuma nodošana pati par sevi nenozīmē autora tiesību nodošanu. Praksē tas nozīmē, ka arhīvs ar visu pirmkodu, piekļuve repozitorijam un pat pilna dokumentācija joprojām nav tas pats, kas tiesības šo kodu izmantot, pārveidot un nodot citam izstrādātājam.

Tas darbojas arī pretējā virzienā, un šī puse ir mazāk zināma, jo uzņēmums var būt ieguvis mantiskās tiesības ar labi uzrakstītu līgumu, bet tā arī nesaņēmis pirmkodu, ja līgumā nebija atsevišķi ierakstīts pienākums to nodot. Atļauja bez faila ir tikpat neizmantojama kā fails bez atļaujas, tāpēc līgumā vajag abus, un tie ir divi patstāvīgi punkti, nevis viens punkts, kas otru ietver pats no sevis.

Kad tiesības tiek nodotas pareizi, likums prasa zināmu precizitāti, un tā nav formalitāte, jo Autortiesību likums ļauj mantisko daļu atsavināt vai licencēt, atļaujot līgumā norādīt gan teritoriju, gan termiņu, bet nosaka arī noklusējumu tam, kas notiek, ja teritorija nav minēta: nodošanu uzskata par notikušu tikai tajā valstī, kurā līgums noslēgts. Uzņēmumam, kas darbojas vairākās valstīs vai plāno tur darboties, tas ir tiešs iemesls teritoriju ierakstīt, turklāt likums prasa atļauju katram izmantošanas veidam atsevišķi, tāpēc formulējums par vienu izmantošanas veidu neatver pārējos.

Ir vēl viens pārsteigums, kas gaida uzņēmumu, kurš dzīvo ar netiešu licenci un nekad nav to noformējis rakstiski. Autortiesību likuma 44. panta otrā daļa nosaka, ka gadījumā, ja licence nav ierobežota ar termiņu, autors vai tiesību īpašnieks var to izbeigt, brīdinot sešus mēnešus iepriekš, un panta trešā daļa nosaka, ka atteikšanās no šīm tiesībām nav spēkā. Uzņēmums, kura vienīgais pamats sistēmas lietošanai ir nerakstīta vienošanās, tāpēc dzīvo ar sešu mēnešu uzteikuma iespēju, un no tās nevar atrunāties pat tad, ja abas puses to vēlētos.

Personiskās tiesības un tas, ko tās vairs neaizliedz

Personiskajā daļā ietilpst autorība, vārds, darba neaizskaramība un iespēja darbu atsaukt no izmantošanas, un tas viss paliek pie autora, jo nevienu no šiem elementiem nevar nodot citai personai autora dzīves laikā. Uzņēmumam, kas pasūtījis sistēmu, tas sākumā izklausās draudīgi, jo rodas iespaids, ka bijušais izstrādātājs kādā brīdī var pieprasīt sistēmas apturēšanu.

Praksē tas vairs nav tā, un iemesls ir 2023. gadā pievienotā 14. panta pirmā prim daļa, kas datorprogrammām šo risku noņem: datorprogrammas autors, pamatojoties uz personiskajām tiesībām, nevar aizliegt programmas pārveidošanu, grozīšanu vai papildināšanu, ja vien šāda izmantošana nekaitē viņa godam un cieņai, un nevar izmantot tiesības atsaukt darbu. Tas nozīmē, ka bijušais programmētājs nevar apturēt ne parasto uzturēšanu, ne pārstrādi, un tieši šī bija tā personisko tiesību daļa, kas uzņēmumam būtu bīstama.

Tajā pašā 2023. gada grozījumu paketē ir vēl viena norma, kas uzņēmumam ir labvēlīga un kuru ir vērts zināt, jo pretējā gadījumā to var sagaidīt no nepareizās puses. Noteikumi par taisnīgu atlīdzību un autora tiesībām saņemt informāciju par darba izmantošanu, kas citiem darbu veidiem ļauj autoram atgriezties pie jautājuma par samaksu, uz datorprogrammu autoriem neattiecas, un tas nozīmē, ka programmētājs, kurš uzskata, ka sistēma izrādījusies vērtīgāka, nekā abas puses gaidīja, uz šī pamata papildu atlīdzību prasīt nevar.

Kas paliek, ir iespēja tikt nosauktam par autoru un aizsardzība pret tādu darba izmantošanu, kas kaitē godam un cieņai, un tas ir ievērojami mazāks risks, ar kuru var dzīvot. Svarīgi ir tikai neapjaukt divas lietas: pārveidošana kā personisko tiesību jautājums vairs nav šķērslis, bet pārveidošana kā mantiskā daļa joprojām prasa tās īpašnieka atļauju, tāpēc, ja mantiskā daļa palikusi pie aģentūras, sistēmas pārstrādei joprojām ir vajadzīga tās piekrišana.

Ko likums dod arī bez laba līguma

Pat uzņēmumam, kurš nav noformējis neko, likums dod dažas iespējas, un ir vērts zināt, kuras no tām līgumā var atņemt un kuras nevar. Autortiesību likuma 29. panta pirmā daļa ļauj likumīgam lietotājam reproducēt, tulkot, pielāgot vai citādi pārveidot programmu, ciktāl tas vajadzīgs izmantošanai atbilstoši paredzētajam nolūkam, ieskaitot kļūdu labošanu, bet šī tiesība darbojas tikai tad, ja līgumā nav paredzēts citādi, tāpēc to līgums var atņemt, un daudzi līgumi to arī dara.

Rezerves kopijas izgatavošana ir citāds gadījums, un tā ir vienīgā šajā sadaļā, kuru līgums atņemt nevar, jo Autortiesību likuma 29. panta otrā daļa nosaka, ka likumīgam ieguvējam nedrīkst aizliegt izgatavot programmas rezerves kopiju, ja tā nepieciešama programmas izmantošanai, un tas atbilst Direktīvas 2009/24/EK 5. panta otrajai daļai. Direktīvas 8. pants turklāt nosaka, ka līguma noteikumi, kas ir pretrunā ar 6. pantu vai ar 5. panta otrajā un trešajā daļā paredzētajiem izņēmumiem, nav spēkā.

Šeit ir vērts būt precīziem, jo starpība ir smalka un viegli pārspīlējama, proti, Latvijas likums rezerves kopijas gadījumā lieto formulējumu par aizlieguma nepieļaujamību, bet dekompilācijas pantā nav atsevišķa teikuma par to, ka pretrunīgs līgums nav spēkā, kaut gan direktīva to nosaka. Tāpēc nav pareizi rakstīt, ka Latvijas likums burtiski pārņem direktīvas 8. pantu; pareizi ir teikt, ka rezerves kopiju līgumā atņemt nevar un ka direktīva papildus atzīst par spēkā neesošiem noteikumus, kas ir pretrunā dekompilācijas izņēmumam.

Dekompilācija savukārt ir atļauta šauri un ar nosacījumiem: to drīkst veikt, lai panāktu neatkarīgi radītas programmas sadarbspēju, ja informācija citādi nav pieejama, to dara persona, kas likumīgi ieguvusi tiesības lietot kopiju, un darbība aprobežojas ar tām daļām, kas sadarbspējai vajadzīgas. Iegūto informāciju nedrīkst izmantot citiem mērķiem vai tāda produkta radīšanai, kas ir būtiski līdzīgs, un šis izejas ceļš ir noderīgs, bet šaurs, un neviens uzņēmums nevēlas, lai tas būtu vienīgais.

Sistēmā ir daudz koda, kas nekad nebūs Jūsu

Pasūtījuma sistēma gandrīz nekad nav tikai tas kods, ko rakstīja izstrādātājs, jo lielākā daļa apjoma nāk no bibliotēkām un ietvara, kas jau eksistēja. Tas kods nekļūst par Jūsu īpašumu nekad un nekādā līgumā, jo Jūs saņemat licenci no tā autoriem, un šī atšķirība ir svarīga tieši tad, kad kāds sola nodot visas tiesības uz sistēmu.

Atļaujošās licences problēmu nerada, jo tās prasa maz un neierobežo to, kā gatavo sistēmu drīkst izmantot komercdarbībā. MIT licence ļauj izmantot, kopēt, pārveidot, apvienot, publicēt, izplatīt un pārdot, ja vien tiek saglabāts autortiesību paziņojums un pati licence, un programmatūra tiek nodota tāda, kāda tā ir, bez garantijām, savukārt Apache 2.0 licence tam pievieno tiešu patentu licenci un prasa atzīmēt izdarītās izmaiņas. Abas ir savietojamas ar slēgtu komercsistēmu, lielākā daļa mūsdienu ietvaru ir viena no tām, un tieši tāpēc šī sistēmas daļa parasti nekādas sarunas neprasa.

Copyleft licences prasa uzmanību, bet ne paniku, un tieši šeit visbiežāk stāsta puspatiesības, kaut gan Brīvās programmatūras fonds savā GPL jautājumu lapā skaidri raksta, ka uzņēmums, kas darbina pārveidotu GPL programmu savā tīmekļa vietnē, nav spiests publicēt pārveidoto pirmkodu, jo copyleft pienākums iestājas, nododot kopijas citiem, nevis lietojot programmu pie sevis. Vairāku kopiju izgatavošana un lietošana vienas organizācijas ietvaros nav izplatīšana, lai gan kopiju nodošana citām organizācijām, ieskaitot darbuzņēmējus lietošanai ārpus uzņēmuma, jau ir.

Izņēmums ir Affero licence, un tieši tās 13. pants ir tas, kas cilvēkus pārsteidz, jo, ja Jūs programmu pārveidojat un pārveidotā versija ļauj lietotājiem ar to sazināties attālināti pa datortīklu, tad šiem lietotājiem ir jāpiedāvā iespēja saņemt attiecīgo pirmkodu. Nosacījumi ir divi un abi ir vajadzīgi: pārveidošana un attālināta lietotāju mijiedarbība, tāpēc nav pareizi teikt, ka jebkura Affero licences lietošana prasa pirmkoda publicēšanu, un nav pareizi teikt, ka viena šāda bibliotēka automātiski pakļauj visu sistēmu, jo tas ir atkarīgs no tā, kā komponenti ir savienoti.

Deponēšana pie trešās puses un ko tā patiesībā dod

Pirmkoda deponēšana ir trīspusējs risinājums, kurā izstrādātājs nodod pirmkodu neitrālam glabātājam, bet glabātājs to izsniedz pasūtītājam tikai tad, ja iestājas līgumā aprakstītais gadījums, un tipiskie gadījumi ir maksātnespēja, darbības izbeigšana vai būtiska uzturēšanas saistību neizpilde pēc brīdinājuma. Latvijā nav likuma, kas šos gadījumus noteiktu vai kaut vai uzskaitītu, tāpēc viss, kas šeit darbojas, ir tas, ko puses pašas ir uzrakstījušas, un tāpēc deponēšanas līgums ir jālasa tikpat uzmanīgi kā pats izstrādes līgums.

Deponēšana dod tieši to, kas ir deponēts, un tikai tad, kad iestājas tas, kas ir aprakstīts, bet pati par sevi tā nenodod autortiesības, jo par to atkal jāatceras 16. panta trešā daļa, un tā neiemāca sistēmu darbināt. Uzņēmums NCC Group, kas šo pakalpojumu pārdod jau gadu desmitiem, savos materiālos atzīst pats: pirmkoda esamība glabātavā ir viena lieta, bet prasme to sakompilēt ir cita, un tieši tāpēc tas pats uzņēmums pārdod arī deponētā satura pārbaudi. Tas ir ieinteresētas puses vērtējums, bet tā ir atzīšanās par sava pamatpakalpojuma vājo vietu, un tāpēc tā ir izmantojama.

Mūsdienu sistēmām ir arī otra nepilnība, kas ar juridisko pusi nav saistīta vispār: ja sistēma darbojas kā pakalpojums uz izstrādātāja infrastruktūras, tad pirmkods bez darbināšanas vides, konfigurācijas un datiem atrisina mazāko daļu problēmas, jo saņēmējam paliek arhīvs, nevis strādājoša sistēma. Praktiķi šo trūkumu risina, papildinot deponēšanu ar vienošanos par to, kurš vidi pārņem un kas notiek, ja rēķini par hostingu paliek neapmaksāti, un tieši šie punkti deponēšanas standarta veidlapās parasti neparādās.

Ir arī juridisks šķērslis, ko apraksta Rīgas Juridiskās augstskolas 2020. gada maģistra darbs par pirmkoda deponēšanas līgumiem: maksātnespējas procesā deponētā manta un tās izsniegšana var nonākt pretrunā ar mantas masas režīmu, tātad tieši tajā gadījumā, kura dēļ deponēšana visbiežāk tiek pirkta. Praktiskais secinājums nav atteikties no deponēšanas, bet neuzskatīt to par aizvietotāju rakstiskai tiesību nodošanai un pirmkoda regulārai izsniegšanai.

Kur atrodas repozitorijs un kur atrodas dati

Jautājums par to, kur atrodas kods un dati, izšķir vairāk nekā jautājums par to, kam tie pieder, jo tiesības bez piekļuves ir lēna problēma. GitHub dokumentācija skaidri apraksta, ka organizācija ir kopīgs konts, kuram pieder repozitoriji, ka organizācijā ieiet nevar, jo cilvēki pieteicas ar personīgajiem kontiem, un ka organizācijas īpašniekiem vienmēr ir piekļuve visiem repozitorijiem; repozitorijs var piederēt gan personīgajam kontam, gan organizācijai, un šī izvēle ir svarīgāka, nekā izskatās.

Ja repozitorijs pieder izstrādātāja personīgajam kontam, tad klienta piekļuve ir tikai līdzstrādnieka piekļuve, kuru konta īpašnieks var atņemt jebkurā brīdī, un, aizejot no projekta, viņš paņem līdzi arī pašu adresi. Ja repozitorijs pieder klienta organizācijai, kurā izstrādātājs ir uzaicināts kā dalībnieks, tad aiziešana nozīmē vienas piekļuves noņemšanu un neko vairāk, un tā ir viena no retajām lietām šajā rakstā, kuru var salabot vienā dienā un bez jurista.

Dati ir atsevišķs jautājums, un tur runa vairs nav par autortiesībām: ja izstrādātājs apstrādā personas datus Jūsu vārdā, proti, darbina ražošanas vidi, piekļūst klientu vai darbinieku datiem vai veido dublējumkopijas, tad Jūs esat pārzinis un izstrādātājs ir apstrādātājs Vispārīgās datu aizsardzības regulas izpratnē. Regulas 28. pants prasa rakstisku līgumu ar konkrētiem punktiem: apstrādes priekšmets un ilgums, raksturs un nolūks, datu veidi un datu subjektu kategorijas, kā arī pārziņa tiesības un pienākumi.

Tīri koda rakstīšanas darbs bez piekļuves personas datiem 28. pantu neiedarbina, tāpēc ne katram izstrādes līgumam vajag datu apstrādes līgumu. Robeža ir vienkārša un pārbaudāma: ja izstrādātājs var redzēt reālus klientu datus, tad vajag, bet, ja izstrādātājs strādā tikai ar testa datiem un ražošanas vidi neredz, tad nevajag, un tas pats par sevi ir arguments par labu tam, lai testa vide būtu atsevišķa.

Ko Jūs iegūstat un ko vienlaikus uzņematies

Šī raksta loģika līdz šim ir bijusi vienpusēja, tāpēc godīgi ir pateikt arī otru pusi: pilna kontrole pār pasūtījuma sistēmu nav tikai ieguvums, bet arī saistību kopums, kas neizzūd. Gatavai programmatūrai uzturēšanu, drošības ielāpus un savietojamību ar jaunām vidēm nodrošina ražotājs, un tas ir iekļauts abonēšanas maksā, savukārt pasūtījuma sistēmai to visu nodrošina īpašnieks, proti, Jūs, un tas ir tiešs izdevums, kas parādās katru gadu neatkarīgi no tā, vai sistēmā kaut kas mainās.

Otrs, ko uzņematies, ir sistēmas novecošana, kas uzkrājas klusi un neizpaužas nekādā veidā, kamēr kāds to nemeklē. Sistēma balstās uz valodas un ietvara versijām, kurām ražotāji nosaka atbalsta termiņus, un pēc šo termiņu beigām jaunas ievainojamības vairs netiek lāpītas, kaut gan sistēma turpina strādāt tieši tāpat kā iepriekš un neviens ekrāns par to nebrīdina. Tas nav aizliegums darbināt novecojušu sistēmu, bet tas ir brīdis, kurā risku pārņem īpašnieks, un konkrētos datumus PHP un Laravel gadījumā esam apkopojuši rakstā par to, ko nozīmē izvēlēties PHP un Laravel, tāpēc šeit tos neatkārtojam.

Trešais ir tirgus, un gatavai platformai speciālistu var atrast salīdzinoši viegli, jo tos māca un tie ir vairāki, savukārt pasūtījuma sistēmu pazīst tikai tie, kas to būvēja, un jaunam izstrādātājam ir jāatvēl laiks iepazīšanai, pirms viņš var kaut ko mainīt droši. Tas nenozīmē, ka pārņemšana ir neiespējama, bet nozīmē, ka tā maksā, un šī izmaksa parādās tieši tajā brīdī, kad attiecības ar iepriekšējo izstrādātāju jau ir beigušās.

Tieši tāpēc jautājums par to, kas Jums pieder, nav juridiska formalitāte, bet jautājums par to, cik dārgi maksās nākamā izvēle. Uzņēmums ar rakstisku nodošanu, pirmkodu savā repozitorijā un sarakstu ar izmantotajiem komponentiem var meklēt jaunu izstrādātāju nedēļas laikā, savukārt uzņēmums bez tā visa vispirms noskaidro, ko tam vispār drīkst darīt, un tikai pēc tam sāk meklēt, un tā ir starpība starp sarunu no pozīcijas un sarunu no vajadzības.

Ko ierakstīt līgumā, kamēr vēl var

Visas iepriekšējās sadaļas noved pie neliela punktu kopuma, kuru vērts ierakstīt līgumā pirms darba sākuma, jo pēc nodošanas sarunu pozīcija ir daudz vājāka. Pirmais ir mantisko tiesību nodošana rakstiski, nosaucot, kuras tiesības pāriet, kādā teritorijā un uz kādu termiņu, jo, ja teritorija nav norādīta, likums uzskata tiesības par nodotām tikai tajā valstī, kurā līgums noslēgts. Otrais ir apliecinājums, ka aģentūra to ir ieguvusi no saviem darbiniekiem un apakšuzņēmējiem, jo bez šī posma pati nodošana var būt tukša.

Trešais ir pirmkoda un visa, kas vajadzīgs tā sakompilēšanai, regulāra nodošana, nevis vienreizēja nodošana projekta beigās, un ceturtais ir repozitorija atrašanās Jūsu organizācijas kontā jau no pirmās dienas. Piektais ir atklāta pirmkoda komponentu saraksts ar to licencēm, jo bez šī saraksta neviens vēlāk nezinās, kas sistēmā ir un ar kādiem nosacījumiem; sestais ir datu apstrādes līgums, ja izstrādātājs redzēs reālus datus, un septītais ir vienošanās par to, kas notiek ar vidēm, atslēgām un piekļuvēm sadarbības beigās.

Neviens no šiem punktiem neprasa garu tekstu, neviens no tiem nav pretrunā ar labu sadarbību, un neviens godīgs izstrādātājs pret tiem neiebilst, jo tie pieraksta tieši to, ko abas puses tāpat domā. Vienīgais, ko tie maina, ir tas, ka vienošanās vairs nav atkarīga no tā, vai konkrētie cilvēki pēc trim gadiem vēl strādā tajā pašā uzņēmumā un vai kāds atceras, kas tolaik tika pateikts mutiski. Šos punktus ir vērts prasīt no jebkura izstrādātāja, arī no mums, un ierakstīt tos līgumā pirms darba sākuma. Mūsu pasūtījuma sistēmu izstrādes lapa šobrīd apsola avota kodu, dokumentāciju un infrastruktūras konfigurāciju nodot darba beigās, un tieši tāpēc trešo punktu šajā sarakstā, proti, regulāru nodošanu darba gaitā, ir vērts pārrunāt atsevišķi, nevis pieņemt, ka tas ir pašsaprotami. Ja gribat, lai izskatām jau esošu līgumu, sazinieties ar mums.