Avoimen lähdekoodin oikeudelliset riskit. Suunnattuun kyselyyn ja haastatteluihin perustuva selvitys

Transkriptio

1 Avoimen lähdekoodin oikeudelliset riskit Suunnattuun kyselyyn ja haastatteluihin perustuva selvitys Työ- ja elinkeinoministeriön julkaisuja Konserni 28/2010

2

3 ville oksanen mikko välimäki Avoimen lähdekoodin oikeudelliset riskit Suunnattuun kyselyyn ja haastatteluihin perustuva selvitys Työ- ja elinkeinoministeriön julkaisuja Konserni 28/2010

4

5 Työ- ja elinkeinoministeriön julkaisuja Konserni 28/2010 Arbets- och näringsministeriets publikationer Koncernen 28/2010 MEE Publications Concern 28/2010 Tekijät Författare Authors Ville Oksanen Mikko Välimäki Julkaisuaika Publiceringstid Date Kesäkuu 2010 Toimeksiantaja(t) Uppdragsgivare Commissioned by Työ- ja elinkeinoministeriö Arbets- och näringsministeriet Ministry of Employment and the Economy Toimielimen asettamispäivä Organets tillsättningsdatum Date of appointment Julkaisun nimi Titel Title Avoimen lähdekoodin oikeudelliset riskit Tiivistelmä Referat Abstract Avoimen lähdekoodin tietokoneohjelmien taloudellinen merkitys on kasvanut viimeisten vuosien aikana nopeasti niin yrityksissä kuin julkisella sektorilla. Esimerkiksi Gartnerin vuoden 2008 lopulla julkaiseman selvityksen mukaan 85% yrityksistä ja yhteisöistä käytti avointa lähdekoodia ja loput 15% suunnitteli käyttöönottoa seuraavan vuoden kuluessa. Avoimen lähdekoodin yleistyminen on muuttanut merkittävästi niin teknisiä, taloudellisia kuin juridisia ajattelutapoja. Se on tuonut mukanaan myös haasteita. Avoin lähdekoodi syntyi ilmiönä yliopistomaailmassa vastaamaan erilaisiin tutkimus- ja koulutustarpeisiin sekä yksittäisten ohjelmoijien näkemyksiin. Sittemmin Internetin yleistyttyä avoin lähdekoodi alkoi saada jalansijaa myös yrityksissä. Keskeinen ajatus on, että uudelle ohjelmistotuotteelle voidaan saada nopeammin käyttäjiä ja kehittäjiä kaikkialta maailmasta, jos tuote on lähdekoodeineen vapaasti kenen tahansa saatavilla. Nykyään onkin melkein pääsääntö, että uusi ohjelmistoyritys jakaa ainakin osan kehittämästään ohjelmistosta avoimena lähdekoodina. On siis väärinkäsitys luulla, että avointa lähdekoodia kehitettäisiin enää yksinomaan vapaaehtoisvoimin erilaisissa epämuodollisissa yhteisöissä. Työ- ja elinkeinoministeriön (TEM) 2008 julkaisemassa ns. kansallisessa IPR-strategiaselvityksessä todettiin, että avoin lähdekoodi sisältää potentiaalisia oikeudellisia riskejä mutta näkyvissä ei ole merkkejä suurista ristiriidoista. Nyt käsillä oleva TEM:in tilaama selvitys avoimen lähdekoodin oikeudellisista riskeistä on avaamassa näitä potentiaalisia riskejä sekä antamassa osviittaa riskien hallitsemiseksi. Selvityksen ensimmäisessä osiossa (luvut 2 ja 3) käydään läpi ohjelmistoja koskeva nykyinen oikeustila ja tyypilliset riskitilanteet. Selvityksen toisessa osioissa (luku 4) käydään läpi verkossa tehdyn kyselytutkimuksen tulokset. Selvityksen kolmas osio (luku 5) koostuu yhdeksän syvähaastattelun tuloksista. Selvityksen viimeinen osio (luku 6) koostuu verkkokyselyn ja haastatteluiden yhteenvedosta ja niissä esiinnousseiden ongelmien potentiaalisista ratkaisukeinoista. Osiossa lopuksi esitetään kokoavina huomioina joukko konkreettisia suosituksia, joilla havaittuja ongelma-alueita voitaisiin kehittää. Työ- ja elinkeinoministeriön yhteyshenkilö: Työelämä- ja markkinosasto/mikko Huuskonen, puh ISSN Kokonaissivumäärä Sidoantal Pages 44 Julkaisija Utgivare Published by Työ- ja elinkeinoministeriö Arbets- och näringsministeriet Ministry of Employment and the Economy ISBN Kieli Språk Language Hinta Pris Price Suomi, finska, finnish 13 Kustantaja Förläggare Sold by Edita Publishing Oy / Ab /Ltd

6

7 Esipuhe Valtioneuvosto teki periaatepäätöksen kansallisesta aineettomien oikeuksien eli IPR-strategiasta. Strategiaan sisältyy 60 erilaista toimenpidettä IPR-kentän kehittämiseksi. Eräänä toimenpidekohtana on avoimeen lähdekoodiin perustuvien tietokoneohjelmistojen lisensioinnin ja hyödyntämisen oikeudellisten riskien selvittäminen. Käsillä oleva FT Ville Oksasen ja FT Mikko Välimäen laatima selvitys täyttää tämän tehtävän. Miksi asia on kiinnostava? Tietokoneohjelmia on perinteisesti tehty yritysten toimesta liikesalaisuuksia ja uusi oivalluksia tarkasti vartioiden ja valvoen. Ajatus ideoiden vapaasta jakamisesta ohjelmoijien kesken syntyi hiukan samaan tapaan kuin internet eli tutkijoiden kesken lähinnä yliopistomaailmassa helpottamaan samoista asioista kiinnostuneiden yhteistyötä, keskustelua ja yhteydenpitoa. Yliopistomaailmasta se kuitenkin verraten nopeasti levisi myös liikeyritysten käyttöön tarjoten kokonaan uudenlaisen tavan kehittää ohjelmistotuotteita laajassa yhteistyössä asiasta kiinnostuneiden kesken. Kyse ei siten ole pelkästään uudesta tavasta tuottaa tietokoneohjelmia, vaan uudesta tavasta kehittää tuotteita yhteisöllisesti. Koska kyse on oikeudellisessa mielessä perinteisiin yksinoikeuksiin perustuvien luovan työn tulosten jakamisesta ja hyödyntämisestä, muodostaa kenttä kiinnostavan ja kasvavan alueen myös oikeudellisesti. Enää ei riitä kysymys, miten suojaan oikeuteni, vaan avoimen lähdekoodin toiminnan kysymyksiä ovat, miten jaan oikeuteni tehokkaasti ja oikeusvarmasti, ja miten itse vastaavasti hyödynnän yhteistyön tuloksia turvallisesti. Avoimen lähdekoodin tietokoneohjelmien taloudellinen merkitys on kasvanut viimeisten vuosien aikana nopeasti niin yrityksissä kuin julkisella sektorilla. Esimerkiksi Gartnerin vuoden 2008 lopulla julkaiseman selvityksen mukaan 85% yrityksistä ja yhteisöistä käytti avointa lähdekoodia ja loput 15% suunnitteli käyttöönottoa seuraavan vuoden kuluessa. Avoimen lähdekoodin yleistyminen on muuttanut merkittävästi niin teknisiä, taloudellisia kuin juridisia ajattelutapoja. Se on tuonut mukanaan myös haasteita. Selvityksessä käydään läpi ohjelmistoja koskeva nykyinen oikeustila ja tyypilliset riskitilanteet, verkossa tehdyn kyselytutkimuksen tulokset, yhdeksän syvähaastattelun tulokset sekä esitetään esiinnousseiden ongelmien potentiaalisia ratkaisukeinoja. Lopuksi esitetään kokoavina huomioina joukko konkreettisia suosituksia, joilla havaittuja ongelma-alueita voitaisiin kehittää. Mikko Huuskonen OTT, neuvotteleva virkamies työelämä- ja markkinaosasto/tem

8

9 Sisältö Esipuhe Johdanto Selvityksen tausta ja tavoitteet Terminologiasta Sisältö ja menetelmät Avoin lähdekoodi Mitä ilmiöllä tarkoitetaan? Oikeudet tietokoneohjelmiin Lisensointi Avoimen lähdekoodin lisenssit Oikeudelliset riskit Tekijänoikeus- ja lisenssiriskit Patenttiriskit Riskien hallinta sisäisissä ohjeistuksissa ja sopimuksissa Toiminta oikeudenloukkaustilanteissa Verkkokysely Kyselyn sisältö ja suoritus Kyselyn tulokset Haastattelut Haastatteluiden sisältö ja suoritus Riskitietoisuusmalli Puolustusvoimat Tampereen kaupunki Avarea Valtion IT-hallinnon johtamisyksikkö CSC IT Center for Science Tieto Nokia Monty Program COSS Center of Open Source Software Excursio: Antti Damskin kantelu Johtopäätökset ja suositukset Kokoavia huomioita Suosituksia... 37

10 Kuvaajat Kuvaaja 1. Kuvaaja 2. Kyselyn mukaiset avoimen lähdekoodin sovellusalueet asteikolla 1 10, vastausten keskiarvot (1=ei lainkaan, 10=pelkästään) Kyselyssä raportoidut syyt avoimen lähdekoodin käytölle asteikolla 1 5, vastausten keskiarvot (1=ei tärkeä, 5=erittäin tärkeä) Kuvaaja 3. Juristien käyttö ohjelmistoyrityksissä Kuvaaja 4. Kyselyssä raportoidut oikeudelliset riskit asteikolla 1-6, vastausten keskiarvot (1=ei tärkeä, 6=erittäin tärkeä) Kuvaaja 5. Kuvaaja 6. Vastaus kysymykseen onko yrityksellä prosessi avoimen lähdekoodin käytölle Eri avoimen lähdekoodin lisenssien käyttö ohjelmistoyrityksissä Kuvaaja 7. Lisenssinhallintatyökalujen käyttö ohjelmistoyrityksissä. 24 Kuva 1. Avoimen lähdekoodin riskitietoisuusmalli

11 1 Johdanto 1.1 Selvityksen tausta ja tavoitteet Avoimen lähdekoodin taloudellinen merkitys on kasvanut viimeisten vuosien aikana nopeasti niin yrityksissä kuin julkisella sektorilla. Esimerkiksi Gartnerin vuoden 2008 lopulla julkaiseman selvityksen mukaan 85% yrityksistä ja yhteisöistä käytti avointa lähdekoodia ja loput 15% suunnitteli käyttöönottoa seuraavan vuoden kuluessa.1 Avoimen lähdekoodin yleistyminen on muuttanut merkittävästi niin teknisiä, taloudellisia kuin juridisia ajattelutapoja. Se on tuonut mukanaan myös haasteita. Työ- ja elinkeinoministeriön (TEM) 2008 julkaisemassa ns. kansallisessa IPR-strategiaselvityksessä todettiin, että avoin lähdekoodi sisältää potentiaalisia oikeudellisia riskejä mutta näkyvissä ei ole merkkejä suurista ristiriidoista. Immateriaalioikeuksien kannalta avoin lähdekoodi miellettiin fundamenttiongelmaksi.2 Nyt käsillä oleva TEM:in tilaama selvitys avoimen lähdekoodin oikeudellisista riskeistä on toivon mukaan avaamassa näitä potentiaalisia riskejä sekä antamassa osviittaa riskien hallitsemiseksi. Kuten monessa muussakin tapauksessa, avoimen lähdekoodin oikeudelliset riskit ovat kiinteästi yhteydessä myös liiketoiminnallisiin ja teknisiin riskeihin. Vaikka tämän selvityksen painopiste pyritäänkin pitämään oikeudellisella puolella, liiketoimintaa ja teknisiä kysymyksiä koskevaa keskustelua ei voida siten täysin ohittaa. On syytä korostaa, että tämä selvitys ei ole ohjelmistojuridiikan tai ohjelmistolisensoinnin käsikirja. Aihe on rajattu avoimeen lähdekoodiin liittyvien riskien empiiriseen kartoittamiseen ja havaintojen pohjalta tehtyihin suosituksiin. Jo selvityksen rajattu laajuus estää avaamasta esimerkiksi erilaisia avoimen lähdekoodin liiketoimintastrategioita tai erilaisten avoimen lähdekoodin lisenssien juridisia yksityiskohtia. Näistä teemoista on onneksi saatavilla jo runsaasti kirjallisuutta ja koulutusta Terminologiasta Tässä selvityksessä käytetään termiä avoin lähdekoodi ( open source ) kuvaamaan tietyllä lisenssimallilla jaettavia ohjelmistoja ja tähän liittyvää taloudellista ilmiötä. Toisena vaihtoehtona olisi ollut vapaat ohjelmistot ( free software ), jonka taustalla 1 Gartnerin lehdistötiedote : Gartner Says as Number of Business Processes Using Open-Source Software Increases, Companies Must Adopt and Enforce an OSS Policy. 2 Ks. IPR tehokkaaseen käyttöön! Aineksia teollis- ja tekijänoikeuksien strategiaan (TEM, 2008), s Lainaukset ovat yritysten syvähaastatteluista tehtyjä johtopäätöksiä. 3 Mainittakoon, että vuodesta 2009 on ilmestynyt yksinomaan avoimen lähdekoodin juridiikkaan keskittynyt International Free and Open Source Software Law Review, jossa julkaistut artikkelit on vapaasti luettavissa osoitteessa Liiketoimintanäkökulmasta tehtyjä selvityksiä ja tutkimuksia on koottu esimerkiksi osoitteeseen 9

12 on Free Software Foundationin (FSF) ideologiasta kumpuava lähestymistapa. Suomessa on käytetty myös jonkin verran lyhennystä VALO (vapaa ja avoin lähdekoodi), joka on muunnelta EU:ssa yleisesti käytössä olevasta lyhenteestä FOSS ( Free/libre and Open Source Software ). Tämän selvityksen kannalta näillä kaikilla viitataan samaan ilmiöön. 1.3 Sisältö ja menetelmät Tämä selvitys koostuu neljästä pääosiosta. Ensimmäisessä osiossa (luvut 2 ja 3) käydään läpi tiiviisti ohjelmistoja koskeva nykyinen oikeustila ja tyypilliset riskitilanteet. Tämän osien tarkoituksena on tarjota erityisesti muille kuin juristeille tarvittavat pohjatiedot seuraavien osioiden läpikäymiseen. Tosin ohjelmistojen oikeudellisen suojan kertaaminen ei välttämättä ole juristeillekaan huono ajatus, sillä perinteinen käsitys tekijänoikeudesta ohjelmistojen ainoana suojamuotona on jokseenkin vanhentunut. Selvityksen toisessa osioissa (luku 4) käydään läpi verkossa tehdyn kyselytutkimuksen tulokset. Verkkokyselyn tarkoituksena oli saada yleiskäsitys siitä, mitä eri alan toimijat pitävät merkittävimpinä oikeudellisina riskeinä ja mihin toimenpiteisiin on ryhdytty näiden korjaamiseksi. On syytä pitää mielessä, että kyseessä ei ole otantansa puolesta tieteelliset kriteerit täyttävä kysely, sillä vastaajiksi on todennäköisemmin valikoitunut tahoja, joita aihepiiri kiinnostaa. Selvityksen kolmas osio (luku 5) koostuu yhdeksän syvähaastattelun tuloksista. Haastateltavaksi valittiin mahdollisimman monipuolisesti yrityksiä ja julkisen sektorin toimijoita ja näin koitettiin paikata verkkokyselyyn mahdollisesti jääneitä aukkoja. Toiseksi haastatteluilla koitettiin saada selville myös erityissektorien ongelmia. Haastatteluiden lisäksi osiossa käydään läpi myös yksi konkreettinen esimerkki avoimen lähdekoodin toimittamisen ongelmista. Selvityksen viimeinen osio (luku 6) koostuu verkkokyselyn ja haastatteluiden yhteenvedosta ja niissä esiinnousseiden ongelmien potentiaalisista ratkaisukeinoista. Osiossa lopuksi esitetään kokoavina huomioina joukko konkreettisia suosituksia, joilla havaittuja ongelma-alueita voitaisiin kehittää. Osa suosituksista on luonteeltaan sellaisia, ettei niitä voida ratkaista yksin Suomessa. 10

13 2 Avoin lähdekoodi 2.1 Mitä ilmiöllä tarkoitetaan? Teknisesti tietokoneohjelmat ovat koodia. Tietokoneohjelmia kehitetään kirjoittamalla ohjelmointikielellä ihmisten ymmärtämää lähdekoodia, joka käännetään tietokoneella ajettavaksi konekoodiksi (binäärikoodi). Esimerkiksi C-ohjelmointikielellä kirjoitettu lähdekoodi int main( ) { printf( hello, world ); return 0; } voisi näyttää konekoodiksi käännettynä vaikka tämännäköiseltä: Pääsääntöisesti tietokoneohjelmia levitetään ja myydään valmiiksi ajettavina konekooditiedostoina. Tällöin käyttäjä voi käynnistää ohjelman ja käyttää sitä normaalisti, mutta luonnollisestikaan käyttäjä ei voi alkaa muunnella tai kehittää tietokoneohjelmaa edelleen ilman lähdekoodia.4 Poikkeuksen ohjelmistotuoteliiketoiminnassa ovat aiemmin muodostaneet lähinnä yrityskohtaiset ohjelmistot sekä ohjelmistokehittäjien käyttöön tarkoitetut työkalut, jotka ovat aina vaatineet lähdekoodin mukaansa. Tällöinkin lähdekoodia on pidetty sen tekijänoikeuden haltijalle niin arvokkaana, että lisenssisopimuksessa koodin levittäminen eteenpäin on ollut lähtökohtaisesti kielletty. Avoin lähdekoodi syntyi ilmiönä yliopistomaailmassa kaukana liiketoiminnasta vastaamaan erilaisiin tutkimus- ja koulutustarpeisiin sekä yksittäisten ohjelmoijien näkemyksiin. Sittemmin Internetin yleistyttyä avoin lähdekoodi alkoi saada jalansijaa myös yrityksissä. Keskeinen ajatus on, että uudelle ohjelmistotuotteelle voidaan saada nopeammin käyttäjiä ja kehittäjiä kaikkialta maailmasta, jos tuote on lähdekoodeineen vapaasti kenen tahansa saatavilla. Nykyään onkin melkein pääsääntö, että uusi ohjelmistoyritys jakaa ainakin osan kehittämästään ohjelmistosta avoimena lähdekoodina. Monet suosituksi nousseet avoimen lähdekoodin projektit on myös yhtiöitetty joko siten, että koodiin kuuluvat oikeudet on siirretty perustetulle yhtiölle, tai vaihtoehtoisesti projektin oheen on syntynyt sitä tukevia palveluyrityksiä. On siis väärinkäsitys luulla, että avointa lähdekoodia 4 Tämä voi olla rajoitetusti mahdollista käänteismallintamalla konekoodia lähdekoodiksi. Käsin tehtävä operaatio on kuitenkin hyvin työläs, eikä lopputulos ole koskaan täydellinen

14 kehitettäisiin enää yksinomaan vapaaehtoisvoimin erilaisissa epämuodollisissa yhteisöissä. 2.2 Oikeudet tietokoneohjelmiin Tietokoneohjelmiin kohdistuu lukuisia immateriaalioikeuksia. Näistä keskeisimmät ovat:5 Tekijänoikeus, joka kohdistuu luovaan ja omaperäiseen koodiin. Tekijänoikeus kattaa sekä lähdekoodin että siitä käännetyn konekielisen ohjelman. Tekijänoikeuden haltijalla on yksinoikeus määrätä tietokoneohjelman kopioimisesta, muuntelusta, ja levittämisestä. Liikesalaisuus, joka kohdistuu esimerkiksi ohjelmiston suunnitteluaineistoon sekä lähdekoodiin, mikäli se pidetään salaisena. Patenttioikeus, joka kohdistuu sellaisiin patentoituihin keksintöihin, jotka tietokoneohjelma mahdollisesti toteuttaa. Patentti on aina haettava. Euroopassa on myönnetty patentteja esimerkiksi algoritmeihin, tiettyihin toiminnallisuuksiin sekä arkkitehtuurisiin ratkaisuihin. Myönnetty patentti antaa yksinoikeuden keksinnön ammattimaiseen hyödyntämiseen. Tavaramerkkioikeus, joka kohdistuu ohjelmiston nimeen. Hyvän tavan mukainen niin sanottu viittauskäyttö on kuitenkin sallittu. Mallioikeus, joka kohdistuu esimerkiksi käyttöliittymän osiin ja ikoneihin. Mallioikeus on aina haettava. Vaikka tekijänoikeus on edelleen suojamuodoista kaikkein tärkein, se ei ole siis suinkaan enää ainoa. Tiettyyn ohjelmistoon voi kohdistua yhtä aikaa lukuisia eri oikeuksia, ja niillä voi olla useita oikeudenhaltijoita. Yksittäisistä oikeuksista etenkin patenttien merkitys on kasvanut kaiken aikaa. Toisin kuin monet ovat luulleet, myös Euroopassa on ollut jo useita vuosia mahdollista patentoida keksintöjä, jotka voidaan käytännössä toteuttaa vain tietokoneohjelmalla. Tietokoneohjelmien patentointi on tosin edelleen poliittinen kysymys, ja sen rajoja haetaan parhaillaan oikeuskäytännössä. Yhdysvaltojen Korkein oikeus antoi kesällä 2009 valitusluvan Bilski-tapauksessa, johon odotetaan ratkaisua vuoden 2010 aikana.6 Pohjana oleva päätös valitustuomioistuimessa rajasi liiketoimintamenetelmien patentointia mutta ohjelmistojen patentoitavuus jäi avoimeksi. Euroopan patenttivirastossa Münchenissä puolestaan viraston presidentti on lähettänyt laajennetulle valitusjaostolle joukon kysymyksiä, joilla täsmennettäisiin vihdoin, missä määrin tietokoneohjelmat voidaan patentoida teknisinä keksintöinä.7 5 Ks. laajemmin esimerkiksi Mikko Välimäki: Oikeuden tietokoneohjelmistoihin. 2.p. Talentum In re Bilski, 545 F.3d 943, 88 U.S.P.Q.2d 1385 (Fed. Cir. 2008). 7 Referral to the Board of Appeal, G 3/08, Euroopan patenttiviraston valituslautakunnan linjaus ei muodollisesti sido kansallisia tuomioistuimia mutta on kuitenkin luultavaa, että ratkaisun antamisen jälkeen kansalliset tuomioistuimet tulevat sitä noudattamaan. 12

15 2.3 Lisensointi Se jolla on oikeudet tietokoneohjelmaan voi tehdä oikeuksilla kauppaa joko oikeudet luovuttamalla tai lisensoimalla. Jos oikeudet myydään, kuten monesti toimitaan asiakaskohtaisissa projekteissa, kysymys on oikeuksien kertaluonteisesta pysyvästä luovutuksesta. Jos taas oikeudenhaltija pitää kaikki oikeudet itsellään ja antaa niihin rajattuja käyttöoikeuksia, kysymys on oikeuksien lisensoinnista. Oikeudellisesti ohjelmistotuoteliiketoiminta perustuu pitkälti tietokoneohjelman käyttöehdoista sopimiseen eli lisensointiin. Ohjelmistolisenssit eivät ole kuitenkaan puhtaita immateriaalioikeuslisenssejä, sillä niissä on myös immateriaalioikeuksiin kuulumattomia sopimusehtoja. Näitä voivat olla mm. tekijänoikeusmerkintöjä koskevat ehdot, ohjelman käyttöä rajoittavat ehdot, liitännäispalveluja koskevat ehdot, vastuunrajoitusehdot ja kilpailunrajoitusehdot. Sopimusoikeudelliset ja immateriaalioikeudelliset käyttöehdot sidotaan lisenssisopimuksissa yleensä mahdollisimman kiinteästi toisiinsa. Tavoitteena on, että minkä tahansa käyttöehdon rikkominen johtaa siihen, että lisenssi ei ole enää voimassa. Tietokoneohjelman käyttö ilman lisenssiä on siten yleensä tekijänoikeuden loukkaus. Oikeuksien valvonnan kannalta tekijänoikeuden loukkaus antaa lisenssinantajalle huomattavasti pelkkää sopimusrikkomusta vahvemman aseman. Yhdysvaltalaisessa tapauksessa Jacobsen v. Katzer (2008) oli kysymys siitä, että erästä avoimen lähdekoodin komponenttia käyttänyt yritys oli jättänyt mainitsematta omassa lopputuotteessaan lisenssiehdoissa vaaditut asiat:8 (1) the authors names, (2) JMRI copyright notices, (3) references to the COPYING file, (4) an identification of Source-Forge or JMRI as the original source of the definition files, and (5) a description of how the files or computer code had been changed from the original source code. Mikään näistä ehdoista ei perustunut Yhdysvaltojen tekijänoikeuslakiin. Tästä huolimatta kysymys oli tekijänoikeuden loukkauksesta, ja oikeudenhaltija saattoi hakea nopeaa kieltotuomiota oikeuden loukkauksen keskeyttämiseksi, koska ilman voimassaolevaa lisenssiä yritys ei olisi voinut kopioida ja levittää komponenttia osana omaa tuotettaan. Tuomioistuin kiinnitti huomiota siihen, että kaikki kyseisen Artisticlisenssin käyttöehdot oli kirjoitettu muodossa provided that. 2.4 Avoimen lähdekoodin lisenssit Tietokoneohjelmiin kohdistuvien immateriaalioikeuksien lisensointiin ei ole koskaan ollut vain yhtä reseptiä. Jo 1970-luvulta alkaen ohjelmistoja on lisensoitu malleilla, joissa tekijä luopuu osasta lain suomia oikeuksia. Suosittuja ovat olleet esimerkiksi erilaiset kokeiluversiot ( shareware ) ja täysin ilmaiset ohjelmistot ( freeware ). Toisin kuin esimerkiksi äänilevyteollisuudessa, maksimalistinen kaikkien 8 Jacobsen v. Katzer, No. 06 CV JSW, 2007 WL (N.D.Cal. Aug. 17, 2007 ) 13 12

16 mahdollisten oikeuksien pidättäminen ei ole ollut ainut menestyksekäs tapa toimia ohjelmistoteollisuudessa. Internetin yleistymisen myötä 1990-luvulla eräät yliopistomaailmassa käytetyt lisenssimallit tulivat nopeasti laajaan käyttöön. Yhteiseksi nimittäväksi tekijäksi nousi ensin vapaat ohjelmistot ( free software ) ja sittemmin avoin lähdekoodi ( open source ). Avoimen lähdekoodin määritelmästä vastaava yleishyödyllinen yhteisö Open Source Initiative on hyväksynyt kymmeniä lisenssejä, jotka täyttävät määritelmän.9 Hyväksyttyjä avoimen lähdekoodin lisenssejä on useita kymmeniä. Ne voidaan kategorisoida kahteen päätyyppiin: Ensimmäistä ryhmää voi kutsua salliviksi lisensseiksi. Ne sallivat mutta eivät vaadi että lähdekoodi on avoinna ja saatavilla. Lisensseissä on kuitenkin erilaisia ehtoja muun muassa siitä että lisenssiä itsessään, tekijöiden nimiä ja vastuuvapauslausekkeita ei saa poistaa. Tällaisia lisenssejä ovat esimerkiksi BSD, MIT ja Apache-lisenssit. Toista ryhmää voi kutsua copyleft-lisensseiksi, jotka vaativat tiettyä vastavuoroisuutta. Jos copyleft-lisenssi asettaa vaatimuksen, että kokonaisuus pitää vastavuoroisesti lisensoida samoin avoimen lähdekoodin ehdoin kuin sen yksittäinen komponentti, voidaan puhua vahvasta vastavuoroisuudesta, lisenssin periytyvyydestä tai tarttuvuudesta ( viral effect ). Tällainen on esimerkiksi kaikkein suosituin avoimen lähdekoodin lisenssi GNU GPL. Jos lisenssi ei aseta vaatimuksia kokonaisuuden lisensoimiselle vaan sallii esimerkiksi komponenttien linkityksen osaksi kokonaisuutta, voidaan puhua heikosta vastavuoroisuudesta tai yksinkertaisesti lisenssin pysyvyydestä ( share alike ). Tällainen on esimerkiksi GNU LGPL -lisenssi. Näiden kategorioiden lisäksi on olemassa vielä omana alalajina palveluliiketoimintaan suunnitellut lisenssit kuten Affero GPL. Suosituimmat avoimen lähdekoodin lisenssit ovat olleet käytössä pitkään, ja ne ovat syntyneet yksittäisissä ohjelmistoprojekteissa. Jotkin suuremmat yritykset ja julkiset toimivat ovat yrittäneet tuoda myös omia lisenssivaihtoehtojaan saataville. Toistaiseksi merkittävimmät ovat olleet Microsoftin Public License ja Euroopan Unionin EU Public License. Avoimen lähdekoodin lisenssit perustuvat tekijänoikeuteen siinä missä mikä tahansa ohjelmistolisenssi. Kaikkien avoimen lähdekoodin lisenssien keskeisenä ajatuksena kuitenkin on, että tekijä ei pidä kiinni yksinoikeuksistaan kopioida, levittää ja muuttaa ohjelmistoa, vaan näiden oikeuksien hyödyntäminen nimenomaan sallitaan laajasti ja siihen kannustetaan julkaisemalla lähdekoodi. Tältä osin avoimen lähdekoodin lisenssit toimivat päinvastaisesti kuin tavanomaiset rajoitetun käyttöoikeuden lisenssit. Avoimen lähdekoodin lisenssit sulkevat pois monia hinnoittelumalleja, sillä tekijällä on niiden takia vähemmän mahdollisuuksia asettaa lisäehtoja tietokoneohjelman

17 käytölle. Ohjelmiston sisältämiä keksintöjä ei voi enää pitää salassa. Ohjelmiston kehitystäkään ei enää voi hallita pelkästään salaamalla lähdekoodi. On mahdollista, että joku ulkopuolinen kehittää lähdekoodin pohjalta oman version ja laskee liikkeelle kilpailevan ohjelmistotuotteen. Mainituista muutoksista huolimatta tai ehkä pikemminkin niiden takia avoin lähdekoodi on tullut erittäin suosituksi. Nykyään lähes jokainen tietokoneohjelmia käyttävä yhteisö käyttää myös avoimen lähdekoodin ohjelmia, toiset enemmän, toiset vähemmän. Avoimen lähdekoodin käytöstä on tullut osa sekä ohjelmia kehittävien että käyttävien yritysten liiketoimintastrategiaa. Avoimella lähdekoodilla pyritään usein hakemaan kustannussäästöjä ja vähentämään toimittajariippuvuutta kriittisissä ohjelmistoissa. Toisaalta on tilanteita, jolloin nimenomaan edellytetään, että avointa lähdekoodia tai tietyntyppisiä lisenssejä ei käytetä

18 3 Oikeudelliset riskit 3.1 Tekijänoikeus- ja lisenssiriskit 10 Tietokoneohjelmien tekijänoikeuden loukkauksissa voidaan tunnistaa kaksi tyyppitilannetta. Joko lähdekoodia on kopioitu tekijänoikeuslain vastaisesti tai sitten lisenssiehtoja ei ole noudatettu. Loukkaukset voivat kohdistua sekä lisenssinantajan itsensä tuottamaan osaan ohjelmistosta tai ulkopuolisen laatimaan komponenttiin. Jälkimmäisiin liittyvät ongelmat ovat luonnollisesti hankalammin havaittavissa, ja usein komponenttia käyttävän toimittajan loukkaukset ovat siksi tahattomia. Lähdekoodin kopioimista voidaan jossain määrin selvittää ennakolta teknisesti. Tämä edellyttää, että myös ulkopuolisten toimittamien komponenttien lähdekoodi on saatavilla. Lisäksi, jos on olemassa toinen lähdekoodi, jota epäillään kopioidun, koodeja voidaan verrata toisiinsa. Mitenkään syvälliseen analyysiin ei teknisin keinoin kuitenkaan päästä. Esimerkiksi lähdekoodin rakenteen tutkiminen on huomattavan hankalaa. Kopioinnin tunnistamiseksi on saatavilla lukuisia ohjelmistoja. Monet näistä hyödyntävät laajoja lähdekoodien vertailutietokantoja, joihin on koottu esimerkiksi julkisesti saatavilla olevien avoimen lähdekoodin projektien lähdekooditiedostot. Tunnettuja valmistajia ovat esimerkiksi Black Duck Software ja Palamida. Näiden valmistajien tuotteilla on mahdollista tunnistaa myös jossain määrin konekielisten komponenttien kopiointia; tämä perustuu tiedostojen yksilöllisiin tarkistussummiin ja laajaan tietokantaan tällaisista komponenteista. Myös lisenssiehtojen noudattamista voidaan selvittää jossain määrin ennakolta. Edellytyksenä on, että kaikki ohjelmistokokonaisuuteen kuuluvat lisenssiehdot voidaan tunnistaa ja listata. Tämä puolestaan yleensä edellyttää, että lähdekoodi on saatavilla, sillä esimerkiksi avoimen lähdekoodin komponenteissa lisenssiehdot on tyypillisesti upotettu lähdekoodiin. Jos tällaisen komponentin lähdekoodi on saatavilla, siitä voidaan tekstihauilla etsiä kolmansien tekijänoikeusilmoituksia ja lisenssiehtoja. Kun lisenssiehdot on saatu listattua, niistä on vielä tehtävä juridinen arviointi. Ehtojen tulkinta ei ole mitenkään suoraviivaista etenkään, jos ohjelmistokomponenteissa on komponenttivalmistajan itsensä laatimat yksilölliset ehdot. Myös lisenssimerkintöjen tunnistamista ja analysointia voidaan jossain määrin automatisoida. Kansainvälisesti tunnetuin ratkaisu lienee avoimen lähdekoodin Fossology, joissa on myös paljon muita toimintoja. Teknillisellä korkeakoululla kehitetty täsmäratkaisu Open Source License Checker pyrkii tunnistamaan lähdekooditiedostoja sisältävästä paketista tekijänoikeus- ja lisenssimerkinnät sekä avoimen lähdekoodin lisenssien keskinäiset riippuvuudet ja 10 Tämä ja seuraava jakso vastaavat pitkälti teoksen Välimäki (2009) jaksoa

19 yhteensopivuuden. Tuloksia voi tarkastella ohjelman sisällä ja ne voi tulostaa raportiksi myöhempää selvitystä varten.11 Suomessa toimii Validos niminen yhdistys, joka validoi juridisesti muun muassa mainittuja työkaluja hyödyntämällä jäsenyritysten käyttöön avoimen lähdekoodin komponentteja.12 Yllä sanotun perusteella voidaan todeta, että ulkopuolisten tuottamia komponentteja käyttävä lisenssinantaja voi vain hyvin rajatusti varmistua siitä, loukkaako lisensoitu tuote mahdollisesti kolmannen tekijänoikeuksia. Jos komponentin lähdekoodi ei ole saatavilla, mahdollisuudet riskien juridiseen arviointiin ovat lähes olemattomat. Jos lähdekoodi on saatavilla, riskejä voidaan teoriassa kartoittaa yllä sanottujen suuntaviivojen mukaisesti, mutta silloinkin kartoitus on aina rajallista. Jos komponentin lähdekoodi on lisäksi avoimesti kaikkien saatavilla, loukkausriski kasvaa, sillä mahdollisesti loukatuksi tullut kolmas voi helpommin havaita omien oikeuksiensa loukkauksen. 3.2 Patenttiriskit Ohjelmistoon voi tekijänoikeuksien lisäksi kohdistua kolmansien patentteja, jotka eivät tule ilmi ennen kuin ohjelmisto on tullut riittävän suosituksi ja tunnetuksi. Patenttiloukkausten riski kasvaa ohjelmiston markkina-alueen kasvaessa. Yhdysvaltojen markkinoilla riski on luonnollisesti suurin. Patenttiloukkauksien havainnoiminen ennakolta on teoriassa mahdollista mutta käytännössä usein mahdotonta. Koska ohjelmistopatenttivaatimuksiin ei yleensä sisälly lähdekoodia, patentin käytön tekninen analysointi lähdekoodin perusteella ei ole mahdollista, vaikka tuotteen kaikkien komponenttien lähdekoodi olisi saatavilla. Patenttien loukkauksiin voidaan ennakolta varautua lähinnä silloin, kun kyseessä on toimialalla yleisesti tunnettu patentti. Lisäksi loukkauksia voidaan yrittää välttää kilpailijoiden patenttisalkkuja seuraamalla. Tosin patenttisalkkujen seuranta on ohjelmistoalan dynaamisuudesta johtuen käytännössä erittäin hankalaa ja kallista. Ohjelmistopatentteja on myönnetty jo tuhansia eri puolilla maailmaa. Olisi epärealistista väittää, että edes alan suurimmat toimijat voisivat aukottomasti tietää, mitä kolmansien patentteja heidän toimittamiin laajoihin tuotekokonaisuuksiin mahdollisesti kohdistuu. Suurten ohjelmistoyritysten mahdollisuudet varautua patenttiloukkauksiin ovat kuitenkin merkittävästi paremmat kuin pienyrityksillä. Suurimmilla yrityksillä on yleensä etuna omat patenttisalkut, ja loukkausväitteiden tullessa niillä on tällöin mahdollisuus esittää vastaväitteitä ja vaatia ristiinlisensointia. Pienillä yrityksillä ei ole vastaavaa mahdollisuutta. Pieni yritys on käytännössä aseeton patenttiväitteen saapuessa. Yllä sanotusta seuraa, että huolellisenkin lisenssinantajan mahdollisuudet varautua patenttiloukkauksiin ovat vielä rajatummat kuin tekijänoikeusloukkauksissa. 11 Kirjoittajat ovat osallistuneet Open Source License Checkerin kehityksen johtamiseen Yhdistys, johon kuuluu kymmenkunta jäsentä, toimii Asianajotoimisto HH Partnersin yhteydessä

20 Mitä pienemmästä yrityksestä ja suuremmasta markkina-alueesta on kysymys, sitä suurempi on riski. Lähdekoodin saatavuus ei juurikaan auta riskin kartoittamisessa vaan voi nostaa loukkausriskiä entisestään: avoimesta lähdekoodista kolmas osapuoli voi helpommin havaita patenttiloukkaukset. 3.3 Riskien hallinta sisäisissä ohjeistuksissa ja sopimuksissa 13 Usein tehokkain tapa hallita tahattomia tekijänoikeuden ja patenttien loukkauksia on valvoa ohjelmistokehitystä ja ohjeistaa ohjelmoijat tutustumaan huolellisesti jokaisen kolmannen osapuolen komponentin käyttöehtoihin. Mikäli mahdollista, komponenttitoimittajat on pyrittävä saamaan takaamaan, että heidän toimittamansa tuotteet eivät loukkaa kolmansien oikeuksia ( indemnification ). Myös omaan koodiin on syytä sisällyttää asianmukaiset tekijänoikeusmerkinnät. Koska avoimen lähdekoodin komponenttien hyödyntämiseen liittyy erilaisia käyttörajoituksia ja ohjelmia saattaa ilmaantua yrityksenkäyttöön suoraan Internetistä ohi perinteisten ostokanavien, useat yritykset ja julkishallinnon toimijat ovat luoneet käyttösääntöjä avoimelle lähdekoodille. Säännöt voivat kuulua pääpiirteissään esimerkiksi seuraavasti: 1. Avointa lähdekoodia ei saa ottaa käyttöön ilman lupaa; käytön suunnittelusta on aina raportoitava. 2. Ennen käyttöönottoa on tutkittava ohjelman lisenssiehdot ottaen huomioon ohjelman aiottu käyttötarkoitus (loppukäyttö, tuotekehitys). 3. Osa lisensseistä voidaan luokitella valmiiksi hyväksytyiksi (sallivat lisenssit), osa taas vaatii aina tapauskohtaisen tarkemman selvityksen (copyleft-lisenssit). 4. Käyttöönotetuista ohjelmista on pidettävä kootusti kirjaa, josta selviää ainakin ohjelman nimi, oikeuksien omistaja, käyttöönottoajankohta, lisenssi ja käyttötarkoitus. Käytännössä käyttösäännöt voivat olla hyvinkin yksityiskohtaisia. Esimerkiksi julkishallinnon käyttösääntösuosituksissa on 36-sivua.14 Ne eivät tosin rajoitu oikeudellisiin riskeihin vaan erittelevät etenkin teknisiä riskejä joihin kuuluu varmistaa käytetyn komponentin takana olevan projektin elinvoimaisuus ja se, että komponentin ylläpitoon löytyy tarvittaessa vaihtoehtoinen toimittaja. Käyttösääntöjen toteuttaminen edellyttää, että avoin lähdekoodi otetaan huomioon jo ohjelmistotoimituksesta sovittaessa. Esimerkiksi julkishallinnon JIT 2007 yleisten ehtojen kohdassa 17(9) annetaan toimittajalle vastuu selvittää, mitä avoimen lähdekoodin komponentteja toimitukseen sisältyy. Kohdan mukaan toimittajan on lähtökohtaisesti vältettävä vastavuoroisuutta vaativien copyleft-lisenssien käyttöä siten, että niistä aiheutuisi velvoitteita asiakkaan muiden ohjelmistojen käyttöön: 13 Tämä jakso vastaa pääosin teoksen Välimäki (2009) jaksoa Ks. Avoimen lähdekoodin ohjelmien käyttö julkisessa hallinnossa, JHS-169, jhs169 18

21 Jos sopijapuolet sopivat avoimen lähdekoodin käyttämisestä, toimittaja ilmoittaa tilaajalle etukäteen avoimeen lähdekoodiin liittyvistä käyttöoikeutta koskevista ehdoista sekä muista ehdoista ja rajoituksista, joita tilaajan tulee avoimen lähdekoodin käytössä noudattaa. Mikäli toisin ei ole sovittu, toimittaja vastaa siitä, että avoimen lähdekoodin sopimuksen mukainen käyttö ei johda siihen, että tilaajan muihin ohjelmistoihin sovellettaisiin avoimen lähdekoodin käyttöoikeutta koskevia ehtoja. 3.4 Toiminta oikeudenloukkaustilanteissa Varotoimista huolimatta oikeudenloukkausriskeiltä ei voida koskaan varautua aukottomasti. Koska vastuu immateriaalioikeuden loukkauksesta on lähtökohtaisesti ankaraa eli loukkaajan vilpitön mieli ei vapauta korvausvelvollisuudesta, joutuu huolellisesti toimiva käyttäjä harkitsemaan tarkkaan, miten asianmukaiseen ja perusteltuun loukkausväitteeseen tulisi reagoida. Keskeisiä vaihtoehtoja ovat ainakin seuraavat: Ei tehdä mitään, ja toivotaan, että loukkausväitteen esittäjä jättää asian sillensä. Oikeudenkäynnin aloittaminen Suomessa edellyttää vahvaa asemaa ja uskoa omiin mahdollisuuksiin johtuen siitä, että jutun hävinnyt maksaa pääsääntöisesti vastapuolen oikeudenkäyntikulut. Lopetetaan loukatuksi väitetyn tuotteen käyttö ja korvataan se tai sen loukkaava osa vaihtoehtoisella ratkaisulla. Tämän vaihtoehdon käyttömahdollisuus riippuu luonnollisesti siitä, voidaanko loukkaus ohittaa, missä ajassa ja millä hinnalla. Maksetaan vaadittu summa. Käytännössä loukkausväitteitä sovitaan varmasti paljon, mutta sovinnoista on vaikea saada tietoa. Epäilemättä esimerkiksi suuret kansainväliset yritykset saavat viikoittain lukuisia loukkausväitteitä, ja jokainen niistä tutkitaan. Maksuun päätynevät vain sellaiset, joiden perusteet ovat kiistattomat ja uhka niin uskottava, että maksamalla kohtuullinen sovintosumma vältetään pitkä ja todennäköisesti tappiollinen oikeudenkäynti. Kiistetään loukkaus ja varaudutaan oikeudenkäyntiin. Oikeudenloukkauksia koskevat oikeudenkäynnit ovat melko harvinaisia. Joissakin tapauksissa hävitynkin oikeudenkäynnin kustannukset on mahdollista saada takaisin vakuutuksesta, jos se kattaa immateriaalioikeuden loukkaukset. Varsinainen oikeudenkäyttö alkaa usein turvaamistoimiprosessilla. Siinä vastapuolta voidaan esimerkiksi vaatia lopettamaan loukkaava toiminta tai vaihtoehtoisesti julkaisemaan lähdekoodi avoimen lähdekoodin ehtojen mukaisesti, mikäli lisenssiehtojen vastaisuus on ilmeistä. Pääasian oikeudenkäynnissä esimerkiksi tekijänoikeudenloukkauksesta voi seurata vain tekijänoikeuslain mukaiset seuraamukset. Näihin kuuluvat muun muassa kohtuullinen rahallinen hyvitys, vahingonkorvaus ja loukkaavien tuotteiden hävittäminen mutta ei esimerkiksi velvollisuutta julkaista lähdekoodia

22 4 Verkkokysely 4.1 Kyselyn sisältö ja suoritus Tämän selvityksen tärkein tavoite oli tuottaa empiiristä tietoa avoimeen lähdekoodiin liittyvistä oikeudellisista riskeistä. Tiedon kerääminen aloitettiin järjestämällä verkossa täytettävä kysely, josta ilmoitettiin syyskuussa 2009 Center of Open Source Softwaren (COSS) jäsenlistalla sekä Tietokone-lehden Lex Oksanen -blogissa. COSS:n jäsenlistalla on noin 150 avoimesta lähdekoodista kiinnostuneita yritystä ja julkisyhteisöä, ja Lex Oksanen blogilla tuhatkunta lukijaa. Kyselyyn saatiin yhteensä 55 hyväksyttyä vastausta. Kyselyssä pyrittiin selvittämään paitsi oikeudellisia riskejä ja niiden hallintaa myös yleisemmin missä vaiheessa avoimen lähdekoodin käyttö yhteisössä on ja miksi avointa lähdekoodia käytettiin. Kyselystä saatu data on tiivistetty seuraavassa esitettyihin kuvaajiin Kyselyn tulokset Aluksi pyrittiin selvittämään minkä tyyppisessä käytössä avoin lähdekoodi on (kuvaaja 1). Ehkä hieman yllättäen avointa lähdekoodia on käytössä lähes yhtä paljon työpöytäsovelluksissa (esimerkiksi Firefox, OpenOffice) kuin perinteisemmällä käyttöalueella järjestelmäpuolella (esimerkiksi Linux-serverit, MySQL ja Postgres tietokannat). Kysely vahvisti oletuksen, jonka mukaan ohjelmistoyrityksissä avointa lähdekoodia käytetään varsinkin erilaisissa työkaluissa ja tuotekehityksessä. Toiseksi kysyttiin syitä avoimen lähdekoodin käytölle (kuvaaja 2). Tässä oli joitakin eroja riippuen siitä, oliko vastaajana julkisyhteisö vai yritys. Helppo lisenssinhallinta sai paljon kannatusta, ja oli esimerkiksi julkisyhteisölle tärkeämpi tekijä kuin hinta. Ymmärrettävästi tekniset syyt kuten testattavuus, yhteensopivuus ja lähdekoodin muokattavuus olivat tärkeitä yrityksille. 15 Kyselylomake on tämän selvityksen liitteessä A. Kyselystä kertynyt data on saatavissa selvityksen laatijoilta excel-tiedostona. 20

23 Kuvaaja 1. Kyselyn mukaiset avoimen lähdekoodin sovellusalueet asteikolla 1 10, vastausten keskiarvot (1=ei lainkaan, 10=pelkästään) IT-infrassa Työpöytäsovellutuksissa Työkaluissa Ohjelmistoyritykset Muut yritykset Julkinen sektori Omien ohjelmien pohjana Kuvaaja 2. Kyselyssä raportoidut syyt avoimen lähdekoodin käytölle asteikolla 1 5, vastausten keskiarvot (1=ei tärkeä, 5=erittäin tärkeä) Tuote mahdollista testata etukäteen Yhteensopivuus Tuotteet tuttuja ylläpitäjille Tuotteet tuttuja käyttäjille Helppo lisenssinhallinta Ideologiset syyt Parempi käytettävyys Tietoturvallisuus Mahdollisuus muokkaamiseen Hinta Julkinen sektori Muut yritykset Ohjelmistoyritykset Oikeudellisia riskejä ja niiden hallintaa lähestyttiin kysymällä suunnatusti ohjelmistoyrityksiltä, miten nämä käyttävät juristeja (kuvaaja 3). Puolet vastanneista (14) ilmoitti käyttävänsä ulkopuolista asianajotoimistoa. Vain muutamalla oli oma juristi tai oma lakiosasto. Lisäksi lähes kolmannes ilmoitti, ettei käytä lainkaan juristeja. Osaltaan viimeksi mainittu tulos kuvastaa kuinka pieniä suomalaiset ohjelmistoyritykset keskimäärin ovat, ja toisaalta kuinka tärkeää näille on tarjota juridista perustietoa muita kanavia pitkin

24 Kuvaaja 3. Juristien käyttö ohjelmistoyrityksissä. 60 % 50 % 40 % 30 % 20 % 10 % 0 % Ulkopuolinen AA-toimisto Yrityksen oma juristi Yrityksen oma lakiosasto Yritys ei käytä juristeja Ei vastausta Kaikkia vastanneita pyydettiin arvottamaan joukko avoimeen lähdekoodiin liitettyjä oikeudellisia riskejä (kuvaaja 4). Ohjelmistopatentit raportoitiin kautta linjan pelätyimmäksi riskitekijäksi, Yhdysvallat ennen Eurooppaa. Tässä kohdin ohjelmistoyritysten vastauksessa oli merkittävä varianssi, joka ei näy kuvaajasta: mediaanivastaus patenttiuhasta Yhdysvalloissa oli 6 ja patenttiuhasta Euroopassa 5, mutta osa yrityksistä arvotti Yhdysvallat 0:ksi epäilemättä ne pienet yritykset, joilla ei ollut edes suunnitelmissa laajentaa toimintaa tai asiakaskuntaa valtameren toiselle puolelle. Huomionarvoista on, että avoimen lähdekoodin lisenssien keskinäinen yhteensopivuus nähtiin suuremmaksi ongelmaksi kuin kaupallisen ja avoimen lähdekoodin ohjelmien yhdistäminen. Perinteinen virhevastuu ( bugivastuu ) nähtiin yhtä vaikeaksi (tai helpoksi) ongelmaksi kuin virhe oikeudenloukkauksista kuten koodin kopioinnista. 22

25 Kuvaaja 4. Kyselyssä raportoidut oikeudelliset riskit asteikolla 1-6, vastausten keskiarvot (1=ei tärkeä, 6=erittäin tärkeä) Virhevastuu ulkopuolisten tuottamasta koodista Koodissa mukana luvatta kolmannen osapuolen koodia Avoinen la hdekoodin lisenssien yhteensopimattomuus Koodi loukkaa ohjelmistopatentteja USA:ssa Koodi loukkaa ohjelmistopatentteja EU:ssa Avoinen ja suljetun la hdekoodin lisenssinvastainen yhdista minen Julkinen sektori Muut yritykset Ohjelmistoyritykset Suurin osa yrityksistä toimii ilman erityistä prosessia avoimen lähdekoodin käytölle vaikkakaan prosessit eivät ole täysin vieraita (kuvaaja 5). Sisäiset toimintatavat avoimelle lähdekoodille ovat yleisempiä ohjelmistoyrityksissä, joissa lähes puolella oli käytössä sisäinen toimintapa. Tulokset vastaavat pitkälti aiempia kansainvälisiä selvityksiä.16 Kuvaaja 5. Vastaus kysymykseen onko yrityksellä prosessi avoimen lähdekoodin käytölle. Kyllä Ei Ohjelmistoyritykset Muut yritykset Ei vastausta Black Duckin keväällä 2009 julkaiseman tiedotteen mukaan noin 40%:lla suuryrityksistä on sisäiset käyttösäännöt avoimelle lähdekoodille. Ks. Black Duckin lehdistötiedote : Black Duck Survey Reveals Open Source Development Trends

26 Ohjelmistoyrityksiltä kysyttiin myös eri lisenssien käytöstä (kuvaaja 6). Tässäkään ei koettu mitään yllätyksiä. Suosituimmat lisenssit ovat laajassa käytössä. Ehkä kiinnostavana tietona vuonna 2007 julkaistu GNU GPL -lisenssin uusi versio 3 on yleistynyt nopeasti. Kuvaaja 6. Eri avoimen lähdekoodin lisenssien käyttö ohjelmistoyrityksissä. 100 % 90 % 80 % 70 % 60 % 50 % 40 % 30 % 20 % 10 % 0 % GPL2 Apache BSD tai MIT GPL3 LGPL PHP license Eclipse public license Muu OSI:n hyväksymä Affero License Oma EUPL Ohjelmistoyrityksiltä kysyttiin vielä, käyttivätkö nämä jotakin lisenssinhallintatyökalua selvittämään esimerkiksi lisenssiristiriitoja. Yli kaksi kolmasosaa ei käytä mitään työkalua. Neljä yritystä ilmoitti käyttävänsä TKK:lla kehitettyä Open Source License Checkeriä, kaksi Fossologyä ja kolme suurempaa yritystä kaupallista Black Duckia. Kuvaaja 7. Lisenssinhallintatyökalujen käyttö ohjelmistoyrityksissä Fossology OSLC BlackDuck Emme käytä 24

27 Lopuksi vastaajilla oli mahdollisuus esittää vapaasti ideoita avoimen lähdekoodin oikeudellisten riskien pienentämiseksi. Seuraavassa on muutama esille tullut näkökohta. Ensinnäkin avoimen lähdekoodin lisensseistä ja sisäisistä käyttösäännöistä: Lisenssimallien vähentäminen ja yksinkertaistaminen! Vapaiden ohjelmien lisenssien määrää vähennettävä. käytä tunnettuja projekteja, on hyvä olla samalla puolella IBM lakiosaston kassa Yhteinen rekisteri tunnetuimmista open source ohjelmistoista ja niihin liittyvistä lisensseistä yms. TEM voisi tuottaa julkisia lisenssi-, patentti- ja tekijänoikeusauditointeja tunnetuimmista ja käytetyimmistä OSS-ohjelmistoista. Näiden pohjalta yritysten olisi helppo päättää tietyn OSS-ohjelmiston käytöstä. - Määritellään prosessi avoimen lähdekoodin käyttöönotolle. Tämän ei tarvitse olla laaja prosessi pääasia, että asiaa on mietitty ja toteutetaan tietyt stepit. Ei uskota kaikkea, mitä projektin kotisivulla sanotaan. Esim. lisenssitsekkaus on hyvä tehdä asiakkaille toimitettavien koodien osalta. Käytetään tarvittaessa oikeudellisia palveluja, kuten Validos.org, COSS Helpdesk tai asianajotoimistojen palveluja Sitten osaamisesta ja koulutuksesta: SW juridiikan ja immateriaalioikeuden kompetenssitason ja tunnettuuden nosto oman organisaation sisällä. Enemmän tiedottamista lisenssien kehittymisistä ja käytännöllisistä ratkaisumalleista alan toimijoille. Ensinnäkin olisi syytä tiedottaa nykyisiä ammattilaisia ja ihan katto-organisaatioitakin siitä mistä ylipäätään on kyse, sillä Suomessa tunnutaan asiasta olevan monesti autuaan tietämättömiä. Koulutuksessakin voisi ehkä jossain mainita... Lopuksi patenteista: Patenttijärjestelmä hävitettävä, ainakin ohjelmistojen osalta. Ohjelmistopatenttien hylkääminen Patenttilainsäädännön selkeyttäminen (tai laissa jo olevan ohjelmapatenttien kiellon noudattaminen tiukemmin) Patenttilainsäädäntö kuntoon. Softapatentit ovat nykymuodossaan tarpeettomia ja jopa haitallisia. Ne ovat lähinnä suuryritysten etu, ja estävät uusien toimijoiden pääsyä markkinoille. Patenttien on katettava vain aika, joka on tarpeen keksinnön tekijän pääsemiseksi markkinoille, ja patenttiprosessit pitää muuttaa sellaisiksi että niiden hyväksikäyttö on mahdollista myös Nokiaa laihemmalla kukkarolla. Patenteista ei kukaan pidä, mutta ei meillä ole varaa astua ansaan niiden suhteen

28 5 Haastattelut 5.1 Haastatteluiden sisältö ja suoritus Empiiristä aineistoa laajennettiin tekemällä yhdeksän syvähaastattelua syyskuun ja marraskuun välisenä aikana Haastatelluiksi haettiin edustavia tahoja julkisen sektorilta, pienyrityksistä sekä myös alan suurimmista toimijoista Suomessa. Haastatelluiksi tulivat:17 1. Puolustusvoimat 2. Tampereen kaupunki 3. Avarea 4. Valtion IT-hallinnon johtamisyksikkö 5. CSC IT Center for Science 6. Tieto Oyj 7. Nokia Oyj 8. Monty Program 9. COSS Haastatteluissa käytettiin pohjana verkkokyselyn runkoa, jossa esitettyjä kysymyksiä pyrittiin vapaamuotoisessa keskustelussa avaamaan ja syventämään. Tämän lisäksi pyrittiin erityisesti löytämään niitä kysymyksiä, joita verkkokyselyssä ei ollut huomattu kysyä. Myöhemmissä haastatteluissa esille otettiin myös aikaisemmissa haastatteluissa nousseita asioita, mikä on osaltaan vaikuttanut tuloksiin. Haastatteluiden kesto vaihteli 45 minuutista lähes kolmeen tuntiin riippuen lähinnä haastateltavien perehtyneisyydestä aiheeseen. 5.2 Riskitietoisuusmalli Haastatteluiden ehkä keskeisin tulos oli, että oikeudellisten riskien hahmottaminen menee aalloissa. Ensimmäisessä vaiheessa avointa lähdekoodia pelätään ja esimerkiksi GNU GPL:n tarttuvuuden merkittävyyttä yliarvioidaan. Tämän jälkeen seuraa usein vaihe, jossa avoimen lähdekoodissa nähdään lähinnä mahdollisuuksia ja sen uskotaan tarjoavan helpon ja nopean tien tuotekehitykseen. Kun avointa lähdekoodia aletaan sitten tuomaan osaksi yrityksen tuotteita tai järjestelmiä, pelko oikeudellisista ongelmista nousee uudelleen ja esimerkiksi lisenssien yhteensopivuusongelmat koetaan merkittävä käytännön esteenä. Kun tuote on ollut jonkin aikaa markkinoilla tai palvelu käytössä ja avoimen lähdekoodin käyttöön luodut prosessit saatu kuntoon, pelko ja turhautuminen alkavat taas vähentyä. Ne asettuvat loppu- 17 Lista haastatelluista on tämän selvityksen liitteessä B. 26

29 jen lopuksi tasolle, jota voidaan pitää realistisena. Patenttiriskien merkitys nousee esiin vasta viimeisessä vaiheessa. Kuva 1. Avoimen lähdekoodin riskitietoisuusmalli. 1. Vaihe: spekulointi Skeptinen suhtauminen Ylireagointi GPL-lisenssiin 3. Vaihe: käyttöönotto Uudet ongelmatilanteet Lisenssien yhteensopivuus 2. Vaihe: ensikosketus Yleinen optimismi Riskien unohtaminen 4. Vaihe: vakiintunut käyttö Ammattimainen riskien hallinta Oikeuden loukkausriskit mukaan Seuraavaksi tässä selvityksessä käydään läpi yksittäisissä haastatteluissa nousseita tärkeimpiä aiheita siten, että samalla esille nousseet asiat pyritään myös liittämään mahdollisuuksien mukaan laajempaan kontekstiinsa. Haastattelut ovat järjestetty edellä esitetyn riskitietoisuusmallin mukaisesti siten, että pisimpään lähdekoodia käyttäneet toimijat esitellään viimeksi. CSC:stä alkaen haastateltavien voidaan katsoa kuuluvan viimeiseen luokkaan. 5.3 Puolustusvoimat Haastattelun perusteella Puolustusvoimissa avoimen lähdekoodin käyttö on tällä hetkellä marginaalista. Tosin haastattelun piiriin eivät kuuluneet mm. Tikkakoskella ja Riihimäellä toimivat elektronisen sodankäynnin yksiköt, mikä olisi voinut muuttaa kokonaiskuvaa. Avoimessa lähdekoodissa ei sinänsä nähty mitään erityisiä oikeudellisia ongelmia, jotka olisivat rajoittamassa sen käyttöä. Myöskään nykyisen hankintalainsäädännön ei koettu olevan merkittävä ongelma hankintojen kannalta. Kyse on lähinnä siitä, että nykyiset toimittajat eivät ole tarjonneet avoimen lähdekoodin tuotteita. Tilanteen arvioitiin kuitenkin olevan muuttumassa, erityisesti koska käyttöön otettujen palveluarkkitehtuuriperiaatteiden koettiin vauhdittavan kehitystä. Kansainvälisen tietojärjestelmien (erityisesti NATO) osalta avoin lähdekoodi ei ollut toistaiseksi tullut vastaan. Suomen puolustusvoimien tilanteelle mielenkiintoisen vertailukohdan voi hakea Yhdysvalloista. Siellä puolustusministeriö (Department of Defense) on tukenut pitkään avoimen lähdekoodin käyttöä ja julkaisee erityistä dokumenttia, jossa annetaan 26 27

30 yksityiskohtaisia neuvoja liittyen avoimen lähdekoodin ohjelmistojen käyttämiseen puolustusjärjestelmissä.18 Dokumentissa on myös tarkat ohjeet siitä, millä edellytyksillä julkiset hankinnat voidaan toteuttaa avoimella lähdekoodilla ja miten jo hankitut järjestelmät voidaan julkaista uudestaan avoimena lähdekoodina. Dokumentissa suositellaan käytettäväksi tunnetuimpia lisenssejä. 5.4 Tampereen kaupunki Tampereen kaupunki edusti haastattelussa suurta julkista käyttäjätahoa. Kaupungilla on n käyttäjää, työasemaa ja satoja palvelimia. Kaupungilla ei ole omaa ohjelmistotuotantoa, tosin oman työn ohella voidaan tehdä pienempiä projekteja. Käyttöympäristö on vakioitu ja kaupungin liikelaitos hoitaa lähes kokonaan tukipalvelut. Avointa lähdekoodia kaupungilla on käytössä lähinnä palvelimissa ja middleware-kerroksessa. Sen sijaan työpöytäohjelmistoissa avoin lähdekoodi ei ole vielä käytössä. Esimerkiksi toimisto-ohjelmisto Open Office tai selain Firefox eivät kuulu vakioituun ympäristöön. Avoimen lähdekoodin käytössä tai hankinnoissa ei nähty erityisiä ongelmia oikeudellisten kysymysten suhteen. Perusteluna tähän oli, että vastuu hankinnoista on siirretty sopimuspohjaisesti toimittajille. Kaupunki käyttää JIT-ehtoja. Kilpailutuksissa käytetään kokonaistaloudellisuutta tärkeimpänä hankintakriteerinä. Tältä osin kaupungilla ei kuitenkaan ollut tiettyä vakioitua laskentapohjaa käytössä. Julkisen sektorin yleistä aktiivisuutta alueella arvioitiin toistaiseksi matalaksi. Erittäin potentiaalisena pidettiin Kunta-IT:tä ja sen hanketta kohti kumppanuutta, jossa on Tampereen lisäksi mukana kuusi kuntaa. Hankkeessa pyritään tuotettujen ohjelmistojen täyteen avoimuuteen. Tosin tiedossa ei vielä ollut, miten kysymys hankintayksiköstä ratkaistaan ilmeisesti Tampere tilaa toteutuksen ja muut kunnat osallistuvat kustannuksiin. Ehkä tärkeimpänä rajaavana tekijänä kuntien suhteen pidettiin oman ohjelmistotuotannon puuttumista. Tämän vuoksi kunnat ovat helposti toimittajien armoilla valittavien ratkaisuiden suhteen. Alan kilpailutilanteen kiristyminen on kuitenkin johtamassa avoimen ratkaisujen suosintaan, koska niissä kustannuksia saadaan lisenssikulujen puuttuessa painetuksi alas. 5.5 Avarea Avarea on liiketoimintatiedon hallintaan, varastointiin ja esittämiseen sekä projektihallintaan erikoistunut pienyritys. Yrityksellä ei ole tällä hetkellä vielä tuotteita, joissa käytettäisiin laajemmin avointa lähdekoodia. Yrityksen tarkoituksena 18 DoD Open Source Software (OSS) FAQ, htm 28