Mikä kuuluu sinulle, kun järjestelmä on valmis: koodi, data ja riippuvuus kehittäjästä

Järjestelmä on luovutettu, lasku on maksettu, ja puolen vuoden kuluttua yritys päättää vaihtaa kehittäjää, ja juuri siinä kohdassa kysytään se, mitä kukaan ei siihen asti pitänyt kiireellisenä: kenen on se, mistä maksettiin. Vastaus Suomessa yllättää lähes kaikki, jotka kuulevat sen ensimmäistä kertaa, koska maksu kehityksestä ei itsessään anna tilaajalle tekijänoikeutta syntyneeseen tietokoneohjelmaan, eikä se ole oikeudellinen pikkuseikka vaan oletus, joka toimii joka kerta, kun sopimukseen ei ole kirjoitettu muuta.

Tämä artikkeli kertoo, mitä jää käsiisi luovutuksen jälkeen, eikä se ole sama kysymys, jota olemme jo käsitelleet vertaillessamme valmista tuotetta räätälöityyn ohjelmistoon. Siinä oli kyse valinnasta; tässä on kyse siitä, mitä pidät käsissäsi, kun valinta on jo tehty ja järjestelmä on käynnissä. Vastaus jakautuu kolmeen osaan: koodi ja oikeudet siihen, data yhdessä sen paikan kanssa, jossa se sijaitsee, ja riippuvuus ihmisistä, jotka tuntevat järjestelmän.

Tekijä on aina ihminen, ei yritys

Tekijänoikeuslain mukaan tekijä on se, joka on luonut kirjallisen tai taiteellisen teoksen, ja se tarkoittaa, että yritys ei ole tekijä: tekijöitä ovat ohjelmoijat, suunnittelijat ja tekstien kirjoittajat, jotka järjestelmää tekivät. Tietokoneohjelmia suojataan kirjallisina teoksina, samoin kuin Euroopan unionin direktiivissä 2009/24/EY, ja tekijänoikeus syntyy sillä hetkellä, kun teos on luotu, ilman rekisteröintiä, ilman merkintää ja riippumatta siitä, onko teos valmis.

Tekijänoikeus jakautuu kahteen osaan, joita Suomen laki kutsuu moraalisiksi ja taloudellisiksi oikeuksiksi, ja käytännössä se on koko tämän aiheen tärkein jako, koska vain toinen niistä voi ylipäätään siirtyä yritykselle. Taloudellinen osa on se, jonka voi luovuttaa toiselle, ja tietokoneohjelman kohdalla se antaa oikeuden määrätä ohjelmasta valmistamalla kappaleita ja saattamalla se yleisön saataviin, muuttamattomana tai muutettuna, käännöksenä tai muunnelmana. Moraalinen osa jää tekijälle, eikä sitä voi luovuttaa kenellekään, ja juuri siksi mikään sopimus ei voi kirjoittaa, että yrityksestä tulee tekijä.

On vielä yksi raja, joka jää harvoin huomatuksi ja voi tulla kalliiksi. Tekijänoikeuslain 40 b §, joka siirtää tekijänoikeuden työnantajalle, koskee tietokoneohjelmaa ja siihen välittömästi liittyvää teosta, joten ohjelmaan suoraan liittyvä dokumentaatio kulkee ohjelman mukana. Kaikkeen muuhun, mitä hanke tuottaa — ulkoasuun, markkinointiteksteihin ja ohjeisiin, jotka eivät ole ohjelmaan välittömästi liittyviä teoksia — ei ole yleistä työsuhdesäännöstä: ne jäävät tekijälle, jollei luovutuksesta ole sovittu, ja työnantaja saa tavanomaiseen toimintaansa rajatun käyttöoikeuden. Käytännössä se merkitsee, että saman hankkeen kahdella tuotoksella voi olla kaksi eri oikeudenhaltijaa, ja sopimus, joka puhuu vain ohjelmistosta, voi jättää ulkoasun ulkopuolelle.

Siitä seuraavat ensimmäiset käytännön seuraukset, jotka kannattaa ymmärtää ennen kaikkea muuta: kun yritys tilaa järjestelmän toimistolta, oikeuksien ketju on vähintään kahden askeleen mittainen, koska ensin ohjelmoijat ovat tekijöitä, sitten toimisto on tai ei ole saanut heiltä taloudellista osaa, ja vasta sen jälkeen toimisto voi luovuttaa sinulle jotakin. Jos jokin askel puuttuu, toimisto lupaa enemmän kuin sille kuuluu, ja sen huomaa vasta, kun joku alkaa tarkistaa.

Työsuhde ja tilaus ovat kaksi eri oletusta

Tässä on artikkelin ydin, ja tässä kohdassa intuitio vie väärään suuntaan. Tekijänoikeuslain 40 b § säätää, että jos tietokoneohjelma ja siihen välittömästi liittyvä teos on luotu täytettäessä työsuhteesta johtuvia työtehtäviä, tekijänoikeus ohjelmaan ja teokseen siirtyy työnantajalle, jollei toisin ole sovittu. Se on Suomen vastaus direktiivin 2009/24/EY 2 artiklan 3 kohtaan, ja se koskee vain työsuhdetta — ja virkasuhdetta — sekä tietokoneohjelmia ja niihin välittömästi liittyviä teoksia. Säännös ei kuitenkaan koske korkeakoulun opetus- ja tutkimustyössä itsenäisesti toimivan tekijän luomaa ohjelmaa eikä siihen välittömästi liittyvää teosta, sotilasopetuslaitoksia lukuun ottamatta.

Tilaustyössä oletus on päinvastainen, ja juuri siksi näitä kahta tilannetta ei saa sekoittaa: tilaustyösopimus velvoittaa tekijän tekemään tilatun teoksen ja luovuttamaan sen tilaajan käyttöön, mutta se ei yhdelläkään sanalla sano, että taloudellinen osa siirtyisi tilaajalle. Urakkasopimus ei puhu tekijänoikeudesta lainkaan, koska se säätelee työn tekemistä ja luovutusta, ei oikeuksien kiertoa.

Laita nämä kaksi yhteen, ja syntyy tilanne, johon tyypillinen yritys ajautuu tietämättään: asiakas tilaa järjestelmän toimistolta; ohjelmoijat ovat toimiston työntekijöitä, joten 40 b § vie taloudellisen osan toimistolle; asiakkaan ja toimiston sopimus on urakkasopimus, joka ei siirrä sitä eteenpäin. Tuloksena asiakas on maksanut tuloksesta ja saanut tuloksen, mutta taloudellinen osa on jäänyt toimistolle, ja ainoa, mitä asiakkaalla on, on epäselvä hiljainen tekijänoikeuslisenssi käyttää järjestelmää siihen tarkoitukseen, johon se tilattiin.

Yleinen harhaluulo on, että oikeudet tietokoneohjelmaan kuuluvat sille, joka on tilannut ja maksanut sen kehityksen, ja että tekijänoikeuslaki siirtäisi oikeudet tilaajalle automaattisesti. Laki ei sitä tee. Hiljaisen lisenssin sisältö jää epäselväksi, ja koska kyse on juuri siitä, mitä sopimukseen kannattaa kirjoittaa, 27 § ja 40 b § kannattaa lukea itse: ne vahvistavat tämän jaon.

Tiedostojen saaminen ei ole oikeuksien saamista

Toinen oletus, joka ei kestä tarkastelua, on se, että koodin saaminen ratkaisisi jotakin, mutta tekijänoikeuslain 27 § säätää, että kappaleen luovutukseen ei sisälly tekijänoikeuden luovutus. Käytännössä se merkitsee, että arkisto, jossa on koko lähdekoodi, pääsy repositorioon ja jopa täydellinen dokumentaatio ei ole sama asia kuin oikeus käyttää tätä koodia, muunnella sitä ja luovuttaa se toiselle kehittäjälle.

Se toimii myös toiseen suuntaan, ja tämä puoli tunnetaan huonommin, koska yritys on voinut saada taloudelliset oikeudet hyvin kirjoitetulla sopimuksella eikä silti ole saanut lähdekoodia, jos sopimukseen ei ollut kirjattu erillistä velvollisuutta luovuttaa se. Lupa ilman tiedostoa on yhtä käyttökelvoton kuin tiedosto ilman lupaa, joten sopimukseen tarvitaan molemmat, ja ne ovat kaksi itsenäistä kohtaa, ei yksi kohta, joka sisältäisi toisen itsestään.

Kun oikeudet luovutetaan oikein, laki vaatii tiettyä täsmällisyyttä, eikä se ole muodollisuus, koska tekijänoikeuslain 27 § sallii luovuttaa tekijänoikeuden kokonaan tai osittain ja sopimuksessa voidaan sopia sekä alueesta että kestosta, mutta Suomessa ei ole oletusta, jonka mukaan nimeämättä jäänyt alue tarkoittaisi vain sitä valtiota, jossa sopimus tehtiin. 28 § sen sijaan säätää, että luovutuksensaaja ei saa muuttaa teosta eikä luovuttaa oikeutta edelleen, ellei toisin ole sovittu. Yritykselle, joka toimii useassa maassa tai aikoo toimia, se on suora syy kirjoittaa alue ja kesto sopimukseen, ja yhden käyttötavan nimeäminen ei avaa muita.

On vielä yksi yllätys, joka odottaa yritystä, joka elää hiljaisella lisenssillä eikä ole koskaan kirjoittanut sitä. Suomen tekijänoikeuslaissa ei ole säännöstä, jonka mukaan määräajaton lisenssi voitaisiin irtisanoa kuuden kuukauden varoitusajalla ja jonka mukaan tästä oikeudesta luopuminen olisi tehoton. Yritys, jonka ainoa perusta järjestelmän käyttöön on kirjaamaton yhteisymmärrys, elää silti 28 §:n oletuksen varassa: muuntelua ja edelleenluovutusta ei ole, ellei niistä ole sovittu, eikä epäselvää hiljaista lisenssiä kannata jättää sen varaan.

Moraaliset oikeudet ja se, mitä ne eivät estä

Moraaliseen osaan kuuluu Suomessa tekijän nimi ja suoja teoksen muuttamista sekä sellaista yleisön saataviin saattamista vastaan, joka loukkaa tekijän kirjallista tai taiteellista arvoa tai omalaatuisuutta, ja se kaikki jää tekijälle, koska 27 §:n luovutus tapahtuu 3 §:n rajoituksin. Lakissa ei ole erillistä oikeutta peruuttaa teos käytöstä. Yritykselle, joka on tilannut järjestelmän, tämä kuulostaa aluksi uhkaavalta, koska syntyy vaikutelma, että entinen kehittäjä voisi jossain vaiheessa vaatia järjestelmän pysäyttämistä.

Käytännössä tavallinen ylläpito ei pysähdy siihen. Suomessa ei ole vuoden 2023 muutosta, joka poistaisi tietokoneohjelman tekijältä oikeuden kieltää muuntelu moraalisten oikeuksien nojalla: 3 § suojaa nimeä ja kunniaa, eikä se anna entiselle ohjelmoijalle vipua, jolla tavallinen ylläpito tai edelleenkehitys pysäytettäisiin, ellei muutos loukkaa 3 §:n suojaa. Entinen ohjelmoija ei siis voi 3 §:n nojalla keskeyttää tavallista ylläpitoa eikä uudelleenkirjoitusta, ja juuri se osa moraalisista oikeuksista olisi yritykselle vaarallinen.

Vuoden 2023 muutospaketissa — laissa 263/2023 — on sen sijaan toinen, yritykselle myönteinen säännös, joka kannattaa tuntea, koska muuten sen voi odottaa väärältä suunnalta. Säännökset asianmukaisesta ja oikeasuhtaisesta korvauksesta sekä tekijän oikeudesta saada tietoa teoksen käytöstä, jotka muissa teoslajeissa antavat tekijälle mahdollisuuden palata maksukysymykseen, eivät 27 §:n 3 momentin mukaan koske tietokoneohjelman tekijää, ja se merkitsee, että ohjelmoija, joka katsoo järjestelmän osoittautuneen arvokkaammaksi kuin osapuolet odottivat, ei voi tällä perusteella vaatia lisäkorvausta.

Jäljelle jää oikeus tulla nimetyksi tekijäksi ja suoja sellaista teoksen käyttöä vastaan, joka loukkaa kunniaa, ja se on huomattavasti pienempi riski, jonka kanssa voi elää. Tärkeää on vain olla sekoittamatta kahta asiaa: muuntelu moraalisena kysymyksenä ei 3 §:n kapean suojan takia ole tavallisen ylläpidon este, mutta muuntelu taloudellisena oikeutena vaatii yhä sen haltijan luvan, ja 28 §:n oletus on, että luovutuksensaaja ei saa muuttaa teosta, ellei toisin ole sovittu. Jos taloudellinen osa on jäänyt toimistolle, järjestelmän uudelleenkirjoitus tarvitsee yhä sen suostumuksen.

Mitä laki antaa myös ilman hyvää sopimusta

Silloinkin, kun yritys ei ole formalisoinut mitään, laki antaa joitakin keinoja, ja kannattaa tietää, mitkä niistä sopimus voi viedä ja mitkä ei. Tekijänoikeuslain 25 j §:n 1 momentti antaa sille, joka on laillisesti hankkinut tietokoneohjelman, oikeuden valmistaa ohjelmasta sellaiset kappaleet ja tehdä siihen sellaiset muutokset, jotka ovat tarpeen ohjelman käyttämiseksi aiottuun tarkoitukseen, myös virheiden korjaamiseksi, mutta tätä 1 momentin oikeutta sopimus voi rajoittaa, ja monet sopimukset myös rajoittavat.

Varmuuskappaleen valmistaminen on toinen tapaus, eikä sitä sopimus voi viedä, koska 25 j §:n 2 momentti antaa sille, jolla on oikeus käyttää tietokoneohjelmaa, oikeuden valmistaa ohjelmasta varmuuskappaleen, jos se on tarpeen ohjelman käytön kannalta, ja se vastaa direktiivin 2009/24/EY 5 artiklan 2 kohtaa. Direktiivin 8 artikla säätää lisäksi, että sopimusehdot, jotka ovat ristiriidassa 6 artiklan tai 5 artiklan 2 ja 3 kohdan poikkeusten kanssa, ovat mitättömiä.

Tässä kannattaa olla täsmällinen, koska ero on hieno ja sitä on helppo liioitella: Suomen laki ei jätä direktiivin 8 artiklaa dekompiloinnin kohdalla auki. 25 j §:n viimeinen momentti säätää, että sopimuksen ehto, jolla rajoitetaan 2–4 momentin mukaista käyttöä, on tehoton, ja 25 k §:n viimeinen momentti säätää saman yhteentoimivuutta koskevasta analysoinnista. Varmuuskappaletta ei siis voi sopimuksella kieltää, eikä dekompilointia eli ohjelman koodin kopioimista ja sen muodon kääntämistä yhteentoimivuutta varten voi sopimuksella kieltää.

Dekompilointi — lain 25 k §:ssä koodin kopioiminen ja sen muodon kääntäminen, direktiivin suomenkielisessä otsikossa analysointi — on sallittu kapeasti ja ehdoin: sen saa tehdä itsenäisesti luodun tietokoneohjelman yhteentoimivuuden saavuttamiseksi, jos tieto ei muuten ole saatavilla, sen tekee henkilö, jolla on laillisesti oikeus käyttää kappaletta, ja toimet rajoittuvat niihin osiin, jotka yhteentoimivuus vaatii. Saatua tietoa ei saa käyttää muihin tarkoituksiin eikä ilmaisumuodoltaan huomattavassa määrin samanlaisen ohjelman tekemiseen, ja tämä ulospääsy on hyödyllinen mutta kapea, eikä kukaan yritys halua, että se on ainoa.

Järjestelmässä on paljon koodia, joka ei ole koskaan sinun

Räätälöity järjestelmä ei lähes koskaan ole vain se koodi, jonka kehittäjä kirjoitti, koska suurin osa määrästä tulee kirjastoista ja ohjelmistokehyksestä, jotka olivat jo olemassa. Se koodi ei tule omaksesi koskaan eikä missään sopimuksessa, koska saat lisenssin sen tekijöiltä, ja tämä ero on tärkeä juuri silloin, kun joku lupaa luovuttaa kaikki oikeudet järjestelmään.

Sallivat lisenssit eivät aiheuta ongelmaa, koska ne vaativat vähän eivätkä rajoita sitä, miten valmista järjestelmää saa käyttää liiketoiminnassa. MIT-lisenssi sallii käyttämisen, kopioimisen, muuntelemisen, yhdistämisen, julkaisemisen, levittämisen ja myymisen, kunhan tekijänoikeusilmoitus ja itse lisenssi säilytetään, ja ohjelmisto luovutetaan sellaisena kuin se on, ilman takuita, kun taas Apache 2.0 -lisenssi lisää siihen nimenomaisen patenttilisenssin ja vaatii merkitsemään tehdyt muutokset. Molemmat sopivat suljettuun kaupalliseen järjestelmään, suurin osa nykyaikaisista ohjelmistokehyksistä on jompikumpi niistä, ja juuri siksi tämä osa järjestelmästä ei yleensä vaadi mitään neuvottelua.

Copyleft-lisenssit vaativat huomiota, ei paniikkia, ja juuri tässä kerrotaan useimmin puolitotuuksia, vaikka Free Software Foundation kirjoittaa GPL-kysymyssivullaan selvästi, että yrityksen, joka ajaa muunneltua GPL-ohjelmaa omalla verkkosivustollaan, ei tarvitse julkaista muunneltua lähdekoodia, koska copyleft-velvollisuus syntyy, kun kappaleita luovutetaan muille, ei kun ohjelmaa käytetään itsellä. Useiden kappaleiden valmistaminen ja käyttäminen yhden organisaation sisällä ei ole levittämistä, vaikka kappaleiden luovuttaminen toisille organisaatioille, myös urakoitsijoille käyttöön yrityksen ulkopuolella, jo on.

Poikkeus on Affero-lisenssi, ja juuri sen 13 § — verkkovuorovaikutuslauseke (AGPL §13) — on se, joka yllättää, koska jos muuntelet ohjelmaa ja muunneltu versio antaa käyttäjien olla siihen yhteydessä etäältä tietoverkon kautta, näille käyttäjille on tarjottava mahdollisuus saada vastaava lähdekoodi. Ehtoja on kaksi ja molemmat tarvitaan: muuntelu ja etäinen käyttäjävuorovaikutus, joten ei ole oikein sanoa, että mikä tahansa Affero-lisenssin käyttö vaatisi lähdekoodin julkaisemista, eikä ole oikein sanoa, että yksi tällainen kirjasto alistaisi automaattisesti koko järjestelmän, koska se riippuu siitä, miten komponentit on kytketty.

Lähdekoodin escrow kolmannelle ja mitä se oikeasti antaa

Lähdekoodin escrow on kolmen osapuolen järjestely, jossa kehittäjä luovuttaa lähdekoodin neutraalille säilyttäjälle, mutta säilyttäjä luovuttaa sen tilaajalle vasta, kun sopimuksessa kuvattu tilanne toteutuu, ja tyypillisiä tilanteita ovat konkurssi, toiminnan päättyminen tai olennainen ylläpitovelvoitteen laiminlyönti varoituksen jälkeen. Suomessa ei ole lakia, joka näitä tilanteita määrittäisi tai edes luettelisi, joten kaikki, mikä tässä toimii, on se, mitä osapuolet itse ovat kirjoittaneet, ja siksi escrow-sopimus on luettava yhtä tarkasti kuin itse kehityssopimus.

Escrow antaa juuri sen, mitä on talletettu, ja vasta sitten, kun kuvattu tilanne toteutuu, mutta se ei itsessään luovuta tekijänoikeutta, koska 27 §:n mukaan kappaleen luovutukseen ei sisälly tekijänoikeuden luovutus, eikä se opeta järjestelmää käyttämään. NCC Group, joka on myynyt tätä palvelua vuosikymmeniä, myöntää omissa aineistoissaan itse: lähdekoodin oleminen säilytyksessä on yksi asia, taito kääntää se on toinen, ja juuri siksi sama yritys myy myös talletetun sisällön tarkistusta. Se on intressitahon arvio, mutta se on tunnustus oman ydinpalvelun heikosta kohdasta, ja siksi se on käyttökelpoinen.

Nykyaikaisilla järjestelmillä on myös toinen puute, joka ei liity juridiseen puoleen lainkaan: jos järjestelmä toimii palveluna kehittäjän infrastruktuurilla, lähdekoodi ilman ajoympäristöä, konfiguraatiota ja dataa ratkaisee pienimmän osan ongelmasta, koska saajalle jää arkisto, ei toimiva järjestelmä. Käytännössä tätä puutetta paikataan täydentämällä escrow-järjestelyä sopimuksella siitä, kuka ottaa ympäristön haltuunsa ja mitä tapahtuu, jos hosting-laskut jäävät maksamatta, ja juuri nämä kohdat puuttuvat escrow-sopimusten vakioehdoista yleensä.

Konkurssi ei ole tämän kolmen osapuolen sopimuksen ulkopuolella vain siksi, että tekijänoikeuslaissa ei ole erillistä pykälää. Käytännön johtopäätös ei ole luopua escrowsta, vaan olla pitämättä sitä kirjallisen oikeuksien luovutuksen ja lähdekoodin säännöllisen luovutuksen korvikkeena.

Missä repositorio on ja missä data on

Kysymys siitä, missä koodi ja data sijaitsevat, ratkaisee enemmän kuin kysymys siitä, kenelle ne kuuluvat, koska oikeudet ilman pääsyä ovat hidas ongelma. GitHubin dokumentaatio kuvaa selvästi, että organisaatio on jaettu tili, jolle repositoriot kuuluvat, että organisaatioon ei kirjauduta, koska ihmiset kirjautuvat henkilökohtaisilla tileillä, ja että organisaation omistajilla on aina pääsy kaikkiin repositorioihin; repositorio voi kuulua henkilökohtaiselle tilille tai organisaatiolle, ja tämä valinta on tärkeämpi kuin miltä näyttää.

Jos repositorio kuuluu kehittäjän henkilökohtaiselle tilille, asiakkaan pääsy on vain collaborator-oikeus, jonka tilin omistaja voi perua milloin tahansa, ja projektista lähtiessään hän vie mukanaan myös itse osoitteen. Jos repositorio kuuluu asiakkaan organisaatiolle, johon kehittäjä on kutsuttu jäseneksi, lähteminen tarkoittaa yhden käyttöoikeuden poistamista eikä muuta, ja se on yksi harvoja asioita tässä artikkelissa, jotka voi korjata yhdessä päivässä ja ilman juristia.

Data on erillinen kysymys, eikä siinä ole enää kyse tekijänoikeudesta: jos kehittäjä käsittelee henkilötietoja puolestasi, eli ajaa tuotantoympäristöä, pääsee asiakkaiden tai työntekijöiden tietoihin tai tekee varmuuskopioita, sinä olet rekisterinpitäjä ja kehittäjä on henkilötietojen käsittelijä yleisen tietosuoja-asetuksen tarkoittamassa mielessä. Asetuksen 28 artikla vaatii kirjallisen sopimuksen, jossa on tietyt kohdat: käsittelyn kohde ja kesto, luonne ja tarkoitus, tietotyypit ja rekisteröityjen ryhmät sekä rekisterinpitäjän oikeudet ja velvollisuudet.

Puhdas koodin kirjoittaminen ilman pääsyä henkilötietoihin ei käynnistä 28 artiklaa, joten jokainen kehityssopimus ei tarvitse sopimusta henkilötietojen käsittelystä. Raja on yksinkertainen ja tarkistettavissa: jos kehittäjä näkee oikeita asiakastietoja, sopimus tarvitaan, mutta jos kehittäjä työskentelee vain testidatalla eikä näe tuotantoympäristöä, sitä ei tarvita, ja se itse on argumentti sen puolesta, että testiympäristö on erillinen.

Mitä saat ja mitä samalla otat vastuullesi

Tämän artikkelin logiikka on tähän asti ollut yksipuolinen, joten on reilua sanoa myös toinen puoli: täysi määräysvalta räätälöityyn järjestelmään ei ole vain etu, vaan myös velvoitteiden joukko, joka ei katoa. Valmiille ohjelmistolle ylläpidon, tietoturvakorjaukset ja yhteensopivuuden uusiin ympäristöihin hoitaa valmistaja, ja se sisältyy tilausmaksuun, kun taas räätälöidylle järjestelmälle kaiken sen hoitaa omistaja, eli sinä, ja se on suora kulu, joka ilmestyy joka vuosi riippumatta siitä, muuttuuko järjestelmässä mitään.

Toinen, minkä otat vastuullesi, on järjestelmän vanheneminen, joka kertyy hiljaa eikä näy millään tavalla, ennen kuin joku sitä etsii. Järjestelmä nojaa kielen ja ohjelmistokehyksen versioihin, joille valmistajat asettavat tukiajat, ja näiden aikojen päätyttyä uusia haavoittuvuuksia ei enää paikata, vaikka järjestelmä jatkaa toimimistaan täsmälleen entiseen tapaan eikä mikään näyttö siitä varoita. Se ei ole kielto ajaa vanhentunutta järjestelmää, mutta se on hetki, jossa riskin ottaa omistaja, ja konkreettiset päivämäärät PHP:n ja Laravelin kohdalla olemme koonneet artikkeliin siitä, mitä PHP:n ja Laravelin valinta merkitsee, emmekä toista niitä tässä.

Kolmas on markkina, ja valmiille alustalle asiantuntijan löytää suhteellisen helposti, koska heitä koulutetaan ja heitä on useita, kun taas räätälöidyn järjestelmän tuntevat vain ne, jotka sen rakensivat, ja uudelle kehittäjälle on varattava aikaa tutustumiseen, ennen kuin hän voi muuttaa mitään turvallisesti. Se ei tarkoita, että haltuunotto olisi mahdotonta, mutta se tarkoittaa, että se maksaa, ja tämä kulu ilmestyy juuri sillä hetkellä, kun suhde edelliseen kehittäjään on jo päättynyt.

Juuri siksi kysymys siitä, mikä kuuluu sinulle, ei ole juridinen muodollisuus, vaan kysymys siitä, kuinka kalliiksi seuraava valinta tulee. Yritys, jolla on kirjallinen luovutus, lähdekoodi omassa repositoriossaan ja luettelo käytetyistä komponenteista, voi etsiä uutta kehittäjää viikossa, kun taas yritys ilman kaikkea tätä selvittää ensin, mitä sille ylipäätään saa tehdä, ja vasta sitten alkaa etsiä, ja se on ero sen välillä, neuvotellaanko asemasta vai pakosta.

Mitä sopimukseen kannattaa kirjoittaa, kun se vielä onnistuu

Kaikki edelliset jaksot johtavat pieneen kohtien joukkoon, joka kannattaa kirjoittaa sopimukseen ennen työn alkua, koska luovutuksen jälkeen neuvotteluasema on paljon heikompi. Ensimmäinen on taloudellisten oikeuksien luovutus kirjallisesti, nimeämällä, mitkä oikeudet siirtyvät, millä alueella ja mihin saakka, koska 28 §:n oletus on, että luovutuksensaaja ei saa muuttaa teosta eikä luovuttaa oikeutta edelleen, ellei toisin ole sovittu, eikä laki täytä nimeämättä jäänyttä aluetta sen valtion oletuksella, jossa sopimus tehtiin. Toinen on vakuutus siitä, että toimisto on saanut nämä oikeudet omilta työntekijöiltään ja alihankkijoiltaan, koska ilman tätä askelta itse luovutus voi olla tyhjä.

Kolmas on lähdekoodin ja kaiken sen kääntämiseen tarvittavan säännöllinen luovutus, ei kertaluovutus hankkeen lopussa, ja neljäs on se, että repositorio on organisaatiotililläsi jo ensimmäisestä päivästä. Viides on avoimen lähdekoodin komponenttien luettelo niiden lisensseineen, koska ilman tätä luetteloa kukaan ei myöhemmin tiedä, mitä järjestelmässä on ja millä ehdoin; kuudes on sopimus henkilötietojen käsittelystä, jos kehittäjä näkee oikeita tietoja, ja seitsemäs on sopimus siitä, mitä ympäristöille, avaimille ja käyttöoikeuksille tapahtuu yhteistyön päättyessä.

Yksikään näistä kohdista ei vaadi pitkää tekstiä, yksikään niistä ei ole ristiriidassa hyvän yhteistyön kanssa, eikä yksikään rehellinen kehittäjä vastusta niitä, koska ne kirjaavat juuri sen, mitä molemmat osapuolet muutenkin ajattelevat. Ainoa, minkä ne muuttavat, on se, että sopimus ei enää riipu siitä, työskentelevätkö kyseiset ihmiset kolmen vuoden kuluttua yhä samassa yrityksessä ja muistaako joku, mitä silloin sanottiin suullisesti. Näitä kohtia kannattaa vaatia miltä tahansa kehittäjältä, myös meiltä, ja kirjoittaa ne sopimukseen ennen työn alkua. Räätälöidyn ohjelmistokehityksen sivumme lupaa tällä hetkellä luovuttaa lähdekoodin, dokumentaation ja infrastruktuurin konfiguraation työn lopussa, ja juuri siksi tämän luettelon kolmas kohta, eli säännöllinen luovutus työn kuluessa, kannattaa sopia erikseen eikä olettaa, että se on itsestään selvää. Jos haluat, että katsomme jo olemassa olevaa sopimusta, ota yhteyttä.