Blogindlæg af Leif Lodahl, it-arkitekt, Ballerup Kommune
OS2 står som bekendt for Open Source - Offentligt Samarbejde.
I OS2 er open source software et af hjørnestenene i samarbejdet, og det er en del af foreningens hjerteblod. Kildekoden til de programmer, vi udvikler i fællesskab, skal kunne benyttes, ikke bare af os selv, men også af alle andre.
Ideen er bestemt attråværdig og falder i hak med seneste års principper om ”public money – public code”, altså ideen om at programkode, som bliver udviklet for skatteborgernes penge, skal komme skatteborgerne til nytte. I Danmark er kampagnen ikke så synlig fsva. kode, men vi snakker rigtig meget om åbne data, altså samme princip, bare for indsamlede data.
OS2-foreningen er blevet ”voksen”, og nogle af de løsninger, som vi har udviklet, er faktisk blevet ganske populære, og visse systemer indgår som kritiske komponenter i flere kommuners infrastruktur. Vi oplever også, at OS2 i stigende grad indgår som aktiv spiller og bliver hørt i den offentlige debat. Senest er OS2 nævnt som en spiller i ”Den fælleskommunale digitaliseringsstrategi” og begrebet ”open source” fremhæves i KL’s ”Fælleskommunale Arkitekturprincipper”.
Det stiller krav til, at vi agerer professionelt, også når det kommer til licensering.
OS2-foreningen har offentliggjort en vejledning til kommunerne.
Licenserne
Der findes en lang række forskellige open source licenser, og det er der en grund til. Open source er ikke ensbetydende med, at det er tilladt at stjæle med arme og ben. Nogle licenser er meget eftergivende (permissive) og andre er restriktive (restrictive). De restriktive licenser er dem vi af og til betegner copyleft-licenser.
Lad mig lå fast med det samme: Licensen udløses ikke ved anvendelse, men først ved videredistribution. Som bruger behøver du ikke bekymre dig.
Copyleft-licenserne er kendetegnet ved, at anvender du noget kode i et af dine projekter, og koden er copyleft, så må den kode du laver ikke blive offentliggjort med en licens, som er svagere end den ”lånte” kodes licens. Det betyder også, at hvis du bruger flere forskellige kodestumper, er det den stump der har den stærkeste (mest restriktive) licens, som definerer mindstekravet til licensen af dit eget program. Det er spørgsmålet, om hvordan licenserne i kombination er kompatible. For eksempel kan software, der kombinerede kode frigivet under version 1.1 af Mozilla Public License (MPL) med kode under GNU General Public License (GPL) ikke distribueres uden at krænke et af vilkårene i licenserne.
Kilde: Wikipedia
Hvad betyder det?
Lad os lave et tænkt eksempel, hvor du som udvikler i en kommune har programmeret en lille ”dims”, som kan noget smart. I udviklingsarbejdet har du fundet inspiration i og lånt kode fra to-tre forskellige projekter på Github.
Den løsning du har lavet giver værdi for dig og din kommune, og så længe den forbliver inden for kommunegrænsen er der ingen ko på isen. Din kommune er bruger af de kodestumper du har fundet på Github, og open source licensen træder slet ikke i kraft.
Men andre kommuner har hørt om jeres succes, og din chef har ikke noget imod at du deler løsningen med de andre, og selvfølgelig helst igennem OS2-fællesskabet. Uanset om løsningen deles med nabokommunen i en mail eller stilles til rådighed for hele fællesskabet på OS2’s Github, så klapper fælden. Licenserne til de Github-projekter du har anvendt, bliver udløst med et brag.
Hvis bare et af de projekter du har lånt kode fra er underlagt copyleft restriktioner, kan du ikke tillade dig at frigive din egen kode under en licens, som er svagere. Det er med andre ord den stærkeste licens blandt de anvendte, som bestemmer mindstekravet til din licens.
Hvordan håndterer vi det i det daglige?
Enhver udvikler som anvender kode fra offentlige repositorier som Github o.l., bør i sine egne projekter føre et nøje regnskab over, hvad der er anvendt af eksterne moduler, biblioteker og ”stumper”. Du kan med fordel anvende kommentarer i koden og indføje såkaldte boilerplates, en ”deklaration” af din kode om anvendelse af kode fra 3. part.
Med dette regnskab kan du selv ”beregne” mindstekravet for frigivelsen af din løsning.
Gør du det, kan du altid forsvare brugen, og har du din ryg fri.
Som indkøber af open source software eller af software, som bygger på open source software, bør du som en del af leverancen forlange enten en erklæring fra leverandører som friholder dig, eller et tilsvarende ”bogholderi” over anvendte eksterne moduler og biblioteker, så du selv kan vurdere om koden overholder licensbetingelserne.
Hvad er konsekvenserne?
I sidste ende er det OS2 som forening, som er ansvarlig for at OS2-projekterne overholder licensreglerne i de underliggende moduler og biblioteker. Langt de fleste konflikter løses i mindelighed, og det er yderst sjældent at brud på open source licenser ender med erstatningssager. Men konsekvensen kan være, at OS2 bliver tvunget til, enten at ændre licensens på OS2-løsningen eller at OS2 tvinges til at udskifte et modul med et andet, og sidstnævnte kan ende med at blive en dyr fornøjelse.
Foto: La-Rel Easter på Unsplash.com