Merge branch 'main' into feature/product-management

.gitignore

@@ -0,0 +1 @@
+node_modules

devbox.json

@@ -0,0 +1,17 @@
+{
+  "$schema": "https://raw.githubusercontent.com/jetify-com/devbox/0.14.0/.schema/devbox.schema.json",
+  "packages": [
+    "nodejs@latest",
+    "terraform@latest"
+  ],
+  "shell": {
+    "init_hook": [
+      "echo 'Welcome to devbox!' > /dev/null"
+    ],
+    "scripts": {
+      "test": [
+        "echo \"Error: no test specified\" && exit 1"
+      ]
+    }
+  }
+}

devbox.lock

@@ -0,0 +1,121 @@
+{
+  "lockfile_version": "1",
+  "packages": {
+    "github:NixOS/nixpkgs/nixpkgs-unstable": {
+      "resolved": "github:NixOS/nixpkgs/2d9e4457f8e83120c9fdf6f1707ed0bc603e5ac9?lastModified=1741462378&narHash=sha256-ZF3YOjq%2BvTcH51S%2BqWa1oGA9FgmdJ67nTNPG2OIlXDc%3D"
+    },
+    "nodejs@latest": {
+      "last_modified": "2025-03-16T16:17:41Z",
+      "plugin_version": "0.0.2",
+      "resolved": "github:NixOS/nixpkgs/8f76cf16b17c51ae0cc8e55488069593f6dab645#nodejs_23",
+      "source": "devbox-search",
+      "version": "23.10.0",
+      "systems": {
+        "aarch64-darwin": {
+          "outputs": [
+            {
+              "name": "out",
+              "path": "/nix/store/dihlffh62qmgzsrxq1igwxicdyr3fn8a-nodejs-23.10.0",
+              "default": true
+            },
+            {
+              "name": "libv8",
+              "path": "/nix/store/ks94i4365833bykrzg3d3mqxnciygyrn-nodejs-23.10.0-libv8"
+            }
+          ],
+          "store_path": "/nix/store/dihlffh62qmgzsrxq1igwxicdyr3fn8a-nodejs-23.10.0"
+        },
+        "aarch64-linux": {
+          "outputs": [
+            {
+              "name": "out",
+              "path": "/nix/store/m7j1lf8a4z5bfla1m78pa3y12888hl7b-nodejs-23.10.0",
+              "default": true
+            },
+            {
+              "name": "libv8",
+              "path": "/nix/store/kfvlfxx83n2w2fyb8hiz4p4dc165r035-nodejs-23.10.0-libv8"
+            }
+          ],
+          "store_path": "/nix/store/m7j1lf8a4z5bfla1m78pa3y12888hl7b-nodejs-23.10.0"
+        },
+        "x86_64-darwin": {
+          "outputs": [
+            {
+              "name": "out",
+              "path": "/nix/store/nj0d1lc4nanqj7v4ibcgd26m3p5yfb0h-nodejs-23.10.0",
+              "default": true
+            },
+            {
+              "name": "libv8",
+              "path": "/nix/store/k5rvmvqyibamfxa7cfzjfd5ldmi38kf3-nodejs-23.10.0-libv8"
+            }
+          ],
+          "store_path": "/nix/store/nj0d1lc4nanqj7v4ibcgd26m3p5yfb0h-nodejs-23.10.0"
+        },
+        "x86_64-linux": {
+          "outputs": [
+            {
+              "name": "out",
+              "path": "/nix/store/m7imcmwi4hschl257dzc33gxciqlf4bm-nodejs-23.10.0",
+              "default": true
+            },
+            {
+              "name": "libv8",
+              "path": "/nix/store/wy7ysxmd2ygdc5zpbhf9ripwgvvvnwsd-nodejs-23.10.0-libv8"
+            }
+          ],
+          "store_path": "/nix/store/m7imcmwi4hschl257dzc33gxciqlf4bm-nodejs-23.10.0"
+        }
+      }
+    },
+    "terraform@latest": {
+      "last_modified": "2025-04-10T20:20:34Z",
+      "resolved": "github:NixOS/nixpkgs/d19cf9dfc633816a437204555afeb9e722386b76#terraform",
+      "source": "devbox-search",
+      "version": "1.11.4",
+      "systems": {
+        "aarch64-darwin": {
+          "outputs": [
+            {
+              "name": "out",
+              "path": "/nix/store/46l1vs4h00h1y3n3xxwzab0a16mawfcs-terraform-1.11.4",
+              "default": true
+            }
+          ],
+          "store_path": "/nix/store/46l1vs4h00h1y3n3xxwzab0a16mawfcs-terraform-1.11.4"
+        },
+        "aarch64-linux": {
+          "outputs": [
+            {
+              "name": "out",
+              "path": "/nix/store/knyqig364fi94f3z33q47jawv9b4h4sy-terraform-1.11.4",
+              "default": true
+            }
+          ],
+          "store_path": "/nix/store/knyqig364fi94f3z33q47jawv9b4h4sy-terraform-1.11.4"
+        },
+        "x86_64-darwin": {
+          "outputs": [
+            {
+              "name": "out",
+              "path": "/nix/store/9w7xlspipmx4kal4bagqnf76h0wv8lx8-terraform-1.11.4",
+              "default": true
+            }
+          ],
+          "store_path": "/nix/store/9w7xlspipmx4kal4bagqnf76h0wv8lx8-terraform-1.11.4"
+        },
+        "x86_64-linux": {
+          "outputs": [
+            {
+              "name": "out",
+              "path": "/nix/store/xlg2aqgy2fwilpfnla4313f39vs0hhmb-terraform-1.11.4",
+              "default": true
+            }
+          ],
+          "store_path": "/nix/store/xlg2aqgy2fwilpfnla4313f39vs0hhmb-terraform-1.11.4"
+        }
+      }
+    }
+  }
+}

docs/technical-documentation/.pages

@@ -0,0 +1,6 @@
+title: Technical doc
+arrange:
+  - concepts
+  - architecture
+  - product
+  - project

docs/technical-documentation/architecture/decisions/0002-openbao-as-identity-provider.md

@@ -0,0 +1,62 @@
+---
+status: "proposed"
+decision-makers: {list everyone involved in the decision}
+---
+
+<!-- markdownlint-disable-next-line MD025 -->
+# Replace Keycloak with OpenBao as OIDC Provider
+
+## Context and Problem Statement
+
+The EDP currently relies on Keycloak as the OpenID Connect (OIDC) provider to handle authentication and authorization. However, Keycloak is fairly complex and has quite some maintenance overhead, which will leads to increased operational effort. We need to determine if replacing Keycloak with OpenBao, a tool we already use for secrets management and which may support OIDC capabilities, can streamline our architecture and reduce these operational burdens.
+
+## Decision Drivers
+
+- Simplify architecture by reducing the number of tools in our ecosystem.
+- Reduce operational complexity and maintenance overhead to improve team efficiency.
+- Ensure seamless integration with existing systems, particularly leveraging our current use of OpenBao.
+- Maintain or enhance security and performance to meet platform requirements.
+
+## Considered Options
+
+- Keep using Keycloak
+- Replace Keycloak with OpenBao
+
+## Decision Outcome
+
+Chosen option: "Replace Keycloak with OpenBao", because it enables us to consolidate identity and secrets management into a single tool, reducing operational complexity, improving integration with our existing infrastructure, and potentially enhancing performance, provided OpenBao can meet our OIDC needs.
+
+### Consequences
+
+- *Good*, because it simplifies the architecture by reducing the number of tools we need to manage.
+- *Good*, because it may lower operational costs by eliminating a separate system and leveraging an existing open-source tool.
+- *Bad*, because additional configuration or development might be required to ensure OpenBao fully supports all necessary OIDC features.
+- *Bad*, because relying on a single tool for both identity and secrets management increases risk if OpenBao encounters issues.
+
+### Confirmation
+
+- Conduct a proof-of-concept to validate that OpenBao can effectively serve as an OIDC provider meeting our platform’s requirements.
+- Validate that all EDP components support the Authorization Code Flow
+- Review the design and implementation with the development team to confirm alignment with this decision.
+
+## Pros and Cons of the Options
+
+### Keep using Keycloak
+
+Keycloak is a mature, feature-rich OIDC provider widely used for authentication and authorization.
+- *Good*, because it offers extensive OIDC features, including support for single sign-on and various authentication protocols.
+- *Good*, because it is already integrated into our platform, minimizing immediate changes.
+- *Bad*, because its complexity increases configuration and maintenance efforts.
+- *Bad*, because maintaining it as a separate tool adds to operational overhead.
+
+### Replace Keycloak with OpenBao
+
+OpenBao, a fork of HashiCorp Vault, is currently used for secrets management and may be configurable as an OIDC provider.
+- *Good*, because consolidating identity and secrets management into one tool simplifies our architecture.
+- *Good*, because it leverages our existing OpenBao deployment, potentially improving integration and reducing costs.
+- *Bad*, because OpenBao may not natively support all advanced OIDC features provided by Keycloak, such as comprehensive user management.
+- *Bad*, because its community and documentation for OIDC use cases may be less robust compared to Keycloak.
+
+## More Information
+
+Before finalizing this decision, we must verify OpenBao’s OIDC capabilities against our specific authentication and authorization requirements, such as user federation and token issuance for our development platform. The team should also assess the long-term implications of relying heavily on OpenBao and consider revisiting this decision if significant gaps in OIDC functionality are identified during the proof-of-concept phase.

docs/technical-documentation/architecture/design/_index.md

@@ -0,0 +1,6 @@
+---
+title: Design
+weight: 1
+description: Edge Developver Framework Design
+---
+

docs/technical-documentation/architecture/design/mvp1-12-otc/index.md

@@ -0,0 +1,59 @@
+# MVP1-12-OTC Milestone
+
+History:
+* 24.04.25: Initial Arch done in lucid by Waldemar
+* 06.05.25: Ported to C4 by Stephan
+* 13.05.25: Review OTC-EDP
+
+
+https://lucid.app/lucidspark/7134abcb-0c5e-41e5-93da-7118e285a668/edit?invitationId=inv_fbf0d105-7023-4740-806e-fcbb522ea61a&page=0_0#
+
+## C4 Architecture
+
+* https://forgejo.edf-bootstrap.cx.fg1.ffm.osc.live/DevFW-CICD/edp-doc/src/branch/development/likec4/views/deployment/otc/otc.c4
+
+![alt text](./_assets/image.png)
+
+![alt text](./_assets/image-1.png)
+
+## Overall
+
+### Architecture
+
+![alt text](./_assets/EDPForgejoArch1.svg)
+
+### Work packages
+
+![alt text](./_assets/EDPForgejoArch2.svg)   
+
+## EDP Foundry
+
+### Sub-Components 'Internal Services' and 'Central Observaability'           
+
+![alt text](./_assets/EDPForgejoArch3.svg)
+
+## EDP (deployed per tenant)
+
+### Sub-Components 'Kubernetes' and 'Cloud Services'    
+
+![alt text](./_assets/EDPForgejoArch4.svg)
+
+## Operator (Provisioning Pipeline)
+
+### Sub-Components 'Forgejo-Actions' and 'ArgoCD'  
+
+![alt text](./_assets/EDPForgejoArch5.svg)
+
+![alt text](./_assets/EDPForgejoArch6.svg)
+
+# OTC EDP product review on 13.05.25
+
+![alt text](./_assets/edp-otc-1.png)
+
+![alt text](./_assets/edp-otc-2.png)
+
+![alt text](./_assets/edp-otc-3.png)
+
+![alt text](./_assets/edp-otc-4.png)
+
+![alt text](./_assets/edp-otc-5.png)

docs/technical-documentation/architecture/design/mvp1-12-otc/productline-portal-frontend.md

@@ -0,0 +1,60 @@
+### WiP - needs to be reworked
+
+Participants: Michael, Robert, Stephan
+Date: Thu, 05.06.2025
+
+# EDP Product Line 'Portal/Frontend/Forgejo'
+
+[Also refer to other page here](../../../product/components/forgejo/index.md) 
+
+
+## how to proceed
+
+* let's create tickets!
+* let's mob!
+
+## terms
+
+Frontend: The part in the platfrom the user accesses. These are CLIs, APIs and Portals. Forgejo is our Portal.
+
+### Agreement
+
+* Forgejo=Portal (of the platform)
+* Forgejo has a 'Frontend' - this is the touchpoint for users (like HTML-browsers)
+* Forgejo has a backend, which delivers the content to be presented in the frontend
+
+## issues
+
+* Michael into ArchMeeting?! (agreement!)
+    * Robert/Stepan: discusion about our mindset - mobbing as avoiding missing detailed planning, in two streams
+    * Michael - Michal, Felix sind das 'Portal-Frontend'
+        * Tickets in Jira currently
+        * TODO creating tickets in forgejo / porting tickets from Jira
+        * we create the new forgejo-proect 'Portal-Frontend'
+        * zweiter meilenstein: Backend-activities need to be adressed in the future 
+* TODO have a look into the old backstage-portal
+
+* TODO Stephna an Julius ... Logo/CICD: We should define Logo/name tenant name, product name, url schemas
+
+### Development lifecycle
+
+* create project in CFor
+* create tasks in CFor
+* TODO Stephan possible tasks
+    * Environments -> let's provide a 'productline-forgejo' env in OTC!
+    * Pipelines
+    * check all tests!
+
+### Architecture
+
+* Goals:
+    * Stay Open Source compatible!
+    * stay forgejo-downstreaming compatible!
+    * provide ADRs before breaking changes
+
+#### forgejo-Architecture
+
+* analyse, presnt ad discuss forgejo architecture
+* Notice [Forgejo-Design guidleine](https://codeberg.org/forgejo/design/)
+* Notice/You must read [Developer Doc](https://forgejo.org/docs/next/contributor/)
+

docs/technical-documentation/architecture/research/forgejo-opensource/licences.md

@@ -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.
+
+![alt text](forgejo-releases.jpg)
+
+
+## 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.
+
+---
+

docs/technical-documentation/concepts/.pages

@@ -0,0 +1,6 @@
+title: Concepts
+arrange:
+  - overview.md
+  - general
+  - customer-developer
+  - edp-developer

docs/technical-documentation/concepts/edp-developer/.pages

@@ -0,0 +1,10 @@
+title: edgeDeveloper Framework
+arrange:
+  - storyline.md
+  - introduction.md
+  - edge-developer-framework.md
+  - platforming.md
+  - orchestrators.md
+  - cnoe.md
+  - cnoe-showtime.md
+  - conclusio.md

docs/technical-documentation/concepts/edp-developer/7_conclusio/likec4.config.json

@@ -0,0 +1,3 @@
+{
+  "name": "project-management"
+}

docs/technical-documentation/concepts/edp-developer/orchestrators.md

@@ -6,7 +6,8 @@ description: Next level platforming is orchestrating platforms
 
 ## Summary
 
-When defining and setting up platforms next two intrinsic problems arise: 
+When defining and setting up platforms next two intrinsic problems arise:
+
 1. it is not declarative and automated
 2. it is not or least not easily changable
 
@@ -21,7 +22,7 @@ This is something extremely new since late 2023 - the rise of the automation of
 
 It was Humanitec creating a definition of platform architecture, as they needed to defien what they are building with their 'orchestrator':
 
-<img src="./vendor-neutral-idp-final.gif" width="600" alt="https://developer.humanitec.com/introduction/overview/">
+![https://developer.humanitec.com/introduction/overview/](./4_orchestrators/vendor-neutral-idp-final.gif)
 
 ## Declarative Platform Orchestration
 
@@ -29,16 +30,13 @@ Based on the refence architecture you next can build - or let's say 'orchestrate
 
 https://humanitec.com/reference-architectures
 
-<img src="./platform-architectures.webp" width="600" alt="https://humanitec.com/blog/aws-azure-and-gcp-open-source-reference-architectures-to-start-your-mvp">
+
+![https://humanitec.com/blog/aws-azure-and-gcp-open-source-reference-architectures-to-start-your-mvp](./4_orchestrators/platform-architectures.webp)
 
 > Hint: There is a [slides tool provided by McKinsey](https://platformengineering.org/blog/create-your-own-platform-engineering-reference-architectures) to set up your own platform deign based on the reference architecture 
 
-
-{{% pageinfo color="info" %}}
-### What comes next?
-
-[Next](../cnoe/) we'll see how we are going to do platform orchestration with CNOE!
-{{% /pageinfo %}}
+> What comes next?
+> [Next](./cnoe.md) we'll see how we are going to do platform orchestration with CNOE!
 
 ## Addendum
 
@@ -46,6 +44,4 @@ https://humanitec.com/reference-architectures
 
 You remember the [capability mappings from the time before orchestration](../platforming)? Here we have a [similar setup based on Humanitecs platform engineering status ewhite paper](https://humanitec.com/whitepapers/state-of-platform-engineering-report-volume-2):
 
-<img src="./platform-tooling-humanitec-platform-report-2024.PNG" width="600" alt="https://humanitec.com/whitepapers/state-of-platform-engineering-report-volume-2 Whitepaper_ State of Platform Engineering Report.pdf">
-
-
+![https://humanitec.com/whitepapers/state-of-platform-engineering-report-volume-2 Whitepaper_ State of Platform Engineering Report.pdf](./4_orchestrators/platform-tooling-humanitec-platform-report-2024.PNG)

docs/technical-documentation/concepts/edp-developer/platforming.md

@@ -18,7 +18,7 @@ Let's start with a look into the history of platform engineering. A good startin
 
 They create lots of [beautiful articles and insights](https://humanitec.com/blog), their own [platform products](https://humanitec.com/products/) and [basic concepts for the platform architecture](https://humanitec.com/platform-engineering) (we'll meet this later on!).
 
-<img src="./humanitec-history.png" width="600" alt="https://platformengineering.org/blog/the-story-of-platform-engineering">
+<img src="./3_platforming/humanitec-history.png" width="600" alt="https://platformengineering.org/blog/the-story-of-platform-engineering">
 
 
 ### Further nice reference to the raise of platforms
@@ -41,7 +41,7 @@ When looking at these 'capabilities', we have CNCF itself:
 
 There is a CNCF working group which provides the definition of [Capabilities of platforms](https://tag-app-delivery.cncf.io/whitepapers/platforms/#capabilities-of-platforms) and shows a first idea of the layered architecture of platforms as **service layer for developers** ("product and application teams"):
 
-<img src="./platforms-def.drawio.png" width="600">
+<img src="./3_platforming/platforms-def.drawio.png" width="600">
 
 
 > Important: As Platform engineer also notice the [platform-eng-maturity-model](https://tag-app-delivery.cncf.io/whitepapers/platform-eng-maturity-model/)
@@ -50,7 +50,7 @@ There is a CNCF working group which provides the definition of [Capabilities of
 
 Or, in another illustration for the platform as a developer service interface, which also defines the **'Platform Engineering Team'** inbetween: 
 
-<img src="./platform-self-services.webp" width="600" alt="https://medium.com/@bijit211987/what-is-platform-engineering-and-how-it-reduce-cognitive-load-on-developers-ac7805603925">
+<img src="./3_platforming/platform-self-services.webp" width="600" alt="https://medium.com/@bijit211987/what-is-platform-engineering-and-how-it-reduce-cognitive-load-on-developers-ac7805603925">
 
 ## How to set up Platforms
 
@@ -77,7 +77,7 @@ Build or buy - this is also in pltaform engineering a tweaked discussion, which
 {{% pageinfo color="info" %}}
 ### What comes next?
 
-[Next](../orchestrators/) we'll see how these concepts got structured!
+[Next](./orchestrators.md) we'll see how these concepts got structured!
 {{% /pageinfo %}}
 
 ## Addendum

docs/technical-documentation/concepts/edp-developer/storyline.md

@@ -1,3 +1,11 @@
+---
+title: 'Storyline'
+linktitle: Conceptual Onboarding
+weight: 20
+description: How to conceptually onboard onto the Edge Developer Framework (EDF) requirements and the designed solution
+---
+
+# Platform 101: Conceptual Onboarding
 
 ## Storyline 
 
@@ -24,5 +32,3 @@
 3. Don't miss to further investigate and truely understand **CNOE solution**
 
 ## Architecture
-
-