(Jos avoin lähdekoodi on sinulle uusi asia, suosittelen yhteistyökumppanimme Cybercomin Panu Horsmalahden erittäin hyvää blogia avoimen lähdekoodin käytöstä moderneissa ohjelmistokehitysprojekteissa.)
Avoimen lähdekoodin hyödyllisyys ei perustu pelkästään lähdekoodin hyödyntämiseen vaan vastavuoroiseen kanssakäymiseen avoimen lähdekoodin yhteisöjen kanssa. Yritykset, jotka julkaisevat laadukasta avoimen lähdekoodia, houkuttelevat osaavia ohjelmistokehittäjiä eri tavalla kuin pelkät avoimen lähdekoodin hyödyntäjät. Yritykset, jotka julkaisevat bugikorjauksia käyttämiinsä avoimen lähdekoodin ohjelmistoihin, voivat päästä vaikuttamaan niiden kehitykseen. Koodin lisäksi kanssakäyminen avoimen lähdekoodin kehittäjäyhteisöjen kanssa voi olla yhteisön kokoontumisten, niiden tarvitseman verkkoinfrastruktuurin tai niitä tukevien säätiöiden ja yhdistyksien sponsorointia. Myös aktiivinen palautteen antaminen ohjelmistosta laadukkaiden bugiraporttien ja hyvin perusteltujen kehitysideoiden muodossa on osa kanssakäymistä. Avointa lähdekoodia voi siis hyödyntää sekä sitä käyttämällä että julkaisemalla.
Avoimen lähdekoodin lisensseissä, kuten avoimen datankin lisensseissä, on selkeys erittäin tärkeää, koska se laskee kynnystä käyttää koodia. Copyleft-ehto lisenssissä on kuitenkin monelle niin pelottava, että myöskään muita avoimen lähdekoodin lisenssejä ei uskalleta käyttää. Copyleft-ehto tarkoittaa avoimen lähdekoodin lisenssissä olevaa ehtoa, jonka tarkoitus on estää koodin levittäminen tai sen muuttaminen ilman että ohjelmistoon tehtyjä muutoksia voi arvioida ja jatkokehittää. Lisenssit ovat kuitenkin avoimen lähdekoodin yhteisöjen kulttuurissa olennaisia tekijöitä, joten myös copyleft-lisenssien kanssa on voitava elää.
Tein diplomityöni OSSLI-projektissa, jossa tutkittiin juuri avoimen lähdekoodien lisenssien ehtojen vaikutuksien hallintaa. Tutkimuksessa nousi esille, että copyleft-lisenssit mahdollistavat erilaiset liiketoimintamallit kuin niin sanotut akateemiset avoimen lähdekoodin lisenssit, joissa copyleft-ehtoa ei ole. Koska copyleft- ja akateemisilla lisensseillä on eri käyttötarkoitukset, ei niitä voi pitää kilpailijoina toisilleen. Käyttötarkoitus ja sen mukanaan tuoma yhteisö määrittävät, minkälainen lisenssi on sopiva projektiin.
Akateemiset lisenssit ovat joustavampia ja helpompia lukea, joten monet uudet projektit aloitetaan näillä lisensseillä. Skriptikielillä, joita ei käännetä binääriksi tai tavukoodiksi ennen ajoa, käytetään usein akateemisia lisenssejä, koska koodiin tehtyjen muokkausten piilottaminen on mahdotonta, jollei ohjelmistoa tarjota verkkopalveluna. Esimerkiksi selaimessa ajettavat JavaScript-kirjastot julkaistaan yleensä akateemisilla lisensseillä, koska ne on pakko jaella suoraan selaimeen muodossa, jossa lähdekoodia pääse tarkastelemaan. Tällä hetkellä JavaScriptin käyttö kehittyy erittäin nopeasti, joten uusia kirjastoja akateemisilla lisensseillä julkaistaan paljon. Yliopistoissa tuotetut kokeellisemmat ohjelmistot voivat mahdollistaa uutta liiketoimintaa paremmin akateemisilla lisensseillä, koska ne sopivat useampiin liiketoimintamalleihin.
Linux- ja palvelinohjelmistot taas suosivat GPL- ja LGPL-lisenssejä, joissa on copyleft-ehto, kun taas kokonaiset verkkopalvelut julkaistaan usein AGPL-lisenssillä, joka kuuluu samaan copyleft-perheeseen. Jos haluaa kehittää Linuxin perustuvia kirjastoja ja sovelluksia, saa todennäköisemmin houkuteltua ulkopuolisia kehittäjiä mukaan käyttämällä GPL-perheen lisenssejä, joita Linuxissakin käytetään. Unixeissa taas kulttuuriin kuuluvat akateemisiin lisensseihin kuuluvat BSD-lisenssit. AGPL taas on suosittu verkkopalveluiden lisensoinnissa varsinkin, jos kehittäjä haluaa myös myydä palvelua. Tällöin kilpailijat eivät voi suoraan jatkokehittää uutta toiminnallisuutta palvelun päälle julkaisematta lähdekoodia myös alkuperäisen lisensoijan käyttöön ja näin saada epäreiluksi koettu kilpailuetua. Eri lisenssien sekä niiden ehtojen vaikutukset avoimen lähdekoodin ohjelman kykyyn houkutella jatkokehittäjiä ja loppukäyttäjiä on laaja tutkimuskysymys, johon ei ole vielä saatu vastausta. Siitä voidaan johtaa myös kysymyksiä lisenssiehtojen vaikutuksiin liiketoimintaympäristön tasolla, eli esimerkiksi kilpailijoiden kykyyn hyödyntää koodia tai liiketoimintaympäristön kokonaiskannattavuuteen.
Puhuttaessa julkishallinnon järjestelmistä julkkishallinnon liiketoiminalliset tavoitteet sopivat hyvin yhteen copyleft-lisenssien kanssa. Vastaavaa palvelua tarjoavat kilpailijat sijaitsevat toisessa kunnassa tai maassa, joten ohjelmiston toiminnallisuus ei ole salaisuus, vaan motiivi pitää huolta, että myös muiden tekemä jatkokehitys tulee alkuperäisen julkaisijan käyttöön. Käyttäjät voivat myös auditoida koodin varmistuen näin sen toiminnan oikeellisuudesta ja oikeudenmukaisuudesta
Copyleft-ehto voi estää joidenkin liiketoimintamallien lisäksi myös integroinnin joidenkin avoimen lähdekoodin komponenttien kanssa lisenssien ehtojen ristiriidan vuoksi. Näiden ongelmien hallitsemiseen käytettyjä menetelmiä on esitelty diplomityössäni. Lisenssien yhteensopivuusongelmia voidaan ehkäistä seuraamalla aktiivisesti avoimen lähdekoodin käyttöä, olemalla aktiivisesti yhteydessä kehittäjäyhteisöön ja käyttämällä ohjelmistoarkkitehtuuritason ratkaisuja. Nämä ratkaisut perustavat lisenssien ehtojen ymmärtämiseen, jota voidaan edistää muun muassa yhteistyöllä avoimen lähdekoodin yhteisöjen kanssa sekä mallintamalla käytettyjä lisenssejä. Onkin tärkeä pystyä hahmottamaan, mitkä avoimen lähdekodin lisenssin myöntämät oikeudet riippuvat mistäkin ehdoista, ja missä käyttötarkoituksissa nämä ehdot pätevät. Ohjelmistoteknisen ja lakiteknisen osaamisen lisäksi myös avoimen lähdekoodin yhteisöjen ymmärtäminen on tarpeen lisenssiongelmien ratkaisemiseksi.
Avoimen lähdekoodin yhteisöjen sisäiset dialogit siitä, ovatko akateemiset- vai copyleft-lisenssit avoimempia, ovat ideologisia. Myös julkisella rahalla tuotettujen ohjelmistojen lisenssi on tällöin ideologinen kysymys, joka kuuluu oikeastaan ohjelmistosta maksavalle asiakkaalle eikä koodaajalle. Mikään ei kuitenkaan estä tekijänoikeuksien haltijaa julkiasemasta lähdekoodia useilla eri lisensseillä tai lisensoimalla eri osia koodista eri lisensseillä. Asiansa osaava ohjelmistokehittäjä voi kuitenkin tukea asiakasta päätöksenteossa sekä ottamalla huomioon tarvittavien komponenttien lisenssit että ymmärtämällä tuotettavan ohjelmiston liiketoimintatavoitteet.
Yleisimpiä avoimen lähdekoodin lisenssejä esitelty alla:
| Lyhenne | Nimi | Kuvaus |
| GPL | GNU General Public License | Vahva copyleft-lisenssi, jolla lisensoidun koodin muokkaus tai levittäminen vaatii yhteensopivan avoimen lisenssin käytön. |
| LGPL | GNU Library General Public License tai GNU ”Lesser” General Public License | Copyleft-lisenssi, joka sallii dynaamisen linkittämisen sillä lisensoituihin kirjastoihin, myös epäyhteensopivilla lisensseillä lisensoiduilla komponenteilla. |
| AGPL | Affero GNU General Public License | Copyleft-lisenssi, joka vaatii myös yhteensopivan lisenssin käytön, jos sillä lisensoitua koodia käytetään verkkopalvelussa. |
| APL | Apache Public Licence | Akateeminen lisenssi, jonka copyleft-ehto astuu voimaan vain, jos ohjelmisto julkaistaan samaan tarkoitukseen kuin alkuperäinen. Osallistuminen ohjelmistopatenttioikeudenkäyntiin saattaa mitätöidä lisenssin. |
| MIT | The MIT License | Yksinkertainen akateeminen lisenssi. |
| BSD | Berkley Software Distribution License | Yksinkertainen akateeminen lisenssi, josta on monta eri versiota käytössä. Vanhemmat versiot sisältävät vaatimukset tekijöiden nimien julkaisusta, mikä aiheuttaa ongelmia. |
