En softwareleverandør varsler en licensaudit. Nogle uger senere kommer en rapport, der viser, at kunden bruger flere licenser, end der er betalt for, og et krav om efterbetaling. Kunden er uenig, men ved ikke helt, hvad der er talt, eller hvordan.
Tvisten handler om aftalen og om tal. Hvordan licensaftalen og auditklausulen skal fortolkes, er en juridisk vurdering. Tallene derimod er tekniske, og de er ofte mere usikre, end auditrapporten giver indtryk af.
Hvad en audit typisk bygger på
En audit kan bygge på forskellige kilder:
- Leverandørens scripts eller værktøjer, som kunden kører i sit eget miljø, og som sender data tilbage.
- Kundens egne oversigter, fx et regneark med installationer, servere og brugere.
- Data fra leverandørens egen platform, når softwaren kører som abonnement i skyen.
- Oplysninger fra tredjepartsværktøjer til styring af softwareaktiver.
Hver kilde har sine egne begrænsninger. Et script måler det, det er skrevet til at måle, på det tidspunkt, det blev kørt. Det kan tælle installationer, der ikke bruges, eller miljøer, der ikke er omfattet af kravet.
Tællemetoden er kernen
Licensmodeller er ofte komplicerede. Der kan tælles pr. bruger, pr. enhed, pr. processorkerne, pr. server eller efter samtidige brugere. I virtualiserede miljøer og i skyen kan det være uklart, hvad der er “en server” eller “en installation”.
Tvister handler derfor ofte om:
- om testmiljøer, udviklingsmiljøer og backup tælles med,
- om virtuelle maskiner tælles efter den fysiske vært eller den enkelte maskine,
- om inaktive eller lukkede brugerkonti tælles,
- om servicekonti og tekniske konti tælles som brugere,
- om tidligere købte licenser kan flyttes mellem miljøer.
Advokaten bør tidligt få beskrevet, hvilken tællemetode leverandøren har brugt, og sammenholde den med aftalens ordlyd. Uenighed om tallene er ofte en skjult uenighed om metoden.
Før data afleveres
Det er klogt at forholde sig til auditten, før kunden afleverer data. Overvej:
- Hvad kræver auditklausulen? Ikke alle klausuler forpligter kunden til at køre leverandørens scripts eller give adgang til hele miljøet.
- Hvad indsamler scriptet? Kunden bør vide, hvilke oplysninger der sendes til leverandøren, og om der indgår personoplysninger eller fortrolige oplysninger.
- Kan resultatet kontrolleres? Kunden bør gemme en kopi af alt, hvad der afleveres, med tidspunkt.
- Er miljøet repræsentativt? Hvis auditten falder på et tidspunkt med ekstraordinær brug, fx en migrering, bør det dokumenteres.
En skriftlig aftale om rammerne for auditten kan gøre det lettere at håndtere en senere uenighed. → Bevissikring uden retssag
Kundens egen dokumentation
Kundens stærkeste kort er ofte egen dokumentation af, hvad der er købt, og hvad der er i brug:
- ordrebekræftelser, fakturaer og licenscertifikater,
- tidligere aftaler om ændringer eller overgang til nye licensmodeller,
- konfiguration af virtuelle miljøer, fx begrænsninger på hvilke værter en maskine kan køre på,
- logs over brugerkonti, herunder oprettelse og lukning,
- egne opgørelser fra værktøjer til styring af softwareaktiver.
Konfigurationer ændres løbende. Er en bestemt opsætning afgørende for tællingen, bør den dokumenteres for den periode, kravet dækker, og ikke kun som den ser ud i dag. Historikken kan ligge i ændringslogs, i backup eller i dokumentation fra IT-leverandøren.
Perioden
Et krav om efterbetaling dækker ofte en periode bagud. Leverandøren kan have målt på ét tidspunkt og regnet tilbage. Det er relevant at spørge, om brugen faktisk var den samme i hele perioden. Data om, hvornår servere blev sat op, og hvornår brugere blev oprettet, kan vise, at brugen var lavere tidligere.
Abonnementer i skyen
Når softwaren leveres som abonnement, ligger brugsdata ofte hos leverandøren. Kunden ser kun det, der vises i administrationsportalen. Leverandøren kan derfor have et informationsforspring. Det er relevant at spørge, hvilke data leverandøren bygger kravet på, og om kunden kan få et udtræk af de samme data.
Kunden bør selv eksportere oversigter over brugere, tildelte licenser og aktivitet med jævne mellemrum, hvis en tvist er under opsejling. Portalen viser typisk kun den aktuelle tilstand, ikke historikken. → SaaS-tvister: oppetid, SLA og logdata
Forhandling før sag
Mange licenstvister ender i forhandling. Også her er dokumentation vigtig. En kunde, der kan vise en alternativ opgørelse med en beskrevet metode, står stærkere end en kunde, der blot afviser leverandørens tal. Omvendt kan en leverandør, der fremlægger rå data og beregning, lettere opnå en aftale.
Når tvisten bliver til en sag
Kommer sagen for retten, kan begge parter have behov for en uafhængig vurdering af tallene. Typiske temaer er, om tællingen er udført korrekt efter den beskrevne metode, og hvilke tal der kommer ud af en anden metode. Det er vigtigt, at spørgsmålene adskiller det tekniske, hvad der er installeret og brugt, fra det juridiske, hvad der er omfattet af aftalen. → Syn og skøn i IT-sager
Er der store mængder data, kan parterne aftale en fælles metode eller en fælles sagkyndig til at lave opgørelsen. → Fælles IT-sagkyndig aftalt mellem parterne
Når klienten er leverandøren
Repræsenterer advokaten leverandøren, skal auditresultatet kunne forklares og efterprøves. Det kræver:
- en beskrivelse af scriptets funktion og version,
- de rå data, som scriptet indsamlede,
- en beregning, der viser vejen fra rå data til kravet,
- en begrundelse for den valgte tællemetode med henvisning til aftalen.
En rapport, der kun viser slutresultatet, er let at anfægte.
Spørgsmål til leverandørens auditor
Når auditrapporten foreligger, kan kunden stille konkrete spørgsmål, før kravet forhandles:
- Hvilke kilder bygger opgørelsen på, og hvornår er data indsamlet?
- Hvilken version af scriptet eller værktøjet er brugt, og hvad registrerer det?
- Hvilken tællemetode er anvendt, og hvor i aftalen er den forankret?
- Hvordan er test-, udviklings- og backupmiljøer behandlet?
- Er inaktive konti og servicekonti talt med?
- Kan kunden få de rå data og beregningen, som rapporten bygger på?
Svarene viser ofte, hvor uenigheden reelt ligger. En IT-sagkyndig kan derefter genberegne opgørelsen med leverandørens metode og med en alternativ metode, så forskellen kan forklares. Den sagkyndige kan ikke afgøre, hvilken metode aftalen foreskriver. → Skabelon: spørgsmål til modpartens sagkyndige
Typiske fejl
- At køre leverandørens script uden at vide, hvad det indsamler.
- At aflevere data uden at gemme en kopi.
- At diskutere antal licenser uden at være enige om tællemetoden.
- At dokumentere miljøet, som det ser ud nu, og ikke i perioden.
- At overse, at testmiljøer og servicekonti behandles særskilt i aftalen.
Spørgsmål til skønsmanden
- Hvilke installationer og brugere fandtes i miljøet i den angivne periode?
- Hvordan var de virtuelle miljøer konfigureret, og hvad betyder det for antallet af enheder efter den beskrevne metode?
- Kan leverandørens opgørelse genskabes ud fra de rå data?
- Hvor mange brugerkonti var aktive, og hvor mange var tekniske eller lukkede?
Tjekliste
- ☐ Auditklausulen og licensmodellen er gennemgået
- ☐ Det er afklaret, hvad leverandørens script indsamler
- ☐ Kopi af alt afleveret materiale er gemt med tidspunkt
- ☐ Tællemetoden er beskrevet og sammenholdt med aftalen
- ☐ Miljøets konfiguration er dokumenteret for hele perioden
Når kravet bygger på tekniske målinger, som kunden ikke selv kan efterprøve, kan en IT-sagkyndig gennemgå data og metode, før der forhandles om beløbet.
→ Send en sag · Tlf. 70 13 63 23 · IT-sagkyndig bistand til advokater hos Nielco IT
