Urheberrecht, Verträge, Lizenzen und so weiter: In der Serie "Rechts-Rat" erhalten Linux-Magazin-Leser verständliche Auskünfte zu Rechtsproblemen des Linux-Alltags.

In dieser Ausgabe geht\’s um Haftung für Internet-Zugangsvermittlung, den Verkauf von vorinstallierten Linux-PCs mit Projekt-Logos und um die Nutzungsbedingungen von Business-Distributionen.

Abbildung 1: Beim Handel mit vorinstallierten Linux-PCs im Ebay-Shop sind die Vorgaben für die verwendeten Logos zu beachten, auch jene für die Veröffentlichung der Quellen. (Bild: © Slawomir Jastrzebski, Fotolia.com)

Linux-PCs im Shop bei Ebay

Nehmen wir an, ich eröffne einen Laden für Computer bei Ebay (Abbildung 1). Die PCs haben ein vorinstalliertes Debian Linux oder sind Gateways mit IP-Cop. Ich biete für einen begrenzten Zeitraum Support für die Systeme an. Dürfen Tux und das Debian- oder das IP-Cop-Logo in den Angeboten erscheinen oder nur mit Genehmigung? Kann ich davon ausgehen, dass der Verkauf möglich ist? Die GPL würde beiliegen und auch etwas darüber, was freie Software bedeutet.

Martin S.

Ob Sie freie Software als Download, auf Datenträgern oder vorinstalliert auf PCs anbieten, ist ohne Belang: Die Lizenz erlaubt bei GPL-Software natürlich auch die Verbreitung zu gewerblichen Zwecken und schließt Gewinnerzielungsabsicht nicht aus. Im Gegenteil: Die Dienstleistung der Vorinstallation gehört zu den durch die Lizenz geförderten Erwerbsmöglichkeiten.

Die GPL selbst muss nicht den Geräten, sondern zusammen mit der Software nach den jeweiligen Lizenzbedingungen beigegeben werden. Das umschließt jedes GPL-Programm und erschöpft sich nicht in einem Zettel oder einer Textdatei, die im Paket enthalten ist. Beachten Sie auch, dass Sie bei freier Software nicht nur die auf dem Rechner installierten Binärprogramme weitergeben, sondern – je nach Lizenzbedingung – zusätzlich auch noch die Quellen herausgeben oder zumindest verfügbar machen müssen.

Was die Nutzung der Logos angeht: Larry Ewings Tux ist frei nutzbar, wenn Sie die Bedingungen einhalten, die er auf seiner Homepage vorgibt [1]. Dazu gehört der Verweis auf Larry Ewing als Urheber und das Bildbearbeitungsprogramm Gimp – wenn Sie danach gefragt werden. Ein entsprechender Link sollte aber auch so selbstverständlich sein. Das Debian-Logo dürfen Sie nach den Bedingungen auf der Debian-Webseite [2] (fast) frei nutzen, das IP-Cop-Projekt [3] zeigt keine ersichtliche Freigabe des Logos – hier brauchen Sie die Erlaubnis des Urhebers.

Router aufbohren und verkaufen

In unserer Firma wollen wir einen bestimmten Markenrouter vertreiben. Dabei soll ein OpenWRT-Linux die originale Firmware ersetzen, und wir wollen den Router um bestimmte Aufgaben erweitern. Es kommen verschiedene Softwaretools und -bibliotheken zum Einsatz, etwa PHP, Gdlib oder SQLite. Diese finden ohne Quellcodeänderung Verwendung. Der Quellcode unserer Software ist in PHP und mit Shellskripten komplett selbst erstellt.  Eine Anfrage beim Routerhersteller ergab, dass eine Änderung der Firmware erlaubt ist, jedoch unter Verlust der Gewährleistung. Nun stellen sich mehrere rechtliche Fragen. Dürfen wir die Partitionen mit unserem erstellten Quellcode verschlüsseln? Müssen wir die Sourcen veröffentlichen und wenn ja, welche (Linux-Kernel, Bibliotheken, Tools, eigener PHP/Shell- Quellcode)? Dürfen wir Entwicklungskosten in den Verkaufspreis einrechnen? Ist eine Closed- Source-Variante für unsere eigenen Quellen möglich? Müssen wir die Lizenzvereinbarungen aller eingesetzen Tools beachten?

Steffen S.

Sie dürfen Ihren Router (Abbildung 2) vertreiben, müssen dabei jedoch die Lizenzbedingungen der eingesetzten Software in vollem Umfang beachten. Bei freier Software gehört es üblicherweise dazu, die Quellen mitzuliefern oder sie zumindest frei verfügbar zu machen. Bei selbst erstelltem Code ist es freigestellt, diesen zu verschlüsseln, in sonstiger Form auf dem Gerät zu installieren oder für den Betrieb zu laden. Auch die Quellen müssen nicht verfügbar sein.

Abbildung 2: Router im Angebot: Die veränderte Firmware lässt die Gewährleistung des Routers erlöschen. Bei selbst erstellter Software ist zudem auf Sortenreinheit zu achten. (Bild: © Olaf Schwenty, Fotolia.com)

Dies allerdings nur, wenn es sich um reine Eigenentwicklung handelt, die nicht auf anderer Software aufsetzt. Das bedeutet, dass veränderte oder angepasste GPL-Programme nicht verborgen sein dürfen, sondern wieder unter der GPL oder den entsprechenden Lizenzbedingungen weiterzugeben sind – auch vorinstallierte auf einem intelligenten Router.

Das gilt für GPL-Software, nicht aber für Programme unter etwa einer BSD-Lizenz, auf die Sie auch eigene Entwicklungen aufsetzen und proprietär vertreiben dürfen. Als Gegenpart zur GPL kommt die LGPL bei vielen Bibliotheken zum Einsatz, die die Kombination mit proprietärer Software gestattet.

In Ihrem Fall sind die Programme gleichzeitig auch die Quellen: Echte Skriptsprachen werden ja nur vom Interpreter abgearbeitet und liegen nicht in binärer Installationsform vor. Außerdem binden Skripte keine externen Bibliotheken ein, sondern rufen nur weitere Programme auf. Sind die Skripte vollständig selbst erstellt, brauchen Sie sie auch nicht zu offenbaren.

Beachten Sie aber, dass schon die Benutzung kleiner Vorlagen aus dem Web genügt, um fremdes Urheberrecht zu beeinträchtigen. Kopieren Sie etwa ein Skript von einer Internetseite oder ein Installations- oder Konfigurationsskript aus einem GPL-Paket und passen deren Code an eigene Erfordernisse an, haben Sie ein urheberrechtlich geschütztes Sprachwerk bearbeitet. Damit dürfen Sie auch den neuen Code nicht ohne Erlaubnis des ursprünglichen Programmierers veröffentlichen oder verbreiten.

Vorratsdatenspeicherung bei Seminaren

Vorratsdatenspeicherung bei SeminarenDanke für die interessante Klarstellung in dem Artikel “Vorratsdaten vom Hotspot im Hotel” (Linux-Magazin 02/2009, Seite 78). Da wir als Seminaranbieter Teilnehmern für die Dauer des Seminars kostenlosen Zugang zum Internet gewähren, fallen wir in dieselbe Kategorie wie das dargestellte Hotel.Zwei Fragen kommen noch dazu: Wenn ein Teilnehmer seinen Rechner bei uns im WLAN betreibt und wir im Gegensatz zum besprochenen Hotel keine Einzelauthentifizierung über ein Captive-Portal betreiben, müssen wir dann die Nachvollziehbarkeit über die MAC-Adresse und den Namen des Teilnehmers, eventuell sogar über seine Unterschrift dokumentieren? Und wie verhält es sich mit den für alle Teilnehmer anonym zugänglichen Kiosk-Notebooks in den Pausenräumen? Ist dort auch eine Identifizierung und Authentifizierung nötig?

Marcus J.

Um zivilrechtlicher Haftung oder strafrechtlicher Verfolgung sicher zu begegnen, müssen Sie im Zweifel belegen, wer bei Ihnen wann unter einem bestimmten Zugang die Internetverbindung genutzt hat. Eine Unterschrift ist dafür nicht nötig, sie schadet aber auch nicht. Wichtig ist der Beleg der konkreten Identität, am besten durch die Daten aus einem Ausweisdokument: Name und Anschrift sollten genügen.

Natürlich handelt es sich dabei tatsächlich um personenbezogene Daten, für deren Speicherung und Verarbeitung das Datenschutzgesetz maßgeblich ist. Unter anderem müssen Sie also den Kunden entsprechend von der Speicherung in Kenntnis setzen und dürfen die Daten nur für die gesetzlich zulässigen Zwecke nutzen und nicht weitergeben.

Das gleiche Prinzip gilt auch für anonym zugängliche Kiosk-Notebooks: Wenn über diese ein Internetzugang auch nur mittels Webbrowser möglich ist, so ist dadurch doch der gesamte Spielraum der Internetnutzung eröffnet. Sie können selbst dann, wenn das Kiosk-System keinen Zugriff auf Drucker oder Schnittstellen erlaubt, nicht ausschließen, dass der Benutzer interaktiv möglicherweise rechtswidrige Handlungen begeht – vom Einstellen ehrverletzender Kommentare in Blogs bis zum Vervielfältigen urheberrechtlich geschützten oder pornographischen Inhalts.

Die Bekämpfung rechtsfreier Räume im Internet setzt voraus, dass kein anonymer Zugang möglich ist. Daher muss jeder, der anderen solch anonymen Zugang über den eigenen gewährt, damit rechnen, haftbar oder sogar strafrechtlich verantwortlich gemacht zu werden. Die Zugangsgewährung an sich ist dabei (noch) erlaubt, befreit aber nicht von der Verantwortlichkeit, wenn diese anderen, insbesondere Kunden, mittels dieses Zugangs Rechtsübertretungen begehen.

Rüstzeug für Subskriptionsversteher

Rüstzeug für SubskriptionsversteherIch bin beim Überarbeiten unserer Red-Hat-Subskriptionen: Welche Rechte erstehe ich für diese Subskriptionen genau? Updates und Support klingt ja einfach und einleuchtend. Aber was ist, wenn ich keine Subskription mehr kaufe? Muss ich dann die Software deinstallieren? Eigentlich nicht, ist ja alles GPL. Und was passiert, wenn ich die Updates nur bei einem Server herunterlade und dann verteile? Geht das? Auf Anfragen hat Red Hat gemeint, dass dies nicht zulässig sei, außer mit dem Satellite Server. Was passiert, wenn ich die CD/DVD herunterlade, kann ich die dann mehrfach verwenden, wenn ich keine Updates und Support will? Ich habe dann im Internet gesucht und in den Verträgen [4] und [5], aber ich werde nicht schlau daraus.Gemäß Red Hat muss pro Server eine Subskription vorhanden sein, ansonsten darf man Red Hat nicht nutzen. Da wir auch im Dataquality- Bereich (D/Q) GFS einsetzen (und noch RHEL 4 nutzen müssen), sind wir gezwungen für GFS auch dort Subskriptionen zu kaufen, auch wenn wir keinen Support benötigen. Unsere Idee war, wir kaufen keine Subskription mehr für D/Q. Gemäß Red Hat ist das aber nicht zulässig.

Michael H.

Software- und Support-Abonnements sind – zumindest zwischen Unternehmern – inhaltlich frei aushandelbar. Zunächst kommt es für die konkrete Bestimmung der jeweiligen Lizenz- beziehungsweise Nutzungsbedingungen darauf an, welches Programm- oder Support-Paket Sie erworben haben (Abbildung 3). Die angegebenen Bezugsbedingungen sind Rahmenbedingungen, die sich durch produktspezifische Vertragsbedingungen ergänzen, konkretisieren oder einschränken lassen.

Abbildung 3: Wer seine Lizenzverträge in allen Einzelheiten verstehen will, kommt um eine gründliche Durchsicht der Akten nicht herum. Bild: © Ahermes, photocase.com)

Im Wesentlichen erwerben Sie zusätzliche Produkte, die als Teil der Business-Distributionen nicht als freie Software qualifiziert sind und damit nichts anderes als gewöhnliche proprietäre Programme. Deren Lizenz- beziehungsweise Nutzungsbedingungen sind ebenso bindend wie die von Programmen, die nichts mit Linux oder anderer freier Software gemein haben. Das betrifft die Basisinstallationen und sämtliche Updates.

Business-Pakete setzen sich aus einer kaum überschaubaren Anzahl von Programmen zusammen, die zum größten Teil frei sein mögen, aber auch proprietäre Pakete enthalten. Dazu zählen typischerweise Management-Tools und Dienstprogramme. Das müssen keine kompilierten Programme sein, auch Skripte oder Konfigurationsdateien können darunter fallen. Die Annahme, die gesamte Software sei frei, trifft daher nicht zu.

Zwar ist die weitere uneingeschränkte Nutzung des freien Anteils der bezogenen Software auch dann noch möglich, wenn ein bestehendes Bezugs- oder Supportverhältnis aufgelöst wird – durch Zeitablauf oder Kündigung -, das gilt aber nicht für die Supportleistungen und den proprietären Teil des Pakets.

Vertragliche Verpflichtungen, nach denen Sie ausschließlich die Software eines Providers einsetzen dürften oder für jeden Rechner, den Sie künftig für Ihr Unternehmen erwerben, eine weitere Lizenz beziehen müssten, unabhängig davon, ob er tatsächlich mit den Systemen verbunden ist, hätten knebelnden Charakter und wären unwirksam. Das betrifft aber nicht die Verpflichtungen, nach denen sich die Lizenzen auch auf Systeme erstrecken müssen, die entweder eigenständig oder mittels proprietärer Clientprogramme auf Serverdienste zugreifen, die – selbst proprietär – zur Business-Distribution gehören. Das gilt auch für die älteren Versionen. Natürlich kann der Distributor auch seinen Support auf die Systeme einschränken, für die der Kunde die entsprechenden Lizenzen erworben hat.

Es ist also möglich, ein unternehmensinternes Subnetz aufzubauen, dessen einzelne Server und Clients für den Zugriff auf die proprietären Bestandteile des Business-Pakets berechtigt sind und auch Support genießen. Systeme aus anderen Bereichen dürfen in diesem Fall eben nicht auf die proprietären Serverdienste zugreifen.

Die Schwierigkeit besteht darin, unfreie Bestandteile von freien zu trennen, um dann noch die unfreien Bestandteile isoliert zu deinstallieren. Ob der Distributor verpflichtet ist eine derartige Programmliste zur Verfügung zu stellen, ist strittig und nach meiner Ansicht wohl eher nicht anzunehmen. Außerdem kann ein derartig entkerntes System leicht unbenutzbar werden und ohne tiefgehende Kenntnis der nötigen Ersatzkonfigurationen auch dauerhaft bleiben. (uba)