Open-Source-Lizenzen, GPL-Auswirkungen und Third-Party Notices
Lizenzrisiken verstehen: permissive Lizenzen, Copyleft, GPL/AGPL-Folgen, Notices, SBOM und Review-Prozess.
Warum dieses Thema in Version 5 wichtig ist
Version 5 behandelt Open-Source-Lizenzen, GPL-Auswirkungen und Third-Party Notices als Senior-Thema. In echten Enterprise-Projekten reicht es nicht, eine Bibliothek einzubauen oder ein Pattern zu kennen. Entscheidend ist, ob die Lösung fachlich begründet, testbar, betreibbar, sicher und langfristig änderbar bleibt.
Orientierungsrahmen
| Aspekt | Erklärung |
|---|---|
| Ausgangspunkt | Das Thema wird als Teil einer produktionsreifen Java-Enterprise-Landschaft betrachtet, nicht als isolierte Technik. |
| Kernfrage | Welche fachliche Grenze, Betriebsgrenze oder Integrationsgrenze wird durch Open-Source-Lizenzen, GPL-Auswirkungen und Third-Party Notices sichtbar? |
| Risiko | Scheinbar technische Details erzeugen oft fachliche Nebenwirkungen: Datenverlust, Dopplungen, unklare Ownership, Sicherheitslücken oder hohe Betriebskosten. |
| Nachweis | ADR, Test, Runbook, Metrik, Trace, Contract, SBOM oder Code-Kommentar muss zeigen, dass die Entscheidung verstanden wurde. |
Technisches Beispiel
Das Beispiel zeigt absichtlich keine Framework-Magie. Die Regel wird als Java-Objekt formuliert. Dadurch kann sie in Spring Boot, Jakarta EE, Quarkus oder Micronaut verwendet und mit Unit-Tests abgesichert werden.
package at.aydinsude.enterprise.v5.sketch; import java.time.Instant; import java.util.List; import java.util.Map; // Pattern: Policy Object - kapselt eine wiederverwendbare Architekturregel. // Pattern: Strategy - unterschiedliche Projektsituationen können andere Bewertungen liefern. public final class LicenseReviewRule { public ArchitectureDecision evaluate(ArchitectureContext context) { int risk = context.businessCriticality() + context.integrationCount() + context.operationalComplexity(); String action = risk >= 9 ? "formal-review" : risk >= 5 ? "lightweight-adr" : "team-standard"; return new ArchitectureDecision(action, risk, Instant.now(), List.of( "document trade-offs", "add automated evidence", "define rollback or recovery path")); } public record ArchitectureContext(int businessCriticality, int integrationCount, int operationalComplexity, Map<String, String> tags) {} public record ArchitectureDecision(String action, int riskScore, Instant decidedAt, List<String> evidence) {} }
Die gleiche Entscheidung muss im Projekt sichtbar bleiben. Eine kleine YAML- oder Markdown-Dokumentation hilft, Standards zu automatisieren und Ausnahmen sauber zu erklären.
# open-source-lizenzen-gpl-auswirkungen-und-third-party-notices.yaml owner: enterprise-architecture chapter: 102 risk_level: senior evidence_required: - adr - architecture-test - runbook - monitoring-dashboard review: cadence: quarterly escalation: architecture-board
Typische Fehlerbilder
Prüffragen für Senior Entwickler
- Welche Entscheidung wird hier wirklich getroffen?
- Welche Alternative wurde bewusst verworfen?
- Welche Metrik zeigt im Betrieb, ob die Annahme noch stimmt?
- Welche Tests verhindern Rückfälle?
- Welche Dokumentation muss im Repository liegen?
- Welche Auswirkung hat das Thema auf Legacy-Migration, OpenShift-Betrieb und Kosten?