Entscheidung: Open oder Proprietär

Die grundsätzliche Frage, ob ein Produkt als Open‑Source‑Hardware (OSH) oder als geschlossenes, proprietäres System entwickelt werden soll, muss zu Beginn eines Projekts geklärt werden. In der Praxis kommt es jedoch häufig vor, dass eine bereits zu Projektstart getroffene Entscheidung später mit den Anforderungen an die Verwertung (z. B. Zertifizierung, Marktstrategie) kollidiert. Deshalb ist ein bewusstes, mehr‑perspektivisches und möglichst rationales Vorgehen zu empfehlen – nicht das bloße „Alle machen das so“-Prinzip.

Vorteile von Open‑Source‑Hardware

Open‑Source‑Hardware bringt mehrere, gut belegte Pluspunkte mit, die gerade in frühen Projektphasen entscheidend sein können.

Transparenz – OSH‑Designs sind keine Black‑Box; sie können vollständig eingesehen, nachvollzogen und geprüft werden.
Flexibilität – Der Quell‑ und Schaltplan lässt sich jederzeit an neue Anforderungen oder an individuelle Bedürfnisse anpassen.
Kollektive Ressourcen – Idealerweise tragen zahlreiche Entwickler aus einer Community ihr Fachwissen und zusätzliche Entwicklungszeit bei, wodurch das Projekt schneller vorankommt.
Niedrige Lizenzkosten – Kostenfreie OSH‑Lizenzen bedeuten, dass nur die eigentlichen Herstellungs‑ und Betriebskosten für die Endnutzer anfallen.

Mögliche Nachteile (insbesondere für die spätere Nutzung)

Auch wenn Open‑Source‑Hardware viele Stärken hat, gibt es kritische Aspekte, die insbesondere die Markt‑ und Nutzerakzeptanz betreffen.

Zertifizierung & Regulatorik – Bei rein kostenlosen OSH ist es selten, dass jemand die hohen Aufwendungen für Zulassungen (z. B. medizinische Geräte) übernimmt. Das kann die praktische Einsatzfähigkeit stark einschränken oder sogar unmöglich machen.
Produktionskosten – OSH‑Projekte werden häufig für Einzel- oder Kleinserien (3‑D‑Druck, CNC) konzipiert, was pro Stück höhere Kosten verursacht als eine industrielle Massenfertigung.
Usability – Open‑Source‑Projekte verfügen oft nicht über dedizierte Ressourcen für benutzerfreundliche Bedienungsanleitungen, UI/UX‑Design oder Support‑Materialien, sodass die Anwenderfreundlichkeit darunter leiden kann.

Entscheidungs‑Kriterien – Fokus auf das langfristige Projektziel

Um die passende Verwertungsstrategie zu finden, sollten Sie die langfristigen Projektziele, die angestrebten Nutzergruppen und den Finanzierungsbedarf systematisch prüfen.

Projektziel – Soll die Hardware möglichst breit genutzt werden (z. B. in Bildung, Forschung) oder steht die kommerzielle Erlösmaximierung im Vordergrund?
Zielgruppen – Welche Nutzer*innen oder Nutzergruppen werden die Hardware künftig einsetzen und zu welchem Zweck?
Finanzierungsbedarf – Muss das Projekt bereits jetzt oder zu einem späteren Zeitpunkt Einnahmen generieren, um weiter zu existieren? Wenn ja, wie hoch sind die benötigten Mittel und wofür genau?

Ausschlusskriterium: Exportkontrollen

Hardware, die militärisch einsetzbar oder anderweitig sanktionierten Bereichen zugeordnet ist, unterliegt häufig Export‑Kontrollen (z. B. EU‑Dual‑Use‑Verordnung VO 2021/821, Außenwirtschaftsgesetz). In solchen Fällen gilt die Veröffentlichung im Internet – etwa auf GitHub – bereits als Export und ist ohne spezielle Genehmigung rechtlich riskant oder sogar unzulässig. Deshalb sollte diese Prüfung vor jeder öffentlichen Freigabe erfolgen, idealerweise bereits im Rahmen der grundlegenden Entscheidung für oder gegen Open Source.

Das Entscheidungs‑Tool

Wie sich die Zielüberlegungen auf die Entscheidung Open Source oder Proprietär auswirken, hat OpenTransfer in einem ausführlichen Tool „Entscheidungshilfe Open vs. Proprietär“ aufbereitet. In vier Themenbereiche geordnet werden eine Reihe von Fragen gestellt und mögliche Antworten eingeordnet, ob sie mehr für oder gegen eine Open-Source-Veröffentlichung sprechen.

Im ersten Bereich Personen / Team werden Motivation und Engagement‑Potential der Projektbeteiligten erfasst, etwa die Bereitschaft zu freiwilligem Aufwand, individuelles Erlösinteresse sowie das Vorhandensein oder der Aufbau einer Community.

Der zweite Bereich Organisation klärt die strategische Präferenz der Einrichtung – ob sie eher auf offene oder proprietäre Verwertungsmodelle ausgerichtet ist – und ob bereits Vor‑Lizenzen bzw. Lizenz‑Restriktionen die Wahl einschränken.

Der dritte Bereich Produkt beinhaltet Fragen zur technischen Reife, zu Sicherheits‑ und Zuverlässigkeitsanforderungen sowie zur Bedeutung einer Open‑Source‑Reputation für die Marktdurchdringung.

Im vierten Bereich Finanzierung wird der Finanzierungsbedarf, das erwartete Marktvolumen, die Realisierbarkeit von Open‑Geschäftsmodellen (Service, Support, Dual Licensing) und die generelle Erfolgswahrscheinlichkeit einer wirtschaftlichen Verwertung beleuchtet.

Die Antworten können auch in einem elektronischen Fragebogen aggregiert und zu einem Polaritätsprofil zusammengefasst werden. Dieses bildet visuell die Tendenz zu einer offenen, gemischten oder proprietären Verwertungsstrategie ab. Darin können auch unterschiedliche Präferenzen einzelner Teammitglieder wie auch die, ggf. konträren, Auswirkungen einzelner Themenkomplexe dargestellt und dann diskutiert werden.

Das Ergebnis ist bewusst kein abschließendes Urteil, sondern ein Entscheidungsimpuls, der die nächsten Analyse‑ und Planungsschritte – etwa einen detaillierten Lizenz‑Check, eine Marktstudie oder die Ausarbeitung eines Business‑Cases – gezielt steuert. Das Tool lässt sich einfach in bestehende Projekt‑Governance‑Prozesse einbinden und unterstützt Teams dabei, bereits in der Anfangsphase die passende Verwertungsstrategie zu identifizieren.

Laden Sie sich das excel-Tool runter: EXCEL-TOOL

Exportkontrolle und Ausfuhrregularien

Von den meisten Staaten – auch von Deutschland – wird der Export von Produkten, die militärisch, sicherheitstechnisch oder kerntechnisch eingesetzt werden können, streng reguliert. Das gilt ebenso für Open‑Source‑Software (OSS) und Open‑Source‑Hardware (OSH). Sobald ein Entwurf im Internet (z. B. auf GitHub) veröffentlicht wird, gilt das als Export, weil theoretisch jede Person weltweit darauf zugreifen kann.

Unterliegt die Technologie bzw. Hardware Ihres Projekts der Exportkontrolle oder Sanktionen, ist eine Open‑Source‑Veröffentlichung rechtlich verboten, bis Sie eine behördliche Genehmigung erhalten haben.

Die maßgeblichen Rechtsgrundlagen sind

EU‑Dual‑Use‑Verordnung (VO 2021/821) – regelt die Ausfuhr von Gütern, die sowohl zivil‑ als auch militärisch nutzbar sind.
Außenwirtschaftsgesetz (AWG) – nationale Ergänzung zur EU‑Verordnung.
EU‑Sanktionen – Verbote für bestimmte Länder, Organisationen oder Personen.

In Deutschland wird die Durchsetzung durch das Bundesamt für Wirtschaft und Ausfuhrkontrolle (BAFA) vorgenommen. Meist betreffen die Regelungen Exporte außerhalb der EU, aber das Internet lässt keine geografische Beschränkung zu, sodass jede Onlineveröffentlichung unter die Exportkontrolle fällt. Die meisten Forschungseinrichtungen haben interne Spezialisten, die bei der Prüfung der Frage helfen, ob und in welcher Form die Ausfuhr (und damit die Veröffentlichung) eingeschränkt ist.

Für ein Open Source Vorhaben sind grundsätzlich folgende Dinge zu prüfen:

Sanktionen prüfen

Gibt es EU‑Sanktionen, die das Ziel‑Land, die Zielorganisation oder die Zielperson betreffen?
Sind bestimmte Technologiebereiche (z. B. Kryptografie, Raketentechnik) von den Sanktionen erfasst?

Dual‑Use‑Liste prüfen

Finden Sie Ihre Hardware‑ oder Software‑Komponente im Anhang I der EU‑Dual‑Use‑Verordnung (VO 2021/821)?
Wenn ja, benötigen Sie eine Genehmigung, solange das Produkt nicht bereits Public Domain ist.

Public‑Domain‑Ausnahme

Ist die betreffende Technologie bereits öffentlich zugänglich (z. B. in einer früheren Veröffentlichung, in einer Bibliothek oder in einem öffentlichen Standard)?
Ist das der Fall, ist für die erneute Veröffentlichung keine zusätzliche Genehmigung mehr erforderlich.

Endverwendungscheck (Catch‑all‑Prüfung)

Können Sie einen sensiblen Verwendungszweck erkennen oder plausibel annehmen? Dazu zählen:
- Militärische oder rüstungsbezogene Nutzung in einem Embargoland
- Einsatz in Massenvernichtungswaffen oder deren Trägersystemen
- Verwendung zur internen Repression oder bei schweren Menschenrechtsverletzungen
Wenn einer dieser Punkte zutrifft, muss das BAFA einbezogen werden.

Dokumentation

Es empfiehlt sich, die obigen Schritte zu dokumentieren für eine etwaige spätere Prüfung.