Geistiges Eigentum und Compliance

Diese Informationsübersetzung ist keine Rechtsberatung. Maßgeblich sind die Originalrechtstexte.

Dieses Dokument unterstützt Compliance- und Beschaffungsprüfungen sowie Beitragende. Quellenprüfungen stehen im Provenienzüberblick.

1. Zusammengesetztes Lizenzmodell

Eigener OdfKit-Code nutzt CC0 1.0 Universal; Abhängigkeiten behalten MIT-, BSD- oder andere Lizenzen, OASIS-Schemas ihr OASIS Copyright und Fixtures die im Manifest angegebene Lizenz. Weitergabe muss LICENSE und THIRD-PARTY-NOTICES.md erfüllen. Das Gesamtprodukt darf nicht als gemeinfrei bezeichnet werden.

Patent- und Markengrenzen von CC0

Nach Abschnitt 4(a) von CC0 1.0 werden Patent- und Markenrechte weder eingeräumt noch aufgegeben. OdfKit gewährt keine Patentlizenz, Nichtverletzungsgarantie, Patentrecherche oder Freistellung. Anwender müssen selbst prüfen. Maßgeblich ist der CC0-Rechtstext.

2. Rechteinhaber und KI-Inhalte

Öffentlicher Code, Dokumentation, Beispiele und Tests wurden überwiegend mit KI-Werkzeugen erstellt oder geordnet. Ein CC0 Affirmer und jeder Beitragende muss über die eingeräumten Rechte verfügen. Die urheberrechtliche Bewertung rein maschineller Werke unterscheidet sich je nach Rechtsordnung. Das Projekt bietet keine kommerzielle Freistellung.

3. Clean-room und verbotene Quellen

Öffentliche OASIS-/ISO-/RFC-/W3C-Spezifikationen, öffentliche Wire-Formate, weiterverteilbare Fixtures, Verhaltensvergleiche und eigene Regressionstests sind zulässig. Das Kopieren von LibreOffice C++, Java ODF Toolkit, Apache POI, NPOI, kommerziellen SDKs oder dekompilierten Binärdateien ist verboten. JSON Collaboration ist kompatibel, aber keine Quellcodeportierung.

4. Standards und Marken

Beschreibende Nennungen von OpenDocument, ODF, OpenFormula, OOXML und LibreOffice-Tests sind zulässig. Eine Zertifizierung oder Unterstützung durch OASIS, TDF, LibreOffice oder Apache darf nicht angedeutet werden.

5. Developer Certificate of Origin (DCO)

Beitragende müssen Schöpfung oder Einreichungsrecht, das Fehlen unzulässiger Drittquellen, die Einhaltung des Clean-room-Index und aktualisierte Drittanbieterhinweise bestätigen können. Empfohlen ist Signed-off-by: Name <email>; Commits müssen außerdem GPG-signiert sein.

6. Prüfung durch Anwender

Prüfen Sie Lizenz und SBOM, Version 0.x, Funktionsgrenzen, Ressourcenlimits, Provenienz und Support. Es gibt kein SLA; kritische Systeme benötigen Rückfall- und Wartungspläne.

7. Sicherheitsmeldungen

Derzeit bestehen weder öffentlicher Issue-Tracker noch privater Meldekanal und keine Bearbeitungszusage. Vollständige Exploitdetails gehören auch künftig nicht in öffentliche Meldungen. Sicherheits- und Lizenzfragen sind getrennt zu behandeln.

8. Verwandte Dokumente

Siehe den Clean-room-Quellenindex, die Foreign-Extension-Richtlinie und die Corpus-Regeln.