Kode og dokumentation

Open source-licenser: ved I, hvad appen bygger på?

En AI-bygget app består sjældent kun af virksomhedens egen kode. Pakker, kopierede eksempler, ikoner, fonte, workflows og færdige komponenter kan have forskellige vilkår. Et vedligeholdt komponentoverblik gør det muligt at finde oprindelsen, bevare nødvendige notices og få tvivl vurderet, før appen deles med kunder eller bliver kritisk for driften.

Udgivet 5. oktober 2026 · Ca. 11 minutters læsetid

Det korte svar

Lav et inventar over de komponenter og det materiale, appen faktisk indeholder. Registrér navn, version eller commit, kilde, licens, placering i appen og hvem der har vurderet brugen. Generér gerne en maskinlæsbar SBOM for dependencies, men gennemgå også kodeudsnit, billeder, fonte og andre dele, som et pakkeværktøj ikke nødvendigvis ser. Ukendt oprindelse er et fund, der skal afklares — ikke en licenstype.

Et automatisk licensnavn er dokumentation, ikke en juridisk konklusion. Metadata kan mangle, være upræcis eller dække pakken anderledes end det materiale, I faktisk distribuerer. Ved tvivl om rettigheder eller forpligtelser bør den konkrete kode, licenstekst og brug vurderes professionelt.

Kortlæg mere end package.json

Dependency-filer er et godt startpunkt, men de er ikke hele appen. Gennemgå de steder, hvor kode og andre aktiver kan være kommet ind — også selv om AI-værktøjet har skrevet eller foreslået dem.

Kilde	Eksempler	Kontrol
Pakker	Direkte og transitive npm-, NuGet-, Python- eller andre dependencies	Manifest, lockfile, dependency graph og faktisk build
Kildekode	Kopierede snippets, skabeloner, genererede filer og vendored kode	Filhistorik, kilde-URL, header, commit og licenstekst
Brugerflade	Ikoner, fonte, illustrationer, billeder og designsystemer	Oprindelig fil, købs- eller licensbevis og eventuelle krediteringskrav
Build og drift	GitHub Actions, container-images, plugins og CLI-værktøjer	Fast version, udgiver, kilde og vilkår for brug eller distribution
Virksomhedens egen kode	Kode skrevet af medarbejdere, leverandører og AI-assisterede forløb	Aftale, repositoryhistorik, forfatter og dokumenteret overdragelse

Skeln mellem appens licens og komponenternes licenser

Repositoryets egen licens fortæller, hvad andre må gøre med virksomhedens kode. Den ændrer ikke automatisk vilkårene for tredjepartskomponenter inde i projektet. Omvendt bliver en dependency ikke virksomhedens egen kode, fordi den ligger i et privat repository.

Egen kode: Beslut bevidst om den er intern, kundespecifik eller skal udgives med en licens.
Tredjepart: Bevar den oprindelige licens, copyright-meddelelser og relevante NOTICE-filer sammen med komponentens registrering.
Ingen licens: Et offentligt repository uden licens er ikke automatisk frit at kopiere og genbruge. GitHub beskriver, at almindelige ophavsretsregler som udgangspunkt gælder.
Flere licenser: Registrér det præcise udtryk og den valgmulighed eller kombination, der faktisk gælder. Skriv ikke bare “open source”.

SPDX-id’er som MITog udtryk med AND,OR ellerWITH giver et standardiseret sprog. De fortolker ikke i sig selv, om jeres konkrete brug opfylder vilkårene.

Brug en SBOM som versionsbundet komponentliste

En Software Bill of Materials er et maskinlæsbart overblik over softwarekomponenter og relationer. NIST anbefaler at bevare oprindelsesdata for komponenterne i hver release. Knyt derfor inventaret til den commit og det build, der faktisk blev udgivet, frem for kun at eksportere den aktuelle udviklingsbranch.

1. Vælg omfang. Notér repository, projektmapper, package managers, runtime, container og andre dele, som værktøjet skal se.
2. Generér i buildet. Gem SBOM’en som et versionsbundet releaseartefakt, når den valgte løsning understøtter det.
3. Kontrollér dækning. Sammenlign med lockfiles, buildoutput og kendte komponenter. Registrér bevidst det, som værktøjet ikke finder.
4. Bevar kilden. Gem version eller commit, leverandør, downloadsted, licenstekst og eventuelle notices.
5. Opdatér ved release. En gammel SBOM beskriver en gammel sammensætning og bør ikke præsenteres som aktuel.

GitHub kan eksportere repositoryets dependency graph i SPDX-format. Eksporten kan indeholde versioner, pakke-id’er, licenser og transitive stier for det, GitHub har registreret. GitHub dokumenterer samtidig, at registreringen afhænger af understøttede manifest- og lockfiler eller indsendte dependency-data. Gennemgå derfor eksporten i stedet for at antage, at den er komplet.

Gør hvert fund til en konkret beslutning

Licensarbejdet er ikke færdigt, når alle rækker har et navn. En ansvarlig skal kunne forklare, om komponenten bruges internt, leveres til kunden, indgår i en app-download eller kun bruges under build. Den faktiske brug og den konkrete licenstekst afgør, hvilke handlinger der er relevante.

Kendt og accepteret: Registrér vurderingen, og sørg for at nødvendige tekster og notices følger den relevante levering.
Ukendt licens: Find original kilde og licenstekst. Et pakkenavn eller en kommentar fra AI’en er ikke tilstrækkeligt bevis.
Uklare vilkår: Afgræns hvordan komponenten bruges og distribueres, og få spørgsmålet vurderet før release.
Ikke accepteret: Erstat eller fjern komponenten kontrolleret, opdatér lockfile og SBOM, og test de berørte brugerrejser.

Behandl ukendt AI-kode som et oprindelsesproblem

Et AI-værktøj kan foreslå kode uden en brugbar kildehenvisning. Det gør ikke koden dokumenteret. Når et forslag er stort, særligt genkendeligt eller indeholder headers, kommentarer, licenstekst eller navne fra et andet projekt, skal oprindelsen afklares før merge.

Bed om små, afgrænsede ændringer, så nye filer og større kodeblokke er synlige i diffen.
Registrér den originale URL og commit, når en officiel dokumentationsprøve eller et open source-eksempel genbruges.
Fjern aldrig copyright-, licens- eller NOTICE-tekst for at få koden til at se intern ud.
Søg efter markante kommentarer, funktionsnavne eller længere tekststykker, hvis oprindelsen er uklar.
Omskriv ikke blot ukendt kode kosmetisk. Afklar rettigheden, erstat den med dokumenteret kode eller få konkret rådgivning.

Læg kontrollen i ændringsflowet

En årlig oprydning bliver hurtigt forældet. Gør nye komponenter og ukendt kode synlige i pull requesten, mens ændringen stadig er lille og kan afvises uden at ramme produktion.

Vis ændringen: Manifest, lockfile, vendored kode, assets, actions og container-baseimage skal reviewes sammen med funktionen.
Kør automatiske kontroller: Brug et værktøj, der passer til projektets økosystem, men bevar manuel vurdering af ukendte eller særlige vilkår.
Kræv en ejer: Fund skal have en navngiven beslutningstager og må ikke ende som en permanent, ignoreret rapport.
Gem beslutningen: Notér kilde, brug, vurdering, eventuelle handlinger og dato uden at kopiere unødigt tredjepartsmateriale.
Bevis leverancen: Kontrollér at relevante licens- og NOTICE-filer faktisk findes i den pakke, download eller kundeleverance, de vedrører.

Typiske fejl

Alt fra GitHub kaldes frit: Et offentligt repository er ikke nødvendigvis udgivet med en licens, der tillader genbrug.
Kun direkte packages registreres: Transitive dependencies og komponenter fra buildet mangler i overblikket.
Scanneren bliver facit: Manglende eller forkert metadata bliver behandlet som en sikker konklusion.
NOTICE-filer ryddes væk: Vigtig dokumentation forsvinder under minificering, pakning eller manuel oprydning.
Repositoryets egen licens bruges på alt: Tredjepartskode mister sin oprindelige sammenhæng og dokumentation.
AI-kode antages at være egen kode: Ingen kan bagefter forklare kilden til store, genkendelige kodeblokke eller assets.
SBOM’en ligger kun på en laptop: Listen kan ikke forbindes med den release, kunden eller driften faktisk bruger.

Tjekliste før appen deles eller sættes i drift

☐ Direkte og transitive dependencies er registreret med version eller commit.
☐ Kodeudsnit, skabeloner, vendored kode, fonte, ikoner og andre assets har kendt oprindelse.
☐ Hver tredjepartskomponent har kilde, licensmetadata og en navngiven vurdering.
☐ Ukendt, manglende eller specialtilpasset licens er behandlet som et åbent fund.
☐ Repositoryets egen licens er bevidst valgt og forveksles ikke med dependencies.
☐ Copyright-, LICENSE- og NOTICE-filer bevares, hvor den konkrete brug kræver det.
☐ En SBOM eller tilsvarende komponentliste er knyttet til den faktiske release.
☐ SBOM’ens dækning er sammenlignet med lockfiles, build og kendte manuelle komponenter.
☐ Nye dependencies, actions, baseimages og større kodeblokke er synlige i pull request-review.
☐ Ikke-accepterede komponenter kan erstattes uden at efterlade gammel kode eller metadata.
☐ Tvivl om rettigheder eller forpligtelser bliver vurderet før kundelevering eller offentliggørelse.

Relaterede guides

Afhængigheder, lockfiles og kontrollerede opdateringer Sikkerhedsscanning af kode, secrets og dependencies Pull requests, review og beskyttelse af main Driftsdokumentation, ejerskab og overdragelse Se hele guidebiblioteket

Officielle kilder

Licenser og leveringsformer skal vurderes konkret. Kilderne nedenfor dokumenterer komponentinventar, SPDX-format, licensmetadata og repositoryadfærd; de erstatter ikke juridisk rådgivning om en bestemt komponent eller aftale.