Open Source Lizenzen für deine Hardware-Designs

Open Source Lizenzen für Hardware-Designs sind für Maker, Start-ups und Unternehmen längst mehr als ein „Nice-to-have“: Sie bestimmen, was andere mit Ihren Schaltplänen, PCB-Layouts, Stücklisten (BOM), Firmware-Quellen, Gehäusedateien und Dokumentationen tun dürfen – und welche Pflichten dabei entstehen. Wer sein Hardwareprojekt veröffentlicht, möchte meist zwei Dinge zugleich: maximale Nachnutzung und klare Leitplanken gegen Missbrauch oder ungewollte „Closed“-Abspaltungen. Genau hier entscheidet die Lizenzwahl über Erfolg oder Frust. Anders als bei reiner Software besteht Hardware typischerweise aus mehreren „Artefakten“ (z. B. KiCad-Dateien, Gerber, STEP/STL, Code, Handbuch). Deshalb gibt es nicht die eine perfekte Lizenz, sondern ein Lizenz-Set, das zu Ihrem Ziel passt: permissiv, reziprok („Share-Alike“) oder mit stärkerer Copyleft-Wirkung. Dieser Leitfaden erklärt die wichtigsten Besonderheiten, typische Fallstricke und praxistaugliche Strategien – so, dass Sie Ihre Designs rechtssicher und nachvollziehbar veröffentlichen können.

Warum Hardware-Lizenzen anders ticken als Software-Lizenzen

Bei Software ist der Gegenstand klar: Quellcode wird kopiert, verändert und verteilt. Bei Hardware kommt eine zusätzliche Ebene dazu – die physische Umsetzung. Ein Layout kann als Datei verbreitet werden, aber der entscheidende Schritt ist oft die Herstellung und der Vertrieb des daraus entstehenden Produkts. Genau deshalb sprechen viele Hardwarelizenzen explizit über „Fertigung“, „Herstellung“, „Instanziierung“ oder „Produktion“.

• Mehrere Werkstypen: Schaltplan/PCB-Layout, Firmware, CAD-Dateien, Dokumentation können unterschiedliche Lizenzen benötigen.
• Herstellung als Nutzung: Manche Lizenzen regeln nicht nur Verbreitung von Dateien, sondern auch die Herstellung des physischen Geräts.
• Lieferkettenrealität: Fertiger, EMS-Dienstleister und Distributoren brauchen eindeutige Freigaben, sonst blockieren Compliance-Abteilungen.
• Markenrecht bleibt separat: Name, Logo und Produktdesign (Trade Dress) sind nicht automatisch „Open Source“, auch wenn die Hardware offen ist.

Die Bausteine eines Hardwareprojekts: Was genau wird lizenziert?

Ein häufiger Fehler ist, eine einzige Lizenz „über alles“ zu stülpen. Besser ist es, Ihr Repository in klar getrennte Bereiche zu strukturieren und pro Bereich passend zu lizenzieren. Typische Bestandteile sind:

• Elektronikdesign: Schaltplan (z. B. KiCad/Altium), PCB-Layout, Bibliotheken, Gerber/Drill-Dateien.
• Mechanik: CAD (STEP), 3D-Druck (STL), Zeichnungen, Gehäusevarianten.
• Firmware/Software: Microcontroller-Code, Tools, Skripte, Testprogramme.
• Dokumentation: Readme, Handbuch, Montageanleitung, Bilder, Datenblätterauszüge, Tutorials.
• Begleitmaterial: BOM, Bestückungspläne, Pick-and-Place, Fertigungsnotizen, Test-Jigs.

Die Open Source Hardware Association beschreibt Grundprinzipien und Erwartungen rund um offene Hardware sehr anschaulich, inklusive typischer Dokumentationsanforderungen: Definition und Grundlagen zu Open Source Hardware.

Lizenztypen im Überblick: permissiv, reziprok, stark reziprok

Bei Open Source Lizenzen für Hardware-Designs lassen sich die meisten Modelle grob in drei Kategorien einordnen. Die Unterschiede sind praktisch entscheidend, vor allem bei kommerzieller Nutzung und bei Derivaten (Abwandlungen).

Permissive Lizenzen: maximale Freiheit, minimale Pflichten

Permissive Lizenzen erlauben Nutzung, Anpassung und auch proprietäre Weiterentwicklung – meist bei Pflicht zur Urheberhinweis-Beibehaltung und Haftungsausschluss. Das ist ideal, wenn Sie maximale Verbreitung möchten, auch in kommerziellen Produkten ohne Offenlegungspflicht.

• Solderpad Hardware License (SHL): An Apache 2.0 angelehnt und auf Hardware übertragen; geeignet, wenn Sie ein „Apache-ähnliches“ Modell für Designs möchten. Ein öffentlich einsehbarer Lizenztext findet sich z. B. hier: Solderpad Hardware License v2.1 (Beispieltext).
• Apache 2.0 / MIT für Begleitsoftware: Für Firmware und Tools sind klassische Softwarelizenzen oft die sauberste Wahl, wenn Sie permissiv bleiben wollen. Orientierung bietet u. a. Lizenzübersicht der GNU-Projektseite.

Reziproke Lizenzen: Änderungen müssen offen bleiben

Reziproke (Share-Alike/Copyleft) Lizenzen verlangen typischerweise, dass abgeleitete Werke unter derselben oder kompatiblen Lizenz veröffentlicht werden. Das schützt vor „Closed“-Forks, kann aber Unternehmen abschrecken, die proprietäre Erweiterungen planen.

• CERN Open Hardware Licence v2: Ein etabliertes Modell mit Varianten (z. B. permissiv vs. reziprok). Eine gut zugängliche Übersicht ist hier verfügbar: CERN-OHL v2 – Überblick und Einordnung.
• TAPR Open Hardware License: Eine der älteren Hardwarelizenzen mit Fokus auf Weitergabe und Offenheit. Der Text ist hier abrufbar: TAPR Open Hardware License.

Stark reziprok: Copyleft mit „harter Kante“

Stark reziproke Modelle gehen weiter: Nicht nur die Dateien, sondern auch bestimmte Formen der Nutzung/Distribution können Offenlegungspflichten auslösen. Das ist attraktiv, wenn Sie sicherstellen wollen, dass Verbesserungen am Design der Community zurückgegeben werden. Gleichzeitig steigt die Komplexität in der Praxis (Compliance, Lieferkette, Produktvarianten).

Dokumentation separat betrachten: Creative Commons ist nicht automatisch „Hardware-Lizenz“

Viele Maker nutzen Creative-Commons-Lizenzen für Dokumentation, Bilder und Texte – was sinnvoll sein kann. Allerdings sind CC-Lizenzen nicht primär als Lizenz für technische Hardware-Design-Dateien konzipiert. Eine praxistaugliche Lösung ist oft: technische Design-Artefakte unter einer echten Hardwarelizenz (z. B. CERN OHL oder SHL), Dokumentation unter CC.

• Für Handbücher, Anleitungen, Fotos: Häufig genutzt sind CC BY oder CC BY-SA (je nach gewünschter Offenheit).
• Für CAD/Layouts: Besser eine Hardwarelizenz, die Herstellung und Weitergabe klar adressiert.

Eine verständliche Einstiegssammlung zu Creative-Commons-Modellen bietet die offizielle CC-Seite: Creative Commons Lizenzmodule im Überblick.

Kompatibilität und „License Stacking“: Wenn mehrere Lizenzen zusammenkommen

In realen Projekten treffen Bibliotheken, Footprints, Symbole, Code-Snippets und Drittanbieter-Komponenten aufeinander. Dadurch entstehen Lizenzketten. Typische Problempunkte:

• KiCad/Altium-Bibliotheken: Footprints und Symbole können eigene Lizenzbedingungen haben. Prüfen Sie, ob Sie sie mitverteilen dürfen.
• Datenblätter und Grafiken: Hersteller-PDFs sind meist urheberrechtlich geschützt; lieber verlinken statt einchecken.
• Firmware-Libraries: Arduino-Libraries können GPL, LGPL, MIT etc. haben. Das kann Ihre Firmware-Lizenz beeinflussen.
• Fonts und Icons: UI-Projekte (Displays, E-Paper) bringen schnell Lizenzfragen für Schriftarten und Piktogramme mit.

Wenn Sie unsicher sind, hilft ein strukturierter Ansatz: Trennen Sie Quellbestände nach Herkunft, dokumentieren Sie Lizenzquellen und legen Sie pro Ordner eine kurze Lizenznotiz ab. Als Orientierung für saubere Lizenzkennzeichnung wird häufig der Ansatz „SPDX-Identifier in Dateien“ genutzt; die offizielle SPDX-Seite erklärt die Idee und Identifier: SPDX-Standard für Lizenzkennzeichnung.

Welche Lizenz passt zu welchem Ziel?

Die beste Lizenz ist die, die Ihre Projektziele unterstützt – nicht die „strengste“ oder „bekannteste“. Eine praxiserprobte Entscheidungshilfe:

• Maximale Verbreitung (auch kommerziell): permissiv (z. B. SHL/Apache-ähnlich) + klare Namens-/Markenregeln.
• Community-Verbesserungen zurückholen: reziprok (z. B. CERN OHL reziproke Varianten) + gute Contribution-Regeln.
• Open-Ökosystem schützen: stark reziprok + klare Definition, wann ein „Derived Work“ vorliegt.
• Schul-/Lehrmaterial und Tutorials: Dokumentation unter CC BY(-SA), Hardware-Design passend dazu unter Hardwarelizenz.

Für eine schnelle, gut lesbare Orientierung ist auch die allgemeine Lizenz-Entscheidungshilfe nützlich – nicht nur für Software, sondern als Strukturgeber: Choose a License – Entscheidungshilfe.

Praxis: So lizenzieren Sie ein Pro-Mini-nahes Hardwareprojekt sauber

Viele Projekte rund um Mikrocontroller (z. B. Pro-Mini-Boards, Sensor-Platinen, Adapter) enthalten wiederkehrende Dateitypen. Ein empfehlenswertes Set-up sieht so aus:

• /hardware: Schaltplan, PCB-Layout, Gerber, Pick-and-Place – unter Hardwarelizenz (z. B. CERN OHL oder SHL).
• /firmware: Arduino-Sketches, Libraries, Testcode – unter Softwarelizenz (z. B. MIT/Apache oder GPL/LGPL je nach Ziel).
• /mechanical: STEP/STL, Zeichnungen – je nach Nutzung Hardwarelizenz oder (bei reiner Doku) CC.
• /docs: Aufbauanleitung, Bilder, BOM-Erklärung – typischerweise CC BY oder CC BY-SA.
• /LICENSES: Sammlung der Lizenztexte (inkl. Drittanteile) und ggf. Klartext-Erklärung.

Ergänzen Sie eine kurze Datei wie „LICENSE-OVERVIEW.html“ oder „README“ mit einer Tabelle, die pro Ordner Lizenz und Zweck nennt. Das reduziert Nachfragen und erhöht die Wiederverwendbarkeit Ihres Projekts erheblich.

Copyright, Patente, Marken: Drei Ebenen, die oft verwechselt werden

Open Source Lizenzen für Hardware-Designs betreffen in erster Linie urheberrechtliche Nutzungsrechte an den Dateien und Werken. In der Praxis spielen aber zwei weitere Rechte eine große Rolle:

• Patente: Manche Lizenzen enthalten Patentklauseln (bekannt aus Apache-ähnlichen Modellen). Das kann für Unternehmen entscheidend sein, wenn Innovationen geschützt sind.
• Marken: Ihr Projektname, Logo oder Produktlabel bleibt in aller Regel Ihr Markenrecht – auch bei offener Hardware. Das ermöglicht „Open Design, geschützter Name“.
• Designschutz: Gehäuseformen oder Produktdesign können zusätzlich geschützt sein, unabhängig von der CAD-Datei-Lizenz.

Ein praktischer Tipp: Legen Sie eine „TRADEMARKS“-Notiz an, in der Sie erklären, wie Name/Logo verwendet werden dürfen (z. B. „kompatibel mit“, „basierend auf“). Das verhindert, dass Dritte mit Ihrer Marke Verwirrung stiften.

Einbindung von Drittmodulen: Was gilt bei fertigen Bauteilen und Referenzdesigns?

Viele Hardwareprojekte verwenden Module (Funk, Sensorik, Ladeelektronik) oder orientieren sich an Referenzdesigns. Lizenzrechtlich relevant sind dabei vor allem Dokumente und Layoutfragmente, die Sie übernehmen. Fertige Bauteile selbst sind nicht „lizenziert“ wie Dateien, aber die Designdateien dazu können es sein.

• Referenzdesigns: Prüfen, ob der Hersteller eine Lizenz für die PCB-Dateien/Schaltpläne erteilt oder nur ein PDF zur Ansicht bereitstellt.
• Symbol-/Footprint-Übernahmen: Wenn Sie Bibliotheken kopieren, übernehmen Sie oft auch deren Lizenzbedingungen.
• Datasheet-Auszüge: Besser verlinken statt kopieren – so vermeiden Sie Urheberrechtsrisiken.

Veröffentlichung und Nachvollziehbarkeit: Was „gute Offenheit“ praktisch bedeutet

Offenheit zeigt sich nicht nur in der Lizenz, sondern in der Qualität der Veröffentlichung. Wenn andere Ihr Projekt wirklich nachbauen sollen, brauchen sie reproduzierbare Daten. Das erhöht auch Ihre eigene Wartbarkeit.

• Fertigungspaket: Gerber/Drill, BOM, Pick-and-Place, Bestückungsdruck, Versionshinweise.
• Reproduzierbare Versionen: Releases (z. B. v1.0, v1.1) mit zugehörigen Fertigungsdateien.
• Änderungshistorie: Changelog, kurze Begründungen für Designentscheidungen.
• Lizenzhinweise in Dateien: Header oder SPDX-Identifier, wo passend.

Wenn Sie zusätzlich eine Open-Source-Hardware-Zertifizierung anstreben, finden Sie Kriterien und Ablauf bei der OSHWA-Zertifizierung: OSHWA-Zertifizierung für Open Source Hardware.

Kommerzielle Nutzung: Wie Sie „Open“ und „Business“ sinnvoll kombinieren

Offene Hardware schließt ein Geschäftsmodell nicht aus – im Gegenteil. Viele Projekte finanzieren sich über Fertigung, Qualität, Support, Kits oder Zusatzleistungen. Die Lizenz beeinflusst dabei, wie leicht Dritte „mitziehen“ können, und wie Sie sich differenzieren.

• Qualität & Dokumentation: Selbst wenn Dritte nachbauen dürfen, gewinnen Sie mit besserer QA, Tests und Support.
• Kits und geprüfte Komponenten: Kunden zahlen für verlässliche BOM, geprüfte Lieferkette, Montagekomfort.
• Dual Licensing: In manchen Fällen möglich: offene Community-Lizenz plus separate kommerzielle Lizenz für Sonderfälle.
• Markenstrategie: Offenes Design, aber geschützter Markenname für „Original“-Produkte.

Checkliste: In 30 Minuten zu einer belastbaren Lizenzstruktur

• Repository in Hardware, Firmware, Mechanik und Doku trennen.
• Für Hardware-Dateien eine passende Hardwarelizenz wählen (permissiv oder reziprok).
• Für Firmware eine etablierte Softwarelizenz wählen und Library-Lizenzen prüfen.
• Dokumentation separat lizenzieren (z. B. CC BY oder CC BY-SA) und Bildrechte klären.
• In jedem Hauptordner eine kurze LICENSE-NOTICE ablegen (1–2 Absätze reichen).
• Urheber, Jahr und Lizenz in zentraler Datei dokumentieren; Drittanteile auflisten.
• Eine klare Namens-/Markenregel ergänzen (kurze Trademark-Notiz).
• Release-Pakete mit Fertigungsdaten bereitstellen, damit die Lizenz praktisch nutzbar ist.

Typische Fallstricke und wie Sie sie vermeiden

• „Alles unter GPL“ ohne Trennung: Kann unbeabsichtigt Dokumentation, CAD und Hardwaredateien verkomplizieren. Besser modular lizenzieren.
• Unklare Definition von „Modifikation“: Beschreiben Sie, welche Dateien als „Design Source“ gelten und wie Derivate zu kennzeichnen sind.
• Fehlende Lizenztexte: Ein Link allein reicht oft nicht. Legen Sie den Lizenztext (oder Verweis auf verbindliche Quelle) sauber ab.
• Fremdmaterial im Repo: Datenblätter, Bilder oder Texte ohne Rechteklärung führen schnell zu Takedown-Risiken.
• Keine Versionsstabilität: Ohne Releases und reproduzierbare Fertigungsdateien ist „Open“ zwar formal, aber praktisch schwer nutzbar.

Weiterführende Ressourcen für die Lizenzentscheidung

• OSHWA: Open Source Hardware – Grundlagen und Definition
• TAPR Open Hardware License: Offizieller Lizenztext
• CERN-OHL v2: Einordnung und Überblick
• SPDX: Lizenzkennzeichnung standardisieren
• Creative Commons: Lizenzmodule für Dokumentation

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.