# Licensing Strategy

## Aktueller Stand

Der Quellstand enthält derzeit die MIT-Lizenz. Sie erlaubt ausdrücklich Nutzung, Änderung, Weitergabe, Unterlizenzierung und Verkauf von Kopien unter Einhaltung der Lizenzbedingungen.

Die Runtime-Lizenz der Universal License Platform ist deshalb primär eine **technische und vertragliche Grenze der offiziellen Distribution**, nicht ein Ersatz für eine bewusst gewählte Software-Lizenzstrategie.

## Mögliche Produktstrategien

### Permissive Open Source + kommerzielle Dienste

MIT/Apache-2.0 bleibt bestehen. Monetarisiert werden beispielsweise:

- offizielle Managed-/Hosted-Dienste;
- Support und SLA;
- Verifikations- und Signaturdienste;
- Marken-/Trust-Programme;
- offizielle Images und Updatekanäle.

Das maximiert Adoption, schützt aber einzelne lokal vorhandene Funktionen nicht exklusiv.

### Dual Licensing

Eine häufige Alternative ist eine Copyleft-Open-Source-Lizenz für die Community-Ausgabe und eine separate kommerzielle Lizenz für Kunden, die die Copyleft-Bedingungen nicht übernehmen möchten. Eine solche Umstellung sollte nur vorgenommen werden, wenn die erforderlichen Rechte an allen Beiträgen vorliegen.

### Open Core

Ein vollständig offener Kern und separat lizenzierte, nicht unter der Open-Source-Lizenz veröffentlichte Enterprise-Komponenten sind ebenfalls möglich. Dabei muss die Lizenzgrenze im Repository und in Build-Artefakten eindeutig dokumentiert werden.

## Empfehlung vor öffentlichem Launch

Vor einer kommerziellen Veröffentlichung sollten insbesondere entschieden und juristisch geprüft werden:

1. welche Teile tatsächlich Open Source sein sollen;
2. ob MIT beibehalten, Dual Licensing verwendet oder ein Open-Core-Modell gewählt wird;
3. welche Marken/Logos ausschließlich für offizielle bzw. verifizierte Implementierungen verwendet werden dürfen;
4. welche Vertragsbedingungen für Runtime-Lizenzen, Support, SLA und Verifikation gelten.

Diese Datei beschreibt Produktarchitektur und ersetzt keine Rechtsberatung.