Suoja aika ja IT-ala, sekä tekijänoikeustyöryhmän kuulumisia

En ole hetkeen kirjotellut IPR:stä, joten tässä vähän tekijänoikeustyöryhmän kuulumisia. Maaliskuussa esitettiin kommentteja vihreiden poliittiseen ohjelmaan. Kommentit piti tehdä aika kiireellä, joten lopulta pidettiin vaan ärsyttävä äänestysrumba kaikenlaisista sanamuotonyansseista. Siitä jäi lähinnä paskan maku suuhun, mutta itse ohjelmasta tuli lopulta aika hyvä. Ei mitenkään erityisen spesifi, mutta se ei kai ollut tarkoituskaan. Omaa kynänjälkeäni tunnistan sieltä yhden lauseen: ”Sananvapaus ja yksityisyyden suoja on turvattava kaikille myös Internetissä”, muitakin hiukan tutun oloisia kohtia näkyi kyllä.

Nyt työryhmän varsinainen työ jatkuu taas tavoitteena rakentaa linjapaperi, tällä kertaa vähän paremmalla ajalla kuin tuon ohjelman kommentointi. Tänään olisi kokous, jossa Ville Oksanen (Effi, Turre legal, jne) alustaa tekijänoikeuksien suoja-ajoista. En valitettavasti pääse itse paikalle, joten kirjoitin allaolevan hahmotelman tekijänoikeuksien roolista IT-alalla muille työryhmäläisille, joista enemmistö on tutumpi kulttuurialan kanssa (koen olevani jonkinlaisessa virallisen nörtin roolissa, joten edustan sitten sitä parhaani mukaan). Tässä siis hiukan pohdintaa suoja-ajoista IT-alan näkökulmasta, ja vain siitä.

Tietokoneohjelmat ovat käytännössä aina tekijänoikeuden suojaamia. En tiedä oikeuden päätöksiä teoskynnyksestä, mutta käytännön oletuksena alalla on, että jokainen koodirivi on suojattu. Tekijänoikeuksiin perustuvan ohjelmistobisneksen arvo on Suomessa laskutavasta riippuen puolesta miljardista runsaaseen kahteen miljardiin euroa. Tämä tekee siitä rahassa mitattuna saman kokoluokan alan kuin musiikkiala.

Tekijänoikeuden merkitykseen IT-alalla liittyy muutama erityispiirre, joita koitan avata alla.

Lähes kaikilla mainittavilla ohjelmalla on useita tekijöitä. Pienemmillä ohjelmilla 3-10 hengen tiimi, suurimmilla jopa kymmeniä tuhansia tekijöitä. Lähinnä pienillä harrasteprojekteilla ja oppilastöillä voi olla yksi tekijä. Kaupallisessa tuotannossa tekijöiden nimiä ei yleensä kerrota (poikkeuksena avoimen koodin projektit, s.o. open source). Alan käytäntönä on, että kaikki tekijänoikeudet siirtyvät aina työnantajalle osana työsuhdetta siinä laajuudessa kuin laki vain suinkin sallii. Usein myös yritykset muodostavat alihankintaketjun, niin että tekijänoikeudet siirtyvät saman tien jopa 6 kertaa eri yritykselle sopimusten perusteella.

Tekijän kuolinvuoteen sidottu tekijänoikeuden suoja-aika on IT-alalla ongelmallinen, koska tekijöitä on yllä kuvatun seurauksena yleensä mahdoton selvittää. Teoksen julkaisuhetki sen sijaan on yleensä tiedossa, joten siihen sidottu suoja-aika toimii paremmin.

Toinen IT:n erityispiirre on, että teokset vanhenevat nopeasti, ja niitä päivitetään koko ajan. Vuoden vanha peli on vanha, ja 5 vuotta vanha esihistoriaa. Toimisto-ohjelmatkin vanhenevat viidessä vuodessa, ja sitä vanhempia ohjelmajulkaisuja on hyvin vaikea löytää kuluttajille myynnissä.

Ohjelmien ydin on toki pitkäikäisempi. Esimerkiksi nykyiset windowsit perustuvat Windows NT:hen, joka julkaistiin 1993, mutta ei kukaan enää halua tuota versiota käyttää. Sen jälkeen on tullut 14 uutta pääversiota, ainakin 32 service pack -päivitystä ja satoja ellei tuhansia pieniä korjauspäivityksiä.

Suosituista ohjelmista tuleekin yleensä uusia päivitysversioita muutaman kuukauden tai vuoden välein, ja pieniä korjauspäivityksiä jopa viikottain. Jos ohjelmasta ei tule uusia versioita, se johtuu luultavasti siitä että kukaan ei käytä sitä.

Yli 10 vuotta vanhoja ohjelmajulkaisuja käytetään lähinnä historiaharrastuksena: erityisesti vanhoilla peleillä, mutta myös vanhoilla käyttöjärjestelmillä on omat harrastajansa, jotka rakentavat emulaattoreita ja näkevät suurta vaivaa kyetäkseen edes ajamaan niitä.

Julkisten laitosten ja suurten yritysten tietojärjestelmät ovat toisinaan selvästi vanhempia, mutta niitäkin on varmasti päivitetty ajan myötä, ehkä muutaman vuoden välein. jos jossain on käytössä yli 10 vuotta vanha järjestelmä, jota ei ole päivitetty, se johtuu luultavasti siitä, että päivitystä ei ole saatavilla, koska tekijänoikeudet omistava yhtiö on mennyt nurin tai muutoin lopettanut tuotteen.

IT-alalla siis järkevä suoja-aika olisi selvästi nykyistä lyhyempi. Yli 5 vuotta vanhojen ohjelmajulkaisujen kaupallinen merkitys on hyvin lähellä nollaa, ja esimerkiksi 15 vuoden suoja-aika vastaa käytännössä jo ikuista. Alkuperäiset tekijät eivät juuri koskaan saa tekijänoikeustuloja, vaan heille maksetaan palkan muodossa. Heidän vanhuuden turvaansa suoja-aika vaikuttaa siis vain, jos se tekee ohjelmistobisneksen ylipäätään kannattamattomaksi.

Tiivistetysti:

  • IT-alalla tekijän kuolemaan sidottu suoja-aika ei toimi.
  • Suoja-ajan kestona esimerkiksi 15 vuotta ei haittaisi tekijöitä tai teoksiin perustuvaa nykyistä liiketoimintaa käytännössä lainkaan.
  • Jos erilaisille teoksille harkitaan eri mittaisia suoja-aikoja, tietokoneohjelmille kannattaa harkita lyhyempiä aikoja kuin esim. kulttuurituotteille.

Sivumennen sanoen, se, että esim. Piraattipuolue kannattaa suunnilleen tämän pituisia suoja-aikoja sidottuna juuri teoksen julkaisuun ei liene sattumaa. Heistä useimmille teoksen prototyyppi lienee tietokoneohjelma.

Hyvä tiimi

Kooderien tuottavuuserot ovat valtavia. Hyvä kooderi käyttää tehtävään viidesosan siitä ajasta joka keskiverrolta kuluu, ja lopputulos on silti monin tavoin parempi. Sama pätee moniin muihinkin ohjelmistotuotannon osiin: arkkitehtuurisuunnitteluun, käyttökokemussuunnitteluun ja myös laadunvarmistukseen. Tämä erottaa kaikki nämä ammatit vaikkapa heinän niittämisestä tai T-fordien kokoamisesta liukuhihnalla.

Ohjelmistojen tekeminen on lähes aina tiimityötä. Tyypillisesti ohjelmistokehitystä tehdään 3-10 hengen tiimeissä (*), joissa on yksi projektipäällikkö tai vastaava, osa jäsenistä on spesialisteja, esimerkiksi testaajia, käyttökokemussuunnittelijoita tai arkkitehtejä, ja loput tekevät koodia. Spesialistit saattaa olla hallinnollisesti eroteltu muista, mutta projekti tuo heidät yleensä silti samaan tiimiin kooderien kanssa.

Oikeastaan pitäisikin siis puhua kehitystiimien eroista. Hyvä tiimi tuottaa paremmin tarkoitukseen sopivan ja luotettavammin toimivan ohjelman nopeammin kuin keskiverto tiimi.

Mikä sitten tekee tiimistä hyvän? Sekö, että se koostuu hyvistä tyypeistä?

Ei välttämättä, eikä ainakaan yksinomaan.

Ihan yksilöiden taitotasosta riippumatta, hyvän tiimin pitää toimia yhteen. Se myös tarvitsee kelvolliset tilat ja hyvät työkalut. Joel Spolsky tiivistää tarvittavat työkalut ja työ-olot 12 kohdan check-listiinsä. Ainakin tämän verran ympäristöllä on väliä.

Parikin astetta pidemmälle ajatuksen vie Alan G. Carter luentosarjassaan Programmers’ stone. Jos lukee hyväntahtoisesti ja ohittaa pseudopsykologian suuntaan osoittavat vihjeet (**), Carterin perusidea on, että hyvän tiimin erottaa huonosta se, että jäsenet löytävät oikeanlaisen keskittymisen ja yhteisymmärryksen, ja sitä kautta itse asiassa ymmärtävät mitä ovat tekemässä tavalla, joka on sitä kokemattomalle lähes käsittämätön.

Tälläisen ”Kullatun tiimin” luomiseen tarvitaan tietysti Joelinkin käisttelemät järkevät tavoitteet, hyvät työkalut, rauhalliset työtilat, tiimin pysyvyys, jne, mutta ennen kaikkea mahdollisuus ylläpitää riittävän matalaa stressitasoa.

Carterin mukaan lähes kuka tahansa ohjelmoija voisi olla kymmenen kertaa normaalia tuottavampi, mutta tätä harvoin tapahtuu, koska normaalissa softafirmassa ei ole yksinkertaisesti mahdollista ylläpitää matalaa stressitasoa. Ainakaan kokonaisen tiimin. Lukekaa koko tarina jos haluatte kattavan selityksen.

Itse uskon, että Carter on oikeilla jäljillä, vaikka välillä menee penkan puolelle. Kaikista tuskin voi ikinä tulla super-ohjelmoijia, mutta hyvä ohjelmointikyky ei ole geneettinen ominaisuus, vaan jotakin, mitä voi oppia. Ei helposti, vaan vaikeasti. Eikä yksikseen, vaan oikeassa seurassa.

(*) Vapaissa ohjelmistoissa työn organisointi toimii aivan eri tavalla, enkä puhu siitä tässä.

(**) Myöhemmin Carter on laajentanut repertuaariaan vähän joka suuntaan jonkinlaiseksi teknohippi-suurmestariksi.

Onnelliset ohjelmistot

Mma Ramotswe-dekkarissa Mma:n kihlattu, automekaanikko ja ehkä Botswanan paras mies J.L.B Matekoni toteaa ”Vain ihminen joka todella ymmärsi koneita, pystyi ajattelemaan moottorin onnellisuutta; sellaista näkemystä mekaanisesti lahjattomilla ei yksinkertaisesti ollut.

Ymmärrän idean moottorin onnellisuudesta, mutta entä mikä tekee softan onnelliseksi? Ehkä softa on moottoria pari astetta abstraktimpana vaikeampi ymmärtää; ehkä siitä on liian kauan kun olen koodannut mitään kunnollista. Tai sitten en vaan ole ollenkaan riittävän lahjakas mekaanisesti (erinomaisen nerokas tapa määritellä teknisluonteinen lahjakkuus empatiana).

Oli miten oli, kysymys softan onnellisuudesta ei ole minulle itsestäänselvä. Niin kuin sen ehkä pitäisi olla. Olen saattanut tehdä urallani suurestakin joukosta ohjelmistoja onnettomia ihan vain ymmärtämättömyyttäni!

Vähän pinnistelemällä keksin muutaman ajatuksen:
* Bugittomuus (tai siis vähäbugisuus) tekee softan onnelliseksi. Kukapa nyt haluaisi kantaa ötököitä sisuksissaan.
* Riittävä välimuisti jossa voi rennosti lepuuttaa sivujaan kutsujen välillä. Ehkä myös nopea prosessori, ettei tarvitse hikoilla suorituksessa liian kauaa vaan pääsee takaisin idlaamaan (tästä kiitos Teemulle, joka ei ikinä kommentoi tänne).
* Kaunis ja siisti arkkitehtuuri. Jos softan arkkitehtuuri on silkkaa spagettia, juuttuu syöte johonkin suolen mutkaan, eikä etene siististi tulosteeksi. Ikävältähän semmoinen tuntuu ja aiheuttaa kaikenlaista ummetusta ja tuskaista räpiköintiä.

Löytyykö lukijoiden joukosta teknisesti lahjakkaita? Mikä tekee ohjelmiston onnelliseksi?