Når vi først jobber med å utvikle en fri programvare Noark 5 kjerne så burde vi tenke felleskomponent tankegangen. Hvis vi er enig om det, så er neste spørsmål “Hvilken lisens skal vi bruke?”. Dette har jeg sett nærmere på og det er ingen enkel svar. Men la oss begynne med å se nærmere på hva fri programvare er.
Fri programvare er et spørsmål om brukernes frihet til å kjøre, kopiere, distribuere, studere, endre og forbedre programvaren. Mer presist, betyr det at programmets brukere har de fire grunnleggende frihetene:
- Friheten til å kjøre programmet, uansett formål (frihet 0)
- Friheten til å studere hvordan programmet fungerer, og endre den slik at den gjør hva du vil. Tilgang til kildekoden er en forutsetning for dette
- Friheten til redistribuere kopier så du kan hjelpe andre
- Friheten til å distribuere kopier av dine endrede versjoner til andre. Ved å gjøre dette kan du la andre dra nytte av endringene. Tilgang til kildekoden er en forutsetning for dette
Det er kun dette det handler om. Det står ingenting om at deg skal være gratis i disse fire prinsippene og noen av de negative holdningene til fri programvare mener jeg er en misforståelse som bygger på tolkningen av det engelske ordet “free” som gir assosiasjoner med gratis mens på norsk så skiller vi tydelig mellom gratis og fri. Noen er negative til fri programvare fordi det ødelegger for proprietære leverandører, det ødelegger markedet forteller de. Tvert imot så synes jeg at fri programvare skaper en rettferdighet i markedet gjennom å øke konkurranse nivået og hindre at noen danner et monopol situasjon. Dette kan gi brukeren den mest konkurransedyktige løsningen.
Det finnes et mangfold av fri programvare lisenser og til å være helt ærlig så kan det være et mareritt å holde orden på hva som er hva og hvordan det kan brukes. Ironisk nok så kan dette mangfoldet av lisenser også hemme bruken av fri programvare da det ikke nødvendigvis er fritt fram å blande kode med forskjellige lisenser.
Den mest kjente fri programvare lisensen er GPL som ofte blir omtalt som “viral”. Alt som blir kompilert mot GPL blir GPL og det er ikke mulig å bryte denne avhengigheten (hvis ikke original forfatteren ønsker det). Jeg ble overrasket da en av masters studentene fra forrige semester var ekstremt negativ til GPL. Koden hans skulle kun utgies med BSD lisens. Dette mente han ga han mest frihet og størst mulighet for at andre tok i bruk koden hans. Og han har faktisk rett. Sånn som koden has er lisensert nå, så kan hvem som helst bruke det. Hadde han valgt GPL så hadde mange potensiale brukere av koden hans latt være å bruke det.
Hvis vi ser nærmere på disse lisensene så kan vi dele de opp i grupper som vist i Figur 1. (kommer opprinnelig fra: http://www.dwheeler.com/essays/floss-license-slide.html) På venstre side ser vi de som gir liten eller ingen beskyttelse til kode. Når vi snakker om beskyttelse så mener vi at koden må forbli offentlig. Disse blir typisk bruk til å frigøre koden på en måte som beskytter forfatteren fra å bli saksøkt for en eller annen feil som oppstår under kjøring. Eksempler på disse er BSD, MIT lisenser. På den andre side ser vi GPL lisensen og et tillegg som heter AGPL som tar høyde for programvare som blir brukt i nettsyken. I midten har vi ett sett med lisenser som gir en svak beskyttelse. LGPL er den mest brukte lisensen her. Det som blir interesant er hvordan disse lisensene introduserer problemer hvis du øsnker å kombinere kildekode med forskjellige lisenser. Har du et prosjekt der du inkluderer en kildekode fil som har GPL lisensen så vil hele prosjektet ditt måtte distribueres med en GPL lisens. Hvis du er en leverandør av proprietær programvare så vil du ikke kunne leve med den betingelsen og kan ikke bruke GPL kode. Men som proprietære leverandør så kan du lett integrere BSD/MIT kode i prosjektet ditt.
Figur 1. Lisens kompatibilitet
Vi mener at hvis det er ønskelig med interoperatibelt, konkurranse og videreutvikling av programvare på toppen av Noark 5 friprog felleskomponent så må lisensen være slik at den kan brukes av både proprietære og åpen kilde kode prosjekter. LGPL kan brukes til å lage en referanse implementasjon som alle må forholde seg til. Betingelsene i lisensen vil tvinge leverandøren til å vise endringene de gjorde til kjernen men ikke sin proprietær programvare på toppen av kjernen. Det er ingen hinder for at et GPL lisensert prosjekt kode kan bruke en LGPL kjerne men lisensen vil tvinge hele prosjektet under GPL. Jeg ser ingen problem med det. Hvis man valgte BSD eller MIT type lisenser så kunne leverandørene endre kjernen slik de selv ønsker og dermed hindre interoperabilitet.
Når det gjelder valg av lisens for statlige felleskomponenter så er det naturlig at det vil variere fra prosjekt til prosjekt og hva kjøperen ønsker med koden. For Noark 5 kjerne så mener vi det må være LGPL.
