Yliopiston etusivulle In English
Helsingin yliopisto
clt310ipr: 401092 Tekijänoikeudet - kevät 2010

Yhteystiedot

Nykykielten laitos

PL 24 (Unioninkatu 40)
00014 HELSINGIN YLIOPISTO

Puhelin +358 (09) 1911 (vaihde)
Faksi +358 (09) 191 28313

6. 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 kuuma puheenaihe viimeisen vuosikymmenen tai parikin. Vaikka useimpien Euroopan maiden tavoin Suomen patenttilaki (1 § 2) kieltääkin "pelkästään" tietokoneohjelman patentoinnin, käytännössä tietokoneohjelman patentointi on jo pitkään ollut mahdollista patentoimalla tietokoneohjelma menetelmänä, siis tapana ratkaista jokin tekninen ongelma käyttämällä mm. yleiskäyttöistä tietokonetta, joka suorittaa määrätynlaista ohjelmaa. Vuodesta 2003 PRH on myöntänyt myös vastaavia tietokoneohjelman sisältäviä tuotepatentteja EPO:n tätä edeltäneen käytännön mukaisesti.

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:

  • T 22/85, yhteenvedon tekeminen dokumenteista
  • T 52/85, tesauruksen generointi
  • T 01/83, automaattinen oikoluku
  • T 38/86, tekstin muuttaminen helppolukuisemmaksi
  • T 65/86, automaattinen oikoluku samalla tavoin äännettäville sanoille
  • T 42/87, monikielinen käyttöliittymä
  • T 110/87, konekäännös (tai jotain)
  • T 167/92, yhteenvetodokumenttien generointi (osaluetteloista)
  • T 572/93, puheentunnistuksen käyttö muistiinpanojen tekoon puhelimitse
  • GB9719454.2, kielentunnistus (UK)

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

  • T 71/91, dokumenttienhallintajärjestelmä (parannukset dokumenttien sisältöön riippumattomia)
  • T 236/91, menukäyttöliittymä (teknisenä tehona mm. pienempi muistin kulutus)

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 esimerkiksi Pekka Takin IT-sopimukset-kirjassa) 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). Sopimusoikeudellisesti tässä ei ole mitään kovin ihmeellistä, jossain määrin vastaavasta asiasta oli kyse myös laajaa huomiota herättäneessä ParkCom-oikeusjutussa (KKO:2010:23), jossa vastaavalla tavalla ns. konkludenttisella eli hiljaisella tahdonilmaisulla syntynyt sopimus yksityisalueelle pysäköinnin edellytyksenä oli riittävä sopimusperuste pysäköintivirhemaksun kaltaisten valvontamaksujen maksamisvelvoitteelle.

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ä eräitä tunnetuimpia ovat GNU/Linux-käyttöjärjestelmä, OpenOffice-toimisto-ohjelmisto 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.)

Creative Commons

Vapaiden ja avoimen lähdekoodin ohjelmistojen tekijänoikeudellinen ideologia on alkanut levitä myös ohjelmistoalan ulkopuolelle. Tähän liittyvistä hankkeista selvästi tunnetuin on Creative Commons, joka tarjoaa joukon vakiomuotoisia lisenssejä minkä tahansa tyyppisten teosten enemmän tai vähemmän vapaan levityksen käyttöehdoiksi. Mahdolliset käyttöehdot ovat jokin yhdistelmä seuraavista:

  • Attribution/Nimeä (by): tekijän nimi on kaikessa käytössä ilmoitettava tekijän vaatimalla (ja hyvän tavan mukaisella) tavalla
  • Share Alike/Jaa samoin (sa): jälkiperäisteosten levittäminen on sallittua ainoastaan alkuperäistä teosta vastaavin ehdoin
  • Non-Commercial/Epäkaupallinen (nc): teoksen kopiointi, levitys, näyttäminen, julkinen esittäminen ja hyödyntäminen jälkiperäisteosten tekemiseen ansiotarkoituksessa on kielletty
  • No Derivatives/Ei jälkiperäisiä (nd): teoksen käyttö on sallittu vain sellaisenaan, jälkiperäisteosten tekeminen on kielletty

Näistä by-ehto on pakollinen, sa- ja nd-ehdot taas keskenään ristiriitaisia. Lähtökohtana on kaikenlainen vapaa käyttöoikeus koskien niin teoskappaleiden valmistusta (kopiointia) ja jakelua, näyttämistä ja julkista esittämistä kuin teoksen käyttämistä omien (jälkiperäis)teosten tekemiseenkin, jolle luetelluista kolme viimeistä vaihtoehtoa voivat kuitenkin asettaa tarkempia rajoituksia. Oikeudellisesti tässä kuten myös vapaiden ohjelmistojen tapauksessa on kyse konkludenttiseen tahdonilmaisuun perustuvasta sopimuksesta: yksinoikeuden piiriin kuuluva teoksen käyttö edellyttää oikeudenomistajan suostumusta, ja jos tätä suostumusta ei ole hankittu muilla keinoin (mikä toki usein saattaa olla mahdollista ainakin silloin, kun tekijän omat kädet eivät ole vastaavan lisenssin sitomat), käyttäjän on käytännössä pakko hyväksyä lisenssi tarjolla olevine ehtoineen ja toimittava niiden mukaisesti. Muuten ainoa vaihtoehto on kokonaan luvaton (ja siis varmasti laiton) käyttö. Tietenkin tekijänoikeuden rajoitusten nojalla tapahtuva käyttö on sallittua joka tapauksessa.

Vastuukysymykset

Käytännössä ohjelmiston toimittajan vahingonkorvausvastuu tilaajaan nähden määrätään 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.

Hae laitoksen sivuilta:

Laitoksen etusivulle | Tiedekunnan etusivulle | Yliopiston etusivulle
Laitoksen yhteystiedot | Palaute laitokselle

Copyright © 2002-2010 Anna Ronkainen ja Helsingin yliopisto. Kaikki oikeudet pidätetään.