Open-Source – aber richtig

Immer mehr FPGA-Designer setzen Soft- Mikroprozessoren ein. Doch welches Lizenzmodell ist das richtige? Dieses hat weit reichende Auswirkungen auf die Arbeit des Anwenders. Dieser Beitrag stellt vier der am weitesten verbreiteten Modelle mit ihren Vorund Nachteilen vor und geht dann genauer auf den Open-Source-Ansatz ein. Denn auch da gilt es genau hinzuschauen: Open-Source ist nicht gleich Open-Source.

Immer mehr FPGA-Designer setzen Soft- Mikroprozessoren ein. Doch welches Lizenzmodell ist das richtige? Dieses hat weit reichende Auswirkungen auf die Arbeit des Anwenders. Dieser Beitrag stellt vier der am weitesten verbreiteten Modelle mit ihren Vorund Nachteilen vor und geht dann genauer auf den Open-Source-Ansatz ein. Denn auch da gilt es genau hinzuschauen: Open-Source ist nicht gleich Open-Source.

Die Open-Source-Bewegung begann im Softwarebereich, wo viele Ansätze zur Open-Source-Lizenzierung unternommen wurden. Eine der gängigeren Lizenzen ist die »GNU General Public License« (GPL). Diese gewährt den Anwendern folgende wichtige Rechte, wenn sie im Gegenzug folgende Verantwortlichkeiten oder Anforderungen akzeptieren (Die exakte Lizenzvereinbarung und der entsprechende Text sind im Internet unter www.gnu.org veröffentlicht):

  • das Recht, die Software zu verwenden und zu modifizieren,
  • das Recht, die Software sowie Derivate davon in Eigenregie zu verteilen,
  • die Anforderung, sämtliche Software-Distributionen unter der GPL vorzunehmen und die Lizenz an alle weiterzugeben, die diese Distribution erhalten,
  • die Anforderung, die GPL auf Arbeiten anzuwenden, welche auf Material beruhen, welches im Rahmen der GPL erhalten wurde,
  • die Anforderung, den Quellcode von Arbeiten verfügbar zu machen, welche auf Material beruhen, das im Rahmen der GPL erhalten wurde,
  • eine Begrenzung der Haftung sowie
  • die Anforderung, ursprüngliche Copyright- Vermerke beizubehalten und Modifikationen klar zu kennzeichnen.

Diese Lizenz schützt einerseits die Rechte des Entwicklers an der entsprechenden Software, indem er für seine Arbeit auch die entsprechende Anerkennung erhält, und sorgt andererseits dafür, dass das neue Werk auch Public-Domain wird. Gleichzeitig müssen zukünftige Nutzer gewisse Anforderungen erfüllen. Exakt diese Balance ist einer der Faktoren, die zu dessen Popularität in der Community der Softwareentwickler beitrugen und beitragen.

Allerdings ist GPL in vielen Anwendungsfällen ungeeignet für Intellectual-Property, die letztendlich in Hardware implementiert wird. Die erste Herausforderung besteht darin, eine Kopie der Lizenz mitzuliefern und den Quellcode verfügbar zu machen. Dieser Punkt ist vernünftig und wichtig, wenn Programme in Form von »weicher « Software weitergegeben werden, also wenn beispielsweise modifizierter Code auf einer Website veröffentlicht oder an einen Kunden ausgeliefert wird. Wenn es jedoch zu einer physischen Implementierung des Designs beispielsweise innerhalb eines FPGAs kommt, dann ist dieser Aspekt problematischer. Man stelle sich vor, eine Kopie der GPL mit jeder Version des Systems auszuliefern. Die »Open IP Core License« von Lattice Semiconductor geht exakt diesen Punkt explizit an:

»Der Anbieter bietet Ihnen ein persönliches, nicht-exklusives Recht, den Objektcode zu nutzen, der aus der Software oder einem Derivat erzeugt wurde, um das Design physikalisch in Bausteinen wie beispielsweise PLDs (Programmable Logic Devices) oder ASICs zu implementieren. Sie dürfen diese Bauteile weiterverteilen ohne dabei eine Kopie dieser Lizenz oder des Quellcodes beizufügen.«

Die zweite Herausforderung ist die Anforderung, das gesamte Derivat zu lizenzieren, welches den Code auf GPLBasis unter GPL enthält. Oft wollen Entwickler die GPL zusammen mit proprietärem Material nutzen (Bild 2). Bei Software ist es normalerweise nicht zu schwierig, Code auf GPL-Basis und proprietären Code auf zwei separat kompilierte beziehungsweise dokumentierte Programme aufzuteilen. Bei der Hardware, wo ein einzelnes Place-and-Route zu einem einzigen Design führt, ist das nicht machbar. Das »Open IP License Agreement « geht auch diesen Aspekt direkt an:

»Der Anbieter gewährt Ihnen ein persönliches, nichtexklusives Recht, den Quellcode der Software zu modifizieren und diese zusammen mit anderem Quellcode zu integrieren, um so ein Derivat zu schaffen. Sie dürfen dieses Derivat nach Ihrem Ermessen in einer Form und unter den Bedingungen Ihrer Auswahl gemäß den folgenden Punkten weiterverteilen:

  • Sie ordnen Ihr Design so an, dass das Derivat ein identifizierbares Modul innerhalb Ihres Gesamtdesigns ist.
  • Sie verteilen den zu den Modulen gehörigen Quellcode, welcher das Derivat enthält, in einem üblicherweise akzeptierten maschinenlesbaren Format – und zwar kostenlos und unter diesen Lizenzbedingungen.« (rh)