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

ref: https://likec4.dev/dsl/projects/#_top

.gitignore

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

.vscode/settings.json

@@ -0,0 +1,22 @@
+{
+    "peacock.color": "#832561",
+    "workbench.colorCustomizations": {
+        "activityBar.activeBackground": "#ab307e",
+        "activityBar.background": "#ab307e",
+        "activityBar.foreground": "#e7e7e7",
+        "activityBar.inactiveForeground": "#e7e7e799",
+        "activityBarBadge.background": "#25320e",
+        "activityBarBadge.foreground": "#e7e7e7",
+        "commandCenter.border": "#e7e7e799",
+        "sash.hoverBorder": "#ab307e",
+        "statusBar.background": "#832561",
+        "statusBar.foreground": "#e7e7e7",
+        "statusBarItem.hoverBackground": "#ab307e",
+        "statusBarItem.remoteBackground": "#832561",
+        "statusBarItem.remoteForeground": "#e7e7e7",
+        "titleBar.activeBackground": "#832561",
+        "titleBar.activeForeground": "#e7e7e7",
+        "titleBar.inactiveBackground": "#83256199",
+        "titleBar.inactiveForeground": "#e7e7e799"
+    }
+}

README.md

@@ -1,46 +1,95 @@
-# eDF Release 'PoC' [WiP]
+# 🌟 EDP - EdgeDeveloperPlatform
 
-This is a preliminary README in 'WiP' state - it's just sketching the story and structure of work.
+> * Owner: Telekom MMS & T-Systems
+> * Date: December 20, 2024
+> * Version: Release 1.0.0 ('PoC')
 
-When we reach the 'PoC' milestone it will be replaced by a short and concise README as the main documentation entry point for our customers who want to consume the 'edf_poc' product.
+## About this Repository
 
-## POC Content Structure
+This repo [`edp-doc`](https://forgejo.edf-bootstrap.cx.fg1.ffm.osc.live/DevFW-CICD/edp-doc) is the documentation repository of the **EDP product**.
 
-* [Part 1 - User documentation](https://jira.telekom-mms.com/browse/IPCEICIS-368)
-* Part 2 - Hands On
-    * [Part 2.1 - Local IdP creation](https://jira.telekom-mms.com/browse/IPCEICIS-765)
-    * [Part 2.2 - OSC IdP creation](https://jira.telekom-mms.com/browse/IPCEICIS-766)
-    * Part 2.1 & 2.2 Use Cases
-        * [Part 2.x.1 - Golden Path template for a Go application](https://jira.telekom-mms.com/browse/IPCEICIS-514)
-        * [Part 2.x.2 - Fibonacci Go application](https://jira.telekom-mms.com/browse/IPCEICIS-759)
-        * [Part 2.x.3 - Forgejo Actions with respect to the Fibonacci CI/CD](https://jira.telekom-mms.com/browse/IPCEICIS-760)
-        * [Part 2.x.4 - Telemetry with respect to the Fibonacci workload](https://jira.telekom-mms.com/browse/IPCEICIS-761)
-        * [Part 2.x.5 - OSC infrastructure with respect to the Fibonacci workload](https://jira.telekom-mms.com/browse/IPCEICIS-762)
-        * [Part 2.x.6 - Additional bells and whistles](https://jira.telekom-mms.com/browse/IPCEICIS-763)
-    * [Part 2.3 - Extended Local IdP creation and orchestration](https://jira.telekom-mms.com/browse/IPCEICIS-767)
-    * Part 2.3 Use Cases
-        * tbd
-* [Part 3 - User documentation](https://jira.telekom-mms.com/browse/IPCEICIS-768)
+## About the EDP Product
 
+EDP is a product developed by the IPCEI-CIS subproject 'edge Developer Framework'. The goal is to provide a cutting edge developer experience for developing and delivering applications in the cloud edge continuum.
 
-## Content and Story
+## What EDP contains
 
-This is the Storybook of the PoC content structure (content is depicted top right): 
+The EDP product consists of three parts:
 
-![](./content-and-storybook.png)
+1. The platform orchestrator, processing declarative 'platform stack' descriptions
+1. The predefined stack for a Demo EDP instance
+1. The documentation
 
-## Use case content of 2.1 and 2.2 'Hands On'
+### Platform Orchestrator `edpbuilder`
 
-This is the illustration of the [use cases (aka 'functionality') in the PoC content](https://confluence.telekom-mms.com/display/IPCEICIS/Proof+of+Concept+2024): 
+[edpbuilder](https://forgejo.edf-bootstrap.cx.fg1.ffm.osc.live/DevFW/edpbuilder) is a tool to quickly instantiate and manage Internal Development Platforms (IDPs).
+The Edge Development Platform Builder (edpbuilder) can easily setup a Kubenetes cluster (local kind cluster or OSC instance) and deploy tools to manage the Kubernetes resources and the software lifecicle of an application.
 
-![](./use-cases.png)
+### Predefined `Demo EDP` Stack
 
-## Technical composition
+There are predefined stack sets for deploying and orchestrating a whole platform.
 
-The 'edf_poc'-product should be as self-contained as possible. 
+At the time of writing (version PoC) we provide the [`Demo EDP`as PoC stack](https://forgejo.edf-bootstrap.cx.fg1.ffm.osc.live/DevFW-CICD/stacks).
 
-Thus all parts coming from upstream repos should have a physical copy in this repo with a reference to the upstream repo. Therefore we need a mapping table from parts here to references in upstreams.
+#### `Demo EDP` Stack
 
-Alternative: Submodules
+The `Demo EDP` Stack contains the follwing application components:
 
-Proposal: The final product will be a export of the repo
+* Version-Control: Forgejo
+* CI: Forgejo Actions
+* CD: ArgoCD
+* Monitoring: Grafana, Prometheus, Loki, Promtail
+* SSO: Keycloak
+* Developer Portal: Backstage
+* Secret-Management: OpenBao, external-secrets
+* Infrastructur-Provisioning: Crossplane
+
+One usecase to demonstrate the capabilities and development lifecycle flow through all stack components is the [PetClinic Application](./docs/user-documentation/petclinic.md)
+
+### Documentation
+
+The EDP documentation is subject to this repo in folder [`docs`](./docs/). It is created in the [`mkdocs`](https://www.mkdocs.org/) documentation format and natively embedded in the [`Backstage TechDocs` documentation technology](https://backstage.io/docs/features/techdocs/).
+
+Thus it can be read in four ways by
+
+1. [accessing the Backstage portal in a running Demo EDP](#doc-in-backstage-in-a-running-demo-edp)
+2. [accessing the Backstage portal in a Demo EDP setup on your computer](#doc-in-backstage-in-a-demo-edp-setup-on-your-computer)
+3. [browsing the documentaion repository](#doc-in-the-repository)
+4. [browsing in a Backstage simulation on your computer](#doc-in-a-backstage-simulation)
+
+## Getting Started
+
+So get started by reading the doc in one of these ways, sorted from 'easy' to 'opinionated' accessibility:
+
+### Doc in Backstage in a running Demo EDP
+
+The documentation can be easily accessed through a Demo EDP instance hosted on our Open Sovereign Cloud (OSC).
+Thus there you have a Backstage-Developer Portal running, containing the EDP documentation.
+
+Simply log in to Demo EDP Backstage to read through the documentation:
+
+* [EDP Documentation URL](https://edf-cc1.cx.fg1.ffm.osc.live/docs/edppoc/component/edp-documentation)
+* Username: user1
+* Password: PpMpfZYICG9MRRF-3QBY2Zz1-+URYB6+-JRe
+
+### Doc in the repository
+  
+> Hint: the following link only works when you are in the repo (not in Backstage), like [the central one](https://forgejo.edf-bootstrap.cx.fg1.ffm.osc.live/DevFW-CICD/edp-doc)
+
+If you prefer direct access, the content of our documentation is centrally defined and maintained within the [docs folder of this repository](./docs/contents.md).
+
+### Doc in a Backstage simulation
+
+> Hint: the following link only works when you are in the repo (not in Backstage), like [the central one](https://forgejo.edf-bootstrap.cx.fg1.ffm.osc.live/DevFW-CICD/edp-doc)
+
+The Backstage TechDocs embedding can also be [emulated in a Backstage portal frame running on your computer](./live-preview-integration/README-backstage-local.md).
+
+### Doc in Backstage in a Demo EDP setup on your computer
+
+As `edpbuilder` is a infrastructure agnostic platform orchestrator, you also can boostrap the EDP Demo on your own laptop!
+
+Using the edpbuilder, you can set up a local Demo EDP that comes with a Backstage instance containing the documentation:
+
+> Hint: the following link only works when you are in the repo (not in Backstage), like [the central one](https://forgejo.edf-bootstrap.cx.fg1.ffm.osc.live/DevFW-CICD/edp-doc)
+
+[How to set up a local IDP on a kind cluster](./docs/user-documentation/edpbuilder.md)

design/README-poc-design.md

@@ -0,0 +1,46 @@
+# eDF Release 'PoC' [WiP]
+
+This is a preliminary README in 'WiP' state - it's just sketching the story and structure of work.
+
+When we reach the 'PoC' milestone it will be replaced by a short and concise README as the main documentation entry point for our customers who want to consume the 'edf_poc' product.
+
+## POC Content Structure
+
+* [Part 1 - User documentation](https://jira.telekom-mms.com/browse/IPCEICIS-368)
+* Part 2 - Hands On
+    * [Part 2.1 - Local IdP creation](https://jira.telekom-mms.com/browse/IPCEICIS-765)
+    * [Part 2.2 - OSC IdP creation](https://jira.telekom-mms.com/browse/IPCEICIS-766)
+    * Part 2.1 & 2.2 Use Cases
+        * [Part 2.x.1 - Golden Path template for a Go application](https://jira.telekom-mms.com/browse/IPCEICIS-514)
+        * [Part 2.x.2 - Fibonacci Go application](https://jira.telekom-mms.com/browse/IPCEICIS-759)
+        * [Part 2.x.3 - Forgejo Actions with respect to the Fibonacci CI/CD](https://jira.telekom-mms.com/browse/IPCEICIS-760)
+        * [Part 2.x.4 - Telemetry with respect to the Fibonacci workload](https://jira.telekom-mms.com/browse/IPCEICIS-761)
+        * [Part 2.x.5 - OSC infrastructure with respect to the Fibonacci workload](https://jira.telekom-mms.com/browse/IPCEICIS-762)
+        * [Part 2.x.6 - Additional bells and whistles](https://jira.telekom-mms.com/browse/IPCEICIS-763)
+    * [Part 2.3 - Extended Local IdP creation and orchestration](https://jira.telekom-mms.com/browse/IPCEICIS-767)
+    * Part 2.3 Use Cases
+        * tbd
+* [Part 3 - User documentation](https://jira.telekom-mms.com/browse/IPCEICIS-768)
+
+
+## Content and Story
+
+This is the Storybook of the PoC content structure (content is depicted top right): 
+
+![](./content-and-storybook.png)
+
+## Use case content of 2.1 and 2.2 'Hands On'
+
+This is the illustration of the [use cases (aka 'functionality') in the PoC content](https://confluence.telekom-mms.com/display/IPCEICIS/Proof+of+Concept+2024): 
+
+![](./use-cases.png)
+
+## Technical composition
+
+The 'edf_poc'-product should be as self-contained as possible. 
+
+Thus all parts coming from upstream repos should have a physical copy in this repo with a reference to the upstream repo. Therefore we need a mapping table from parts here to references in upstreams.
+
+Alternative: Submodules
+
+Proposal: The final product will be a export of the repo

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/about/mkdocs-test.md

@@ -0,0 +1,133 @@
+# Mkdoc Test Doc
+
+```plantuml
+@startuml
+title Login Sequence
+    ComponentA->ComponentB: Login Request
+    note right of ComponentB: ComponentB logs message
+    ComponentB->ComponentA: Login Response
+@enduml
+```
+
+## hello mock docs
+
+!!! test
+Testing something
+
+Abbreviations:
+Some text about MOCDOC
+
+This is a paragraph.
+{: #test_id .test_class }
+
+Apple
+: Pomaceous fruit of plants of the genus Malus in
+the family Rosaceae.
+
+```javascript
+import { test } from 'something';
+
+const addThingToThing = (a, b) a + b;
+```
+
+- [abc](#abc)
+- [xyz](#xyz)
+
+## abc
+
+This is a b c.
+
+## xyz
+
+This is x y z.
+
+# The attack plan
+
+{% dot attack_plan.svg
+    digraph G {
+        rankdir=LR
+        Earth [peripheries=2]
+        Mars
+        Earth -> Mars
+    }
+%}
+
+```graphviz dot attack_plan.svg
+digraph G {
+    rankdir=LR
+    Earth [peripheries=2]
+    Mars
+    Earth -> Mars
+}
+```
+
+# PlantUML Samples
+
+```plantuml classes="uml myDiagram" alt="Diagram placeholder" title="My diagram"
+@startuml
+  Goofy ->  MickeyMouse: calls
+  Goofy <-- MickeyMouse: responds
+@enduml
+```
+
+# Emojis
+
+:bulb: :smile:
+
+# Code blocks
+
+```javascript
+import { test } from 'something';
+
+const addThingToThing = (a, b) a + b;
+```
+
+# Grouped Code blocks
+
+=== "JavaScript"
+
+    ```javascript
+    import { test } from 'something';
+
+    const addThingToThing = (a, b) a + b;
+    ```
+
+=== "Java"
+
+    ```java
+    public void function() {
+        test();
+    }
+    ```
+
+```java tab="java"
+    public void function() {
+      test();
+    }
+```
+
+```java tab="java 2"
+    public void function() {
+      test();
+    }
+```
+
+# MDX truly sane lists
+
+- attributes
+
+- customer
+  - first_name
+    - test
+  - family_name
+  - email
+- person
+  - first_name
+  - family_name
+  - birth_date
+- subscription_id
+
+- request
+
+<!-- prettier-ignore -->
+*[MOCDOC]: Mock Documentation

docs/contents.md

@@ -0,0 +1,35 @@
+# EDP Documentation
+
+The documentation consists of two parts
+
+* User Documentation
+* Technical Documentation
+
+Both are outlined in the following.
+
+## User Documentation
+
+A 'user' is someone who accesses a predeployed EDP and wants to drive developer use cases. 
+
+### 🧐 What is it?
+
+When you enter a EDP as a development user the EDP is an Internal Development Platform.
+
+### 📦 Main features
+
+* Start new use cases
+* Search, browse, monitor and revoke already run use cases
+
+### ⏱️ Quick start guide (WiP)
+
+* Open the platform URL
+* Follow one of the use cases
+
+## Technical Documentation  
+
+EDP is a product developed by the IPCEI-CIS subproject 'edge Developer Framework'. The goal is to provide a cutting edge developer experience for developing and delivering applications in the cloud edge continuum.
+
+It consists of 
+
+* [edpbuilder](https://forgejo.edf-bootstrap.cx.fg1.ffm.osc.live/DevFW/edpbuilder) as a tool to quickly instantiate and manage Internal Development Platforms (IDPs).
+* declarative 'platform stack' descriptions which are processed by the orchestrator

docs/index.md

@@ -0,0 +1 @@
+../README.md

docs/technical-documentation/.pages

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

docs/technical-documentation/architecture/decisions/0001-pipeline-tools.md

@@ -0,0 +1,126 @@
+# CI/CD pipeline tools for composable pipeline
+
+## Context and Problem Statement
+
+In order to build a composable pipeline that provides a golden path and reusable components, we need to define the tools that will be used to execute the pipeline.
+
+ArgoCD is considered set in stone as the tool to manage the deployment of applications. However, the tools to compose and execute the pipeline are still up for debate.
+
+> Note: The pipeline will use many other tools to perform certain actions such as testing, building, and deploying. This ADR is focused on the tools that will be used to compose and execute the pipeline itself.
+
+In general, there are 2 decisions to make:
+
+- What tools should we use to execute the pipeline?
+- What tools should we use to compose the pipeline?
+
+The following use-cases should be considered for this decision:
+
+- **User who wants to manage their own runners (???)**
+- User who only wants to use our golden path
+- User who wants to use our golden path and add custom actions
+- User who wants to use their own templates and import some of our actions
+- User who wants to import an existing GitHub repository with a pipeline
+
+## Considered Options
+
+- Argo Workflows + Events
+- Argo Workflows + Events + Additional Composition tool
+- Forgejo Actions
+- Forgejo Actions + Additional Composition tool
+- Dagger (as Engine)
+- Shuttle (as Engine)
+
+## Decision Outcome
+
+TBD
+
+## Pros and Cons of the Options
+
+### Argo Workflows + Events
+
+**Pro**
+
+- integration with ArgoCD
+- ability to trigger additional workflows based on events.
+- level of maturity and community support.
+
+**Con**
+
+- Ability to self-host runners?
+- way how composition for pipelines works (based on Kubernetes CRDs)
+  - Templates must be available in the cluster where the pipelines are executed, so any imported templates must be applied into the cluster before the pipeline can be executed and cannot simply reference a repository
+  - This makes it difficult to import existing templates from other repositories when using self-hosted runners
+  - This also makes it difficult to use our golden path, or at least we will need to provide a way to import our golden path into the cluster
+  - This also makes the split of every component has its own repo very difficult
+- additional UI to manage the pipeline
+- Additional complexity
+
+### Argo Workflows + Events + Additional Composition tool
+
+**Pro**
+
+- Composability can be offloaded to another tool
+
+**Con**
+
+- All cons of the previous option (except composability)
+- Additional complexity by adding another tool
+
+### Forgejo Actions
+
+**Pro**
+
+- tight integration with GitHub Actions providing a familiar interface for developers and a vast catalog of actions to choose from
+- ability to compose pipelines without relying on another tool
+- Self-hosting of runners possible
+- every component can have its own repository and use different tools (e.g. written in go, bash, python etc.)
+
+**Con**
+
+- level of maturity - will require additional investments to provide a production-grade system
+
+### Forgejo Actions + Additional Tool
+
+**Pro**
+
+- may be possible to use GitHub actions alongside another tool
+
+**Con**
+
+- additional complexity by adding another tool
+
+### Shuttle
+
+**Pro**
+
+- Possibility to clearly define interfaces for pipeline steps
+- Relatively simple
+
+**Con**
+
+- basically backed by only one company
+- **centralized templates**, so no mechanism for composing pipelines from multiple repositories
+
+### Dagger
+
+**Pro**
+
+- Pipeline as code
+  - if it runs it should run anywhere and produce the "same" / somewhat stable results
+  - build environments are defined within containers / the dagger config. Dagger is the only dependency one has to install on a machine
+- DX is extremely nice, especially if you have to debug (image) builds, also type safety due to the ability to code your build in a strong language
+- additional tooling, like trivy, is added to a build pipeline with low effort due to containers and existing plugin/wrappers
+- you can create complex test environments similar to test containers and docker compose
+
+**Con**
+
+- relies heavily containers, which might not be available some environments (due to policy etc), it also has an effect on reproducibility and verifiability
+- as a dev you need to properly understand containers
+- dagger engine has to run privileged locally and/or in the cloud which might be a blocker or at least a big pain in the ...
+
+**Suggestion Patrick**
+
+- dagger is a heavy weight and might not be as productive in a dev workflow as it seems (setup lsp etc)
+- it might be too opinionated to force on teams, especially since it is not near mainstream enough, community might be too small
+- it feels like dagger gets you 95% of the way, but the remaining 5% are a real struggle
+- if we like it, we should check the popularity in the dev community before further considering as it has a direct impact on teams and their preferences

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/decisions/README.md

@@ -0,0 +1,5 @@
+# ADRs
+
+Architecture Decision Records (ADRs) are a way to capture the important architectural decisions made during the development of a project. They are a way to document the context, the decision, and the consequences of the decision. They are a way to keep track of the architectural decisions made in a project and to communicate them to the team.
+
+The [Markdown Architectural Decision Records](https://adr.github.io/madr/) (MADR) format is a simple and easy-to-use format for writing ADRs in Markdown.

docs/technical-documentation/architecture/decisions/_adr-template.md

@@ -0,0 +1,67 @@
+<!-- we need to disable MD025, because we use the different heading "ADR Template" in the homepage (see above) than it is foreseen in the template -->
+<!-- markdownlint-disable-next-line MD025 -->
+# {short title, representative of solved problem and found solution}
+
+## Context and Problem Statement
+
+{Describe the context and problem statement, e.g., in free form using two to three sentences or in the form of an illustrative story. You may want to articulate the problem in form of a question and add links to collaboration boards or issue management systems.}
+
+<!-- This is an optional element. Feel free to remove. -->
+## Decision Drivers
+
+* {decision driver 1, e.g., a force, facing concern, …}
+* {decision driver 2, e.g., a force, facing concern, …}
+* … <!-- numbers of drivers can vary -->
+
+## Considered Options
+
+* {title of option 1}
+* {title of option 2}
+* {title of option 3}
+* … <!-- numbers of options can vary -->
+
+## Decision Outcome
+
+Chosen option: "{title of option 1}", because {justification. e.g., only option, which meets k.o. criterion decision driver | which resolves force {force} | … | comes out best (see below)}.
+
+<!-- This is an optional element. Feel free to remove. -->
+### Consequences
+
+* Good, because {positive consequence, e.g., improvement of one or more desired qualities, …}
+* Bad, because {negative consequence, e.g., compromising one or more desired qualities, …}
+* … <!-- numbers of consequences can vary -->
+
+<!-- This is an optional element. Feel free to remove. -->
+### Confirmation
+
+{Describe how the implementation of/compliance with the ADR can/will be confirmed. Are the design that was decided for and its implementation in line with the decision made? E.g., a design/code review or a test with a library such as ArchUnit can help validate this. Not that although we classify this element as optional, it is included in many ADRs.}
+
+<!-- This is an optional element. Feel free to remove. -->
+## Pros and Cons of the Options
+
+### {title of option 1}
+
+<!-- This is an optional element. Feel free to remove. -->
+{example | description | pointer to more information | …}
+
+* Good, because {argument a}
+* Good, because {argument b}
+<!-- use "neutral" if the given argument weights neither for good nor bad -->
+* Neutral, because {argument c}
+* Bad, because {argument d}
+* … <!-- numbers of pros and cons can vary -->
+
+### {title of other option}
+
+{example | description | pointer to more information | …}
+
+* Good, because {argument a}
+* Good, because {argument b}
+* Neutral, because {argument c}
+* Bad, because {argument d}
+* …
+
+<!-- This is an optional element. Feel free to remove. -->
+## More Information
+
+{You might want to provide additional evidence/confidence for the decision outcome here and/or document the team agreement on the decision and/or define when/how this decision the decision should be realized and if/when it should be re-visited. Links to other decisions and resources might appear here as well.}

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/design-documents/decision-iam-and-edf-self-containment.md

@@ -0,0 +1,31 @@
+---
+title: eDF is self-contained and has an own IAM (WiP)
+weight: 2
+description: tbd
+---
+
+* Type: Proposal
+* Owner: Stephan Lo (stephan.lo@telekom.de)
+* Reviewers: EDF Architects
+* Status: Speculative, revision 0.1
+
+## Background
+
+tbd
+
+## Proposal
+
+==== 1 =====
+
+There is a core eDF which is self-contained and does not have any impelmented dependency to external platforms.
+eDF depends on abstractions.
+Each embdding into customer infrastructure works with adapters which implement the abstraction.
+
+==== 2 =====
+
+eDF has an own IAM. This may either hold the principals and permissions itself when there is no other IAM or proxy and map them when integrated into external enterprise IAMs.
+
+
+## Reference 
+
+Arch call from 4.12.24, Florian, Stefan, Stephan-Pierre  

docs/technical-documentation/architecture/decisions/design-documents/proposal-local-deployment.md

@@ -0,0 +1,23 @@
+---
+title: Agnostic EDF Deployment
+weight: 2
+description: The implementation of EDF must be kubernetes provider agnostic
+---
+
+* Type: Proposal
+* Owner: Stephan Lo (stephan.lo@telekom.de)
+* Reviewers: EDF Architects
+* Status: Speculative, revision 0.1
+
+## Background
+
+EDF is running as a controlplane - or let's say an orchestration plane, correct wording is still to be defined - in a kubernetes cluster.
+Right now we have at least ArgoCD as controller of manifests which we provide as CNOE stacks of packages and standalone packages.
+
+## Proposal
+
+The implementation of EDF must be kubernetes provider agnostic. Thus each provider specific deployment dependency must be factored out into provider specific definitions or deployment procedures.
+
+## Local deployment
+
+This implies that EDF must always be deployable into a local cluster, whereby by 'local' we mean a cluster which is under the full control of the platform engineer, e.g. a kind cluster on their laptop.

docs/technical-documentation/architecture/decisions/design-documents/proposal-stack-hydration.md

@@ -0,0 +1,28 @@
+---
+title: Agnostic Stack Definition
+weight: 2
+description: The implementation of EDF stacks must be kubernetes provider agnostic by a templating/hydration mechanism
+---
+
+* Type: Proposal
+* Owner: Stephan Lo (stephan.lo@telekom.de)
+* Reviewers: EDF Architects
+* Status: Speculative, revision 0.1
+
+## Background
+
+When booting and reconciling the 'final' stack exectuting orchestrator (here: ArgoCD) needs to get rendered (or hydrated) presentations of the manifests. 
+
+It is not possible or unwanted that the orchestrator itself resolves dependencies or configuration values.
+
+## Proposal
+
+The hydration takes place for all target clouds/kubernetes providers. There is no 'default' or 'special' setup, like the Kind version.
+
+## Local development
+
+This implies that in a development process there needs to be a build step hydrating the ArgoCD manifests for the targeted cloud.
+
+## Reference 
+
+Discussion from Robert and Stephan-Pierre in the context of stack development - there should be an easy way to have locally changed stacks propagated into the local running platform.   

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

@@ -0,0 +1,22 @@
+# EDP Design
+
+## 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/foundry-berlin-january-2025/highlevelarch.md

@@ -0,0 +1,27 @@
+---
+title: Architecture
+weight: 1
+description: High level EDP Architecture
+---
+
+## Architecture
+
+> This architecture chart was discussed in the Berlin arch workshop Jan. 21st 2025
+ 
+
+![alt text](architecture-IMG_20250121_163020.jpg)
+
+
+## Additional notes
+
+With respect to the meaning of 'Platform as a product' there are following notes to EDP as a product:
+
+* Product items are
+    1. EDP Foundry
+        a) oppionated extreme, (aka 'locked down version')
+        b) 'construction set' ('baukasten') extreme 
+        c) provide documentation
+    2. all EDP's themsselves 
+* 'product' in terms of a ciustomer view means two aspects:
+    * they get it provisionned, i.e. we do the bootstrapping
+    * they have it in maintenines state, i.w. we do the maintaining (compare to github: there is no github version to the customer!)

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/architecture/research/gitops/_index.md

@@ -0,0 +1,16 @@
+---
+title: Gitops
+weight: 1
+description: Gitops scenarios
+---
+
+WiP - this is in work.
+
+What kind of Gitops do we have with idpbuilder/CNOE ?
+
+## References
+
+
+https://github.com/gitops-bridge-dev/gitops-bridge
+
+![alt text](image.png)

docs/technical-documentation/architecture/research/orchestration/_index.md

@@ -0,0 +1,34 @@
+---
+title: Orchestration
+weight: 1
+description: Usage scenarios and system architecture of platform orchestartion
+---
+
+WiP - this is in work.
+
+What deployment scenarios do we have with idpbuilder/CNOE ?
+
+## References
+
+* Base Url of CNOE presentations: https://github.com/cnoe-io/presentations/tree/main
+
+### CNOE in EKS
+
+The next chart shows a system landscape of CNOE orchestration.
+
+[2024-04-PlatformEngineering-DevOpsDayRaleigh.pdf](https://github.com/cnoe-io/presentations/blob/main/2024-04-PlatformEngineering-DevOpsDayRaleigh.pdf)
+
+Questions: What are the degrees of freedom in this chart? What variations with respect to environments and environmnent types exist? 
+
+![alt text](image.png)
+
+### CNOE in AWS
+
+The next chart shows a context chart of CNOE orchestration.
+
+[reference-implementation-aws](https://github.com/cnoe-io/reference-implementation-aws)
+
+Questions: What are the degrees of freedom in this chart? What variations with respect to environments and environmnent types exist? 
+
+
+![alt text](image-1.png)

docs/technical-documentation/concepts/.pages

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

docs/technical-documentation/concepts/customer-developer/_index.md

@@ -0,0 +1,95 @@
+---
+title: Stakeholder Workshop Intro
+weight: 50
+description: An overall eDF introduction for stakeholders
+linktitle: Stakeholder Workshops
+---
+
+
+## Edge Developer Framework Solution Overview
+
+> This section is derived from [conceptual-onboarding-intro](../conceptual-onboarding/1_intro/)
+
+1. As presented in the introduction: We have the ['Edge Developer Framework'](./edgel-developer-framework/). \
+    In short the mission is:
+    * Build a european edge cloud IPCEI-CIS
+    * which contains typical layers infrastructure, platform, application
+    * and on top has a new layer 'developer platform'
+    * which delivers a **cutting edge developer experience** and enables **easy deploying** of applications onto the IPCEI-CIS
+2. We think the solution for EDF is in relation to ['Platforming' (Digital Platforms)](../conceptual-onboarding/3_platforming/)
+    1. The next evolution after DevOps
+    2. Gartner predicts 80% of SWE companies to have platforms in 2026
+    3. Platforms have a history since roundabout 2019
+    4. CNCF has a working group which created capabilities and a maturity model
+3. Platforms evolve - nowadys there are [Platform Orchestrators](../conceptual-onboarding/4_orchestrators/)
+    1. Humanitec set up a Reference Architecture
+    2. There is this 'Orchestrator' thing - declaratively describe, customize and change platforms!
+4. Mapping our assumptions to the [CNOE solution](../conceptual-onboarding/5_cnoe/)
+    1. CNOE is a hot candidate to help and fulfill our platform building
+    2. CNOE aims to embrace change and customization!
+
+
+## 2. Platforming as the result of DevOps
+
+### DevOps since 2010
+
+![alt text](DevOps-Lifecycle.jpg)
+
+* from 'left' to 'right' - plan to monitor
+* 'leftshift' 
+* --> turns out to be a right shift for developers with cognitive overload
+* 'DevOps isd dead' -> we need Platforms
+
+### Platforming to provide 'golden paths'
+
+> don't mix up 'golden paths' with pipelines or CI/CD
+
+![alt text](../conceptual-onboarding/3_platforming/humanitec-history.png)
+
+#### Short list of platform using companies
+
+As [Gartner states](https://www.gartner.com/en/newsroom/press-releases/2023-11-28-gartner-hype-cycle-shows-ai-practices-and-platform-engineering-will-reach-mainstream-adoption-in-software-engineering-in-two-to-five-years): "By 2026, 80% of software engineering organizations will establish platform teams as internal providers of reusable services, components and tools for application delivery."
+
+Here is a small list of companies alrteady using IDPs:
+
+* Spotify
+* Airbnb
+* Zalando
+* Uber
+* Netflix
+* Salesforce
+* Google
+* Booking.com
+* Amazon
+* Autodesk
+* Adobe
+* Cisco
+*  ...
+
+## 3 Platform building by 'Orchestrating'
+
+So the goal of platforming is to build a 'digital platform' which fits [this architecture](https://www.gartner.com/en/infrastructure-and-it-operations-leaders/topics/platform-engineering) ([Ref. in German)](https://www.gartner.de/de/artikel/was-ist-platform-engineering):
+
+![alt text](image.png)
+
+### Digital Platform blue print: Reference Architecture
+
+The blue print for such a platform is given by the reference architecture from Humanitec:
+
+[Platform Orchestrators](../conceptual-onboarding/4_orchestrators/)
+
+### Digital Platform builder: CNOE
+
+Since 2023 this is done by 'orchestrating' such platforms. One orchestrator is the [CNOE solution](../conceptual-onboarding/5_cnoe/), which highly inspired our approach.
+
+In our orchestartion engine we think in 'stacks' of 'packages' containing platform components.
+
+
+## 4 Sticking all together: Our current platform orchestrating generated platform
+
+Sticking together the platforming orchestration concept, the reference architecture and the CNOE stack solution, [this is our current running platform minimum viable product](../plan-in-2024/image-2024-8-14_10-50-27.png).
+
+This will now be presented! Enjoy!
+
+
+

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