Åpen kildekode betyr mer enn at du kan se koden

Ti kriterier, ikke ett

Åpen kildekode dukker opp overalt i norsk digitaliseringsspråk. Altinn kaller seg åpen kildekode, NAV kaller seg åpen kildekode, og en kommunes nye saksbehandlingssystem skal visstnok bli det også. Men hva skal egentlig være oppfylt for at merkelappen stemmer? At koden ligger synlig på nett, holder ikke alene.

Organisasjonen som definerte begrepet, Open Source Initiative, sier det rett ut i sin egen definisjon: «Open source doesn't just mean access to the source code. The distribution terms of open source software must comply with the following criteria.» Deretter følger ti kriterier en lisens må oppfylle. To av dem forklarer mye av forskjellen mellom «åpen» og «bare synlig»: lisensen kan verken kreve royalty eller hindre at noen selger eller gir bort programvaren videre, og kildekoden må være i den formen en programmerer faktisk ville brukt for å endre programmet – ikke en bevisst tilslørt eller mellomliggende versjon.

Åpen kildekode er altså en juridisk konstruksjon, en lisens, ikke en beskrivelse av hvor godt kommentert koden er.

To lisenser, to ulike logikker

De fleste norske eksemplene lener seg på én av to hovedtyper.

MIT-lisensen er den enkleste. Den gir «permission ... to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software», nesten uten begrensning. Den eneste plikten er å la opphavsrettsnotisen bli med videre: «The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.» MIT-kode kan havne i et helt lukket, kommersielt produkt uten at noen bryter noe.

GPL er strengere, med vilje. Free Software Foundations GPLv3 krever at hele det avledede verket lisensieres videre under samme vilkår: «You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy.» Endrer du GPL-kode og distribuerer resultatet, må kildekoden til endringen følge med. Effekten er at GPL-kode holder seg åpen nedover i kjeden, mens MIT-kode ikke har noen slik forpliktelse og sprer seg friere – også inn i lukket programvare.

Anbefalt, ikke påbudt, i det offentlige

Digdir har tatt stilling til spørsmålet i sine digitaliseringsprinsipper. Under prinsipp 6 , om løsninger som støtter samhandling, står det: «Vurder bruk av åpen kildekode fremfor lukkede, kommersielle løsninger.» Det er formulert som en anbefaling å vurdere, ikke et krav – det finnes ingen bestemmelse i denne kilden som pålegger offentlige virksomheter å velge åpen kildekode i sine anskaffelser.

NAV har likevel gått lenger enn anbefalingen på egen hånd. Retningslinjene for åpen kildekode i NAV er selv offentlige, og de er konkrete: «Alle repoer må ha MIT-lisensen i en egen LICENSE-fil.» Begrunnelsen er ikke først og fremst gjenbruk, understreker retningslinjene selv: «Motivasjonen er da ikke hovedsakelig gjenbruk, selv om det selvsagt er en heldig bieffekt.» Poenget er et annet: «Offentlig finansierte løsninger bør være offentlig tilgjengelig.» På GitHub-organisasjonen til NAV IT ligger nå over 3 000 offentlig tilgjengelige kodelagre.

Altinn har valgt samme åpenhet for sin egen utviklingsplattform, Altinn Studio, og begrunner den slik i sin egen sikkerhetsdokumentasjon: «Open source allows others to analyze the code for vulnerabilities and quality.» Digdir, som drifter Altinn, sier det enda tydeligere: de vektlegger «openness and trust that open source provides rather than the likelihood of malicious exploitation». Det er en bevisst avveining, ikke en selvfølge – et konseptuelt standpunkt om åpenhet, ikke en oppskrift på hva noen faktisk finner.

Sjekk selv

Neste gang en offentlig løsning kaller seg åpen kildekode, er det ett konkret sted å se etter beviset: en LICENSE-fil i kodelageret, og hvilken av de to logikkene den følger. Står det MIT, kan koden i prinsippet havne hvor som helst. Står det GPL, er den forpliktet til å forbli åpen der den går videre. Begge deler er åpen kildekode. De er bare ikke det samme løftet.