Quorum - Skriv

Open source gir kontroll du ikke får kjøpt

2026-09-24T00:00:00+00:00

Fri programvare handler om muligheter – fire friheter

Open source, fri programvare og åpen kildekode – kjært barn har mange navn – handler ikke om pris, men om hvilke muligheter brukeren får. Juridisk sett blir programvare betraktet som åndsverk, og det betyr at det er innehaveren av opphavsretten som bestemmer hvordan programvare kan brukes. Det skjer i lisensen.

Programvare sies å være fri når lisensen gir brukeren fire friheter: bruke den til ethvert formål, forstå den gjennom tilgang til kildekoden, endre den og dele den videre.

For de fleste sluttbrukere betyr ikke disse frihetene så mye, så lenge programmet gjør jobben sin.

I offentlige eller kommersielle virksomheter er rettighetene heller ikke så interessante, så lenge alt går som det skal. Men i en krise kan man med open source handle raskt selv: man har kildekoden og nødvendige juridiske rettigheter.

Frykt, usikkerhet og tvil

Steve Ballmer fra Microsoft gjorde en god jobb med å spre tvil og usikkerhet. I 2001 sa han til Chicago Sun-Times: “Slik lisensen er skrevet, hvis du bruker noe åpen kildekode, må du gjøre resten av programvaren åpen kildekode”.

Denne myten lever fortsatt 25 år senere. Folk er redde for at GPL smitter ukontrollert, og denne frykten tjener leverandørene av lukkede løsninger.

Enkle vilkår i lisenser

Det finnes ingen grunn til å frykte GPL, AGPL eller noen annen open source-lisens, men god grunn til å lese dem. Saken er enkel: lisensen sier hvilke rettigheter du får og hva du eventuelt må gjøre. En annen sak er at noen lisenser er nærmest leserfiendtlige.

Hvis du bare bruker fri programvare internt, trenger du faktisk ikke gjøre noe! Er ikke det deilig?

Plikter oppstår i hovedsak først når du distribuerer åpen kildekode, for eksempel som en komponent i et større system eller en løsning du tilbyr markedet. Hvilke plikter det er, avhenger av lisensen: noen krever bare en liten merknad i dokumentasjonen, andre at du også tilbyr å gjøre kode tilgjengelig. Enkelte lisenser, som AGPL, gir plikter også når du lar eksterne brukere få tilgang over nettverk, for eksempel som SaaS. Og hvis du lager fysiske produkter som inneholder GPLv3-lisensiert fri programvare, må du ha et opplegg for å kunne gjøre brukeren i stand til å kjøre endrede versjoner på dingsen.

Fri programvare gir deg kontroll som lukkede løsninger ikke kan selge – og det er nettopp det digital suverenitet handler om. Quorum kjører i stor grad på fri programvare, og jeg har egne friprog-prosjekter og bidrar til andres. Ta kontakt, enten du vil ha kontroll på bruken av åpen kildekode eller kontroll gjennom den.

– Kirill

Smidig løsning av spenninger i IT-prosjekter

2026-09-07T00:00:00+00:00

Friksjoner, spenninger og konflikter

Friksjoner og til en viss grad spenninger er normale både i kjærligheten og i IT-prosjekter. Friksjonen skaper liv.

Mer friksjon medfører større bruk av ressurser og redusert fremdrift. Ting stopper opp. I IT-prosjekter gir det forsinkelser, fordi leveranser skal være ferdige til avtalte tider.

I kjærligheten er forsinkelse ikke noe problem, partene er tross alt ekte partnere. I IT-prosjekter er det annerledes. Til tross for høytidelige erklæringer om partnerskap og samme båt, sitter kunde og leverandør på forskjellige sider og i forskjellige båter, og har interesser og insentiver til å dytte forsinkelsen over på den andre.

Når avstanden mellom partene øker, øker også spenningen. Det er begrenset hvor mye den kan øke før brudd – og konflikt – er et faktum.

Parterapi

Parterapi er en greie for å håndtere spenninger og økende avstand i kjærligheten.

I IT-prosjekter blir spenningene forsøkt løst ved utveksling av tekster, som egentlig er skrevet av advokater, men der advokatenes deltakelse er kamuflert. Det som i realiteten skjer, er posisjonering. I stedet for å lete etter løsninger, markerer partene sine posisjoner og gjør det vanskelig for seg selv å forlate posisjoner uten tap av ansikt. Hvordan hadde parterapi virket hvis hver av partene hadde med en advokat?

Statens standardavtaler definerer en mekanisme for parterapi – oppnevnt uavhengig ekspert.

Uavhengig ekspert

“Partene skal i forbindelse med inngåelsen av avtalen oppnevne en uavhengig ekspert som angis i bilag 6, med den kompetansen partene mener passer best i forhold til avtalen. Hvis dette ikke er gjort, kan partene bli enige om oppnevningen av en uavhengig ekspert på tvistetidspunktet.”

I mine 20 år som IT-advokat opplevde jeg bare én gang at uavhengig ekspert ble oppnevnt. Eller, det var egentlig to kontrakter, men de hang sammen, så jeg teller det som én. Når jeg diskuterer temaet med bransjekolleger, beskriver de en tilsvarende erfaring. Fra samtalene kommer det også frem at de partene som er modne nok til å bruke uavhengig ekspert – enten til rådgivende eller bindende uttalelser – får mye igjen for bruken.

Min hypotese, som støttes av signalene fra aktørene i bransjen og diskusjoner med fagkolleger, er at ordningen ikke blir brukt så mye, fordi partene ikke vet hvem de skal oppnevne. Ekspertens nytte avhenger nemlig av ekspertens kompetanse.

For å være nyttig i et IT-prosjekt må eksperten kunne teknologi, arkitektur, prosjektstyring og kontrakter. Eksperten må være en nerd.

Statens standardavtaler har mekanismen allerede. Bruk den, og la Quorum løse opp i spenninger, friksjoner og uenigheter. Jeg er nemlig en nerd du trygt kan foreslå for den andre parten.

– Kirill

"Contracts must be written for people to read"

2026-09-01T00:00:00+00:00

“Programs must be written for people to read, and only incidentally for machines to execute” – SICP

Sitatet fra Structure and Interpretation of Computer Programs lar seg omskrive til kontraktsarbeid med enkle grep:

Contracts must be written for people to read, and only incidentally for lawyers to interpret

Kontrakter skal altså ikke bare skrives eller skrives ut, men først og fremst leses. Av mennesker. Derfor må kontraktene bygges logisk, i menneskelig språk, uten det unødvendige, slik at vanlige folk forstår og kan følge kontraktens anvisninger.

Det er klare likheter mellom kode og kontrakt: begge skal styre aktører, tilstander og prosesser, og reagere på hendelser. Det som er forskjellig, er blant annet språk, tolknings- og kjøretidsmiljø og evne til å håndtere unntak. I koden fanges unntak eksplisitt, i kontrakter kan man ende opp med improvisasjon.

Varig, nyttig, vakker

Arkitekter tegner bygninger, IT-arkitekter tegner systemer, kontraktsarkitekter tegner kontrakter. Eller, nei, vent – det finnes jo ikke kontraktsarkitekter!

Vitruvius mente at gode bygg er varige, nyttige og vakre. Utviklere vil helt sikkert omtale god programvare med samme adjektiver. Men hva med kontrakter?

Advokater som lager kontrakter, er ingen arkitekter. Advokatene tenker på situasjonen når noe kan gå galt og kontrakten plutselig ikke gir svar på hvordan en hendelse skal håndteres. Da må mange tenkelige situasjoner generaliseres. Så forsøker de å formulere seg slik at det ikke går galt, altså at ikke en situasjon faller mellom alle de oppsatte stolene. Da blir språket gjerne advokatsk, inkludert, men ikke begrenset til, definisjon av “og” og “eller”, definerte termer med Store Forbokstaver og Ord Som Ser Ut Som Termer, men som mangler en definisjon. Det er derfor ingenting lar seg lese.

Advokatene er opptatt av at kontrakten skal være varig, men tenker som oftest ikke på det vakre og det nyttige.

Jeg er opptatt av å skrive slik at teksten ikke skremmer leseren, IKKE SKRIKER og ikke bruker sjargong som gjør at leseren føler seg dum. Mitt mål er å fjerne mest mulig, og sørge for at det som ikke lar seg fjerne, er lesbart. Og det skader naturligvis ikke hvis dokumentet er pent.

Tech-triks

Når jeg jobber med kontrakter, bruker jeg gjerne teknologenes prinsipper og metoder. Noen er såpass sentrale at de har fått sine egne navn: KISS, DRY, YAGNI. Dessverre sliter advokatene med alle prinsippene.

Det første prinsippet – KISS – handler om å holde det enkelt og unngå unødvendig kompleksitet. Noen kaller det Rema 1000-prinsippet. Er behovet enkelt, så holder det med én side.

DRY – om at ting skal stå ett sted – er ofte vanskelig i praksis. Enkle avtaler har sjelden et problem med duplisering, men når KISS ikke strekker til, blir DRY hardt: hva gjør man når det er behov for å ha den samme informasjonen eller reguleringen flere steder? Den enkleste løsningen er å kopiere litt her, og litt der. Problemet er bare at med tiden vil klonene både se ut og oppføre seg forskjellig. For å unngå duplisering kreves kontroll på helheten, disiplin og tid.

YAGNI handler om å la være å bygge noe for behov som ikke finnes. I kontrakter kan man falle for fristelsen til å regulere alt. I tilfelle. Resultatet blir sider opp og sider ned med reguleringer for hendelser som ingen har vurdert som sannsynlige, og som ingen kommer til å finne når noe faktisk skjer. Advokaten som skriver for hvert tenkelige tilfelle, føler seg grundig. Kunden, som skal bruke avtalen, finner ikke frem, og slutter å bruke kontrakten som et verktøy.

Copy & paste er altså forbudt, og på samme måte som teknisk gjeld, må du passe deg for kontraktsgjeld, som er lett å ta opp og vanskelig å bli kvitt.

Ta kontakt hvis du ønsker deg varige, nyttige og vakre kontraktsdokumenter. Jeg hjelper deg også hvis du sliter med kontraktsgjeld.

– Kirill

Gode løsninger med dårlige beskrivelser taper anbud

2026-08-25T00:00:00+00:00

Gjennom det siste tiåret hjalp jeg offentlige innkjøpere med å gjøre gode anskaffelser av IT-løsninger. Noen ganger samarbeidet jeg med andre advokater, andre ganger tok jeg hele prosessen fra a til å, og iblant skrev jeg også kravspesifikasjonen for det som skulle kjøpes. En god anskaffelse begynner nemlig hos kunden og krever en del av kunden gjennom hele prosessen.

Å delta i slike offentlige konkurranser, populært kalt anbud, krever mye av leverandøren: forskjellige kunder har forskjellige krav og forventninger til form, innhold og prosess.

Som innkjøpernes rådgiver og medlem av evalueringsteam så jeg gang på gang at gode leverandører og løsninger tapte anbud de kunne ha vunnet.

Anbudsprosessen

Anbudsprosessen følger en kjedelig, synkron protokoll:

Kjøperen oppdager et behov og kartlegger markedet
Kjøperen inviterer kanskje til markedsdialog for å lære mer om hva markedet kan tilby
Kjøperen lager et konkurransegrunnlag som beskriver blant annet behovet, prosessen, kriterier for valg av vinnende tilbud og frist for å levere tilbud
Kjøperen publiserer konkurransegrunnlaget
Leverandørene oppdager konkurransegrunnlaget, og leser og vurderer dette
Leverandørene sender inn sine tilbud før tilbudsfristen
Kjøperen leser mottatte tilbud, kontrollerer at formelle krav er oppfylt, og evaluerer tilbudene med utgangspunkt i definerte kriterier
Avhengig av prosess kan det være én eller flere runder med forhandlinger, oppdaterte tilbud og nye evalueringer
Når evalueringen er fullført, tildeler kjøperen kontrakten til leverandøren som har det beste tilbudet gitt definerte tildelingskriterier

Protokollen er enkel og baserer seg på skriftlighet. Selv når det er muntlige forhandlinger, brukes møtene først og fremst til å formidle og forklare det skriftlige.

Det er det skriftlige som teller. Protokollen gjør at prosessen blir forutsigbar og etterprøvbar, og leverandørene behandles likt.

Beskrivelser, beskrivelser, beskrivelser

Når bare det skriftlige teller, må du beskrive det du tilbyr detaljert nok til at leseren skal kunne trekke de riktige konklusjonene. Du må også veilede leseren i å trekke dem. Nøkkelordene blir hva og hvorfor.

Du kan ikke si at noe er brukervennlig og bra uten samtidig å komme med en beskrivelse som gjør leseren i stand til å gjøre en egen vurdering, og gjerne lede leserens tanke underveis. Evalueringen er tross alt en krevende øvelse, fordi leseren må analysere, vurdere og gi poeng til mange krav fra flere leverandører. Tildelingen av poeng skal kunne begrunnes skriftlig. Beskrivelser må derfor gjøres så leservennlige som mulig.

Beskrivelser må gjøres leservennlige. Det betyr at det er nødvendig å legge ned arbeid for å få til et godt resultat. På leverandørkonferansene pleide jeg å si at vi ikke ønsket å se “sales and marketing bullshit”. I referatet stod det at leverandørene skal unngå å skrive generell salgstekst.

I Quorum hjelper jeg gode leverandører med å forbedre kvaliteten på sine tilbud og vinne flere anbud.

Gi lyd, så tar vi en titt på ditt neste tilbud sammen. Jeg hjelper tilbudsteamet ditt med å bli bedre, slik at det blir mindre behov for meg. Og når jeg ikke lenger trengs til å lage tilbud, så kan jeg bidra med gjennomgang og kvalitetssikring før innlevering. Jeg hjelper også gjerne i dialogen med kunden når det er behov for å spørre, avklare, utfordre eller protestere.

– Kirill

Quorums nisje

2026-08-17T00:00:00+00:00

Det er et 1-1-forhold mellom Quorum og meg. Quorums nisje måtte derfor bli det jeg selv er god på og elsker å jobbe med. Og bare det. Alt de store, etablerte miljøene gjør bedre – eller jeg ikke brenner for – har jeg valgt bort. Quorum er et spesialisert teknologijuridisk byrå, ikke et juridisk landhandleri.

20 år som advokat og 30 år med kode definerer nisjen nærmest selv: snittet av det juridiske og det teknologiske, av kontraktene og koden. Regnestykket med 50 års erfaring hos en 44-åring går opp fordi årene gikk parallelt.

IT-anskaffelser

Jeg fortsetter med IT-anskaffelser i Quorum.

Det første tiåret av advokatkarrieren var jeg som regel på leverandørsiden, og hjalp store aktører med å vinne store offentlige anbud. Jeg var utleid som internadvokat i Accenture i to år.

Så byttet jeg side, og det andre tiåret var jeg mest på kundesiden. Da var jobben å hjelpe de offentlige kundene med å kjøpe løsninger og tjenester de trengte. Innsikten fra leverandørsiden var nyttig for å unngå situasjoner hvor leverandørene ble tvunget til å ta forbehold eller øke prisen for å håndtere en kundespesifikk risiko.

Som representant for kunden så jeg gang på gang at gode leverandører og løsninger tapte anbud de kunne ha vunnet.

I Quorum skal jeg derfor hjelpe gode leverandører med å forbedre kvaliteten på sine tilbud og vinne flere anbud.

Leservennlige avtaler

Kontrakter skal ikke bare skrives eller skrives ut, men først og fremst leses. Derfor må kontraktene bygges logisk, i menneskelig språk, uten det unødvendige.

Kontraktene skal dokumentere enigheten og fungere som en praktisk oppskrift på et samarbeid.

Jeg fortsetter å utvikle avtaler folk leser og forstår.

Konfliktløsning i IT-prosjekter

Statens standardavtaler definerer en mekanisme for enkel konfliktløsning i pågående prosjekter – oppnevnt uavhengig ekspert. Mekanismen er egnet til å fjerne friksjon og få prosjektet til å gli smidig igjen. En rettssak er derimot noe som skjer når alt annet har feilet.

Quorum hjelper deg å ta mekanismen i bruk, og jeg tar på meg oppdrag som oppnevnt uavhengig ekspert.

Open source

Jeg startet Quorum også for å kunne bruke fri programvare! Open source gir meg forutsigbarhet og kontroll.

Er du redd for at GPL smitter over på alt, eller at du må avsløre alle interne systemer fordi en av komponentene er AGPL?

Det er mye FUD ute og går, og mange råd blir gitt for sikkerhets skyld. Sannheten er at lisensene er regler med visse klare virkninger i definerte situasjoner. Spør Quorum, så får du et tydelig svar uten CYA.

– Kirill

Hei, verden!

2026-08-15T00:00:00+00:00

Etter nøyaktig 20 år med forskjellige advokatroller i forskjellige inkarnasjoner av Advokatfirmaet Føyen starter jeg, Kirill Miazine, noe nytt: Quorum.

I Quorum skal jeg fortsette å gi gode, praktiske råd innenfor IT-rett, offentlige anskaffelser, teknologikontrakter og open source. Jeg skal dyrke det jeg er god på, og bli enda bedre på det.

Jeg gleder meg til å kunne hjelpe gamle venner og få gode nye!

Ny modell for juridisk virksomhet

Quorum skal være et moderne og tvers igjennom brukervennlig lite juridisk byrå. Den rettslige bistanden vil leveres etter reglene i advokatloven § 66.

Modellen er blitt mulig etter at rettsrådsmonopolet ble opphevet 2025-01-01 og innebærer først og fremst at juridisk rådgivning kan leveres mer smidig.

Visse aktiviteter er likevel fortsatt forbeholdt advokater: i hovedsak kan bare advokater opptre som prosessfullmektige, og bare advokater kan håndtere klientmidler. Kommunikasjon med advokater er i tillegg spesielt vernet av bevisforbudet i tvisteloven § 22-5.

Kappe er kult, og klientmidler gir sikkert også respekt, men i Quorum ser jeg for meg andre gleder enn å kle meg ut i kappe eller leke bank, og derfor er det ikke behov for advokattittelen.

Det som ble avgjørende for å starte Quorum etter den nye modellen var lavere kompleksitet: når jeg ikke trenger advokattittelen, er det heller ikke rasjonelt å gjøre alle de ekstraaktivitetene som er nødvendige for å kunne kalle meg advokat. KISS.

Som bonus får jeg et rent firmanavn: Quorum AS.

Jeg kaster altså kappen etter 20 år, men for de aller fleste av kundene var kappen uansett bare et eksotisk plagg.

Erfaringen, integriteten og humoren lever videre!

Ta kontakt

Ønsker du å kunne få napp på flere anbud? Gjør det vondt å lese egne terms, og ønsker du deg i stedet noe logisk, enkelt og leservennlig? Er temperaturen i IT-prosjektet så høy at den påvirker leveransen? Er du redd for open source og tror at GPL smitter over på alt?

Lurer du på om Quorum er noe for deg, så ta kontakt. Kontaktinformasjon og noen andre godsaker står i dokumentet med formaliteter.

Jeg snakker også svært gjerne med advokater som vurderer å kaste kappen: en av mine motivatorer startet sin solopraksis som advokat og vurderer nå å droppe tittelen.

– Kirill