doc(arch): added an analysis of forgejo OSS release timeline and the impact of Forgejo's GPL licencing on our EDP Frontend Portal (-Frontend)
This commit is contained in:
parent
c6f54040d6
commit
666d70ea81
3 changed files with 744 additions and 0 deletions
Binary file not shown.
|
After Width: | Height: | Size: 1.5 MiB |
|
|
@ -0,0 +1,735 @@
|
|||
# OSS licenceses and their impact on Forgejo development
|
||||
|
||||
Forgejo ist GPL copylefted [since v9 from October 2024](https://forgejo.org/2024-10-release-v9-0/). The entry to the [discussion is here (blog)](https://forgejo.org/2024-08-monthly-update/#forgejo-is-now-copyleft). and [here (ticket)](https://codeberg.org/forgejo/discussions/issues/192)
|
||||
|
||||
In the follwowing is the documentation of a chat with GPT about OSS licencing in general and the impact of Forgejo's copyleft on our Forgejo development.
|
||||
|
||||
## TL:DR;
|
||||
|
||||
* It looks like that as a SaaS/PaaS product EDP will not be affected to be 'infected' by GPL
|
||||
* But if we share/distribute the code, all 'integrated' parts (like frontend code) needs to be published under GPL also.
|
||||
|
||||
### Forgejo release line
|
||||
|
||||
The following chart shows the Forgejo releases (and semantiv versioning) over time and their relation - soft- vs hardfork - to Gitea.
|
||||
|
||||
|
||||
|
||||
|
||||
## Copyleft
|
||||
|
||||
> was ist copyleft software?
|
||||
|
||||
**Copyleft** ist ein Begriff aus dem Bereich der **freien Softwarelizenzen**. Er bezeichnet eine spezielle Lizenzform, bei der **die Freiheit, Software zu nutzen, zu verändern und weiterzugeben, sichergestellt und auf alle abgeleiteten Werke übertragen wird**.
|
||||
|
||||
### Einfach erklärt:
|
||||
|
||||
Wenn Software unter einer **Copyleft-Lizenz** steht:
|
||||
|
||||
* Darfst du sie **frei verwenden**, **verändern** und **weiterverbreiten**.
|
||||
* **Aber:** Wenn du sie veränderst oder in eigene Programme einbaust und diese weiterverbreitest, **musst du deinen Code auch wieder unter derselben Lizenz veröffentlichen**.
|
||||
|
||||
### Ziel von Copyleft:
|
||||
|
||||
Copyleft verhindert, dass jemand freie Software nimmt, verbessert und **dann proprietär macht** (also als unfreie Software weiterverkauft). Es sorgt dafür, dass **Freiheit erhalten bleibt** – auch bei Änderungen und Weiterentwicklungen.
|
||||
|
||||
---
|
||||
|
||||
### Beispiele für Copyleft-Lizenzen:
|
||||
|
||||
* **GNU General Public License (GPL)** – stärkstes Copyleft
|
||||
* **AGPL (Affero GPL)** – wie GPL, aber auch bei Webdiensten wirksam
|
||||
* **LGPL (Lesser GPL)** – abgeschwächt, erlaubt Linken mit proprietärem Code
|
||||
|
||||
---
|
||||
|
||||
### Abgrenzung:
|
||||
|
||||
* **Copyleft**: Freiheit bleibt ansteckend (GPL).
|
||||
* **Permissive Lizenzen** (wie MIT oder Apache): Du darfst den Code auch in proprietäre Software einbauen, ohne ihn wieder offenlegen zu müssen.
|
||||
|
||||
---
|
||||
|
||||
### Kurzes Beispiel:
|
||||
|
||||
Du nutzt eine GPL-lizenzierte Bibliothek in deinem Projekt.
|
||||
→ Du verteilst dein Programm weiter.
|
||||
→ Du **musst deinen Code offenlegen** und unter GPL stellen.
|
||||
→ Du **darfst nicht** dein Programm schließen und sagen: „Ist jetzt meins.“
|
||||
|
||||
---
|
||||
|
||||
## Integration of proprietary own code
|
||||
|
||||
> ich arbeite in einer company. wir verwenden forgejo als ausgangsprodukt für unser eigenes produkt P. wir wollen forgejo zu einem portal ausbauen. forgejo hat seit v9 eine copyleft lizenz, es ist GPL 3 und höher. wenn jetzt meine company sagt, wir müssen in P die company-eigenen frontend komponenten (javascript und css) K einbauen, dann würde das doch bedeuten, dass bei der veröffentlichung von P alle K mit ausgeliefert werden müssen. Sind sie dann auch copyleft?
|
||||
|
||||
Das ist eine sehr gute und wichtige Frage. Du hast die Ausgangslage korrekt beschrieben:
|
||||
|
||||
* **Forgejo steht seit Version 9 unter der GPLv3 (Copyleft)**.
|
||||
* Eure Firma baut darauf ein neues Produkt **P** auf.
|
||||
* In **P** sollen proprietäre **Frontend-Komponenten K (JS + CSS)** integriert werden.
|
||||
* Jetzt ist die Frage: **Werden K dadurch automatisch copyleft (GPL-3-lizenziert)?**
|
||||
|
||||
---
|
||||
|
||||
### Die juristisch relevante Frage ist:
|
||||
|
||||
> **Ist K als „abgeleitetes Werk“ (derivative work) von Forgejo zu betrachten?**
|
||||
|
||||
Wenn ja → **GPL-Virus** greift → K müsste **ebenfalls unter der GPL veröffentlicht werden**, sobald P verteilt wird.
|
||||
Wenn nein → K kann **proprietär** bleiben.
|
||||
|
||||
---
|
||||
|
||||
### Einschätzung aus der Praxis:
|
||||
|
||||
#### 🔹 Forgejo (bzw. Gitea/Gogs) ist eine Webanwendung:
|
||||
|
||||
* Typisch: Backend (Go) + Web-Frontend (JS/HTML/CSS).
|
||||
* GPLv3 umfasst das **gesamte Programm**, auch das Web-Frontend.
|
||||
|
||||
#### 🔹 Wenn ihr Frontend-Komponenten K in Forgejo-P einbettet:
|
||||
|
||||
* Also z. B. in `templates/*.tmpl` einbindet
|
||||
* Oder sie mit Forgejos JS interagieren (über globale Objekte, Hooks, Module usw.)
|
||||
* Oder sie direkt im Forgejo-Build-Prozess enthalten sind
|
||||
|
||||
→ Dann sind **K Teil des Gesamtwerks** → **GPL-pflichtig**, wenn ihr **P verteilt** (z. B. als installierbare Software oder über ein Download-Angebot).
|
||||
|
||||
#### 🔹 Wenn ihr P **nur als internen Service** betreibt (also nicht verteilt):
|
||||
|
||||
* Dann **greift die GPL nicht**. Die GPL regelt **Verbreitung**, nicht bloße Nutzung (auch intern oder SaaS).
|
||||
* Ausnahme: Bei AGPL (Affero GPL) wäre das anders. Forgejo nutzt aber **nur GPL**, nicht AGPL.
|
||||
|
||||
---
|
||||
|
||||
### Fazit:
|
||||
|
||||
| Szenario | Müssen K offen gelegt werden? |
|
||||
| --------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
|
||||
| **P wird nicht verteilt, nur gehostet (z. B. SaaS, internes Portal)** | ❌ Nein, GPL greift hier nicht |
|
||||
| **P wird an Dritte verteilt (z. B. Kunden, Partner, zum Download)** | ✅ Ja, dann müssen **auch K offen gelegt werden**, wenn sie Teil des Gesamtsystems sind |
|
||||
|
||||
---
|
||||
|
||||
### Mögliche Strategien:
|
||||
|
||||
1. **Frontend-K modularisieren:**
|
||||
|
||||
* K **außerhalb** von Forgejo laden (z. B. über CDN, iframe, Microfrontend, WebExtension)
|
||||
* Dann wäre K kein „abgeleitetes Werk“, sondern „separat“ → GPL greift nicht
|
||||
|
||||
2. **Forgejo entkoppeln:**
|
||||
|
||||
* Forgejo als **Backend-Komponente** nutzen, euer Portal ist UI-first
|
||||
* Forgejo läuft z. B. headless oder als API-only-Service
|
||||
|
||||
3. **Lizenzpflicht akzeptieren:**
|
||||
|
||||
* K offenlegen und unter GPLv3 (oder kompatibler Lizenz) stellen
|
||||
|
||||
4. **Lizenzrechtlich beraten lassen:**
|
||||
|
||||
* Wenn euer Setup komplizierter ist (z. B. komplexes Zusammenspiel, modulare Bundles), ist eine rechtliche Einschätzung sinnvoll
|
||||
|
||||
---
|
||||
|
||||
## Headless, separtion of forgejo Frontend and Backend
|
||||
|
||||
> angenommen, Forgejo würde sich zu einem headless-Ansatz entwicklen und Frontend und Backend trennen. Und wenn unsere virulenten K Komponenten dann nur im Frontend wären, würde ja dieselbe diskussion gültig sein, diesmal halt nur mit dem Gesamtwerk 'Frontend'. Richtig?
|
||||
|
||||
Ganz genau – **du hast das Prinzip vollständig verstanden**. Lass uns das nochmal im Detail klarmachen:
|
||||
|
||||
---
|
||||
|
||||
### 🧠 Grundidee: GPL „infiziert“ das **Gesamtwerk** bei *Verbreitung*
|
||||
|
||||
* Ob das „Gesamtwerk“ aus einem **monolithischen Projekt** besteht oder aus **Frontend + Backend getrennt** aufgebaut ist, ist **lizenzrechtlich egal**, solange die Teile als **ein zusammengehöriges Werk** vertrieben werden.
|
||||
|
||||
---
|
||||
|
||||
### 🔍 Headless Forgejo: Was ändert sich?
|
||||
|
||||
Angenommen Forgejo trennt sich vollständig in:
|
||||
|
||||
* **Forgejo Backend** (API, Auth, Git, etc.) → GPLv3
|
||||
* **Forgejo Frontend** (UI, Web-App, REST-Client) → ebenfalls GPLv3
|
||||
|
||||
Nun baut ihr euer eigenes Frontend:
|
||||
|
||||
* Ihr verwendet Forgejos GPLv3-Frontend als Grundlage
|
||||
* Ihr integriert eigene proprietäre Komponenten **K** (JS, CSS, React, etc.)
|
||||
|
||||
Dann gilt:
|
||||
|
||||
> Wenn **euer Frontend P'** auf dem GPLv3-Frontend von Forgejo basiert (also *abgeleitet ist*) und **weitergegeben wird**, dann **muss auch P' unter der GPLv3 stehen**.
|
||||
|
||||
→ Und damit **auch K**, wenn sie integraler Bestandteil sind.
|
||||
|
||||
---
|
||||
|
||||
### 🤔 Was ist „integraler Bestandteil“?
|
||||
|
||||
Wenn K z. B.:
|
||||
|
||||
* direkt in Forgejo-Frontend eingebunden wird (als Module, React-Components, Styles)
|
||||
* im Build mit Forgejo-Code gebundled wird (z. B. über Webpack, Vite, Rollup)
|
||||
* von GPL-Code aufgerufen oder mit GPL-Code gemeinsam ausgeliefert wird
|
||||
|
||||
→ Dann ist K **Teil des Frontend-Gesamtwerks** → **GPL-pflichtig**
|
||||
|
||||
---
|
||||
|
||||
### 🔓 Wie kann man K trotzdem proprietär halten?
|
||||
|
||||
Du musst K **technisch und lizenzrechtlich abtrennen**. Das geht z. B. durch:
|
||||
|
||||
#### 1. **Frontend-Plugins über offene Schnittstellen (APIs, Hooks)**
|
||||
|
||||
* Forgejo lädt externe Komponenten **dynamisch** zur Laufzeit (wie Plugins)
|
||||
* Plugins liegen **nicht im selben Repository**, werden **nicht mitgebundled**
|
||||
* Sie kommunizieren z. B. über Events oder JS-APIs
|
||||
|
||||
→ Diese Trennung kann stark genug sein, um K **nicht als abgeleitetes Werk** gelten zu lassen.
|
||||
|
||||
#### 2. **Microfrontend-Architektur**
|
||||
|
||||
* Forgejo-UI + K-Frontend als **völlig getrennte Webapps**
|
||||
* Sie kommunizieren nur via REST
|
||||
* Beide haben eigene Buildprozesse, Domains oder Deployments
|
||||
|
||||
→ Dann ist K **nur ein separater Client**, der Forgejo nutzt → **kein Copyleft-Risiko**
|
||||
|
||||
---
|
||||
|
||||
### ⚖️ Kurzes Lizenz-Merkblatt (bei Verteilung):
|
||||
|
||||
| Du verwendest... | Und veränderst... | Und verbreitest... | Dann musst du... |
|
||||
| ---------------- | ----------------- | ------------------------ | ----------------------------------------------- |
|
||||
| GPL-Frontend | nur API-Aufrufe | Nein | Nichts (Nutzung ist frei) |
|
||||
| GPL-Frontend | nichts | Ja (z. B. als Proxy-App) | GPL-Code beilegen |
|
||||
| GPL-Frontend | und fügst K ein | Ja | Dann wird K auch GPL (wenn nicht klar getrennt) |
|
||||
|
||||
---
|
||||
|
||||
**Fazit:**
|
||||
Ja, auch bei Headless-Struktur bleibt die Diskussion **identisch**, nur auf **Frontend-Ebene**.
|
||||
Was zählt, ist **Verbreitung** und **Abhängigkeit**: Wenn ihr Forgejos GPL-Code als **technisches Fundament** für euer eigenes UI nehmt und es **weitergebt**, dann **unterliegt das gesamte resultierende UI dem Copyleft** – inklusive eurer Komponenten **K**, falls sie technisch integriert sind.
|
||||
|
||||
## Portal as SaaS/PaaS
|
||||
|
||||
> ok, und wenn unser P nur als SaaS bzw. PaaS verfügbar wird für Kunden, dann erübrigt sich die ganze Lizenzdiskussion?
|
||||
|
||||
Fast – aber mit einer wichtigen Einschränkung:
|
||||
|
||||
---
|
||||
|
||||
### ✅ Ja: Wenn ihr **P nur als SaaS oder PaaS betreibt**, also **nicht verteilt**,
|
||||
|
||||
dann **greift die GPLv3 nicht**.
|
||||
|
||||
> **Die GPL regelt die *Verbreitung* (distribution)** von Software, **nicht deren Nutzung über ein Netzwerk**.
|
||||
|
||||
Das heißt:
|
||||
|
||||
* Ihr könnt **Forgejo (GPLv3)** hosten
|
||||
* Ihr könnt es verändern
|
||||
* Ihr könnt eigene Komponenten **K (JS/CSS)** integrieren, auch tief im System
|
||||
* Solange ihr **P nicht als Download oder Produkt weitergebt**,
|
||||
**müsst ihr keinerlei Quellcode veröffentlichen** – auch nicht für K
|
||||
|
||||
---
|
||||
|
||||
### 🔒 Ausnahme: Die **AGPLv3**
|
||||
|
||||
Die **Affero GPLv3** (nicht die normale GPLv3!) **schließt diese Lücke**:
|
||||
|
||||
> Wenn Software **über ein Netzwerk bereitgestellt wird**, dann gilt das wie eine „Verbreitung“,
|
||||
> und ihr müsst den **Quellcode bereitstellen**, inklusive Modifikationen.
|
||||
|
||||
Aber:
|
||||
→ **Forgejo verwendet nur GPLv3**, **nicht** AGPLv3.
|
||||
→ Daher **greift diese Ausnahme bei euch nicht**.
|
||||
|
||||
---
|
||||
|
||||
### 🧠 Fazit
|
||||
|
||||
| Szenario | GPLv3-Pflichten? |
|
||||
| --------------------------------------------- | ------------------------------------------------- |
|
||||
| P wird nur gehostet (SaaS/PaaS), nie verteilt | ❌ Nein |
|
||||
| P wird als installierbares Produkt verteilt | ✅ Ja, alle abgeleiteten Werke müssen GPL sein |
|
||||
| P nutzt AGPL-Komponenten | ⚠️ Ja, auch bei SaaS muss Code offengelegt werden |
|
||||
|
||||
---
|
||||
|
||||
### 💡 Empfehlung
|
||||
|
||||
Wenn ihr **zukünftig eventuell doch distributieren wollt**, wäre es gut, das in der Architektur zu berücksichtigen (z. B. K trennbar halten).
|
||||
Solange ihr aber rein **als Betreiber eines SaaS/PaaS-Portals** handelt, seid ihr aus GPLv3-Sicht **vollkommen auf der sicheren Seite** – auch mit euren proprietären K-Komponenten.
|
||||
|
||||
## AGPL vs GPL
|
||||
|
||||
> Das bedeutet ja, dass, im Sinne von OS, die AGPL strenger (schützneder) als die GPl ist?
|
||||
|
||||
Ganz genau – **die AGPL ist eine „strenger schützende“ Lizenz als die GPL**, vor allem im Kontext von Cloud-/SaaS-Anbietern. Hier ist eine kurze, aber präzise Einordnung:
|
||||
|
||||
---
|
||||
|
||||
### 🔍 Unterschied: GPL vs. AGPL
|
||||
|
||||
| Lizenz | Muss Quellcode offengelegt werden bei… | Ziel |
|
||||
| ---------- | ---------------------------------------------------------------------------------- | ----------------------- |
|
||||
| **GPLv3** | Nur wenn Software **verbreitet** wird (z. B. Download, Installationspaket) | Schutz bei Distribution |
|
||||
| **AGPLv3** | Auch wenn Software **nur übers Netzwerk bereitgestellt** wird (z. B. als **SaaS**) | Schutz auch bei Hosting |
|
||||
|
||||
---
|
||||
|
||||
### 🧠 Was schützt die AGPL mehr?
|
||||
|
||||
Die AGPL wurde entwickelt, um die sogenannte **„SaaS-Lücke“** in der GPL zu schließen:
|
||||
|
||||
* Viele Unternehmen nahmen GPL-Software, erweiterten sie, **veröffentlichten sie nie**, sondern **hosteten sie einfach als Service**.
|
||||
* Ergebnis: **Sie profitierten von freier Software, gaben aber nichts zurück** – ganz legal unter der GPL.
|
||||
|
||||
Die AGPL sagt daher:
|
||||
|
||||
> Wenn du Software nutzt, die unter der AGPL steht,
|
||||
> **und Nutzer über ein Netzwerk mit ihr interagieren können**,
|
||||
> **musst du deinen geänderten Quellcode offenlegen** –
|
||||
> auch **ohne Verbreitung der Software an sich**.
|
||||
|
||||
---
|
||||
|
||||
### 🎯 Beispiel aus der Praxis
|
||||
|
||||
* GitLab hat früher zwischen:
|
||||
|
||||
* **Open-Core GPLv3** (für das Backend),
|
||||
* und **nicht-freien Premium-Modulen** unterschieden.
|
||||
* Wäre GitLab stattdessen **AGPL-lizenziert** gewesen, hätten **Cloud-Anbieter wie AWS** den Code nicht einfach benutzen können, ohne ihre Änderungen zu teilen.
|
||||
|
||||
---
|
||||
|
||||
### 💡 Zusammenfassung
|
||||
|
||||
* **GPL schützt Freiheit bei Distribution**
|
||||
* **AGPL schützt Freiheit auch bei Netzwerk-Zugriff**
|
||||
* AGPL ist also:
|
||||
|
||||
* **restriktiver** für Unternehmen (die Software nur hosten)
|
||||
* **schutzstärker** im Sinne der Open-Source-Idee
|
||||
|
||||
---
|
||||
|
||||
Wenn euch also wichtig ist, dass **niemand eure Software nehmen und als Cloud-Dienst hosten kann**, ohne den Code freizugeben, dann ist **AGPL die bessere Wahl**.
|
||||
Aber für viele Firmen ist genau das der Grund, **AGPL zu vermeiden**, z. B. bei kommerziellem SaaS-Geschäft.
|
||||
|
||||
## MIT and LGPL
|
||||
|
||||
> Und LGPL und MIT? Wie sind diese Lizenzen in dieser Hinsicht zu bewerten?
|
||||
|
||||
|
||||
Super Frage! Wenn wir GPL, **AGPL**, **LGPL** und **MIT** in Bezug auf **„Schutzwirkung“ im Sinne von Open Source“** vergleichen wollen, entsteht ein ziemlich klar gestaffeltes Bild:
|
||||
|
||||
---
|
||||
|
||||
### 🧭 Übersicht: GPL, AGPL, LGPL, MIT im Vergleich
|
||||
|
||||
| Lizenz | Verbreitungspflicht bei… | „Infiziert“ abgeleitete Werke? | Kommerziell verwendbar? | SaaS-Abdeckung? | Schutzwirkung (Stärke) |
|
||||
| ---------- | -------------------------------------- | --------------------------------------- | ---------------------------------- | --------------- | ---------------------- |
|
||||
| **MIT** | Nur bei direkter Weitergabe (optional) | ❌ Nein | ✅ Ja | ❌ Nein | 🔓 *Sehr schwach* |
|
||||
| **LGPLv3** | Nur bei Verbreitung als *Library* | 🔸 Nur bei statischer/direkter Kopplung | ✅ Ja (dynamische Kopplung erlaubt) | ❌ Nein | ⚖️ *Moderat* |
|
||||
| **GPLv3** | ✅ Ja, bei Verbreitung | ✅ Ja | ⚠️ Eingeschränkt | ❌ Nein | 🔐 *Stark* |
|
||||
| **AGPLv3** | ✅ Ja, auch bei SaaS | ✅ Ja | ⚠️ Eingeschränkt | ✅ Ja | 🛡️ *Sehr stark* |
|
||||
|
||||
---
|
||||
|
||||
### 🔍 Detail: Was bedeuten diese Lizenzen im Alltag?
|
||||
|
||||
#### 1. **MIT License**
|
||||
|
||||
* Extrem permissiv: „Mach, was du willst – aber lass den Lizenztext dran.“
|
||||
* **Keine Copyleft-Wirkung**
|
||||
* Unternehmen können MIT-Code integrieren, verändern, verkaufen – **ohne irgendetwas offenzulegen**
|
||||
|
||||
🔧 **Typisch für:**
|
||||
|
||||
* Frontend-Libs (React, Lodash)
|
||||
* Dev-Tools, CLI-Tools
|
||||
* Universitätscode
|
||||
|
||||
---
|
||||
|
||||
#### 2. **LGPL (Lesser GPL)**
|
||||
|
||||
* Speziell für **Bibliotheken** entwickelt
|
||||
* Erlaubt **dynamische Verlinkung** mit proprietärer Software
|
||||
* Nur wenn du die Library **veränderst** oder **statisch einbindest**, musst du den Quellcode offenlegen
|
||||
|
||||
⚠️ **Aber Achtung:** Wenn du z. B. ein JavaScript-Modul *"inplace"* in dein Bundle einbaust, kann das **als „statische Kopplung“** gelten → Copyleft greift!
|
||||
|
||||
🔧 **Typisch für:**
|
||||
|
||||
* Standard-Bibliotheken wie glibc (GNU C Library)
|
||||
* Frameworks, die auch kommerziell nutzbar sein sollen
|
||||
|
||||
---
|
||||
|
||||
#### 3. **GPLv3**
|
||||
|
||||
* Klassisches **„starkes Copyleft“**
|
||||
* Wer verändert + verteilt, muss **den vollständigen Quellcode** offenlegen
|
||||
* **ABER:** Keine Wirkung bei reinem SaaS-Hosting
|
||||
|
||||
🔧 **Typisch für:**
|
||||
|
||||
* Linux-Kernel (GPLv2)
|
||||
* Forgejo, Gitea
|
||||
* Viele CLI-Tools oder Compiler
|
||||
|
||||
---
|
||||
|
||||
#### 4. **AGPLv3**
|
||||
|
||||
* Wie GPLv3, **plus Netzwerk-Nutzung**
|
||||
* „Wenn Benutzer über das Internet mit der Software interagieren können, dann musst du auch bei SaaS den Quellcode offenlegen“
|
||||
|
||||
🔧 **Typisch für:**
|
||||
|
||||
* Self-hosted SaaS-Alternativen (z. B. Matomo, CryptPad, GitLab CE früher)
|
||||
* Community-Projekte, die „Cloud-Reselling“ verhindern wollen
|
||||
|
||||
---
|
||||
|
||||
### 🧠 Zusammenfassung als Diagramm
|
||||
|
||||
```text
|
||||
⬆ Schutzwirkung / Copyleft
|
||||
│
|
||||
│ 🛡️ AGPLv3 → verteilt + SaaS → Quellcodepflicht
|
||||
│ 🔐 GPLv3 → verteilt → Quellcodepflicht
|
||||
│ ⚖️ LGPLv3 → Libs bei Verlinkung → schwächer
|
||||
│ 🔓 MIT → keine Pflicht, frei nutzbar
|
||||
│
|
||||
└────────────▶ Freiheit für kommerzielle Nutzung
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 🔎 Fazit für dich:
|
||||
|
||||
Wenn du in deinem Unternehmen:
|
||||
|
||||
* **keinen Quellcode offenlegen willst**, ist MIT oder (je nach Fall) LGPL sinnvoll
|
||||
* **SaaS-only anbietest**, und Open-Source-Code nutzt:
|
||||
|
||||
* **MIT, BSD, LGPL → unkritisch**
|
||||
* **GPL → unkritisch (solange nicht verteilt)**
|
||||
* **AGPL → kritisch, da *Quellcodeoffenlegungspflicht* trotz SaaS**
|
||||
|
||||
## Apache
|
||||
|
||||
> kannst du in die obige Analyse noch die Apache Lizenz mit aufnehmen? Also alle schritet 1-4, plus die Zusammanfassung bitte, denn das sieht seeeeht übersichtlich aus, was du da geschrieben hast!
|
||||
|
||||
Sehr gern! Hier ist die **erweiterte und überarbeitete Analyse**, diesmal mit der **Apache License 2.0** ergänzt – inklusive aller Schritte, Unterschiede und der praktischen Zusammenfassung.
|
||||
|
||||
---
|
||||
|
||||
### 🧭 Übersicht: MIT, LGPL, GPLv3, AGPLv3, Apache 2.0 im Vergleich
|
||||
|
||||
| Lizenz | Verbreitungspflicht bei… | „Infiziert“ abgeleitete Werke? | Kommerziell verwendbar? | SaaS-Abdeckung? | Schutzwirkung |
|
||||
| -------------- | -------------------------------------------- | ----------------------------------- | ----------------------- | --------------- | -------------------------------- |
|
||||
| **MIT** | ✅ Nur bei direkter Weitergabe | ❌ Nein | ✅ Ja | ❌ Nein | 🔓 *Sehr schwach* |
|
||||
| **Apache 2.0** | ✅ Nur bei Weitergabe (wie MIT) | ❌ Nein *(aber inkl. Patentklausel)* | ✅ Ja | ❌ Nein | 🔓 *Schwach* + 🧩 *Patentschutz* |
|
||||
| **LGPLv3** | ✅ Bei Veränderung oder statischer Verlinkung | 🔸 Teilweise (nur bei Kopplung) | ✅ Ja (mit Vorsicht) | ❌ Nein | ⚖️ *Moderat* |
|
||||
| **GPLv3** | ✅ Bei jeder Weitergabe | ✅ Ja (alles, was „abgeleitet“ ist) | ⚠️ Eingeschränkt | ❌ Nein | 🔐 *Stark* |
|
||||
| **AGPLv3** | ✅ Auch bei SaaS/Remote-Zugriff | ✅ Ja | ⚠️ Eingeschränkt | ✅ Ja | 🛡️ *Sehr stark* |
|
||||
|
||||
---
|
||||
|
||||
### 🔍 Schritt 1: **MIT License**
|
||||
|
||||
* Extrem permissiv
|
||||
* Du kannst fast alles damit machen (auch Closed Source)
|
||||
* Nur Pflicht: Lizenztext beibehalten
|
||||
* **Keine** Copyleft-Wirkung
|
||||
* ⚠️ Keine Patentlizenz (aber selten ein Problem bei typischem JavaScript-Code etc.)
|
||||
|
||||
✅ Ideal für: Bibliotheken, die möglichst breit einsetzbar sein sollen
|
||||
🧩 Kein Schutz gegen „Trittbrettfahrer“, aber maximal kompatibel
|
||||
|
||||
---
|
||||
|
||||
### 🔍 Schritt 2: **Apache License 2.0**
|
||||
|
||||
* Sehr ähnlich zu MIT, aber mit einem großen Zusatz:
|
||||
|
||||
* 📄 **Erteilt explizit eine Patentlizenz**
|
||||
* 🛡️ **Schützt Nutzer davor, von ursprünglichen Autoren verklagt zu werden**
|
||||
* Keine Copyleft-Wirkung
|
||||
* Sehr **kompatibel mit kommerziellen Projekten**
|
||||
* Weit verbreitet in Unternehmen (Google, Apache Software Foundation, etc.)
|
||||
|
||||
✅ Ideal für: Große Projekte, bei denen Patentsicherheit wichtig ist (Cloud, Machine Learning, etc.)
|
||||
|
||||
---
|
||||
|
||||
### 🔍 Schritt 3: **LGPLv3**
|
||||
|
||||
* „Mittelweg“ zwischen MIT/Apache und GPL
|
||||
* Typisch für **dynamisch gelinkte Libraries**
|
||||
* **Du darfst sie in Closed Source nutzen**, solange du:
|
||||
|
||||
* dynamisch linkst,
|
||||
* **und** keine Änderungen an der LGPL-Bibliothek selbst machst
|
||||
* Bei **statischer Einbindung**: GPL-Pflichten!
|
||||
|
||||
✅ Ideal für: Libraries, die *frei genutzt* werden sollen, ohne dass jedes Projekt unter GPL stehen muss
|
||||
|
||||
---
|
||||
|
||||
### 🔍 Schritt 4: **GPLv3 / AGPLv3**
|
||||
|
||||
#### GPLv3:
|
||||
|
||||
* Striktes Copyleft
|
||||
* Alles, was du daraus baust oder veränderst, **muss auch GPL werden**, sobald du es weitergibst
|
||||
* **Keine Wirkung bei SaaS**
|
||||
|
||||
#### AGPLv3:
|
||||
|
||||
* Wie GPLv3, aber **greift auch bei SaaS**
|
||||
* Nutzer über das Netzwerk = „Verbreitung“ → Quellcodepflicht
|
||||
|
||||
✅ Ideal für: Projekte, bei denen sichergestellt werden soll, dass **jede Nutzung** (auch SaaS) zur Veröffentlichung zwingt
|
||||
|
||||
---
|
||||
|
||||
### 🎯 Zusammenfassung als Diagramm
|
||||
|
||||
```text
|
||||
⬆ Schutzwirkung / Copyleft
|
||||
│
|
||||
│ 🛡️ AGPLv3 → verteilt + SaaS → Quellcodepflicht
|
||||
│ 🔐 GPLv3 → verteilt → Quellcodepflicht
|
||||
│ ⚖️ LGPLv3 → bei Kopplung/Änderung → Quellcodepflicht für die Library
|
||||
│ 🔓 Apache 2 → freie Nutzung, + Patentlizenz
|
||||
│ 🔓 MIT → freie Nutzung, einfachste Lizenz
|
||||
│
|
||||
└────────────▶ Freiheit für kommerzielle Nutzung
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 🧠 Praxis-Tipps
|
||||
|
||||
| Ziel | Empfohlene Lizenz |
|
||||
| -------------------------------------------------------------------------------- | --------------------------- |
|
||||
| Du willst maximale Freiheit für Nutzer und Firmen | **MIT** oder **Apache 2.0** |
|
||||
| Du baust eine Library, willst Verlinkung erlauben, aber Änderungen offenlegen | **LGPLv3** |
|
||||
| Du willst, dass alle Ableitungen Open Source bleiben (außer bei SaaS) | **GPLv3** |
|
||||
| Du willst, dass niemand deinen Code nutzt, ohne ihn offenzulegen – auch bei SaaS | **AGPLv3** |
|
||||
|
||||
---
|
||||
|
||||
## 'Free software forever'
|
||||
|
||||
> Der Claim 'will be free forever' lässt sich also nur mit GPL und AGPL verwirklcihen? verstehe ich das richtig? Oder anders: Warum ist Forgejo in v9 zur GPL gewechselt?
|
||||
|
||||
Ja, du verstehst das im Kern **richtig** – und wir können den Gedanken noch etwas differenzierter ausleuchten.
|
||||
|
||||
---
|
||||
|
||||
### 🎯 1. „Will be free forever“ – Was bedeutet das konkret?
|
||||
|
||||
Das ist **kein juristischer Begriff**, sondern ein ideologischer Anspruch:
|
||||
|
||||
> ❝ Jeder, der meine Software nutzt, verändert oder weiterverbreitet, muss sie **frei halten**, so wie ich es getan habe. Niemand soll sie einsperren dürfen. ❞
|
||||
|
||||
Damit ist gemeint:
|
||||
|
||||
* Der Quellcode bleibt **immer offen** (auch bei Ableitungen)
|
||||
* Niemand darf durch Ableitungen ein **proprietäres Produkt** daraus machen
|
||||
* Freiheit für alle Nutzer, **nicht nur für den ersten Entwickler**
|
||||
|
||||
Das nennt man **„starkes Copyleft“**, und das bieten:
|
||||
|
||||
* **GPL (v2, v3)** – schützt vor proprietärer Weitergabe
|
||||
* **AGPL** – schützt vor proprietärer Weitergabe **und** vor „SaaS-Einschluss“ (Cloud-Tricks)
|
||||
|
||||
---
|
||||
|
||||
### ✅ 2. Welche Lizenzen sichern diese Freiheit tatsächlich?
|
||||
|
||||
| Lizenz | „Wird für immer frei bleiben“ (auch bei Ableitungen)? |
|
||||
| -------------------- | -------------------------------------------------------- |
|
||||
| **AGPLv3** | ✅ Ja – selbst bei SaaS |
|
||||
| **GPLv3** | ✅ Ja – bei jeder Weitergabe |
|
||||
| **LGPLv3** | 🔸 Teilweise – nur bei Änderungen an der LGPL-Komponente |
|
||||
| **MIT / Apache 2.0** | ❌ Nein – Ableitungen dürfen Closed Source sein |
|
||||
|
||||
Also: **Nur AGPL/GPL können mit gutem Gewissen sagen: *„Will be free forever.“***
|
||||
|
||||
---
|
||||
|
||||
### 🧩 3. Warum ist **Forgejo** in Version 9 auf **GPLv3+** gewechselt?
|
||||
|
||||
Forgejo ist ein **Fork von Gitea**, und dieser Fork entstand aus **Sorge um Community-Eigentum** und langfristige Offenheit.
|
||||
Mit dem Wechsel zu GPLv3 wollte das Forgejo-Projekt klarstellen:
|
||||
|
||||
> 💬 „Unsere Plattform bleibt auf ewig frei. Niemand wird Forgejo nehmen und ein Closed-Source-Projekt daraus machen können, ohne ihre Änderungen offenzulegen.“
|
||||
|
||||
#### Hintergrund:
|
||||
|
||||
* Forgejo sieht sich als „**Community-controlled GitHub-Alternative**“
|
||||
* Die GPL verhindert, dass jemand (z. B. ein Cloud-Anbieter oder eine Firma) Forgejo nutzt, verändert und **nicht wieder zurückgibt**
|
||||
* Bei MIT oder Apache könnte z. B. jemand Forgejo forken, um daraus ein kommerzielles, geschlossenes DevOps-Portal zu bauen – völlig legal.
|
||||
|
||||
Mit der **GPL** ist das **nicht erlaubt**, sobald der Code weitergegeben wird (z. B. als Binary oder Quellcode).
|
||||
Mit der **AGPL** wäre sogar **SaaS-Nutzung geschützt** – aber Forgejo hat sich (noch?) nicht für AGPL entschieden.
|
||||
|
||||
---
|
||||
|
||||
### 🏁 Fazit
|
||||
|
||||
* Ja: **Nur GPL und AGPL** gewährleisten, dass der Code „für immer frei“ bleibt
|
||||
* Forgejo wählte GPL, um:
|
||||
|
||||
* Copyleft-Schutz zu aktivieren
|
||||
* Die Community gegen proprietäre Forks zu schützen
|
||||
* Den Open-Source-Gedanken auf Dauer zu sichern
|
||||
|
||||
Wenn du „Free as in freedom“ **rechtlich absichern willst**, führt an **(A)GPL** kaum ein Weg vorbei.
|
||||
MIT, Apache und LGPL ermöglichen zwar freie Nutzung, aber **keinen dauerhaften Schutz der Freiheit**.
|
||||
|
||||
---
|
||||
|
||||
## Forgejo and SaaS/PaaS
|
||||
|
||||
> Rückfrage zu "Bei MIT oder Apache könnte z. B. jemand Forgejo forken, um daraus ein kommerzielles, geschlossenes DevOps-Portal zu bauen – völlig legal.": Das ist doch mit der GPL möglich, weil sie SaaS/PaaS nicht einschliesst ?!
|
||||
|
||||
Sehr gute Rückfrage – das ist **genau der Knackpunkt**, den viele übersehen.
|
||||
|
||||
---
|
||||
|
||||
### 🔍 Ja, du hast recht:
|
||||
|
||||
**GPL (auch v3)** schützt **nicht** vor der sogenannten:
|
||||
|
||||
> **SaaS-Schlupflücke** (auch „ASP loophole“ genannt)
|
||||
|
||||
Das bedeutet konkret:
|
||||
|
||||
> Ein Anbieter kann ein GPL-lizenziertes Programm **modifizieren**, es **auf Servern betreiben** (z. B. als DevOps-Plattform), es **niemals weitergeben** – und somit **nichts zurückgeben müssen**.
|
||||
|
||||
---
|
||||
|
||||
### 🔁 Was genau *verbietet* die GPL (v3)?
|
||||
|
||||
Sie verpflichtet zur **Offenlegung des Quellcodes**, wenn:
|
||||
|
||||
* du das Programm **weiterverbreitest** (als Binary oder Source)
|
||||
* du es **mit anderer Software kombinierst** (dann unter bestimmten Bedingungen auch)
|
||||
|
||||
Aber:
|
||||
|
||||
> Wenn du das Programm nur **ausführst** (z. B. auf einem eigenen Server) und **nur als Dienst** anbietest – **greift die GPL nicht**.
|
||||
|
||||
#### Also:
|
||||
|
||||
Mit GPL darf jemand Forgejo **modifizieren**, gehostet als z. B. `SuperForgeDevOps.io`, **ohne** den geänderten Code zu veröffentlichen.
|
||||
Solange er **nichts weitergibt**, **muss er nichts zurückgeben**.
|
||||
|
||||
---
|
||||
|
||||
### 🛡️ AGPL schließt diese Lücke
|
||||
|
||||
Die **AGPL (Affero GPL)** ist eine Erweiterung der GPLv3, und sie **fügt explizit hinzu**:
|
||||
|
||||
> **Wenn du das Programm über ein Netzwerk bereitstellst (z. B. SaaS), musst du auch dann den Sourcecode veröffentlichen.**
|
||||
|
||||
Damit ist auch das **Servermodell abgedeckt** – kein Entkommen durch Hosting.
|
||||
|
||||
---
|
||||
|
||||
### 📌 Fazit zur Rückfrage
|
||||
|
||||
| Lizenz | Schutz vor Closed-Source-Forks | Schutz vor SaaS-Schlupflücke |
|
||||
| ---------------- | ------------------------------ | ---------------------------- |
|
||||
| **MIT / Apache** | ❌ nein | ❌ nein |
|
||||
| **GPLv3** | ✅ ja (bei Weitergabe) | ❌ nein (SaaS erlaubt) |
|
||||
| **AGPLv3** | ✅ ja | ✅ ja |
|
||||
|
||||
➡️ **Forgejo mit GPLv3** schützt vor klassischen **Closed-Source-Distributionen**,
|
||||
aber **nicht** vor der **„wir hosten es einfach selbst“-Strategie**.
|
||||
|
||||
Wenn Forgejo also „vollständige Freiheitserhaltung“ auch im SaaS-Kontext will,
|
||||
müsste es auf **AGPL** umsteigen.
|
||||
|
||||
## Forgejo and SaaS/PaaS - II
|
||||
|
||||
> Also war deine Analyse oben in Punkt 3 "Warum ist Forgejo in Version 9 auf GPLv3+ gewechselt?" noch nicht ganz korrekt ... d.h. Forgejo lässt diese Möglichkeit offen (ein Portal auf eines PaaS zu bauen, so wie ich da plane)
|
||||
|
||||
Ganz genau – **sehr präzise erkannt**.
|
||||
|
||||
---
|
||||
|
||||
### 🛠️ Korrektur & Präzisierung von Punkt 3:
|
||||
|
||||
Meine Aussage in Punkt 3 war **inhaltlich nicht falsch**, aber **nicht vollständig**.
|
||||
Ich hatte gesagt:
|
||||
|
||||
> „Mit der GPL ist das nicht erlaubt, sobald der Code weitergegeben wird (z. B. als Binary oder Quellcode).“
|
||||
|
||||
Das stimmt – **aber nur bei Weitergabe**.
|
||||
Ich hätte explizit hinzufügen sollen:
|
||||
|
||||
> 🔸 **Die GPL erlaubt es jedoch, modifizierte Versionen privat als Service zu betreiben – ohne Quellcodefreigabe.**
|
||||
|
||||
---
|
||||
|
||||
### 🤝 Richtigstellung in Bezug auf Forgejo:
|
||||
|
||||
* Mit der Wahl von **GPLv3+** (nicht AGPL) hat Forgejo:
|
||||
|
||||
* ✅ *Copyleft* gegen klassische Forks durch Distribution geschützt
|
||||
* ❌ *Keinen Schutz* gegen **SaaS-only Forks** geschaffen
|
||||
|
||||
Das heißt für dich:
|
||||
|
||||
> Du darfst Forgejo modifizieren (inkl. Frontend, z. B. zu einem Portal), und **solange du P nur als PaaS anbietest**, **bist du GPL-konform** – **auch wenn du den Quellcode deiner Erweiterungen nicht veröffentlichst**.
|
||||
|
||||
---
|
||||
|
||||
### Warum dann überhaupt GPL und nicht MIT?
|
||||
|
||||
Forgejo wollte vermutlich:
|
||||
|
||||
* den **klassischen Missbrauch** (Closed-Source-Forks, OEMs, Redistribution als Produkt) **verhindern**
|
||||
* aber trotzdem eine gewisse **SaaS-Offenheit** erlauben, z. B.:
|
||||
|
||||
* für Hoster
|
||||
* für Unternehmen, die Forgejo intern/extern als Plattform verwenden
|
||||
* für Partner wie dich, die es als Basis in Produkten einsetzen
|
||||
|
||||
Eine **AGPL** hätte potenziell:
|
||||
|
||||
* zu mehr **rechtlicher Unsicherheit** geführt
|
||||
* Hosting-Anbieter **abgeschreckt**
|
||||
* weniger Verbreitung ermöglicht
|
||||
|
||||
Das ist oft ein **strategischer Trade-off**:
|
||||
**Mehr Kontrolle** (AGPL) vs. **mehr Adaption & Akzeptanz** (GPL).
|
||||
|
||||
---
|
||||
|
||||
### 🔍 Fazit zu deiner Einschätzung:
|
||||
|
||||
> **„Forgejo lässt die Möglichkeit offen, ein Portal auf PaaS-Basis zu bauen.“**
|
||||
|
||||
✅ **Richtig.**
|
||||
Solange du nichts **weitergibst** (Binary, Container, Installationspaket), bist du **nicht verpflichtet**, den Quellcode deiner Erweiterungen zu veröffentlichen – trotz GPLv3.
|
||||
|
||||
---
|
||||
|
||||
|
|
@ -279,3 +279,12 @@ git clone https://code.forgejo.org/actions/setup-forgejo.git
|
|||
* https://brainsteam.co.uk/2024/03/17/moving-from-gitea-to-forgejo-including-actions-with-docker-compose/
|
||||
* https://code.forgejo.org/forgejo/runner
|
||||
* https://linus.dev/posts/setting-up-a-self-hosted-forgejo-actions-runner-with-docker-compose/
|
||||
|
||||
|
||||
### Further [curated] references
|
||||
|
||||
* [ArchWiki](https://wiki.archlinux.org/title/Forgejo)
|
||||
* [Forgejo Command Line and Cli](https://forgejo.org/docs/latest/admin/command-line/)
|
||||
* [Interface Costomization](https://forgejo.org/docs/next/contributor/customization/)
|
||||
* [From soft to hard fork from Gitea](https://forgejo.org/docs/next/contributor/customization/): In Feb 2024 it was decided to stop downward compatibility with Gitea
|
||||
* [Drastic UI consolidation in v8.0](https://forgejo.org/2024-07-release-v8-0/)
|
||||
Loading…
Reference in a new issue