Avoimen lähdekoodin periaatteet tukevat yliopiston ohjelmistojen avointa kehittämistä

Tietotekniikkakeskus julkaisi yliopiston uudet avoimen lähdekoodin periaatteet loppuvuodesta 2022. Tässä kirjoituksessa vastataan muun muassa kysymyksiin siitä, mitä avoimen lähdekoodin periaatteet ja avoimuus tarkoittavat, keitä periaatteet koskevat ja mistä niiden soveltamiseen saa tarkempaa ohjeistusta ja lisätietoa.

(This article is also available in English.)

Teksti: Tiina Silvonen, Petteri Hemmilä ja Jukka Karvonen (Tietotekniikkakeskus, Helsingin yliopisto)

Avoimuudessa ei ajatuksena ole mitään uutta, sillä yliopistolla on suosittu avointa lähdekoodia jo pitkään. Nyt julkaistut avoimen lähdekoodin periaatteet muotoilevat avoimuuden linjauksen ymmärrettävään muotoon, jolloin aiheesta on helpompi viestiä.

Avoimen lähdekoodin hyödyt

Avoimuus on yliopistolle strateginen valinta, jonka tuomia etuja ovat muun muassa:

Yhteisöllisyys Avoimuuden merkittävimpiin hyötyihin lukeutuvat yhteisöllisyys ja yhdessä tekeminen, jotka voivat toteutua vain avoimuuden kautta. Avoimessa lähdekoodissa kaikki on avointa, jolloin koodin avulla on mahdollista selvittää, miten ohjelma toimii, miten tietoa käsitellään ja miten toiminnallisuus on muuttunut ajan saatossa. Laatu Parempi laatu nähdään usein yhtenä avoimen lähdekoodin merkittävimmistä eduista. Koska avointa ohjelmistoa kehitetään yhteistyössä, myös useampi silmäpari tarkastaa koodin. Avoimesti julkaistavan aineiston halutaan myös lähtökohtaisesti olevan laadukasta, sillä kehittäjän omalla nimellä julkaisema koodi on osa julkista käyntikorttia. Siksi myös aineiston kieliasu, rakenne ja kommentit laaditaan yleensä erityisen huolellisesti. Ketteryys Avoin lähdekoodi mahdollistaa ketterän ohjelmistokehityksen, jossa uusia ominaisuuksia tehdään tarpeeseen ja oikea-aikaisesti. Kuka tahansa voi tehdä avoimeen lähdekoodiin muokkauksia milloin tahansa, mikä tukee ketterää kehitystä. Jos organisaatiossa puolestaan hyödynnetään ulkopuolella tuotettua suljettua koodia, on halutut muutokset tilattava erikseen, mikä ei yleensä ole kovin ketterää. Toimittajariippuvuuden välttäminen Avoimen lähdekoodin kaikki toiminnallisuudet ja ominaisuudet ovat avoimesti nähtävillä. Jos avoimen lähdekoodin tuotteessa ei ole niitä ominaisuuksia, joita itse kaipaisi, on ohjelmistoa mahdollista kehittää itselle mieluisaan suuntaan. Joskus suljettujen ohjelmistojen kohdalla päädytään toimittajariippuvuuteen, koska vain yksi taho pystyy kehittämään tuotetta. Avoimilla ratkaisuilla vähennetään tätä riskiä. Kustannustehokkuus Avointen sovellusten käyttäminen on usein kustannustehokasta. Avoimuutta ei kuitenkaan kannata mieltää ilmaiseksi – vaikka avointen sovellusten käytöstä ei tarvitse maksaa lisenssimaksuja, vaatii käyttö silti osaamista ja resursseja. Omalle toiminnalle tärkeiden sovellusten tai komponenttien tukeminen on kannattavaa, vaikka se ei pakollista olekaan. Monia avoimia sovelluksia kehitetään yhteisön tuella – tuki voi olla rahallista tai osallistumista kehitykseen jopa kokonaisten henkilöresurssien verran. Laajempi osallistuminen mahdollistaa usein myös omalle toiminnalle tärkeiden toiminnallisuuksien edistämisen ja vähentää toimittajariskiä, koska omassa talossa on hyvää sovellusosaamista. Kehittäjäyhteisön koordinointi voi viedä pääkehittäjiltä merkittävästi resursseja. Kehitystoiveisiin ja bugi-ilmoituksiin odotetaan vastaamista, minkä lisäksi muiden mahdollisia kontribuutioita täytyy sekä käydä läpi että arvioida niiden soveltuvuutta sovelluksen tavoitteisiin ja arkkitehtuuriin.

Haasteet

Avoimen lähdekoodin käyttöön liittyy myös haasteita:

• Avoimessa lähdekoodissa ei ole yleensä takuuta.
• Hyödyntäjä voi yrittää selvittää, kuinka aktiivinen yhteisö avoimen tuotteen taustalla on, mutta tämäkään ei pitkällä aikavälillä takaa aktiivista kehitystyötä.
• Avoin lähdekoodi ei myöskään aina tarkoita hyvää ja laadukasta lähdekoodia. Koodissa voi olla virheitä ja haavoittuvuudet ovat nopeasti yleisessä tiedossa. Avoimen koodin tuotteissa ei välttämättä ole saatavilla tukipalveluita.
• Kaikessa toiminnassa on riskejä, eikä avoin lähdekoodi ole poikkeus. Riskit tulee tunnistaa ja niihin tulee varautua.

Miksi juuri minun pieni sovellukseni tulisi avata?

Koodi kannattaa avata lähes aina, ja avoimuus tulee nähdä lähtökohtana. Vaikka oman sovelluksen hyötypotentiaali muille olisi pieni, on hyvä pitää mielessä, että yhteiskehittämisen hyödyt saavutetaan vain avoimuuden kautta. Ohjelmistossa voi olla teknisiä komponentteja, jotka ovat kuitenkin yleisesti hyödynnettävissä.

Julkisena organisaationa haluamme myös toimia läpinäkyvästi. Kehittämistyössä on tärkeää, että kehittäjät hyödyntävät muiden tuottamaa avointa koodia ja osallistuvat myös itse muualla tuotetun avoimen koodin kehittämiseen.

Koodi kannattaa avata lähes aina, ja avoimuus tulee nähdä lähtökohtana. Vaikka oman sovelluksen hyötypotentiaali muille olisi pieni, on hyvä pitää mielessä, että yhteiskehittämisen hyödyt saavutetaan vain avoimuuden kautta.

Avoimen koodin lisensointi

Jos itse kehitetty tuote herättää kiinnostusta ja sen kehittäjäkunta laajenee, kehittäminen yleensä nopeutuu. Oman koodin kaupallista jatkokäyttöä voi olla vaikea estää, mutta oikealla lisenssivalinnalla koodi ja tuote pidetään jatkossakin avoimena.

Lisenssi on dokumentti, joka kertoo miten ohjelmaa voi julkaista ja käyttää. Avoimia lisenssejä on kahta erilaista päätyyppiä – tarttuvia ja sallivia. Nämä lisenssityypit eroavat toisistaan keskeisesti ennen kaikkea siten, että tarttuva lisenssi sisältää enemmän rajoituksia. Tarttuvuudella – eli vahvalla vastavuoroisuuden velvoitteella – tarkoitetaan sitä, että lisenssi on julkaistava alkuperäisellä lisenssillä edelleen jaettaessa (esim. muunnokset tai kopiot), mutta myös silloin, jos ohjelmaan lisätään uusia komponentteja linkittämällä. Yleisin tarttuva lisenssi on GPL.

Helsingin yliopiston avoimen lähdekoodin linjaukset lähtevät siitä, että lähdekoodi julkaistaan avoimena, eikä sen jatkokäyttöä turhaan rajoiteta. Tämän vuoksi lisenssiksi suositellaan MIT-lisenssiä, joka on salliva lisenssi yksinkertaisilla ja selkeillä lisenssiehdoilla.

MIT-lisenssin on kehittänyt Massachusetts Institute of Technology (MIT). MIT-lisenssi velvoittaa pitämään alkuperäisen lisenssitekstin ja tekijänoikeuslausekkeen mukana sovellusta jaettaessa, mutta antaa muuten koodin hyödyntäjälle täydet oikeudet tehdä kopioita ja muokkauksia lähdekoodiin. MIT-lisenssillä julkaistuja ohjelmia voi edelleen lisensoida toisilla lisensseillä. MIT-lisenssillä julkaistuja ohjelmistoja voi esimerkiksi liittää GPL-lisenssillä julkaistuihin ohjelmistoihin ja käyttää niihin GPL-lisenssiä. GPL-lisenssillä julkaistuja ohjelmistoja ei puolestaan voi jakaa eteenpäin MIT-lisenssillä.

Avoimen lähdekoodin tuotteissa voidaan käyttää myös kaksoislisensointia. Tällöin avoimen lähdekoodin tuote julkaistaan myös kaupallisella lisenssillä, joka mahdollistaa lisenssimaksuja vastaan tuotteen muokkaamisen ja levityksen ilman muokatun koodin julkistamista.

Avoimen koodin julkaisu ja Helsingin yliopiston soveltamisohjeet

Avoimen lähdekoodin on oltava avoimesti muiden saatavilla. Luontevinta on julkaista koodi GitHub-versionhallintapalvelussa, joka on vakiintunut avoimen koodin julkaisupaikka. Koodi kannattaa julkaista siten, että sen ymmärretään olevan Helsingin yliopiston julkaisemaa materiaalia. Ohjeita koodin julkaisemiseen löydät tietotekniikkakeskuksen ylläpitämistä avoimen lähdekoodin soveltamisohjeista.

Soveltamisohjeissa on myös kerrottu, milloin avoimuudesta on perusteltua poiketa. Mikäli käyttöön otettava ohjelmisto on osa kriittistä infrastruktuuria tai sillä käsitellään salaista tietoa, tulee varmistaa, ettei lähdekoodin avoimuus muodosta uhkaa tietoturvalle tai tietosuojalle. Myös laadulliset syyt voivat estää koodin julkaisun.

Jokaisessa ohjelmistokehitysprojektissa tulisi käydä keskustelua koodin avoimuudesta. Käsiteltäviä aiheita voivat olla mm:

• Voimmeko me julkaista lähdekoodimme?
• Millainen on meidän ohjelmistojen laatu?
• Millaisia riskejä avoimuuteen liittyy?
• Millaisia hyötyjä voidaan saavuttaa?

Avoimuuden riskeistä ja hyödyistä on hyvä muodostaa yhteisymmärrys projektitiimissä. Annamme tietotekniikkakeskuksessa mielellämme aiheeseen liittyvää neuvontaa ja muita vinkkejä osoitteessa: versionhallinta@helsinki.fi.

---

Tiina Silvonen työskentelee ryhmänvetäjänä tietotekniikkakeskuksen ohjelmistotuotantoryhmässä.

Petteri Hemmilä toimii tietotekniikkapäällikkönä tietotekniikkakeskuksen tietotekniikkaratkaisut-yksikössä.

Jukka Karvonen työskentelee tietotekniikka-asiantuntijana tietotekniikkakeskuksen käyttäjähallintoryhmässä.