KIT Ctl310ipr, 2004k:
Tekijänoikeudet

5. luento: Immateriaalioikeudet ja tietokoneohjelmat

Tietokoneohjelmien immateriaalioikeudellinen suoja

Tekijänoikeus

Tekijänoikeus on yleensä tärkein tietokoneohjelmaa suojaavista immateriaalioikeuksista. Lähes kaikki tietokoneohjelmat ovat tekijänoikeuden suojaamia teoksia, aivan triviaaleimpia koodinpätkiä lukuunottamatta. (Toisaalta näennäisesti triviaalikin ohjelma voi ylittää teoskynnyksen tai ainakin olla hyvin lähellä sitä, vrt. GNU Hello...)

Tekijänoikeus suojaa yhtä lailla tietokoneohjelman ohjelmointikielistä lähdekoodia kuin sen konekielistä objektikoodia. Välttämättähän ohjelmasta ei perinteistä, ihmisluettavaa lähdekoodia edes ole olemassa, mikäli ohjelma on luotu esim. jollain graafisella sovelluskehittimellä. Sen sijaan tekijänoikeus ei suojaa ohjelman käyttämiä teknisiä rajapintoja (mahdollisesti näiden määrittelydokumentteja kylläkin), vaan vastaavien rakentamiseksihan on myös reverse engineering poikkeuksetta sallittua. Tekijänoikeus ei myöskään suojaa ohjelman käyttäjärajapintaa kokonaisuutena (kuten valikoiden tai ohjelmaikkunan rakenteen tasolla). USA:ssa kokeiltiin toisenlaista linjaa jonkin aikaa 1980- ja 1990-lukujen taitteessa (ns. look and feel -suoja), mutta tästä luovuttiin melko pian, mikä ainakin käyttöliittymien standardointia ja sen etuja ajatellen olikin järkevää. Käyttöliittymän yksittäiset elementit (kuten ikonit tai opastustekstit) voivat taas olla tekijänoikeudenkin suojaamia.

Patentti

Ohjelmistopatentit ovat olleet viime aikojen kuuma puheenaihe, viimeisimpänä PRH:n päätös käsitellä myös tietokoneohjelmia koskevia tuotepatentteja EPO:n käytännön mukaisesti, vaikkei patenttilaki tätä varsinaisesti sallikaan. Mikään aivan uusi ilmiö ne eivät kuitenkaan ole (Suomessakaan), tähän asti tietokoneohjelma on vain pitänyt patentoida menetelmänä eikä tuotteena, siis tapana ratkaista jokin tekninen ongelma käyttämällä mm. yleiskäyttöistä tietokonetta, joka suorittaa määrätynlaista ohjelmaa.

Kieliteknologia-alan kannalta tuossa ehkä tärkein avainsana on "tekninen". EPO on nimittäin käsitellyt useitä kieliteknologisia ohjelmistopatenttihakemusta, joille ei ole myönnetty patenttia, syynä teknisen tehon puuttuminen. Nämä keksinnöt siis EPO:n mielestä ratkaisevat lingvistisen ongelman ("menetelmä älyllistä toimintaa varten"), ei teknistä ongelmaa:

Toisaalta nämä keksinnöt ratkaisevat (myös) teknisen ongelman ja olivat siksi patentoitavissa:

Ohjelmistopatentit ovat lähteneet USA:sta, jossa ne nykyään ovat jo jokseenkin arkipäivää, ja varmasti niiden merkitys kasvaa Euroopassakin. Samaa merkitystä kuin niillä on muilla tekniikan aloilla ne tuskin kuitenkaan saavuttavat, onhan tietokoneohjelmilla turvanaan (muista tekniikan aloista poiketen) myös tekijänoikeus. Lisäksi tekniikan kehitysasteesta johtuen tietokoneohjelmien osalta innovaatiotahti voi olla sitä luokkaa, että keksintö, jolle patenttia haetaan, on jo vanhentunut, kun patentti lopulta vuosien kuluttua myönnetään. Patentit ovat ongelmallisia myös käytännön työssä, sillä patentoiduista keksinnöistä selvillä pysyminen ja niiden huomioiminen omassa ohjelmassa voi muodostua erittäin vaikeaksi. Samanlaisia ongelmia tullee myös alaa verraten huonosti tunteville rekisteriviranomaisille, osittain samasta syystä, osittain myös siksi, ettei tunnettu tekniikka ole valtaosin ollut ainakin aiemmin patentoitua kuten muilla aloilla. Tästä ongelmasta kertovat myös huomiota herättäneet mm. hyperlinkin ja elektronisen kaupankäynnin patentit.

Muut teollisoikeudet

Ohjelmistotuotteen nimi (tai siinä esiintyvä ikoni tai valmistajan logo tai...) voi olla tavaramerkki. Tämä ei suojaa itse ohjelmistoa, vaan vain sen nimen käyttöä markkinoinnissa. Edes ohjelman nimen käyttöäkään ei tällä voi kokonaan estää, sillä sitä voi tämän estämättä edelleen käyttää esimerkiksi vertailevassa mainonnassa tai kerrottaessa tuotteen yhteensopivuudesta. Se, kannattaako tavaramerkki rekisteröidä, riippuu yleensä tavaramerkin arvosta (ja tietenkin rekisteröitävyydestä). Massamarkkinoille tarkoitetun tuotteen nimen arvo voi olla suurikin, toisaalta tällainen nimi on helpompi todeta vakiintuneeksi. Komponenttitoimittajalle taas tärkeämpää on usein toimittajan oma nimi, jolle saattaakin kannattaa hankkia lisäsuojaa rekisteröimällä se myös tavaramerkiksi. Vastaavasti komponenttitoimittajan tapauksessa saattaa tuottaa vaikeuksia saada osoitettua merkki vakiinnutetuksi ja tätä varten määritellä se (usein hyvinkin kapea eikä välttämättä juuri lainkaan suomalainen) asiakassegmentti, jolle merkin pitäisi olla tunnettu ollakseen tavaramerkki. Tämän estämättä ohjelmistoyritykselle ei ole mitään ihmeempää haittaakaan TM-merkkien kylvämisestä kaikkialle siinä toivossa, että kyseinen merkki tulisi vakiintuneeksi, tietenkin vain kunhan tällä ei loukata kenenkään muun tavaramerkkiä.

Mallisuoja suojaa tavaran tai sen koristeen ulkomuotoa. Tavaralla ymmärretään tässä fyysistä esinettä. Tästä johtuen ainakaan tämän kirjoittajan mielestä mallisuoja ei voisi soveltua tietokoneohjelman kuvaruudulla näkyvään ulkomuotoon, kuten ikoneihin tai käyttöliittymään yleensäkään, sen sijaan ohjelman pakkaukseen tai asennusmediaan kylläkin. Aivan ongelmaton tämä tulkinta ei kuitenkaan ole, saattaisihan olla mahdollista suojata esimerkiksi myös ohjelman pakkauksessa näkyvä ikoni pakkauksen osana, tätä saattaisi sitten olla mahdollista loukata myös käyttämällä kyseistä ikonia vain ohjelmassa. Käytännössä mallisuojaa ei ole sovellettu tietokoneohjelmiin (juuri?) lainkaan.

Hyödyllisyysmallioikeutta ei voi saada tietokoneohjelmaan sellaisenaan. Toisaalta rajoitus on samanlainen kuin patentillakin, joten periaatteessa edellä patentista kirjoitettu pätee tähänkin. Käytännössä patentin kaltaisia kehityspaineita ei kuitenkaan ole ollut hyödyllisyysmallioikeuden suhteen, mahdollisesti instituution rajoitetun alueellisen levinneisyyden vuoksi.

Tietokoneohjelma voi olla myös piirimallisuojan kohteena, mikäli se toimitetaan valottamalla valmistetulla (kontra xPROM-piirit) integroidulla piirillä, kuten esimerkiksi mikroprosessorin käskykanta.

Immateriaalioikeudellisen suojan lisäksi (tai sen puuttuessa) on tietokoneohjelma (tai tietokanta) mahdollista suojata myös salassapitosopimuksilla (non-disclosure agreement, NDA). Tällöin ohjelman kappaleita ja käyttöoikeutta luovutetaan vain sopimuksen mukaisesti. Tällaisessa sopimuksessa määrätään, mihin ja miten ohjelmaa tai siitä (etenkin lähdekoodimuodossa) saatuja tietoja saa käyttää, sekä seuraamukset (sopimussakko) tämän rikkomisesta. NDA tulee yleensä eteen myös ohjelmistoalan työsopimusta tehtäessä. Tällainen sopimus kannattaa toisaalta laatia tarkasti (riittävän suojan saamiseksi), toisaalta lukea tarkasti, että tietää, mihin sitoutuu (kohtuuttomia ehtoja voidaan tosin sovitella, osa voi jopa kumoutua pakottavan lainsäädännön nojalla).

Tietokoneohjelmat ja sopimukset

Tietokoneohjelmia ei yleensä myydä samassa merkityksessä kuin fyysisiä esineitä. Ostaja ei siis ostaessaan saa tietokoneohjelmaa kokonaisuudessaan, vaan sen teoskappaleen ja oikeuden käyttää tätä käyttöehto- eli lisenssisopimuksessa määrätyllä tavalla. Toki tietokoneohjelman myynti kokonaisuudessaan eli "kaikkien" oikeuksien (pl. erikseen luettelemattomat moraaliset oikeudet, joiden merkitys alalla toki on muutenkin olematon) pysyvä ja yksinomainen luovuttaminenkin on mahdollista, muttei järin yleistä.

Jokaisen tietokoneohjelman käyttö perustuu siis tavalla tai toisella lisenssisopimukseen (pl. tietysti omatekoiset ja laittomat ohjelmat). Tämän vuoksi sopimukset ja niiden ehdot ovatkin huomattavasti keskeisemmässä asemassa kuin tekijänoikeudessa yleensä.

Tässä ei voida käsitellä tietokoneohjelmia koskevia sopimuksia kuin pintapuolisesti. Käytännön tietoa tarvitsevan kannattakin perehtyä alan kirjallisuuteen, jossa hyvän (käytännönläheisen) johdatuksen tarjoaa Takki: IT-sopimukset - käytännön käsikirja.

Vakioehdot

Vaikkei yritys myisikään kutakin ohjelmaansa kuin yksittäisiä kappaleita, niistä ei yleensä ole tarpeen kirjoittaa jokaisesta uutta sopimusta alusta alkaen. (Hyllytavarana myytävissä ohjelmistoissa sopimukset ovat tietenkin käytännön pakosta aina samanlaisia, näistä hiukan lisää jäljempänä.) Tämän vuoksi alalla onkin varsin yleisenä käytäntönä kirjoittaa sopimuksesta toiseen samanlaisina toistuvat osat erikseen ja kutakin toimitusta koskevat osat erikseen. Käytännössä varsinaisessa sopimuksessa ovat vain yleiset ehdot, ja itse kaupan kohde, kauppahinta ym. määritellään sopimuksen liitteissä ("Exhibit A, B" jne.).

Toimittajalla saattaa olla täysin omat vakioehtonsa, tai voidaan käyttää alalla yleisesti noudatettavia vakioehtoja, Suomen sisällä etenkin Keskuskauppakamarin, Tietotekniikan liiton ym. julkaisemia IT2000-sopimusehtoja (maksulliset, kopio kurssikansiossa). IT2000-ehdot sisältävät yleisen osan (YSE), kunkin sopimuksen lajin mukaan valittavat vakioerikoisehdot laite- (ELT), valmisohjelmisto- (EVT) ja asiakaskohtaisen ohjelmiston toimituksia (EAT), huolto- (ELH), ylläpito- (EOY) ja konsultointipalveluita (EAP) sekä pientoimituksia (PTE) varten, sekä kutakin sopimusta varten erikseen täytettävän osan. IT2000-ehdot tarjoavat käytännöllisen pakettiratkaisun, jossa varmasti on huomioitu yleisimmät mahdollisesti esiin tulevat sudenkuopat.

Myös ostajalla saattaa olla omat vakioehtonsa, tärkeänä esimerkkinä valtion tietotekniikkahankintojen yleiset sopimusehdot (VYSE 1998). Mikäli kumpikin osapuoli esittää sopimusta tehtäessä omat vakioehtonsa, voimaan jäävät näiden ollessa keskenään ristiriidassa viimeksi esitetyt ehdot, mikäli toinen osapuoli on tämän jälkeen sopimuksen hyväksynyt (esim. toimittamalla ohjelmiston tai maksamalla kauppasumman).

Toimittajan kannalta

Asiakaskohtaista järjestelmää etenkin projektiluontoisesti toimitettaessa erittäin tärkeä osa sopimusta on itse toimitettavan ohjelman määrittely (eli speksi). Aiemmin kehitetyn, jo sopimushetkellä valmiin ohjelmanhan voi antaa testattavaksi ennen sopimuksen tekemistä, jolloin ostaja voi joko ottaa tai jättää. Tilanne on toinen, kun sopimushetkellä ohjelmasta on olemassa vain speksi ja jotain sekavia ideoita, joiden mukainen ohjelma sitten pitäisi ajallaan toimittaa asiakkaalle, että tältä saisi lopulta rahaakin. Ohjelmasta olisikin syytä olla jo tässä vaiheessa mahdollisimman selkeä kuva, sekä ostajan toiveiden ja tarpeiden että toimittajan teknisen tietämyksen perusteella. (Huomiota kannattaa toki kiinnittää speksin ohella muihinkin sopimusehtoihin, ettei sitoudu mahdottomuuksiin tai kohtuuttomiin riskeihin, varsinkaan takuiden tai vastuiden osalta. Ei myöskään yleensä kannata sitoutua mihinkään aivan loputtomiin.)

Kieliteknologisten ohjelmistojen näennäisesti tarkatkin määrittelyt sisältävät usein isoja aukkoja, varsinkin jos luvataan vain jotain kovin yleistä kielellisestä oikeellisuudesta, huomioimatta tarkemmin, mitä (ja minkä mukaista) kielellinen oikeellisuus oikeastaan on, ja mikä ylipäänsä on teknisesti mahdollista. Ohjelman suorituskyky (lingvistinen, mutta toisaalta myös kellolla tai megatavuilla mitattava) kannattaa ilmoittaa mitattavilla numeroilla (kuten precision ja recall, joiden osalta on syytä myös määritellä tässä käytettävän aineiston laji ja laajuus), jos vain mahdollista.

Tilaajan kannalta

Tilaajan kannalta tilanne on osittain edellisen peilikuva. Toisaalta yksiselitteinen sopimus on yleensä lopulta molempien edun mukaista, antaahan se myös ostajalle selkeän mahdollisuuden reklamoida tuotteesta, mikäli ilmoitetut ominaisuudet eivät täyty.

Ohjelmistoyrityksessä vielä yksi tässä yhteydessä esille tuleva erityiskysymys on ohjelmistojen mahdollinen alihankinta. Tähän tietenkin pätee sama kuin ohjelmistojen hankintaan yleensä. Erityisesti on kuitenkin huomioitava myös, että alihankinnan tilaaja varmasti saa itselleen kaikki ne alihankintana hankittuun ohjelmistoon kohdistuvat oikeudet, joita tarvitaan ohjelmiston jälleenmyyntiin.

Shrink wrap -lisenssit

Yleisen kansanperinteen mukaan ns. shrink wrap -lisenssi, eli "sopimuksen" solmiminen ohjelmistopakkauksen kutistesuojamuovin avaamalla (vast), on vailla mitään merkitystä. Ihan näin yksinkertainen asia ei kuitenkaan ole. Jostainhan ostajan on käyttöoikeutensa ohjelmaan johdettava, ja jos muutakaan sopimusta ei ole, ei koko käyttöoikeutta tällöin olisi lainkaan. Aivan tavallista "oikeaa" sopimusta ei tällä tavoin kuitenkaan välttämättä synny, jos sopimus sisältää "yllättäviä" kohtia (kuten määräyksiä toimivaltaisesta tuomioistuimesta tai sovellettavasta laista), vaan sopimuksen sisältö rajoittuu käyttöoikeuden sisältöön ja muihin tavanomaisiin määräyksiin. Oleellista sisällöllistä eroa ei tämän suhteen ole, vaikka käyttäjän pitäisikin esim. näppäillä jotain voidakseen käyttää ohjelmaa (sen sijaan todistelu voi olla helpompaa).

Shrink wrap -tyyppiset sopimusehdot soveltuvat luonnostaan vain vakio-ohjelmistoihin. Tällöinhän kaupan kohteena on aina tietty ohjelmisto sellaisenaan (ilman mitään kovin ihmeellisiä tietoja sen ominaisuuksista, joitain perustavaa laatua olevia järjestelmä- ja ympäristövaatimuksia lukuunottamatta) ja sillä hyvä.

Vapaat ohjelmat

Vaihtoehtona kaupallisesti tuotetuille ohjelmille ovat viime aikoina yleistyneet vapaat ohjelmat (avoimen lähdekoodin ("open source") ohjelmistot, "ilmaisohjelmat"). Näistä tunnetuimpia ovat GNU/Linux-käyttöjärjestelmä ja GNU Emacs -pyhäinjäännös/editori. Vapaat ohjelmat eivät ole siinä mielessä vapaita, että niille voisi tehdä mitä tahansa miten tahansa, vaan ne ovat lisenssiehtojen sääntelemiä siinä missä kaupalliset ohjelmatkin. Näistä lisensseistä yleisimmin käytettyjä ovat GNU General Public License (GPL) ja Open Software License, muita saman tyyppisiä mutta kuitenkin erilaisia lisenssejä on satamäärin. Lähinnä nämä lisenssit koskevat itse ohjelmistoja ja niiden dokumentaatiota, jossain määrin myös muuta dokumentaatiota, ja onpa GPL:n alla julkaistu T-paitojakin.

Tunnusomaista vapaille ohjelmistoille on, ettei ohjelmiston levitystä saa rajoittaa, vaan ohjelmasta saa korvauksetta valmistaa kappaleita yhtä lailla omaa käyttöä kuin edelleenlevitystäkin varten. Tämä ei tarkoita, että kenenkään tarvitsisi luovuttaa ohjelman kappaletta ilmaiseksi, vaan ettei ohjelman ostajan kopiointioikeutta saa rajoittaa. Toinen tärkeä piirre vapaan kopioinnin ohella on oikeus tehdä muutoksia ohjelmaan, tai jopa tehdä olemassaolevia koodinpätkiä hyväksikäyttäen aivan erilainenkin ohjelma. Tämän oikeuden mahdollistamiseksi lisensseihin sisältyy myös vaatimus ohjelman lähdekoodin levittämisestä (tästä nimi "open source"), lähdekoodin pitää joko sisältyä jaettavaan ohjelmaan tai olla saatavissa ilmaiseksi/käsittelykustannuksin. (Tämä koskee vain ohjelmia, joita on luovutettu edelleen muille. Oman yrityksen sisällä pysyvien ohjelmien lähdekoodeja ei tarvitse luovuttaa mihinkään.)

Vapaan ohjelmiston lisenssi "tarttuu" yleensä myös ohjelmistoa käyttämällä syntyneeseen ohjelmaan, mikäli kyseessä on tekijänoikeudellisesti alkuperäiseen ohjelmaan nähden jälkiperäisteos. Vastaavasti tämä ei koske uusia, itsenäisiä teoksia, vaikka niiden tekemiseen olisikin käytetty vapaata ohjelmaa. (Tämän tekstin kirjoittaminen Emacsilla ei siis tee siitä GPL:n alaista, kuten ei myöskään minkä tahansa C-koodin kääntäminen gcc:llä.)

Yleisimpänä poikkeuksena tästä "tarttumisesta" ovat ns. kirjastolisenssit, kuten GNU Lesser General Public License (LGPL). Näiden osalta GPL- tai vastaavat ehdot (vapaa levitys, avoin lähdekoodi) koskevat vain levitettävää funktiokirjastoa ja sen muokattuja versioita, sen sijaan kirjastoa käyttävä ohjelma voi olla normaali maksullinen, suljetun lähdekoodin ohjelma.

Äärimmäinen muoto vapaista/ilmaisista tietokoneohjelmista ovat public domain (PD) -ohjelmat, joiden tekijä on luopunut täysin kaikista oikeuksistaan ohjelmaan, joten ohjelmaa saa käyttää, levittää, muokata jne. täysin ilman rajoituksia. Käytännössä useilla PD:n nimellä kulkevillakin ohjelmilla on kuitenkin joitain rajoituksia, jotka asettuvat jonnekin todellisen public domainin ja GPL:n välimaastoon.

Vapaisiin ohjelmiin ei pidä sekoittaa shareware-ohjelmia, jotka ovat poikkeuksellisella tavalla levitettäviä maksullisia ohjelmia. Shareware-ohjelmasta saa yleensä levittämistä varten valmistaa teoskappaleita vapaasti, samoin ohjelmaa saa usein käyttää jonkin aikaa maksutta, mutta tämän ajan kuluttua loppuun on ohjelmasta maksettava rekisteröintimaksu (tai lopetettava ohjelman käyttö), tai muuten ohjelma lakkaa toimimasta. (Ohjelma voi myös rekisteröimättömänä toimia demoversiona tai, kuten Opera-selaimen maksuton versio, vaikkapa näyttää mainoksia.)

Vastuukysymykset

Käytännössä ohjelmiston toimittajan vahingonkorvausvastuu tilaajaan nähden lähes aina sopimuksessa. Tämä koskee sekä toimituksen myöhästymisen tai virheellisyyden seuraamuksia (sopimussakko ja/tai vahingonkorvaus) että toimitetun ohjelman käytön aiheuttamia vahinkoja. Jälkimmäisessä tapauksessa käytäntö vaihtelee lähinnä kaiken vastuun kiistämisestä vain välittömien (eli ohjelman suoraan aiheuttamien) vahinkojen korvaamiseen, välillisiä (ohjelman aiheuttamasta vahingosta seuraavaa taloudellista menetystä tms.) vahinkoja ei yleensä korvata.


$Id: softa.html,v 1.7 2007/02/01 19:52:31 oronkain Exp $
© Anna Ronkainen ja Helsingin yliopisto 2003