Avoin lähdekoodi - Soveltamisohjeet
Helsingin yliopiston lähtökohtana on suosia avoimia teknologioita ja avoimen lähdekoodin ratkaisuja. Avoimen lähdekoodin periaatteita suositellaan noudatettavaksi kehitettäessä yliopistolle ohjelmistoja ja ohjelmiston osia.
Lue periaatteet yliopiston julkisilta sivuilta: Avoimen lähdekoodin periaatteet
Tältä sivulta löydät selventäviä käytännön ohjeita avoimen lähdekoodin periaatteiden soveltamiseen.
Tutustu ainakin roolisi mukaisiin kohtiin, olit sitten projektin omistaja, projektipäällikkö tai kehittäjä.
Soveltamisala (PO, PP)
Avoimen lähdekoodin periaatteet ovat tietohallintojohtajan hyväksymä tahdonilmaus ja suositus.
Helsingin yliopisto on julkisesti rahoitettu toimija ja yliopiston strategia tukee vahvasti avoimuutta. Yliopistolla työn puolesta tai ostopalveluna tuotettu lähdekoodi suositellaan julkaistavaksi lähtökohtaisesti avoimena.
Periaatteissa tarkoitettua lähdekoodia voi syntyä esimerkiksi:
- Tuotettaessa sisäisesti tai ostopalveluna yliopiston hallinnon tai opetustoiminnan käyttöön sovelluksia.
- Tuotettaessa sisäisesti tai ostopalveluna lisäosia käytössä oleviin sovelluksiin, kuten julkaisujärjestelmän moduuleja.
Tutkimustoiminnalla on ennestään erilliset avoimen tieteen periaatteet, joten ne on rajattu suosituksen ulkopuolelle. Vastaavat suositukset löytyvät tutkimustoiminnan omista periaatteista.
Avoimuudesta poikkeaminen (PO, PP)
Periaatteista on mahdollista poiketa perustellusta syystä. Syitä voi olla erilaisia, alla on muutama esimerkki:
- Vanha sovellus, joka on toteutettu ennen näiden periaatteiden voimassaoloa ja jonka materiaali lähtökohtaisesti on julkaisukelvotonta.
- Periaatteista palautetta kerätessä tämä nousi esiin huolena. Tämä on myös esimerkki siitä, miten avoin lähdekoodi usein ohjaa parempilaatuiseen ja harkitumpaan tuotokseen. Tästä on hyötyä sovelluksen ylläpidossa ja jatkokehityksessä. Julkaisukelvoton koodi tarkoittaa yleensä myös huonosti ymmärrettävää ja heikosti dokumentoitua koodia.
- Tällaisten sovellusten osalta tulisi pyrkiä saattamaan materiaali julkaisukuntoon esim. suurempien jatkokehityskierrosten aikana.
- Tietoturva esimerkiksi tapauksissa, joissa käsitellään arkaluonteisia tietoja. Tällöin kyseessä ovat ohjelmistot, joiden laadunvalvonta on jo lähtökohtaisesti poikkeuksellisen tarkkaa ja joille toteutetaan erillinen tietoturva-arviointi.
- Jos yliopiston tietoturvatiimi tai erillinen tietoturva-arviointi suosittaa, ettei koodia julkaista, on tämä perusteltu syy olla julkaisematta sitä.
- Usein näissä tapauksissa osa ohjelmistosta voidaan tästä huolimatta julkaista avoimesti.
- Lähdekoodi liittyy yksittäisten järjestelmien konfiguraatioon, joka ei ole yleisesti hyödynnettävissä.
- Skriptit, joilla sovellus konfiguroidaan Helsingin yliopiston käytössä toimivaksi.
Kehitystä on myös mahdollista tehdä suljetussa ympäristössä, esim. yliopiston omilla GitLab-palvelimilla, ja julkaista vain tuotantoversiot laajemmin käytettäväksi.
Viime kädessä ohjelmiston avoimuudesta päättää järjestelmän omistaja näiden periaatteiden pohjalta.
Yhteistyö ja yhteisöllisyys (PO, PP, kehittäjät)
Ohjelmistokehityksellä pyritään usein toteuttamaan tiettyä tarvetta ja nämä tarpeet ovat harvoin organisaatiokohtaisia. Myös monet muut yliopistot, korkeakoulut ja organisaatiot pyrkivät ratkaisemaan tai ovat jo ratkaisseet samoja ongelmia.
On kannustettavaa selvittää myös rinnakkaisyhteisöjen tarpeita ja ratkaisuja, sekä mahdollisuuksia täyttää tarpeet osallistumalla olemassa oleviin projekteihin tai tekemällä yhteistyötä muiden organisaatioiden kanssa.
Laatutavoitteet (PP, kehittäjät)
Ohjelmistojen avoimen julkaisun pääasiallisena tavoitteena on mahdollistaa niiden hyödynnettävyys myös muualla. Tämä asettaa tavoitteita ohjelmiston laadulle. Avoimen lähdekoodin sovelluksen laatutavoitteet eivät poikkea suljettujen sovellusten laatutavoitteista, mutta avoimuus asettaa näiden tavoitteiden toteutumisen julkisesti arvioitavaksi.
Luotettavuutta, uudelleenkäytettävyyttä ja ylläpidettävyyttä voidaan parantaa hyvillä sovelluskehityskäytännöillä, esimerkiksi:
- Hyvin suunniteltu arkkitehtuuri.
- Modulaarisuus. Ohjelmisto on jaettu funktionaalisiin osiin, jotka toimivat määritettyjen rajapintojen kautta toisten osien kanssa.
- Yleisesti käytettyjen koodi- ja dokumentointimallien noudattaminen.
- Monille kielille ja ohjelmistokehityksille on yleisesti käytettyjä tyylioppaita.
- Ulkoiseen ohjelmistoon osia toteuttaessa noudatetaan kyseisen sovelluksen tyyliohjeita.
- Selkeys, selittävyys, yhtenäisyys ja yksinkertaisuus koodissa ja dokumentoinnissa.
- Koodin testattavuus sekä riittävän kattavat automaatiotestit.
- Koodin tarkastus toisen henkilön toimesta ennen julkaisua.
- Käytetään koodin analysointiin kehitettyjä työkaluja.
Lisenssin valinta (PO, PP, kehittäjät)
Avoin lähdekoodi vaatii aina jonkin lisenssin. Lisenssi kertoo miten lähdekoodia voi hyödyntää, eikä lähdekoodi ole muiden käytettävissä ilman lisenssiä.
Lisenssi vaikuttaa niihin mahdollisuuksiin ja ehtoihin, joiden puitteissa ohjelmistoa tai sen osia voidaan käyttää uudelleen. Lisenssi voi myös rajata pois mahdollisuuksia käyttää tiettyjä komponentteja sovelluksissa.
Myös muita kuin suositeltuja lisenssejä on mahdollista käyttää perustellusta syystä.
Lähdekoodin osalta ensisijaisesti suositeltu lisenssi on MIT (malli):
Lisenssi on kehitetty Massachusetts Institute of Technology -yliopistossa Yhdysvalloissa.
MIT-lisenssi on helppo ymmärtää.
MIT-lisenssi ei velvoita tekijää mihinkään.
Ainoana rajoituksena on pitää tekijänoikeusteksti ja lisenssitieto mukana levitettävissä osissa.
MIT-lisenssi sallii uudelleenlisensoinnin rajatumpaan lisenssiin, eli sitä voidaan käyttää osana vaikkapa Apache 2 tai GPL-lisensoitua sovellusta.
Jos lähdekoodia tuotetaan osaksi valmista projektia, on perusteltua käyttää kyseisen projektin lisenssiä. Monet ohjelmistot käyttävät myös tarttuvaa lisenssiä, jolloin niiden osien käyttäminen vaatii oman ohjelmistokoodin julkaisua samalla lisenssillä. Hyvä esimerkki tällaisesta on Drupal, johon tuotetut moduulit julkaistaan GPL versio 2 tai myöhemmällä lisenssillä.
MIT on ensisijaisesti ohjelmistokoodille tehty lisenssi, eikä välttämättä sovellu kaikkiin muihin tarkoituksiin. Erilliselle dokumentoinnille, kuville ym. suositellaan suositellaan Creative Common s-lisenssiperheeseen kuuluvan CC BY -lisenssin ajantasaista versiota. Materiaalia voi julkaista myös täysin vapaaseen yleiseen käyttöön (Public Domain), esim. käyttäen CC0-lisenssiä.
Julkaisupaikka (PP, kehittäjät)
Jotta avoin lähdekoodi olisi kaikkien saatavilla, niin se tulee julkaista lähdekoodin julkaisulle tarkoitettuun paikkaan. De facto-paikka lähdekoodille on GitHub. GitHub on internetistä löytyvä koodin jakamiseen tarkoitettu alusta, joka on toteutettu Git-versionhallintajärjestelmällä (https://github.com/)
Ensisijainen julkaisupaikka HY:n avoimilla ohjelmistoilla on GitHubin University of Helsinki-organisaatio (https://github.com/UniversityofHelsinki) tai yksikön virallinen GitHub-organisaatio.
Kehityksessä käytetään usein HY:n GitLab-palveluita, mutta myös näistä olisi hyvä julkaista tuotantoversiot vähintään GitHubissa ja ohjeistaa siellä kehitykseen liittyvät asiat oikeaan paikkaan.
Käytännön ohjeita koodin julkaisuun löydät sivulta Versionhallinta.