JHS 169 Avoimen lähdekoodin ohjelmien käyttö julkisessa hallinnossa

  • Versio: 1.1 5.10.2012
  • Julkaistu: 23.02.2009
  • Voimassaoloaika: Toistaiseksi

Sisällys

  1. 1 Johdanto
  2. 2 Soveltamisala
  3. 3 Termit ja määritelmät
  4. 4 Suositukset
  5. 4.1 Huomioi ohjelmistojen jakaminen ja uudelleenkäyttö hankinnoissa
  6. 4.2 Julkaise muokatut ohjelmistot avoimella lisenssillä
  7. 4.3 Käytä avoimia standardeja ja rajapintoja
  8. 4.4 Tarkista lisenssin avoimuus
  9. 4.5 Varmista riittävä asiantuntemus käyttöönotossa
  10. 4.6 Kartoita ja vertaile vaihtoehtoja
  11. 4.7 Selvitä tietoturvariskit
  12. 5 Johdanto avoimeen lähdekoodiin
  13. 5.1 Avoimen lähdekoodin evoluutio
  14. 5.2 Avoimen lähdekoodin ohjelman määritelmä
  15. 5.3 Tietokoneohjelman lähdekoodi
  16. 5.4 Avoimen lähdekoodin ohjelma kaupallisena ohjelmana
  17. 5.5 Avoimet rajapinnat ja standardit
  18. 5.5.1 Avoimet rajapinnat
  19. 5.5.2 Avoimet standardit
  20. 5.6 Yhteenveto avoimen lähdekoodin hyödyistä ja haasteista
  21. 5.6.1 Hyötyjä
  22. 5.6.1.1 Ohjelmistokehityksen nopeutuminen
  23. 5.6.1.2 Paikallisten toimijoiden kilpailuedellytysten parantaminen
  24. 5.6.1.3 Toimittajariippuvuuden pieneneminen ja vapaa kilpailutus
  25. 5.6.1.4 Yhteiskunnallinen riippumattomuus
  26. 5.6.1.5 Kustannussäästöt
  27. 5.6.1.6 Kansalaisten yhdenvertaisuuden paraneminen
  28. 5.6.1.7 Lähdekoodin tarkistettavuus
  29. 5.6.1.8 Ohjelmiston avoimen jakamisen edut ja versionhallinnan haasteet
  30. 5.6.2 Haasteita
  31. 5.6.2.1 Avoimen lähdekoodin ohjelmistojen saatavuus ja sopivuus
  32. 5.6.2.2 Kaupallisten toimijoiden löytäminen
  33. 5.6.2.3 Ylläpito- ja muutoksenhallinta
  34. 5.6.2.4 Avoimen lähdekoodin käyttöönoton vaatimat omat resurssit (oma käyttöönotto)
  35. 5.7 Avoimen ja suljetun lähdekoodin vertailutaulukko
  36. 5.8 Avoimen lähdekoodin liiketoiminta
  37. 5.9 EU:n linjaukset suhteessa avoimiin ohjelmistoihin ja standardeihin
  38. 5.10 Avoin lähdekoodi muissa suosituksissa
  39. 6 Avoin lähdekoodi ja hankintaprosessi
  40. 6.1 Toimintamalleja esiselvitysvaiheeseen
  41. 6.1.1 Perehdy avoimien ohjelmien mahdollisuuksiin ja erityispiirteisiin
  42. 6.1.2 Vaatimusmäärittely ja esiselvitysvaihe ovat olennaisia onnistuneen ohjelmisto- tai järjestelmähankinnan kannalta
  43. 6.2 Seitsemän askelta avoimen lähdekoodin ohjelmiston mahdollisuuden arviointiin
  44. 6.3 Avoimen ohjelmiston ja suljetun ohjelmiston hankinnan erot
  45. 6.4 Esiselvitysvaiheessa avoimiin ohjelmistoihin liittyvät erityispiirteet
  46. 6.5 Avoimiin ohjelmistoihin liittyvät erityiskysymykset tarjouspyyntöä laadittaessa ja arvioitaessa
  47. 6.5.1 Kelpoisuuskriteereihin kuuluvat laatutekijät
  48. 6.5.1.1 Referenssit
  49. 6.5.1.2 Henkilöstön pätevyys
  50. 6.5.1.3 Toimitusvarmuus
  51. 6.5.2 Tarjousten vertailuun liittyvät tekijät
  52. 6.5.2.1 Kokonaisratkaisun soveltuvuus
  53. 6.5.2.2 Hinta
  54. 6.6 Ohjelmiston hankkiminen avoimen lähdekoodin lisenssillä
  55. 7 Avoimen lähdekoodin juridisia kysymyksiä
  56. 7.1 Tekijänoikeus ja avoimen lähdekoodin ohjelmistolisenssit
  57. 7.1.1 Nykytila
  58. 7.1.2 Avoimen lähdekoodin lisenssit
  59. 7.1.3 Lisenssityyppejä
  60. 7.1.3.1 Sallivat lisenssit
  61. 7.1.3.2 Vastavuoroisuutta edellyttävät lisenssit
  62. 7.1.3.3 Vahvaa vastavuoroisuutta edellyttävät lisenssit
  63. 7.1.4 Vastuukysymykset ja avoimen lähdekoodin lisenssit
  64. 7.2 Avoimen lähdekoodin riskit ja niiden hallinta
  65. 7.2.1 Riskianalyysin osa-alueet
  66. 7.2.1.1 Vaihtoehtoisten toimittajien saatavuus
  67. 7.2.1.2 Takuut ja vastuut
  68. 7.2.1.3 Avoimen lähdekoodin tuotteiden elinkaari
  69. 7.2.1.4 Lähdekoodin saatavuuden merkitys
  70. 7.2.1.5 Teknologiariskit
  71. 7.2.2 Menettelytavat riskien hallintaan
  72. 7.2.3 Hankintatapaan liittyvien riskien arviointi
  73. 7.2.3.1 Itsenäinen hankinta
  74. 7.2.3.2 Ulkoinen toimittaja
  75. 7.2.4 Tuotteen elinkelpoisuuden arviointi
  76. 7.2.5 Tuotteen jatkokehityksen arviointi
  77. 7.2.6 Riskien tarkistuslista
  78. 7.3 JIT 2007 ja avoin lähdekoodi
  79. 7.3.1 Yleistä
  80. 7.3.2 JIT ja avoimen lähdekoodin erityisehdot
  81. 7.3.3 JIT:n yleiset ehdot
  82. 8 Opastavat tiedot
  83. 8.1 Suosituksen ylläpito
  84. 8.2 Liitteet

1 Johdanto

Tämän suosituksen tarkoitus on opastaa julkisen hallinnon organisaatioita avoimen lähdekoodin ohjelmistojen hankinnassa ja käyttöönotossa. Suositus keskittyy julkisen hallinnon toimijoihin ohjelmistojen hankkijana ja käyttäjänä. Muun muassa seuraavat kysymykset liittyvät oleellisesti avoimeen lähdekoodiin:

  • Missä määrin avoimen lähdekoodin ohjelmistojen käytöllä voidaan pienentää ohjelmistohankintojen kokonaiskustannuksia?
  • Miten ja millaisin edellytyksin voidaan parantaa tietojärjestelmien yhteentoimivuutta ja joustavuutta, kun käytetään avoimen lähdekoodin ohjelmistoja?
  • Missä määrin avoimen lähdekoodin avulla voidaan vähentää tietojärjestelmien hankintaan liittyviä riskejä?
  • Millä tavoin julkisen sektorin hankintoja koskevaa lainsäädäntöä ja ohjeistusta tulee soveltaa avoimen lähdekoodin hankintaan? Millaisilla hankintakäytännöillä turvataan erilaisten lisensointimallien ja niihin perustuvien liiketoimintamallien tasapuolinen kohtelu ja vapaa kilpailu?

Suositus on jaettu kolmeen päälukuun:

  • Luku 5. Johdanto avoimeen lähdekoodiin tarjoaa perustiedot avoimesta lähdekoodista ja kertoo EU:n linjauksista, jotka liittyvät sen käyttöön.
  • Luku 6. Avoin lähdekoodi ja hankintaprosessi käsittelee erityispiirteitä avoimen lähdekoodin ohjelmiston hankinnassa.
  • Luku 7. Avoimen lähdekoodin juridisia kysymyksiä sisältää tietoa avoimen lähdekoodin lisensseistä, riskeistä ja niiden hallinnasta. Luvussa tarkastellaan myös Julkisen hallinnon IT-hankintojen yleisiä sopimusehtoja (JHS 166, JIT 2007).

Varsinaiset suositukset on koottu lukuun 4. Niissä todetaan muun muassa, että ohjelmiston hankinta kannattaa tehdä siten, että hankittava ohjelmisto voidaan tarvittaessa jakaa hallinnon ja kansalaisten keskuudessa. Parhaiten ohjelmiston jakamisen edellytykset turvataan käyttämällä avoimen lähdekoodin lisenssejä. Kun avoimen lähdekoodin ohjelmistoon tehdään tai teetetään muutoksia, tulee kehitystulokset julkaista avoimen lähdekoodin lisenssillä, ellei kehitystyön sulkemiseen ole erityistä perustetta.

2 Soveltamisala

Tämä suositus koskee julkisen hallinnon tietohallintoa ja erityisesti tietojärjestelmien ja ohjelmistojen hankintaa, mutta sitä voidaan hyödyntää myös yksityissektorilla.

3 Termit ja määritelmät

Avoimen lähdekoodin lisenssi

Avoimen lähdekoodin lisenssit täyttävät Open Source Initiativen (OSI) avoimen lähdekoodin määritelmän ehdot (ks. avoin lähdekoodi). Ne antavat lisenssinsaajalle oikeuden käyttää, kopioida, levittää ja muokata ohjelmaa vapaasti. OSI ylläpitää listaa hyväksymistään avoimen lähdekoodin lisensseistä.

http://www.opensource.org/licenses

Avoimen lähdekoodin ohjelma

Ks. avoin ohjelma.

Avoin lähdekoodi

Open Source Initiative lanseerasi avoin lähdekoodi (engl. open source) -termin vuonna 1998. Sen julkaisema kymmenkohtainen avoimen lähdekoodin määritelmä voidaan tiivistää viiteen oikeuteen: Avoimen lähdekoodin ohjelman käyttäjä saa automaattisesti

  1. käyttää ohjelmaa mihin tarkoitukseen tahansa
  2. kopioida ja levittää ohjelmaa
  3. luoda ohjelman muunnelmia ja levittää niitä
  4. ohjelman lähdekoodin, jota hän voi hyödyntää
  5. yhdistää ja levittää ohjelmaa toisten ohjelmien kanssa.

Termi avoin lähdekoodi voidaan käytännössä vaihtaa termiin vapaa ohjelma.

http://www.opensource.org/

Avoin ohjelma

Avoin ohjelma on tietokoneohjelma, jota jaellaan jollakin avoimen lähdekoodin lisenssillä. Tiukasti tulkiten kyse on ”avoimen lähdekoodin ohjelmasta”, mutta tässä suosituksessa käytetään myös termin lyhyempää versiota.

Avoin standardi

European Interoperability Frameworkin (EIF) mukaan avoimen standardin täytyy täyttää seuraavat ehdot:

  • Standardia ylläpitää voittoa tavoittelematon organisaatio ja sitä kehitetään kaikille sidosryhmille avoimella ja tasapuolisella menettelyllä.
  • Standardi on julkaistu ja sen määrittelydokumentti on tarjolla ilmaiseksi tai nimellistä maksua vastaan (myös kopiointi, jakelu ja käyttö).
  • Standardia ja sen osia voidaan käyttää pysyvästi ilman teollisoikeudellisia korvauksia.
  • Standardin uudelleenkäyttöä ei ole rajoitettu.

Escrow

Lähdekoodin escrow-menettelyssä ohjelmiston lähdekoodi talletetaan kolmannen osapuolen, nk. escrow-agentin haltuun. Ohjelmiston toimittaja ja hankkija tekevät sopimuksen. Siinä määritellään ehdot, joiden mukaan escrow-agentti on velvollinen luovuttamaan ohjelmiston lähdekoodin hankintayksikölle. Tällaisia tilanteita voivat olla esimerkiksi toimittajan konkurssi tai ohjelman ylläpidon päättyminen.

European Union Public Licence (EUPL)

EUPL on Euroopan komission hyväksymä avoimen lähdekoodin lisenssi, jota saa kaikilla EU:n virallisilla kielillä. Lisenssissä on huomioitu EU:n juridinen viitekehys, joten se on EU-maissa laillisesti pitävä. EUPL on yhteensopiva mm. GPL-lisenssin version 2 kanssa.

http://www.osor.eu/eupl/

Free Software Foundation (FSF)

Vuonna 1985 perustettu voittoa tavoittelematon järjestö, jonka tarkoituksena on edistää tietokoneen käyttäjien vapauksia ja puolustaa vapaiden ohjelmien käyttäjien oikeuksia. FSF on luonut vapaan ohjelman määritelmän ja julkaissut avoimen lähdekoodin GPL- ja LGPL-lisenssit.

http://www.fsf.org/

Freeware

Tietokoneohjelman jakelumalli, jossa ohjelmaa saa yleensä käyttää, kopioida ja levittää ilman maksua. Freeware-ohjelman lähdekoodia ei yleensä ole saa, eikä lisenssinsaajalle anneta vastaavia vapauksia kuin avoimen lähdekoodin lisenssin haltijalle. Tämä suositus luokittelee freeware-ohjelman suljetuksi ohjelmaksi.

Free software

Ks. vapaa ohjelma.

GNU General Public License (GPL)

Yleisin avoimen lähdekoodin lisenssi, joka takaa kyseisellä lisenssillä lisensoitujen ohjelmien käyttäjille avoimen lähdekoodin ja vapaan ohjelman määritelmien mukaiset vapaudet. Lisenssistä on olemassa nykyään kaksi laajasti käytössä olevaa versiota (GPL 2.0 ja GPL 3.0).

http://www.gnu.org/copyleft/gpl.html

Hankinta

Tässä suosituksessa hankinnalla tarkoitetaan tavaran, hyödykkeen tai palvelun vastikkeellista hankkimista julkisia hankintoja koskevan lainsäädännön tarkoittamalla tavalla.

IDABC

IDABC Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens) on Euroopan komission DG DIGIT:n alainen ohjelma, jonka avulla tähdätään tietotekniikan parempaan käyttöön yleiseurooppalaisissa sähköisissä hallinnollisissa prosesseissa (PEGS; Pan-European eGovernment Services). IDABC tekee suosituksia EU:n tavoitteenasettelun näkökulmasta hyödyntäen kulloinkin parasta ammatillista saatavilla olevaa osaamista.

http://ec.europa.eu/idabc/

Käyttöönotto

Käyttöönotolla tarkoitetaan tässä suosituksessa organisaation tai sen toimittajan suorittamia toimenpiteitä, joilla tietty järjestelmä tai ohjelmisto otetaan käyttöön.

Open Source Initiative (OSI)

Vuonna 1998 perustettu voittoa tavoittelematon organisaatio, jonka tarkoituksena on edistää avoimen lähdekoodin ohjelmistojen käyttöä. OSI on lanseerannut käsitteen open source, suomeksi avoin lähdekoodi, ja se ylläpitää avoimen lähdekoodin määritelmää.

http://www.opensource.org/

OSOR

OSOR (Open Source Observatory and Repository for European public administrations) on Euroopan unionin IDABC-ohjelman alainen hanke, joka edistää vapaiden ja avoimien ohjelmistojen käyttöä ja hyviä tietohallintokäytäntöjä EU:n julkisella sektorilla. OSOR sisältää myös julkisen sektorin ohjelmakoodi- ja dokumentaatiovaraston. Näin avoimen lähdekoodin mallin mukaista avointa lähdekoodia voidaan jakaa ja hyödyntää edelleen. Sen avulla myös mahdollista osallistua kehitystyöhön.

http://www.osor.eu/

Open source

Ks. avoin lähdekoodi.

Shareware

Tietokoneohjelman jakelumalli, jossa ohjelmaa saa yleensä kopioida ja levittää vapaasti ja käyttää tietyn aikaa maksutta. Shareware-ohjelman lähdekoodi ei yleensä ole saatavilla, eikä lisenssinsaajalle anneta vastaavia vapauksia kuin avoimen lähdekoodin lisensseissä. Tämä suositus luokittelee shareware-ohjelman suljetuksi ohjelmaksi.

Suljettu lähdekoodi

Avoimen lähdekoodin vastakohta siinä mielessä, että ohjelmiston lähdekoodi pidetään liikesalaisuutena, eikä lisenssinsaajalle anneta pääsyä ja oikeuksia lähdekoodiin.

Suljettu ohjelma

Tietokoneohjelma, jonka lähdekoodi ei ole käyttäjän saatavilla ohjelman toiminnan tarkastamista tai kehittämistä varten. Lisenssiehdot eivät salli ohjelman muuttamista ja muutosten julkaisua.

Tarttuvuus

Tarttuvuudella tai vahvalla vastavuoroisuuden velvoitteella tarkoitetaan ominaisuutta, joka edellyttää ohjelman julkaisemista alkuperäisellä lisenssillä kopioissa ja muunnelmissa sekä myös silloin, kun ohjelmaan yhdistetään uusia elementtejä esimerkiksi linkittämällä. Yleisin tarttuva lisenssi on GPL.

Toimittajariippuvuus

Toimittajariippuvuudella (engl. vendor lock-in) tarkoitetaan tilannetta, jossa asiakas lukkiutuu tiettyyn tuotteeseen ja tuotteen tai palvelun toimittajaan. Monesti tilanteessa syntyy nk. de facto -monopoli, koska vaihtamisesta kilpailevaan tuotteeseen syntyisi liian suuret kustannukset. Ohjelmistoissa suljetut ohjelmistot voivat muodostaa tällaisen tilanteen, koska yleensä kukaan muu kuin ohjelmiston kehittäjäyhtiö tai sen valtuuttamat myyntikanavat eivät voi tarjota palveluja hankitulle ohjelmistolle.

Vapaa ohjelma

Vapaata ohjelmaa voi käyttää mihin tarkoitukseen tahansa Sitä voi muokata ja levittää vapaasti, niin alkuperäisiä kuin muokattujakin versioita. Ohjelman toiminnan tutkiminen ja muokkaaminen edellyttää pääsyä ohjelman lähdekoodiin. Termin ja määritelmän taustalla on Free Software Foundation. Sen voi käytännössä vaihtaa termiin avoin lähdekoodi.

4 Suositukset

4.1 Huomioi ohjelmistojen jakaminen ja uudelleenkäyttö hankinnoissa

Ohjelmiston hankinta kannattaa tehdä siten, että hankittava ohjelmisto voidaan tarvittaessa jakaa hallinnon ja kansalaisten keskuudessa. Parhaiten ohjelmiston jakamisen edellytykset turvataan käyttämällä avoimen lähdekoodin lisenssejä.

4.2 Julkaise muokatut ohjelmistot avoimella lisenssillä

Kun avoimeen ohjelmistoon tehdään tai teetetään muutoksia ja lisäyksiä, tulee kehitystulokset julkaista avoimen lähdekoodin lisenssillä, ellei kehitystyön sulkemiseen ole erityistä perustetta, esim. tietoturva tai tietosuoja.

4.3 Käytä avoimia standardeja ja rajapintoja

Avoimia standardeja ja rajapintoja käyttämällä varmistetaan mahdollisimman suuri liikkumavara tulevaisuudessa.

4.4 Tarkista lisenssin avoimuus

Avointa ohjelmistoa hankittaessa on tarkistettava, että ohjelmiston lisenssi täyttää Open Source Initiativen avoimen lähdekoodin määritelmän. Markkinoilla on ohjelmistoja, joita markkinoidaan avoimina, vaikka niitä ei saa muokata tai jaella edelleen. OSI:n hyväksymien avoimen lähdekoodin lisenssien lista on osoitteessa http://www.opensource.org/licenses.

4.5 Varmista riittävä asiantuntemus käyttöönotossa

Ohjelmiston omatoimisessa käyttöönotossa on huolehdittava, että käyttäjäorganisaatiolla on riittävästi omaa osaamista ja resursseja evaluoida vaihtoehtoiset ratkaisut ja suorittaa käyttöönotto. Useimmissa tapauksissa ulkopuolisen asiantuntijapalvelun hankkiminen on suositeltavaa.

4.6 Kartoita ja vertaile vaihtoehtoja

Tarjolla oleviin vaihtoehtoihin tulee perehtyä huolellisesti ennen ohjelmiston valintaa ja verrata niiden ominaisuuksia organisaation tarpeisiin. Kannattaa myös kartoittaa muiden organisaatioiden kokemuksia ja suunnitelmia vastaavista hankinnoista. Yhteistyöhön kannattaa pyrkiä – voidaan esimerkiksi sopia kustannusten jakamisesta

4.7 Selvitä tietoturvariskit

Mikäli käyttöön otettava ohjelmisto on osa kriittistä infrastruktuuria tai siinä käsitellään salaista tietoa, tulee varmistaa, ettei lähdekoodin avoimuus muodosta uhkaa tietoturvalle tai tietosuojalle.

5 Johdanto avoimeen lähdekoodiin

5.1 Avoimen lähdekoodin evoluutio

Avoimen lähdekoodin ohjelma on tietokoneohjelma, jonka lisenssi takaa ohjelman käyttäjälle useita perinteisiä tietokoneohjelman lisensointisopimuksia laajempia vapauksia. Tietokoneohjelman lähdekoodin vapaa saatavuus ei sinänsä ole uusi asia, vaan sitä on tapahtunut niin kauan kuin tietokoneohjelmia on ollut olemassa. Tänä aikana avoimen lähdekodin käsite on saanut uusia sävyjä ja sen liiketoiminnallinen merkitys on muuntunut.

Avoimen lähdekoodin evoluutioprosessissa voidaan erottaa kolme vaihetta:

  • free software - vapaa ohjelma
  • open source - avoin lähdekoodi
  • commercial open source - kaupallinen avoin lähdekoodi

Ensimmäisessä vaiheessa luotiin käsite vapaa ohjelma (engl. free software). Se korostaa vuonna 1985 perustetun Free Software Foundationin (FSF) vapaan ohjelmistokehityksen ja ohjelmistojen käyttäjien vapauden ideaalia. FSF:n tavoitteena on muuttaa ohjelmistoliiketoimintaa siten, että se turvaa määrittelemiensä perusvapauksien toteutumisen. FSF:n luoma GPL-lisenssi on keskeinen työkalu tämän päämäärän saavuttamisessa.

Toisessa vaiheessa luotiin käsite avoin lähdekoodi (engl. open source). Siinä vapauden eettiset periaatteet siirrettiin sivummalle. Yritykset, ohjelmistokehityksen hajautettu prosessi ja kehittäjien välinen avoin yhteistoiminta nousivat keskiöön. Vuonna 1998, perustettiin avoimen lähdekoodin lisenssejä hyväksyvä ja lisenssilistaa ylläpitävä Open Source Initiative (OSI), jota myös ohjelmistoteollisuus alkoi laajamittaisesti tukea. Sen ympärille organisoitui kasvava kehittäjäyhteisö.

Kolmannelle vaiheelle, kaupalliselle avoimelle lähdekoodille (engl. commercial open source), on tyypillistä avoimen lähdekoodin hyödyntäminen osana perinteisesti lisensoituja kaupallisia tuotteita, palveluita ja alan vakiintuneita liiketoimintamalleja. Avoimen lähdekoodin käytön avulla pyritään erityisesti pienentämään kustannuksia ja lisäämään kehitysnopeutta. Tyypillisiä ilmiöitä ovat suljetun ja avoimen lähdekoodin teknologioita yhdistävät mixed source -tuotteet, joihin sisältyy sekä avoimia että suljettuja komponentteja. Lisäksi tarjotaan ohjelmistoja palveluina (SaaS, Software as a Service). Tämä kehitysvaihe alkoi noin vuonna 2005.

5.2 Avoimen lähdekoodin ohjelman määritelmä

Avoimen lähdekoodin ohjelmalla ei ole yhtä standardoitua määritelmää, eikä avoin lähdekoodi ole juridinen termi. Yhdysvaltalainen voittoa tavoittelematon Free Software Foundation (FSF) loi 1980-luvulla termin free software (vapaa ohjelma) ja niin ikään yhdysvaltalainen Open Source Initiative (OSI) loi vuonna 1998 termin open source (avoin lähdekoodi).

Julkishallinnon näkökulmasta käsitteillä ei ole merkittävää sisällöllistä eroa, sillä ne molemmat sisältävät samat käyttöön, kopiointiin, muokkaamiseen ja levittämiseen liittyvät perusvapaudet. Open Source Initiativen määritelmä on yleisimmin viitattu erityisesti yritysmaailmassa. Esimerkiksi JIT 2007 -ehdoissa (JHS 166) siihen viitataan määriteltäessä avointa lähdekoodia.

Open Source Initiativen määritelmän mukaan avoimen lähdekoodin ohjelman tulee täyttää seuraavat vaatimukset:

  1. Ohjelman täytyy olla vapaasti levitettävissä ja välitettävissä.
  2. Lähdekoodin täytyy tulla ohjelman mukana tai olla vapaasti saatavissa.
  3. Johdettujen teosten luominen ja levitys pitää sallia.
  4. Lisenssi voi rajoittaa muokatun lähdekoodin levittämistä vain siinä tapauksessa, että lisenssi sallii korjaustiedostojen ja niiden lähdekoodin levittämisen. Lisäksi voidaan vaatia, ettei johdettua teosta levitetä samalla nimellä tai versionumerolla kuin lähtöteosta.
  5. Yksilöitä tai ihmisryhmiä ei saa asettaa eriarvoiseen asemaan.
  6. Käyttötarkoituksia ei saa rajoittaa.
  7. Kaikilla ohjelman käsiinsä saaneilla on samat oikeudet.
  8. Lisenssi ei saa olla riippuvainen laajemmasta ohjelmistokokonaisuudesta, jonka osana ohjelmaa levitetään, vaan ohjelmaan liittyvät oikeudet säilyvät, vaikka se irrotettaisiin kokonaisuudesta.
  9. Lisenssi ei voi asettaa ehtoja muille ohjelmille. Ohjelmaa saa levittää myös yhdessä sellaisten ohjelmien kanssa, joiden lähdekoodi ei ole avointa.
  10. Lisenssin sisällön pitää olla riippumaton teknisestä toteutuksesta. Oikeuksiin ei saa liittää varaumia jakelutavan tai käyttöliittymän varjolla.

5.3 Tietokoneohjelman lähdekoodi

Lähdekoodi sisältää ohjelman tekijöiden kirjoittamat käskyt ja ohjeet, joiden avulla tietokone saadaan toimimaan halutulla tavalla. Jotta tietokone ymmärtää syötettyjä käskyjä, lähdekoodi on useimmiten käännettävä niin sanottuun suoritettavaan muotoon ennen sen ajamista tietokoneessa.

Ohjelman käännetty, suoritettava muoto ei ole ihmisen tulkittavissa. Koska suljetuissa ohjelmissa lähdekoodi yleensä pidetään liikesalaisuutena eikä siihen anneta muutos- ja levitysoikeuksia, ei hankintayksiköllä ole teknisiä ja juridisia edellytyksiä tai oikeuksia tutkia ohjelman toteutusta tai tehdä tai teettää muutoksia ohjelmaan. Lähdekoodin avoimuuden ja sallivien lisenssiehtojen myötä hankintayksikkö tai mikä tahansa kolmas osapuoli voi tarkastaa tai muuttaa avoimen lähdekoodin ohjelman toteutusta.

Harva käyttäjä ja hankintayksikkö katsoo tarvitsevansa lähdekoodia, sillä hankinnathan koskevat tietokoneohjelmia ja tietojärjestelmiä. Lähdekoodin avoimuudella voi kuitenkin olla hankintayksikölle suuri merkitys. Tärkein etu on suurempi riippumattomuus toimittajasta. Kun toimituksen kuuluu lähdekoodi ja oikeus käyttää sitä ohjelman toiminnan muuttamiseen, voidaan pienentää yhden toimittajan varaan joutumisen riskiä. Tällöin joku muukin kuin ohjelmiston alkuperäinen kehittäjä voi huolehtia kehityksestä ja ylläpidosta ja tehdä muut mahdolliset työt.

On hyvä huomata, että esimerkiksi kriittisten tai erityisiä läpinäkyvyysvaatimuksia sisältävien järjestelmien toteutus voidaan haluta tarkastaa ennakolta. Ohjelmistoissa tämä on mahdollista tehdä ainoastaan käymällä läpi ohjelmiston lähdekoodi.

5.4 Avoimen lähdekoodin ohjelma kaupallisena ohjelmana

Avoimen lähdekoodin ohjelmia pidetään usein virheellisesti ei-kaupallisina niiden vapaan jakelumallin vuoksi. Avoimen lähdekoodin lisenssit eivät kuitenkaan estä kaupallisen liiketoiminnan harjoittamista. Markkinoilla toimii laaja joukko yrityksiä, joiden ratkaisut ja palvelut perustuvat avoimen lähdekoodin ohjelmistoihin. Lisäksi monet suljetun lähdekoodin ratkaisuja tarjoavat yritykset harjoittavat liiketoimintaa myös avoimen lähdekoodin ohjelmistoilla: mallit eivät sulje toisiaan pois. Monet kaupalliset, suljetut ohjelmistot sisältävät avoimen lähdekoodin teknologiaa.

Avoimen lähdekoodin ohjelmista ei makseta lisenssimaksuja, mikä ymmärrettävästi luo mielikuvan ei-kaupallisista ilmaisohjelmista. Lisenssimaksujen sijaan useat kaupalliset avoimen lähdekoodin toimijat tarjoavat avoimen lähdekoodin ohjelmiin liittyviä palveluja, jolloin liiketoiminta syntyy palveluista eikä lisenssimyynnistä. Kaupallisten ja ei-kaupallisten ohjelmistojen sijaan onkin mielekkäämpää erotella avoimiin ohjelmistoihin ja suljettuihin ohjelmistoihin perustuva liiketoiminta.

Taulukko 1. Eräitä tunnusmerkkejä avoimen ja suljetun ohjelmiston liiketoiminnassa.

Avoin ohjelmisto

Suljettu ohjelmisto

Toimittajien määrä

Ohjelmisto saatavissa useilta toimittajilta

Ohjelmisto saatavissa vain yhdeltä toimittajalta

Liiketoiminta

Painopiste palveluissa

Painopiste lisensseissä ja niiden jakelutavassa

Perinteisten kaupallisten ohjelmistojen rinnalla käytössä on myös laajasti ns. shareware- ja ilmaisohjelmistoja (freeware), jotka usein virheellisesti yhdistetään avoimeen lähdekoodiin. Näitä ohjelmistoja saa ohjelmien mukana tulevien käyttöehtojen perusteella yleensä kopioida ja levittää vapaasti ja myös käyttää tietyissä rajoissa. Ohjelmien mukana ei kuitenkaan tule lähdekoodia eikä avoimen lähdekoodin perusvapauksia, joten niitä ei voi esimerkiksi kehittää itsenäisesti edelleen. Lisäksi monissa shareware-tuotteissa osa kehittyneemmistä ominaisuuksista on sidottu maksun suorittamiseen, joten ohjelmistoa ei voi käyttää täysipainoisesti ostamatta siihen lisenssiä. Ilmaisohjelmien käyttöoikeus voi olla rajattu esimerkiksi vain ei-kaupalliseen toimintaan.

5.5 Avoimet rajapinnat ja standardit

Ohjelmiston lähdekoodin avoimuus ei takaa yhteentoimivuutta eikä helppoa liitettävyyttä muihin ohjelmistoihin, vaan niihin tarvitaan avoimia ohjelmistorajapintoja ja standardeja. Suljettuun ohjelmistoon verrattuna lähdekoodin avoimuus mahdollistaa ohjelmiston toiminnallisuuden tutkimisen ja muuttamisen, jolloin yhteentoimivuus on periaatteessa saavutettavissa.

5.5.1 Avoimet rajapinnat

Avoimilla rajapinnoilla tarkoitetaan sellaisia ohjelmistoon toteutettuja vapaasti käytettäviä, huolellisesti dokumentoituja liittymäpintoja, joiden välityksellä ohjelmistot vaihtavat tietoja keskenään. Rajapinta voi tarjota esimerkiksi henkilön tietojen haun tietokannasta henkilötunnuksen perusteella.

Avoin lähdekoodi ei sellaisenaan takaa ohjelman vaivatonta liitettävyyttä toisiin ohjelmiin. Mikäli avoimen lähdekoodin ohjelman rajapinta on heikosti toteutettu tai dokumentoitu, voi ohjelman liitettävyys olla suuritöinen. Myös suljetut ohjelmistot voidaan liittää toisiin ohjelmistoihin silloin, kun niissä on käytetty avoimia rajapintoja ja avoimien standardien mukaisia tiedonkuvaustapoja.

5.5.2 Avoimet standardit

Avoimet standardit lisäävät kilpailua ja pienentävät riippuvuutta toimittajasta. Niillä parannetaan ohjelmiston yhteentoimivuutta muiden ohjelmistojen kanssa, mikä lisää ohjelmiston ja tuotetun sisällön käyttö- ja jälleenhyödyntämismahdollisuuksia. Avoimen lähdekoodin projekteille on tyypillistä, että niissä noudatetaan avoimia ja yleisiä standardeja, jos se vain on järkevää ja mahdollista.

5.6 Yhteenveto avoimen lähdekoodin hyödyistä ja haasteista

Hyödyt ja mahdolliset haasteet ja riskit riippuvat avoimen lähdekoodin käyttötavasta ja -laajuudesta. Jos käytetään esimerkiksi ohjelmia työasemissa ja palvelimissa organisaation sisällä, monet avoimen lähdekoodin juridiset riskit jäävät kokonaan pois. Jos tuotetta muutetaan ja levitetään, on huomioon otettavia asioita puolestaan paljon enemmän. Toisaalta osallistumisella avoimen lähdekoodin projekteihin voidaan saavuttaa paljon enemmän hyötyjä kuin pelkällä passiivisella hyödyntämisellä.

5.6.1 Hyötyjä

5.6.1.1 Ohjelmistokehityksen nopeutuminen

Avoimen lähdekoodin avulla voidaan nopeuttaa joustavien ja innovatiivisten IT-ratkaisujen rakentamista ja alentaa kustannuksia hyödyntämällä valmiita ohjelmia ja ohjelmakomponentteja.

5.6.1.2 Paikallisten toimijoiden kilpailuedellytysten parantaminen

Koska avoin lähdekoodi on kaikkien toimijoiden käytettävissä, tarjoutuu mahdollisuus kasvavalle kilpailulle ja lisääntyneelle yrittäjyydelle. Myös paikalliset, pienet kasvuyritykset saavat mahdollisuuden osallistua julkisen hallinnon toimituksiin. Näin uudet uudet toimijat pääsevät helpommin markkinoille.

5.6.1.3 Toimittajariippuvuuden pieneneminen ja vapaa kilpailutus

Avoimen lähdekoodin takaamat vapaudet pienentävät riskiä toimittajariippuvuudesta. Kun käytetään avointa lähdekoodia, ei toimittaja voi markkinoilta poistuessaan viedä tukea mukanaan. Avoimissa ohjelmistoissa ei tarvita suljetun lähdekoodin sovelluksissa sovellettavaa lähdekoodin rajoitettua luovuttamista escrow-menettelyllä.

Kun yksi yritys ei voi kontrolloida ohjelman hyödyntämisessä tarvittavia tietoja ja oikeuksia, kaikki ohjelmistoon liittyvät toimenpiteet voidaan kilpailuttaa. Vapaa kilpailutus on mahdollista tuotteen elinkaaren kaikissa vaiheissa.

Jotta palveluiden kilpailu aidosti toimisi, on markkinoilla oltava useita kyvykkäitä palveluntarjoajia. Vähän käytetyissä ohjelmissa kilpailu voi olla vähäistä, mutta ohjelman suosion kasvaessa tilanne voi nopeasti muuttua.

5.6.1.4 Yhteiskunnallinen riippumattomuus

Kokonaisuudessaan avoin lähdekoodi vähentää yhteiskunnan riippuvuutta ja haavoittuvuutta. Esimerkiksi kauppapoliittisten kriisitilanteiden aikana voidaan luottaa siihen, että pakottavassa tapauksessa voidaan itse ylläpitää toiminnallisuutta tai toimittaa ylläpito paikalliselta alihankkijalta.

5.6.1.5 Kustannussäästöt

Avoimen lähdekoodin ratkaisut voivat alentaa ohjelmistohankintojen kustannuksia. Suurimmat säästöt voidaan saada vapaalla kilpailutuksella, jolloin ei olla riippuvaisia toimittajista ja lisenssit ovat maksuttomia. Kokonaistaloudellisuuden laskeminen voi olla haastavaa, sillä säästöt voivat olla suoria (ei lisenssimaksuja) tai epäsuoria (yhteentoimivuus tulevaisuudessa mahdollisesti hankittavan järjestelmän kanssa). Investointilaskelmissa on otettava huomioon ohjelmiston koko elinkaaren kustannukset.

Seuraavassa on listattu eräitä avoimen lähdekoodin mahdollisia kustannussäästöjä:

  • Ei lisenssimaksuja. Avoimien ohjelmien oikeuksien antamisesta ei saa periä rojalteja tai muita maksuja.
  • Kaikkien palveluiden vapaa kilpailutus tuotteen koko elinkaaren ajan, myös järjestelmästä toiseen siirryttäessä. Toimittajaa voidaan vaihtaa tarvittaessa ja eri palveluihin voidaan valita eri toimittaja, mikäli näin halutaan.
  • Pilotointi ja kokeilu sangen pienellä riskillä. Tämä voidaan lopettaa heti, jos huomataan, että ratkaisu ei toimi tai on liian työläs. Näin riski sitoutua sopimattomiin ja vähäkäyttöisiin ratkaisuihin pienenee.
  • Oman ja avoimen lähdekoodin yhteisön osaamisen hyödyntäminen.
  • Yhteistyön tekeminen muiden organisaatioiden kanssa esimerkiksi ohjelmistoja levittämällä.

Mitään ohjelmistoa ei tosiasiassa voida ottaa ilmaiseksi käyttöön, sillä käyttöönottotyö ei ole kulutonta edes itse tehtynä. Mikäli ohjelmisto ladataan verkosta, tulee ohjelmiston käyttöönotosta ja ylläpidosta vastaavan henkilöstön varata riittävästi aikaa ohjelmiston omaehtoiseen opiskeluun, evaluointiin ja käyttöönottoon. Usein on lisäksi hankittava osaamista organisaation ulkopuolelta.

5.6.1.6 Kansalaisten yhdenvertaisuuden paraneminen

Koska avoimen lähdekoodin tuotteet voidaan luovuttaa vastikkeetta eteenpäin, kaikilla kansalaisilla on periaatteessa yhdenvertaiset mahdollisuudet niiden hyödyntämiseen. Esimerkiksi organisaatio, joka tuottaa jotain sähköistä materiaalia jaettavaksi suurelle ihmismäärälle, voi avointen ohjelmistojen avulla tarjota vapaasti materiaalin käyttöön tarvittavia ohjelmistoja. Tilastokeskus on ratkaissut tällä tavalla tilastotietojen levittämisen ongelman: samalle tallennusmedialle on tilastotietojen taulukkoaineiston lisäksi tallennettu avoimen lähdekoodin toimisto-ohjelmisto, jolla aineisto voidaan avata muokattavaksi. Tätä ohjelmistoa ei kuitenkaan tarvitse asentaa, jos käyttäjällä on jo valmiina ohjelmisto, joka osaa avata kyseiset taulukkolaskentadokumentit. Tilastokeskuksen ei tarvitse maksaa lisenssi- tai muita lupamaksuja ohjelmiston sisällyttämisestä tallennusmedialle.

5.6.1.7 Lähdekoodin tarkistettavuus

Avoimen lähdekoodin ratkaisut voivat joissakin turvallisuuskriittisissä tapauksissa olla lähdekoodin escrow-menettelyn ohella ainoita vaihtoehtoja, joilla ohjelmisto voidaan tarkistaa esimerkiksi haittaohjelmien ja piilotettujen toiminnallisuuksien osalta. Kaikki suljettujen ohjelmistojen lähdekoodin katselmointimahdollisuudet eivät kuitenkaan mahdollista sovelluksen kääntämistä luovutetuista lähdekoodeista. Tällöin suljetulla puolella ei voida saavuttaa lopullista varmuutta ajettavan ohjelman ominaisuuksista.

5.6.1.8 Ohjelmiston avoimen jakamisen edut ja versionhallinnan haasteet

Lähdekoodin julkinen saatavuus on avoimen lähdekoodin kehityksen eteenpäin vievä voima. Kuka tahansa voi kehittää ohjelmaa ja jakaa tekemänsä muutokset muille, jolloin muutkin hyötyvät. Lähdekoodin avaamista avoimen lähdekoodin projektiksi voidaan harkita, mikäli organisaatio päätyy tilanteeseen, jossa valmista ohjelmistoa ei ole kohtuullisin ehdoin tai lainkaan olemassa, vaan sellainen kannattaa tehdä tai teettää omana tuotekehityksenä.

Jos lähdekoodin osana käytetään valmiita komponentteja ja päätetään levittää omaakin lähdekoodia, niin kannattaa etukäteen selvittää käytettyjen komponenttien lisenssien yhteensopivuus sekä lähdekoodin jakamisesta aiheutuvat velvoitteet. Mikäli ohjelmistokehityksessä käytetään ulkopuolista asiantuntija-apua, on jo tarjouspyyntövaiheessa huomioitava lähdekoodin jakelumahdollisuus ja kirjattava tarjouspyyntöön reunaehdot tuotettavan lähdekoodin lisenssille.

Julkishallinnossa ohjelmiston jakaminen voi olla erittäin edullista, jos toimintaympäristö on jokseenkin vakioitu, jos samanlaisia hallinnollisia prosesseja on kaikkialla hallinnossa ja kaikkia koskee sama lainsäädäntö,. Avoimia ohjelmistoja voi jakaa vapaasti muille ja muut organisaatiot voivat ottaa niitä käyttöön ja saavuttaa näin säästöjä. Lähdekoodin avoimella lisenssillä jakeluun luovuttava taho saavuttaa etuja, mikäli muut organisaatiot tekevät tai teettävät ohjelmistoon parannuksia, jotka voidaan ottaa käyttöön. Ohjelmiston laajempi käyttö voi synnyttää yhteistyötä organisaatioiden välillä esimerkiksi ohjelmiston kehittämisessä, jolloin kustannuksia voidaan jakaa.

Ero suljettujen ohjelmistojen toimintamalliin on merkittävä. Siinä asiakkaan rahoilla tehdyt parannukset jäävät useimmiten ohjelmiston toimittajan omaisuudeksi ja niiden jatkohyödyntäminen edellyttää kaupankäyntiä tämän nimenomaisen yrityksen kanssa.

Julkisen jakelun mallissa on kuitenkin tekninen haaste, joka suljettujen ohjelmien mallissa kuuluu ohjelmistotaloille: ohjelmiston eri versioiden hallinta. Kun ohjelmistoon tehdään muutoksia, pitää olla menettelytapa, jolla varmistetaan, että versiot voidaan erottaa toisistaan. Tätä kutsutaan versionhallinnaksi.

Vaikka versionhallinta ei ole pakollista, se on käytännössä välttämätöntä, jotta ohjelmiston kehitys pysyisi hallittavana prosessina. Jos versionhallintaa ei tehdä, ohjelmiston kehitys haarautuu useiksi rinnakkaisiksi versioiksi, jotka saattavat olla keskenään yhteen sopimattomia. Tällainen kehitys ei ole toivottavaa.

Oheiseen taulukkoon 2 on tiivistetty ohjelmistojen avoimella lisenssillä jakamisen etuja ja haittoja verrattuna siihen, että ohjelmistoa ei jaeta. On syytä huomata, että oikeanpuoleinen sarake pätee niin suljettujen ohjelmistojen käyttöön kuin siihenkin, että organisaatio ostaa ohjelmiston lähdekoodeineen ja päättää olla jakamatta sitä.

Taulukko 2. Ohjelmiston jakaminen verrattuna jakamatta jättämiseen.

Ohjelmisto jaetaan julkisesti avoimella lisenssillä

Ohjelmistoa ei jaeta julkisesti

Muut voivat käyttää ohjelmistoa ja hyötyä siitä.

Muut voivat käyttää ohjelmistoa maksamalla siitä sen omistajalle.

Muut voivat kehittää ohjelmistoa edelleen ja jakaa muutoksiaan muille. Näin kaikki voivat hyötyä kehityksen tuloksista.

Ainoastaan ohjelmiston omistaja tai sen valtuuttama taho voi kehittää ohjelmistoa.

Mielekäs kehitys edellyttää versionhallintaa. Tämä vaatii ostaja- tai tuottajataholta osaamista. Panostuksen vastapainona on toisten tekemästä jatkokehityksestä itselle koituva hyöty, jota ei kuitenkaan voida ennakoida tai taata. Julkaistu lähdekoodi ei enää ole omassa hallinnassa.

Ohjelmiston lähdekoodi ja kehityskaari ovat täysin ohjelmiston kehittäjän hallinnassa. Kehitys tapahtuu tämän saneleman aikataulun mukaisesti. Myös päätös siitä, milloin ohjelmisto on kehitetty uudeksi versioksi, josta pitää erikseen maksaa, on yksin ohjelmiston omistajan päätösvallassa. Toisaalta ratkaisu on helppo: ostajan ei tarvitse huolehtia versionhallinnasta.

Ohjelmiston käyttöiän määrittää prosessuaalinen tai tekninen ympäristö. Tarvittaessa se voidaan muuntaa eri käyttöjärjestelmässä tai -ympäristössä toimivaksi. Muutoksia ohjelmistoon voidaan tehdä tai teettää niin kauan kuin halutaan.

Ohjelmiston valmistaja päättää ohjelmiston käyttöiän esimerkiksi siten, että siihen ei enää tehdä päivityksiä tai sitä ei tueta uudessa käyttöjärjestelmäversiossa.

Jakamiseen liittyvät juridiset riskit on huomioitava.

Jakamiseen liittyvistä juridisista riskeistä ei tarvitse huolehtia.

5.6.2 Haasteita

5.6.2.1 Avoimen lähdekoodin ohjelmistojen saatavuus ja sopivuus

Vaikka avoimen lähdekoodin ohjelmistoja on tehty valtava määrä ja uusia projekteja käynnistyy jatkuvasti, ei kaikkiin tarkoituksiin ole vielä saatavilla kypsiä avoimen lähdekoodin ratkaisuja. Toisaalta vaikka sopiva ohjelmisto olisikin olemassa, siitä ei välttämättä tiedetä eikä sitä näin ollen osata etsiäkään.

5.6.2.2 Kaupallisten toimijoiden löytäminen

Erityisesti kotimaisia ja melko vähän käytettyjen ohjelmistojen ratkaisutoimittajia ja tukipalveluita tarjoavia yrityksiä ei välttämättä ole olemassa tai ne eivät markkinoi itseään. Vähemmän käytetty tuote saattaa olla varsin uusi ja myös tuotetukea tarjoavat yritykset voivat olla ainakin osittain uusia toimijoita ICT-markkinoilla.

5.6.2.3 Ylläpito- ja muutoksenhallinta

Monissa avoimen lähdekoodin projekteissa muutostahti on erittäin ripeä. Osa näistä projekteista voi julkaista uuden ohjelmistoversion muutaman päivän tai viikon välein. Joissain tilanteissa nopea kehitys ja suuret muutokset ovat vaikuttaneet siten, että ohjelmiston luotettavuus ja vakaus ovat heikentyneet. Kannattaa huomata, että tämä muutosten nopeus koskee myös osaa suljetuista ohjelmistoista.

Avoimen lähdekoodin ratkaisua valittaessa onkin suositeltavaa ottaa mahdollisuuksien mukaan selvää valittavan ohjelmiston julkaisuaikataulusta. Jotkut avoimen lähdekoodin projektit ovat siirtyneet julkaisukäytäntöön, jossa uusi versio tuotteesta tuodaan markkinoille esimerkiksi puolen vuoden välein. Tämän uuden version lisäksi ylläpidetään vanhojen versioiden virhekorjauksia esimerkiksi kolmen vuoden ajan.

Ohjelmistoa käyttävän organisaation on myös punnittava uusien versioiden hyödyllisyys suhteessa omaan käyttöön. Mikäli uusi versio ei tuo mitään oleellista parannusta sen hetkiseen toteutukseen, on päivitystyö todennäköisesti turhaa ajankäyttöä ja riskinottoa. Tämä koskee sekä suljettuja että avoimia ohjelmistoja.

5.6.2.4 Avoimen lähdekoodin käyttöönoton vaatimat omat resurssit (oma käyttöönotto)

Kuten kaikissa tietojärjestelmissä, on avoimen lähdekoodin ohjelmiston käyttöön ottavan organisaation syytä huolehtia siitä, että hankkeeseen saadaan riittävästi henkilöstöä ja osaamista.

Käyttöönoton yhteydessä on vaatimusmäärittelyn avulla analysoitava, mitkä ominaisuudet otetaan käyttöön ja mitkä ominaisuudet jätetään hyödyntämättä. Laaja ominaisuuksien asentaminen varmuuden vuoksi voi puoltaa paikkaansa silloin, kun odotettavissa on käyttötarpeen pikainen laajeneminen. Muussa tapauksessa tarpeettomat ominaisuudet on syytä jättää asentamatta.

Kun organisaatio päättää vastata käyttöönotosta itse, on vastuu ohjelmiston toimivuudesta ja oikeudellinen vastuu esimerkiksi ohjelmistossa mahdollisesti piilevistä tekijänoikeusloukkauksista organisaatiolla itsellään. Useimmiten laajasti käytetyillä ohjelmistoilla on kuitenkin tukisivusto, josta kysymyksiin voi etsiä vastauksia ja ratkaisuja näihin ongelmiin. Tämä vaatii kuitenkin omaa aktiivisuutta ja osaamista.

Omassa käyttöönotossa organisaatio voi tulla riippuvaiseksi kehittäjäyhteisöstä, johon voi vapaaehtoisten kehittäjien lisäksi kuulua useita yrityksiä.

5.7 Avoimen ja suljetun lähdekoodin vertailutaulukko

Taulukko 3. Avoimen ja suljetun lähdekoodin vertailu.

Avoin lähdekoodi

Suljettu lähdekoodi

Ohjelmistokehitys

Voidaan hyödyntää avoimen lähdekoodin ohjelmistoja ja komponentteja eli jo valmiiksi tehtyä työtä. Lisenssien yhteensopivuus pitää tarkistaa, mikäli suunniteltua teosta aiotaan levittää.

Avoimen lähdekoodin ohjelmien hyödyntäminen on rajoitetusti mahdollista, jos tekijänoikeuksien hajautus ei haittaa. Mikäli halutaan säilyttää tekijänoikeudet itsellä, voidaan käyttää vain niitä komponentteja, joihin on hankittu oikeus tai jotka on toteutettu itse.

Paikalliset toimijat

Voivat tuottaa ohjelmakoodia ja palveluja.

Palvelujen ja erityisesti ohjelmakoodin tuotanto on rajoitettua.

Toimittajariippuvuus

Riippuvuutta oikeuksien omistajaan ei ole, toimittaja vaihdettavissa.

Ohjelmiston oikeuksien omistaja kontrolloi toimittajakenttää.

Kansalaiset

Yhdenvertaisessa roolissa. Ohjelmistoja voidaan jakaa kaikille.

Ohjelmistojen käyttölisenssit ovat yleensä maksullisia. Tämä asettaa kansalaiset eriarvoiseen asemaan mm. varallisuuden mukaan.

Lähdekoodin tarkistettavuus

Lähdekoodi voidaan vapaasti luovuttaa kenelle tahansa arvioitavaksi ja tarkistettavaksi.

Lähdekoodin tarkistettavuus vaatii sopimisen ohjelmiston oikeuksien omistajan kanssa.

Lähdekoodin laadukkuus

Lähdeoodi voidaan vapaasti luovuttaa kenelle tahansa arvioitavaksi.

Lähdekoodin laadukkuus vaatii sopimisen ohjelmiston oikeuksien omistajan kanssa.

5.8 Avoimen lähdekoodin liiketoiminta

Avoimen lähdekoodin teknologioita hyödynnetään liiketoiminnassa paljon. Yleisintä sen hyödyntäminen on yrityksen sisäisissä operaatioissa työkaluina, työpöytäkäytössä ja palvelimissa. Askel pidemmälle on liittää avointa lähdekoodia omiin myytäviin tuotteisiin ja palveluihin tai rakentaa liiketoiminta olemassa olevien avoimien tuotteiden ympärille. Pisimmälle vietynä perustetaan oma avoimen lähdekoodin projekti, hallinnoidaan ja ylläpidetään sitä aktiivisesti, kehitetään tuotteelle palvelukonsepti ja luodaan yhteisöasemaan voimakkaasti nojautuva liiketoimintamalli.

Koska avoimen lähdekoodin lisenssit estävät perinteisen, käytön rajoituksiin perustuvan lisenssimyynnin, on avoimen lähdekoodin liiketoiminnassa käytettävä muita tulonlähteitä. Seuraavaksi esitellään eräitä avoimen lähdekoodin teknologioihin perustuvia liiketoimintamalleja.

Avoimen lähdekoodin liiketoimintamallit voidaan jakaa muutamaan pääryhmään sen mukaan, mistä ansainta muodostuu. Omana ryhmänään näiden varsinaisten liiketoimintamallien ulkopuolella on puhdas harrastustoiminta, jossa siinäkin useimmiten on nähtävissä jonkinlainen edun tavoittelu esimerkiksi siten, että tekijä hyödyntää avoimen lähdekoodin projektin tuomaa osaamista ja julkisuutta muussa toiminnassaan, kuten työnhaussa.

Taulukko 4. Hankinnan kohde eräissä liiketoimintamalleissa avoimella ja suljetulla puolella.

Liiketoimintamalli

Hankinnan kohde - avoin

Hankinnan kohde - suljettu

Huom.

Palvelupohjainen

Ostetaan palvelu

Ostetaan palvelu

Avoimella puolella tehtävää työtä voi tarjota kuka vain. Suljetulla puolella työn tekijä on ohjelmistovalmistajan kontrolloitavissa.

Käyttäjälle ilmaiset, mainosrahoitteiset palvelut

Ei hankinta, koska vastikkeeton

Ei hankinta, koska vastikkeeton

Ei ole tyypillisesti käytössä julkishallinnossa.

Laitteeseen sulautettu

Hankitaan laite

Hankitaan laite

Laite voidaan räätälöidä organisaatiolle sopivaksi avoimella puolella. Avoin lähdekoodi ei kasvata laitteen hintaa ohjelmistolisenssimaksuilla. Se voi pienentää ohjelmiston kehitys- ja ylläpitokustannuksia.

Lisenssimyynti

Ei hankita, koska se on vastikkeeton

Käyttölisenssi

Avoimen lähdekoodin ohjelmissa ei ole perinteisiä lisenssimaksuja. Ns. kaksoislisensointi on mahdollinen, jolloin avoimesta ohjelmasta on maksullisesti saatavilla eri lisenssiehdoilla varustettu versio.

Tilauspalvelu

Hankitaan tuote- ja palvelupaketti

Hankitaan tuote- ja palvelupaketti

Avoimella puolella ei välttämättä lisenssimaksuja.

Ohjelmisto palveluna, Software as a Service (SaaS),

Palveluhankinta

Palveluhankinta

Hankinnassa (ja palvelussa) ei ole mitään eroa.

5.9 EU:n linjaukset suhteessa avoimiin ohjelmistoihin ja standardeihin

Euroopan unioni asetti kunnianhimoisen poliittisen tavoitteen vuonna 2000 Lissabonissa olla johtava tietoon perustuva talousalue maailmassa vuoteen 2010 mennessä. Keskeistä on edistää yhteismarkkinoiden taloudellista toimintaa ja suojella markkinoita häiritseviltä tekijöiltä. Jotta tavoitteisiin päästäisiin, on luotu ja kehitetään edelleen keinoja tukemaan pitkän aikavälin politiikkakysymysten ratkaisua sekä tarjoamaan välineitä ennakoivaan päätöksentekoon ja talouden suunnitteluun. Tällaisia kehyksiä ja ohjeistuksia ovat mm. European Interoperability Framework (EIF), European Interoperability Architecture Guidelines (AG) ja ylemmän tason European Interoperability Strategy (EIS).

Euroopan unionin eri elimet ovat useissa yhteyksissä kiinnittäneet huomiota toimittajariippuvuuden aiheuttamiin ongelmiin ja tilanteen kilpailua rajoittavaan vaikutukseen. Tavoitteena on aiempaa avoimempi kilpailu, alhaisemmat tietojärjestelmäkustannukset ja parempi tietojen vaihdettavuus eri ohjelmistojen välillä eli yhteentoimivuus (interoperability). Ministerikokouksen julistus Brysselissä marraskuussa 2001 toteaa: ”Ministerit ilmaisivat huolensa yhdestä ICT-toimittajasta tai valmistajasta ja peräänkuuluttivat kilpailun lisäämistä. Ministerit [...] kehottivat komissiota kiihdyttämään avoimen lähdekoodin vaihtoehtojen kehitystä [...] ja lisäksi avoimet standardit ja ”teknologianeutraali” sääntely on elintärkeää”.

Comossa heinäkuussa 2003 ”ministerit kannustivat hallintoa määrittelemään järjestelmänsä ja prosessinsa uudelleen, jotta hallinnon eri tasojen toimia voidaan koordinoida paremmin avoimia standardeja käyttämällä.”

Muun muassa näitä tavoitteita varten EU:n komissio on perustanut IDABC-ohjelman. IDABC:n suositukset ja ohjeet ovat päätyneet laaja-alaisen valmistelun jälkeen suosittamaan avoimen lähdekoodin käytön huomioon ottamista, jopa priorisoimista hankintatoimen yhteydessä, jotta saavutettaisiin EU:n poliittiset tavoitteet, kuten yhteismarkkinat, kilpailukyky ja tasa-arvoinen kohtelu hallinnossa.

IDABC:n alla toimii OSOR-hanke, joka mm. kokoaa tietoa jäsenmaissa tehdyistä avoimen lähdekoodin hankinnoista ja -käyttöön otoista, levittää tietoa eri maista saaduista hyvistä käytännöistä ja hallinnoi julkisen sektorin avoimen lähdekoodin ohjelmien säilytyspaikkaa. Toinen esimerkki EU:n ja IDABC:n avoimeen lähdekoodiin liittyvistä käytännön toimista on EUPL-lisenssi. EUPL on avoimen lähdekoodin lisenssi, joka luotiin vastaamaan Euroopan komission vaatimuksiin kieliriippumattomasta ja terminologialtaan EU:n lain kanssa yhteensopivasta lisenssistä.

EIF-dokumentti suosittelee, että julkisen sektorin tulisi tutustua avoimen lähdekoodin yhteisön työskentelytapoihin, jotta avoimen lähdekoodin ohjelmista koituvat hyödyt avautuvat. Tämän lisäksi suositellaan avoimien ohjelmistojen käytön inventointia, koska monet organisaatiot ovat yllättyneet siitä, kuinka paljon niitä on jo käytössä. Näin syvällistä perehtymistä suositellaan siksi, että ohjelmistojen avoimuudesta on selkeitä hyötyjä. Tavoitteena on tilanne, jossa julkisella hallinnolla on oma ohjelmistohakemisto, jossa olevat ohjelmat ovat vapaasti hyödynnettävissä.

5.10 Avoin lähdekoodi muissa suosituksissa

Ennen tätä suositusta avointa lähdekoodia on käsitelty mm. valtiovarainministeriön dokumentissa Suositus valtion tietojärjestelmien ja rajapintojen avoimuudesta (Valtiovarainministeriön työryhmämuistioita 23/2003). Suosituksessa todetaan mm. seuraavaa:

”Selvityksessä todettiin avoimen lähdekoodin menetelmin rakennetun järjestelmän olevan varteenotettava vaihtoehto erityisesti silloin, kun on kyse useiden hallinnon organisaatioiden tarvitsemasta palvelusta, järjestelmän avoimen lähdekoodin komponentteja on olemassa tai järjestelmän läpinäkyvyydellä on erityistä merkitystä.”

Suosituksessa korostetaan, että ”järjestelmätoimituksissa tilaajan tulisi ehdottomasti saada oikeus järjestelmän lähdekoodin hallussapitoon sekä järjestelmämuutosten tekemiseen ja teettämiseen”. Valmisohjelmistojen osalta tulisi ”huolehtia ainakin kriittisten järjestelmien koodin saatavuudesta Escrow-sopimuksin”.

Avoimen lähdekoodin toimintamallin mainitaan sopivan erityisesti projekteihin, joita leimaa monistettavuus ja muunneltavuus. Joissakin julkisissa palveluissa teknologian läpinäkyvyys voi olla ensiarvoisen tärkeää. Lähdekoodin pitää olla saatavilla ja myös muiden kuin tilaajan tarkasteltavissa.

Avoimen lähdekoodin lisäksi suosituksessa painotetaan rajapintojen ja standardien avoimuuden tärkeyttä:

”Aina kun mahdollista tulisi järjestelmät rakentaa niin, että ei ajauduta yksittäisen toimittajan suljetun rajapinnan takia riippuvaisiksi kyseisen toimittajan järjestelmistä. Järjestelmäkomponentteja ja kokonaisia järjestelmiä tulisi olla mahdollista tarvittaessa vaihtaa.”

Julkisen hallinnon IT-hankintojen yleisissä sopimusehdoissa (JHS 166, JIT 2007) on myös avoin lähdekoodi huomioitu. Julkisen hallinnon tietohallinnon neuvottelukunta (JUHTA) suosittelee kyseisiä sopimusehtoja valtion virastojen, liikelaitoksien ja rahastojen sekä kuntien ja kuntayhtymien käyttävän hankkiessaan IT-tuotteita ja -palveluita. JIT 2007 -ehtoja käsitellään luvussa 6.3.

6 Avoin lähdekoodi ja hankintaprosessi

Avoimeen lähdekoodiin ja hankintaprosessiin liittyvät erityiskysymykset voidaan jakaa seuraavasti:

  1. avoimen lähdekoodin ohjelmistoihin liittyvät erityispiirteet esiselvitysvaiheessa
  2. avoimen lähdekoodin vaihtoehdon mahdollistavan tarjouspyynnön tekeminen
  3. tarjousten arvioimisessa huomioon otettavat asiat, kuten toimittajariippuvuuden riskin arviointi.

6.1 Toimintamalleja esiselvitysvaiheeseen

6.1.1 Perehdy avoimien ohjelmien mahdollisuuksiin ja erityispiirteisiin

Julkisissa hankinnoissa ajatellaan käytännössä myös hankintaprosessiin itseensä käytettäviä resursseja. Hankinta pyritään tekemään tasapuolisesti niin, että oikeusriidalle todennäköisyys minimoituu. Resurssien rajallisuuden vuoksi hankinnat tehdään usein jo aiemmin hyväksi havaitulla tavalla. Avoimien ohjelmien tapauksessa tähän liittyy haaste: totutut mallit ovat kehittyneet miltei yksinomaan suljettujen ohjelmistojen hankinnasta opittujen kokemusten kautta. Avoimiin ohjelmiin, niiden lisensointiin ja yritysten toimintakulttuuriin liittyy kuitenkin suljettujen ohjelmien maailmasta eroavia tekijöitä, jotka on syytä ottaa huomioon.

6.1.2 Vaatimusmäärittely ja esiselvitysvaihe ovat olennaisia onnistuneen ohjelmisto- tai järjestelmähankinnan kannalta

Vaatimusmäärittelystä ja esiselvitysvaiheesta on syytä huomata, että monilta osin valinta hankittavan tuotteen tyypistä tehdään jo silloin, kun määritellään vaatimuksia eli ominaisuuksia: tällöin määritellään käytännössä samalla myös se, mitä valitaan. Olennaista on, kuinka hyvin määritelty tuote tai hankinta soveltuu suunniteltuun käyttöön.

Vaatimusmäärittelyn ja esiselvityksen merkitys korostuu, kun otetaan huomioon, mitä Valtion hankintakäsikirja toteaa hankinnoista:

Tarjousten käsittelyssä tarkistetaan ensin tarjoajan soveltuvuus ja tarjouksen tarjouspyynnönmukaisuus. Sen jälkeen tarjoukset vertaillaan. Kokonaistaloudellisen edullisuuden vertailu ja sen mahdollinen pisteytys on perusteltava yksityiskohtaisesti.

Vertailuperusteet ovat lukittuja siinä vaiheessa, kun julkinen tarjouspyyntö lähtee. Sen jälkeen arviointiperusteita ei enää voida muuttaa. Valmistelutyö on siksi tehtävä kunnolla.

Erilaiset sopimusehdot hankaloittavat eri tarjousten vertailua. Helpointa on, jos kaikki tarjoajat velvoitetaan noudattamaan tilaajan määrittelemiä sopimusehtoja.

6.2 Seitsemän askelta avoimen lähdekoodin ohjelmiston mahdollisuuden arviointiin

Ohjelmistoa hankittaessa tärkeintä on määritellä hankittavan ohjelmiston vaatimukset siten, että se sopii hyvin käyttötarkoitukseensa. Useimmiten paras, mutta myös raskain tapa on määritellä tarkasti ne toiminnallisuudet, mitä ohjelmalla pitäisi olla, ja tehdä hyvä vaatimusmäärittely.

Joissakin tilanteissa voidaan selvitä huomattavasti edullisemmin seuraavaa seitsemän askeleen hankintaprosessia käyttäen.

  1. Selvitetään, mitä ohjelman pitäisi pystyä tekemään käytännössä. Tämä voidaan tehdä esim. ottamalla verrokiksi tunnettu suljettu ohjelma ja lähteä hakemaan vähintään sen tasoista avoimen lähdekoodin ohjelmaa.
  2. Suoritetaan ohjelman koeasennus ja tehdään ohjelmalla samanlaisia tosielämän työtehtäviä kuin tuotantokäytössäkin. Kokemukset kirjataan ja ohjelmiston soveltuvuus arvioidaan. Monista avoimista ohjelmista erityisesti palvelinkäyttöön soveltuvista, on tehty internetissä esittelyversio, jolla käyttöä voi kokeilla. Koeasennuksen yhteydessä käytetään internetissä mahdollisesti saatavilla olevia käyttäjäfoorumeita vastausten ja tuen etsimiseen ja arvioidaan tuloksen laatu. Yritetään etsiä muita ohjelmistoa käyttäviä organisaatioita ja tiedustellaan käyttökokemuksia.
  3. Arvioidaan tuen tarve ja sen aiheuttamat lisäkustannukset sekä organisaation henkilöstön tarvitsema lisäkoulutus, jos siirrytään käyttämään uutta ohjelmistoa.
  4. Jos kysymys on palvelinohjelmistosta, selvitetään kannattaako organisaation ylläpitää palvelinta itse vai kannattaako työ ostaa muualta. Sovellusvuokraus ja SaaS-malli (engl. Software as a Service) kannattaa tutkia vaihtoehtoina. Jokin IT-palveluyritys voi myydä ohjelmiston käyttöoikeuden kiinteään kuukausihintaan huolehtien myös ylläpidollisista töistä.
  5. Arvioidaan, mitä sellaisia hyötyjä harkittu avoin ohjelmisto tarjoaa, joita suljetut vaihtoehdot eivät voi tarjota. Lisäksi arvioidaan niiden merkitys käytännön toiminnan kannalta.
  6. Käytetään immateriaalioikeuden ja ohjelmistolisenssien asiantuntijaa arvioimaan harkittavana olevan ohjelmiston lisenssin vaikutukset tuotteisiin, toimintaan ja liiketoimintaan. Kannattaa muistaa, että toiminnan laajuus voi muuttua ja ohjelmistojen lisensseillä saattaa olla suuri vaikutus siihen, mikä on mahdollista tai taloudellisesti järkevää tulevaisuudessa.
  7. Arvioidaan kokonaisuuden hyödyt, haitat ja kustannukset. Verrataan näitä muihin vaihtoehtoihin ja tehdään päätös tarjouspyynnön sisällöstä. Päätöksen tulee perustua mahdollisimman konkreettisiin faktoihin. Jos paljastuu, että jossakin edeltävässä vaiheessa ei ole otettu kaikkea tarpeellista huomioon, palataan siihen vaiheeseen.

6.3 Avoimen ohjelmiston ja suljetun ohjelmiston hankinnan erot

Oheiseen taulukkoon on koottu tärkeimmät avoimien ja suljettujen ohjelmistojen hankintaan liittyvät erot.

Taulukko 5. Avoimen ja suljetun ohjelmiston hankinnan vertailu.

Avoin ohjelmisto

Suljettu ohjelmisto

Hankinnan sisältö

Koska ohjelmisto on yleensä vapaasti saatavilla, hankinnan kohteena ovat avoimeen ohjelmistoon kohdistuvat palvelut. Käytön laajuus ei vaikuta hintaan.

Käyttöoikeus hankitaan tiettyyn määrään asennettuja ohjelmiston kopioita tai tiettyyn käytön laajuuteen. Hinnanmuodostus on yleensä sidottu käytön laajuuteen.

Keneltä hankitaan

Keneltä tahansa toimittajalta, joka tarjoutuu toimittamaan ratkaisun kyseisellä ohjelmistolla. Toimittajia voi olla monia. Tavallisesti ohjelmistot voi ladata verkosta, jolloin myös omatoiminen käyttöönotto on mahdollinen.

Käyttöoikeus ostetaan ohjelmiston valmistajalta tai valtuutetulta jälleenmyyjältä.

Kuka vastaa tuesta

Tuesta vastaa yleisesti järjestelmän toimittaja, jos on kyse ostetusta palvelusta. Tuen toimittaja voi kilpailuttaa tuotteet vapaasti. Tukea saa myös avoimilta foorumeilta tai erikoistuneilta kaupallisilta tukiorganisaatioilta.

Useimmiten jälleenmyyjä, jolla on tukiorganisaatio. Vaikeissa teknisissä kysymyksissä sen on kuitenkin käännyttävä ohjelmiston valmistajan puoleen.

Miten korjaukset ohjelmistoon tehdään?

Ohjelmiston toimittaja toimittaa. Jos näin ei tapahdu, asiakas voi itse tehdä tai teettää korjauksen.

Ohjelmiston toimittaja toimittaa. Jos näin ei tapahdu, asiakas voi tekijänoikeuslain nojalla itse tehdä tai teettää korjauksen. Lähdekoodi on kuitenkin useimmissa tapauksissa pyydettävä ohjelmiston valmistajalta, jolla ei ole velvollisuutta sen toimittamiseen (ks. kappale 6.5).

Integrointi muihin tuotteisiin

Integroitavissa muihin avoimiin ohjelmistoihin. Integrointityön määrä riippuu mm. ohjelmistojen teknisistä toteutuksista ja dokumentaatioista. Integrointi suljetun ohjelmiston kanssa on riippuvainen suljetun ohjelmistovalmistajan tahdosta avata ohjelmistonsa rajapintoja.

Integrointi saman valmistajan ohjelmistoihin ja järjestelmiin on yleensä saumatonta. Muissa tapauksissa tapauskohtaista riippuen määritellyistä rajapinnoista ja lisenssiehdoista.

6.4 Esiselvitysvaiheessa avoimiin ohjelmistoihin liittyvät erityispiirteet

Esiselvitysvaiheessa on lähtökohtana seuraava tilanne:

  • Tiedetään, mitä ohjelmistoja organisaatiolla on jo olemassa
  • Uuden hankinnan tarve pohjautuu uusiin tarpeisiin ja sen pitää nivoutua jo olemassa olevaan
  • On käsitys siitä tarpeesta, joka uuden ohjelmiston tai ohjelmistokokonaisuuden pitää täyttää

Esiselvitysvaiheessa on mahdollista joustavasti vertailla erilaisten toteutustapojen ominaisuuksia ja kustannuksia. Samalla voidaan kartoittaa mahdollisuudet yhteistyöhön ja yhteisiin hankintoihin muiden organisaatioiden kanssa. Vaikka käytössä ei vielä olekaan tarjouksia, hankintojen hintojen suuruusluokka on kuitenkin pystyttävä selvittämään muun muassa kilpailutusprosessin laajuuden arvioimisen takia.

Parhaan vaihtoehdon löytämiseksi pyritään kuvaamaan tarvittava ohjelmisto tai ratkaisu mahdollisimman prosessi- ja tarvelähtöisesti. Näin säilytetään mahdollisuus ratkaista asia tavoilla, jotka muuten voivat rajautua määrittelijän mielikuvituksen rajojen tai tietojen rajallisuuden takia pois. Olennaisinta on pyrkiä kuvaukseen, joka ei ole pelkästään näennäisesti etäännytetty yleisimmästä ratkaisutavasta. Tämä periaate on hyödyllinen, valittiinpa avoin tai suljettu ohjelmisto, koska näin mahdollistetaan totutusta poikkeavat ratkaisut.

Ohjelmistohankintaa tekevän kannalta avoimien ohjelmistojen maailma on hankala, koska toimintatavat ja liiketoimintamallit ovat jossain määrin erilaiset kuin suljettujen ohjelmien puolella. Esimerkiksi TIEKEn Onnistunut julkinen ICT-hankinta -julkaisun ilmaisu ”katsaus markkinoilta löytyviin ratkaisuihin” herättää kysymyksen: mitä käsite ”markkinat” tarkoittaa avoimien ohjelmien tapauksessa? Mahdollisia vastauksia on äärimuodoissaan kaksi:

  • Käsite markkinat sisältää kaikki muodossa tai toisessa saatavilla olevat ohjelmistot;
  • Käsite markkinat sisältää vain sellaiset ohjelmistot, joita kaupalliset toimijat tarjoavat.

Ero on olennainen siksi, että on olemassa paljon käyttökelpoisia avoimen lähdekoodin ohjelmistoja, joita mikään ohjelmistotoimittaja ei kuitenkaan Suomessa tue tai toimita. Jos organisaatiossa on riittävästi tietoteknistä osaamista, tällaisen ohjelmiston valinta voi olla perusteltua. Tällainen tapaus voi olla esimerkiksi silloin, kun ohjelmisto on tehty johonkin harvinaiseen käyttötarkoitukseen. Jälkimmäinen tulkinta on realistinen niiden organisaatioiden kannalta, joilla ei ole omaa tietoteknistä osaamista tai jotka edellyttävät takaajan ohjelmiston toimivuudelle.

Avoimen lähdekoodin käyttöä tulee verrata tasavertaisena vaihtoehtona muihin ratkaisuihin käyttäen kokonaistaloudellisuutta kriteerinä. Koko elinkaaren kustannusten laskeminen on tosin haasteellinen tehtävä. Lisäksi avoimen lähdekoodin myötä tulee uusia kysymyksiä:

  • Mikä arvo on sillä, että jos saman ratkaisun käyttöä organisaatiossa laajennetaan, ei lisenssimaksujen määrä kasva?
  • Mikä arvo on sillä, että käyttäjäkunnan laajentuminen ei aiheuta uutta tarjouskilpailua?
  • Mikä arvo on sillä, että mikäli tarjouspyynnössä mainittuja toiminnallisuuksia halutaan oleellisesti laajentaa, niin laajennusta ei tarvitse kilpailuttaa?
  • Mikä arvo on sillä, että organisaatio voi antaa ohjelmiston vastikkeetta henkilöstönsä tai vaikka toisen julkishallinnon organisaation käyttöön?

Esimerkki:

Virasto A on kilpailuttanut itselleen projektinohjausjärjestelmän.

  • Virasto B ja kunta C haluaisivat saman järjestelmän.
    • Suljettu lähdekoodi: B:n ja C:n tulee kilpailuttaa järjestelmähankinta ja tuleva järjestelmä määräytyy kilpailutuksen perusteella.
    • Avoin lähdekoodi: B ja C voivat ottaa järjestelmän käyttöönsä ja kilpailuttaa mahdollisesti tarvittavan työn.
  • Virasto A haluaa laajentaa projektinohjausjärjestelmää dokumentinhallinnan ja arkistoinnin suuntaan.
    • Suljettu lähdekoodi: Dokumentinhallinta ja arkistointi pitää kilpailutettaa ja tuleva järjestelmä määräytyy kilpailutuksen perusteella.
    • Avoin lähdekoodi: Järjestelmän toiminnallisuuksia voidaan laajentaa kilpailuttamalla tehtävä työ.

Avoimen lähdekoodin ohjelmistojen tarjoamien vaihtoehtojen selvittäminen on luonteeltaan erilainen prosessi kuin suljettujen ohjelmistojen hankinta. Avoimissa ohjelmissa yksi olennainen ongelma liittyy niiden suljettuja vastineitaan huonompaan tunnettuuteen. Pääsyy tähän on se, että kun yksi yhtiö ei omista ohjelmistoa eikä useampi toimittaja voi tarjota samaa ohjelmistoa, niin yhdelläkään toimittajalla ei ole intressiä tehdä suuria markkinointiponnistuksia tuotteen eteen.

Avoimien ohjelmistojen parhaita tiedonlähteitä ovat toiset samaa ohjelmistoa käyttävät organisaatiot - mitä samankaltaisempi organisaatio sitä parempi. Viitteitä voi etsiä tehokkaasti ohjelmiston käyttäjäorganisaatioista ohjelmiston käyttäjien kehittäjä- ja tukifoorumeilta. Ne ovat yleensä julkisia, koska ohjelmiston kehityskin tapahtuu yleensä julkisesti. On kuitenkin syytä muistaa, että nämä käyttäjät ovat jo sitoutuneet valinnallaan ohjelmiston käyttöön eikä ole lainkaan varmaa kuinka hyvin he tuntevat muita vaihtoehtoja. Siksi heille esitettävät kysymykset kannattaa esittää operationalisoidussa muodossa, kuten: ”Miten hoidatte tiedon vaihtamisen rajapinnassa x kyseisellä ohjelmalla?” Ei siis: ”Toimiiko se teillä hyvin x:n kanssa?”

Avoimista ohjelmistoista on myös koottua, luokiteltua tietoa. Tietolähteitä ja koottuja hakemistoja on listattu liitteessä 1. Jos tällaiset hakemistot ovat sisällöllisesti liian vaikeita tai haastavia, kannattaa organisaation antaa ohjelmiston valinta jonkin konsultoivan osapuolen tehtäväksi. Erityisesti tällaisessa tapauksessa kannattaa kartoittaa yhteistyömahdollisuudet muiden samankaltaisten organisaatioiden kanssa.

Tässä yhteydessä kannattaa miettiä, olisiko vastaavalla ratkaisulla käyttöä muissa julkisissa organisaatioissa. Hyvä esimerkki on kuntien yhdistämiset: joissa avoimilla ohjelmistoilla toteutetulla ratkaisulla on se etu, että se voidaan lisenssiehtoja noudattaen ”monistaa” käyttöön ilman ohjelmistoista koituvia lisäkustannuksia.

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 ja avoimen lähdekoodin ratkaisujen tarjoajille. Suositeltava muotoilu 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.”

Hankintalaki ei erikseen mainitse tietokoneohjelmia tai käyttöoikeuksia vaan puhuu tavaroiden tai palveluiden hankkimisesta. Alankomaissa toimivan Nederland Open in Verbinding (NOiV) -järjestön julkaisemassa The acquisition of (open-source) software -oppaassa tulkitaan EU-lainsäädäntöä siten, että itse tehty maksuttomien (gratis) ohjelmien käyttöönotto ei ole lain tarkoittama hankinta lainkaan. Organisaatio voi näin ollen tehdä päätöksen ottaa käyttöön tietty maksuton ohjelmisto ja kilpailuttaa käyttöönottoon liittyvät palvelut erikseen.

On huomattava, että hankintayksikön on ongelmallista käsitellä rinnakkain vastikkeetta tapahtuvaa, itse tehtävää avoimen ohjelmiston käyttöönottoa sekä sille vaihtoehtoista suljetun ohjelmiston ohjelmistohankintaa. Hankinnan kohde on vaihtoehdoissa eri, ja kahden eri hankinnan kohteen vertailua samassa kilpailutuksessa on hankala tehdä.

Käytännössä avoimen lähdekoodin ohjelmistoja harkitsevalla on yleisten hankintaperiaatteiden ja hankintalain mukaan kaksi mahdollisuutta:

  1. Valitaan avoimen lähdekoodin ohjelmisto itse ja otetaan se käyttöön omin toimin. Tällöin ohjelmisto ja sen käyttöönotto ei itsessään ole hankintalain tarkoittama hankinta. Hankinnan kohteeksi voi kuitenkin muodostua avoimeen ohjelmistoon kohdistuva työ, esimerkiksi ohjelmistoon hankittavat tukipalvelut. Hankintayksikkö voi tehdä päätöksen maksuttoman ohjelmiston käyttöönotosta ja sen jälkeen kilpailuttaa esimerkiksi käyttöönottoon liittyvät asennus- ja tukipalvelut. Näin on menetelty esimerkiksi oikeusministeriössä, jossa kaikki yli 10 000 työasemaa varustettiin avoimen lähdekoodin toimisto-ohjelmistolla.
  2. Tehdään julkinen tarjouspyyntö, jossa hankinnan kohde on ohjelmiston, käyttöönoton ja integroinnin muodostama kokonaisuus. Tällöin hankitaan ohjelmiston lisäksi myös käyttöönottoon liittyvät toimet ja esimerkiksi integrointi jo olemassa olevaan tietojärjestelmään. Tarjouspyyntö laaditaan siten, että siihen voidaan vastata myös avoimilla ohjelmistoilla. Tällöin hankinta tehdään yleisten hankintaperiaatteiden mukaan.

Jos esiselvitysvaiheessa tullaan siihen tulokseen, että jokin avoin ohjelma täyttää tarpeet ja on kokonaisuutena tarkastellen järkevä ja kokonaistaloudellinen vaihtoehto, käyttöönotto voidaan tehdä ilman kilpailuttamista. Pilotointi on toki järkevää, jotta mahdolliset ongelmat tunnistetaan.

Taulukossa 6 on vertailtu ohjelmistojen omin toimin tehtyä käyttöönottoa ohjelmistojen hankintaan.

Taulukko 6. Ohjelmiston oman käyttöönoton ja hankinnan erot.

Ohjelmiston oma käyttöönotto

Ohjelmiston hankkiminen

Markkinoiden ja vaihtoehtojen kartoittamisella suuri merkitys.

Vaatimusmäärittely keskeisessä asemassa.

Sopivan ohjelmiston etsiminen ja lataaminen vaatii erityisosaamista henkilöstöltä.

Tarjouspyynnön valmisteleminen vaatii paljon tietoa. Tarjoajat antavat osan siitä.

Mahdolliset palvelut pitää kilpailuttaa erikseen.

Ohjelmistot ja palvelut voidaan sisällyttää samaan tarjouspyyntöön.

6.5 Avoimiin ohjelmistoihin liittyvät erityiskysymykset tarjouspyyntöä laadittaessa ja arvioitaessa

Hankinnan kohteen kuvaus tulee tehdä niin riippumattomasti, että se ei sisällä tarpeettomia viittauksia tiettyihin ohjelmistoihin tai teknologioihin. Tämä pätee myös avoimiin ohjelmistoihin liittyviin käsitteisiin. ”Avoin lähdekoodi” ja ”vapaa ohjelma” eivät ole sisällöllisesti kovin tunnettuja, eivätkä ne ole tarkkarajaisia tai yksiselitteisiä.

Sama pätee erilaisiin avoimien ohjelmien lisensseihin. Sen sijaan, että edellytettäisiin hankittavaa ohjelmistoa esimerkiksi GPL-lisensoituna, voidaan kirjoittaa GPL-lisenssin ehdot auki halutussa määrin. Lähdekoodi tulisi toimituksen mukana ja hankintayksikkö tai kuka tahansa muu saa hyödyntää lähdekoodia rajoituksetta, kunhan julkaisee tekemänsä muutokset, mikäli ohjelmistoa levitetään. Tekijänoikeuslaki takaa joka tapauksessa oikeuden valmistaa ohjelmasta sellaiset kappaleet ja tehdä ohjelmaan sellaisia muutoksia, jotka ovat tarpeen ohjelman käyttämiseksi aiottuun tarkoitukseen (ks. kappale 7.1.1). Ohjelmiston valmistajalla ei kuitenkaan ole velvollisuutta lähdekoodin toimittamiseen, ellei muuta ole sovittu (esim. escrow-menettely).

Tarjousten vertailuperusteisiin kannattaa kiinnittää huomiota. Erityisesti sekä avoimen lähdekoodin että suljettuja ohjelmistoja sisältävissä sekahankinnoissa ongelmaksi saattaa muodostua se, miten kelpoisuusehdot ja arviointiperusteet saadaan muotoiltua siten, että ne kohtelevat erilaisia vaihtoehtoja tasapuolisesti ja järkevä hankintalain mukainen kilpailutus saadaan tehtyä.

Hankintalain mukainen lähtökohta tarjouksia arvioitaessa on, että valinta tulee tehdä joko halvimman hinnan tai kokonaistaloudellisen edullisuuden perusteella. Jos valinta tehdään kokonaistaloudellisuuden perusteella, vertailuperusteet on ilmoitettava. Jos näin ei menetellä, tulee valita hinnaltaan halvin. Tarkempia ohjeita hankintojen tekemisestä antaa Valtion hankintakäsikirja.

On syytä huomioida, että tietotekniikka- ja ohjelmistotoimituksissa pisteytysperusteiden määrittelemisessä tulee olla tarkkana. Sama toiminnallisuus voidaan useassa tapauksessa saavuttaa ostamalla kokonaistoimitus, ohjelmistojen käyttölisenssejä tai palvelu. Pisteytysperusteiden tulee olla tasapuolisia eri vaihtoehtojen kesken.

Ohjelmiston tai kokonaistoimituksen hankkijan kannalta olennaiset kysymykset jakautuvat hankintamenettelyssä kahteen ryhmään: osa liittyy toimittajien kelpoisuuteen liittyviä ja osa tarjousten arviointiin.

Seuraavissa luvuissa käsitellään hankintaan liittyviä kelpoisuus- ja vertailukriteereitä avoimen lähdekoodin hankinnan kannalta. Kyse ei ole ohjelmisto- tai tietoteknisten toimitusten hankinnan kattavasta yleisesityksestä vaan lyhyestä avoimien ohjelmistojen hankintaan liittyvien erityiskysymysten esittelystä.

6.5.1 Kelpoisuuskriteereihin kuuluvat laatutekijät

Referenssien ja henkilöstön osaamisen määrittelyssä on otettava huomioon avoimen lähdekoodin maailman erilainen toimintakulttuuri (mm. hajautettu ohjelmistokehitys) ja esittää myös sellaisia kysymyksiä, jotka mittaavat tarjoajan aktiivisuutta suhteessa tarjottavaan ohjelmistotuotteeseen.

Kysymyksillä pitäisi vähintään pystyä erottamaan tarjoajista ne, jotka todella osallistuvat ohjelmiston kehittämiseen tavalla tai toisella niistä, jotka hiljaisesti seuraavat kehitystä ja tarjoavat ohjelmistoon perustuvia ratkaisuja. Kehitykseen osallistuvilla yrityksillä on karttunut muita laajempi ohjelmiston osaamistaso ja tiiviimmät yhteydet kehittäjäyhteisöön. Vaatimuksissa esitettyjen yhteiskuntavastuuta mittaavien edellytysten tavoin voidaan kysyä asioita, jotka mittaavat yrityksen vastuunottoa avoimen lähdekoodin yhteisössä.

Pyydettäessä ehdokkailta tai tarjoajilta selvityksiä hankintalain (348/2007, pykälä 59) mukaisesti, teknisen suorituskyvyn ja ammatillisen pätevyyden osoittamiseksi, selvityksessä arvostettavia asioita voivat olla esimerkiksi seuraavat tiedot:

  • Onko yrityksenne osallistunut tarjotun ohjelmiston kehittämiseen luovuttaen siihen lähdekoodia? Millä tavoin ja kuinka paljon?
  • Onko yrityksenne esittänyt ohjelmiston kehittäjille kehitys- tai korjausehdotuksia? Mitä ja milloin? Miten ehdotuksille kävi?
  • Onko yrityksellänne oikeus lisätä lähdekoodia ohjelmiston versionhallintajärjestelmään?
  • Osallistutteko ohjelmiston kehittämiseen liittyvään organisoituun toimintaan? Mihin ja missä roolissa?

On oleellista tietää, miten tarjoajana olevan aktiivisen toimijan kehittämisehdotuksiin on suhtauduttu. On hyvä merkki, jos mielekkäät kehittämisehdotukset on toteutettu ja tarjotut lähdekoodimuutokset hyväksytty. Mikäli näin ei ole, toimija ei välttämättä ole vakiinnuttanut asemaansa ohjelmiston kehittäjäyhteisössä tai kehittämisehdotukset tai -panostukset eivät ole olleet riittävän hyviä. Mikäli toimijalla on oikeus lisätä lähdekoodia suoraan ohjelmiston versiohallintaan, on sillä oleellisesti paremmat vaikutusmahdollisuudet ohjelmiston kehittymiseen ja todennäköisesti paremmat referenssit ohjelmiston osaajana.

Edellä mainittuja kysymyksiä voidaan kuitenkin kritisoida kahdesta syystä.

  1. Ne mittaavat asioita, jotka ovat nimenomaan tyypillisiä avoimen lähdekoodin ohjelmistotuotannolle, kuten kehitysehdotusten tai korjausten tekemistä.
  2. Omaa suljettua ohjelmistoaan tarjoava yritys saa näistä täydet pisteet.

Tämän vuoksi ehdotetut kysymykset toimivatkin vain vertaillessa tarjouksia avoimen lähdekoodin ratkaisuista. Tilanne osoittaa myös sen, millaisiin vaikeuksiin saattavat johtaa ”sekakilpailutukset”, joihin voidaan vastata sekä avoimilla että suljetuilla ohjelmistoilla.

6.5.1.1 Referenssit

Toimittajalta odotetaan näyttöä aiemmista vastaavanlaisista toteutuksista. Toimittajan eduksi katsotaan kokemus ratkaisukuvauksen laatimisesta ja toteutuksesta sekä alustaratkaisun räätälöinnistä, jotka vastaavat asiakkaan tarpeita. Samoin eduksi katsotaan toimittajan kokemus järjestelmien integroinnista.

Referenssien kohdalla kannattaa ottaa huomioon, että avoimia ohjelmistoja voi tarjota kuka vain. Ostajaa voi kiinnostaa esimerkiksi se, mitkä samankaltaiset organisaatiot käyttävät kyseistä ohjelmistoa, vaikka toimitus ei olisikaan tarjoajan toteuttama. Näistä tiedoista on hyötyä, kun selvitetään esimerkiksi soveltuvuutta ostajan oman hallinnonalan käyttöön. Toisaalta tarjoajien oma osaaminen kyseisen ohjelmiston tapauksessa on syytä selvittää.

Esimerkkikysymyksiä:

  • Mitkä ovat yrityksenne toimitusreferenssit tarjoamastanne ohjelmistosta?
  • Onko muita kannaltamme vertailukelpoisia kyseisen ohjelmiston tai ratkaisun käyttäjiä?
6.5.1.2 Henkilöstön pätevyys

Tarjoajan tulee osoittaa työhön käytettävät henkilöstöresurssit ja nimetä työstä vastaava henkilö, jotta voidaan arvioida sekä henkilöstöresurssien laatua että riittävyyttä. Resurssien on oltava koulutukseltaan ja kokemukseltaan projektiin sopivia.

Resurssien pätevyyden arvioinnissa avoimissa ohjelmistoissa kannattaa ottaa huomioon henkilöstön koulutustason lisäksi osallistuminen erilaisiin avoimiin ohjelmistohankkeisiin, sillä ne kartuttavat kokemusta avoimen ja hajautetun ohjelmistokehitysmallin soveltamisesta.

6.5.1.3 Toimitusvarmuus

Suljetuista ohjelmista toimittajalta voi kysyä, kuinka pitkä elinkaari ja tuki ohjelmistolle taataan. Niiden kohdalla on syytä myös arvioida ja pyrkiä minimoimaan toimittajariippuvuudesta aiheutuva riski. Jos toimittaja poistuu markkinoilta, asiakkaan tilanteesta voi tulla hankala, ellei tilanteeseen olla suojauduttu escrow-järjestelyllä, jossa tiettyjen ehtojen täyttyessä ostaja saa ohjelmiston lähdekoodin haltuunsa.

Avoimissa ohjelmistoissa vastaavaa riskiä ei ole. Toimittajalta on kuitenkin hyvä pyytää lähdekoodit osana kokonaistoimitusta. Tällöin on mahdollista ryhtyä toimenpiteisiin heti, jos toimittajan kanssa tehtävässä yhteistyössä ilmenee vakavia ongelmia.

Suljetun ohjelmiston ostaminen lähdekoodeineen ja oikeuksineen on myös mahdollista. Esimerkiksi EU:n tasolla tullin käyttämissä järjestelmissä on joissain tapauksissa menetelty näin.

Tarjoajien toimitusvarmuuden arvioiminen voi olla avoimen lähdekoodin ohjelmia tarjoavien yritysten kohdalla ongelmallista. Mittarina on perinteisesti käytetty yrityksen vakavaraisuutta ja sen mittaamisessa suureena liikevaihtoa. Pelkkää työtä tai konsultointia myyvän yrityksen liikevaihto jää alemmalle tasolle kuin esimerkiksi sellaisen, joka tekee sekä laite- että lisenssikauppaa.

Avoimen lähdekoodin yritykset myyvät lähes pelkästään omaa työtään, ja siksi keskisuuren yrityksenkin liikevaihto voi jäädä merkittävästi heikommaksi kuin työntekijämäärältään huomattavasti pienemmän, tuotteiden myynnillä ansaitsevan yrityksen. Lisäksi pienikin yritys voi olla jollain erityisalalla alansa huippu, esimerkiksi roskapostisuodatinjärjestelmissä. Liikevaihtoa olisikin hyvä käyttää kriteerinä harkiten ja keskittyä projektiorganisaation kvalitatiivisiin ominaisuuksiin, kuten projektiin nimettävien henkilöiden osaamiseen. Jos liikevaihtoa käytetään mittarina, siitä pitäisi käyttää vain sitä osaa, joka koskee kyseessä olevan hankinnan luonteista liiketoimintaa.

6.5.2 Tarjousten vertailuun liittyvät tekijät

6.5.2.1 Kokonaisratkaisun soveltuvuus

Tarjousta verrataan tarjouspyynnössä esitettyihin vaatimuksiin. Arvioinnissa ei ole merkittäviä avoimiin ohjelmistoihin liittyviä kysymyksiä. Jos määrittely ja tarjous on tehty siten, että ne eivät sisällä viittauksia tiettyihin käyttöjärjestelmiin tai ohjelmistoihin, arviointi on suoraviivaista toiminnallisuuden arviointia.

6.5.2.2 Hinta

Laatuvertailun jälkeen lasketaan hintapisteet tarjouspyynnössä annetun kaavan mukaisesti.

Hintoja arvioitaessa on syytä ottaa huomioon, että avoimilla ohjelmistoilla ei tyypillisesti ole maksullisia lisenssejä. Niille perustuvan tarjouksen hinnasta suurin osa koostuu yrityksen omasta työstä. Tämä kannattaa ottaa huomioon jo tarjouksen tekovaiheessa kiinnittäen huomiota laskutavan tasapuolisuuteen, huomioiden ohjelmiston koko elinkaaren aikaiset kustannukset.

6.6 Ohjelmiston hankkiminen avoimen lähdekoodin lisenssillä

Ohjelmiston hankinta tulee tehdä pääsääntöisesti siten, että hankittava ohjelmisto voidaan jakaa hallinnon ja kansalaisten keskuudessa. Parhaiten ohjelmiston jakamisen edellytykset turvataan käyttämällä avoimen lähdekoodin lisenssejä. Tähän on kolme vaihtoehtoa:

  1. Tarjouspyynnössä määritellään, että ohjelmisto toimitetaan avoimen lähdekoodin oikeudet antavilla lisenssiehdoilla. Mitään yksittäistä avoimen lähdekoodin lisenssiä ei kannata mainita nimellä, vaan tarjouspyyntöön listataan avoimen lähdekoodin määritelmästä tärkeimmät oikeudet ja mahdollisesti lisäksi joitakin toivotun lisenssin erityispiirteitä:
    1. Oikeus ajaa ohjelmaa millä tahansa laitteistolla ja käyttää sitä mihin tahansa tarkoitukseen.
    2. Oikeus jaella ohjelmistoa suoritettavassa ja lähdekoodimuodossa. Kaikilla käyttäjillä on yhtäläiset oikeudet ohjelmistoon.
    3. Oikeus muokata ohjelmistoa haluamallaan tavalla ja jaella muutettua ohjelmistoa.
    4. Oikeus käyttää ohjelmaa minkä tahansa ohjelmiston kanssa. Lisenssi ei saa rajoittaa sitä, minkälaisten ohjelmistojen kanssa sitä käytetään olivatpa ne suljettuja tai avoimia. Lisenssi ei saa myöskään olla riippuvainen isommasta ohjelmistokokonaisuudesta, jonka osana ohjelma toimitetaan.
  1. Tarjouspyynnössä määritellään, että määräysvalta ohjelmiston lisensoinnista on hankintayksiköllä.
  2. Ohjelmisto hankitaan tekijänoikeuksineen niin, että oikeudet siirtyvät hankintayksikölle (kallein vaihtoehto).

Kun avoimeen ohjelmistoon teetetään muutoksia, olisi kehitystulokset hyvä saada avoimen lähdekoodin lisenssillä ja julkaista alkuperäisen ohjelmiston projektiin ja muiden hyödynnettäviksi. Tästä on useita etuja:

  • Muut saavat kehitystulokset käyttöönsä ja voivat ja kehittää niitä edelleen. Tuote voi kehittyä entistä paremmaksi ilman uusia hankintoja.
  • Alkuperäinen projekti voi ottaa kehitystulokset ohjelmiston viralliseen jakeluun, jolloin hankintayksikön ohjelmisto on yhteensopiva alkuperäisen ohjelmiston ja sen tulevien päivitysten kanssa. Näin voidaan välttää ohjelmiston haarautuminen alkuperäisestä teoksesta, mikä voi vaikeuttaa ylläpitoa.

7 Avoimen lähdekoodin juridisia kysymyksiä

7.1 Tekijänoikeus ja avoimen lähdekoodin ohjelmistolisenssit

7.1.1 Nykytila

Tietokoneohjelmat on suojattu tekijänoikeudella. Tekijänoikeuslaissa (404/1961, pykälä 25) on annettu erityissäännöksiä tietokoneohjelmien ja tietokantojen käytöstä ja kopioinnista. Tekijänoikeuslaki takaa oikeuden valmistaa ohjelmasta sellaiset kappaleet ja tehdä ohjelmaan sellaisia muutoksia, jotka ovat tarpeen ohjelman käyttämiseksi aiottuun tarkoitukseen. Tämä koskee myös virheiden korjaamista. Laki antaa käyttöoikeuden haltijalle myös luvan tarkastella, tutkia tai kokeilla tietokoneohjelman toimintaa niiden ideoitten ja periaatteiden selvittämiseksi, jotka ovat ohjelman osan perustana, jos hän tekee sen ohjelman tietokoneen muistiin lukemisen tai ohjelman näyttämisen, ajamisen, siirtämisen tai tallentamisen yhteydessä. Tietyin edellytyksin laki sallii myös ohjelman koodin kopioimisen ja sen muodon kääntämisen, jos nämä toimenpiteet ovat välttämättömiä sellaisten tietojen hankkimiseksi, joiden avulla voidaan saavuttaa yhteentoimivuus itsenäisesti luodun tietokoneohjelman ja muiden ohjelmien välillä

Perinteisissä kaupallisissa ohjelmistoissa käyttö- ja kopiointiluvan on saanut ostamalla lisenssejä, jotka oikeuttavat käyttämään ohjelmaa tietyin rajoituksin. Yleensä yhdellä lisenssillä ohjelman on voinut asentaa yhteen koneeseen. Joissakin tapauksessa ohjelmistoihin on voinut ostaa myös esimerkiksi kuntakohtaisia lisenssejä, jotka sallivat ohjelmiston asentamisen kaikkiin yksikön koneisiin. Palvelinohjelmistojen lisenssiehdot perustuvat esimerkiksi yhtäaikaisten käyttäjien maksimimäärään tai palvelinkoneen prosessorien lukumääriin.

Koska ohjelmiston lähdekoodi ei tule tavallisesti ohjelmistojen mukana, muokkaaminen edellyttää lähdekoodin saamista valmistajalta.

7.1.2 Avoimen lähdekoodin lisenssit

Suljetuissa ohjelmissa tekijänoikeuden haltija asettaa lisenssinsaajan vapauksille rajoituksia, kun taas avoimissa ohjelmissa tekijänoikeuden haltija pyrkii lisenssiehtojen avulla turvaamaan lisenssinsaajan vapaudet. Suurin periaatteellinen ero avoimien ja suljettujen ohjelmien lisensseissä on, että Open Software Initiativen (OSI) mukaan avoimen lähdekoodin lisenssien tulee täyttää OSI:n avoimen lähdekoodin määritelmän ehdot. Nämä on esitelty luvussa 4.

OSI on standardoinut kymmeniä lisenssiä, jotka täyttävät tämän määritelmän. Näistä tärkeimmät esitellään seuraavassa luvussa. On syytä kuitenkin huomioida, että tekijänoikeus avoimilla lisensseillä julkaistuihin ohjelmistoihin pysyy niiden tekijöillä. Mikäli avointen lisenssien ehtoja ei noudateta, kyse on vastaavasta rikkomuksesta kuin kaupallistenkin tuotteiden kohdalla – tosin sillä erolla, että tilanne on useimmiten paljon helpommin korjattavissa esimerkiksi julkaisemalla ohjelmiston lähdekoodi.

Työasemakäytössä avoimien lisenssien yksityiskohtaisiin ehtoihin ei yleensä ole varsinaista tarvetta tutustua. Tärkeintä on tieto ohjelmien vapaasta käyttämisestä ja kopioimisesta. Jos tiettyä ohjelmistoa halutaan kuitenkin lähteä muokkaamaan esimerkiksi useamman kunnan yhteisprojektina, on asiaan kuitenkin syytä perehtyä huolellisesti.

7.1.3 Lisenssityyppejä

Avoimen lähdekoodin lisenssejä on tällä hetkellä melkein joka lähtöön. Tilanne ei ole tältä osin erityisen toivottava, koska "lisenssitulva" tekee lisenssien hallinnoinnin ohjelmistoyrityksille hankalaksi. Käyttään asti tämä ongelma ei kuitenkaan yleensä heijastu, sillä yhteen sovittamiseen liittyvät ongelmalliset kohdat tulevat yleensä vastaan vain silloin, kun ohjelmia levitetään organisaation ulkopuolelle.

Avoimet lisenssit kategorisoidaan usein kolmeen eri ryhmään niiden ominaisuuksien mukaan:

  • sallivat lisenssit
  • vastavuoroisuutta edellyttävät lisenssit
  • vahvaa vastavuoroisuutta edellyttävät lisenssit.
7.1.3.1 Sallivat lisenssit

Sallivia lisenssejä ovat esimerkiksi MIT-, BSD- ja Apache-lisenssit. Niissä ohjelmaa saa muokata ja levittää vapaasti ja lähdekoodin voi, muttei välttämättä tarvitse laittaa levitettävän ohjelman mukaan. Nämä lisenssit ovat hyvin lyhyitä ja selviä. Esimerkiksi MIT-lisenssi mahtuu kolmeen kappaleeseen:

The MIT License

Copyright (c) <year> <copyright holders>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

7.1.3.2 Vastavuoroisuutta edellyttävät lisenssit

Toisen lisenssikategorian muodostavat vastavuoroisuutta edellyttävät lisenssit. Näissä lisensseissä ohjelmatiedostoihin tehdyt muutokset tulee julkaista tietyin edellytyksin, joista ylivoimaisesti yleisin on ohjelmiston julkinen levittäminen muutoksen jälkeen. Näillä lisensseillä julkaistuja ohjelmistoja saa kuitenkin yhdistää vapaasti muihin, eri lisensseillä tehtyihin ohjelmistoihin, esimerkiksi linkittämällä ohjelmakirjastoihin. Yleisimpiä tämän kategorian lisensseistä ovat Eclipse Public License (EPL), Mozilla Public License (MPL) ja GNU Lesser General Public License (LGPL).

7.1.3.3 Vahvaa vastavuoroisuutta edellyttävät lisenssit

Kolmannen kategorian muodostavat vahvaa vastavuoroisuutta edellyttävät lisenssit. Ne ovat oikeastaan vastavuoroisuutta edellyttävien lisenssien erityiskategoria, sillä nämä lisenssit edellyttävät lähdekoodin julkaisemista alkuperäisellä lisenssillä kaikissa niissä tilanteissa, joissa alkuperäistä ohjelmistoa muokataan tai siihen yhdistetään uusia elementtejä esimerkiksi linkittämällä.

Tämän hetken kaikista yleisin avoimen lähdekoodin lisenssi, GNU General Public License (GPL), kuuluu tähän kategoriaan. Toisena esimerkkinä voidaan mainita Common Public License (CPL).

Näiden lisenssien kohdalla ongelmana on yhteensopivuus muiden avoimen lähdekoodin lisenssien kanssa. Esimerkiksi GPL 2.0 ei ole yhteensopiva Apache 2.0 -lisenssin kanssa, mikä estää niillä lisensoitujen ohjelmistojen yhdistämisen toistensa kanssa. Myöskään GPL 2.0 ja GPL 3.0 eivät ole keskenään yhteensopivia.

Taulukko 7. Ohjelmistojen jakelumallien ja lisenssien ominaisuuksia.

Lisenssi

Vapaa levitys

Vapaa käyttö

Vapaa lähdekoodi

Normaali vastavuoroisuus

Vahva vastavuoroisuus

Suljettu ohjelmisto

-

-

-

-

-

Shareware

x

-

-

-

-

Freeware

x

x (voi sisältää rajoituksia)

-

-

-

BSD, MIT, Apache , …

x

x

x

-

-

LGPL, MPL , EPL ...

x

x

x

x

-

GPL 2, GPL 3,CPL, ...

x

x

x

x

x

7.1.4 Vastuukysymykset ja avoimen lähdekoodin lisenssit

Käytännössä kaikissa avoimen lähdekoodin lisensseissä on mukana vastuurajoituslausekkeet, jotka pyrkivät estämään ohjelmien tekijöihin kohdistuvat vahingonkorvausvaatimukset. Tilanne ei tältä osin poikkea merkittävästi kaupallisista ohjelmistoista. Suomalaisessa oikeuskäytännössä tällaiset vastuurajoitusehdot ovat yleensä sitovia muissa paitsi niissä tilanteissa, joissa on kyse törkeistä laiminlyönneistä tai tahallisista teoista aiheutuvista vahingoista. Asiaa käsitellään yksityiskohtaisemmin seuraavassa luvussa.

7.2 Avoimen lähdekoodin riskit ja niiden hallinta

7.2.1 Riskianalyysin osa-alueet

Vaikka avoimen lähdekoodin ottaminen mukaan organisaation ohjelmistopalettiin ei välttämättä tarkoita suurta muutosta aikaisempaan, kyse on kuitenkin muutoksesta, jonka hallinnan tulee olla suunnitelmallista toimintaa. Yksi keskeinen osa tätä prosessia on riskinhallinta. Perinteisten ohjelmistoprojektien riskinhallinnasta on saatavilla jo valmiiksi runsaasti erilaista materiaalia niin teknisestä, kaupallisesta kuin oikeudellisestakin näkökulmasta. Turhan toiston välttämiseksi tässä osioissa esitellään erityisiä riskikohtia avoimen lähdekoodin hankinnoissa ja vertaillaan niiden hallintaa perinteisissä ja avoimen lähdekoodin ohjelmistohankinnoissa.

Avoin lähdekoodi ja erityisesti sen hankinta on ilmiönä varsin uusi monille hankintayksiköille, mikä korostaa hyvän valmistautumisen merkitystä. Todellisten riskien hahmottaminen ei välttämättä ole helppoa tilanteessa, jossa monet aikaisemmin opitut periaatteet on käännetty päälaelleen. Lisäksi myös avoimen lähdekoodin riskit voivat alkuun vaikuttaa suuremmilta kuin ne todellisuudessa ovat. Vasta käytännössä voidaan oppia, mihin asioihin tulisi kiinnittää huomiota ja mitkä ovat toisarvoisia.

Oikeilla menettelytavoilla avoimeen lähdekoodiin liittyvien riskien taso voidaankin säätää useimmiten organisaation haluamalle tasolle. Käytännön toiminnassa erot perinteisiin kaupalliseen tuotteisiin jäävät hyvin pieniksi, jos näin halutaan. Tosin avoin lähdekoodi tarjoaa monesti jopa joustavamman lähestymisen riskinhallintaan, ja tässä mielessä syntyvät erot ovat avoimille ohjelmille eduksi.

7.2.1.1 Vaihtoehtoisten toimittajien saatavuus

Yhteen toimittajaan sitoutuminen on yksi suurimmista taloudellisista riskeistä, mitä ohjelmistoprojekteissa joudutaan usein ottamaan. Ostajan vahva sitoutuminen tiettyyn toimittajaan mahdollistaa tuotteen elinkaaren aikana sen kustannustason merkittävän kohottamisen. Vieläkin ongelmallisempia ovat tilanteet, joissa toimittaja lopettaa yllättäen käytössä olevan tuotteen tukemisen ja korvaavaan tuotteeseen siirtyminen ei ole mahdollista esimerkiksi puuttuvan tiedostomuotodokumentaation vuoksi. Riskiä voidaan osittain rajata ns. escrow-ratkaisuilla, mutta turva jää kauas täydellisestä. Escrow-järjestely toteutetaan kuviteltujen ongelmatilanteiden varalta. Käytännössä on kuitenkin vaikea varautua kaikkiin mahdollisiin tilanteisiin. Usein toimittaja ei myöskään suostu esimerkiksi rajapintojen oikeuksien avaamiseen missään olosuhteissa.

Avoimen lähdekoodin ratkaisuissa näihin ongelmiin törmätään huomattavasti harvemmin. Ensinnäkin avoimen lähdekoodin luonne on omiaan suosimaan aitojen avoimien standardien käyttöä rajapinnoissa ja tiedostomuodoissa. Toiseksi lähdekoodi on vapaasti saatavilla ja muokattavissa, jolloin hankintayksikkö pystyy ainakin periaatteessa aina etsimään toisen toimittajan ohjelmiston jatkokehittämiselle, jos käytössä olevan toimittajan kanssa ei päästä yksimielisyyteen hinta- tai palvelutasosta.

Kannattaa kuitenkin muistaa, että kovinkaan monella toimittajalla ei välttämättä ole tarvittavaa tietotaitoa harvinaisemmista tuotteista, mikä rajaa todellista kilpailua. Myöskään hyvin uusien tuotteiden osaamista ei välttämättä ole ehtinyt syntymään kovinkaan monelle toimittajalle. Jos taas kysyntää ei ole riittävästi, intoa tarvittavien oppimisinvestointien tekemiseen ei välttämättä ole. Ennen syvällistä sitoutumista tiettyyn ohjelmistoon tai tekniikkaan on järkevää tehdä markkina-analyysi myös avoimen lähdekoodin tuotteista.

7.2.1.2 Takuut ja vastuut

Vastuukysymysten järjestäminen on usein yksi isoimmista ongelmista avoimen lähdekoodin ohjelmistohankinnoissa. Voiko kukaan vastata netistä ladattavasta lähdekoodista, jonka jokin epämääräinen yhteisö on tuottanut? Käytännössä tilanne ei välttämättä poikkea lainkaan perinteisistä kaupallisista tuotteista. Paljon riippuu siitä, kuinka laajan takuun ostaja haluaa ja kuinka paljon siitä ollaan valmiita maksamaan.

Ensinnäkin jos organisaatio hakee internetistä jonkin avoimen lähdekoodin tuotteen ja asentaa itse, jäävät ohjelmiston toiminta ja ongelmat sen kannettavaksi. Avoimen lähdekoodin projektit tarjovat toki usein vapaaehtoisvoimin neuvontaa esimerkiksi sähköpostilistoilla ja keskustelualueilla, mutta tarjottavan avun laatu vaihtelee huomattavasti projektien koon ja resurssien mukaan: tukeen liittyviä oikeudellisia sitoumuksia ei anneta, ja useimmissa avoimen lähdekoodin lisensseissä nimenomaisesti sanoudutaan irti vastuusta ohjelmiston toiminnasta (tai toimimattomuudesta). Esimerkiksi suositussa BSD-lisenssissä on seuraava vastuunrajoitusehto:

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Jos hankintayksikkö ottaa käyttöönsä BSD-lisensoidun ohjelmiston, sen kehittäneet ohjelmoijat eivät kanna mitään vastuuta ohjelman toimivuudesta tai sen virheistä tai niiden aiheuttamista vahingoista. On kuitenkin syytä pitää mielessä, että tilanne ei tältä osin juuri poikkea kaupallisista valmisohjelmistoista, joiden lisenssiehdoista löytyy normaalisti vastaavat vastuurajoitusehdot. Merkittävin ero valmisohjelmistoihin onkin siinä, että avoimen lähdekoodin ohjelmat voidaan ottaa käyttöön ilman lisenssimaksuja ja niiden toimivuutta haluttuun käyttötarkoitukseen voidaan testata ilman rajoituksia ennen varsinaista tuotannon käyttöönottoa. Koska lähdekoodi on saatavilla ja muokattavissa, havaittuihin ongelmiin voidaan myös tarvittaessa ja tietotaidon riittäessä hakea itsenäisesti ratkaisuja.

Hankintayksikkö voi halutessaan käyttää kolmatta tahoa varmistamaan ohjelmiston toiminnan. Avoimen lähdekoodin ratkaisut voivat joissakin turvallisuuskriittisissä tapauksissa olla lähdekoodin escrow-menettelyn ohella ainoita vaihtoehtoja tarkistaa ohjelmiston haittaohjelmat ja piilotetut toiminnallisuudet. Kaikki kaupallisten ohjelmistojen rajoitetut lähdekoodin katselmointimahdollisuudet eivät kuitenkaan mahdollista sovelluksen kääntämistä luovutetuista lähdekoodeista. Tällöin lopullista varmuutta ajettavan ohjelman ominaisuuksista ei suljetulla puolella voida saavuttaa.

Avoimen lähdekoodin lisenssit eivät estä lisenssiehtoja parempien takuu- ja vastuuehtojen tarjoamista. Näin esimerkiksi tarjouspyyntöön voidaan määritellä haluttu takuutaso, johon toimittajan tulee sitoutua. Mikään ei myöskään estä takuupalveluiden erillistä ostamista jo käyttöönotetulle avoimen lähdekoodin ratkaisulle. Ongelmaksi saattaa muodostua sellaisen toimittajan löytäminen, joka on kiinnostunut tämänkaltaisesta sopimuksesta.

Oma lukunsa on lähdekoodia koskevien oikeudellisten takuiden antaminen. Hankintayksikön kannalta olisi toivottavaa, että toimittaja lupaisi korvata tai hoitaa mahdolliset tekijänoikeuteen ja ohjelmistopatentteihin liittyvät vaatimukset. Tekijänoikeuden osalta eri avoimen lähdekoodin projekteissa lähdekoodin oikeuksien hallinta vaihtelee huomattavasti, mikä aiheuttaa varteenotettavia uhkakuvia, kun erityisesti projektien hajautettu luonne otetaan huomioon. Onkin lähes mahdotonta varmistua kattavasti, että tietyn projektin lähdekoodissa ei ole sinne luvatta lisättyä materiaalia. Tosin lähdekoodin vapaa saatavuus on omiaan vähentämään luvatonta plagiointia, sillä julkisesti saatavilla olevasta lähdekoodista luvatta kopioidun lähdekoodin löytäminen on huomattavasti helpompaa kuin suljetusta lähdekoodista. On myös olemassa kaupallisia toimijoita, jotka tarjoavat työkaluja lähdekoodin auditointiin.

Ohjelmistopatenteissa tilanne on vieläkin huonompi. On lähes varmaa, että kaikki laajemmat avoimen lähdekoodin tuotteet rikkovat ainakin jotakin, lähinnä Yhdysvalloissa, myönnetyistä kymmenistä tuhansista patenteista. Jälleen kerran on kuitenkin syytä pitää mielessä, että ero tältä osin perinteisiin kaupallisiin tuotteisiin on olematon: yhtä todennäköisesti myös suljetun lähdekoodin tuotteet rikkovat patentteja. Avoimen lähdekoodin patenttiriskiä tosin lisää jonkin verran lähdekoodin vapaa saatavuus, mikä helpottaa loukkauksien löytämistä. Toisaalta Suomessa ohjelmistopatentteihin liittyviä oikeudenkäyntejä ei ole esiintynyt ja täältä puuttuu kokonaan erityisesti Yhdysvalloissa yleinen tapa yrittää rahastaa epämääräisillä patenteilla.

Joka tapauksessa on syytä tiedostaa, että määräaikaista toimenpidekieltoa tai käyttökieltoa voidaan hakea ketä tahansa patenttia käyttävää tahoa vastaan. Tämän vuoksi julkishallinnon järjestelmätkään eivät ole immuuneja. Euroopan unionin alueella ei ole kuitenkaan tiedossa yhtään julkishallintoa vastaan nostettua kannetta tai patenttiriitaa. Yhdysvalloissa harjoitettava patenttikiistoilla rahastaminen ei leviä todennäköisesti julkiselle sektorille, koska osavaltiot on suojattu IPR-kiistoilta lailla.

Ei liene kovinkaan yllättävää, että toimittajat ovat varsin haluttomia antamaan oikeudellisia takuita avoimen lähdekoodin tuotteille. Mikä merkitys olisi ylipäänsä pienempien toimittajien antamilla takuilla, jos yrityksien taseet eivät kuitenkaan kestä täysimittaista patenttilitigaatiota. Yksi vaihtoehto tilanteen ratkaisemiseen on erityisten IPR-vakuutusten käyttö joko toimittajan tai hankintayksikön toimesta. Vakuutusten ongelmana ovat kuitenkin yleisesti kalliit hinnat ja huono kattavuus ongelmatilanteissa. Onkin varsin kyseenalaista, saavutetaanko vakuutusten käytöllä todellista apua potentiaalisiin ongelmatilanteisiin.

7.2.1.3 Avoimen lähdekoodin tuotteiden elinkaari

Yksi keskeinen ero avoimen lähdekoodin ja perinteisten suljettujen tuotteiden välillä on julkaisunopeus. Suljetut tuotteet julkaistaan yleensä vasta siinä vaiheessa, kun ne ovat toimittajan mielestä valmiita tarkoitettuun käyttötarkoitukseen. Avoimen lähdekoodin ohjelmistot ovat yleensä vapaasti saatavilla yhteisöjen kotisivulta aivan alusta alkaen, jolloin ohjelmien toiminnallisuus voi olla hyvinkin puutteellista. Tämä ero on tosin osittain pienentynyt viime aikoina perinteisten toimittajien lisättyä erilaisten beta-versioiden tarjoamista tuotteistaan ja välillä kaupalliset paineet pakottavat julkaisemaan keskeneräisiä tuotteita.

Alkuvaiheen avoimen lähdekoodin ohjelmistoille tyypillisiä piirteitä:

  • Nopeita muutoksia on niin lähdekoodikannassa kuin myös rajapinnoissa.
  • Ohjelmien asentaminen vaatii omatoimista lähdekoodin kääntämistä ja voi olla myös muuten hankalaa.
  • Uusia versioita julkaistaan viikoittain tai jopa päivittäin.
  • Dokumentaatiota on minimaalisesti.
  • Käyttäjiä on vähän, ja heistä suurin osa on itse mukana kehitystoiminnassa.
  • Kaupallisia tukipalveluja ei ole saatavilla, ja neuvonta tapahtuu postilistalla tai IRC-kanavilla.
  • Ohjelmistosta puuttuu suunniteltuja toiminnallisuuksia kuten esimerkiksi graafinen käyttöliittymä.

Näiden ns. alfa-vaiheen ohjelmistojen käyttöä ei voi suositella kuin kaikkein riskejä sietävimmille ja osaavimmille organisaatioille. Pitäisi odottaa ainakin 1.1-version julkaisemista ohjelmistosta ennen kuin laajempaa käyttöönottoa kannattaa harkita. Tosin kaikissa tuotteissa numerointi ei välttämättä kerro tuotteen kypsyyttä. Tosin poikkeuksia on molempiin suuntiin.

Mikäli avoimen lähdekoodin tuote selviää alfa-vaiheesta, kehitystyön vauhti yleensä rauhoittuu ja käytettävyyden hiominen ja dokumentaatio saavat enemmän huomiota osakseen. Ohjelman suosion kasvaessa sen ympärille alkaa muodostua "ekosysteemi", joka tuottaa myös kaupallisia palveluita. Tässä vaiheessa ohjelmistojen käyttöönotto ei yleensä ole kovin haasteellista. Hieman tuotteesta riippuen tämä tasaisen kehityksen vaihe saattaa kestää vuosia. Yksinkertaisemmissa tapauksissa tuote voidaan saada myös toiminnallisuuksiltaan valmiiksi. Tämän jälkeen kyse on enää ylläpidosta ja virheiden korjaamisesta.

Ylläpitovaiheessa olevalla tuotteelle tyypillisiä piirteitä ovat:

  • Vakaus ja kypsyys ilmenevät kaikissa tuotteen osissa.
  • Yleinen luottamus tuotteen toimintaan perustuu pitkäaikaiseen käyttökokemukseen.
  • Uusia virheitä tai tietoturva-aukkoja paljastuu harvoin.
  • Olemassa oleva käyttäjäkunta pitää yllä kysyntää tukipalveluille ja tuotteen ylläpidolle.

Kehitystyön hiljentyminen voi myös merkitä riskiä, koska välttämättä kovinkaan moni yhteisön jäsen ei ole kiinnostunut pelkästä ylläpidosta. Näin projekti voi hiipua pois. Asian voi toisaalta tarkistaa helposti esimerkiksi katsomalla viimeisten julkaisujen päivitysten ajankohtia tai hankkeen sivustolla käytävien keskustelujen ikää. Muilta osin tähän kehitysasteeseen päässeen avoimen lähdekoodin tuotteen käyttö on varsin riskitöntä ja soveltuu kaikille hankintayksiköille.

Avoimen lähdekoodin ohjelmistojen käyttöönotossa on tärkeää tuntea projektin kehitysaste ja suhteuttaa se sitten omaan osaamiseen. Osaavan organisaation käsissä epäkypsäkin projekti voi tarjota tehokkaan ratkaisun ongelmaan. Parhaassa tapauksessa yhteistyö hankkeen kanssa voi johtaa tuotteen kehittymiseen hyvin omaa tarkoitusperää tukevaan suuntaan. Tällöin tulisi aina olla kyse harkitusta ja tietoisesta riskinotosta. Myös erittäin vanhojen tuotteiden käyttöön voi liittyä riskejä esimerkiksi ylläpidon jatkuvuudessa. Sama tilanne on myös perinteisissä kaupallisissa tuotteissa sillä poikkeuksella, että avoimeen lähdekoodiin korjauksien tekeminen ja ylläpito ei ole sidottu siihen, mitä yksi toimittaja on päättänyt tuotteen tulevaisuudesta.

7.2.1.4 Lähdekoodin saatavuuden merkitys

Vaikka avoimen lähdekoodin yksi nimenomaisia vahvuuksia onkin lähdekoodin saatavuus, tilanne ei ole yksinomaan positiivinen. Organisaation sisällä pitää sopia lähdekoodin käyttöön liittyvistä menettelyistä ongelmien välttämiseksi.

Ensinnäkin helposti käsillä oleva lähdekoodi mahdollistaa omien, pienten korjausten tekemisen järjestelmiin. Mikäli tätä toimintaa ei koordinoida mitenkään ja korjauksista ei jää dokumentaatiota, voidaan nopeasti päätyä tilanteeseen, jossa ylläpito muuttuu lähes mahdottomaksi. Toisaalta omien korjausten tekemisellä voidaan saavuttaa merkittäviäkin kustannussäästöjä, eli sitä ei missään tapauksessa kannata kokonaan kieltää. Paras ratkaisu olisi luoda erillinen kehitysympäristö, jonne koottaisiin muutokset ja niiden dokumentaatio ennen käyttöönottoa.

Toimiviksi todetut muutokset ja dokumentaatio kannattaa lähettää ohjelmiston kehittäjäyhteisölle siinä toivossa, että ne liitettäisiin alkuperäiseen ohjelmistoon. Tällöin oma muokattu ohjelmisto olisi yhteensopiva yhteisön kehittämän ohjelmiston kanssa, ja se voidaan päivittää melko riskittömästi uusiin ohjelmistoversioihin.

Edellä mainitun kanssa rinnakkainen kysymys on ohjelmistojen asentamiseen käytettävien tiedostojen hakeminen. Jos ohjelmistojen lataaminen sallitaan vapaasti verkosta – minkä lisenssit sinänsä sallivat – tietoturvassa ja versionhallinnassa tulee nopeasti ongelmia. Olisikin järkevintä, että organisaatio määrittelisi ohjelmistopankin, joka olisi ainoa sallittu paikka asennusmedioiden hakemiseen. Tämä voi olla oma tai jokin laajahkossa käytössä oleva ohjelmistopankki. Valitun pankin tulee pitää asennusmediat ajan tasalla, koska muuten kiusaus toimivamman version hakemiseen muualta voi olla liian suuri. Jos avoimen lähdekoodin ratkaisulle käytetään kaupallista toimittajaa, keskitetty ratkaisu on usein myös ainoa mahdollinen.

7.2.1.5 Teknologiariskit

Kaupallisten tuotteiden toimittajilta on yleensä saatavissa markkinointimateriaalia, josta tuotteiden tekniset ominaisuudet käyvät ilmi. Samoin yritykset tiedottavat usein etukäteen tulevista uusista versioista ja niiden ominaisuuksista. Vaikka tällaiset tiekartat eivät aina toteudu ainakaan esitetyssä muodossa, ne antavat kuitenkin kuvaa siitä, mihin suuntaan tietty tuote on kehittymässä.

Kuten kohdassa 4.3 kuvattiin, avoimen lähdekoodin tuotteissa vastaavaa suoraa tuoteinformaatiota on paljon vaikeampi löytää, mutta verkossa on melko kattavia tuote-esittelyjä ja -vertailuja. Vain isoimmat projektit julkaisevat selviä tiekarttoja tulossa olevista versioista.

Vaikka suunnitelmia olisi olemassa, niistä ei välttämättä pidetä kovin tarkasti kiinni. Yhteisöjen prioriteeteissa keskeisempää onkin saada tuote julkaisukelpoiseen kuntoon, ei niinkään pitää kiinni enemmän tai vähemmän sattumanvaraisesti määritellyistä määräajoista. Tosin osa avoimen lähdekoodin projekteista noudattaa tarkasti ennalta määriteltyä julkaisuaikataulua.

7.2.2 Menettelytavat riskien hallintaan

Mikäli hankintayksikkö päättää ottaa käyttöön itsenäisesti tietyn avoimen lähdekoodin tuotteen, on useimmissa tapauksissa lähes välttämätöntä tehdä huolellinen ennakkoarviointi. Ennakkoarvion ja varsinaisen käyttöönoton välinen ero ei tosin ole yhtä jyrkkä avoimen lähdekoodin tuotteissa kuin se on perinteisissä kaupallisissa ohjelmistoissa. Koska avoimen lähdekoodin lisenssit sallivat rajoittamattoman kokeilun, ainoastaan hankintayksikön resurssit ja mahdolliset aikataulurajoitteet muodostavat rajat käyttökokemusten hakemiselle ennen varsinaiseen tuotantokäyttöön siirtymistä. Käyttökokemusten hakemisen lisäksi kannattaa aina kuitenkin tutustua tuotteen käyttämiin teknologioihin, projektin historiaan, käyttöprofiiliin sekä tuotteesta verkosta löytyvään palautteeseen.

Tilanne on luonnollisesti eri, jos kyse on kilpailutetusta hankinnasta. Tällöin toimittaja kantaa ainakin periaatteessa vastuun valinnasta. Tosin hankintaa edeltävässä esiselvitysvaiheessa hankintayksikön olisi järkevää käydä läpi ainakin suurin piirtein samat asiat kuin tuotteen itsenäisen käyttöönotonkin yhteydessä. Harkittavasta ohjelmistosta tulisi varmistaa ainakin seuraavat seikat:

  • Ohjelmisto toimii, kuten sen dokumentaatio ja verkkosivuilla jaettava informaatio antavat ymmärtää.
  • Ohjelmiston todellinen suorituskyky riittää tai ylittää suunnitellussa tehtävässä tarvittavan suorituskyvyn.
  • Ohjelmistoa ylläpitävä yhteisö (tai yhtiö) on ”hengissä”. Positiivisia merkkejä tästä ovat esimerkiksi
    • Ohjelmiston päivitysversioita ja tietoturva-aukkoja julkaistaan säännöllisesti.
    • Ohjelmiston verkkosivut ovat päivittyneet säännöllisesti.
    • Ohjelmistoa koskevilla sähköpostilistoilla ja foorumeilla on tuoreita viestejä.
    • Ohjelmiston tulevaisuudesta on olemassa suunnitelma (tiekartta, engl. roadmap).
  • Ohjelmistolle on tarjolla useita kaupallista ylläpitopalvelua tarjoavia toimittajia.

Avoimen lähdekoodin tuotteet koostuvat usein monesta erillisestä komponentista, joiden kehittäjä- ja ylläpitoyhteisöt voivat toimia täysin itsenäisesti. Tällöin jokaiset komponentit tulisi tarkistaa erikseen. Kaikissa tapauksissa tämä ei ole luonnollisesti mahdollista: Ääriesimerkkinä voidaan ajatella Linux-jakeluita, jotka voivat koostua tuhansista itsenäisesti ylläpidetyistä, eri ohjelmistoja sisältävistä paketeista. Näiden läpikäyminen tarkoittaisi melkein koko avoimen lähdekoodin kentän läpikäyntiä. Hankintayksikön kannattaakin tällöin harkita, mitkä komponentit ovat keskeisiä hankinnalle tai käyttöönotolle ja mitkä taas niin merkityksettömiä, etteivät niiden mahdolliset ongelmat kumuloidu kokonaisuuteen.

Avoimen lähdekoodin tuotteista tarvittavat tiedot löytyvät yleensä helposti. Koska kehitystyö tapahtuu yleensä avoimilla sähköpostilistoilla ja foorumeilla, hakukone löytää todennäköisesti sekä positiiviset että negatiiviset keskustelut tuotteista.

7.2.3 Hankintatapaan liittyvien riskien arviointi

Kuten tässä luvussa on jo aikaisemmin kerrottu, avoin lähdekoodi mahdollistaa varsin joustavan riskinhallinnan hankintayksikön preferenssien perusteella. Samoin kriteerejä hankintatavan valitsemiselle on jo käyty läpi luvussa 5. Joka tapauksessa itsenäisen käyttöönoton ja täysin toimittajalähtöisen hankinnan välillä on luonnollisesti merkittäviä eroja riskiprofiilissa.

7.2.3.1 Itsenäinen hankinta

Kun hankintayksikkö asentaa itse Internetistä hankittuja ohjelmistoja, siihen liittyy luonnollisesti omat tietoturva- ja oikeudelliset riskinsä.

Laajasti käytössä oleviin tuotteisiin liittyvät tietoturvariskit ovat melko pieniä, ja aktiivinen käyttäjäyhteisö havaitsee yleensä nopeasti tahattomat tai tahalliset tietoturva-aukot. Pienissä projekteissa on kuitenkin mahdollista, että tuotteeseen on jäänyt joko tahattomia tai tahallisia aukkoja, joita voidaan hyödyntää verkkohyökkäyksissä. Tilanne ei kuitenkaan tältä osin eroa merkittävästi perinteisistä suljetun lähdekoodin tuotteista. Tosin osaava hankintayksikkö pystyy ainakin periaatteessa auditoimaan avoimen lähdekoodin tuotteiden sisällön käymällä läpi niiden lähdekoodin. Kaikkein tietoturvakriittisimmissä sovelluksissa tämä on usein jopa välttämätöntä. Auditoinnin voi suorittaa myös kolmas osapuoli.

Itsenäiseen ohjelmistojen ylläpitoon liittyy myös aina kysymys hankintayksikön tietotaidosta. Vaikka normaaleista ongelmatilanteista selvittäisiinkin itsenäisesti, taidot eivät välttämättä riitä ennestään tuntemattomien ongelmien ratkaisemiseen. Avoimen lähdekoodin yhteisöt saattavat kyetä auttamaan tällaisissa tilanteissa. Toinen vaihtoehto on, että tarvittava erityisosaaminen ostetaan ulkopuoliselta palveluntarjoajalta. Tämä luonnollisesti edellyttää, että käytettävän tuotteen ylläpitoon ja ongelmanratkaisuun löytyy kaupallisia palveluntarjoajia. Näiden palveluiden tarjonta olisi syytä varmistaa etukäteen.

Kokonaan oma lukunsa on tilanteet, joissa hankintayksikkö alkaa itsenäisesti kokoamaan eri avoimen lähdekoodin komponenteista uusia tuotteita tarpeisiinsa. Tämä edellyttää jo hyvin huomattavaa osaamista. Tämän lisäksi erityisesti rakennettavien järjestelmien hallinnointi tulee ottaa huomioon sellaisissa tilanteissa, joissa käytettävien komponenttien kehityssuunnat eivät vastaa välttämättä hankintayksiköin tarpeita.

7.2.3.2 Ulkoinen toimittaja

Ulkoisen toimittajien valintaan liittyviä kysymyksiä on jo käsitelty varsin laajasti luvussa 5. Riskinhallinnan näkökulmasta keskeistä on ensinnäkin, että valittava toimittaja sitoutuu noudattamaan hankintayksikön käyttämiä standardeja ja menettelytapoja mm. tietoturvassa ja laadunhallinnassa.

Ideaalitilanteessa hankintayksikön tulisi edellyttää toimittajalta täydellistä käytettävien komponenttien auditointia niin tietoturvan kuin IPR:ien osalta. Käytännössä tämä ei kustannussyistä ole useinkaan mahdollista, ainakaan jos käytetään laajoja avoimen lähdekoodin kokonaisuuksia. Huomiota tulisi kiinnittää myös siihen, että toimitettavien tuotteiden dokumentaatio on niin laadukasta, että hankintayksikkö pystyy tarvittaessa käyttämään kolmansia tahoja mahdollisten ongelmien ratkaisemiseen sekä tuotteiden jatkokehittämiseen. Erityisen kriittistä on, että toimittajan tuotteisiin lisäämät uudet rajapinnat on ensinnäkin dokumentoitu riittävän tarkasti, mutta myös niin avoimia IPR-mielessä, että ne ovat toteutettavissa myös muiden kuin toimittajan toimesta.

Mikäli toimittajan ja hankintayksikön välinen suhde koostuu enemmästä kuin yksittäisestä kertatoimituksesta, on järkevää arvioida toimittajan luotettavuus riskinhallintamielessä. Hankintaprosessissa tämä olisi hyvä tehdä mahdollisuuksien mukaan jo esiselvitysvaiheessa. Keskeisiä kysymyksiä, jotka tosin soveltuvat myös perinteisiin toimittajiin, ovat mm.:

  • toimittajan taloudellinen vakaus
  • tunnustettu asema tuotteen toimittajana
  • toimivat prosessit riskinhallinnassa
  • liiketoimintastrategian realistisuus
  • kolmansien osapuolten vaikutusmahdollisuudet (mm. vihamielinen fuusio)
  • liikkeenjohdollinen osaaminen
  • tietotaito ja tietotaidon pysyvyys.

7.2.4 Tuotteen elinkelpoisuuden arviointi

Avoimen lähdekoodin projektien ”kuoleminen” ei ole mitenkään erityisen harvinaista. Vaikka kyseessä ei ole yhtä radikaali ilmiö kuin perinteisen ohjelmistoyrityksen konkurssi lähdekoodin jäädessä julkisesti saataville, tilanne voi aiheuttaa huomattavia ongelmia kyseisen tuotteen valinneelle organisaatiolle.

Vaikka ylläpitoa voidaankin näissä tapauksissa periaatteessa jatkaa itsenäisesti tai käyttämällä kolmansien tahojen tarjoamia palveluja, tarvittavan osaamisen kartuttaminen vie aikaa ja aiheuttaa mahdollisesti merkittäviä kustannuksia. Mikäli kyse on tarpeeksi arvokkaasta tai helposti hallittavasta tuotteesta, tämäkin vaihtoehto voi olla realistinen. Avoimen lähdekoodin ominaispiirteet, pysyvästi saatavilla oleva lähdekoodi ja täysi muokkaus- ja jatkokehittämisoikeus, muodostuvatkin tässä merkittäväksi riskinrajaukseksi. Useimmiten järkevämpi vaihtoehto on kuitenkin etsiä korvaava tuote ja mahdollisesti koettaa saada siihen integroiduksi edellisen tuotteen erityisen tärkeät osat.

7.2.5 Tuotteen jatkokehityksen arviointi

Avoimen lähdekoodin tuotteet eivät periaatteessa eroa merkittävästi perinteisistä suljetuista tuotteista teknologia-tiekartan suhteen. Esimerkiksi vaikuttamismahdollisuudet tietyn projektin suuntaan eivät juuri poikkea hankintayksikön mahdollisuudesta vaikuttaa tietyn yrityksen jatkokehityssuunnitelmiin. Pienissä projekteissa tämä on usein helppoa kuten myös PK-yrityksissä. Tämä edellyttää kuitenkin useimmiten aktiivisia toimia, kuten lähdekoodiparannusten lähettämistä projektiin. Toisaalta yksittäisen kunnan mahdollisuus vaikuttaa esimerkiksi Linux-ytimen kehitykseen on yhtä epätodennäköistä, kuin vaikuttaminen kilpailevien käyttöjärjestelmien kehitykseen.

Selkeä merkittävä ero on kuitenkin siinä, että mikäli hankintayksikön intressi on tarpeeksi suuri, se voi muokkausoikeutta hyväksikäyttäen tehdä oman räätälöidyn version tuotteesta. Suljettujen tuotteiden osalta tätä mahdollisuutta ei ole.

7.2.6 Riskien tarkistuslista

Seuraavaa listaa, joka on koottu tässä kappaleessa esiin nousseista asioista, voidaan käyttää apuna avoimen lähdekoodin hankintojen riskinhallinnassa. Kuten listasta käy ilmi, useimmat riskinhallintaan liittyvät asiat eivät suoraan liity avoimeen lähdekoodin erikoispiirteisiin, vaan ne soveltuvat myös perinteisiin suljettuihin ohjelmistotuotteisiin. Lisäksi kyse on ennen kaikkea vain esimerkistä. Ennen listan laajaa käyttöä olisi tärkeää miettiä hankintayksikön sisällä, kuvaako listan sisältö niitä riskejä, jotka ovat relevantteja kyseisissä tapauksissa.

Lista on esitetty aika- ja tärkeysjärjestyksessä. Jos ensimmäisissä kohdissa tarkastelun tulos on kielteinen, kannattaa harkita jatkon mielekkyyttä.

  • Vastaako ohjelmisto siitä annettuja kuvauksia?
  • Vastaako ohjelmisto sen dokumentaatiota?
  • Onko ohjelmisto jaossa tunnetulla ja yleisesti saatavilla olevalla verkkosivustolla?
  • Onko ohjelmiston takana yritys, ei-kaupallinen yhteisö vai vain muutamia kehittäjiä?
  • Onko hankintayksikkö riippuvainen kehityssuunnitelmassa mainitusta, tulossa olevasta toiminnallisuudesta?
  • Noudattaako ohjelmisto myös avoimia rajapintoja, protokollia ja tiedostomuotoja?
  • Onko ohjelmistosta julkaistu opaskirjoja?
  • Onko ohjelmiston käyttäjämäärä kasvussa?
  • Onko ohjelmiston kehittäjämäärä kasvussa?
  • Löytyykö ohjelmistolle paikallisia toimittajia?
  • Ovatko ohjelmistoja toimittavat yritykset toimittaneet tuotetta aikaisemmin julkiselle sektorille?
  • Onko ohjelmistolla olemassa kehityssuunnitelmaa (engl. roadmap)?
  • Voiko ohjelmistoon esittää lisättäväksi uusia toiminnallisuuksia?
  • Onko ohjelmiston virheiden raportointiin ja korjaamiseen olemassa selvä prosessi?
  • Onko ohjelmiston julkaisuhistoria julkisesti saatavilla?
  • Onko ohjelmiston tietoturva-aukoista ja niiden paikkaamisesta saatavilla julkista informaatiota?
  • Onko ohjelmistolla useampia ja projektista riippumattomia käyttäjäfoorumeita tai postilistoja?
  • Onko kolmansien osapuolten komponenteista (avoimista tai suljetuista) tehty riskianalyysi, jos ohjelmisto vaatii näin toimiakseen?
  • Onko ohjelmistolla menettelyohjetta patenttiloukkausten suhteen?
  • Onko ohjelmistolla prosessia tekijänoikeuksien hallintaan?
  • Onko ohjelmistolla omaa Usenet-ryhmää (kertoo projektin iästä)?

7.3 JIT 2007 ja avoin lähdekoodi

7.3.1 Yleistä

Mahdollisimman vakioitujen ehtojen käyttäminen hankinnoissa on ehdottoman järkevää. Tämä helpottaa sekä toimittajan että hankintayksikön elämää lisäten erityisesti varmuutta tehdyn oikeustoimen sisällöstä. Avoimen lähdekoodissa on luonnollisesti sama. Julkisen hallinnon tietohallinnon neuvottelukunta (JUHTA) suosittelee, että ”valtion virastot, liikelaitokset, laitokset ja rahastot sekä kunnat ja kuntayhtymät käyttävät …Julkisen hallinnon IT-hankintojen sopimusehtoja (JIT 2007) hankkiessaan IT- tuotteita ja palveluita.”

Ehdot koostuvat Yleisistä ehdoista ja niitä täydentävistä liitteistä:

(i) Yleiset sopimusehdot (JIT 2007 – Yleiset ehdot)

(ii) Erityisehtoja tilaajan sovellushankinnoista (JIT 2007 – Sovellukset)

(iii) Erityisehtoja palveluista (JIT 2007 – Palvelut)

(iv) Erityisehtoja konsultointipalveluista (JIT 2007 – Konsultointi)

(v) Erityisehtoja valmisohjelmistohankinnoista (JIT 2007 – Valmisohjelmistot)

(vi) Erityisehtoja laitehankinnoista (JIT 2007 – Laitteet)

On syytä huomioida, että JIT 2007 ei sisällä varsinaista sopimusta, jossa määriteltäisiin hankinnan osapuolet, kohde, toimituksen tai palvelun sisältö hinnat ym. yksilöivät seikat. Tällainen tulee siis aina laatia erikseen. Toiseksi JIT 2007:ssä esiintyy myös yleisesti toteamus ”jollei toisin ole kirjallisesti sovittu”. Näissä kohdissa on haluttu antaa signaali, että asiasta ehkä todellakin kannattaisi sopia toisin tai ainakin asiaa tulisi harkita huolellisesti.

7.3.2 JIT ja avoimen lähdekoodin erityisehdot

JIT 2007:n soveltamisohje kommentoi avoimen lähdekoodin ja JIT 2007:n suhdetta seuraavasti:

Avoimen lähdekoodin käyttö on lisääntynyt IT-projekteissa. Näissä sopimusehdoissa on lähdetty siitä, ettei avoimen lähdekoodin käyttö yleensä poikkea muiden kolmansien osapuolten komponenttien käyttämisestä toimituksessa. Koska avoimen lähdekoodin lisenssiehdot eivät ole kovin hyvin tunnettuja, sopimusehtoihin on sisällytetty ehto, jonka mukaan toimittajan tulee selvittää tilaajalle avoimen lähdekoodin käyttöön liittyvät ehdot ja varmistaa, etteivät kyseiset ehdot tule sovellettavaksi tilaajan muihin ohjelmistoihin, jollei siitä ole sovittu. Mikäli tilaaja edellyttää tuotteen avoimen lähdekoodin luomista tilaajaa varten, sopijapuolten tulee sopia tapauskohtaisesti avoimen lähdekoodin käyttöön ja lisensiointiin liittyvistä kysymyksistä, kuten lisenssiehdoista ja lähdekoodin julkaisemisesta.

JIT 2007:n peruslähtökohtana on siis, että avoimen lähdekoodin ohjelmistot eivät poikkea muista ohjelmistotuotteista, joiden oikeudet kuuluvat kolmansille osapuolille. Niihin sovelletaan täysin yhteneväisesti toimittajan vastuuta koskevia säännöksiä, testausta, hyväksymismenettelyitä jne. Avoin lähdekoodi on määritelty JIT 2007:ssä seuraavasti (Liite 2: Yleiset sopimusehdot):

”Avoin lähdekoodi tarkoittaa ohjelmistoja, joiden käyttöä koskevat osoitteessa http://www.opensource.org/ yksilöidyt käyttöoikeusehdot tai joiden käyttöoikeusehtoihin sisältyy vaatimus julkaista tai muuten luovuttaa lähdekoodi, jos tilaaja levittää sitä kolmansille osapuolille.”

Muotoilu kattaa kaikki yleisimmät avoimen lähdekoodin lisenssit (OSI-hyväksyttyjä) sekä tämän lisäksi kohdassa 4.2 käytetyn jaottelun mukaisesti kaikki heikkoa ja vahvaa vastavuoroisuutta edellyttävät lisenssit. Sen sijaan sallivat lisenssit, jotka eivät ole saaneet OSI-hyväksyntää, eivät ole määritelmän piirissä.

Käytännön seurauksia on kaksi. Yleisissä sopimusehdoissa Takuu-kohdan alle sijoitetussa ehdossa todetaan seuraavaa:

”(9) 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.”

Kohdan mukaan toimittajan tulee kertoa, mitä oikeuksia ja velvollisuuksia sopimus tuo tullessaan. Tilanne ei tältä osin poikkea merkittävästi perinteisten kaupallisten tuotteiden käytöstä, joiden mukana toimitetaan yleensä niiden lisenssiehdot. Yksinkertaisimmillaan ehto täyttyy toimittamalla tuotteen mukana siinä käytetyt avoimen lähdekoodin lisenssit.

Käytännössä useimmissa tapauksissa järkevin tapa kohdan täyttämiseen on luettelo, jossa listataan toimituksen mukana tulevat ohjelmistot ja niistä löytyvät lisenssit. Avoimeksi jää sellainen tilanne, jossa avoimen lähdekoodin käytöstä ei ole erikseen sovittu. Periaatteessa tällöin ei ole erillistä velvollisuutta luovuttaa käyttöehtoja koskevia ehtoja.

Kohdan toinen edellytys on huomattavasti haasteellisempi toimittajalle. Sen tarkoituksena on estää vahvaa vuorovaikutusta edellyttävien lisenssien (esimerkiksi GPL) ehtojen laajeneminen niin, että kattavat tilaajan olemassa olevia ohjelmistoja. Tilannetta tosin helpottaa se , että läheskään kaikissa toimituksissa tämä ei ole edes teoriassa mahdollista. Kohta ei esimerkiksi luonnollisestikaan sovellu ohjelmistoihin, joiden lisenssit ovat sallivia (esimerkiksi BSD) tai edellyttävät ainoastaan normaalia vastavuoroisuutta (esimerkiksi Mozilla Public License). Samoin jos ohjelmaa ei levitetä hankintayksikön ulkopuolelle, vastavuoroisuusvelvollisuutta ei synny.

Käytännössä voidaankin olettaa, että toimittajat pyrkivät rajaamaan "sopimuksen mukaisen käytön" hankintayksikön sisäiseksi käytöksi, jolloin kohdan merkitys katoaa. Tätä ei voida myöskään pitää täysin kohtuuttomana, koska erilaisten avoimen lähdekoodin integrointitapojen määrittely ennakoivasti olisi sopimuksissa melkoisen haasteellinen tehtävä.

7.3.3 JIT:n yleiset ehdot

JIT:n ehdoissa on myös muita kohtia, joilla on suoraa merkitystä avoimen lähdekoodin hankintaprosessille. Erityisen keskeinen on immateriaalioikeuksia koskeva kohta.

Toimittaja on ehtojen mukaan täysin vastuussa myös toimittamistaan avoimen lähdekoodin tuotteista. Osalle toimittajista tämä saattaa olla liian kova pala nieltäväksi, koska täydellinen IPR-auditointi on usein käytännössä mahdotonta ainakin laajoja kokonaisuuksia käsittävissä avoimen lähdekoodin toimituksissa. Tällaisissa tilanteissa hankintayksikön kannattaa suorittaa oma riskianalyysi ja miettiä, kummasta aiheutuu enemmän ongelmia, potentiaalisten toimittajien vähenemisestä vai kustannustason noususta (varsin teoreettisissa) loukkaustilanteessa.

On myös syytä huomioida, että pienten toimittajien tosiasiallinen kestokyky esimerkiksi laajahkoa patenttioikeudenkäyntiä vastaan on varsin rajallinen. Onkin pelättävissä, että toimittajat sitoutuvat helposti ehtoihin, joita eivät tositilanteen tullessa kykenisi kantamaan. Tilanne ei tältä osin poikkea merkittävästi perinteisten suljetun lähdekoodin tuotteisiin.

8 Opastavat tiedot

8.1 Suosituksen ylläpito

Tätä suositusta ylläpitää Julkisen hallinnon tietohallinnon neuvottelukunta JUHTA, puh. 0295 16001, sähköposti: jhs-sihteeri@jhs-suositukset.fi.

JHS-järjestelmän verkkosivut: http://www.jhs-suositukset.fi/

8.2 Liitteet

  • Liite 1: Linkkejä tietovarantoihin ja ohjelmistohakemistoihin.