Source: http://docs.jhs-suositukset.fi/jhs-suositukset/JHS169/JHS169.html
Timestamp: 2019-03-25 21:45:09+00:00
Document Index: 5039475

Matched Legal Cases: ['kko\n', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ', 'kko ']

Versio: 1.1 5.10.2012
4.1 Huomioi ohjelmistojen jakaminen ja uudelleenkäyttö hankinnoissa
4.2 Julkaise muokatut ohjelmistot avoimella lisenssillä
4.3 Käytä avoimia standardeja ja rajapintoja
4.4 Tarkista lisenssin avoimuus
4.5 Varmista riittävä asiantuntemus käyttöönotossa
4.6 Kartoita ja vertaile vaihtoehtoja
4.7 Selvitä tietoturvariskit
5 Johdanto avoimeen lähdekoodiin
5.1 Avoimen lähdekoodin evoluutio
5.2 Avoimen lähdekoodin ohjelman määritelmä
5.3 Tietokoneohjelman lähdekoodi
5.4 Avoimen lähdekoodin ohjelma kaupallisena ohjelmana
5.5 Avoimet rajapinnat ja standardit
5.5.1 Avoimet rajapinnat
5.5.2 Avoimet standardit
5.6 Yhteenveto avoimen lähdekoodin hyödyistä ja haasteista
5.6.1 Hyötyjä
5.6.1.1 Ohjelmistokehityksen nopeutuminen
5.6.1.2 Paikallisten toimijoiden kilpailuedellytysten parantaminen
5.6.1.3 Toimittajariippuvuuden pieneneminen ja vapaa kilpailutus
5.6.1.4 Yhteiskunnallinen riippumattomuus
5.6.1.5 Kustannussäästöt
5.6.1.6 Kansalaisten yhdenvertaisuuden paraneminen
5.6.1.7 Lähdekoodin tarkistettavuus
5.6.1.8 Ohjelmiston avoimen jakamisen edut ja versionhallinnan haasteet
5.6.2 Haasteita
5.6.2.1 Avoimen lähdekoodin ohjelmistojen saatavuus ja sopivuus
5.6.2.2 Kaupallisten toimijoiden löytäminen
5.6.2.3 Ylläpito- ja muutoksenhallinta
5.6.2.4 Avoimen lähdekoodin käyttöönoton vaatimat omat resurssit (oma käyttöönotto)
5.7 Avoimen ja suljetun lähdekoodin vertailutaulukko
5.8 Avoimen lähdekoodin liiketoiminta
5.9 EU:n linjaukset suhteessa avoimiin ohjelmistoihin ja standardeihin
5.10 Avoin lähdekoodi muissa suosituksissa
6 Avoin lähdekoodi ja hankintaprosessi
6.1 Toimintamalleja esiselvitysvaiheeseen
6.1.1 Perehdy avoimien ohjelmien mahdollisuuksiin ja erityispiirteisiin
6.1.2 Vaatimusmäärittely ja esiselvitysvaihe ovat olennaisia onnistuneen ohjelmisto- tai järjestelmähankinnan kannalta
6.2 Seitsemän askelta avoimen lähdekoodin ohjelmiston mahdollisuuden arviointiin
6.3 Avoimen ohjelmiston ja suljetun ohjelmiston hankinnan erot
6.4 Esiselvitysvaiheessa avoimiin ohjelmistoihin liittyvät erityispiirteet
6.5 Avoimiin ohjelmistoihin liittyvät erityiskysymykset tarjouspyyntöä laadittaessa ja arvioitaessa
6.5.1 Kelpoisuuskriteereihin kuuluvat laatutekijät
6.5.1.1 Referenssit
6.5.1.2 Henkilöstön pätevyys
6.5.1.3 Toimitusvarmuus
6.5.2 Tarjousten vertailuun liittyvät tekijät
6.5.2.1 Kokonaisratkaisun soveltuvuus
6.5.2.2 Hinta
6.6 Ohjelmiston hankkiminen avoimen lähdekoodin lisenssillä
7 Avoimen lähdekoodin juridisia kysymyksiä
7.1 Tekijänoikeus ja avoimen lähdekoodin ohjelmistolisenssit
7.1.1 Nykytila
7.1.2 Avoimen lähdekoodin lisenssit
7.1.3 Lisenssityyppejä
7.1.3.1 Sallivat lisenssit
7.1.3.2 Vastavuoroisuutta edellyttävät lisenssit
7.1.3.3 Vahvaa vastavuoroisuutta edellyttävät lisenssit
7.1.4 Vastuukysymykset ja avoimen lähdekoodin lisenssit
7.2 Avoimen lähdekoodin riskit ja niiden hallinta
7.2.1 Riskianalyysin osa-alueet
7.2.1.1 Vaihtoehtoisten toimittajien saatavuus
7.2.1.2 Takuut ja vastuut
7.2.1.3 Avoimen lähdekoodin tuotteiden elinkaari
7.2.1.4 Lähdekoodin saatavuuden merkitys
7.2.1.5 Teknologiariskit
7.2.2 Menettelytavat riskien hallintaan
7.2.3 Hankintatapaan liittyvien riskien arviointi
7.2.3.1 Itsenäinen hankinta
7.2.3.2 Ulkoinen toimittaja
7.2.4 Tuotteen elinkelpoisuuden arviointi
7.2.5 Tuotteen jatkokehityksen arviointi
7.2.6 Riskien tarkistuslista
7.3 JIT 2007 ja avoin lähdekoodi
7.3.2 JIT ja avoimen lähdekoodin erityisehdot
7.3.3 JIT:n yleiset ehdot
8 Opastavat tiedot
8.1 Suosituksen ylläpito
8.2 Liitteet
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.
Tämä suositus koskee julkisen hallinnon tietohallintoa ja erityisesti tietojärjestelmien ja ohjelmistojen hankintaa, mutta sitä voidaan hyödyntää myös yksityissektorilla.
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ä.
Ks. avoin ohjelma.
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
yhdistää ja levittää ohjelmaa toisten ohjelmien kanssa.
Termi avoin lähdekoodi voidaan käytännössä vaihtaa termiin vapaa 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.
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.
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.
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/
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.
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.
Ks. vapaa ohjelma.
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).
Tässä suosituksessa hankinnalla tarkoitetaan tavaran, hyödykkeen tai palvelun vastikkeellista hankkimista julkisia hankintoja koskevan lainsäädännön tarkoittamalla tavalla.
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.
Käyttöönotolla tarkoitetaan tässä suosituksessa organisaation tai sen toimittajan suorittamia toimenpiteitä, joilla tietty järjestelmä tai ohjelmisto otetaan käyttöön.
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ää.
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.
Ks. avoin lähdekoodi.
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.
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.
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.
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.
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.
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.
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.
Johdettujen teosten luominen ja levitys pitää sallia.
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.
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.
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.
Ohjelmisto saatavissa useilta toimittajilta
Ohjelmisto saatavissa vain yhdeltä toimittajalta
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.
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.
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.
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.
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ä.
Avoimen lähdekoodin avulla voidaan nopeuttaa joustavien ja innovatiivisten IT-ratkaisujen rakentamista ja alentaa kustannuksia hyödyntämällä valmiita ohjelmia ja ohjelmakomponentteja.
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.
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.
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.
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ä:
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.
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.
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.
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.
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.
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.
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.
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.
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ä.
Taulukko 3. Avoimen ja suljetun lähdekoodin vertailu.
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.
Voivat tuottaa ohjelmakoodia ja palveluja.
Palvelujen ja erityisesti ohjelmakoodin tuotanto on rajoitettua.
Riippuvuutta oikeuksien omistajaan ei ole, toimittaja vaihdettavissa.
Ohjelmiston oikeuksien omistaja kontrolloi toimittajakenttää.
Yhdenvertaisessa roolissa. Ohjelmistoja voidaan jakaa kaikille.
Ohjelmistojen käyttölisenssit ovat yleensä maksullisia. Tämä asettaa kansalaiset eriarvoiseen asemaan mm. varallisuuden mukaan.
Lähdekoodi voidaan vapaasti luovuttaa kenelle tahansa arvioitavaksi ja tarkistettavaksi.
Lähdekoodin tarkistettavuus vaatii sopimisen ohjelmiston oikeuksien omistajan kanssa.
Lähdeoodi voidaan vapaasti luovuttaa kenelle tahansa arvioitavaksi.
Lähdekoodin laadukkuus vaatii sopimisen ohjelmiston oikeuksien omistajan kanssa.
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.
Hankinnan kohde - avoin
Hankinnan kohde - suljettu
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 ole tyypillisesti käytössä julkishallinnossa.
Laitteeseen sulautettu
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.
Ei hankita, koska se on vastikkeeton
Avoimen lähdekoodin ohjelmissa ei ole perinteisiä lisenssimaksuja. Ns. kaksoislisensointi on mahdollinen, jolloin avoimesta ohjelmasta on maksullisesti saatavilla eri lisenssiehdoilla varustettu versio.
Hankitaan tuote- ja palvelupaketti
Avoimella puolella ei välttämättä lisenssimaksuja.
Ohjelmisto palveluna, Software as a Service (SaaS),
Hankinnassa (ja palvelussa) ei ole mitään eroa.
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ä.
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.
Avoimeen lähdekoodiin ja hankintaprosessiin liittyvät erityiskysymykset voidaan jakaa seuraavasti:
avoimen lähdekoodin ohjelmistoihin liittyvät erityispiirteet esiselvitysvaiheessa
avoimen lähdekoodin vaihtoehdon mahdollistavan tarjouspyynnön tekeminen
tarjousten arvioimisessa huomioon otettavat asiat, kuten toimittajariippuvuuden riskin arviointi.
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.
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.
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.
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ä.
Oheiseen taulukkoon on koottu tärkeimmät avoimien ja suljettujen ohjelmistojen hankintaan liittyvät erot.
Taulukko 5. Avoimen ja suljetun ohjelmiston hankinnan vertailu.
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.
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?
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:
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.
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.
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ä.
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ä.
Ne mittaavat asioita, jotka ovat nimenomaan tyypillisiä avoimen lähdekoodin ohjelmistotuotannolle, kuten kehitysehdotusten tai korjausten tekemistä.
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.
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ää.
Mitkä ovat yrityksenne toimitusreferenssit tarjoamastanne ohjelmistosta?
Onko muita kannaltamme vertailukelpoisia kyseisen ohjelmiston tai ratkaisun käyttäjiä?
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.
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.
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.
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.
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:
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ä:
Oikeus ajaa ohjelmaa millä tahansa laitteistolla ja käyttää sitä mihin tahansa tarkoitukseen.
Oikeus jaella ohjelmistoa suoritettavassa ja lähdekoodimuodossa. Kaikilla käyttäjillä on yhtäläiset oikeudet ohjelmistoon.
Oikeus muokata ohjelmistoa haluamallaan tavalla ja jaella muutettua ohjelmistoa.
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.
Tarjouspyynnössä määritellään, että määräysvalta ohjelmiston lisensoinnista on hankintayksiköllä.
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.
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.
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.
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:
vastavuoroisuutta edellyttävät lisenssit
vahvaa vastavuoroisuutta edellyttävät 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:
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).
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.
Vapaa lähdekoodi
Normaali vastavuoroisuus
Vahva vastavuoroisuus
x (voi sisältää rajoituksia)
BSD, MIT, Apache , …
LGPL, MPL , EPL ...
GPL 2, GPL 3,CPL, ...
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.
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.
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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ä)?
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.
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ä.
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.
Liite 1: Linkkejä tietovarantoihin ja ohjelmistohakemistoihin.