Patente und Lizenzen bei der STM32-Entwicklung

Bei Embedded-Projekten wird das Thema „Rechtsfragen“ oft erst dann sichtbar, wenn das Produkt in Serie gehen soll, ein Kunde eine Compliance-Erklärung verlangt oder ein Investor eine Due-Diligence startet. Genau hier ist „Patente und Lizenzen bei der STM32-Entwicklung“ für Startups, Mittelständler und auch erfahrene Teams relevant: Sie nutzen nicht nur einen Mikrocontroller, sondern ein ganzes Ökosystem aus Toolchain, Firmware-Bibliotheken, Middleware, Drittanbieter-Komponenten, Kommunikationsstandards und manchmal sogar Audio-/Video-Codecs. Jede dieser Schichten kann eigene Lizenzbedingungen haben; zusätzlich können Patente (z. B. Standard-essential Patents bei Funk oder Codecs) zu Gebühren oder Nutzungsrechten führen. Wer früh sauber arbeitet, senkt Risiken, vermeidet spätere Rewrites und hält den Weg zur Markteinführung frei. Dieser Artikel erklärt verständlich, welche Lizenzarten in der STM32-Welt typischerweise vorkommen, wie ST-Lizenzen (z. B. SLA0048) von Open-Source-Lizenzen abzugrenzen sind, wo Patente in der Praxis auftauchen und welche organisatorischen Maßnahmen helfen, ohne das Entwicklungstempo zu verlieren.

Warum Lizenzen in der STM32-Entwicklung mehr sind als „Open Source ja/nein“

In STM32-Projekten treffen meist mehrere Lizenzwelten aufeinander. Ein typisches Produkt enthält:

• ST-Tools wie STM32CubeMX oder STM32CubeIDE (eigene Lizenzbedingungen, oft mit Zusatzbedingungen und Drittsoftware-Anhängen).
• ST-Firmwarepakete (HAL/LL, Middleware, Beispielprojekte) mit gemischten Lizenzen je Komponente.
• ARM-Komponenten wie CMSIS (häufig Apache-2.0-lizenziert, je Repository/Modul).
• Drittanbieter-Stacks (z. B. Dateisysteme, TLS-Bibliotheken, RTOS, GUI-Frameworks) mit eigenen Regeln.
• Standards und Protokolle (USB, Bluetooth, WLAN, Mobilfunk), die Patente berühren können.

Die Kernfrage lautet selten „Darf ich das nutzen?“, sondern: Unter welchen Bedingungen darf ich es in einem kommerziellen Produkt verwenden, weitergeben, modifizieren und langfristig warten? Und: Entsteht daraus eine Pflicht, Quellcode offenzulegen, Lizenztexte beizulegen oder Nutzungsrechte an Dritte zu gewähren?

ST-Lizenzen verstehen: SLA0048 und warum sie für viele Pakete zentral ist

Viele STM32Cube-Softwarepakete werden unter STs Software-Lizenzvereinbarungen verteilt. Häufig begegnet Ihnen dabei SLA0048 (inklusive zusätzlicher Lizenzbedingungen), insbesondere bei Tools wie STM32CubeMX. Ein markantes Merkmal ist eine Nutzungseinschränkung: Der Softwarebestandteil (inkl. Modifikationen/Derivate) soll ausschließlich in Verbindung mit ST-Mikrocontrollern/-Prozessoren eingesetzt werden. Ein offizielles Beispiel ist die SLA0048-Version für STM32CubeMX, in der diese Bindung an ST-Hardware explizit formuliert wird: SLA0048 für STM32CubeMX (ST).

Wichtig ist zudem: ST-Pakete enthalten oft Drittsoftware unter separaten Lizenzen. Diese Drittanteile sind nicht automatisch von SLA0048 „überdeckt“, sondern bringen eigene Pflichten mit. ST stellt dafür teils explizite „Additional License Terms“ bereit, die Drittkomponenten und deren Lizenztexte aufführen: Additional License Terms für STM32CubeMX (ST).

Gemischte Lizenzlandschaften in STM32Cube-Firmwarepaketen

Viele Entwickler denken bei STM32Cube an „eine Bibliothek“. In der Realität ist ein Cube-Firmwarepaket ein Bündel: HAL/LL, CMSIS-Teile, Middleware (USB, Filesystem, TCP/IP), Utilities, Beispielprojekte und Board Support Packages. Diese Bestandteile können unterschiedliche Lizenztypen haben. In öffentlich einsehbaren LICENSE-Übersichten einzelner Cube-Repositories wird diese Mischung sichtbar, inklusive Verweisen auf BSD-3-Clause, Apache-2.0 oder ST-spezifische Texte: Beispiel: Lizenzübersicht in STM32CubeL4 (GitHub).

Für die Praxis bedeutet das: Sie dürfen nicht „das Paket“ als Ganzes beurteilen, sondern müssen die Komponenten betrachten, die Sie wirklich in Ihr Produkt übernehmen. Besonders relevant ist das, wenn Sie Middleware mit restriktiveren Bedingungen verwenden oder wenn Sie Code aus Beispielprojekten kopieren.

Open-Source-Lizenzen, die in STM32-Projekten häufig vorkommen

In der STM32-Welt begegnen Ihnen typischerweise diese Open-Source-Lizenzfamilien:

• BSD-3-Clause (sehr permissiv, typischerweise mit Pflicht zur Beibehaltung von Copyright-Hinweisen und dem Verbot der Namensnutzung für Werbung/Endorsement). Referenztext: BSD 3-Clause License (OSI).
• Apache License 2.0 (permissiv, zusätzlich mit expliziten Patentlizenz-Klauseln und NOTICE-Anforderungen; häufig bei ARM/CMSIS). ARM verweist z. B. bei CMSIS-Driver-Beispielen auf Apache 2.0: CMSIS-Driver Lizenzhinweis (ARM).
• GPL/LGPL (copyleft) (kann Quellcode-Offenlegung oder Relinking-Pflichten auslösen; taucht in Toolchains oder Drittsoftware gelegentlich auf, teils in „Additional License Terms“ gelistet).

Per „Daumenregel“ sind BSD und Apache in kommerziellen Embedded-Produkten gut handhabbar, wenn Sie die Pflichten ernst nehmen: Lizenztexte beilegen, Hinweise im Produkt/Handbuch/Über-Dialog dokumentieren, Copyrights nicht entfernen und ggf. NOTICE-Dateien übernehmen.

Praktische Lizenzpflichten: Was Sie fast immer erledigen müssen

Auch bei permissiven Lizenzen entstehen typische To-dos, die in Audits abgefragt werden. Besonders häufig:

• Lizenztexte mitliefern: In einer „Third-Party Notices“-Datei, im Handbuch (PDF), im Download-Portal oder in der Geräte-UI („About“).
• Copyright-Header erhalten: Beim Kopieren/Anpassen von Quelltexten Header nicht entfernen.
• NOTICE/Attribution: Bei Apache-2.0-Komponenten ggf. NOTICE-Inhalte beibehalten.
• Änderungen dokumentieren: Wenn Sie Drittcode modifizieren, ist es sauber (und teils erwartet), Änderungen nachzuhalten.
• Weitergabe regeln: Wenn Ihr Produkt Firmware-Images verteilt, ist das rechtlich eine Form der Distribution – dann greifen Lizenzpflichten auch ohne „Source Release“.

Ein häufiger Fehler ist, Lizenztexte erst kurz vor Release zusammenzusuchen. Besser ist ein „License Bill of Materials“ (LBOM) parallel zur technischen BOM: Jede Bibliothek mit Version, Quelle, Lizenztyp und Erfüllungsmaßnahme.

Tooling-Lizenzen vs. Firmware-Lizenzen: Diese Ebenen sollten Sie trennen

Ein typisches Missverständnis: Die Lizenz Ihrer Entwicklungswerkzeuge ist nicht automatisch die Lizenz Ihrer Firmware. STM32CubeMX und STM32CubeIDE sind Tools, die Sie lokal nutzen; deren Lizenzbedingungen definieren, was Sie damit tun dürfen. Die generierten oder mitgelieferten Codebestandteile können wiederum eigene Lizenzen haben. ST weist in Produktunterlagen und Lizenztexten häufig darauf hin, dass Drittsoftware unter separaten Bedingungen steht und dass Zusatzlizenzbedingungen gelten können. Beispielhaft sind die STM32CubeMX-bezogenen SLA0048- und Zusatzdokumente: SLA0048 STM32CubeMX und Additional License Terms.

Für Teams ist diese Trennung wichtig, weil Compliance-Aufgaben sonst vermischt werden: „Wir dürfen das Tool verwenden“ ist nicht dasselbe wie „Wir dürfen diesen Quellcode in unserem Produkt verteilen“.

Patente: Wo sie in Embedded-Produkten wirklich auftauchen

Patente sind in der STM32-Entwicklung selten „am Mikrocontroller“ festzumachen, sondern an Funktionen und Standards. In der Praxis begegnen Ihnen vor allem diese Patentfelder:

• Funkstandards: Bluetooth, WLAN, Mobilfunk (LTE/NB-IoT), teils auch LoRaWAN (weniger klassisch „SEP-getrieben“ als Mobilfunk, aber trotzdem lizenz- und markenrechtlich relevant über Stack/Implementierung).
• Audio-/Video-Codecs: MP3/AAC/H.264/H.265 sind historisch stark patentbelastet; Nutzung kann Lizenzgebühren bedeuten, abhängig von Region, Produkt und Distribution.
• Kryptografie-Implementierungen: Moderne Standards sind meist frei nutzbar, aber manche Implementierungen oder bestimmte Optimierungen können Patentklauseln in Lizenzen haben (Apache-2.0 enthält z. B. eine Patentlizenz/Patentbeendigungsklausel, was praktisch relevant sein kann).
• Industrieprotokolle: Einige Feldbusse oder „zertifizierte“ Ökosysteme koppeln Nutzung an Mitgliedschaften, Zertifizierungen oder Markenrichtlinien.

Ein wichtiger Begriff ist „Standard-essential Patents“ (SEP): Patente, die für die Implementierung eines Standards notwendig sind. Häufig werden SEPs unter FRAND/RAND-Bedingungen lizenziert. Das ist kein STM32-spezifisches Thema, aber in STM32-IoT-Produkten allgegenwärtig.

Eine einfache Kostenlogik für Patent- und Lizenzgebühren

Wenn Gebühren anfallen (z. B. bei bestimmten Codecs oder Zertifizierungsprogrammen), ist es hilfreich, den Effekt pro Gerät zu modellieren. So erkennen Sie früh, ob ein Feature das Geschäftsmodell belastet.

$Kosten$_proGerät = K_fix + R_royalty ⋅ N_Units / N_Units

In Worten: Fixkosten (z. B. Zertifizierung) plus variable Gebühren (Royalty) verteilt auf die Stückzahl. Gerade Startups unterschätzen, dass „kleine“ Gebühren bei niedrigen Stückzahlen oder geringen Margen spürbar werden.

Typische Risikofallen bei Patenten und Lizenzen in STM32-Projekten

• Copy-Paste aus Beispielcode ohne Lizenzprüfung: Auch „Examples“ können eigene Bedingungen haben, je nach Paket.
• Unklare Herkunft von Code: Snippets aus Foren, Gists oder Chat-Verläufen sind juristisch riskant, wenn Lizenz und Autorenschaft unklar sind.
• „Arduino-Style“ Bibliotheksmix in Serienprodukten: Viele kleine Libraries mit unterschiedlichen Lizenzen erhöhen den Compliance-Aufwand exponentiell.
• Codec-/Media-Funktionen ohne Lizenzstrategie: Audio/Video ist ein häufiger Patent-Stolperstein.
• Funk ohne vollständige Dokumentation: Selbst wenn ein Funkmodul „zertifiziert“ ist, bleibt Ihr Endprodukt verantwortlich für Konformität, Branding und ggf. Lizenzbedingungen.

Wie Sie ein Lizenz-Compliance-System etablieren, ohne das Team zu bremsen

Ein pragmatisches System für Startups und kleine Teams besteht aus wenigen, aber konsequenten Bausteinen:

• Third-Party Register (LBOM): Name, Version, Quelle/URL, Lizenztyp, Einsatzort (Firmware/Tool), Pflichten, Verantwortlicher.
• „No Unknown Code“-Regel: Kein Code ohne nachvollziehbare Herkunft in den Hauptbranch.
• Automatisierte Scans: In CI einfache Checks auf LICENSE/NOTICE-Dateien, SPDX-Identifier, Abhängigkeiten.
• Release-Checkliste: Lizenztexte aktualisiert, Attribution generiert, Firmware-Image-Distribution geprüft.
• Architektur-Entscheidung: Lieber wenige, gut dokumentierte Libraries als viele kleine „Bequemlichkeitsabhängigkeiten“.

Gerade bei STM32-Projekten lohnt sich zusätzlich, die ST-Dokumente pro Tool/Komponente abzuspeichern (Lizenz-PDF und Additional Terms), damit Audits später nicht an „toten Links“ scheitern. Beispielhafte offizielle ST-Dokumente sind die SLA0048 für STM32CubeMX und die dazugehörigen Zusatzbedingungen: SLA0048 (ST) und Additional License Terms (ST).

Apache-2.0 und die Patentklausel: Warum ARM/CMSIS oft „auditfreundlich“ ist

Viele ARM-nahe Projekte (inkl. Teile des CMSIS-Ökosystems) verwenden Apache 2.0. Diese Lizenz ist permissiv und enthält zugleich eine explizite Patentlizenz-Komponente, die in professionellen Umgebungen als Vorteil gesehen wird, weil sie Rechtsklarheit schafft. ARM verweist beispielsweise bei CMSIS-Driver-Implementierungen auf Apache 2.0: CMSIS-Driver: Apache-2.0 Hinweis. Für Ihr LBOM ist das hilfreich, weil Pflichten (Attribution/NOTICE) gut definierbar sind.

ST-spezifische Nutzungsbindung: Was „nur mit ST-Hardware“ praktisch heißt

Bei ST-eigenen Lizenztexten ist ein Punkt besonders relevant: die Bindung der Nutzung an ST-Hardware. In der Praxis heißt das für viele Teams:

• Wenn Sie Code oder Komponenten verwenden, die explizit an ST-Hardware gekoppelt sind, planen Sie keinen späteren „Drop-in“-Wechsel auf einen anderen MCU-Hersteller, ohne die Lizenzlage neu zu bewerten.
• Wenn Sie eine Plattformstrategie verfolgen (z. B. Produktfamilie über mehrere MCU-Anbieter), trennen Sie portable Anwendungslogik konsequent von herstellerspezifischen Treibern.

Die Formulierung zur exklusiven Nutzung „auf oder in Kombination mit“ ST-Prozessoren findet sich beispielhaft im STM32CubeMX-SLA0048-Dokument: SLA0048 STM32CubeMX.

Konkrete Handlungsempfehlungen für Einsteiger, Mittelstufe und Profis

• Einsteiger: Nutzen Sie bevorzugt offizielle STM32Cube-Pakete und dokumentieren Sie jede verwendete Library mit Link und Lizenz. Starten Sie früh eine „Third-Party Notices“-Datei, auch wenn sie noch kurz ist.
• Mittelstufe: Führen Sie ein LBOM ein, integrieren Sie Lizenzprüfungen in den Build-Prozess und definieren Sie klare Regeln für das Einbringen von externem Code (Herkunft, Lizenz, Version).
• Profis: Etablieren Sie eine formale Open-Source-Policy, nutzen Sie SPDX-Identifier, automatisieren Sie Compliance-Reports und bewerten Sie Patentrisiken systematisch bei Funk/Codecs/Industrie-Ökosystemen.

Weiterführende Quellen für die Praxis

• SLA0048 für STM32CubeMX (ST, Lizenz-PDF)
• Additional License Terms für STM32CubeMX (ST)
• Beispiel einer Lizenzübersicht in einem STM32Cube-Repository (GitHub)
• BSD-3-Clause Lizenztext (Open Source Initiative)
• CMSIS-Driver: Lizenzhinweis auf Apache 2.0 (ARM)

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.