Nützliche Infos und Links

Informationsportale zu Lizenzen

Lizenz‑Picker & allgemeine Informationsportale

Choose a License – Interaktive Hilfestellung, die anhand Ihrer Projekt‑Ziele passende Open‑Source‑Software‑Lizenzen vorschlägt.\ https://choosealicense
GitHub – Choose a License – Offizielle GitHub‑Seite, gleiches Angebot wie choosealicense.com, aber direkt im Git‑Workflow integriert.\ https://github.com/github/choosealicense.com 
Open Source Initiative (OSI) – Lizenz‑Liste – Vollständige Auflistung aller von der OSI anerkannten Software‑Lizenzen inkl. Kurz‑Infos und Links zum Volltext.\ https://opensource.org/licenses
SPDX License List – Maschinell lesbare Lizenz‑IDs, die in Build‑ und CI‑Tools verwendet werden können – praktisch für automatisierte Lizenz‑Reports.\ https://spdx.org/licenses/ 
FSF – Guide zu freien Lizenzen – Ausführliche Erläuterungen zu GPL‑Familie, LGPL, AGPL und deren rechtlichen Konsequenzen.\ https://www.fsf.org/licensing
Linux Foundation – Open‑Source‑Licensing Guide – White‑Paper mit Überblick über gängige Lizenzen, Kompatibilitätsfragen und Best‑Practices für Unternehmen.\ https://www.linuxfoundation.org/resources/open-source-guides/ 
Debian Free Software Guidelines (DFSG) – Kriterien, nach denen Debian Software als „frei“ klassifiziert – nützlich, um die Freiheit einer Lizenz zu prüfen.\ https://www.debian.org/social_contract#guidelines

Kompatibilitäts‑ und Analyse‑Tools

Interoperable Europe – Lizenz‑Finder – EU‑Projekt, das Lizenzen filterbar macht, Vergleiche erlaubt und nach Anwendungsbereich sowie Rechtsrahmen sortiert.\ https://interoperable-europe.ec.europa.eu/collection/eupl/solution/licensing-assistant/find-and-compare-software-licenses abgerufen
Interoperable Europe – Kompatibilitäts‑Check – Online‑Tool, das prüft, ob zwei gewählte Lizenzen (Software + Hardware) miteinander vereinbar sind.\ https://interoperable-europe.ec.europa.eu/collection/eupl/solution/licensing-assistant/compatibility-checker
tldrlegal – Kurz‑Zusammenfassungen aller gängigen OSS‑Lizenzen in leicht verständlicher Sprache (Hinweis: gelegentlich fehlt juristische Präzision).\ https://www.tldrlegal.com abgerufen
OSS Review Toolkit (ORT) – Kommandozeilen‑Tool, das Projekte scannt, Lizenz‑ und Sicherheits‑Risiken automatisiert erkennt und SBOMs erstellt.\ https://oss-review-toolkit.org/ort/
Licensee (GitHub‑Action) – Automatischer Lizenz‑Scanner für Git‑Repos, der im CI‑Workflow unbekannte oder unzulässige Lizenzen meldet.\ https://github.com/licensee/licensee
Tidelift – Lizenz‑Kompatibilitäts‑Matrix – Interaktive Matrix, die anzeigt, welche Lizenz‑Kombinationen miteinander kompatibel sind – praktisch bei gemischten OSS/OSH‑Stacks.\ https://tidelift.com/license-compliance
OSSA – Open‑Source‑Compliance‑Plattform – Cloud‑basiertes Tool, das sowohl Lizenz‑ als auch Sicherheits‑Compliance prüft; kosten‑frei für reine Open‑Source‑Projekte.\ https://fossa.com

Open‑Source‑Hardware (OSH) – Lizenzen und Ressourcen

CERN Open Hardware Licence (CERN‑OHL) – Der de‑Facto‑Standard für OSH, verfügbar in drei Varianten (v1, v2, v2‑with‑exception). Copyleft‑Optionen für Hardware.\ https://cern-ohl.web.cern.ch 
Übersicht der drei großen OSH‑Lizenzen – Gegenüberstellung von CERN‑OHL, TAPR‑HA und anderen verbreiteten Hardware‑Lizenzen, inkl. Vor‑ und Nachteilen.\ https://curriculum.openhardware.space/articles/06-licenses-and-standards/oh-licenses/
OSHW Certification – FAQ – Offizielle Fragen‑und‑Antwort‑Sammlung der Open‑Source‑Hardware‑Association zu Lizenzwahl, Marken‑ und Zertifizierungsanforderungen.\ https://certification.oshwa.org/faq/
Open‑Source‑Hardware – Lizenz‑FAQ der Open Hardware Community – Community‑Erfahrungen zu Lizenz‑Interpretationen und Best‑Practices beim Publizieren von Hardware‑Designs.\ https://forum.oshwa.org/t/license-faq

Zertifizierung von Open-Source Hardware

Zweck

Eine Zertifizierung gibt einem Open‑Source‑Hardware‑Projekt (OSH) ein glaubwürdiges Vertrauenssignal. Sie belegt, dass das Design vollständig offen, reproduzierbar und rechtlich eindeutig geklärt ist – ein wichtiges Kriterium für Fördermittel, industrielle Partner und Nutzer, die das Produkt in ihre eigenen Anwendungen integrieren wollen.

Zertifizierungswege

Für die meisten OSH‑Entwicklungen reicht die Selbst‑Zertifizierung über die OSHWA‑Open‑Source‑Hardware‑Declaration aus. Hier legt das Projekt im öffentlichen Repository Lizenz‑ und Metadaten‑Informationen offen, beantragt das offizielle OSHW‑Badge und erhält sofort ein sichtbares Qualitätssiegel.

Wenn das Projekt darüber hinaus in den regulierten Markt (z. B. Medizintechnik, industrielle Elektronik) eingeführt werden soll, ist eine formale Zertifizierung sinnvoll. Dazu gehören das OSHWA‑Certified Product‑Siegel (gegen eine moderate Jahresgebühr), sowie klassische Sicherheits‑ und Konformitätsprüfungen wie TÜV‑EMC‑Tests, CE‑Markierung nach Low‑Voltage‑Directive und ggf. ein ISO 9001‑Qualitäts‑Management‑System.

Kurzüberblick über relevante Programme

Programm	Ziel	wichtigste Anforderungen	Kosten / Prüfungsmodus
OSHWA‑Declaration	Alle OSH‑Projekte	Offenlegung von Design‑Files, Lizenz (SPDX‑Header), vollständige Metadaten, Nachweis der Reproduzierbarkeit	kostenlos, Selbst‑Deklaration (optional Review)
OSHWA‑Certified  Product	Projekte mit breiter öffentlicher Nutzung	Vollständige Metadaten, Lizenz‑Konformität, Dokumentations‑Vollständigkeit, reproduzierbarer Build‑Prozess	150 – 300 €/Jahr, Review durch OSHWA‑Expert*innen, Badge‑Ausstellung
TÜV‑Sicherheits/EMC	Elektronische Geräte für den EU‑Markt	Einhaltung IEC/EN‑Normen, EMV‑Tests, Sicherheits‑Check	abhängig vom Umfang, Labor‑Prüfung + Audit
CE‑Markierung (LVD, RoHS)	Geräte, die in der EU verkauft werden	Grenzwerte für Spannung, Schadstoffe, EMV	Tester + technische Dokumentation, Konformitätserklärung
ISO 9001	Unternehmen, die Serienfertigung planen	Qualitäts‑Management‑System, Dokumentations‑ und Audit‑Pflicht	Jahresgebühr + externer Audit

Für die meisten Community‑Entwicklungen ist die OSHWA‑Declaration bereits ausreichend; die übrigen Zertifikate kommen erst zum Tragen, wenn ein Produkt in den regulierten Markt überführt wird.

Check‑Liste für die OSHWA‑Declaration (Kurzfassung)

Lizenz – Jede Datei (Schaltplan, CAD, Firmware, Dokumentation) enthält einen gültigen SPDX‑Header, der auf die gewählte Open‑Hardware‑Lizenz (z. B. CERN‑OHL‑v2) verweist.
Metadaten – Im Repository‑Root liegt eine metadata.yaml nach dem OSHWA‑Schema vor (Projekt‑Name, Version, Reifegrad, Kontakt, DOI, Lizenz).
Design‑Files – Alle Quell‑CAD‑Dateien sind im Ordner hardware/ abgelegt und kommentiert.
Fertigungs‑Daten – Gerber‑ bzw. STEP‑Export, Stückliste (CSV) und eine Fertigungs‑Anleitung existieren.
Build‑ und Prüf‑Instruktionen – Schritt‑für‑Schritt‑Anleitungen, DRC/DFT‑Ergebnisse und Validierungs‑Berichte liegen im docs/‑ bzw. validation/‑Verzeichnis bereit.
Reproduzierbarkeit – Der komplette Build‑Prozess kann über ein CI‑Log (GitHub Actions) nachgeprüft werden.
Versionierung – Jeder Release wird mit einem SemVer‑Tag versehen und automatisch über Zenodo mit einem DOI versehen.
Badge & Hinweis – Das offizielle OSHW‑Badge wird im README.md eingebunden.

Sind diese Punkte erfüllt, kann das Projekt die Declaration online einreichen und erhält das OSHW‑Badge.

Ablauf einer formalen OSHWA‑Zertifizierung

Vorbereitung – Die oben genannte Check‑Liste wird abgearbeitet, fehlende Dokumente ergänzt und ein Ordner certification/ angelegt, in dem das ausgefüllte Zertifizierungs‑Formular, das Badge und das offizielle Zertifikat versioniert werden.
Einreichung – Das öffentliche Repository‑URL sowie das PDF‑Formular werden auf der OSHWA‑Zertifizierungsplattform hochgeladen.
Review – Das OSHWA‑Board prüft Lizenz‑Konformität, Vollständigkeit der Metadaten und die Nachvollziehbarkeit des Builds.
Feedback – Eventuelle Korrekturen werden nachgebessert; das Projektteam erhält Rückmeldungen innerhalb von etwa zwei Wochen.
Zertifikat – Nach erfolgreichem Review wird das Certified‑Product‑Badge (SVG/PNG) sowie ein offizielles Zertifikat (PDF) ausgestellt.
Publikation – Das Badge wird im README.md, auf der Projekt‑Webseite und im Release‑Tag eingebunden; der zugehörige Zenodo‑DOI bleibt dauerhaft erhalten.
Wartung – Bei wesentlichen Änderungen (neue Lizenz, neue Hardware‑Revision) muss das Zertifikat erneuert oder das Projekt erneut zertifiziert werden.