feat(forgejo): added readable markdown for the repo-org model of forgejo

devbox.json

@@ -1,6 +1,9 @@
 {
-  "$schema":  "https://raw.githubusercontent.com/jetify-com/devbox/0.14.0/.schema/devbox.schema.json",
+  "$schema": "https://raw.githubusercontent.com/jetify-com/devbox/0.14.0/.schema/devbox.schema.json",
-  "packages": ["nodejs@latest"],
+  "packages": [
+    "nodejs@latest",
+    "terraform@latest"
+  ],
   "shell": {
     "init_hook": [
       "echo 'Welcome to devbox!' > /dev/null"

devbox.lock

@@ -68,6 +68,54 @@
           "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/architecture/decisions/design-documents/_index.md

@@ -0,0 +1,9 @@
+---
+title: Design
+weight: 1
+description: Edge Developver Framework Design Documents
+---
+
+This design documentation structure is inspired by the [design of crossplane](https://github.com/crossplane/crossplane/tree/main/design#readme).
+
+

docs/technical-documentation/architecture/decisions/environment-hierarchy.md

@@ -0,0 +1,51 @@
+# proposal: how to (re)structure our infrastructure setup
+
+what we have:
+* different providers - currently OTC and kind
+* different groups of environments - currently called 'environment_namespace'
+* different environments in each group of environments
+* environments are called 'cluster_environment' and are terragrunt stacks, i.e. a huge set of resources where the kubernetes cluster itself is only one of them
+* the top domain name (like t09.de, buildth.ing) is bound to the environment group
+
+issues:
+* in provider OTC there are two attributes for the environment group - 'tenant' and 'environment_namespace' are the same 
+* missing hierarchy for other providers than otc - we directly start with 'prod' and 'non-prod' right now
+
+## opportunity
+
+right now we start switching to go code.
+we can use this port to also restructure, generalize and improve the infrastructure and platfrom-provisioning.
+
+
+## proposed environment hierarchy
+
+* new: the 'environment_namespace' layer is called 'platformzone': "A neutral, abstract term that encompasses both the isolation (account, tenant, subscription) and the operational context (prod vs. non-prod)." (ChatGPT)
+* new: folder 'environments'
+* new: level 1 hierarchy 'provider'
+* old: level 2 hierarchy 'platformzone'
+* old: level 3 hierarchy 'environment'
+
+### visualization
+
+```bash
+environments
+├── provider:kind
+│   └── platformzone:non-prod e.g.vm-1 or local
+│       ├── edp
+│       └── observability
+├── provider:otc
+│   ├── platformzone:non-prod i.e. tenant-1
+│   │   ├── central-forgejo-aka-edp
+│   │   ├── forgejo-dev
+│   │   └── observability
+│   └── platformzone:prod i.e. tenant-2
+│       ├── edp
+│       └── observability
+└── provider:scaleway
+    ├── platformzone:non-prod e.g. account-1
+    └── platformzone:prod e.g. account-2
+        ├── edp
+        └── observability
+```
+
+![alt text](environments.png)

docs/technical-documentation/architecture/decisions/environments.puml

@@ -0,0 +1,42 @@
+@startuml
+!includeurl https://raw.githubusercontent.com/plantuml-stdlib/C4-PlantUML/master/C4_Context.puml
+
+LAYOUT_WITH_LEGEND()
+
+Person(dev, "Developer")
+
+System_Boundary(env, "environments") {
+    
+    System_Boundary(kind, "provider:kind") {
+        System_Boundary(kind_np, "platformzone:non-prod (vm-1 / local)") {
+            System(edp_kind, "edp")
+            System(obs_kind, "observability")
+        }
+    }
+
+    System_Boundary(otc, "provider:otc") {
+        System_Boundary(otc_np, "platformzone:non-prod (tenant-1)") {
+            System(edp_otc_np, "central-forgejo-aka-edp")
+            System(forgejo_dev, "forgejo-dev")
+            System(obs_otc_np, "observability")
+        }
+
+        System_Boundary(otc_prod, "platformzone:prod (tenant-2)") {
+            System(edp_otc_p, "edp")
+            System(obs_otc_p, "observability")
+        }
+    }
+
+    System_Boundary(scaleway, "provider:scaleway") {
+        System_Boundary(scaleway_np, "platformzone:non-prod (account-1)") {
+            ' leer
+        }
+
+        System_Boundary(scaleway_p, "platformzone:prod (account-2)") {
+            System(edp_scaleway_p, "edp")
+            System(obs_scaleway_p, "observability")
+        }
+    }
+}
+
+@enduml

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

@@ -1,9 +1,22 @@
----
+# EDP Design
-title: Design
-weight: 1
-description: Edge Developver Framework Design Documents
----
 
-This design documentation structure is inspired by the [design of crossplane](https://github.com/crossplane/crossplane/tree/main/design#readme).
+## Mission, High level arch
+
+* Date: May 2025
+
+![alt text](high-level-arch.png)
+
+* [Link to the powerpoint in internal MMS Sharepoint](https://telekom.sharepoint.de/:p:/r/sites/IPCEICIS/Freigegebene%20Dokumente/8%20Sub-Projects/Developer%20Framework/02%20Solution%20Development%20Track/EDP%20-%20High-Level%20Architecture%20-%20Draft%20v0.1.pptx?d=wa333a7fef6684bb6b606c977a82d8736&csf=1&web=1&e=bkvKwM)
 
 
+We create a developer platform, comparable to replit or humanitec. In the first milestone of the product, the functionality is essentially ‘github clone’ and we use Forgejo as implementation (version control, project management, CI/CD). Forgejo is also extended as a portal, e.g. to implement functionalities such as those that exist in Backstage. The orchestration of the platform is done via Forgejo pipelines and argocd and kubernetes operators. The deployment is in a European cloud (currently OTC), completely as infrastructure as code.
+
+
+## Guidelines / Competitor claims
+
+* Railway: Every application stack is different, but the building blocks are similar. These are the core primitives behind every app hosted on Railway.
+
+* Qovery is a DevOps Automation Tool that eliminates your DevOps hiring needs. Provision and maintain a secure and compliant infrastructure in hours - not months!
+* Railway is a deployment platform that lets you provision infrastructure, develop locally with that infrastructure, and deploy to the cloud or simply run ready-made software from our template marketplace.
+
+[![alt text](humanitec-orchestrator.png)](https://humanitec.com/products/platform-orchestrator)

docs/technical-documentation/architecture/design/prototype-forgejo-as-a-service/index.md

@@ -0,0 +1,86 @@
+# 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
+
+## Design links to lucid app
+
+* [Architecture](https://lucid.app/lucidspark/7134abcb-0c5e-41e5-93da-7118e285a668/edit?invitationId=inv_fbf0d105-7023-4740-806e-fcbb522ea61a&page=0_0#)
+* [Roadmap](https://lucid.app/lucidspark/16a4c21e-5798-4562-9a59-14b54e722124/edit?invitationId=inv_17de9c72-a92f-4544-a6c3-08e52dd336a2&page=0_0#)
+
+## Roadmap Forgejo-as-a-Service
+
+![Roadmap](./_assets/roadmap.png)
+
+![alt text](./_assets/8-weeks-goal.png)
+
+## 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
+
+### Deployment
+
+![alt text](./_assets/deployment-c4.png)
+
+### 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)
+
+## Mob working mode
+
+![alt text](./_assets/mob-working.png)
+
+## IAM (OTC)
+
+![alt text](./_assets/iam-otc.png)
+
+## Environment / Deployment plan
+
+![envs](./_assets/deployment.svg)
+
+![alt text](./_assets/deloyment-faas.png)

docs/technical-documentation/architecture/design/prototype-forgejo-as-a-service/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/design/prototype-forgejo-projectmanagement/index.md

@@ -0,0 +1,3 @@
+# Prototype Forgejo ProjectManagement
+
+https://lucid.app/lucidspark/d2eb9577-78dd-42c9-b84b-b00958f381d5/edit?invitationId=inv_de56db0a-3439-44b3-8c48-b8e274f52256&page=0_0#

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

@@ -0,0 +1,794 @@
+# 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.
+* [MMS-OSS](https://confluence.telekom-mms.com/spaces/MMSMTB/pages/717458132/Open+Source+License+Compliance)
+* [Security-Checklist](https://github.com/ossf/scorecard/blob/main/docs/checks.md)
+
+### 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)
+
+## MMS Support
+
+```
+
+
+Von: Schurz, Martin <Martin.Schurz@telekom.de> 
+Gesendet: Dienstag, 10. Juni 2025 16:47
+An: Lo, Stephan <Stephan.Lo@telekom.de>
+Betreff: AW: Going OS, z.B. in Codeberg - Anschubfragen :-)
+
+Hi Stephan,
+
+an sich gibt’s da überraschend wenig zu beachten.
+
+Einer der relevanten Punkte ist die Wahl der Lizenz, da gibt es hier Hilfestellungen: https://confluence.telekom-mms.com/spaces/MMSMTB/pages/717458132/Open+Source+License+Compliance
+Dann lohnt meist noch ein Blick in Richtung Security, dafür hat es hier ne schöne Sammlung: https://github.com/ossf/scorecard/blob/main/docs/checks.md
+
+Alles andere ist effektiv nur ongoing Maintanance.
+Du kannst mir gerne mal nen Termin Ende Juni, nachdem MMS Geburtstag, einstellen, dann können wir ein wenig drüber reden.
+
+Grüße
+Martin 
+
+-- 
+Deutsche Telekom MMS GmbH
+Agile Operations & Cloud
+
+Martin Schurz
+IT Architect
+
+Riesaer Strasse 5, 01129 Dresden
++49 351 2820-2773
+Martin.Schurz@telekom.de 
+
+You can find the compulsory statement on: www.telekom-mms.com/pflichtangaben
+
+Von: Lo, Stephan <Stephan.Lo@telekom.de> 
+Gesendet: Donnerstag, 5. Juni 2025 08:00
+An: Schurz, Martin <Martin.Schurz@telekom.de>
+Betreff: Going OS, z.B. in Codeberg - Anschubfragen :-)
+
+Hallo Martin,
+
+du hast ja so schön mit mir die Telekom-MMS Organistaion auf Codeberg errichtet (https://codeberg.org/telekom-mms) – jetzt überlegen wir uns (also das IPCEICIS-Platform-Projekt), ob und wie wir da unseren Code eröffenltichne wollen/können.
+
+Ich selbst bin da ohne Erfahrung, und Stefan ist ja nicht mehr da.
+Jetzt denke ich mir, ob es vielleicht Bets Prectices aus der MMS gibt, die ich mal gegenlesen/konsumieren und bewerten könnte?
+
+Hättest du hierfür einen Einstiegspunkt für mich? 
+Oder auch die Möglichkeit einer kleinen Session? 
+Und/oder gibt es weitere Player/Experten, die ich ansprechen kann?
+
+Danke dir für ein paar ratschläge!
+
+Stephan
+```
+
+
+## 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/product/components/Backstage/backstage-update-tutorial/_index.md

@@ -0,0 +1,103 @@
+---
+title: Backstage Update Tutorial
+---
+
+The first Backstage update was performed as described in the ticket https://jira.telekom-mms.com/browse/IPCEICIS-2299 from version 1.28 to version 1.36.1.
+
+This document provides a detailed guide on the process to update Backstage locally on your machine from version 1.36.1 to 1.38.1.
+Later updates can be performed accordingly. (The fixing of deprecated imports should not be necessary, again.)
+
+## Table of Contents
+
+1. [Prerequisites](#prerequisites)
+2. [Setting Up Backstage](#setting-up-backstage)
+3. [Updating Backstage](#updating-backstage)
+4. [Fix deprecated import](#fix-deprecated-import)
+5. [Running Backstage](#running-backstage)
+
+## Prerequisites <a name="prerequisites"></a>
+
+Before you start, make sure you have the following installed on your machine:
+
+1. **Node.js**: Backstage requires Node.js. You can download it from the [Node.js website](https://nodejs.org/).
+2. **Yarn**: Backstage uses Yarn as its package manager.
+3. **Git**
+4. **Docker**
+
+## Setting Up Backstage <a name="setting-up-backstage"></a>
+
+To download the latest version of our Backstage-EDP app, use git to clone it from the OSC repository at https://forgejo.edf-bootstrap.cx.fg1.ffm.osc.live/DevFW-CICD/backstage-edp.git.
+
+Make sure yarn ist installed locally. If it hasn't been installed yet, run in the project path:
+   ```bash
+   yarn install
+   ```
+
+## Updating Backstage <a name="updating-backstage"></a>
+
+In the project path run:
+   ```bash
+   yarn backstage-cli versions:bump
+   ```
+
+This will update all relevant components to the newest versions.
+
+## Fix deprecated import <a name="fix-deprecated-import"></a>
+
+In a text editor of your choice open the file <I>'/backstage-edp/packages/backend/src/plugins/proxy.ts'</I> and implement the two following changes.
+
+### Update import
+
+First (due to changes in the library) replace the deprecated import
+
+   ```typescript
+   import { createRouter } from '@backstage/plugin-proxy-backend';
+   ```
+
+with the following import:
+
+   ```typescript
+   import { createRouter } from '@roadiehq/backstage-plugin-argo-cd-backend';
+   ```
+
+### Update method call createRouter()
+
+Secondly (due to a changed signature) replace the <B>old</B> call of method createRouter() 
+
+   ```typescript
+  return await createRouter({
+    logger: env.logger,
+    config: env.config,
+    discovery: env.discovery
+  });
+   ```
+
+with the following <B>new</B> method call:
+
+   ```typescript
+  return await createRouter({
+    logger: env.logger,
+    config: env.config
+  });
+   ```
+
+## Running backstage <a name="running-backstage"></a>
+
+After completing all updates and fixes, run backstage to verify everything was updated correctly.
+
+In the project path run:
+   ```bash
+   docker build --no-cache -t backstage-cnoe .
+   ```
+
+Start the backend from a console:
+   ```bash
+   yarn run start-backend
+   ```
+
+Start the frontend from a console:
+   ```bash
+   yarn run start
+   ```
+
+The backstage frontend should now open in your browser.

docs/technical-documentation/product/components/forgejo/index.md

@@ -0,0 +1,77 @@
+# Forgejo
+
+## Meta
+
+* https://codeberg.org/forgejo
+* https://codeberg.org/forgejo#meta
+
+## Forgejo Development
+
+* https://forgejo.org/docs/v1.21/developer/architecture/
+* https://forgejo.org/docs/v1.21/developer/customization/
+
+## UI
+
+* https://codeberg.org/forgejo/discussions/issues/338
+
+## Tasks
+
+Abstimmung mit Micha (Marschner), 06.05.25:
+
+1. Einarbeiten, Development Model, zB. Astro Framework
+1. Soft-Forking, Down/Up-Streaming
+1. 'Sparring' User experience
+
+Koordination:
+* Hinweis: '8 Wochen MVP Forgejo-as-a-Service' ist derzeit der Fokus auf das SaaS in der OTC
+* In dieser zeit arbeitet Julius an der UX-Architekturkonzeption 
+* Michael arbeitet sich ein, Technologie-Stack verstehen
+* 'Zum laufen bekommen': Lokales Aufsetzen als Nächstes gemeinsam -> Termin stellt Stephan ein
+
+## Local Development
+
+### method 1: docker compose with forgejo:latest
+
+Method 1: run a latest forgejo with sqlite - configuration is done on first login
+
+* https://forgejo.org/docs/latest/admin/installation-docker/
+
+```bash
+docker compose up -d
+
+# open localhost:3000
+
+# check registry
+
+docker login localhost:3000
+
+docker image push localhost:3000/<user>/<image>
+```
+
+### method 2: install and develop it from source
+
+* https://codeberg.org/forgejo/forgejo.git 
+
+```bash
+git clone https://codeberg.org/forgejo/forgejo.git 
+
+# enter devcontainer in VSC (takes 10 mins for the first time)
+
+# make build
+
+# then run ./gitea (sic!) --help
+# also see ./gitea forgejo-cli actions
+```
+
+### method 3: 'setup forgejo' (with runner)
+
+* https://code.forgejo.org/actions/setup-forgejo
+
+Additional links:
+* 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/
+
+```bash
+git clone https://code.forgejo.org/actions/setup-forgejo.git
+```

docs/technical-documentation/product/components/forgejo/local-development/local-development-onboarding.md

@@ -0,0 +1,290 @@
+# Forgejo
+
+In the following you will find 
+
+* a lot of interestimg Forgejo links 
+* to to local setup and local development
+* and 4 methods to set up Forgejo locally
+* 3 times based only on Docker
+* and once only based on Go et.al.
+
+## Local Setup and Development
+
+### Forgejo Releases
+
+* https://forgejo.org/releases/
+
+-> the current release is 11.0
+
+### method 1: docker ( - compose) with forgejo
+
+Method 1 is just run the or a docker image.
+To be more comfortable in the parameters we can use a docker-compose file.
+
+run a latest forgejo with sqlite - configuration is done on first login
+
+* https://forgejo.org/docs/latest/admin/installation-docker/
+
+#### prepare and investigate the image
+
+```bash
+docker pull codeberg.org/forgejo/forgejo:11
+
+docker inspect codeberg.org/forgejo/forgejo:11
+# check cmd and entrypoint
+
+    # "Env": [
+    #     "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
+    #     "USER=git",
+    #     "GITEA_CUSTOM=/data/gitea"
+    # ],
+    # "Cmd": [
+    #     "/usr/bin/s6-svscan",
+    #     "/etc/s6"
+    # ],
+    # "WorkingDir": "/",
+    # "Entrypoint": [
+    #     "/usr/bin/entrypoint"
+    # ],
+
+# run the image with a cli
+docker run -it --entrypoint="" codeberg.org/forgejo/forgejo:11 bash
+
+# in the container
+cat /usr/bin/entrypoint
+# if [ $# -gt 0 ]; then
+#     exec "$@"
+# else
+#     exec /usr/bin/s6-svscan /etc/s6
+# fi
+
+# check /etc/s6
+
+tree /etc/s6/
+# /etc/s6/
+# ├── gitea
+# │   ├── finish
+# │   ├── run
+# │   └── setup
+# └── openssh
+#     ├── finish
+#     ├── run
+#     └── setup
+
+cat /etc/s6/gitea/run 
+# #!/bin/bash
+# [[ -f ./setup ]] && source ./setup
+
+# pushd /app/gitea >/dev/null
+# exec su-exec $USER /usr/local/bin/gitea web
+# popd
+
+cat /etc/s6/gitea/setup 
+# #!/bin/bash
+
+# if [ ! -d /data/git/.ssh ]; then
+#     mkdir -p /data/git/.ssh
+# fi
+
+# # Set the correct permissions on the .ssh directory and authorized_keys file,
+# # or sshd will refuse to use them and lead to clone/push/pull failures.
+# # It could happen when users have copied their data to a new volume and changed the file permission by accident,
+# # and it would be very hard to troubleshoot unless users know how to check the logs of sshd which is started by s6.
+# chmod 700 /data/git/.ssh
+# if [ -f /data/git/.ssh/authorized_keys ]; then
+#     chmod 600 /data/git/.ssh/authorized_keys
+# fi
+
+# if [ ! -f /data/git/.ssh/environment ]; then
+#     echo "GITEA_CUSTOM=$GITEA_CUSTOM" >| /data/git/.ssh/environment
+#     chmod 600 /data/git/.ssh/environment
+
+# elif ! grep -q "^GITEA_CUSTOM=$GITEA_CUSTOM$" /data/git/.ssh/environment; then
+#     sed -i /^GITEA_CUSTOM=/d /data/git/.ssh/environment
+#     echo "GITEA_CUSTOM=$GITEA_CUSTOM" >> /data/git/.ssh/environment
+# fi
+
+# if [ ! -f ${GITEA_CUSTOM}/conf/app.ini ]; then
+#     mkdir -p ${GITEA_CUSTOM}/conf
+
+#     # Set INSTALL_LOCK to true only if SECRET_KEY is not empty and
+#     # INSTALL_LOCK is empty
+#     if [ -n "$SECRET_KEY" ] && [ -z "$INSTALL_LOCK" ]; then
+#         INSTALL_LOCK=true
+#     fi
+
+#     # Substitute the environment variables in the template
+#     APP_NAME=${APP_NAME:-"Forgejo: Beyond coding. We forge."} \
+#     RUN_MODE=${RUN_MODE:-"prod"} \
+#     DOMAIN=${DOMAIN:-"localhost"} \
+#     SSH_DOMAIN=${SSH_DOMAIN:-"localhost"} \
+#     HTTP_PORT=${HTTP_PORT:-"3000"} \
+#     ROOT_URL=${ROOT_URL:-""} \
+#     DISABLE_SSH=${DISABLE_SSH:-"false"} \
+#     SSH_PORT=${SSH_PORT:-"22"} \
+#     SSH_LISTEN_PORT=${SSH_LISTEN_PORT:-"${SSH_PORT}"} \
+#     LFS_START_SERVER=${LFS_START_SERVER:-"false"} \
+#     DB_TYPE=${DB_TYPE:-"sqlite3"} \
+#     DB_HOST=${DB_HOST:-"localhost:3306"} \
+#     DB_NAME=${DB_NAME:-"gitea"} \
+#     DB_USER=${DB_USER:-"root"} \
+#     DB_PASSWD=${DB_PASSWD:-""} \
+#     INSTALL_LOCK=${INSTALL_LOCK:-"false"} \
+#     DISABLE_REGISTRATION=${DISABLE_REGISTRATION:-"false"} \
+#     REQUIRE_SIGNIN_VIEW=${REQUIRE_SIGNIN_VIEW:-"false"} \
+#     SECRET_KEY=${SECRET_KEY:-""} \
+#     envsubst < /etc/templates/app.ini > ${GITEA_CUSTOM}/conf/app.ini
+
+#     chown ${USER}:git ${GITEA_CUSTOM}/conf/app.ini
+# fi
+
+# # Replace app.ini settings with env variables in the form GITEA__SECTION_NAME__KEY_NAME
+# environment-to-ini --config ${GITEA_CUSTOM}/conf/app.ini
+
+# # only chown if current owner is not already the gitea ${USER}. No recursive check to save time
+# if ! [[ $(ls -ld /data/gitea | awk '{print $3}') = ${USER} ]]; then chown -R ${USER}:git /data/gitea; fi
+# if ! [[ $(ls -ld /app/gitea  | awk '{print $3}') = ${USER} ]]; then chown -R ${USER}:git /app/gitea;  fi
+# if ! [[ $(ls -ld /data/git   | awk '{print $3}') = ${USER} ]]; then chown -R ${USER}:git /data/git;   fi
+# chmod 0755 /data/gitea /app/gitea /data/git
+```
+
+#### Outcome
+
+The container will run 
+* /usr/local/bin/gitea web 
+* with USER=git
+* and DB_TYPE=${DB_TYPE:-"sqlite3"
+
+
+#### prepare the docker compose file
+
+From the [link above](https://forgejo.org/docs/latest/admin/installation-docker/) copy and create a docker-compose.yml like this:
+
+```bash
+echo $"
+networks:
+  forgejo:
+    external: false
+
+services:
+  server:
+    image: codeberg.org/forgejo/forgejo:11
+    container_name: forgejo
+    environment:
+      - USER_UID=1000
+      - USER_GID=1000
+    restart: always
+    networks:
+      - forgejo
+    volumes:
+      - ./forgejo:/data
+      - /etc/timezone:/etc/timezone:ro
+      - /etc/localtime:/etc/localtime:ro
+    ports:
+      - '3000:3000'
+      - '222:22'
+" >> docker-compose.yml
+```
+
+### Run the container and open the WebUI
+
+```bash
+docker compose up -d
+
+# open http://localhost:3000
+
+### test: Check the registry 
+
+# check registry
+
+docker login localhost:3000
+
+docker image push localhost:3000/<user>/<image>
+```
+
+### method 2: install and develop it from source
+
+The next real 'do development' setup method is by running the source. 
+
+
+* https://codeberg.org/forgejo/forgejo.git 
+
+```bash
+git clone https://codeberg.org/forgejo/forgejo.git 
+
+# enter devcontainer in VSC (takes 10 mins for the first time)
+
+# make build
+
+# then run ./gitea (sic!) --help
+# also see ./gitea forgejo-cli actions
+```
+
+### method 3: setup (a bit) declarativly - Forgejo and Forgejo Runner
+
+#### The kubernetes operator way
+
+The highly sophisticated way to do a declarative setup is already provided by the [Forgejo-Operator](https://forgejo.edf-bootstrap.cx.fg1.ffm.osc.live/DevFW/forgejo-operator) running your desired forgejo and forgejo runner state by an operator as custom ressources.
+
+#### The docker-compose way
+
+You can also run both [Forgejo and Forgejo Runner the pure docker way.](https://forgejo.edf-bootstrap.cx.fg1.ffm.osc.live/stephan.lo/stl-edp/src/branch/development/09-forgejo)
+
+```bash
+git clone https://forgejo.edf-bootstrap.cx.fg1.ffm.osc.live/stephan.lo/stl-edp.git
+
+git checkout development
+
+cd 09-forgejo
+
+# spin up
+# ... first check and understand the content of the script !
+./spin-up.sh
+
+# destroy
+./teardown.sh
+```
+
+Also have a look into the linsk provided in the README, especially https://codeberg.org/forgejo-contrib/delightful-forgejo
+
+### method 4: 'setup forgejo' (with runner)
+
+Really funny and promisingly looking high-end-community-development stuff is this:
+
+* https://code.forgejo.org/actions/setup-forgejo
+
+
+```bash
+git clone https://code.forgejo.org/actions/setup-forgejo.git
+```
+
+
+## References 
+
+### Meta
+
+* https://codeberg.org/forgejo
+
+### Forgejo Development
+
+* https://forgejo.org/docs/v1.21/developer/architecture/
+* https://forgejo.org/docs/v1.21/developer/customization/
+
+### UI
+
+* https://codeberg.org/forgejo/discussions/issues/338
+
+### Some nice Setup references
+
+* 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/)

docs/technical-documentation/product/components/forgejo/repo-access-model-and-organisations/admin-cli-commands.md

@@ -0,0 +1,35 @@
+
+create user with simple password which doesn't need to be changed:
+
+forgejo admin user create --username user-8 --email user-8@u.de --password p --must-change-password=false
+
+
+create admin token in forgejo-instance with forgejo admin
+
+
+410880a9c760:/var/lib/gitea$ forgejo admin user generate-access-token --username admin2 --token-name "automation-token4" --scopes write:admin,write:repository,write:organization,write:user,write:issue,write:misc
+Access token was successfully created: d7497188e767ec44bfa06424e25cc7d2387399a0
+
+add logn to tea
+
+tea login add --url http://localhost:3000 --token d7497188e767ec44bfa06424e25cc7d2387399a0 --name myadmin
+
+
+login to myadmin
+
+
+❯ tea login
+┌────────────────┬───────────────────────┬────────────────┬──────────┬─────────┐
+│      NAME      │          URL          │    SSH HOST    │   USER   │ DEFAULT │
+├────────────────┼───────────────────────┼────────────────┼──────────┼─────────┤
+│ localhost:3000 │ http://localhost:3000 │ localhost:3000 │ admin2   │ false   │
+│ admin          │ http://localhost:3000 │ localhost:3000 │ johannes │ false   │
+│ myadmin        │ http://localhost:3000 │ localhost:3000 │ admin2   │ false   │
+└────────────────┴───────────────────────┴────────────────┴──────────┴─────────┘
+❯ tea login myadmin
+
+  myadmin                                                                                                             
+                                                                                                                      
+ @admin2 http://localhost:3000/admin2                                                                                 
+                                                                                                                      
+ Created: 29 Jun 25 12:39 CEST  

docs/technical-documentation/product/components/forgejo/repo-access-model-and-organisations/organisations.md

@@ -0,0 +1,82 @@
+
+# Forgejo's entities' relations repo, organisation, team, user
+
+## small: only one comment
+
+![alt text](org-repo-user-small.png)
+
+## normal model
+
+![alt text](org-repo-user.png)
+
+## large
+
+![alt text](org-repo-user-large.png)
+
+## large packaged
+
+![alt text](org-repo-user-large-packaged.png)
+
+
+Das `owners`-Team in Gitea/Forgejo ist **etwas Besonderes** und tatsächlich **hardcoded** – hier sind die Details:
+
+---
+
+## 🧠 Bedeutung des `owners` Teams
+
+### 🟩 Es ist **automatisch vorhanden**
+
+* Jede Organisation hat immer ein Team namens `owners`.
+* Dieses Team wird **automatisch erstellt**, wenn die Organisation erstellt wird.
+
+### 🔐 Es hat **immer Admin-Rechte**
+
+* Mitglieder des `owners`-Teams haben **volle Admin-Rechte** auf:
+
+  * alle Repositories der Organisation
+  * alle Teams
+  * die Organisation selbst (z. B. Mitgliederverwaltung, Einstellungen)
+* Rechte können **nicht reduziert** oder **entfernt** werden.
+* Nur Mitglieder dieses Teams können:
+
+  * neue Teams erstellen oder löschen
+  * andere Mitglieder zum `owners`-Team hinzufügen oder entfernen
+
+### 🔒 Sicherheitsrelevant
+
+* Dieses Team steuert **letztlich die Kontrolle über die gesamte Organisation**.
+* Es ist vergleichbar mit „Org Admins“.
+
+---
+
+## 🔧 Muss ich das `owners`-Team konfigurieren?
+
+### Nein – aber:
+
+* Du **musst es nicht konfigurieren**, es funktioniert immer.
+* Du **kannst Mitglieder hinzufügen oder entfernen**, aber **nicht das Team selbst löschen oder umbenennen**.
+
+### ✅ Empfehlungen:
+
+* Nur vertrauenswürdige Personen (z. B. Projekt-Admins) sollten im `owners`-Team sein.
+* Für andere Rollen (Contributor, Maintainer, Leser) solltest du **eigene Teams** mit passenden Rechten erstellen.
+
+---
+
+## 📘 Beispiel: Organisation mit klarer Rollentrennung
+
+| Team           | Beschreibung              | Rechte                     |
+| -------------- | ------------------------- | -------------------------- |
+| `owners`       | Orga-Admins (hartkodiert) | Admin                      |
+| `maintainers`  | Aktive Maintainer         | Admin/Write je nach Bedarf |
+| `contributors` | Beitragende Entwickler    | Write                      |
+| `readers`      | Dürfen nur lesen          | Read                       |
+
+---
+
+Wenn du möchtest, kann ich dir auch ein Skript bauen, das sicherstellt:
+
+* Nur bestimmte Benutzer im `owners`-Team sind
+* Alle anderen automatisch in passende andere Teams sortiert werden
+
+Möchtest du so ein Beispiel oder ein Review-Skript für Orga-Mitglieder und deren Rechte?

docs/technical-documentation/product/components/forgejo/repo-access-model-and-organisations/user-orgamnisation-team-entity-model-large-packaged.puml

@@ -0,0 +1,63 @@
+@startuml
+package "Forgejo/Gitea System" {
+
+  package "Systemweite Benutzer & Rollen" {
+    class User {
+      + id: int
+      + username: string
+      + email: string
+    }
+  }
+
+  package Organisation {
+    class Organisation {
+      + id: int
+      + name: string
+    }
+
+    class OrgMember {
+      + user_id: int
+      + org_id: int
+      + is_owner: bool
+      + role: string
+    }
+
+    class Team {
+      + id: int
+      + org_id: int
+      + name: string
+      + permission_level: string
+    }
+  }
+
+  package Repository {
+    class Repository {
+      + id: int
+      + owner_id: int
+      + name: string
+      + is_private: bool
+    }
+  }
+
+  User "1" -- "0..*" OrgMember : membership
+  Organisation "1" -- "0..*" OrgMember : members
+  Organisation "1" -- "0..*" Team : teams
+  Team "1" -- "0..*" User : members
+  Team "1" -- "0..*" Repository : repos
+
+  Organisation "1" -- "0..*" Repository : owns
+
+  note right of OrgMember
+    Owner (is_owner = true) kann:
+    - Organisation verwalten
+    - Teams erstellen/löschen
+    - Mitglieder verwalten
+  end note
+
+  note left of Repository
+    Zugriff durch Teams nur möglich, wenn
+    Repository zu Organisation gehört.
+    Owner können Repository voll verwalten.
+  end note
+}
+@enduml

docs/technical-documentation/product/components/forgejo/repo-access-model-and-organisations/user-orgamnisation-team-entity-model-large.puml

@@ -0,0 +1,58 @@
+@startuml
+scale 500 width
+package "Forgejo/Gitea User-Organisation-Repo-Modell" {
+
+  class User {
+    + id: int
+    + username: string
+    + email: string
+  }
+
+  class Organisation {
+    + id: int
+    + name: string
+  }
+
+  class OrgMember {
+    + user_id: int
+    + org_id: int
+    + is_owner: bool
+    + role: string
+  }
+
+  class Team {
+    + id: int
+    + org_id: int
+    + name: string
+    + permission_level: string
+  }
+
+  class Repository {
+    + id: int
+    + owner_id: int
+    + name: string
+    + is_private: bool
+  }
+
+  User "1" -- "0..*" OrgMember : membership
+  Organisation "1" -- "0..*" OrgMember : members
+  Organisation "1" -- "0..*" Team : teams
+  Team "1" -- "0..*" User : members
+  Team "1" -- "0..*" Repository : repos
+
+  Organisation "1" -- "0..*" Repository : owns
+
+  note right of OrgMember
+    Owner (is_owner = true) kann:
+    - Organisation verwalten
+    - Teams erstellen/löschen
+    - Mitglieder verwalten
+  end note
+
+  note left of Repository
+    Zugriff durch Teams nur möglich, wenn
+    Repository zu Organisation gehört.
+    Owner können Repository voll verwalten.
+  end note
+}
+@enduml

docs/technical-documentation/product/components/forgejo/repo-access-model-and-organisations/user-orgamnisation-team-entity-model-small.puml

@@ -0,0 +1,56 @@
+@startuml
+left to right direction
+skinparam linetype ortho
+skinparam classAttributeIconSize 0
+hide circle
+
+' Gruppierungen
+package "Systemweite Benutzer und Rollen" {
+  class User {
+    +username
+    +email
+    +isAdmin
+  }
+
+  note right of User
+    Kann Organisationen erstellen
+    Kann eigenen Namespace verwalten
+    Kann systemweiter Admin sein
+  end note
+}
+
+package "Organisation" {
+  class Organisation {
+    +name
+    +visibility
+  }
+
+  class Team {
+    +name
+    +permissionLevel
+    +canCreateRepos
+  }
+
+  class OrgMember {
+    +role: member / owner
+  }
+
+  Organisation "1" -- "0..*" Team : verwaltet >
+  Organisation "1" -- "0..*" OrgMember : hat Mitglieder >
+  User "1" -- "0..*" OrgMember : ist >
+
+  OrgMember "1" -- "0..*" Team : gehört zu >
+}
+
+package "Repository" {
+  class Repository {
+    +name
+    +visibility
+    +owner: User|Organisation
+  }
+
+  Team "1" -- "0..*" Repository : Zugriff auf >
+  User "1" -- "0..*" Repository : direkte Rechte (optional) >
+}
+
+@enduml

docs/technical-documentation/product/components/forgejo/repo-access-model-and-organisations/user-orgamnisation-team-entity-model.puml

@@ -0,0 +1,62 @@
+@startuml
+left to right direction
+skinparam linetype ortho
+skinparam classAttributeIconSize 0
+hide circle
+
+' Gruppierungen
+package "Systemweite Benutzer und Rollen" {
+  class User {
+    +username
+    +email
+    +isAdmin
+  }
+
+  note right of User
+    Kann Organisationen erstellen
+    Kann eigenen Namespace verwalten
+    Kann systemweiter Admin sein
+  end note
+}
+
+package "Organisation" {
+  class Organisation {
+    +name
+    +visibility
+  }
+
+  class Team {
+    +name
+    +permissionLevel
+    +canCreateRepos
+  }
+
+  class OrgMember {
+    +role: member / owner
+  }
+
+  Organisation "1" -- "0..*" Team : verwaltet >
+  Organisation "1" -- "0..*" OrgMember : hat Mitglieder >
+  User "1" -- "0..*" OrgMember : ist >
+
+  OrgMember "1" -- "0..*" Team : gehört zu >
+}
+
+package "Repository" {
+  class Repository {
+    +name
+    +visibility
+    +owner: User|Organisation
+  }
+
+  Team "1" -- "0..*" Repository : Zugriff auf >
+  User "1" -- "0..*" Repository : direkte Rechte (optional) >
+
+  note right of Repository
+    Teams können nur auf Repositories zugreifen,
+    die zur selben Organisation gehören.
+    Nutzer-Repos können nicht über Teams geteilt werden.
+  end note
+}
+
+@enduml

docs/technical-documentation/product/components/forgejo/user-onboarding/user-onbording-flow.puml

@@ -0,0 +1,31 @@
+@startuml
+skinparam defaultTextAlignment center
+skinparam linetype ortho
+
+start
+
+:Neuer Nutzer registriert
+oder eingeladen;
+
+:Login am Forgejo-Server;
+
+partition "Eigenes Nutzerkonto" {
+  :Optional: SSH-Key, Avatar, Bio;
+  :Optional: Eigenes Repo erstellen;
+}
+
+partition "Organisationen" {
+  :Neue Organisation erstellen;
+  :Team 'Owners' automatisch vorhanden;
+  :Weitere Teams erstellen;
+  :Bestehende Nutzer zu Teams hinzufügen;
+}
+
+partition "Repositories" {
+  :Repo in Organisation erstellen;
+  :Teams Berechtigungen auf Repos geben;
+  :Optional: Webhooks, Labels, Milestones;
+}
+
+stop
+@enduml

docs/technical-documentation/project/250527-review.md

@@ -0,0 +1,16 @@
+
+# Review / Product-Demo 27.05.25
+
+* central-forgejo in OTC -> war nur test
+* API OTC sold out: kann man auf ressourcenengpässe in der cloud beim provisioniren reagieren?
+
+Fragen Alex endter:
+
+* CI für cluster generieren (nightly?)
+* kubernetes version ?
+* wie läuft migration von kubernetes?
+
+## Retro
+
+Dailis overload
+Salzstreuer in den Mobs - not everything can be solved in mobs

docs/technical-documentation/project/forgejo-service-mob-1/index.md

@@ -0,0 +1,172 @@
+# OTC
+
+## CCE Cloud Container engine - Kubernetes
+
+* Kata-Container - MicroVM, e.g. for Forgejo-Runner
+
+
+## Networking
+
+* compare it with local networking in docker-compose e.g.
+* there you also can do 'Software defied Networking'
+* like we do in OTC
+
+![alt text](image.png)
+
+* Question: When or why to subnet?
+* A: It' for security ... for sure, but at first it's for creating domains of transparently interacting applicatios
+
+* Hint: Use CIDR calculators when getting lost in IP4 networking
+
+## Routing Table
+
+![alt text](image-1.png)
+
+## Peering Connections
+
+![alt text](image-2.png)
+
+## tags
+
+should be possible ... 
+
+
+## VM
+
+### AZ
+
+is a data center - we take random
+
+![alt text](image-3.png)
+
+![alt text](image-5.png)
+
+
+### price calculator
+
+always be aware of costs!
+> Todo: We need to talk about our budgets
+
+![alt text](image-4.png)
+
+
+## security group 
+
+![alt text](image-6.png)
+
+
+## IP
+
+![alt text](image-7.png)
+
+## Creating VM
+
+![alt text](image-8.png)
+
+
+### result
+
+![alt text](image-9.png)
+
+## trying to connect 
+
+![alt text](image-10.png)
+
+... company VPN issues :-)
+
+![alt text](image-11.png)
+
+## try to hand over the key ...
+
+![alt text](image-12.png)
+
+![alt text](image-13.png)
+
+## find IP again, try to get in
+
+![alt text](image-16.png)
+
+![alt text](image-14.png)
+
+![alt text](image-15.png)
+
+## current state
+
+![alt text](image-17.png)
+
+## ... break of stephan from 14h45-16h00
+
+## terraform, driver is daniel
+
+![alt text](image-100.png)
+
+![alt text](image-101.png)
+
+![alt text](image-102.png)
+
+![alt text](image-103.png)
+
+![alt text](image-104.png)
+
+![alt text](image-105.png)
+
+![alt text](image-106.png)
+
+![alt text](image-107.png)
+
+![alt text](image-108.png)
+
+![alt text](image-109.png)
+
+![alt text](image-110.png)
+
+## in otc, new driver is cristopher
+
+![alt text](image-111.png)
+
+install terraform ...
+
+![alt text](image-112.png)
+
+### otc provider
+
+![alt text](image-113.png)
+
+![alt text](image-114.png)
+
+![alt text](image-115.png)
+
+
+![alt text](image-116.png)
+
+
+### auth
+
+![alt text](image-117.png)
+
+![alt text](image-118.png)
+
+
+```bash
+export OS_ACCESS_KEY=<your-key>
+export OS_SECRET_KEY=<your-key>
+export OS_SECURITY_TOKEN=<your-token>
+```
+
+## apply
+
+![alt text](image-119.png)
+
+![alt text](image-120.png)
+
+![alt text](image-121.png)
+
+## syncing
+
+![alt text](image-122.png)
+
+![alt text](image-123.png)
+
+### statefile, needs to be shared
+
+![alt text](image-124.png)