Afklaring: Licensmæssige konsekvenser ved offentliggørelse

[zorp]

Titel

Afklaring: Licensmæssige konsekvenser ved offentliggørelse af patches og Helm charts på tværs af licenstyper

Beskrivelse

Vi ønsker at offentliggøre både vores tilpasninger (patches) og vores Helm chart som open source.

Tilpasningerne er baseret på eksisterende open source-software, som installeres og konfigureres via Helm charts, og som efterfølgende er blevet modificeret for at fungere i vores miljø.

Et konkret eksempel er software licenseret under BSD 3-Clause (fx Open WebUI):
https://github.com/open-webui/open-webui/blob/main/LICENSE

Samtidig er det forventningen, at løsningen kan inkludere komponenter med andre licenstyper (fx GPL, MPL, MIT/Apache).

Spørgsmål

Hvordan skal vi generelt forstå og håndtere licensforpligtelser i dette scenarie, hvor vi offentliggør både patches og deployment-setup på tværs af forskellige open source-licenser?

Vi ønsker særligt afklaret:

• Hvornår patches og ændringer betragtes som et “afledt værk”

• Hvilken betydning det har for forpligtelser under forskellige licenstyper (fx BSD/MIT, MPL, GPL, AGPL)

• Om der er forskel på:

  • patches, der ændrer upstream kode direkte
  • konfigurationsbaserede tilpasninger (fx via Helm values)

• Hvordan vi skal forstå forskellen mellem:

  • intern brug
  • distribution til andre
  • tilgængeliggørelse som tjeneste (SaaS)

• Hvordan vi skal forstå vores Helm chart:

  • som en selvstændig komponent
  • eller som en del af et samlet afledt værk

• Hvilke krav der gælder ved offentliggørelse ift.:

  • attribution (fx BSD/MIT)
  • deling af ændringer (fx MPL, GPL)
  • brug over netværk/SaaS (fx AGPL)

• Hvordan vi korrekt håndterer licensvalg for vores eget arbejde:

  • Kan patches og Helm chart have en anden licens end upstream?
  • Hvilke begrænsninger gælder for kompatibilitet?

• Hvordan vi sikrer en samlet licensmæssig korrekt distribution, når flere licenser indgår (fx via SBOM eller tilsvarende overblik)

Formål

At etablere en generel praksis for, hvordan vi:

• vurderer afledte værker
• håndterer licensforpligtelser
• og offentliggør tilpasninger og deployment-setup korrekt

på tværs af forskellige open source-licenser.

[zorp]

Foreløbig konklusion

Den foreløbige vurdering er følgende:

• Direkte patches til upstream-kode skal som udgangspunkt behandles som ændringer af den oprindelige software og dermed vurderes efter den relevante upstream-licens.
• Helm charts, values-filer og anden separat deployment-konfiguration vil ofte kunne behandles som selvstændige artefakter og ikke automatisk som afledte værker af upstream-koden.
• Det afgørende juridiske skel går især mellem:
  • intern brug
  • distribution til andre
  • tilgængeliggørelse som tjeneste (SaaS)

På tværs af licenstyper er hovedkonklusionen:

• BSD/MIT/Apache: giver typisk stor frihed, så længe attribution, licenstekster og eventuelle NOTICE-krav overholdes.
• MPL 2.0: ændringer til MPL-dækkede filer skal ved distribution deles under MPL, mens separate filer normalt kan licenseres særskilt.
• GPL: distribution af modificeret software udløser pligt til at gøre den relevante kildekode tilgængelig under GPL.
• AGPL: som GPL, men pligten kan også udløses ved netværksbrug af en modificeret version.

Praktisk betydning for OS2ai

Hvis vi offentliggør:

• patches til upstream-kode, skal de håndteres i overensstemmelse med upstream-licensen.
• eget Helm chart og egen konfiguration, kan disse ofte offentliggøres under en selvstændig licens, hvis de reelt er separate filer og ikke indeholder upstream-kode.

Næste skridt

For at sikre korrekt licenshåndtering bør vi for hver komponent afklare:

1. Hvilken licens komponenten har
2. Om vi ændrer upstream-koden direkte
3. Om vi kun tilføjer separat konfiguration/deployment
4. Om vi distribuerer videre eller kun bruger internt
5. Om løsningen stilles til rådighed som tjeneste

[zorp]

Yderligere har jeg sammen med min assistent (AI) påbegyndt en vejledning og et beslutningstræ.

https://boks.os2.eu/s/2kJMe4e9fWK9agQ