Eje 7: Gobernanza
Estatutos de GCC
El GCBoK es publicado por GitCover Commons gUG (GCC). GCC es una corporación sin ánimo de lucro conforme al § 60a Abs. 1 AO, reconocida por el Finanzamt Bad Homburg v. d. H. (resolución de 27.05.2026).
Los fines estatutarios (§ 52 Abs. 2 Satz 1 AO):
- Ciencia e investigación (n.º 1)
- Educación, formación general y profesional (n.º 7)
- Asesoramiento y protección de consumidores (n.º 16)
- Actitud internacional y entendimiento entre los pueblos (n.º 13)
Estatutos completos, resolución de reconocimiento e información sobre donaciones: en la página de inicio de GCC.
Reglas de la comunidad de GCC
El GCBoK sigue principios de código abierto:
- OSS-first - Todas las especificaciones son de código abierto
- CC BY-SA 4.0 (previsto) - Distribución libre con atribución
- Apache 2.0 - Para componentes de código
- Revisión comunitaria - Contribuciones mediante pull requests de Gitea
- Sin Vendor Lock-in - Referencia neutral respecto al fabricante
Procedimiento de modificación del GCBoK
Las modificaciones del GCBoK siguen un proceso definido:
- Proposal - Issue en el repositorio de Gitea
gcbok-content - Review - Debate comunitario, revisión técnica
- Draft - Pull request con cambios propuestos
- Approval - Revisión por la dirección de GCC
- Merge - Integración en la rama main
- Release - Etiqueta de release versionada
Del parecer privado al resultado demostrable
Aquí gobernanza no significa opinión en el documento, sino resultado demostrable en el acervo. Las directrices personales de la persona que autoriza —valoraciones privadas, ponderaciones, criterios de sopesamiento— son el material de entrada: están protegidas, no se versionan y no aparecen en el acervo de documentación. Lo que surge es el resultado de la decisión: una ADR, una plantilla, un conjunto de reglas o una evidencia.
Para la cadena de prueba, esto significa: el acervo de Git demuestra qué se decidió y cómo es demostrable —no cómo se sopesó internamente. Esta separación protege a la vez la privacidad de la persona actuante y la fuerza probatoria del expediente.
Regla para agentes: respetar las directrices, documentar los resultados —no citar ni reproducir la evaluación en sí mientras el HITL no la autorice expresamente.
Versionado
El GCBoK utiliza Semantic Versioning (MAJOR.MINOR.PATCH):
| Componente | Significado |
|---|---|
| MAJOR | Cambios conceptuales incompatibles |
| MINOR | Nuevos capítulos, nuevas definiciones (compatibles hacia atrás) |
| PATCH | Correcciones, aclaraciones |
Autorreferencial nativo de Git
El GCBoK se versiona en Git —la obra de referencia sobre cumplimiento nativo de Git está alojada ella misma en Git. Se trata de una autorreferencia consciente: la obra sobre la obra está versionada en la obra.
Marco estratégico: derecho de uso de la PI
AFJD (Axel Franz Johann Druschel), como persona física, es solicitante, inventor y titular permanente de todos los derechos de protección. La PI permanece en AFJD —se concede a GCC sobre base contractual para su uso (sin transmisión de propiedad).
| Aspecto | Transmisión de propiedad (no elegida) | Derecho de uso por contrato (elegido) |
|---|---|---|
| Titular de la PI | GCC | persona física |
| ¿GCC como licenciante? | Sí -> peligra el carácter de utilidad pública | No -> carácter de utilidad pública de GCC asegurado |
| Protección frente a adquisición | Baja | Alta (la PI permanece en la persona física) |
Detalles completos: Véase Derechos de protección.
Separación de PII: datos personales centralizados, referencias en los tenants
Los datos personales (PII, RGPD/GDPR) no se dispersan por los repositorios de tenant. Cada entidad jurídica lleva todos los PII en un repositorio PII central (raíz superior, p. ej. REPOS/AFJD/PII/) — datos maestros y de contacto, anotaciones de bloqueo, anotaciones de conservación/eliminación, consentimientos y datos especialmente protegidos. En los repositorios de tenant/OSS/work solo hay referencias: el uuidV7 de la persona como person_uid (el tipo uuidV7, no un nombre de propiedad) más información local de referencia (función/rol, derechos).
Por qué: minimización de datos (RGPD art. 5), identificación inequívoca (el nombre real no es inequívoco) y derechos de los interesados realmente aplicables (información/eliminación/portabilidad) — un hecho de PII existe una sola vez, todas las demás ubicaciones remiten a él. Los escaneos en bruto (documentos de identidad/firmas) permanecen fuera de Git.
Herramientas: la solución GitCover.PII (UI de autogestión similar a una cuenta de Google: aspectos obligatorios del RGPD, anotaciones de bloqueo, retención, datos de contacto) integra GitCover.IdP (IAM) y GitCover.Ledger (evidencia).
SSoT normativo:
OSS/TOP/.gitcover/specs/pii-separation.md.
Orden y normalización: Los tratamientos se determinan primero según la disposición del GDPR (legalBasis, art. 6/9 RGPD) y después mediante la referencia (dónde/por qué medio) — legalBasis es el ancla (no una lista libre de finalidades). Los permisos («permiso por el usuario») se documentan técnicamente como GCPN y solo se referencian. Los supuestos del RGPD se normalizan como ENUMs/UNIONs en GCBoK; un catálogo OSCAL + conjuntos de artefactos OPA (SSoT: .gitcover/policy/pii-gdpr.catalog.json, pii_legal_basis.rego) es consumido por la funcionalidad GitCover.PII (Policy-as-Code).
Soberanía de los datos en lugar de Vendor Lock-In: Los hechos que surgen en PII deben sustituir opcionalmente los grafos de cuentas de usuario de M365/MS — los datos personales no se gestionan en una plataforma en la nube, sino en el repositorio de Git. Esto permite cumplimiento nativo de Git (a prueba de auditoría, autorreferencial) y plena soberanía de los datos del usuario sin Vendor Lock-In. Los hechos de PII son al mismo tiempo la base de datos para la funcionalidad OU (GitCover.Discovery/plans/ADR-005), que provee a System.DirectoryServices (Microsoft Active Directory) con estructura de OU/aprovisionamiento — las personas allí solo mediante person_uid; GitCover.IdP sigue siendo el servidor de autorización.