Julkishallinnossa tilaaja valitsee (yleensä) lisenssin
Julkishallinnon kehitysprojekteissa tekijänoikeus tuotetusta koodista muodostuu yleensä tilaajalle. Tällöin vastuu lisensoinnista on tilaajalla. Harva projektipäällikkö tai tuoteomistaja on kuitenkaan vielä perehtynyt kaikkiin avoimen lähdekoodin määritelmää ylläpitävän OSI:n hyväksymiin lisensseihin, jolloin lisenssin valintaan käytetään yleensä jotain kolmesta menetelmästä:
1. Valitaan vaan joku tuttu lisenssi nopeasti.
2. Annetaan lisenssivalintapäätös kehittäjille.
3. Vatvotaan asiaa kuukausia saattaen jopa kiusata sopivaa lakimiestä, joka ei ole asiaan perehtynyt.
Kaikissa näissä menetelmissä on ongelmansa. Lähdetään siis liikkeelle tavallisimmasta käyttötapauksista.
Valmis projekti pohjana
Yksinkertaisin tapaus lisenssin valinnan kannalta on käytettäessä valmista avoimen lähdekoodin ratkaisua pohjana. Silloin on vain yksi ainut oikea ratkaisu eli saman lisenssin käyttäminen.
Saman lisenssin käyttäminen suojaa mahdollisilta ongelmilta tulevaisuudessa. Jos muokatun projektin lähdekoodista löytyisi tekijänoikeusrikkomus kuten lisensoimatonta kopioitua koodia tai patenttiloukkaus, niin koko projektin käyttäjäyhteisöllä on yhteinen intressi korjata ongelma.
Useita valmiita projekteja pohjana
Useammasta eri avoimin lisenssein julkaistuista tuotteesta koostuvan järjestelmän tapauksessa tilanne on monimutkaisempi. Perusperiaate on sama kuin aiemmin, eli kuhunkin osajärjestelmään tehtävät muutokset kannattaa lisensoida alkuperäisellä lisenssillä. Lisäksi on selvitettävä eri lisenssien yhteensopivuus, jotta integraatiossa ei tapahdu lisenssirikkomuksia.
Useiden lisenssien käyttö saattaa olla alussa sekavaa, mutta se ohjaa myös kehittäjiä pitämään eri järjestelmän osien rajoja selvinä. Samaa linjaa on hyvä jatka, mikäli palvelu on muutenkin jaoteltu eri komponentteihin kuten kaikki modernit ohjelmistot.
Sallivat lisenssit
Salliva lisenssi on avointa lähdekoodia, joka ei vaadi uudelleenkäyttäjää julkaisemaan omia tuotoksia. Sallivat lisenssit ovat houkuttelevampia kaupallisille toimijoille kuin vastavuoroiset lisenssit. Salliva lisenssi voi olla järkevä valinta, mikäli palvelun funktio on toimia esimerkkinä tai täydentää kaupallisten palvelujen tarjontaa.
Sallivista lisensseistä tunnetuimmat ovat MIT-lisenssi ja BSD-lisenssi. BSD-lisensseistä on useita versioita, joista osa vaatii tai kieltää tekijänoikeuden haltijan tietojen liittämisen koodia käyttäviin ohjelmistoihin. Yleensä nämä vaatimukset eivät ole oleellisia julkishallinnon palveluissa, joten on järkevämpää käyttää yksikäsitteistä MIT-lisenssiä.
Apache Public Licence (APL) on yleinen lisenssi, jossa on heikko vastavuoroisuusehto. APL:n vastavuoroisuusehto käytännössä estää palveluasi vastaavan palvelun levittämisen ilman lähdekoodin julkaisemista avoimella lisenssillä. On erittäin harvinainen tilanne, jossa julkisen palvelun näkökulmasta APL:n vastavuoroisuusehto olisi tarpeellinen. On siis parempi suosia MIT-lisenssiä. Mikäli tämmöinen tilanne kuitenkin on jo tullut vastaan, kuulisin siitä mielelläni lisää.
Vastavuoroiset lisenssit
Vastavuoroisissa lisensseissä on nk. copyleft ehto joka pakottaa koodin uudelleenkäyttäjät julkaisemaan omat muutoksensa ja näin edesauttaa muiden tekemien muokkausten ja korjausten käyttöä. Vastavuoroiset lisenssit ovat houkuttelevampia yksittäisille kehittäjille, jotka ideologisista syistä haluaisivat tukea julkisten palveluiden kehitystä.
Vastavuoroisten lisenssien suvun matriarkka on GPL ja koko GPL-perhe on vielä hyvässä vedossa. Palvelukehityksessä sopivin vastavuoroinen lisenssi on AGPL. Se eroaa muista sisaruksistaan SAAS-ehdolla. Ehdon mukaan kaikki lähdekoodin muokkaukset on julkaistava myös silloin kun siihen perustuvaa palvelua tarjotaan julkisesti. Muissa GPL-lisensseissä tätä ehtoa ei ole, joten ne ovat verkkopalvelukehityksessä käytännössä sallivia lisenssejä.
Saitko EU-rahaa?
Mikäli on käynyt niin hienosti että osa tai kaikki palvelun rahoituksesta tulee EU:lta, rahoihin todennäköisesti liittyy vaatimus EUPL:n (European Union Public License) käytöstä. Lisenssi poikkeaa yleisesti käytetystä copyleft-lisenssi GPL:stä pääasiassa siinä, että riidat on määritelty selvitettäväksi EU:n tekijänoikeuslainsäädännön alla.
EUPL:n versiosta 1.1. lähtien on mukana myös SAAS ehto kuten AGPL:ssä. Valitettavasti EUPL ei ole suoran yhteensopiva GPL-perheen lisenssien kanssa. Mikäli EUPL-lisensoitua koodia on käytettävä tiivisti GPL-komponenttien kanssa, on se mahdollista jos riittävän laaja osa järjestelmää rinnakkaislisensoidaan CeCILL-lisenssillä ja sopivalla GPL:llä.
Vertailu GPL:stä ja EUPL:stä löytyy täältä.
Microsoftia
Microsoftin julkaistua osat omista työkaluistaan avoimilla lisensseillä onkin teoriassa mahdollista käyttää myös MS-työkaluja avoimen lähdekoodin julkishallinnon projektissa. Tästä ei ole vielä kokemuksia, mutta voidaan veikata että Microsoftin avoimen lähdekoodin ekosysteemi tulee perustumaan Microsoftin lisensseihin. Jolloin kysymyksessä on valinta sallivan Microsoft Public Licensen (MS-PL) ja vastavuoroisen Microsoft Reciprocal Licensen (MS-RL) välillä.
Kehitetään oma lisenssi
Muu lisenssi
Jos sinulla on hyvä ehdotus miksi jotain toista avoimen lähdekoodin lisenssiä tulisi edes harkita niin perustele ehdotuksesi kommenteissa.
HUOM
Oman palvelun lisenssin valinnalla ei voida kokonaan estää tekijänoikeusrikkomuksia, jotka johtuvat epäyhteensopivasti lisensoitujen kolmannen osapuolten julkaisemien avoimen lähdekoodiin komponenttien käytöstä. Näistä on myös palvelun tekijänoikeuden haltija vastuussa. Lisenssin valinta on kuitenkin ensimmäinen päätös, joka luo pohjan onnistuneelle avoimen lähdekoodin lisenssien hallinnalle palvelun kehitysprojektissa.
