Open Source Hardware: Darf ich Arduino-Projekte verkaufen?

Die Frage „Open Source Hardware: Darf ich Arduino-Projekte verkaufen?“ taucht spätestens dann auf, wenn aus dem Hobby ein Nebenprojekt wird: Du hast einen Prototyp gebaut, andere finden ihn spannend – und plötzlich geht es um Preise, Onlineshops, Workshops oder kleine Serien. Grundsätzlich ist das Verkaufen vieler Arduino-basierter Projekte möglich. Gleichzeitig ist das Thema komplexer, als es auf den ersten Blick wirkt, weil hier mehrere Ebenen zusammenkommen: Open-Source-Lizenzen (für Hardware-Designs und Software), Markenrecht (Arduino-Name und Logos), Produktverantwortung (Sicherheit, Gewährleistung) und je nach Produkt auch regulatorische Anforderungen (z. B. CE-Konformität). Dieser Artikel erklärt dir verständlich und praxisnah, wie du das Thema einordnest: Was bedeutet Open Source Hardware im Alltag? Wann musst du Quellcode oder Schaltpläne veröffentlichen? Was darfst du „Arduino“ nennen – und was besser nicht? Und welche Schritte helfen dir, dein Projekt legal sauber und professionell aufzustellen, ohne dich in Paragrafen zu verlieren?

Wichtig vorab: Keine Rechtsberatung, aber klare Orientierung

Gesetze und Lizenzbedingungen hängen vom Einzelfall ab: Welche Komponenten nutzt du? Welche Lizenz hat der Code? Verkaufst du nur ein fertiges Gerät, ein Bausatz, Dateien oder ein eigenes Board? Dieser Artikel bietet dir eine solide Orientierung und typische Praxisregeln. Wenn du in größerem Umfang verkaufst oder unsicher bist, ist eine rechtliche Prüfung sinnvoll – besonders bei Markenfragen, Haftung und Produktkonformität.

Was bedeutet „Open Source Hardware“ im Kern?

Open Source Hardware (OSH) beschreibt Hardware, deren Konstruktionsunterlagen so verfügbar sind, dass andere sie studieren, nachbauen, verändern und weiterverbreiten können. Das umfasst je nach Projekt zum Beispiel Schaltpläne, Layout-Dateien, Stücklisten (BOM) und Dokumentation. Entscheidend ist: „Open Source“ bedeutet nicht „gemeinfrei“ oder „ohne Regeln“, sondern „unter definierten Bedingungen“. Eine anerkannte Grundlage zur Einordnung bietet die Open Source Hardware Definition der OSHWA.

• Du darfst oft nachbauen: Viele OSH-Lizenzen erlauben auch kommerzielle Nutzung.
• Du musst häufig etwas zurückgeben: Zum Beispiel Lizenzhinweise beibehalten oder Änderungen dokumentieren.
• Marken bleiben geschützt: Open Source bedeutet nicht automatisch, dass du Markennamen oder Logos frei verwenden darfst.

Arduino als Ökosystem: Open Source trifft auf Marke

Arduino ist historisch stark durch Open-Source-Hardware und offene Software geprägt. Viele Aspekte sind bewusst so gestaltet, dass Community und Unternehmen darauf aufbauen können. Gleichzeitig ist „Arduino“ eine Marke – und Markenrecht funktioniert unabhängig von Open-Source-Lizenzen. Praktisch heißt das: Du kannst ein Arduino-kompatibles Produkt entwickeln und verkaufen, solltest aber sehr sauber damit umgehen, wie du es benennst und vermarktest. Eine zentrale Referenz für diese Einordnung sind die offiziellen Hinweise von Arduino zu Trademark & Copyright sowie die Lizenzübersicht für Produkte, die auf Arduino basieren: Licensing for products based on Arduino.

Welche „Arduino-Projekte“ willst du verkaufen? Das macht einen großen Unterschied

Im Alltag werden verschiedene Dinge unter „Arduino-Projekt verkaufen“ zusammengefasst. Für Lizenzen und Pflichten ist es aber wichtig, die Kategorie zu unterscheiden:

• Fertiges Gerät: Du verkaufst ein komplett montiertes Produkt (z. B. Wetterstation, Steuergerät, Messgerät).
• Bausatz/Kit: Du lieferst Teile + Anleitung, der Kunde baut selbst.
• Dateien/Pläne: Du verkaufst Design-Dateien, 3D-Druckdaten, Schaltpläne, PCB-Layout oder Code.
• Eigenes Board: Du entwickelst eine Arduino-kompatible Platine oder ein Shield.
• Workshops/Schulungen: Du verkaufst Wissen, Materialpakete und Unterricht.

Bei einem fertigen Gerät spielen Produktsicherheit und Haftung stärker hinein. Beim Verkauf von Dateien sind Lizenzen, Urheberrecht und klare Nutzungsbedingungen entscheidend. Bei eigenen Boards wird Marken- und Lizenzkonformität besonders wichtig.

Software-Lizenzen: Darf ich Code verkaufen – und muss ich ihn offenlegen?

Viele Arduino-Projekte enthalten Software: Sketche, Bibliotheken, Konfigurationsdateien oder PC/Smartphone-Apps. Ob du Quellcode veröffentlichen musst, hängt maßgeblich von den Lizenzen ab, die du nutzt. Grundsätzlich gilt: Du kannst Software in vielen Fällen kommerziell nutzen, aber du musst die Lizenzbedingungen einhalten. Das betrifft sowohl deinen eigenen Code als auch Bibliotheken Dritter.

Typische Lizenzfamilien im Überblick (praktisch gedacht)

• Permissive Lizenzen (z. B. MIT, BSD, Apache): Oft sehr frei. Du darfst meist auch kommerziell nutzen, musst aber Lizenzhinweise beibehalten. Bei Apache-Lizenzen spielen zudem Patent- und Hinweisbedingungen eine Rolle.
• Copyleft-Lizenzen (z. B. GPL): Können Pflichten auslösen, Quellcode (und Änderungen) unter bestimmten Umständen offenzulegen, wenn du das Werk weitergibst. Details sind komplex und hängen von Verlinkung, Distribution und Produktgestaltung ab.
• LGPL: Häufig bei Bibliotheken. In vielen Fällen darfst du sie nutzen, aber es können Bedingungen entstehen, wenn du Änderungen an der Bibliothek verteilst oder sie statisch einbindest.

Wichtig: „Ich nutze nur eine Library“ ist keine Garantie, dass alles unkompliziert ist. Seriöse Hersteller führen deshalb oft eine Liste verwendeter Komponenten und Lizenzen (Open-Source-Attribution).

Hardware-Lizenzen: Muss ich Schaltplan und Layout veröffentlichen?

Bei Open-Source-Hardware hängt die Pflicht zur Offenlegung davon ab, ob du OSH-Designs verwendest und unter welcher Lizenz diese stehen. Manche Lizenzen erlauben kommerzielle Nutzung ohne „Zurückgeben“ außer Attribution. Andere verlangen, dass Änderungen und abgeleitete Designs ebenfalls offen geteilt werden (stärkerer Copyleft-Gedanke). In der Praxis heißt das: Wenn du ein vorhandenes Open-Source-Board-Design abwandelst und verkaufst, kann es sein, dass du deine Änderungen ebenfalls veröffentlichen musst – zumindest die Design-Unterlagen, die zur Nachvollziehbarkeit notwendig sind.

Wenn du ausschließlich ein offizielles Arduino-Board kaufst und in deinem Produkt nutzt, änderst du in der Regel nicht das Arduino-Board-Design, sondern integrierst es als Komponente. Dann sind Hardware-Offenlegungspflichten meist nicht das zentrale Thema – wichtiger werden Produktsicherheit, Dokumentation und Markenführung. Die Arduino-Hinweise zu Produkten „based on Arduino“ helfen bei der Einordnung: Arduino Licensing Guide.

Markenrecht: Darf ich „Arduino“ in Produktnamen, Shop-Texten und Werbung verwenden?

Ein häufiger Stolperstein ist die Vermarktung. Viele Maker schreiben „Arduino Wetterstation“ oder „Arduino Smart Home Modul“ auf Produktseiten. Aus Kundensicht ist das verständlich, kann aber markenrechtlich sensibel sein, wenn der Eindruck entsteht, dein Produkt sei ein offizielles Arduino-Produkt oder von Arduino zertifiziert. Grundregel: Du darfst häufig kompatibel beschreiben, aber nicht so branden, als wäre es ein offizielles Board.

Praxisnahe Formulierungen, die oft besser funktionieren

• Unkritischer: „Arduino-kompatibel“, „kompatibel mit Arduino Uno“, „funktioniert mit der Arduino IDE“
• Riskanter: „Arduino® Wetterstation“ als Produktname, „offizielles Arduino-Gerät“ ohne Nachweis, Nutzung von Arduino-Logo

Für eine belastbare Orientierung sind die offiziellen Markenhinweise die wichtigste Quelle: Arduino Trademark Policy. Dort findest du auch Hinweise, welche Nutzungen typischerweise erlaubt sind (z. B. beschreibende Nutzung) und wo Grenzen liegen (z. B. Logo, Produktbranding, Verwechslungsgefahr).

„Ich verkaufe nur das Projekt, nicht Arduino“: Warum das trotzdem relevant ist

Auch wenn du kein Arduino-Board selbst verkaufst, kann Arduino in deinem Produkt auf drei Arten „drin“ sein:

• Als Komponente: Ein Arduino Uno steckt in deinem Gehäuse und wird mitverkauft.
• Als Voraussetzung: Du verkaufst ein Shield oder Modul, das ein Arduino benötigt.
• Als Plattform: Dein Projekt basiert auf Arduino-Code und Arduino-Bibliotheken.

In allen Fällen musst du auf klare Kennzeichnung achten: Was gehört zu deinem Produkt, was ist eine Drittkomponente? Wie sieht es mit Lizenzhinweisen aus? Welche Sicherheits- und Konformitätsfragen entstehen durch das Gesamtsystem?

Produktsicherheit und Haftung: Der Teil, den viele Maker unterschätzen

Spätestens wenn du an Dritte verkaufst, bist du nicht mehr nur Bastler, sondern Anbieter. Das bedeutet: Du solltest dir Gedanken machen, wie sicher das Produkt ist, wie es verwendet wird und welche Risiken du minimierst. Besonders kritisch sind Projekte mit Netzspannung, Heizungen, Motoren, Akkus oder hoher Stromaufnahme.

• Elektrische Sicherheit: Isolation, Schutzabstände, sichere Netzteile, Sicherungen.
• Thermik: Bauteile, die heiß werden (Regler, Treiber, Leistungselektronik), müssen korrekt dimensioniert und belüftet sein.
• Fehlbedienung: Verpolschutz, Überstromschutz, klare Anleitung und Warnhinweise.
• Langzeitstabilität: Wackelkontakte, Steckverbinder, Zugentlastung, Gehäuse.

Wenn du Produkte in der EU in Verkehr bringst, können je nach Art des Geräts Konformitätsanforderungen relevant werden (z. B. EMV, Niederspannung, Funk). Arduino bündelt Compliance-bezogene Informationen zu eigenen Produkten hier: Arduino Product Compliance. Das ersetzt keine Bewertung deines eigenen Endprodukts, zeigt aber, dass das Thema ernst zu nehmen ist.

CE, EMV, Funk: Wann Regulierung in der EU ins Spiel kommt

Viele Arduino-Projekte bleiben im Kleinspannungsbereich und sind reine Hobbygeräte. Sobald du aber verkaufst, kann das Thema „Inverkehrbringen“ relevant werden. Ob und welche Regeln gelten, hängt stark von der Produktart ab. Typische Auslöser sind:

• Funkmodule (WLAN/Bluetooth/LoRa): Häufig zusätzliche Anforderungen, weil Funkgeräte reguliert sind.
• Netzspannung (230 V): Erhöhte Sicherheitsanforderungen und sorgfältige Konstruktion.
• Störanfälligkeit/EMV: Geräte dürfen andere nicht stören und müssen selbst ausreichend robust sein.

Für einen ersten Überblick über die Idee von Open Source Hardware, Kennzeichnung und Best Practices hilft es oft, sich an allgemein anerkannten Definitionen und Leitlinien zu orientieren, etwa über die OSHWA-Ressourcen.

Wenn du Bibliotheken nutzt: Lizenzhinweise sauber dokumentieren

Ein professioneller Schritt, der dir später viel Stress erspart, ist eine einfache, aber konsequente Lizenzdokumentation. Das gilt besonders, wenn du Bibliotheken (Libraries) verwendest, die nicht von dir stammen.

• Bibliotheken auflisten: Name, Version, Quelle, Lizenz.
• Lizenztexte beilegen: Je nach Lizenz musst du den Text mitliefern oder verlinken.
• Änderungen markieren: Wenn du Code Dritter anpasst, dokumentiere, was du geändert hast.
• Quellen sauber nennen: Attribution ist nicht nur Pflicht, sondern erhöht auch Vertrauen.

Das ist zugleich ein E-E-A-T-Vorteil: Transparenz und Nachvollziehbarkeit wirken professionell und schaffen Vertrauen bei Kunden.

Open Source als Verkaufsargument: Warum „offen“ oft besser verkauft als „geheim“

Viele Maker haben Angst, dass ihnen „jemand alles kopiert“, wenn sie Dokumentation oder Code teilen. In der Praxis ist es oft umgekehrt: Offenheit kann ein starkes Qualitäts- und Vertrauenssignal sein. Kundinnen und Kunden kaufen nicht nur „Dateien“, sondern ein Produkt mit Support, guter Dokumentation, getesteter Hardware, Updates und Community.

• Vertrauen: Offener Code/Schaltplan zeigt, dass du nichts versteckst.
• Wartbarkeit: Kunden können Probleme besser nachvollziehen.
• Community-Effekt: Nutzer liefern Feedback, finden Bugs, schlagen Verbesserungen vor.
• Langfristigkeit: Projekte sterben seltener, wenn Wissen nicht nur bei einer Person liegt.

Typische Szenarien und was du dabei beachten solltest

Szenario: Du verkaufst ein fertiges Gerät mit eingebautem Arduino

• Marke sauber trennen: Nenne Arduino als Komponente („enthält ein Arduino-kompatibles Board“ oder „enthält Arduino Uno“ nur, wenn es wirklich ein offizielles Board ist).
• Sicherheits- und Konformitätsfragen: Gehäuse, Netzteil, EMV, Dokumentation.
• Lizenzhinweise: Bibliotheken/Code-Lizenzen dokumentieren.

Szenario: Du verkaufst ein Shield oder Modul „für Arduino Uno“

• Kompatibilität korrekt beschreiben: „Kompatibel mit Arduino Uno“ statt Branding als Arduino-Produkt.
• Dokumentation liefern: Pinbelegung, Spannungspegel, Beispielcode.
• Qualität: Schutzbeschaltungen und klare Hinweise zu Stromversorgung.

Szenario: Du verkaufst Projektdateien (Code, PCB, 3D-Druck)

• Lizenz klar definieren: Welche Nutzungen erlaubst du? Kommerziell? Weitergabe? Änderungen?
• Drittanteile prüfen: Enthaltene Bibliotheken, Bilder, Fonts, CAD-Modelle müssen lizenzkonform sein.
• Keine irreführenden Marken: Shop-Texte sauber formulieren.

Checkliste: So bereitest du den Verkauf Arduino-basierter Projekte professionell vor

• Komponentenliste: Was ist dein eigenes Werk, was ist Drittmaterial?
• Lizenz-Review: Welche Lizenzen haben Code und Hardware-Unterlagen, die du nutzt?
• Attribution: Lizenzhinweise und Quellen sauber angeben.
• Branding: Produktname und Marketing so formulieren, dass keine Verwechslung mit offiziellen Arduino-Produkten entsteht.
• Dokumentation: Bedienung, Sicherheitshinweise, typische Fehlerbilder, Support-Kontakt.
• Qualitätssicherung: Tests, Burn-in (falls sinnvoll), klare Spezifikationen (Spannung, Strom, Temperaturbereich).
• Regulatorik prüfen: Funk, Netzspannung, EMV – je nach Produktkategorie.

Outbound-Links: Verlässliche Quellen zum Nachlesen

• Arduino: Licensing for products based on Arduino
• Arduino: Trademark & Copyright
• Arduino Dokumentation: Product Compliance
• OSHWA: Open Source Hardware Definition
• OSHWA: Ressourcen und Best Practices rund um Open Source Hardware
• Arduino Docs: Offizielle Dokumentation für Plattform, IDE und Beispiele

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.