Det ikke sjelden vi erfarer at ved kjøp eller salg av en IT-løsning så inneholder kildekoden til IT-løsningen en andel kode som er lisensiert som såkalt åpen kildekode. Andelen kan både være større eller mindre, men kildekoden representerer oftest den sentrale verdien av en IT-løsningen og den kjøperen ønsker tilgang til. Det overraskende er i mange tilfeller hvor lite struktur eller retningslinjer som ligger rundt et selskaps’ valg ved bruk av åpen kildekode.
Her er en forenklet innføring og tanker om åpen kildekode:
- Programvare og kildekoden
Bak en IT-løsning ligger et dataprogram eller applikasjon. Dette er et sett med definerte instruksjoner til en datamaskin som denne skal utføre. Kildekoden er det vi kaller en menneskelesbar kode som skrives på et programmeringsspråk og lagres gjerne i form av en tekstfil. For å kjøre kildekoden på en datamaskin må kildekoden gjøres om til en maskinkode. Det er her vi kjenner igjen bruken av tallene 1 og 0.
Det finnes mange programmeringsspråk, eksempelvis Cobol, Pascal, C+, Python og Java. Vi kan trekke en linje fra i dag og tilbake til 1950-tallet i Vest-Europa og USA for de fleste av disse programmeringsspråkene. Ved bruk av programmeringsspråk vil utviklere kunne lage dataprogrammene som dermed skulle kunne kjøre på flere typer av datidens stormaskiner. Ofte var det kun store selskaper som hadde kapasitet til å utvikle og bruke slik programvare, og dermed var det et behov om å verne om disse verdiene.
Kildekoden til et datamaskinprogram hadde (og har fortsatt) stor verdi som en eier vanligvis ikke ønsket å dele med omverden. Programmer er da også beskyttet som et åndsverk, gitt at det er resultatet av kreativ og skapende innsats med et originalt uttrykk, men det vil også være en del av et selskaps’ forretningshemmeligheter. Når selskaper utvikler egne programmer, ikke deler dem og beskytter de slik at utenforstående kun kan bruke det ved løse en lisens, så kaller vi det oftest proprietær programvare. IT-industrien har historisk sett brukt forretningsmodeller hvor kunder får tilgang til programvare mot å betale et lisensvederlag basert på lisensvilkårene. Vilkårene har ofte vært lange og byrdefulle for brukeren.
Motsatsen til proprietær programvare er programvare hvor kildekoden deles med omverden med et ønske om å bidra til felles utvikling og forbedring av tilgjengelig programvare. Fri deling kan gjøres på flere måter, men den varianten vi her fokuserer på er åpen kildekode («open source») med tilhørende standardlisenser.
En åpen kildekode-lisens tillater vanligvis en bruker (på gitte vilkår) kan fritt bruke, endre eller dele (med eller uten endringer) kildekoden og tilhørende dokumentasjon og design. Dermed kan sluttbrukere, som kommersielle selskaper, kan bruke, få tilgang til og endre kildekoden. Et prinsipp bak åpen kildekode er at rettinger og forbedringer skal føres tilbake til fellesskapet og være tilgjengelige for alle brukere. Tanken er blant annet at programmer distribuert som åpen kildekode raskere oppnår en høy kvalitet ved at kildekoden er tilgjengelig for gjennomgang av likesinnede («peer-review»), og til gode for alle.
Programvare basert på åpen kildekode er stort sett tilgjengelig gratis, og det finnes mange prosjekter basert på åpen kildekode med en kommersiell modell og stor verdi. Åpen kildekode-lisenser kan likevel ha noen begrensninger, slik som krav om å bli navngitt eller krav om at ved videreformidling av programvaren så må det skje under samme lisensvilkår. Og det er her starten på enkelte problemer kan oppstå.
- Forskjellige typer åpen kildekode
Systemet med åpen kildekode fungerer ved at den enkelte kildekode lisensieres basert på en åpen kildekode-lisens. Denne gir brukerne både rettigheter og plikter. I dag finnes det mange forskjellige typer lisenser for åpen kildekode, og blant de mest kjente (og brukte) er Apache 2.0, MIT, BSD, GNU General Public License og Mozilla. Noen lisenser godkjennes av Open Source Initiative («OSI») basert på deres definisjoner, kjent som Open Source Definition («OSD»).
Lisensene er forskjellige og med mange små variasjoner, men det kan trekkes et vesentlig skille mellom de vi på en side kaller (i) «permissive»-lisenser, og på den andre siden (i) «copyleft»-lisenser. Avhengig av hvilken type åpen kildekode-lisens som benyttes, så kan det kan ha betydning for hvordan en IT-løsning kan bygges og hvordan den kan tilbys i markedet uten at det medfører et brudd på lisensen. Konsekvensen ved brudd kan da være eksempelvis plikt til å gi innsyn i kildekoden som er utviklet, tap av rett til å bruke kildekoden eller erstatningskrav.
Copyleft-lisenser krever normalt at både den originale åpne kildekoden og den avledede (videreutviklede) programvaren fra den åpne kildekoden er gjort tilgjengelig under samme copyleft‑lisens eller tilsvarende rettigheter. Det vil si at alle brukerne gis nøyaktig samme rettigheter og plikter for det som videreutvikles uavhengig av hvem som brukte ressurser på utviklingen av den avledede programvaren. Mozilla og de fleste GPL (General Public License) er varianter av såkalte copyleft-lisenser. Noen lisenser definerer avledede verk som totaliteten av kildekoden hvor den åpne kildekoden er innarbeidet, men dette varierer og begrepsbruken kan ha betydning av hvor langt lisensen strekker seg og påvirker utformingen.
Permissive-lisenser gir rett til å bruke, kopiere, endre og distribuere kopier av den lisensierte åpne kildekode-komponenten med færre begrensninger, slik som rett til å bli navngitt og publisert med ansvarsbegrensninger. Kjente lisenser, som Apache, MIT og BSD, tillater derfor en bruker eller eier å gjøre mer tilpasninger med videredistribusjonen av kildekoden, inkludert å ikke dele videreutviklet kildekode med utenforstående. Dette medfører at løsninger med åpen kildekode basert på permissive-lisenser kan beskyttes mot innsyn og forretningsmodeller vernes. Det er ikke alle som mener at dette møter formålet med åpen kildekode.
I praksis kan det tenkes at en IT-løsning består av mange komponenter med forskjellige typer åpen kildekode-lisens. I slike tilfeller må det tas hensyn til at ikke alle lisenser fungerer godt sammen. Eksempelvis, så tillater generelt MIT lisensen at den bakes inn i en større løsning som er basert på GPL lisens, mens det motsatt ikke tillates under GPL lisens.
Dette medfører begrensninger i hvordan en løsning kan kommersialiseres og være en risiko for en ny eier som kanskje må slutte å bruke en løsning før en del er tatt ut og erstattet. Det koster både i tid og midler. En annen begrensning er knyttet til distribusjonen av IT-løsningen. For GPL-lisenser vil eksempelvis en SaaS-tjeneste normalt ikke anses som distribusjon da ingen kode er overført til brukeren, men dette unntaket for SaaS-tjenester gjelder kun enkelte versjoner av GPL lisensen. Lisenser som distribueres ved at koden gjøres tilgjengelig for brukeren og lastes ned av brukeren vil oftest anses som distribusjon og utløse plikter etter GPL-lisensen. Det er derfor viktig å gjennomgå den enkelte åpne kildekode-lisensen som er tenkt brukt og se om denne representerer en utfordring for virksomhetens forretningsmodell.
- Hva nå?
Hvordan kan slike utfordringer møtes? Formålet med dette IT-gruk’et er ikke å fraråde bruk av åpen kildekode. I mange tilfeller representerer det en mulighet for raskere å komme frem til et resultat. Derimot mener vi at de fleste virksomheter burde ha et mer aktivt forhold til hvilke lisenser som benyttes og hva det betyr for den enkelte virksomhet. Dette kan gjøres gjennom å etablere en «Open Source Policy» og samtidig ha en oppdatert oversikt over den kildekoden som benyttes med tilhørende lisenser. Denne prosedyren vil kunne gi verdi ved eksempelvis (i) å synliggjøre hvordan åpen kildekode skal bruke, (ii) hvilke lisenser som enten er akseptable, eller (iii) hvilke lisenser som trenger ytterligere juridisk gjennomgang før de introduseres i IT-løsningen, (iv) sikre en informert beslutning ved slike valg og ikke minst (v) sikre at den valgte åpne kildekode understøtter virksomhetens forretningsmodell.
I neste IT-gruk ser vi nærmere på hva som kan være aktuelt å ta med i en «Open Source Policy». Frem til da; god uke!
Kommentarer
Legg inn en kommentar