Lisensiering: bruksrettigheter, måltall og tekniske tellepunkter

Programvarelisensiering knytter en juridisk bruksavtale til teknisk målbare objekter. For administratorer er det avgjørende å ikke forveksle disse nivåene. En lisensnøkkel, en skyvisning eller en intern brukerteller kan aktivere funksjoner og måle bruk, men definerer ikke alene hva en organisasjon juridisk har lov til å bruke. ISO/IEC 19770-3 behandler digitale Entitlement-data uttrykkelig som en avbildning av bruksrettigheter og presiserer at de opprinnelige lisensvilkårene har forrang for juridiske formål (ISO/IEC 19770-3:2016).

Den operative oppgaven er derfor: å avstemme ervervede rettigheter, teknisk installerte eller tildelte rettigheter og faktisk bruk på en reproduserbar måte. Avvik kan være overforbruk, ubrukte kostnader, feil katalogfiltre, foreldreløse kontoer, passive klyngenoder, utløpte token eller ganske enkelt ulike definisjoner av det samme ordet «bruker». Artikkelen beskriver det tekniske perspektivet; kontrakts- og rettstolkning ligger hos innkjøp, lisensadministrasjon og juridisk rådgivning.

Forklaringen begynner med den kontraktsmessige bruksrettigheten og følger hvordan produkt, måltall og teknisk tellepunkt gjør den til et målt forbruk. Deretter følger tildeling, håndheving, revisjon, spesialtilfeller og gjenoppretting.

En lisens er først og fremst en bruksrettighet; teknisk synlig blir den først gjennom tildeling, målt bruk og eventuelt håndheving. Artikkelen skiller disse fire nivåene før den behandler produktmåltall og revisjoner.

Entitlement, tildeling, bruk og håndheving

En ryddig lisensoversikt holder fire uavhengige tilstander adskilt:

1. Entitlement: Hvilke bruksrettigheter er ervervet med hvilken kontrakt, hvilket produkt, måltall, scope, tidsrom og særrettighet?
2. Distribusjon/tildeling: På hvilke enheter, instanser, brukere, tenants eller funksjoner er programvare installert, aktivert eller tilordnet?
3. Bruk: Hvilke lisensrelevante objekter eller funksjoner ble faktisk brukt i den avtalte måleperioden?
4. Håndheving: Hvilken grense kontrollerer produktet teknisk, og hvordan reagerer det ved manglende forbindelse, utløp eller overskridelse?

Et eksisterende Entitlement beviser ikke korrekt tildeling; en tildeling beviser ikke bruk; lav bruk opphever ikke automatisk en navngitt brukerlisens. Omvendt kan et produkt fortsette teknisk selv om en abonnements- eller supportrettighet er utløpt. Samsvar og teknisk tilgjengelighet er derfor to ulike kontrollmål.

ISO/IEC 19770-1 spesifiserer krav til et IT-asset management-system. ISO/IEC 19770-2 standardiserer Software Identification Tags (SWID), som gjør programvare identifiserbar, men som ifølge standarden ikke krever Entitlement-reconciliation. ISO/IEC 19770-3 definerer begreper og et transportformat for Entitlements og tilhørende måltall. Samlet gir de datanivåene inventar, programvareidentitet og bruksrettighet, ikke en universell lisensberegning (ISO/IEC 19770-1:2017, ISO/IEC 19770-2:2015, ISO/IEC 19770-3:2016).

Lisensmåltall: Hva telles?

Et måltall kan bare tolkes sammen med den fullstendige kontrakten:

Den tekniske enheten må ikke gjettes ut fra produktnavnet. «Per Core» kan bety fysiske kjerner på verten, vCPU-er i VM-en eller et normalisert kjernemåltall. «Bruker» kan bety fysisk person, aktiv konto, postboks, lisensiert identitet eller avsender som sender. «Instans» kan telles som kjørende, installert, registrert eller per klyngenode. ISO/IEC 19770-3 standardiserer en Entitlement-struktur, men erstatter ikke den konkrete definisjonen i Product Terms og bestillingen (ISO/IEC 19770-3:2016).

Måltallet alene sier ennå ikke hvor det telles. Først det tekniske tellepunktet forklarer hvorfor produsentportalen, lokalt inventar og fakturaverdien kan avvike fra hverandre.

Det tekniske tellepunktet

Hvert måltall dokumenteres som en reproduserbar tellefunksjon:

Teller = Scope × objektanker × statusfilter × tidsvindu × aggregeringsregel × unntak

• Scope: organisasjon, tenant, domene, klynge, Subscription, sted eller kontrakt.
• Objektanker: uforanderlig bruker-ID, enhets-ID, VM-ID, vertsserienummer, SKU-ID eller hash – ikke bare visningsnavn.
• Statusfilter: enabled, assigned, provisioned, active, seen, mounted, running eller consumed.
• Tidsvindu: referansedato, kalendermåned, toppverdi, gjennomsnitt, rullerende vindu eller kontraktsår.
• Aggregering: Distinct, sum, maksimum, 95. persentil, minimumspakke eller trinn.
• Unntak: eksterne brukere, systemkontoer, passiv DR-instans, Trial, NFR eller kontraktsmessig gratis Use Case.

Tellepunktet er ofte et overleveringspunkt. En LDAP-import kan telle alle matchende kontoer, selv om de aldri bruker en e-postfunksjon. En gateway kan lære avsendere fra trafikken og dermed beholde slettede eller tekniske identiteter. En sky-SKU kan tildeles direkte eller indirekte via en gruppe. Microsoft Graphs licenseDetails-API leverer lisenser som er arvet direkte og gjennom gruppemedlemskap, samt enkelte tjenesteplaner og klargjøringsstatus; dette viser hvorfor en boolsk verdi «har lisens» ikke er tilstrekkelig for analysen (Microsoft Graph – List licenseDetails).

Arkitektur for et lisenssystem

Kommersielle produkter bruker ulike implementasjoner, men kan teknisk deles opp i kontrollflater. Denne modellen er en driftsmessig syntese av ISO/IEC-19770-datanivåer og dokumenterte produsentmekanismer, ikke en universell standardarkitektur:

Cisco Smart Licensing beskriver sentralisert konto- og lisensadministrasjon; Microsoft Graph eksponerer ervervede SKU-er, tildelinger og tjenesteplaner via API-er. Slike systemer gjør lisensiering til en distribuert avhengighet av identitet, skytjeneste, nettverk, TLS og tid. Et produkt kan fortsatt behandle data, men ikke hente en ny lisens; et annet kan sperre funksjoner etter en frakoblet frist. Den konkrete atferden må hentes fra produsentdokumentasjon og kontrakt (Cisco Licensing, Microsoft Graph – Get-MgSubscribedSku).

Identitetsbasert lisensiering

For navngitte brukere er katalogen en del av lisenssystemet. Et korrekt filter svarer ikke bare på «personer i OU X», men også på:

• hvilket attributt som utgjør den uforanderlige objektankeren;
• om deaktiverte, sperrede, slettede eller ennå ikke klargjorte kontoer telles;
• hvordan delte-/ressurspostbokser, tjenestekontoer, gjester, eksterne partnere og testkontoer behandles;
• om direkte og gruppebaserte tildelinger slås sammen;
• når en fjernet lisens blir tilgjengelig igjen;
• om historisk bruk eller bare beholdningen på referansedatoen er avgjørende;
• hvilke attributter produktet cacher lokalt, og når det sletter dem.

LDAP leverer oppføringer og attributter, men ingen universell definisjon av «lisensiert menneske». LDAP kan implementere scope og filter teknisk; måltallet kommer fra kontrakten. Det samme gjelder i skykataloger: SKU, tjenesteplan, assignedLicenses, klargjøringsstatus og faktisk workload-tilstand er ulike data. Microsoft Graph dokumenterer subscribedSku som et ervervet kommersielt Subscription og licenseDetails per bruker (Microsoft Graph – Get-MgSubscribedSku, Microsoft Graph – List licenseDetails).

Opprydding av foreldreløse kontoer må ikke styres direkte av lisenspress. Først kontrolleres eiere, oppbevaring, e-postruting, Legal Hold, tjenesteavhengigheter og gjenoppretting; deretter deaktiveres eller slettes identiteten kontrollert. En lisensrapport er et innspill i livssyklusen, ikke en sletteordre.

Instans-, kjerne- og kapasitetsmodeller

Virtualisering og klynger gjør det fysiske servernavnet utilstrekkelig. Et inventar trenger vert, VM/container, tildelt vCPU, fysisk CPU/kjerne, hypervisorklynge, mobilitetsregler, Edition og rolle. Hvis en VM kan flyttes mellom verter, kan hele det mulige vertsscopet være relevant avhengig av kontrakten; en fast CPU-affinitet kan dokumenteres teknisk, men er ikke automatisk kontraktsmessig anerkjent.

Editioner knytter bruksrettighet til tekniske begrensninger. Microsoft dokumenterer for eksempel for Exchange Server Editioner som blant annet skiller seg i antall samtidig monterte databaser; passive databasekopier kan også telle som monterte databaser. Product Key angir serverens Edition. Dette er et eksempel på hvordan Enforcement og kapasitetsarkitektur faller sammen, ikke en generell Exchange-lisensberegning (Microsoft – Exchange Server Editions and Versions, Microsoft – Enter Exchange Product Key).

Kapasitetsmåltall trenger et tidsforløp. En øyeblikksverdi viser verken månedstopp eller kortvarig overforbruk. For meldingssystemer er særlig aktive postbokser, interne avsendere, domener, daglig antall meldinger, gjennomstrømming, lagring og krypterte brukere vanlige tekniske tellere – om de er lisensrelevante avgjøres kun av produktrettigheten. Dashbord lagrer derfor råverdi, tid, scope, kilde og beregningsregel i stedet for bare et trafikklys.

Så snart instanser eller identiteter telles, påvirker høy tilgjengelighet, tester og migreringer også lisensmengden. Passive systemer er ikke automatisk kostnadsfrie; den aktuelle kontrakten er avgjørende.

HA, Disaster Recovery, test og migrering

Passive noder, Cold Standby, gjenopprettingsinstanser, lab, test, opplæring og midlertidige parallelle tilstander under en migrering er typiske spesialtilfeller. Teknisk kan «passiv» likevel bety at programvare er installert, replikering behandles, databaser er montert eller en lisens sjekkes ut av serveren. Kontraktsbegrepene må avbildes på observerbare tilstander.

For hvert spesialtilfelle dokumenteres:

• tillatt antall og definisjon av passive/kalde instanser;
• om test, patchkvalifisering, backupgjenoppretting eller DR-test er inkludert;
• hvor lenge samtidig gammel/ny drift er tillatt under migrering;
• om en lisens er mobil og hvilke Reassignment-/ventebetingelser som gjelder;
• om sky- og On-premises-rettigheter er koblet;
• hvilket bevis som skiller en reell DR-hendelse fra produktiv varig last;
• hvordan lisensetjenesten fungerer i et isolert gjenopprettingsnett.

Backup- og DR-konseptet inneholder derfor også lisensfiler, aktiveringsdata, lisensservere, frakoblede token, sertifikater, klokkeslett, DNS/proxy og produsentkontakter. En teknisk perfekt gjenoppretting som ikke kan aktivere sin Edition eller nødvendige funksjoner, oppfyller ikke gjenopprettingsmålet.

Utløp, Grace Period og svikt i lisensetjenesten

For Subscription-, lease- eller skymodeller er minst følgende tidtakere relevante: Entitlement-slutt, token-utløp, heartbeat, Borrow-/Checkout-varighet, frakoblet frist, Grace Period og sertifikatgyldighet. Administratorsynet registrerer absolutt tid, tidssone, synkroniseringskilde og siste vellykkede fornyelse. En feil klokke kan utløse et tilsynelatende lisensutløp eller hindre validering av et signert token.

Atferden ved utløp er produktspesifikk:

• bare advarsel eller samsvarshendelse;
• ingen ny tildeling, eksisterende bruk fortsetter;
• deaktivert Premiumfeature eller tilbakefall til mindre Edition;
• begrenset antall nye sesjoner/brukere;
• skrivebeskyttet drift;
• fullstendig tjenesteavbrudd;
• lokal Grace Period når skytjenesten ikke er tilgjengelig.

Denne reaksjonen fastslås i et testmiljø eller på grunnlag av en eksplisitt produsentkilde, ikke ved å prøve den ut i produksjon. Overvåking varsler ved den tidligste driftsmessige tidtakeren, ikke først ved kontraktsslutt. Cisco dokumenterer egne online-/offline- og kontomekanismer for Smart Licensing; andre produsenter bruker lokale lisensservere, signerte filer, USB-dongler, produktnøkler eller SaaS-Entitlements (Cisco Licensing).

Åpen kildekode: Bruksrettighet uten teknisk teller

Åpen kildekode betyr ikke bare synlig kildekode. Open Source Definition krever blant annet fri videreformidling, tilgang til kildekode, avledede verk og teknologinøytrale rettigheter. Enkelte lisenser stiller ulike vilkår for endring, videreformidling, Notices, tilgjengeliggjøring av kildekode eller patentlisenser (Open Source Initiative – Open Source Definition).

Apache License 2.0 gir opphavsretts- og patentlisenser på vilkår og krever ved videreformidling blant annet en lisenskopi, merking av endringer og bevaring av bestemte Notices. En nedlastingspris på null fjerner ikke disse pliktene (Apache License 2.0). I komponentkombinasjoner kan flere lisenser gjelde samtidig eller alternativt.

SPDX License Expressions modellerer slike tilfeller maskinlesbart: AND for kumulative plikter, OR for et lisensvalg og WITH for et unntak. Et SPDX-uttrykk identifiserer den erklærte lisenssituasjonen, men foretar ingen juridisk kompatibilitetskontroll (SPDX Specification – License Expressions). For administratorer hører lisens- og Notice-filer, SBOM/komponentliste, distribusjonsvei og egne endringer til i release- og arkivdokumentasjonen.

Administratorverktøy for reproduserbare tellere

Eksemplene viser tekniske inventar- og dokumentasjonsspørringer. Om et felt er lisensrelevant, må utledes fra Terms. Eksporter kan inneholde personopplysninger og krever tilgangsbeskyttelse, oppbevaring og formålsbegrensning.

Registrere CPU-, kjerne- og virtualiseringsinventar

Get-CimInstance Win32_ComputerSystem |
  Select-Object Name,Manufacturer,Model,NumberOfProcessors,NumberOfLogicalProcessors,HypervisorPresent
Get-CimInstance Win32_Processor |
  Select-Object DeviceID,Name,SocketDesignation,NumberOfCores,NumberOfLogicalProcessors

lscpu --extended=CPU,NODE,SOCKET,CORE,ONLINE
lscpu

Get-CimInstance leser CIM/WMI-inventardata; lscpu samler CPU-, kjerne-, tråd-, sokkel- og NUMA-data. I en VM viser de primært gjestesynet. Vertsscope, klyngeflytting, skyinstanstype og kontraktsmessige kjernefaktorer dokumenteres separat.

Telle katalogobjekter med eksplisitt scope

Get-ADUser -SearchBase 'OU=Licensed,DC=example,DC=ch' -Filter * \
  -Properties ObjectGUID,Enabled,mail,employeeType |
  Select-Object ObjectGUID,SamAccountName,Enabled,mail,employeeType |
  Export-Csv .\\licensed-users.csv -NoTypeInformation -Encoding UTF8

ldapsearch -LLL -x -H ldaps://directory.example.ch \
  -b 'ou=Licensed,dc=example,dc=ch' \
  '(&(objectClass=person)(mail=*))' entryUUID uid mail employeeType

Get-ADUser og ldapsearch leverer objektankere og attributter. Search Base, filter, paging, flerverdiattributter og deaktiverte objekter dokumenteres. Eksporten teller ingen «lisenspliktige personer» så lenge kontraktsregelen ikke er nøyaktig avbildet på disse feltene.

Lese ut sky-SKU-er og brukertildelinger

Get-MgSubscribedSku -All |
  Select-Object SkuId,SkuPartNumber,ConsumedUnits,PrepaidUnits,CapabilityStatus
Get-MgUserLicenseDetail -UserId 'admin@example.ch' |
  Select-Object SkuId,SkuPartNumber,ServicePlans

curl --fail --silent --show-error \
  --header "Authorization: Bearer $GRAPH_ACCESS_TOKEN" \
  'https://graph.microsoft.com/v1.0/subscribedSkus?$select=skuId,skuPartNumber,consumedUnits,prepaidUnits,capabilityStatus'

Get-MgSubscribedSku, Get-MgUserLicenseDetail og curl leser Microsoft Graph-data. Token lagres ikke i skript, saker eller Shell-historikk. ConsumedUnits, brukertildeling, tjenesteplan-klargjøring og faktisk brukt workload vurderes separat.

Kontrollere lisensserver eller skyendepunkt fra produktnettverket

Test-NetConnection license.example.ch -Port 443 -InformationLevel Detailed

nc -vz -w 5 license.example.ch 443

Test-NetConnection og nc kontrollerer DNS-/TCP-oppsett fra valgt opphav. En suksess beviser verken proxy, TLS, token, kontotilknytning eller lisenstransaksjonen. Produktlogger og produsentstatus leverer neste tilstandsovergang.

Sikre revisjonseksport mot endring

Get-FileHash .\\evidence\\license-inventory.csv -Algorithm SHA256
Get-FileHash .\\evidence\\entitlements.pdf -Algorithm SHA256

sha256sum ./evidence/license-inventory.csv
sha256sum ./evidence/entitlements.pdf

Get-FileHash og sha256sum oppdager senere byteendringer. I tillegg dokumenteres opprettelsestid, spørringsscope, verktøy-/API-versjon, Query, tidssone, eksportør og sikker lagring. En hash bekrefter ikke faglig fullstendighet.

Kontrollere lisens- og aktiveringshendelser i perioden

$since = [datetime]'2026-08-01T00:00:00Z'
Get-WinEvent -FilterHashtable @{LogName='Application'; StartTime=$since} |
  Where-Object Message -Match 'licen[cs]e|activation|entitlement' |
  Select-Object TimeCreated,Id,ProviderName,LevelDisplayName,Message

journalctl --since '2026-08-01 00:00:00 UTC' \
  --output short-iso-precise --no-pager \
  | grep -Ei 'licen[cs]e|activation|entitlement'

Get-WinEvent, journalctl og grep filtrerer lokale hendelser. Produsentlogger kan bruke strukturerte koder i stedet for engelske tekstmeldinger; Provider, Event-ID eller definerte felter foretrekkes. Tid, rotasjon og sentral loggkopi hører med i funnet.

Av Entitlement, tellepunkt og driftstilstand oppstår revisjonsbeviset. Det må reproduserbart vise hva som ble kjøpt, tildelt, installert og faktisk brukt.

Revisjons- og driftsbevis

Et reproduserbart lisensbevis inneholder:

• kontrakts-/bestillingsreferanse, produkt/SKU, måltall, mengde, scope, løpetid og særrettigheter;
• programvare- og maskinvareinventar med uforanderlige ID-er, Edition, versjon og klyngerelasjon;
• direkte, gruppebaserte og automatiske tildelinger med kilde og klargjøringsstatus;
• råmåleverdier og beregningsregel per tidsvindu;
• unntak med begrunnelse, Owner, utløpsdato og teknisk kontroll;
• HA/DR/test/migrering som egen populasjon;
• produktvisning, API-/CLI-eksport og uavhengig motberegning;
• tid, tidssone, Query/verktøyversjon, hash og beskyttet lagring.

Avvik klassifiseres: datafeil (duplikater, gamle kontoer), modellfeil (feil måltall), prosessfeil (lisens ikke fjernet etter fratredelse), teknisk feil (synkronisering/token/server) eller manglende Entitlement. Først dette skillet viser om svaret er opprydding, konfigurasjon, kontraktsavklaring, anskaffelse eller Incident Response.

Teknisk utvikling av lisensiering

Lokale produktnøkler og dongler knyttet først bruksrettigheten tett til én datamaskin. Nettverkslisensservere innførte delte pooler og Concurrent Leases; virtualisering krevde nye vert-, kjerne- og mobilitetsregler. Abonnementer og SaaS flyttet Entitlements til skykontoer, identitetsgrupper og tjenesteplaner. Cisco Smart Licensing og Microsoft Graph illustrerer sentrale konto-/API-modeller, mens ISO/IEC 19770 standardiserer SWID- og Entitlement-data (Cisco Licensing, Microsoft Graph – List licenseDetails, ISO/IEC 19770-2:2015, ISO/IEC 19770-3:2016).

Parallelt gjorde åpen kildekode teknisk aktivering overflødig for mange komponenter, men ikke lisensvilkår. SPDX etablerte maskinlesbare kortidentifikatorer og uttrykk for programvareforsyningskjeder. Dermed flyttet administratoroppgaven seg fra «registrere nøkkel» til et dataproblem om kontrakt, identitet, ressurs, løpetid, telemetri og programvaresammensetning. Mottiltaket er det samme som ved overvåking: klare objektankere, eksplisitte tidsvinduer, rådata og reproduserbare beregninger.

Kilder

• ISO/IEC 19770-3:2016 – Entitlement Schema
• ISO/IEC 19770-1:2017 – IT Asset Management Systems
• ISO/IEC 19770-2:2015 – Software Identification Tag
• Microsoft Graph – List licenseDetails
• Cisco – Licensing
• Microsoft Graph PowerShell – Get-MgSubscribedSku
• Microsoft – Exchange Server Editions and Versions
• Microsoft – Enter Exchange Server Product Key
• Open Source Initiative – Open Source Definition
• Apache Software Foundation – Apache License 2.0
• SPDX Specification 3.0.1 – License Expressions
• Microsoft Learn – Get-CimInstance
• Linux man-pages – lscpu
• Microsoft Learn – Get-ADUser
• OpenLDAP – ldapsearch
• Microsoft Graph PowerShell – Get-MgUserLicenseDetail
• curl – command line manpage
• Microsoft Learn – Test-NetConnection
• OpenBSD – nc
• Microsoft Learn – Get-FileHash
• GNU Coreutils – SHA-2 utilities
• Microsoft Learn – Get-WinEvent
• systemd – journalctl
• GNU Grep – Manual