- Vi er vant til å høre at fri kode og proffe miljøer står i konflikt

Men sånn er det ikke lenger, skriver Peter N. M. Hansteen, i en lang guide til profesjonell bruk av fri programvare og åpen kode.

Peter N. M. Hansteen er styreleder i NUUG og "Senior Technical Specialist" i Tietoevry Create Cloud Norway. 📸: Privat
Peter N. M. Hansteen er styreleder i NUUG og "Senior Technical Specialist" i Tietoevry Create Cloud Norway. 📸: Privat Vis mer

Vi har vært vant til å høre at fri programvare og åpen kildekode og profesjonelle miljøer i store bedrifter står i grunnleggende konflikt og er vanskelige å kombinere.

Er det faktisk tilfelle, eller bør vi heller utforske hvordan bedrifter og fri programvare kan sameksistere på måter som er til fordel for begge?

Fri programvare og åpen kildekode mot bedrifter og forretningsdrift: Det var ille før

Både fri programvare med åpent tilgjengelig kildekode og IT-miljøer i store bedrifter har eksistert en god stund. Jeg er gammel nok til å huske den gang den mest utbredte oppfatningen var at det å åpent utveksle kildekode med andre var noe amatører drev med, eller til nød i akademiske elfenbenstårn.

Omkvedet var at i profesjonell og forretningsorientert sammenheng var det nok bra å hente noe generell lærdom om prinsipper fra akademia, men at ordentlige produkter for profesjonell bruk måtte bare bli distribuert og solgt som binærform, mens kildekoden måtte holdes strengt nedlåst og hemmelig.

«Det var liten eller ingen mulighet for diskusjon. Bare det å ha en annen oppfatning var nærmest uhørt.»

Hvis du er litt yngre, husker du kanskje en periode da Windows NT er fremtiden var ansett som en evig sannhet og at de som levde av å kommentere og gi råd var ganske så sikre på at Unix og stormaskiner ville være helt utdødde om bare få år.

Når vi ser tilbake til sene 1980-tall og tidlig nittitall er det nå vanskelig å forestille seg hvor klar og absolutt enigheten var akkurat på dette punktet i sentrale miljøer. Det var PC-arkitektur og noen andre teknologier som var noens forretningshemmeligheter som var det alle profesjonelle og definitivt også bedrifter skulle drive med fremover.

Det var liten eller ingen mulighet for diskusjon. Bare det å ha en annen oppfatning var nærmest uhørt.

Men så: Internett

Og så kom Internett. Det ikke så mange utenfor noen indre kretser var klar over, var at det som faktisk fikk Nettet til å fungere, var kode som kom direkte fra Berkeley Software Distribution. BSD Unix, ofte bare kalt BSD var et komplett operativsystem som var gjort tilgjengelig for offentligheten under en fri lisens, resultat av et nokså uformelt samarbeid mellom forskere og utviklere i både akademia og i bedrifter, som altså hadde utviklet noe nytt og bedre på grunnlag av Unix-kildekode

Da det amerikanske forsvarsdepartemenet ønsket seg nettverk som var pålitelig, utstyrsuavhengig, distribuert og selvkonfigurerende, gikk oppgaven med å levere referanseimplementasjonen for TCP/IP-stakken, basert på en strøm av spesifikasjoner som ble kalt forespørsler om kommentarer (Request for comments eller RFCer) til en internasjonal gruppe utviklere som ble koordinert av Computer Science Research Group ved University of Californias Berkeley-campus. Kort og godt kom Internett fra BSD, som takket være en avgjørelse i styrende organer for University of California var utgitt under fri lisens.

Denne TCP/IP-stakken fra BSD var del av alle systemer som kunne koble seg til Internett frem til rundt år to tusen. Da startet Linux-utviklere og senere Microsoft arbeid med sine egne, uavhengige implementasjoner. I alle fall var det da klart for utviklere at det var mulig lage åpen kildekode som kunne skalere opp til et industrielt og faktisk globalt nivå.

På grunn av noen historisk viktige tilfeldigheter, som i hovedsak skyldtes svikt i kommunikasjonen mellom forskjellige grupper av utviklere og forsterket av et ikke veldig godt fundert søksmål om BSD-koden, ble det Linux som ble det folk flest forbinder med både fri programvare generelt og renessansen for Unix-liknende systemer i markedet for servere som skulle kobles på Internett. Linux-distribusjonene hadde brukernivå-programvare i hovedsak fra GNU-prosjektet, i skjønn forening med en god del kode fra BSD.

På omtrent samme tid som Linux ble kjent, ble også BSD-koden allment tilgjengelig via prosjektene FreeBSD og NetBSD. Kort tid senere, midt på 1990-tallet, kom OpenBSD til, da en gruppe skilte seg ut fra NetBSD og arbeidet videre med koden separat. En mer detaljert fremstilling av dette kan du finne i en kronikkserie i tre deler på APNIC blog som starter med denne artikkelen. Mer om OpenBSD kan du finne i en annen tredelt serie på digi.no, med første del her.

Krigen mot Linux og den økende utbredelsen av frie verktøy

I løpet av 1990-årene og tidlig 2000-tall vokste utbredelsen av Internett i høyt tempo, og tjenestene av alle slag som kjørte på toppen ble utvidet i alle retninger. Denne økningen i utbredelse førte også med seg at bruk av frie unix-liknende systemer som Linux og BSDene, som kjørte fint på utstyr som var lett tilgjengelig overalt, også økte. Med økt utbredelse vokste det også frem en stadig større samling utviklerverktøy og programvare av alle slag, som ble tilgjengelig for helt nye kategorier av brukere.

Suksessen for fri og åpen programvare førte i sin tur til det som ble kalt Krigen mot Linux, som var en heller rabiat svertekampanje med nedrakking og tvilsomme påstander både i PR-kampanjer og søksmål, primært drevet av den da dominerende leverandøren av programvare til PC-kontorbruk sin ambisjon om å også få dominere server-markedet.

«I løpet av noen år ble det klart for stort sett alle i bransjen at de frie verktøyene var helt sentrale for utvikling.»

En av de mer bisarre sekvensene av søksmål mot Linux ble drevet via en påstått tredjepart, og er utførlig dokumentert på groklaw.net (Merk: webstedet tilbyr kun gammeldags http). Det er verd å merke seg at prosessen til slutt førte til at saksøker gikk konkurs.

I løpet av noen år ble det klart for stort sett alle i bransjen at de frie verktøyene var helt sentrale for utvikling, og de praktiske delene av det å være utvikler ledet i retning av stadig mer bruk av fri og åpen kildekode. I løpet av tiden krigen mot Linux varte, la firmaer som Apple, Cisco, Netscaler (som siden ble kjøpt opp av Citrix), Sun Microsystems (som i sin tur ble kjøpt opp av Oracle) betydelig innsats i å bruke fri programvare i sine produkter, hver på sin måte. Noen av dem innlemmet fri og åpen kildekode i sine produkter og arbeidsprosesser, noen gjorde sin egen kode tilgjengelig under fri og åpen lisens, mens andre baserte sine egne produkter på frie systemer i produkter som i sin tur bare ble tilgjengelig i utførbar, binær form. Det kan være verd å se nærmere på hver av disse tilnærmingene senere.

Hopp til i dag: Alle bruker...

Om vi så går raskt frem til tilstanden dag, så oppsummerte kolleger nylig med at i de større miljøene vi jobber i, blir...

  • ...programvare utviklet på Macer,
  • deployed til en sky et eller annet sted,
  • som etter all sannsynlighet kjører på Linux.

Og programvaren blir mest sannsynlig bygget med verktøy som er fri og åpen kildekode og trekker inn avhengigheter fra andre frie og åpne prosjekter, som gjerne blir gjort tilgjengelig via Github eller andre steder på internett som er tilgjengelig for allmenheten.

Programvaren din bruker nesten helt sikkert noe fri og åpen kode. Og selv om du ikke er utvikler selv, bruker du nokså sikkert frie og åpne verktøy som er integrert i operativsystemet eller applikasjoner og web-tjenester du bruker.

Om vi ser på klientsiden, kommer en stadig større del av volumet kommer fra smarttelefoner og nettbrett der markedsandelen for systemer basert på fri programvare (Android og IOS) ligger godt over 90 prosent. I et dokument vi skal komme litt tilbake til senere, anslår Nasjonal Sikkerhetsmyndighet (NSM) et sted mellom 90 og 98 prosent av programvare som er i bruk, i en eller annen grad er basert på eller har avhengigheter til fri og åpen programvare. Litt relevant statistikk kan en finne her, her og her. Eller for for de som har litt dårligere tid: Det anslås at det i dag finnes minst 3,1 milliarder Linux-baserte Android-telefoner i bruk. I tillegg har vi Apple, som har mye BSD i seg.

Det er også verd å merke seg at til og med den tidligere erkefienden av fri programvare, Microsoft, leverer det som i praksis er en nesten komplett Linux-distribusjon som et delsystem i sitt operativsystem. Det samme firmaet har også for vane å sende ikke ubetydelige beløp til organisasjoner som stiftelsen The OpenBSD Foundation, i tillegg til at de også bidrar aktivt til en rekke frie og åpne prosjekter. La oss heller ikke glemme at mye, kanskje det meste, av det som kjøres på Microsofts Azure-sky på den ene eller andre måten er basert på Linux.

Sikkerhet: Kvalitetssikre leveringskjedene, bruk retten til å reparere

Mens krigen mot Linux foregikk som verst, og til en viss grad fortsatt, har vi ofte fått høre at fri og åpen programvare enten aldri kan bli like sikker som bedriftseid, hemmelig programvare eller at fri og åpen programvare i utgangspunktet er mer sikker en lukket programvare siden "med nok øyne som ser, er alle programmeringsfeil lette å finne".

Begge disse påstandene er feil. Selv uten tilgang til kildekode er det mulig å teste kjørende programvare og se etter sårbarheter. Og for fri og åpen programvare er det helt avgjørende om øynene som ser tilhører noen som faktisk har den kompetansen som faktisk trengs for å finne og rette feil.

I løpet av de siste få årene har det vært en håndfull sikkerhetshendelser som førte til mye kommentarer fra de som lever av slikt, som dessverre i stor grad var dårlig fundert og i stor grad misvisende. La oss se på hvilken lærdom vi kan høste fra disse tilfellene:

#1: Hendelsen med Solarwinds og leveringskjeden, kjent som SUNBURST (2020)

En av de mest omtalte sikkerhetshendelsene i løpet av de siste få årene er samtidig en av de som oftest ikke blir forstått og tolket i samsvar med fakta. Selve hendelsen bestod i at angripere som ikke har blitt offentlig identifisert hadde klart å få tilgang til datamaskinene der et av de mest utbredte produktene for nettverksadministrasjon ble bygget og pakket for distribusjon til brukere.

SANS institute har laget en ganske grundig rapport om hendelsen, som kan oppsummeres slik: Første del av en innbruddspakke i flere deler ble inkludert i binære pakker for distribusjon til installasjon hos kunder, med gyldige kryptografiske signaturer fra byggesystemet, og ble i stor grad satt ut temmelig direkte i produksjon av nettverksadministratorer over hele verden.

Skadevaren satte så i gang med å utforske nettverkene den hadde landet i, og med utstrakt brukt av spesielt utformede DNS-forespørsler og en del andre ikke helt opplagte teknikker var angriperne i stand til å skaffe seg tilgang til kritiske og følsomme nett hos myndigheter og større bedrifter i en rekke land.

«Når frie og åpne komponenter plutselig sluttet å virke, førte det forståelig nok til sterke reaksjoner fra mange.»

#2: En rekke hendelser i leveringskjeden for frie og åpne programvarekomponenter (2020 og senere)

Kort tid etter SUNBURST-hendelsen ble det oppdaget en rekke hendelser der utbredte programvarekomponenter med frie lisenser som andre systemer hentet inn som avhengigheter for egen kode enten sluttet å virke eller ble utilgjengelig, slik at en rekke systemer helt eller delvis sluttet å fungere eller tapte funksjonalitet, som når en web-tjeneste plutselig nektet å kommunisere med spesifikke nettverk.

Når frie og åpne komponenter plutselig sluttet å virke, førte det forståelig nok til sterke reaksjoner fra mange, og deler av skravle-delen av konsulentklassen begynte å lire av seg dystre advarsler om riskikoen de mente var forbundet med enhver bruk av fri og åpen programvare, uansett sammenheng.

Blant oss som så dette litt fra sidelinjen var det mange som jobber med fri og åpen programvare som mente at disse hendelsene til sammen kunne gi viktig læring. Det er nesten en selvfølge at i moderne miljøer suger vi til oss oppgraderinger ofte og automatisk, og at kode som ikke er testet aldri må settes direkte ut til produksjon.

#3: Blind og ubetinget tillit kontra retten til å lese (bli opplyst) og retten til å reparere

Med bedriftseid programvare som kun er tilgjengelig som binær og kjørbar, har du ikke noen annen mulighet enn å stole på leverandøren og ha full tillit til at de utbedrer eventuelle mangler innen rimelig tid. Dette betyr i praksis at med lukket progamvare som kun er tilgjengelig i binærform er du avskåret fra de to viktigste egenskapene ved fri og åpen programvare: Retten til å lese og studere koden og retten til å reparere eventuelle mangler og feil du finner. Retten til å reparere kan komme til å spare deg for nedetid eller midlertidige omgåelser mens de hemmelige delene av systemet du har ansvar for blir fikset et annet sted i verden.

Lærdommen som er å hente i dette er at du må drive kvalitetskontroll på hele leveringskjeden. Du kan velge å stole på det du får, men du må likevel sjekke ordentlig. Dette gjelder uavhengig av om programvaren er fri og åpen eller lukket og bare tilgjengelig for deg som binær.

Det var en viss glede å spore da jeg oppdaget at Nasjonal Sikkerhetsmyndighet i alt vesentlig sier det samme i sine anbefalinger.

Bidra - samarbeide om vedlikehold

Akkurat som med alle andre produkter er det fullt ut mulig å velge å være en passiv forbruker, bare installere og bruke, bygge det du har behov for på toppen og bare kontakte miljøet via nedlasting etter behov fra de offentlige arkivene. Du kan også velge å kommunisere via nettforum, epostlister eller andre kanaler, men det er helt opp til deg selv.

Hvis du er utvikler eller integrator med ambisjon om å gjøre ett eller flere frie og åpne produkter til sentral del av det du lever av, enten ved å bruke og medvirke i et eksisterend projekt eller å starte et nytt, er det flere tilnærminger som er mulige.

La oss se nærmere på strategiene som noen av navnene du har hørt om har brukt med fri og åpen kode i produktene:

#1: Sug til deg koden, lag avledet versjon, selg maskinvare:

Netscalers produkter for lastbalansering og applikasjonsleveranse er basert på avledning (fork) av FreeBSD.

Tilsynelatende har de skrevet om store deler av nettverksstakken og laget et nettverksprodukt med rik funksjonalitet på toppen. Blant annet har de et tiltalende grafisk grensesnitt tilgjengelig for å utføre mange, om ikke absolutt alle, administrative oppgaver.

Når en ser litt nærmere etter ser det ut som Netscaler (senere kjøpt opp og omdøpt av Citrix) holder liv en samling med prosjekter med fri og åpen lisens som kan brukes med produktene.

Men de ser ikke ut til å hatt spesielt nær kontakt med den viktigste kilden for koden de har videreutviklet. (Det er verd å merke seg at BSD-lisensen ikke stiller noe krav om at endringer som blir gjort i koden skal gjøres offentlig tilgjengelig.) Sist jeg sjekket ved å gå til shell-kommandolinje på en Netscaler-enhet, ga det som kom ut fra uname -a indikasjon på at produktet kjørte med en kjerne som fortsatt var basert på FreeBSD 8.4, som FreeBSD-prosjektet på sin web har oppført som End of Life første august i 2015.

#2: Sug til deg koden, lag avledet versjon, selg maskinvare, synkroniser med oppstrøms-kilden:

Fra og med den første utgaven av moderne macOS har Apple vedlikeholdt og utviklet programvaren som driver de forskjellige typene utstyr de lager, fra telefoner til skrivebordsmaskiner og tilhørende tjenester, med betydelige mengder fri og åpen kode.

Samtidig viser firmaet seg generelt villig til å offentliggjøre kode og kommunisere med prosjektene de henter kode fra, som FreeBSD-prosjektet. Apple vedlikeholder webstedet Open Source at Apple som gir enkelt tilgang til de komponentene som brukes i produktene som også er fri og åpen kode.

Denne formen for samarbeid med fri og åpen kode ser ut til å være ganske utbredt, spesielt med nettverksorienterte produsenter av spesialisert utstyr.

#3: Legg alt ut som fri og åpen kode, selg støttetjenester:

Til tross for betydelig skepsis fra forretningssiden i starfasen har flere bedrifter lyktes godt med forretningsmodeller der firmaet deltar i eller til og med er hovedaktør i utvikling av systemer eller komponenter under fri og åpen lisens, mens kontrakter om støttetjenester (som kan omfatte slikt som tidligere tilgang til oppdateringer eller tilgang til spesielle tillegg) i tillegg til konsulenttjenester er eneste eller største inntektskilde.

#4: Finn frem til kode som er både bra nok til å offentliggjøre og vil være nyttig andre steder:

Endelig, for de av oss som tilbyr konsulenttjenester og innimellom kan komme til å skrive kode som ikke er veldig kundespesifikk, finnes det en rimelig middelvei. Identifiser kode som oppfyller disse kriteriene:

  1. Er utviklet av deg og klarert av organisasjonen du tilhører og andre med tilknyting til den
  2. Holder god nok kvalitet til at du tør å vise den til andre
  3. Ikke avslører sentrale eller sensitive deler av kundens forretningslogikk
  4. Sannsynligvis kan være nyttig også andre steder
  5. Ville være bra å få eksponert for andre sett med øyne for å finne feil og rette dem

Hvis du har kode du har ansvar for i din organisasjon som oppfyller disse kriteriene, bør du etter min mening alvorlig vurdere å gjøre koden tilgjengelig under en fri og åpen lisens.

I så fall blir den neste oppdagelsesreisen å finne en lisens som passer for din kode.

Retningslinjer, prosedyrer og prosesser - Er alt på plass?

Hvis du har fulgt med så langt, så har du antakelig oppfattet at det er smart å etablere klare retningslinjer og prosedyrer for hvordan en håndterer kode, enten den er fri og åpen eller ikke.

Husk på at:

#1: En lisens er en markering av autoritet.

En lisens er opphavspersonens melding til verden som angir hvilke vilkår andre må overholde når de bruker, eller om det blir gitt anledning til det, endrer og videreutvikler koden.

Om det ikke eksisterer en lisens, er utgangspunktet at bare den eller de som har laget koden har rett til å gjøre endringer i den eller for den del lage flere eksemplarer for å gi videre til andre.

Av den grunn er det viktig å forsikre seg om at alle deler av prosjekter du har ansvar for, har kjent opphav og lisens.

Det har vært en del tilfeller der fri programvare-prosjekter har skrevet ny kode for å erstatte, forhåpentlig med bedre utgaver, hele delsystemer på grunn av at koden som inntil da hadde vært i bruk var gitt ut under en ikke-akseptabel lisens (se OpenBSD-artiklene i referansedelen til slutt for noen eksempler).

#2: Prosedyrer og retningslinjer, du trenger dem.

En utvikler som jobber i eget firma står vanligvis fritt til å velge den lisensen en selv vil. I miljøer i større bedrifter og organisasjoner blir kode etter all sannsynlighet utviklet i samsvar med en kontrakt eller annen avtale som kan, men ikke nødvendigvis må, angi parametre for hvem som har opphavsrett og hvilke lisenser som kan godtas. Nøyaktig hva som kan fastsettes i en avtale og hva som alltid følger av opphavsrettslovgivning kan være avhengig av hva som gjelder i landet eller territoriet der avtalen er inngått eller der partene holder til, slik at deltakere fra forskjellige land kan ha forskjellig lovgivning de må forholde seg til. Når en vurderer å gi ut kode under en fri og åpen lisens, er det uhyre viktig å sørge for at alle med tilknytning til koden og i alle fall alle kontraktsparter er enige om og inneforstått med hva som gjelder av retningslinjer og prosedyrer.

#3: Så enkelt som mulig, for din egen del.

Det finnes flere hundre lisenser som Open Source Initiative vurderer som frie og åpne. For å gjøre livet så håndterlig som mulig for de som kan være interessert i å jobbe med koden din bør du sterkt vurdere å bruke en av disse velkjente lisensene.

Disse lisensene går fra de enkleste av BSD- eller MIT-type som er noen få setninger lange og kan kondenseres til omtrent at du kan gjøre hva du vil med dette materialet, bortsett fra å påstå at du har laget alt sammen selv, til kompliserte dokumenter (eksempelvis GNU GPL versjon 3) som setter opp detaljerte bestemmelser som eksempelvis kan omfatte krav om at endringer må offentliggjøres med samme vilkår og kan etablere et bestemt regime for eventuelle patentkonflikter.

Det er også viktig å huske på at komponenter du bruker i ditt prosjekt kan ha spesielle krav til lisenser og at forskjellige lisenser kan inneholde bestemmelser som gjør at frie lisenser kan være inkompatible i praksis.

Mitt generelle råd er: Gjør det så enkelt som mulig, men ikke enklere.

Eller sagt på en annen måte: Hovedregelen er den samme for lisenser som for kryptografi-kode: Ikke sett i gang med å skrive din egen om du ikke vet nøyaktig hva du gjør. Unngå det om det er overhode mulig.

#4: Bruk Juridisk når du trenger det (men sjekk at de forstår hva det gjelder).

Jurister sliter seg gjennom en lang utdannelse for å ta eksamen og få rett til å praktisere, men det er ingen garanti for at en person som er godt inne i forretningsjus og kontrakter har nødvendig kompetanse på opphavsrettsområdet. Når du tar kontakt med Juridisk for å få hjelp er det grunn til å være fast bestemt på at de viser at de har god innsikt i opphavsrett og om overhode mulig ,har en rimelig grad av forståelse for hvordan en bygger programvare i den virkelige verden.

For eksempel ønsker du virkelig ikke å bruke en hel ettermiddag eller mer på å forklare forskjellene mellom statisk og dynamisk linking og hvorfor dette kan være viktig når det gjelder spesifikke lisenser, eller at spesifikke bestemmelser i forskjellige lisenser som er regnet som frie og åpne av Open Source Initiative faktisk kan være inkompatible i praksis.

Det er viktig å ha fokus på at å jobbe med fri og åpen kode handler om å gjøre livene våre mer produktive og bedre på alle vis, ved å utveksle gode ideer mellom profesjonelle utviklere og kanskje også dele på vedlikeholdsbyrden slik at vi alle får mer ressurser til disposisjon for å utvikle både kompetanse og produkter videre.

Veien videre - arbeidet fortsetter

Så dette er der vi er i dag. Moderne programvareutvikling og en betydelig del av næringslivet og samfunnet ellers er kritisk avhengig av fri og åpen programvare.

Hvis du har hatt glede av denne teksten (eller ble irritert over noen del av den) vil jeg gjerne høre fra deg. Jeg er spesielt interessert i kommentarer fra kolleger som har erfaring med bruk og/eller utvikling av fri og åpen programvare i profesjonell sammenheng og i store miljøer. Og selvfølgelig, hvis du bare er interessert om å vite mer om bruk av fri og åpen programvare i slike miljøer, er du selvfølgelig velkommen til å sende meg noen ord.

Jeg er enklest å få tak i via epost til nix at nxdomain dot no.

En spesiell takk til Malin Bruland og Knut Yrvin for gode kommentarer og korrektur.

Innlegget er skrevet i anledning et foredrag for NUUG 18. april om "profesjonell bruk av fri programvare".

Ressurser: