Fair source vs. open source: hvad er forskellen — og hvorfor vi valgte fair source

Fair source vs. open source handler om én ting: hvornår konkurrenter frit må sælge din kode som deres egen tjeneste. Open source tillader det med det samme — også for konkurrenter. Fair source er en licensmodel, hvor koden er offentligt tilgængelig med få begrænsninger, og hvor den efter en fastlagt periode — for Agent360 to år — automatisk bliver ægte open source. Agent360 er internalOS: virksomhedens AI-platform i én IDE.

Den korte version: open source betyder, at alle frit må bruge, ændre og videredistribuere koden — også kommercielt, også som konkurrent til den, der skrev den. Fair source betyder, at koden er offentligt tilgængelig at læse og bruge med få begrænsninger, der beskytter producentens forretning — og at den efter en fastlagt periode, typisk to år, bliver ægte open source. Agent360 er fair source — ægte open source efter 2 år. I denne artikel forklarer vi, hvad de to modeller er, hvorfor forskellen overhovedet opstod, hvad den betyder for jer som kunder — og helt åbent: hvorfor vi valgte, som vi gjorde.

Fair source er en licensmodel, hvor kildekoden er offentligt tilgængelig at læse, bruge og ændre med minimale begrænsninger, og hvor hver version af koden efter en planlagt periode automatisk overgår til en anerkendt open source-licens — så åbenheden ikke er et løfte, men en indbygget mekanisme.

Det her er ikke en jura-artikel. Det er en tillids-artikel. Når I vælger en softwareleverandør — især til noget så centralt som virksomhedens AI-platform — så køber I ikke bare funktioner. I køber en afhængighed. Og så er det rimeligt at spørge: Hvad sker der med os, hvis leverandøren lukker, bliver opkøbt eller skifter kurs? Licensen er en stor del af svaret, og derfor fortjener den mere opmærksomhed, end den normalt får i et leverandørvalg.

Hvad er open source? Den officielle definition

“Open source” bliver ofte brugt løst om alt, hvor man kan se koden. Men begrebet har faktisk en præcis, formel definition, som vedligeholdes af Open Source Initiative (OSI) — organisationen, der siden slutningen af 1990’erne har fungeret som standardsætter på området.

OSI’s Open Source Definition stiller ti krav til en licens, før softwaren må kaldes open source. De vigtigste i denne sammenhæng:

Fri videredistribution og fri brug

Licensen må ikke forhindre nogen i at sælge eller forære softwaren videre, og den må ikke kræve royalties. Alle skal kunne bruge softwaren til hvad som helst.

Ingen diskrimination — heller ikke mod konkurrenter

To af OSI’s krav er særligt vigtige at forstå: licensen må ikke diskriminere mod personer eller grupper, og den må ikke begrænse, hvilke formål softwaren bruges til. OSI nævner selv eksemplet direkte: licensen må ikke forhindre, at programmet bruges i en forretning. Det betyder i praksis, at en ægte open source-licens ikke kan forbyde en konkurrent at tage koden og sælge den som sin egen tjeneste. Det er ikke et hul i definitionen — det er en bevidst del af den.

Adgang til kildekode og ret til afledte værker

Programmet skal inkludere kildekode i den form, en udvikler faktisk ville arbejde i (bevidst sløret kode tæller ikke), og licensen skal tillade ændringer og afledte værker på samme vilkår.

Open source er med andre ord ikke bare “koden er synlig”. Det er en juridisk garanti for, at alle — brugere, partnere, konkurrenter, hyperscalere — kan gøre stort set hvad som helst med koden. Den garanti har givet verden Linux, PostgreSQL og det meste af internettets fundament. Den er en af de største succeser i softwarehistorien. Og netop dens styrke — at ingen kan udelukkes — er samtidig grunden til, at nogle virksomheder de senere år har ledt efter et alternativ.

Hvad er fair source — og hvad er FSL?

Fair source er et nyere begreb med sin egen formelle definition, som vedligeholdes på fair.io. Initiativet blev startet af softwarevirksomheden Sentry i 2024, som svar på en debat i udvikler-verdenen om, hvordan man deler kode meningsfuldt uden at underminere sin egen forretning.

Fair.io’s definition siger, at Fair Source-software:

er offentligt tilgængelig at læse — koden ligger åbent fremme, typisk på GitHub,
tillader brug, ændring og videredistribution med minimale begrænsninger, der beskytter producentens forretningsmodel, og
gennemgår forsinket open source-publicering (Delayed Open Source Publication, DOSP) — dvs. koden bliver efter en planlagt periode udgivet under en OSI-godkendt open source-licens.

Det tredje punkt er det afgørende. Fair.io kalder det selv en “bright line” — en skarp grænse, der adskiller fair source fra andre delvist-åbne modeller. Det er ikke nok at vise koden frem; der skal være en indbygget, planlagt overgang til ægte open source.

FSL: Functional Source License

Den mest kendte fair source-licens er Functional Source License (FSL), udviklet af Sentry. FSL’s egen beskrivelse er præcis: det er en fair source-licens, der konverterer til Apache 2.0 eller MIT efter to år. Apache 2.0 og MIT er to af de mest udbredte og mest permissive open source-licenser overhovedet — så når konverteringen sker, er der ikke tale om en light-udgave af åbenhed, men om fuld, OSI-godkendt open source.

FSL formulerer sit princip sådan: du må gøre alt med softwaren, undtagen at underminere dens producent. Du må køre den til stort set alle formål, studere den, ændre den og distribuere dine ændringer — men du må ikke tage produktet og sælge det som en konkurrerende tjeneste, mens producenten stadig lever af det.

To-års-mekanismen — sådan virker den konkret

Et vigtigt teknisk detalje, som fsl.software selv fremhæver: to-års-perioden gælder pr. version. Hver gang der udgives en ny version af softwaren — et git-commit, en pakke-release — starter uret for netop dén version. Det betyder, at koden løbende “modner” til open source: den version, der blev udgivet for to år siden, er open source i dag, uanset hvad producenten mener om det til den tid. fsl.software beskriver det helt lavpraktisk: man kan klone repoet, checke den to år gamle version ud, og bruge den under MIT eller Apache 2.0.

Det er værd at stoppe op ved. Overgangen til open source er ikke et løfte, leverandøren kan fortryde. Den står i licensteksten på den kode, der allerede er udgivet. Selv hvis virksomheden bag skifter mening, bliver opkøbt eller lukker, er den to år gamle kode open source. Ingen kan trække det tilbage.

Hvorfor ikke bare open core?

En model, mange kender, er “open core”: kernen er open source, men de kommercielle funktioner er lukkede. fsl.software kritiserer selv den model for at være for restriktiv på en anden led: nogle produktfunktioner bliver aldrig åbne, og hvor grænsen går, varierer vildt fra produkt til produkt. Med fair source er hele produktet tilgængeligt nu — og hele produktet bliver open source med tiden. Der er ingen permanent lukket del.

Hvorfor ikke AGPL eller BUSL?

For de teknisk nysgerrige: fsl.software forklarer også, hvorfor de ikke bare valgte eksisterende alternativer. AGPLv3 — en stærk copyleft-licens — afvises, fordi den er så “viral”, at mange organisationer helt forbyder den af frygt for at skulle offentliggøre egen proprietær kode. Og FSL’s direkte forgænger, Business Source License (BSL/BUSL), roses for sin tidsbaserede tilgang men kritiseres for to ting: fire år er for længe, og BUSL’s valgfri tillægsklausuler gør, at hver BUSL-implementering reelt er sin egen licens, man skal læse forfra. FSL strammede det op: fast to år, fast konvertering til Apache 2.0 eller MIT, ingen varianter.

Hvorfor er licensmodeller overhovedet blevet et emne?

Hvis open source er så stor en succes, hvorfor findes fair source så? Svaret ligger i en strukturel spænding, som SaaS-æraen skabte.

Spændingen: åben kode vs. hosted forretning

Da open source-definitionen blev skrevet, distribuerede man software på CD’er og downloads. Forretningsmodellen for open source-virksomheder var typisk support, konsulentydelser eller betalte enterprise-udgaver. Men i dag leveres software overvejende som hostede tjenester — og det ændrede spillet fundamentalt.

Problemet er enkelt at beskrive: hvis din kode er ægte open source, må enhver — inklusive verdens største cloud-udbydere — tage den, hoste den som deres egen betalte tjeneste og konkurrere direkte med dig, uden nogensinde at bidrage tilbage. OSI’s definition garanterer dem retten til det (ingen diskrimination mod anvendelsesformål, husker du). Producenten bærer alle udviklingsomkostningerne; free-rideren høster gevinsten.

fsl.software kalder fænomenet “harmful free-riding” og henviser til det klassiske free-rider-problem fra samfundsvidenskaben: når dem, der nyder godt af en fælles ressource, ikke bidrager til den, bliver ressourcen underproduceret eller degraderet — og samarbejdsviljen hos dem, der faktisk bidrager, forvitrer.

Konsekvensen: licens-skift og skuffede communities

Resultatet har været, at en række kendte softwarevirksomheder gennem årene har forladt rene open source-licenser til fordel for mere restriktive modeller. Vi nævner bevidst ikke navne og årstal her — den slags detaljer fortjener præcision, og pointen er ikke at udpege nogen. Pointen er mønsteret: virksomheder, der startede som open source, oplevede at deres hostede forretning blev udhulet, og skiftede så licens undervejs — ofte til stor frustration for brugere og bidragydere, der havde regnet med noget andet. Det er den slags kursskifte, der i udvikler-kredse har fået øgenavnet “rug-pull”: tæppet bliver trukket væk under folk, der havde indrettet sig i god tro.

Fair source er et forsøg på at gøre det ærligt fra starten. I stedet for at love fuld open source og senere trække i land, siger en fair source-virksomhed fra dag ét: her er koden, her er de få ting du ikke må, og her er den dato, hvor hver version bliver ægte open source. Ingen overraskelser i nogen retning. Det er også derfor, fair.io eksplicit siger, at formålet er at legitimere meningsfuld kode-deling uden at forveksle det med Free and Open Source Software — fair source udgiver sig ikke for at være open source. Det er sin egen kategori, med sine egne, åbent deklarerede vilkår.

Fair source i praksis: hvad må man — og hvad må man ikke?

Lad os gøre det helt konkret. Med software under FSL (den licensfamilie, fair source-bevægelsen er bygget op omkring) gælder groft sagt følgende — og for detaljerne henviser vi altid til den faktiske licenstekst på fsl.software:

Det må man:

Læse al koden. Hele produktet, ikke kun en “community-kerne”. I kan lave sikkerhedsreview, audits og due diligence på det, I faktisk kører.
Bruge softwaren til stort set alle formål — internt i virksomheden, i produktion, kommercielt.
Ændre koden — rette fejl selv, tilpasse den, bygge ovenpå.
Distribuere sine ændringer og foreslå forbedringer tilbage til producenten.
Bruge enhver version, der er over to år gammel, som ægte open source under Apache 2.0 eller MIT — uden at spørge nogen om lov.

Det må man ikke:

Underminere producenten — i praksis: tage produktet og udbyde det som en konkurrerende kommerciel tjeneste, mens versionen stadig er inden for to-års-perioden.

Det er hele forskellen. For en virksomhed, der er kunde — ikke konkurrent — er der i hverdagen stort set ingen mærkbar forskel på fair source og open source. Begrænsningen rammer én meget specifik aktør: den, der vil sælge producentens eget produkt i konkurrence med producenten. Alle andre har adgang, indsigt og handlefrihed.

Sammenligningen: open source, fair source og proprietær

Open source, fair source og proprietær software sammenlignet på de punkter, der betyder noget for en kunde
Egenskab	Open source (OSI)	Fair source (fx FSL)	Proprietær / lukket
Kan I læse kildekoden?	Ja, altid	Ja, altid	Nej
Kan I bruge og ændre koden?	Ja, uden begrænsninger	Ja, med få begrænsninger (må ikke konkurrere mod producenten)	Nej — kun det, kontrakten giver
Kan en konkurrent sælge produktet videre?	Ja — det garanterer licensen	Ikke de første to år pr. version	Nej
Bliver koden ægte open source?	Den er det allerede	Ja — automatisk, hver version efter to år	Nej, aldrig
Kan leverandøren "trække tæppet væk"?	Fremtidige versioner kan skifte licens; udgivne versioner forbliver åbne	Udgivne versioner konverterer uanset hvad — det står i licensen	Leverandøren bestemmer alt
Exit-mulighed hvis leverandøren lukker	Stærk — community kan overtage	Stærk — koden er læsbar nu og open source om senest to år	Svag — typisk kun dataeksport, hvis kontrakten sikrer det
Beskytter modellen producentens forretning?	Nej — free-riding er tilladt	Ja — i to-års-vinduet	Ja — fuldstændigt

Tabellen viser det centrale: fair source ligger tæt på open source i alt det, der handler om kundens tryghed og indsigt — og tæt på proprietær i det ene punkt, der handler om at beskytte producentens levebrød. Det er hele designet.

Hvad betyder det for jer som kunder?

Nu til det, der faktisk er artiklens ærinde. Hvorfor skal I som virksomhed interessere jer for jeres leverandørs licens? Fordi licensen afgør tre ting, der først betyder noget den dag, noget går galt — og som netop derfor skal afklares, før I skriver under.

1. Indsigt: I kan se, hvad I kører

Med fair source ligger koden offentligt fremme. Jeres egne udviklere — eller en ekstern sikkerhedsrådgiver — kan læse præcis, hvad platformen gør: hvordan den håndterer jeres data, hvilke systemer den taler med, hvor den sender hvad hen. Det er ikke et markedsføringsargument; det er en praktisk mulighed for at lave rigtig due diligence. I en tid, hvor AI-leverandører beder om adgang til virksomhedens mest følsomme data, er “stol på os” ikke et tilfredsstillende svar. “Læs selv efter” er bedre. Det spiller også direkte sammen med de dokumentationskrav, der følger med ny regulering — vi har skrevet mere om det i vores gennemgang af EU’s AI-forordning og hvad den betyder for danske virksomheder: det er svært at dokumentere, hvad et lukket system gør. Det er væsentligt lettere, når koden kan læses.

2. Exit: afhængigheden har en bagdør

Det ærlige spørgsmål ved ethvert platformsvalg er: hvad koster det os at komme ud igen? Vendor lock-in er en reel omkostning, som mange virksomheder kender fra store CRM- og salgsplatforme — det er en gennemgående pointe i både vores guide til Salesforce-alternativer og vores gennemgang af HubSpot-alternativer: jo dybere platformen sidder i jeres processer, jo dyrere er døren ud.

Fair source ændrer den kalkule fundamentalt. Hvis leverandøren lukker, bliver købt op eller udvikler produktet i en retning, I ikke vil med i, så står I ikke med en sort boks, der en dag slukkes. I står med kode, I kan læse i dag, og som version for version bliver ægte open source. Fair.io formulerer selv præcis dette som en del af formålet med DOSP: hvis en fair source-virksomhed går konkurs eller udvikler produktet i en uønsket retning, kan fællesskabet eller en anden virksomhed samle koden op og føre den videre. Jeres exit er ikke afhængig af leverandørens velvilje — den er indbygget i licensen.

3. Ingen rug-pull: reglerne kan ikke ændres med tilbagevirkende kraft

Den tredje tryghed er den mest oversete. Ved rene open source-projekter, der ejes af én kommerciel aktør, har historien vist, at licensen kan strammes fremadrettet — nye versioner udgives under nye vilkår, og brugerne må vælge mellem at betale eller blive på en gammel version. Fair source vender den mekanik om: Her er udgangspunktet allerede deklareret ærligt (der ER begrænsninger, de står åbent frem), og bevægelsen over tid går kun én vej — mod mere åbenhed, automatisk, version for version. Den to år gamle kode er open source, uanset hvad der sker med virksomheden bag. Det kan ingen bestyrelse, ingen opkøber og ingen ny strategi lave om.

For en kunde betyder det: den værst tænkelige overraskelse er taget af bordet på forhånd. I ved fra dag ét præcis, hvad I har, hvad I får, og hvornår.

Vores valg: derfor er Agent360 fair source

Og så til den del, hvor vi lægger vores egne kort på bordet.

Agent360 er en dansk platform — virksomhedens AI-platform i én IDE — hvor hver virksomhed kører sin egen instans med sin egen database, med mulighed for self-hosting, 35+ connectors til virksomhedens systemer og en agent bygget på Claude. Og Agent360 er fair source — ægte open source efter 2 år. Ikke “open source”, ikke “kildekode tilgængelig” som tomt buzzword — fair source, med den præcise mekanik, denne artikel har beskrevet.

Hvorfor valgte vi det? To grunde, og vi tager den mest selviske først, for det er sådan, transparens fungerer:

1. Det beskytter os mod at blive klonet af større aktører. Vi er en lille dansk virksomhed. Hvis vi udgav hele platformen som ægte open source i morgen, ville enhver større aktør med flere udviklere og et større marketingbudget lovligt kunne tage koden, sætte deres eget logo på og udkonkurrere os med vores eget produkt. Det er ikke paranoia — det er præcis det free-rider-scenarie, FSL blev skabt for at adressere. To-års-vinduet giver os et forspring på vores egen kode: tid nok til at det kan betale sig at bygge, ikke så længe at åbenheden bliver fiktion.

2. Det giver jer som kunder den indsigt og exit, vi selv ville kræve af en leverandør. Vi beder virksomheder om at lade en AI-platform arbejde med deres data og deres processer. Det er en stor tillidserklæring, og den skal ikke hvile på vores ord alene. Med fair source kan I læse koden, I kan hoste selv, jeres data ligger i jeres egen database — og hvis vi en dag ikke længere findes eller ikke længere fortjener jeres tillid, bliver koden ægte open source af sig selv, version for version. Vi har med andre ord bundet os til masten: Vi kan ikke lave en rug-pull, selv hvis vi ville.

Det er den ærlige udlægning. Fair source er ikke ren idealisme fra vores side — det er et velafbalanceret bytte. Vi får beskyttelse i to år pr. version; I får indsigt nu og fuld åbenhed med tidsforsinkelse. Begge parter ved præcis, hvad aftalen er. Vi tror, det er en sundere konstruktion end både den lukkede boks (hvor I ingenting ved) og det rene open source-løfte fra en kommerciel aktør (som historien har vist kan blive trukket tilbage, når investorerne banker på).

Én ting mere, for fuldstændighedens skyld: fair source-valget gælder platformens kode. Det ændrer ikke på, at jeres data altid er jeres — egen instans, egen database — og at almindelig dataeksport selvfølgelig ikke kræver nogen licens overhovedet. Licensen handler om koden; jeres data har I altid kunnet tage med jer.

Sådan vurderer I en leverandørs licens: tjekliste

Uanset om I kigger på os eller en hvilken som helst anden leverandør: her er de spørgsmål, vi mener enhver virksomhed bør stille, før den gør sig afhængig af en softwareplatform. Gem listen — den er leverandør-neutral, og et seriøst svar på alle otte punkter bør være en selvfølge. Den hører naturligt hjemme i samme drejebog som resten af jeres systemvalg — se også vores guide til revenue operations, hvor leverandør- og systemvalg indgår i den samlede arkitektur.

Kan vi læse kildekoden? Ikke “kan vi få en demo” — kan jeres folk faktisk læse den kode, der behandler jeres data? Hvis nej: hvad tilbyder leverandøren i stedet som dokumentation for, hvad systemet gør?
Hvilken licens, præcist? Bed om licensens navn og link til teksten. “Open source” uden licensnavn er et advarselstegn — begrebet har en formel definition (opensource.org/osd), og en seriøs leverandør ved, om deres licens opfylder den eller ej.
Hvis “fair source” eller lignende: hvad er konverteringsmekanismen? Hvornår bliver koden open source, under hvilken licens, og gælder det pr. version? Står det i licensteksten (godt) eller kun i markedsføringen (dårligt)?
Kan vi self-hoste? Selv hvis I aldrig får brug for det, er muligheden et sundhedstegn: den betyder, at leverandøren ikke kan holde jeres drift som gidsel.
Hvor ligger vores data, og hvordan kommer de ud? Egen database eller delt multi-tenant? Fuldt eksportformat eller kun udvalgte felter? Dataspørgsmålet er adskilt fra licensspørgsmålet — stil begge.
Hvad sker der, hvis leverandøren lukker eller opkøbes? Bed om et konkret svar. “Det sker ikke” er ikke et svar. Kode-escrow, fair source-konvertering eller open source er svar.
Har licensen ændret sig undervejs? Tjek projektets historik. En leverandør, der én gang har strammet licensen med kort varsel, kan gøre det igen — og en leverandør, der har deklareret sine begrænsninger ærligt fra start, har mindre at stramme.
Hvem ejer roadmappet? Fair.io er selv ærlige om dette punkt: fair source-virksomheder deler kode, men beholder kontrollen over retning og forretningsmodel. Det er legitimt — men I skal vide det, så I ikke forveksler kodeadgang med medbestemmelse.

Ingen af de otte spørgsmål kræver en jurist at stille. Og mønstret i svarene fortæller jer hurtigt, om I taler med en leverandør, der har tænkt over sit ansvar — eller en, der håber, I ikke spørger.

Ofte stillede spørgsmål

Er fair source det samme som open source?

Nej — og fair source-bevægelsen er selv meget omhyggelig med ikke at påstå det. Open source er defineret af OSI og kræver bl.a., at alle må bruge koden til alle formål, også som konkurrent. Fair source-kode er offentligt læsbar og bredt anvendelig, men har en begrænsning, der beskytter producentens forretning — typisk et forbud mod at udbyde produktet som konkurrerende tjeneste. Til gengæld konverterer hver version automatisk til ægte open source efter en fast periode, i FSL's tilfælde to år.

Hvad betyder det konkret, at Agent360 bliver "ægte open source efter 2 år"?

Det betyder, at hver udgivet version af koden automatisk overgår til en anerkendt, OSI-godkendt open source-licens, når den version er to år gammel. Mekanismen ligger i licensteksten på den allerede udgivne kode — det er ikke et løfte, vi kan trække tilbage. Den kode, der blev udgivet for to år siden, er open source i dag, uanset hvad der måtte ske med os som virksomhed.

Må vores udviklere læse og ændre i koden allerede nu?

Ja. Fair source betyder, at koden er offentligt tilgængelig at læse fra dag ét — ikke først efter to år. Jeres udviklere kan læse den, lave sikkerhedsreview af den og tilpasse den. Den centrale begrænsning i en fair source-licens som FSL rammer kun ét scenarie: at tage produktet og sælge det som en konkurrerende tjeneste, mens versionen er inden for to-års-vinduet. Almindelig brug som kunde — inklusive self-hosting og egne tilpasninger — er netop det, licensen er designet til at tillade.

Hvorfor er Agent360 ikke bare 100 % open source fra dag ét?

Ærligt svar: fordi det ville gøre det lovligt for større aktører at tage hele platformen, sætte eget navn på og konkurrere mod os med vores egen kode — uden at have båret nogen af udviklingsomkostningerne. Det er det såkaldte free-rider-problem, som FSL-licensen er skabt til at løse. Fair source er vores kompromis: I får indsigt og en indbygget exit nu, vi får to års beskyttelse pr. version, og al koden ender som ægte open source. Vi synes, det er et ærligere setup end at love ren open source og risikere at skulle stramme licensen senere, som flere i branchen har måttet.

Hvad sker der med vores data og vores platform, hvis Agent360 lukker?

To adskilte svar. Jeres data: de ligger i jeres egen database på jeres egen instans og kan eksporteres — dataadgang har aldrig krævet nogen softwarelicens. Selve platformen: fordi koden er fair source, er den læsbar i dag, og hver version bliver ægte open source, når den er to år gammel. Det betyder, at jeres organisation — eller en hvilken som helst anden leverandør — lovligt vil kunne videreføre og vedligeholde platformen. Nedlukning af virksomheden bag kan ikke lukke koden.

Er der en fangst? Hvad må man ikke med fair source-kode?

Fangsten er én og den er åbent deklareret: I må ikke tage produktet og udbyde det som en konkurrerende kommerciel tjeneste, så længe den pågældende version er inden for to-års-perioden. FSL formulerer det som, at man må alt undtagen at "underminere producenten". For virksomheder, der bruger softwaren som kunder — internt, i produktion, med egne tilpasninger — er begrænsningen i praksis usynlig. Den findes for at forhindre, at en større aktør høster værdien af producentens arbejde uden at bidrage.

Hvem står bag fair source-begrebet — er det bare et smart marketingord?

Det er et reelt, offentligt defineret begreb med egen organisation. Fair source-initiativet blev startet af softwarevirksomheden Sentry i 2024, definitionen vedligeholdes åbent på fair.io, og den mest udbredte licens i familien — Functional Source License (FSL) — har sin fulde licenstekst liggende frit på fsl.software. Definitionen har tre faste krav: offentligt læsbar kode, brug og ændring med minimale begrænsninger, og planlagt, forsinket open source-publicering (DOSP). En leverandør, der kalder sig fair source uden at opfylde alle tre, bruger ordet forkert — og det kan I selv efterprøve mod definitionen.

Bundlinjen

Open source og fair source er ikke modstandere — de er to ærlige svar på to forskellige situationer. Open source er det rigtige svar for infrastruktur, der skal ejes af alle. Fair source er et nyere, gennemtænkt svar for kommercielle produkter, hvor én virksomhed bærer udviklingen, men hvor kunderne stadig fortjener indsigt, exit og en garanti mod kursskifte med tilbagevirkende kraft.

Vi valgte fair source — ægte open source efter 2 år — fordi det er den model, der lader os bygge en holdbar dansk virksomhed og give jer den transparens, vi selv ville forlange. I behøver ikke tage vores ord for noget af det: definitionerne ligger åbent på opensource.org, fair.io og fsl.software, og vores kode kan læses. Det er sådan, tillid bør fungere i software: mindre “stol på os” — mere “se selv efter”.