Achse 7: Governance
GCC-Satzung
Das GCBoK wird von der GitCover Commons gUG (GCC) herausgegeben. GCC ist eine gemeinnützige Körperschaft nach § 60a Abs. 1 AO, anerkannt durch das Finanzamt Bad Homburg v. d. H. (Bescheid vom 27.05.2026).
Die Satzungszwecke (§ 52 Abs. 2 Satz 1 AO):
- Wissenschaft und Forschung (Nr. 1)
- Erziehung, Volks- und Berufsbildung (Nr. 7)
- Verbraucherberatung und Verbraucherschutz (Nr. 16)
- Internationale Gesinnung und Völkerverständigung (Nr. 13)
Vollständige Satzung, Anerkennungsbescheid und Spendeninformationen: auf der GCC-Landingpage.
GCC-Community-Rules
Das GCBoK folgt Open-Source-Prinzipien:
- OSS-first - Alle Spezifikationen sind Open Source
- CC BY-SA 4.0 (angestrebt) - Freie Verbreitung mit Namensnennung
- Apache 2.0 - Für Code-Komponenten
- Community-Review - Beiträge über Gitea Pull-Requests
- Kein Vendor Lock-in - Herstellerneutrale Referenz
GCBoK-Änderungsverfahren
Änderungen am GCBoK folgen einem definierten Prozess:
- Proposal - Issue im Gitea-Repo
gcbok-content - Review - Community-Diskussion, fachliche Prüfung
- Draft - Pull-Request mit vorgeschlagenen Änderungen
- Approval - Review durch GCC-Geschäftsfuhrung
- Merge - Integration in main-Branch
- Release - Versioniertes Release-Tag
Versionierung
Das GCBoK nutzt Semantic Versioning (MAJOR.MINOR.PATCH):
| Komponente | Bedeutung |
|---|---|
| MAJOR | Inkompatible konzeptionelle Änderungen |
| MINOR | Neue Kapitel, neue Definitionen (abwärtskompatibel) |
| PATCH | Korrekturen, Klarstellungen |
Git-nativ selbstreferenziell
Das GCBoK wird in Git versioniert - das Referenzwerk über Git-native Compliance ist selbst in Git gehostet. Dies ist ein bewusster Selbstbezug: Das Werk über das Werk ist im Werk versioniert.
Strategischer Rahmen: IP-Nutzungsrecht
AFJD (Axel Franz Johann Druschel) ist als natürliche Person Anmelder, Erfinder und dauerhafter Inhaber sämtlicher Schutzrechte. Das IP verbleibt bei AFJD - es wird der GCC auf vertraglicher Basis zur Nutzung überlassen (keine Eigentumsübertragung).
| Aspekt | Eigentumsübertragung (nicht gewahlt) | Nutzungsrecht per Vertrag (gewahlt) |
|---|---|---|
| IP-Inhaber | GCC | nat. Person |
| GCC als Lizenzgeber? | Ja -> Gemeinnützigkeit gefährdet | Nein -> GCC-Gemeinnützigkeit sicher |
| Schutz vor Übernahme | Gering | Hoch (IP verbleibt bei nat. Person) |
Vollständige Details: Siehe Schutzrechte.
PII-Separation: personenbezogene Daten zentral, Referenzen in Tenants
Personenbezogene Daten (PII, DSGVO/GDPR) werden nicht über Tenant-Repos verstreut. Jeder Rechtsträger
führt alle PII in einem zentralen PII-Repo (Top-Root, z. B. REPOS/AFJD/PII/) — Stamm- und
Kontaktdaten, Sperrvermerke, Aufbewahrungs-/Lösch-Vormerkungen, Einwilligungen und besonders
geschützte Daten. In den Tenant-/OSS-/Work-Repos stehen nur Referenzen: die uuidV7 der Person
als person_uid (der Typ uuidV7, kein Property-Name) plus lokale Bezugs-Info (Funktion/Rolle, Rechte).
Warum: Datenminimierung (DSGVO Art. 5), eindeutige Identifikation (der Klarname ist nicht eindeutig) und tatsächlich umsetzbare Betroffenenrechte (Auskunft/Löschung/Übertragbarkeit) — eine PII-Fakt existiert einmal, alle anderen Stellen verweisen. Roh-Scans (Ausweise/Unterschriften) bleiben außerhalb Git.
Tooling: die Solution GitCover.PII (Selbstverwaltungs-UI analog Google-Konto: DSGVO-Pflichtaspekte,
Sperrvermerke, Retention, Kontaktdaten) bindet GitCover.IdP (IAM) und GitCover.Ledger (Evidenz) an.
Normativer SSoT:
OSS/TOP/.gitcover/specs/pii-separation.md.
Ordnung & Normierung: Verarbeitungen werden zuerst nach der GDPR-Bestimmung (legalBasis, Art. 6/9 DSGVO) bestimmt und dann über den Bezug (wo/wodurch) — legalBasis ist der Anker (nicht eine freie Zweckliste). Erlaubnisse („Erlaubnis durch Nutzer") werden technisch als GCPN dokumentiert und nur referenziert. Die DSGVO-Sachverhalte werden als ENUMs/UNIONs in GCBoK genormt; ein OSCAL-Katalog + OPA-Artefakt-Sets (SSoT: .gitcover/policy/pii-gdpr.catalog.json, pii_legal_basis.rego) wird vom Feature GitCover.PII konsumiert (Policy-as-Code).
Daten-Hoheit statt Vendor Lock-In: Die in PII entstehenden Fakten sollen optional M365-/MS-User-Account-Graphs ersetzen — personenbezogene Daten werden nicht in einer Cloud-Plattform, sondern im Git-Repo geführt. Das erlaubt Git-native Compliance (revisionssicher, selbst-referenzierend) und volle Daten-Hoheit des Anwenders ohne Vendor Lock-In. Die PII-Fakten sind zugleich die Datenbasis für das Feature OU (GitCover.Discovery/plans/ADR-005), das System.DirectoryServices (Microsoft Active Directory) mit OU-Struktur/Provisioning versorgt — Personen dort nur per person_uid; GitCover.IdP bleibt Authorization Server.