Open Source-politik

Work4it

Version: 1.0 Dato: 28.06.2026 Ansvarlig: Mike Henriksen Godkendt af: Mike Henriksen

1. FORMÅL OG SCOPE

1.1 Formål

Denne politik fastlægger retningslinjer for brug, bidrag til og distribution af open source software (OSS) hos Work4it. Formålet er at:

Sikre overholdelse af open source licensvilkår

Beskytte virksomhedens intellektuelle ejendomsrettigheder

Minimere juridiske og kommercielle risici

Muliggøre effektiv og ansvarlig brug af open source komponenter

1.2 Scope

Politikken gælder for:

Al software udviklet af eller for Work4it

Alle medarbejdere, konsulenter og kontraktansatte udviklere

Al brug af open source komponenter i produkter, services og intern infrastruktur

Bidrag til eksterne open source projekter

2. ROLLER OG ANSVAR

2.1 Open Source Compliance Officer (OSCO)

Rolle: CTO/Teknisk Ansvarlig Ansvar:

Godkende eller afvise brug af open source komponenter

Vedligeholde liste over godkendte/forbudte licenser

Føre tilsyn med compliance processer

Gennemgå og opdatere denne politik minimum årligt

Håndtere escalerede sager og licenstvivl

2.2 Udviklere

Ansvar:

Anmode om godkendelse før brug af nye open source komponenter

Dokumentere alle anvendte open source komponenter

Overholde licensvilkår for godkendte komponenter

Rapportere potentielle compliance issues

Gennemføre periodiske dependency audits

2.3 Ledelse

Ansvar:

Allokere ressourcer til compliance aktiviteter

Sikre at politikken efterleves

Inkludere open source compliance i projektplanlægning

3. LICENSKLASSIFICERING

3.1 Pre-godkendte licenser (Grøn kategori)*

Følgende licenser er pre-godkendt til brug uden yderligere godkendelse:

Permissive licenser:

MIT License

Apache License 2.0

BSD 2-Clause / 3-Clause License

ISC License

Python Software Foundation License

Zlib License

Krav: Attribution/copyright notices skal bevares i kode og dokumentation.

3.2 Betinget godkendte licenser (Gul kategori)

Følgende licenser kræver review og godkendelse fra OSCO:

Weak copyleft:

GNU Lesser General Public License (LGPL) 2.1/3.0

Mozilla Public License (MPL) 2.0

Eclipse Public License (EPL) 1.0/2.0

Common Development and Distribution License (CDDL)

Vurderingskriterier:

Anvendelsesmåde (linking, modification, distribution)

Produkttype (SaaS web-platform, mobil app, backend services)

Isolation fra proprietær kode

Source code disclosure krav

3.3 Forbudte/kritiske licenser (Rød kategori)

Følgende licenser er som udgangspunkt FORBUDT uden skriftlig godkendelse fra både OSCO og direktion:

Strong copyleft:

GNU General Public License (GPL) 2.0/3.0

GNU Affero General Public License (AGPL) 3.0

Creative Commons ShareAlike (CC-BY-SA)

Open Software License (OSL)

European Union Public License (EUPL) med copyleft

Begrundelse: Risiko for at skulle frigive proprietær source code eller begrænse kommerciel udnyttelse.

3.4 Ukendte/ubeslægtede licenser

Software uden licensinformation eller med custom/proprietære licenser kræver juridisk review og må IKKE anvendes før skriftlig godkendelse.

4. GODKENDELSESPROCES

4.1 Pre-implementation review

Før integration af open source komponenter skal udvikler:

Identificere licens:

Verificer licenstype i package metadata, LICENSE fil eller NOTICE fil

Tjek for multiple licenses eller dual licensing

Udfylde anmodningsformular med:

Komponent navn og version

Licenstype(r)

Anvendelsesformål (runtime dependency, dev tool, build tool, etc.)

Hvordan komponenten integreres (direkte linking, subprocess, API call, etc.)

Hvilke produkter/projekter der påvirkes

Alternative løsninger overvejet

Indsende til OSCO:

Grøn kategori: Automatisk godkendt, dokumentér i SBOM

Gul kategori: Afvent skriftlig godkendelse fra OSCO (maks 5 hverdage)

Rød kategori: Escaleret review, juridisk rådgivning kan være nødvendig

4.2 Godkendelseskriterier

OSCO vurderer:

License compatibility: Er licensen kompatibel med vores produktlicenser?

Copyleft risk: Risiko for source code disclosure krav?

Commercial use: Begrænser licensen kommerciel udnyttelse?

Patent grant: Indeholder licensen patent grants eller termination clauses?

Warranty implications: Påvirker det vores warranties til investorer/kunder?

Maintenance risk: Er projektet aktivt vedligeholdt?

Security: Kendte sårbarheder (CVE check)?

4.3 Dokumentation af godkendelse

Godkendte komponenter registreres i Software Bill of Materials (SBOM) med:

Komponent navn, version, licenstype

Anvendelsesdato og godkender

Produkter/projekter hvor komponenten anvendes

Særlige compliance krav (attribution, notices, etc.)

5. COMPLIANCE KRAV

5.1 Attribution og notices

For alle godkendte komponenter skal:

NOTICE eller CREDITS fil vedligeholdes med alle attributions

Licensinformation inkluderes i produktdokumentation hvor relevant

Third-party notices gøres tilgængelige for slutbrugere (f.eks. i "Om Work4it" eller "Juridisk" sektion)

5.2 Source code disclosure

For komponenter med copyleft-krav:

Modificeret kode skal stilles til rådighed efter licensvilkår

Opret separate repositories for GPL/AGPL komponenter

Implementer tydelig separation mellem proprietær og copyleft kode

Dokumentér build instructions hvor påkrævet

5.3 Modification tracking

Ved modification af open source komponenter:

Dokumentér ændringer i commit messages og CHANGELOG

Overhold licensens krav til modification notices

Opbevar original licensfil sammen med modified version

Overvej at contribute fixes tilbage til upstream projekt

6. SOFTWARE BILL OF MATERIALS (SBOM)

6.1 Vedligeholdelse

SBOM opdateres løbende ved tilføjelse/opdatering/fjernelse af komponenter

Automatiserede tools anvendes hvor muligt (npm audit, OWASP Dependency-Check, osv.)

SBOM gennemgås og valideres minimum kvartalsvis

SBOM arkiveres for hver produktversion

6.2 Indhold

SBOM skal som minimum indeholde:

Komponent navn og version

Licenstype(r)

Download URL / repository

Anvendelsesformål

Direct vs. transitive dependency

Godkendelsesdato og -person

Kendte sårbarheder (CVE)

6.3 Format

SBOM vedligeholdes i maskinlæsbart format (CycloneDX anbefales).

7. BIDRAG TIL OPEN SOURCE PROJEKTER

7.1 Godkendelse af bidrag

Medarbejdere der ønsker at bidrage til eksterne open source projekter skal:

For mindre bug fixes og dokumentation:

Informere OSCO (ingen godkendelse påkrævet)

Sikre at bidrag ikke indeholder proprietær kode eller forretningshemmeligheder

For væsentlige bidrag (ny funktionalitet, arkitekturændringer):

Indhente skriftlig godkendelse fra OSCO

Verificer at bidrag ikke kompromitterer konkurrencefordele

Afklar IP-rettigheder (company assignment vs. personal contribution)

7.2 Contributor License Agreements (CLA)

Ved underskrivelse af CLA for eksterne projekter:

Individuelle CLAs underskrives personligt af medarbejder

Corporate CLAs kræver godkendelse fra direktion

OSCO vedligeholder register over underskrevne CLAs

7.3 Publicering af egne projekter

Udgivelse af intern kode som open source kræver:

Skriftlig godkendelse fra ejer/direktion

IP review: Sikring af at koden ikke indeholder kundekode eller forretningshemmeligheder

Valg af passende license (som udgangspunkt MIT License)

Etablering af contribution guidelines og governance

8. LEVERANDØR- OG KONSULENTKONTRAKTER

8.1 Kontraktuelle krav

Kontrakter med eksterne udviklere skal indeholde:

Forpligtelse til at overholde Work4it's Open Source Policy

Krav om disclosure af alle anvendte open source komponenter

Warranties om at leverancer ikke krænker third-party IP rettigheder

Warranties om at ingen GPL/AGPL kode er anvendt (medmindre godkendt)

8.2 Pre-delivery review

Ved modtagelse af kode fra eksterne udviklere:

Gennemfør license scan med automated tools

Verificer SBOM fra leverandør

Validér overholdelse af license policies

Dokumentér findings og obtain remediation hvor nødvendigt

9. AUDIT OG MONITORING

9.1 Løbende monitoring

Automated scanning: Dependency checks integreres i CI/CD pipeline (GitHub Actions, Firebase hosting deployment, etc.)

Vulnerability monitoring: CVE alerts for anvendte komponenter

License drift: Automatisk detection af licenseændringer i dependencies

Quarterly reviews: Gennemgang af SBOM og compliance status

9.2 Periodisk audit

Minimum årligt gennemføres:

Komplet source code scan af alle repositories

Validering af SBOM accuracy

Review af compliance processer

Assessment af nye risici og opdatering af policy

9.3 Pre-release audit

Før release af nye produktversioner:

Fuld license compliance audit

Generering af third-party notices

Validering af attribution requirements

Sign-off fra OSCO

10. M&A, INVESTERING OG DUE DILIGENCE

10.1 Forberedelse til due diligence

Vedligehold løbende:

Aktuel og komplet SBOM

Dokumentation af license reviews og godkendelser

Compliance audit rapporter

10.2 Warranties

Sørg for at kunne dokumentere:

Ingen GPL/AGPL kode i business-critical komponenter (medmindre disclosed)

Overholdelse af alle license obligations

Ingen krænkelser af third-party IP rettigheder

Ret til kommerciel udnyttelse af alle komponenter

11. NON-COMPLIANCE OG REMEDIATION

11.1 Rapportering

Potentielle compliance violations skal straks rapporteres til OSCO.

11.2 Remediation proces

Ved konstatering af non-compliance:

Risikovurdering:

Severity (kritisk, høj, medium, lav)

Eksponering (production, development, internal)

Legal implications

Remediation plan:

Remove: Fjern komponenten og erstat med alternativ

Replace: Udskift med license-compatible alternativ

Comply: Implementer licensens krav (hvis acceptable)

Negotiate: Kontakt rettighedshaver for dual license eller exemption

Implementation:

Prioriteret efter severity

Tracking i issue tracker (GitHub Issues, Jira, eller lignende)

Dokumentation af remediation

Verification:

Validér at issue er løst

Opdatér SBOM

Dokumentér learnings og opdatér policy/processer

11.3 Disciplinære konsekvenser

Bevidst eller gentagen non-compliance kan medføre disciplinære sanktioner.

12. TRÆNING OG AWARENESS

12.1 Onboarding

Alle nye udviklere skal:

Gennemgå denne policy

Gennemføre open source compliance training

Bekræfte forståelse skriftligt

12.2 Løbende træning

Årlig refresher training for alle udviklere

Updates ved væsentlige policyændringer

Awareness campaigns ved kritiske compliance issues i branchen

13. TOOLS OG RESSOURCER

13.1 Anbefalede tools

SBOM generation: CycloneDX, SPDX tools, npm sbom

License scanning: FOSSA, FOSSology, licensee

Vulnerability scanning: npm audit, Snyk, GitHub Dependabot, OWASP Dependency-Check

License compatibility: LicenseFinder, scancode-toolkit, ClearlyDefined

13.2 Ressourcer

Open Source Initiative (OSI): https://opensource.org/

SPDX License List: https://spdx.org/licenses/

Choose a License: https://choosealicense.com/

TLDRLegal: https://tldrlegal.com/

14. POLITIKOPDATERING

Denne politik gennemgås og opdateres minimum årligt eller ved:

Væsentlige ændringer i forretningsmodel

Nye produkttyper eller distributionsmodeller

Ændringer i relevant lovgivning

Brancheændringer i license best practices

Versionsstyring:

Alle ændringer dokumenteres i changelog

Tidligere versioner arkiveres

Medarbejdere informeres om væsentlige ændringer

15. KONTAKT

Spørgsmål til denne politik: Open Source Compliance Officer (CTO/Teknisk Ansvarlig) Email: Mikehenriksen85@gmail.com

Godkendelse af open source komponenter: Mikehenriksen85@gmail.com

Rapportering af compliance issues: Mikehenriksen85@gmail.com