Martin von Willebrand's Blog

Artikkeli: 10 myyttiä avoimen lähdekoodin juridiikasta ja riskeistä

Näkökulma: Artikkelin myytit on valittu ison organisaation ostajan näkökulmasta, joskin myytit ovat tätä yleisempiä.

A. Johdanto

Avoin lähdekoodi tietojärjestelmissä ei ole ihmeellinen tai uusi asia. Avoimen lähdekoodin hyödyntämisessä on kyse ohjelmistoista, siinä missä suljetun lähdekoodin hyödyntämisessäkin.

Avointa lähdekoodia ei tule kohdella kuin jotain erityistä ilmiötä, sitä tulee kohdella ohjelmistoina. Ohjelmistoja on hyviä ja huonoja ja niiden lisensiointi voi olla yritykselle sopivaa tai epäsopivaa. Tämä soveltuu sekä avoimiin että suljettuihin ohjelmistoihin. Yrityksen tulee katsoa yksittäisiä ohjelmistoja ja niiden soveltuvuutta yrityksen tarkoituksiin. Yrityksen ei yleensä ole järkevää lukittautua yhteen ohjelmistoon tai yhteen lisensiointimalliin.

Ohjelmistoja tulee arvioida samoin kriteerein, olivat ne avoimia tai suljettuja. Arvioinnissa ohjelmiston avoimuus on käyttäjäyritykselle käytännössä aina vain etu, sillä avoimen ohjelmiston arviointi on helpompaa ja lisenssien myöntämä käyttämis-, muuttamis- ja monistamisvapaus on etu.

Lähtökohtaisesti avoimen lähdekoodin arviointiprosessit voisivat olla samoja kuin suljettujen ohjelmistojen arviointiprosessit. Kuitenkin avointa lähdekoodia voidaan hankkia ja käyttää huomattavasti enemmän ja joustavammin kuin erikseen ostettavia suljettuja osia: näin arviointitilanteiden lukumäärä kasvaa. Lisäksi avoimen lähdekoodin arviointiprosesseissa on tiettyjä samankaltaisuuksia silloin, kun kyseessä on avoin lähdekoodi (mm. yleisesti käytettyjä lisenssejä, lähdekoodi saatavilla, kehitysprojekti tutkittavissa jne.). Tämän johdosta voi olla tehokkaampaa luoda erillinen prosessi avoimen lähdekoodin (tai internetistä ladattavien ohjelmien) arviointia ja hyväksyntää varten.

B. Totuudet ja niihin liittyvät myytit

1. myytti: Avoimen lähdekoodin ohjelmistoja ei tueta
2. myytti: Avoin lähdekoodi tarttuu tietojärjestelmiin
3. myytti: Tehdyt muokkaukset pitää julkaista
4. myytti: Suljetut järjestelmät pitää julkaista, jos käyttää avointa lähdekoodia
5. myytti: Freeware ja shareware ovat avointa lähdekoodia
6. myytti: Avoimen lähdekoodin lisensiointi on sekavaa ja aiheuttaa riskejä
7. myytti: Julkaisemalla open sourcea luopuu tekijänoikeudestaan ja patenttioikeuksistaan
8. myytti: Open Source on tietoturvatonta
9. myytti: Isot yritykset eivät käytä open sourcea
10. myytti: Julkisena hankintana ei voi hankkia avointa lähdekoodia

1. Myytti: Avoimen lähdekoodin ohjelmistoja ei tueta

Totuus 1: Tukea on saatavilla monipuolisesti avoimelle lähdekoodille, mutta ei jokaiselle internetistä ladattavalle ohjelmalle (oli lisensiointi suljettua tai avointa). Tuki vaatii työtä (joko omaa tai toisen) ja työ maksaa.

Laajasti käytettyjen avoimen lähdekoodin projektien osalta tuki on varsin monipuolista. Saatavilla voi olla:

–         maksullista tukea projektia ylläpitävältä organisaatiolta,

–         maksullista tukea paikalliselta ja muilta organisaatiolta,

–         maksullista koulutusta ja opastusta,

–         julkisia käyttäjäkokemuksia ja ratkaisuja käyttäjien ongelmiin (maksuton),

–         julkisia resursseja tikettien raportointiin ja seurantaan (maksuton),

–         dokumentaatiota: niin maksullista kuin maksutonta ja

–         vaikutusmahdollisuuksia.

Monipuolisuus mahdollistaa sekä hankitun tuen, että itse tuotettavan tuen. Se, että käyttäjäorganisaatio, voi tuottaa tukea myös omatoimisesti, ei ole heikkous vaan vahvuus.

Toisaalta tietyn ohjelmiston tukimahdollisuudet tulee selvittää ohjelmistokohtaisesti. Löytyy paljon ohjelmistoa – niin suljettuja kuin avoimia – joiden tukikäytännöt eivät vastaa käyttäjäorganisaation toiveita.

2. Myytti: Avoin lähdekoodi tarttuu tietojärjestelmiin

Totuus 2: Mitään tarttumista ei ole olemassa. Kyse on väärinkäsityksestä ja itse asiassa moninkertaisesta väärinkäsityksestä. Väärinkäsitys on lähtenyt liikkeelle Microsoftin Steve Ballmerin haastattelulausunnosta Chicago Sun-Timesille vuonna 2001.

Ballmer on lausunnossa kuvannut avointa lähdekoodia syöväksi, joka tarttuu ja siirtyy yrityksen tietojärjestelmään. Joskus on myös käytetty niin ikään virheellistä termiä ”virusvaikutus”.

Ensinnäkin ajatuksen taustalla oleva vastavuoroisuus on ymmärretty väärin. Vastavuoroisuudella tarkoitetaan sitä, että jos ohjelman haluaa luovuttaa edelleen muokattuna, tulee omat muokkaukset antaa vastaanottajalle samalla lisenssillä kuin ohjelma on tullut. Jos tätä ehtoa ei noudata, ei ole oikeutta levittää alkuperäistä ohjelmaa. Noudattamatta jättämisen seurauksena on mm. tekijänoikeusloukkaus, mutta ei mitään tarttumista (tai automaattista lisenssin tarttumista yrityksen tekijänoikeuden alaiseen ohjelmaan).

Toiseksi vastavuoroisuusvelvollisuus koskee vain tiettyjä lisenssejä, ei avointa lähdekoodia yleisesti (GPLv2 on yleisin esimerkki lisenssistä, joka sisältää vastavuoroisuusvelvollisuuden).

Kolmanneksi vastavuoroisuusvelvollisuus ei kosketa lainkaan oman organisaation sisäistä käyttöä tai kopiointia organisaation sisällä. Palvelun tarjoamista vastavuoroisuusvelvollisuus ei myöskään kosketa, paitsi erikoistapauksissa (esim. Affero GPL).

Neljänneksi vastavuoroisuusvelvollisuutta pitää noudattaa silloin, kun ohjelmaa levittää. Noudattamatta jättämisen seuraus on se, että alkuperäistä (esim. GPLv2-lisenssin alaista) ohjelmaa ei saa levittää. Mikäli silti levittää, on seurauksena tavanomaiset seuraukset, kuten hyvitysmaksuvelvollisuus tekijänoikeuden loukkauksesta.

3. Myytti: Tehdyt muokkaukset pitää julkaista

Totuus 3: Tämäkin on väärinkäsitys. Mikään tunnettu avoimen lähdekoodin lisenssi ei sisällä julkaisuvelvollisuutta. Joidenkin lisenssien mukaan niiden alaisen ohjelmiston lähdekoodi tulee pitää lisenssinsaajan saatavilla eli sen saatavilla, jolle yritys avoimen lähdekoodin ohjelmiston luovuttaa. Toisin sanoen ei ole velvollisuutta luovuttaa lähdekoodia kenelle tahansa, yleisölle, eikä edes alkuperäiselle projektille.

Lisäksi kannattaa huomioida, että lähdekoodin luovutusvelvollisuus koskee vain tiettyjä avoimen lähdekoodin lisenssejä ja aina vain sitä ohjelmistoa, jota kyseinen lisenssi koskee. Lähdekoodin luovutusvelvollisuus ei siis koske yrityksen jollain muulla lisenssillä julkaiseman ohjelmiston lähdekoodia. Lähdekoodin luovutusvelvollisuus koskettaa myös vain levitystilanteita, ei koskaan yrityksen sisäisiä käyttötilanteita.

4. Myytti: Suljetut järjestelmät pitää julkaista, jos käyttää avointa lähdekoodia

Totuus 4: Tämä on yhdistelmä myyttejä 2 ja 3. Kuvitellaan, että lisenssit hyppivät ohjelmistosta toisiin itsestään ja niiden mukaan pitäisi lähdekoodeja julkistaa. Myytit 2 ja 3 kumottiin edellä, joten tämäkin on kumottu.

5. Myytti: Freeware ja shareware ovat avointa lähdekoodia

Totuus 5: Kaikki internetistä ladattavat ohjelmistot eivät ole avointa lähdekoodia. Freeware nimitystä käytetään lisenssimaksuttomasta, mutta suljetusta ohjelmistosta. Shareware on freewarea, josta on esimerkiksi poistettu joitakin toiminnallisuuksia käytöstä tai rajoitettu käyttö testiperiodiin. Toiminnallisuudet saa käyttöön maksamalla lisenssimaksun tai vastaavan.

6. Myytti: Avoimen lähdekoodin lisensiointi on sekavaa ja aiheuttaa riskejä

Totuus 6: Lisensiointia on monen tasoista. Toiset ovat esimerkillisiä (esim. Apache Software Foundationin projektit) ja toiset vaihtelevan tasoisia. Kuitenkin lisensiointi on yleisesti arvioiden helposti selvitettävissä, joskin se vaatii hiukan työtä. Jos hiukan kiinnittää huomiota lisensiointiin, riskit ovat varsin pienet, jopa täysin minimaaliset.

Loppukäyttäjän näkökulmasta on myös hyvä todeta, että teoreettiset riskitkin koskevat käytännössä vain levittäjiä, ei ohjelmiston käyttäjiä.

Asiaa voidaan arvioida muutamalla eri tavalla:

–         Monet avoimen lähdekoodin projektit käyttävät tunnettuja lisenssejä ja niiden lukemiseen ei sen takia kulu juurikaan aikaa. Suljetut projektit käyttävät järjestään projekti-spesifejä lisenssejä, jotka ovat pahimmillaan monikymmensivuisia.

–         Kaikki avoimen lähdekoodin projektit eivät ole kertoneet lisensioinnista parhaalla mahdollisella tavalla. Tätä varten pitää tehdä jonkinasteista selvittelytyötä. Tätä varten on olemassa hyviä työkaluja (avoimen lähdekoodin, erityisesti Fossology[1]) ja lisää syntyy koko ajan. Myös palveluita on tarjolla.[2] Erityisesti nämä työkalut ja palvelut auttavat levittäjiä; loppukäyttäjät tarvitsevat näitä yleensä vasta, kun he alkavatkin levittää toisille organisaatioille avoimen lähdekoodin ohjelmistoja. Suljetuissa projekteissa samoja kysymyksiä ei yleensä voida selvitellä.

–         Suomessa on vuosittain useita it-projektiriitoja, mutta tiedossa ei ole yhtään avoimeen lähdekoodiin kohdistunutta riitaa. Maailmanlaajuisesti tuomioistuimen päätökseen on päätynyt noin kymmenen oikeustapausta. Näissä vastaajina on lähes aina ollut laitevalmistaja. Määrä on minimaalinen it-projektien lukumäärään verrattuna.

–         Avoimen lähdekoodin piirissä toimivat yhteisöt suosittelevat julkisuudelta piilossa tapahtuvaa yhteistoimintaa yritysten kanssa asioiden selvittämiseksi.[3]

7. Myytti: Julkaisemalla avointa lähdekoodia luopuu tekijänoikeudestaan ja patenttioikeuksistaan

Totuus 7: Avoimen lähdekoodin lisensiointi perustuu tekijänoikeuden pidättämiseen ja sitten lisenssin myöntämiseen. Tekijänoikeudenhaltijalla on valta päättää lisensioinnista ja halutessaan myös muuttaa lisensiointia tulevissa julkaisuissaan. Tekijänoikeudenhaltija antaa lisenssissä päättämänsä oikeudet. Niiden mukana voi olla patentteja koskevia oikeuksia.

Ajoittain esitetään käsityksiä, että avoin lähdekoodi olisi jotenkin vierasta markkinataloudelle tai että se rikkoisi sen perustavia lainalaisuuksia. Nämä perustuvat immateriaalioikeuksien väärinymmärrykseen ja avoimen lähdekoodin projektien toimintalogiikan huonoon tuntemukseen.

Projekteissa tekijänoikeudella ja siihen liittyvillä projektin toimintaperiaatteilla on keskeinen merkitys. Nämä vaikuttavat päätöksentekoon projektissa ja yhteisön dynamiikkaan. Yritys, joka perustaa avoimen lähdekoodin projektin, voi itse valita toimintatapansa. Tekijänoikeuden, projektin tavaramerkin ja verkkotunnuksen haltijan rooli on keskeinen, sillä näillä on valta päättää projektin sisällöstä (mitä julkaistaan) sekä lisenssistä. Nämä voivat myös päättää muutoksista. Yleensä päätöksentekovallan pidättäminen vaikuttaa yhteisön dynamiikkaan toimeliaisuutta vähentävästi.

Mikäli yritys osallistuu jo olemassa olevaan projektiin, on ratkaisevaa projektin käytännöt erilaisten kontribuutioiden käsittelemisestä.

8. Myytti: Avoin lähdekoodi on tietoturvatonta

Totuus 8: ”Avoin lähdekoodi” ei ole tietoturvamielessä oikea arvioinnin kohde. Oikea arvioinnin kohde on tietty ohjelmisto. Ohjelmistojen tietoturvataso (oli ohjelmisto avointa tai suljettua) vaihtelee.

Avoimen lähdekoodin ohjelmistojen osalta kuka tahansa voi tutkia ohjelmiston toimintaperiaatetta ja mahdollisia tietoturvaheikkouksia. Tämä nähdään yleensä yksinomaan etuna, koska tietoturvalliseksi ratkaisuksi mielletään ratkaisut, joiden tietoturva perustuu julkisiin tietoturvakäytäntöihin. Ratkaisut, joiden tietoturva perustuu siihen, että aukkoja on hankalampi löytää suljetun koodin vuoksi, mielletään yleensä haavoittuvaisemmiksi. Yksittäistilanteissa tämä voi olla toisinkin.

Kuitenkin laajasti käytetyillä avoimen lähdekoodin ohjelmistoilla on se etu, että monet ovat voineet tutkia käytettyjä tietoturvaratkaisuja detaljoidusti. Julkisuus tukee myös löydettyjen haavoittuvuuksien nopeaa paikkaamista.

9. Myytti: Isot yritykset eivät käytä open sourcea

Totuus 9: Isot yritykset käyttävät avointa lähdekoodia erittäin paljon ja koko ajan vain enemmän.

–         Hewlett-Packard raportoi jo vuonna 2003 saavansa 2,5 miljardia (USD) Linux-liitännäistä liikevaihtoa

–         Red Hat:in (Red Hat Linux-jakelun ylläpitäjä) liikevaihto oli keväällä 2010 päättyneellä tilikaudella noin 800 miljoonaa (USD)

–         Forrester raportoi 2009, että 23 % eurooppalaisista ja amerikkalaisista yrityksistä ilmoitti, että eivät käytä avointa lähdekoodia[4] –> eli 77 % oli sitä mieltä, että käyttävät

–         Oikeusministeriö ja sen hallinnonala otti käyttöön Open Officen noin 10.000 työaseman organisaatiossa.

–         Maailmanlaajuisesti ison toimittajan ilmailuelektroniikkajärjestelmät ovat vuonna 2010 avointa lähdekoodia (lähdettä ei paljasteta)

–         Accenture (elokuu, 2010): 38 % haastatelluista isoista yrityksistä (yli 500 miljoonaa USD/vuosi) aikoo siirtää toimintakriittisiä järjestelmiä avoimeen lähdekoodiin.[5]

10. Myytti: Julkisena hankintana ei voi hankkia avointa lähdekoodia

Totuus 10: Avoimen lähdekoodin hankinta julkisena hankintana on mahdollista ja tarjouspyynnössä voidaan myös vaatia toimitettavaksi vain avoimen lähdekoodin ohjelmistoja.

Mahdollisuus vaatia avointa lähdekoodia perustuu siihen, että avoin lähdekoodi käsitteenä ei ole ohjelmisto, brändi tai toimittaja, vaan kyseessä on vain yleinen kuvaustapa ohjelmistoa koskevan lisenssin tietyistä ominaisuuksista. Käsitteen alla olevia ohjelmistoja ja brändejä on lukuisia ja toimittajia on useita. Jos kunta haluaa voida käyttää hankkimaansa ohjelmistoa vapaasti ja muuttaa sitä ja tarvittaessa jakaa sitä, se voi tällaisen vaatimuksen esittää. Vaatimuksen voi nimittää avoimeksi lähdekoodiksi, mutta on selvempää kirjoittaa se auki.

Hankintayksikkö voisi myös vaatia hankinnassa tekijänoikeuksia itselleen (ei yleensä järkevää), joten laaja lisensiointi – esim. avoin – on tästäkin näkökulmasta mahdollinen vaatimus.

Julkisissa hankinnoissa tulee noudattaa tasapuolisuuden ja syrjimättömyyden vaatimusta. Tämä tarkoittaa muun muassa sitä, että hankintaa ei yleensä tule määritellä niin, että on vain yksi mahdollinen toimittaja.

Sen sijaan tarjouspyynnössä ei yleensä voi vaatia Ubuntua ja Zentyalia (brändiä). Sen sijaan voisi hankkia sähköpostijärjestelmän, jota on oikeus käyttää vapaasti, muokata ja levittää edelleen. Vaatimus voi olla myös Microsoft-yhteensopiva sähköpostijärjestelmä (tai Zentyal-yhteensopiva).

Hankintayksikkö voi vaatia tietojärjestelmältään vapaata käytettävyyttä, muutettavuutta ja edelleen levitettävyyttä. Vain erikoistapauksissa – esimerkiksi jos vain yksi toimittaja pystyisi tällaisen toimittamaan – voisi tällainen muodostua syrjiväksi.

Oikeudellisesta kysymyksestä kokonaan erillinen kysymys on käytännöllinen kysymys siitä, miten joku tietty hankinta kokonaisuutena kannattaa toteuttaa. Tähän kysymykseen vaikuttavat tarjonta markkinoilla ja tietojärjestelmien elinkaarikustannukset.

Mikäli avoimen lähdekoodin toimittajia ei ole, ei ehkä kannata vaatia avointa lähdekoodia. Tämä tilanne kuitenkin on kokonaan loppumassa. Toisaalta, ostajan ja ostajien etu voi usein olla viedä markkinoita avoimen lähdekoodin suuntaan.

Elinkaarikustannusta koskeva analyysi on ohjelmisto tai ratkaisukohtainen ja siinä ohjelmiston lisensiointitapa – avoin tai jonkinlainen suljettu – on vain mauste. Lisensiointi ei ratkaise elinkaarikustannusta suuntaan tai toiseen, joskin avoimuus on vaikkapa muuten yhtäläisten järjestelmien tilanteessa ostajan kannalta sekä käytännöllinen että strateginen etu.

JHS 169-suositus

JHS 169-suosituksen, kohta 6.4, mukaan[6] (Avoimen lähdekoodin ohjelmien käyttö julkisessa hallinnossa):

”Jos ”monistettavuuden” vaatimus tai arviointiperuste esitetään tarjouspyynnössä, se tulee esittää yleisellä tasolla viittaamatta tiettyihin ohjelmistolisensseihin. Näin vertailu on tasapuolinen sekä perinteisten suljettujen että avoimen lähdekoodin ratkaisujen tarjoajille.”

JHS:n mukaan suositeltava muotoilu tarjouspyynnössä on esimerkiksi: ”Tilaajalla on oikeus muokata ohjelmistoa tarkoituksiinsa sopivaksi ja niin halutessaan jakaa ohjelmistoa lähdekoodeineen eteenpäin kolmansille osapuolille ilman rojalteja tai muita maksuja.”

JHS-suosituksessa (kohta 6.6) myös esitetään vaihtoehdot ohjelmiston hankkimiseen avoimen lähdekoodin lisenssillä. Vaihtoehtoina on 1) määritellä hankittavan ohjelmiston lisensiointi avoimen lähdekoodin periaatteilla (periaatteet kuvaten), 2) määritellä hankintayksikölle määräysvalta lisensioinnista päättämiseen ja 3) hankkia ohjelmisto tekijänoikeuksineen.

EU:n avoimen lähdekoodin hankintaopas

EU:n komission IDABC on teettänyt ohjeistuksen avoimen lähdekoodin julkisia hankintoja varten[7]. Kyseessä ei ole komission virallinen kannanotto.

Avoimen lähdekoodin hankintaopas on sisällöllisesti samoilla linjoilla kuin JHS 169-suositus. Tarjouspyynnössä avoin lähdekoodi voi olla vaatimuksena, joskaan se ei sellaisenaan takaa kilpailutuksen tasapuolisuutta. Tarjoajien rajaaminen eri tavoilla voi myös muodostua syrjiväksi.

IDABC:n hankintaopas kuvaa myös mahdollisuutta käyttää avoimuutta pisteytyksessä siten, että avoin lisensiointi on tarjoajille etu.

Martin von Willebrand
Asianajotoimisto HH Partners Oy, osakas
www.hhpartners.fi