Auf der Suche nach dem Neuen im Alten
Artikel drucken

Copyleft für Hardware – ein kniffliges Problem

[This article is also available in English.]

Das Copyleft hat beim Erfolg Freier Software eine wichtige Rolle gespielt. Copyleft stellt sicher, dass alle Versionen einer Software bzw. eines Dokuments frei bleiben. Es hindert Firmen daran, »verbesserte« Versionen eines Freien Programms zu privatisieren und als proprietäre Software zu verkaufen. Die erste und bekannteste Copyleft-Lizenz ist die GNU General Public License (GPL). Die GPL ist beliebter als alle anderen Lizenzen für Freie Software zusammen – sie wird für etwa 50–70% aller Freien Programme genutzt.

Auf den ersten Blick mag die Situation in den neu entstehenden Bereich Freie Hardware ähnlich aussehen. Auch hier sind Copyleft-Lizenzen wie die GPL und die Creative Commons BY-SA-Lizenz (Namensnennung + Weitergabe unter gleichen Bedingungen) sehr beliebt (siehe unten für eine detailliertere Analyse). Aber tatsächlich ist es um Freie Hardware ganz anders bestellt, denn das Copyleft stützt sich auf das Copyright bzw. Urheberrecht, und Hardware ist (in den meisten Fällen) nicht urheberrechtlich geschützt.

Sind Patente die Lösung?

Ich kenne nur eine speziell für Freie Hardware gedachte Lizenz, die dieses Problem zu lösen versucht. Der Ansatz der im Mai 2007 veröffentlichten TAPR Open Hardware License besteht darin, neben dem Urheberrecht auf das Patentrecht zu setzen, indem sich Lizenzgeber und Lizenznehmer gegenseitig Immunität vor Patentrechtsklagen zusichern. Der Lizenzgeber räumt allen, die sich an die Lizenz halten, das Recht zur Verwendung aller seiner relevanten Patente ein. Wer gegen die Lizenz verstößt (und z.B. nicht den »Quelltext« der auf Basis der Hardwarebeschreibung gebauten Produkte öffentlich macht), verliert dieses Recht und kann wegen Patentverletzung verklagt werden.

TAPR hat zwei Varianten der Lizenz veröffentlicht: die Open Hardware License (OHL), die dem regulären Copyleft entspricht (wie die GPL oder die CC BY-SA) und die TAPR Noncommercial Hardware License (NCL), die zudem jegliche kommerzielle Nutzung verbietet (wie die CC BY-NC-SA-Lizenz).

Sich anstelle des Urheberrechts auf das Patentrecht zu beziehen, ist ein sinnvoller Ansatz, da das Patentrecht für Hardware gemacht wurde, während das Urheberrecht für Informationen gedacht ist. Aber es ist auch ein Problem, dann der Erwerb eines Patents ist ein schwieriger und kostspieliger Prozess, während man Urheberrechte automatisch und kostenfrei erhält.

Die TAPR-Lizenzen sind nur dann wirklich effektiv, wenn der Lizenzgeber tatsächlich relevante Patente besitzt, oder wenn man zumindest nicht ganz sicher sein kann, dass er/sie keine solchen Patente besitzt. Dies ist eine schwerwiegende Einschränkung, da der Patenterwerb eine aufwendige Angelegenheit ist. Die meisten Peer-Projekte werden kein Patent beantragen können oder wollen, weshalb die TAPR-Lizenzen für sie kaum geeignet sind.

Ein weiteres Problem der TAPR-Lizenzen besteht darin, dass man gemäß Lizenztext neben den eigenen modifizierten Designs immer auch die unveränderten Originalversionen aller Dokumente weitergeben muss – wenn man eine Datei verändert, darf man sie nicht einfach ersetzen, sondern muss die Vorversion ebenfalls beilegen (§ 4.2 (b)). Für große Versionsgeschichten (mit hunderten oder tausenden von Versionen) dürfte dies extrem unpraktisch sein, und die lizenzkonforme Erstellung gedruckter Hardwaredokumentation wird in solchen Fällen fast unmöglich gemacht. Außerdem ist der Zweck dieser Anforderung unklar.

Pragmatische Lösungen: Standard-Copyleft verwenden oder ganz aufs Copyleft verzichten

Die meisten Freie-Hardware-Projekte scheinen die besonderen Probleme der Hardwarelizenzierung wenig zu kümmern. Sofern sie Copyleft wollen, verwenden die meisten Projekte gewöhnliche Copyleft-Lizenzen wie die GNU GPL oder die Creative Commons BY-SA-Lizenz, wobei sie anscheinend entweder nicht wissen oder sich nicht darum kümmern, dass die Copyleft-Klauseln beim Bau von Hardware nicht greifen (siehe Projektverzeichnis unten).

Eine andere Lösung besteht darin, auf das Copyleft zu verzichten und stattdessen eine liberale Lizenz wie die (modifizierte) BSD-Lizenz zu verwenden. Dies erlaubt es allen, die veröffentlichten Informationen auf beliebige Weise zu verwenden, ohne Abwandlungen oder Verbesserungen offenlegen zu müssen.

Es gibt sogar eine Hardware-spezifische copyleftfreie Lizenz, die Balloon-Lizenz. Diese einfache Lizenz ähnelt der MIT-Lizenz. Da sie Herstellern der Hardware keinerlei Anforderungen stellt, vermeidet sie die Probleme, die sich andernfalls ergeben würden. Allerdings gibt es keinen plausiblen Grund, diese spezielle Lizenz anstelle der gewöhnlich verwendeten liberalen Lizenzen (BSD-Lizenz oder MIT-Lizenz) zu verwenden, da sie keine Probleme löst, die von diesen Lizenzen nicht schon gelöst worden sind.

Was tun?

Wie man dem Projektverzeichnis (unten) entnehmen kann, verwendet der Großteil der Freien-Hardware-Projekte gewöhnliche Copyleft-Lizenzen (die GPL oder die CC BY-SA). Per Copyleft geschützt sind also nur die Baupläne selbst, beim Bau von Hardware greifen die Copyleft-Klauseln dieser Lizenzen nicht. Bedeutet das, dass die Projekte mit diesem begrenzten Copyleft-Effekt zufrieden sind, oder sind sie sich des Problems schlicht nicht bewusst? Ich weiß es nicht…

Jedenfalls scheint es keine wirklich überzeugenden Lösungen zu geben. Es gibt nur eine Lizenz, die die Ausweitung des Copyleft-Konzepts auf die Hardware selbst versucht, nämlich die TAPR-Lizenz. Doch diese Lizenz wird (außerhalb des TAPR-Projekts) praktisch nicht benutzt. Und tatsächlich bedeutet der Rückgriff auf das Patentrecht, dass die Lizenz höchstens von sehr großen Projekten praktisch genutzt werden kann.

Die Verwendung liberaler Lizenzen (wie es das Apache-Projekt und die BSDFamilie tun) scheint für die Mehrheit Freier-Hardware-Projekte aber auch keine attraktive Option zu sein – die meisten ziehen den wenigstens ansatzweise bestehenden Copyleft-Schutz vor, den die GPL und die CC BY-SA ihnen bieten können.

Allerdings ist dieser Copyleft-Schutz im Falle Freier Hardware eben sehr unvollständig, wie oben beschreiben wurde – Hardware-Produzenten müssen ihre Verbesserungen nicht freigeben. Beim RONJA-Projekt hat das Auseinanderklaffen zwischen den Erwartungen der Projekt-Maintainer (die die Verbesserungen anderer nutzen wollten) und dem tatsächlichen Verhalten von Hardware-Produzenten (die ihre Verbesserungen für sich behalten haben) schon zu Spannungen geführt, die zum Niedergang des Projekts beitragen haben. Ob ähnliche Probleme auch in anderen Freie-Hardware-Projekten auftreten und die Freie-Hardware-Community schwächen werden, ist bislang offen…

* * *

Anhang: Projektverzeichnis

Die folgenden Projekte verwenden normale Copyleft-Lizenzen:

Projekte die eine normale Share-Alike-Lizenz verwenden, die die kommerzielle Nutzung untersagt (CC Namensnennung-Keine kommerzielle Nutzung-Weitergabe unter gleichen Bedingungen):

Projekte die verschiedene Creative-Commons-Lizenzen unterstützen:

  • Open Architecture Network: eine Sammlung architektonischer Entwürfe und Pläne; die Beteiligten können beliebige CC-Lizenzen wählen oder ihre Pläne in die Public Domain geben (siehe OAN Licensing)
  • Thingiverse: eine Sammlung digitaler Designs für materielle Objekte; die Benutzer/innen können sich zwischen regulärem Urheberrecht oder CC-Lizenzierung entscheiden, auch die GPL und Public Domain stehen zur Auswahl (siehe Thingiverse Terms of Services)
  • Ponoko: Verzeichnis und Marktplatz für digitale Baupläne; zur Auswahl stehen vollständiges Urheberrecht und Creative-Commons-Lizenzen (siehe Liste CC-lizenzierter Designs)

Projekte die die TAPR Open Hardware License verwenden, eine speziell für Hardware entwickelte Share-Alike-Lizenz, die anstelle des Urheber- auf das Patentrecht setzt:

  • TAPR: die Gemeinschaft der Funkamateure, die diese Lizenz entwickelt hat

Projekte die die TAPR-Lizenz und parallel dazu normales Copyleft verwenden (Doppellizenzierung):

  • Open Graphics Project: Open-Source-Grafikkarten; die Hardwarebeschreibungen (Schaltpläne und Vorlagen) stehen unter drei alternativen Lizenzen: GPL, TAPR-Lizenz oder eine kommerzielle proprietäre Lizenz, siehe OGP FAQ und Ankündigung vom 7. April 2009. Durch die Doppel- bzw. Dreifachlizenzierung mit der TAPR-Lizenz als einer von mehreren Optionen wird allerdings die spezielle Schutzwirkung der TAPR-Lizenz zunichte gemacht (man kann ja stattdessen einfach die GPL verwenden), daher scheint dieses Lizenzmodell ziemlich sinnlos.

Projekte die eine hardwarespezifische Lizenz ohne Copyleft-Effekt verwenden (die Balloon-Lizenz):

  • Balloon Project: ein weiteres Computerboard (nur Teile des Designs sind frei, einige wesentliche Dokumente bleiben proprietär)

Projekte die eine Standard-Lizenz ohne Copyleft-Effekt verwenden (die BSD-Lizenz):

Projekte die sowohl Copyleft als auch Copyleft-freie Lizenzen verwenden:

  • OpenCores: entwickelt Bauteile für CPUs, Speichercontroller, Hauptplatine und andere Computerkomponenten; verwendet eine Kombination von GPL, LGPL (bevorzugt) und modifizierter BSD-Lizenz, gemäß den Präferenzen der Beitragenden (siehe OpenCores FAQ)

Ggf. fehlende wichtige Projekte bitte in einem Kommentar nachtragen – ich werde den Artikel dann ergänzen. Projekte, die klein oder in einem frühen Entwicklungsstadium sind, wurden nicht erfasst. Ausführliche Listen von Freie-Hardware-Projekten gibt es in dem Open source hardware-Artikel der englischsprachigen Wikipedia (die deutsche Version ist sehr viel kürzer), auf der »Product Hacking«-Seite der P2P Foundation, im Open-Innovation-Projekteverzeichnis sowie bei GOSH (List of Open Hardware Projects, List of Open Hardware Organizations).

Kategorien: Freie Hardware, Praxis-Reflexionen

Tags: , , , , , , , ,

30. Dezember 2009, 01:19 Uhr   14 Kommentare

1 The Tricky Business of “Copylefting” Hardware — keimform.de (30.12.2009, 01:20 Uhr)

[…] [Diesen Artikel gibt es auch auf Deutsch.] […]

2 Christian Siefkes (30.12.2009, 01:43 Uhr)

Interessant sind auch die Kommentare zur englischsprachigen Version (allerdings natürlich ebenfalls auf Englisch).

3 Benni (01.01.2010, 19:35 Uhr)

Frank Rieger hat u.a. in seiner #26c3-Keynote auf einen positiven Nebenaspekt dieses Problems hingewiesen: Bastler können Patente als Informationspool verwenden, so lange sie das entstehende nicht verkaufen. Also könnte man doch so vorgehen:

Man copylefted Bauanleitungen, die vorzugsweise Patente enthalten. Und zwar keine eigenen, sondern die von irgendwem. Jeder der die Bauanleitungen weiterverbreiten will, muss sich ans copyleft halten. Jeder der das Produkt herstellen will muss sich an gar nichts halten. Aber wer das Produkt verkaufen will braucht Lizenzen vom Patentaten oder kann das eben nicht. Klingt wie der Patentmafia in die Arme arbeiten? Nicht unbedingt finde ich. Oder übersehe ich was? Oder verbietet das Patentrecht auch Verbreitung von Anleitungen? Was nicht wirklich sein kann, schliesslich sind Patente selbst ja auch Anleitungen.

Der Vorteil eines solchen Vorgehens wäre, dass der Openhardware-Bewegung auf einen Schlag sämtliche patentierte Technologien zur Verfügung ständen! Da könnte das auskooperieren deutlich einfacher werden, weil es damit für kleine Unternehmen, die nicht im Patentkrieg mithalten können evntl. einfacher wird auf Open Hardware zu setzen.

4 Christian Siefkes (06.01.2010, 01:02 Uhr)

@Benni: Du meinst, weil das Patentrecht private Anwendungen erlaubt? Das ist leider selbst in deutschen Patentrecht eine recht dünne Angelegenheit, denn wenn ich ein solches Objekt dann z.B. am Arbeitsplatz verwende, ist das schon kein rein persönlicher Gebrauch mehr und ich mache mich strafbar.

In US- + englischem Recht gibt es diese Ausnahmeklausel für unkommerziellen privaten Gebrauch gar nicht, da würde man sich auf jeden Fall strafbar machen. In den USA gibt es nur eine dünne Research exemption, aber die greift nur, wenn man etwas lediglich für »amusement, to satisfy idle curiosity, or for strictly philosophical inquiry« macht – wenn das Objekt irgendwas nützliches tut, was man dann nachher auch privat nutzt, ist das schon nicht mehr »idle curiosity« und man verstößt gegen das Patent.

Also weltweit gesehen kommt man damit nicht weit…

5 Benni (06.01.2010, 08:11 Uhr)

@Christian: Ah, dass wusste ich noch nicht, dass die angelsachsen da so restriktiv sind. Ja, dann kann das wohl leider nicht funktionieren.

6 RTFM! » Aus der virtuellen Nachbarschaft N° 7 (17.01.2010, 09:16 Uhr)

[…] Siefkes schildert ausgehend von Copyleft für Software bzw. eines Dokuments, welche Probleme sich ergeben, wenn […]

7 Mirko Lindner (26.02.2010, 08:47 Uhr)

Hey,

wollte ein Projekt zur List hunizufügen. Den Ben NanoNote [1], alle schematics unter einer Creative Commons Attribution-ShareAlike Lizens.

/mirko

[1] http://nanonote.cc

8 OSHW — Open Source Hardware — keimform.de (16.07.2010, 10:03 Uhr)

[…] es mit offener Hardware nicht ganz so einfach ist wie mit Freier Software, hat Christian im Artikel »Copyleft für Hardware – ein kniffliges Problem« bereits beschrieben. Nachfolgend fasse ich die 11 Punkte der OSHW-Definition des englischen […]

9 martin (30.01.2011, 01:20 Uhr)

Hi beisammen, kurze Frage: Im deutschen Patentrecht gab es die Regelung, dass nichts patentlich geschützt werden kann, was schon Stand der Technik ist, und der Stand der Technik wurde als paiererner Stand der Technik definiert: Was vor der Patentanmeldung in z.B. einer Fachzeitschrift (wie und ob Fachmedien definiert wurden weiss icht nicht) veröffentlicht war, galt als Stand der Technik und konnte damit nicht mewhr geschützt werden – so zumindest habe ich die Ausführungen meins Profs (in Recht für Iongenieure) im Kopf.

Jetzt weiss ich nicht, inwieweit das heisige Patentrecht inzwischen anderen europäischen Ländern angepasst wurde, oder dem internationalen Patentrecht, und ob es diese Regel in der Form noch gibt. Weiss wer mehr? Gibt es Regelungen im Patentrecht, die verlangen dass das Ganze innovativ sein muss?

Das ist kein Weg, Erfindungen davor zu schützen dass sie vermarktet werden, wohl aber einer um sie offen zu halten.

10 Literatur zu „Selbstbestimmte Technikentwicklung“ « Philosophenstübchen-Blog (30.01.2011, 14:31 Uhr)

[…] Christian (2009): Copyleft für Hardware – ein kniffliges Problem. http://www.keimform.de/2009/copyleft-fuer-hardware/ (abgerufen […]

11 Christian Siefkes (30.01.2011, 17:20 Uhr)

@martin: Ich habe auch verschiedentlich gehört, dass eine bloße Internetveröffentlichung nach deutschem Recht nicht ausreicht, um ein Konzept unpatentierbar machen – anders als z.B. in den USA. Allerdings scheint das mehr eine Auslegung durch die Gerichte zu sein als der tatsächlichen offiziellen Gesetzeslage zu entsprechen, denn § 3 Abs. 1 des deutschen Patentgesetzes lautet:

(1) Eine Erfindung gilt als neu, wenn sie nicht zum Stand der Technik gehört. Der Stand der Technik umfaßt alle Kenntnisse, die vor dem für den Zeitrang der Anmeldung maßgeblichen Tag durch schriftliche oder mündliche Beschreibung, durch Benutzung oder in sonstiger Weise der Öffentlichkeit zugänglich gemacht worden sind. (Quelle: Wikipedia)

Demzufolge musste also eine Internetveröffentlichung ausreichen, aber in der Praxis wird das Internet von deutschen Patentgerichten offensichtlich nicht anerkannt – vermutlich weil das genaue Veröffentlichkeitsdatum von Online-Texten im Nachhinein schwer zu ermitteln ist. Siehe Internet as a source of prior art:

In 2002, „the Bundespatentgericht in case BPatG 17W (pat) 1/02 (see GRUR 2003 Heft 04, pp 323-325) confirmed in later BPatG 17W (pat) 47/00, ruled that the Internet was not a reliable source for determining the state of the art. This applied also to web archives such as the Internet Archive.“

In anderen Ländern scheint es dieses Problem nicht zu geben.

12 Michael Klotsche (30.01.2011, 22:04 Uhr)

Hallo zusammen,

ich habe unter folgendem Link auf meinem Wiki eine Liste von Punkten zusammengestellt, die nach meiner praktischen Erfahrung für eine Freie Technologien notwendig sein können. Die Liste soll den Artikel hier ergänzen.

http://wiki.biores.de/mw/index.php/Leitfaden_f%C3%BCr_freie_Technologien

Viele Grüße, Micha

13 Technik in einer selbstbestimmt-koordinierten Produktion IV « Philosophenstübchen-Blog (31.01.2011, 14:33 Uhr)

[…] (zum Problem der Lizensierung für Freie/Offene Hardwareprojekte siehe auch Christian Siefkes 2009 und ein Vorschlag von Thomas Kalka 2008). In den Büchern aus Umsonstläden gibt es oft wenigstens […]

14 Mier und die neue Bedeutung von »Liquid Democracy« — keimform.de (16.09.2012, 06:25 Uhr)

[…] Die Mier-Macher ermuntern dazu (siehe Video), das Rezept zu nutzen, es zu verändern und Bier zu brauen. Kein Problem, solange es nicht »kommerziell produziert« wird. Was aber heißt »kommerziell« in diesem Fall? Die CC-Lizenz bezieht sich genau genommen nur auf das Rezept, nicht auf das gebraute Bier. Damit sind wir in einer ähnlichen Problematik, die Christian schon einmal ausführlich am Beispiel von Computer-Hardware diskutierte. […]

Schreibe einen Kommentar