I IT-gruk 7/2022 adresserte vi enkelte utfordringer med åpne kildekode-lisenser. I dag ser vi fremover og på hvordan slike utfordringer kan møtes gjennom etablering av retningslinjer for bruk av åpen kildekode. På denne måten kan virksomheter redusere sin kommersielle, juridiske og/eller tekniske risiko. Dette vil gjelde både når de utvikler eller tilbyr programvare, eller ved kjøp eller salg av programvare og dets selskap der verdier ligger i programvare.
Formålet med IT-grukene om åpen kildekode har ikke vært å fraråde bruk av programvare med åpen kildekode, heretter forkortet til OSS (Open Source Software). Det må gjøres konkrete vurderinger knyttet til den enkelte OSS’ verdi for totaliteten av en IT-løsning, hvor også bruk av lisensiert proprietær programvare vil kunne innebære en risiko. Tid, time-to-market eller kvalitet vil være andre parametere som kan tale for bruk av OSS. Derimot er formålet å oppfordre til større bevissthet ved bruk av OSS i en programvare. Det er spesielt bevissthet om hvilken type OSS-lisens som ligger grunn for den enkelte programvare og deres begrensninger ved distribusjon og salg.
I forrige IT-gruk (7/2022) så vi på enkelte overordnede forskjeller mellom OSS-lisenser av typen permissive-lisenser på en side, og de som kan kalles copyleft-lisenser på den andre. Der permissive-lisenser gir mer tillatelse til å distribuere OSS uten å måtte dele avledet kildekode på samme vilkår som den opprinnelige OSS-lisensen, mens det for copyleft-lisenser ofte kreves at all videredistribusjon skjer på samme lisensvilkår som den opprinnelige OSS-koden. Det siste medfører også krav om å dele kildekode og representerer en kommersiell risiko. Det er likevel viktig å presisere at dette er en meget forenklet tilnærming da dette vanligvis er komplekse lisensvilkår som må leses i detalj for å forstå konsekvensen av hver enkelt lisenstype.
Ved siden av å forstå innholdet av den enkelte lisens tidlig nok i et prosjekt, vil en virksomhet ofte nyte godt av klare retningslinjer for bruk og håndtering av OSS. En slik retningslinje (her kalt OSS-policy), må også tilpasses den enkelte virksomhet og dennes behov i forhold til eksempelvis type lisenser som kan aksepteres i virksomhetens IT-løsning. En OSS-policy vil kunne understøtte:
- Enhetlige beslutninger. En god retningslinje bør tydeliggjøre virksomhetens strategi for bruk av OSS, som kan bidra til enhetlig bruk i hele organisasjonen.
- Informative beslutninger. Retningslinjen kan også bidra til at virksomheten innehar tilstrekkelig kompetanse til å ta informative og rasjonelle beslutninger.
- Effektive og strukturerte prosesser. Gjennom en god OSS-policy vil det kunne etableres en effektiv og strukturert prosess for hvordan OSS effektiv kan benyttes. Dermed unngår virksomheten å «finne-opp-hjulet-på-nytt».
- Oversikt og kompetanseoverføring. Ved en strukturert tilnærming så vil en OSS-policy kunne bidra til at virksomheten har oversikt over bruk og erfaring med konkrete OSS-lisenser og programvare, samt at denne kunnskapen kan gjenbrukes.
- Ved kjøp av et selskap som har struktur og oversikt over sin programvare og OSS-bruk, vil et selskap kunne få mer tillit i markedet og også bidra til mer effektive oppkjøpsprosesser.
- Minimere de juridiske, tekniske og forretningsmessige risikoene ved bruk av åpen kildekode-programvare. Helt sentralt er risikoen og bekymringen for å bli saksøkt for å bruke OSS og at dette dermed reduserer de tekniske og forretningsmessige mulighetene i virksomheten. En OSS-policy kan dermed bidra til å minimere disse risikoene, og skape forretningsmessig og teknisk trygghet.
Hva burde så inkluderes i en OSS-policy? Retningslinjen bør sikre forutsigbare prosesser og informasjon som virksomhetens medarbeidere har tilgang til. Elementer/regler som kan vurderes om:
- Tydelige formål og rasjonale for bruk av OSS for å sikre felles forståelse og kunnskap i virksomheten.
- Prosess for hvilke OSS-lisenser kan aksepteres uten godkjenning og hvilke som krever godkjenning.
- Eksempelvis, hvis det vurderes å implementere åpen kildekode, så skal virksomheten kun benytte permissive lisenser som er gjennomgått og akseptert for definerte områder eller produkter.
- Godkjenningsprosess av ikke forhåndsgodkjente OSS-lisenser.
- Forutsigbar og rask behandling av søknader for godkjenning.
- Klar ansvarsdeling, slik som ansvar for en godkjenningsprosess på tilstrekkelig høyt nivå. Eksempelvis at ingen kildekode skal gjøres tilgjengelig uten godkjennelse av produkteier.
- Beslutninger på selskapsnivå som en konsistente, og ved avvik sikre at avviket er begrunnet.
- Informative beslutninger ved at produkteier legger frem ønsket informasjon og vurderinger for en godkjenningskomite, slik som redegjørelse for tilhørende OSS-lisens og risikovurdering opp mot forretningsbehov. Andre muligheter:
- Estimering av alternativ-kostnad ved egenutvikling av ønsket programvare.
- Regler om at OSS ikke skal endres eller implementeres i et produkt uten godkjennelse.
- Deling eller videredistribusjon av programvare med OSS skal først skje når tilhørende lisens er vurdert opp mot retten til videredistribusjon.
- Godkjenningsprosessen må sikre tilgang til tilstrekkelig kompetente ressurser, inkludert juridisk kompetanse, slik at prosjekter ikke forsinkes mer enn nødvendig. Og slike ressurser må ha tilstrekkelig kapasitet for å kunne utføre oppgavene sine innen definert tid.
- Vurdere bruk av advokater tett på prosjekter hvor OSS skal benyttes for å kunne rådgi, og spesielt hvis det aksepteres bruk av restriktive OSS-lisenser under gitte tekniske forutsetninger.
- Dokumentert oversikt over all OSS og tilhørende lisenser som er akseptert, og oversikt over OSS som tidligere ikke er akseptert.
- Oppdatere oversikten for å sikre at den til enhver tid er korrekt.
- Synliggjør oversikten for hele virksomheten. Unngå dobbeltarbeid.
- Sikre at egen lisens på eget produkt er i samsvar med OSS-lisenser, slik som navngivelse.
Selv om en retningslinje forutsetter at all OSS gjennomgås og godkjennes gjennom en definert prosess, er det vanskelig å garantere at åpen kildekode aldri benyttes all den tid den enkelt og fritt kan lastes ned. Regler om regelmessig revisjon av eksisterende systemer og rapportering til ledelsen kan bidra til at retningslinjene etterleves.
Et annet element som kan vurdere er å etablere retningslinjer for håndtering av fusjoner og oppkjøp med tilhørende programvare. Virksomheter som glemmer å undersøke om selskapet de ønsker å kjøpe har programvare som er basert på OSS, hvordan den benyttes og hvilken kommersiell risiko det betyr for det de sitter igjen med, kan få seg en overraskelse. Derfor kan retningslinjer, sjekklister og forhåndskontroll kan være et verdiøkende bidrag for å redusere risiko, samt kunne sikre en best mulig prisevaluering. Teknisk sett finnes det også eksempler på programvare som kan benyttes for å identifisere OSS som er benyttet i en applikasjon.
Formålet med IT-grukene om åpen kildekode har ikke vært å fraråde bruk av programvare med åpen kildekode, heretter forkortet til OSS (Open Source Software). Det må gjøres konkrete vurderinger knyttet til den enkelte OSS’ verdi for totaliteten av en IT-løsning, hvor også bruk av lisensiert proprietær programvare vil kunne innebære en risiko. Tid, time-to-market eller kvalitet vil være andre parametere som kan tale for bruk av OSS. Derimot er formålet å oppfordre til større bevissthet ved bruk av OSS i en programvare. Det er spesielt bevissthet om hvilken type OSS-lisens som ligger grunn for den enkelte programvare og deres begrensninger ved distribusjon og salg.
I forrige IT-gruk (7/2022) så vi på enkelte overordnede forskjeller mellom OSS-lisenser av typen permissive-lisenser på en side, og de som kan kalles copyleft-lisenser på den andre. Der permissive-lisenser gir mer tillatelse til å distribuere OSS uten å måtte dele avledet kildekode på samme vilkår som den opprinnelige OSS-lisensen, mens det for copyleft-lisenser ofte kreves at all videredistribusjon skjer på samme lisensvilkår som den opprinnelige OSS-koden. Det siste medfører også krav om å dele kildekode og representerer en kommersiell risiko. Det er likevel viktig å presisere at dette er en meget forenklet tilnærming da dette vanligvis er komplekse lisensvilkår som må leses i detalj for å forstå konsekvensen av hver enkelt lisenstype.
Ved siden av å forstå innholdet av den enkelte lisens tidlig nok i et prosjekt, vil en virksomhet ofte nyte godt av klare retningslinjer for bruk og håndtering av OSS. En slik retningslinje (her kalt OSS-policy), må også tilpasses den enkelte virksomhet og dennes behov i forhold til eksempelvis type lisenser som kan aksepteres i virksomhetens IT-løsning. En OSS-policy vil kunne understøtte:
- Enhetlige beslutninger. En god retningslinje bør tydeliggjøre virksomhetens strategi for bruk av OSS, som kan bidra til enhetlig bruk i hele organisasjonen.
- Informative beslutninger. Retningslinjen kan også bidra til at virksomheten innehar tilstrekkelig kompetanse til å ta informative og rasjonelle beslutninger.
- Effektive og strukturerte prosesser. Gjennom en god OSS-policy vil det kunne etableres en effektiv og strukturert prosess for hvordan OSS effektiv kan benyttes. Dermed unngår virksomheten å «finne-opp-hjulet-på-nytt».
- Oversikt og kompetanseoverføring. Ved en strukturert tilnærming så vil en OSS-policy kunne bidra til at virksomheten har oversikt over bruk og erfaring med konkrete OSS-lisenser og programvare, samt at denne kunnskapen kan gjenbrukes.
- Ved kjøp av et selskap som har struktur og oversikt over sin programvare og OSS-bruk, vil et selskap kunne få mer tillit i markedet og også bidra til mer effektive oppkjøpsprosesser.
- Minimere de juridiske, tekniske og forretningsmessige risikoene ved bruk av åpen kildekode-programvare. Helt sentralt er risikoen og bekymringen for å bli saksøkt for å bruke OSS og at dette dermed reduserer de tekniske og forretningsmessige mulighetene i virksomheten. En OSS-policy kan dermed bidra til å minimere disse risikoene, og skape forretningsmessig og teknisk trygghet.
Hva burde så inkluderes i en OSS-policy? Retningslinjen bør sikre forutsigbare prosesser og informasjon som virksomhetens medarbeidere har tilgang til. Elementer/regler som kan vurderes om:
- Tydelige formål og rasjonale for bruk av OSS for å sikre felles forståelse og kunnskap i virksomheten.
- Prosess for hvilke OSS-lisenser kan aksepteres uten godkjenning og hvilke som krever godkjenning.
- Eksempelvis, hvis det vurderes å implementere åpen kildekode, så skal virksomheten kun benytte permissive lisenser som er gjennomgått og akseptert for definerte områder eller produkter.
- Godkjenningsprosess av ikke forhåndsgodkjente OSS-lisenser.
- Forutsigbar og rask behandling av søknader for godkjenning.
- Klar ansvarsdeling, slik som ansvar for en godkjenningsprosess på tilstrekkelig høyt nivå. Eksempelvis at ingen kildekode skal gjøres tilgjengelig uten godkjennelse av produkteier.
- Beslutninger på selskapsnivå som en konsistente, og ved avvik sikre at avviket er begrunnet.
- Informative beslutninger ved at produkteier legger frem ønsket informasjon og vurderinger for en godkjenningskomite, slik som redegjørelse for tilhørende OSS-lisens og risikovurdering opp mot forretningsbehov. Andre muligheter:
- Estimering av alternativ-kostnad ved egenutvikling av ønsket programvare.
- Regler om at OSS ikke skal endres eller implementeres i et produkt uten godkjennelse.
- Deling eller videredistribusjon av programvare med OSS skal først skje når tilhørende lisens er vurdert opp mot retten til videredistribusjon.
- Godkjenningsprosessen må sikre tilgang til tilstrekkelig kompetente ressurser, inkludert juridisk kompetanse, slik at prosjekter ikke forsinkes mer enn nødvendig. Og slike ressurser må ha tilstrekkelig kapasitet for å kunne utføre oppgavene sine innen definert tid.
- Vurdere bruk av advokater tett på prosjekter hvor OSS skal benyttes for å kunne rådgi, og spesielt hvis det aksepteres bruk av restriktive OSS-lisenser under gitte tekniske forutsetninger.
- Dokumentert oversikt over all OSS og tilhørende lisenser som er akseptert, og oversikt over OSS som tidligere ikke er akseptert.
- Oppdatere oversikten for å sikre at den til enhver tid er korrekt.
- Synliggjør oversikten for hele virksomheten. Unngå dobbeltarbeid.
- Sikre at egen lisens på eget produkt er i samsvar med OSS-lisenser, slik som navngivelse.
Selv om en retningslinje forutsetter at all OSS gjennomgås og godkjennes gjennom en definert prosess, er det vanskelig å garantere at åpen kildekode aldri benyttes all den tid den enkelt og fritt kan lastes ned. Regler om regelmessig revisjon av eksisterende systemer og rapportering til ledelsen kan bidra til at retningslinjene etterleves.
Et annet element som kan vurdere er å etablere retningslinjer for håndtering av fusjoner og oppkjøp med tilhørende programvare. Virksomheter som glemmer å undersøke om selskapet de ønsker å kjøpe har programvare som er basert på OSS, hvordan den benyttes og hvilken kommersiell risiko det betyr for det de sitter igjen med, kan få seg en overraskelse. Derfor kan retningslinjer, sjekklister og forhåndskontroll kan være et verdiøkende bidrag for å redusere risiko, samt kunne sikre en best mulig prisevaluering. Teknisk sett finnes det også eksempler på programvare som kan benyttes for å identifisere OSS som er benyttet i en applikasjon.
Kommentarer
Legg inn en kommentar