Einbindung von Social Media Buttons auf Websites

Wir erklären die rechtlichen Probleme, die im Zusammenhang mit Social Media Plugins auftreten können.

Einbindung von Social Media Buttons auf Websites

Einführung

Wer im Internet etwas findet, was ihm gefällt, möchte das auch mitteilen, also bspw. „liken“, „sharen“ oder „twittern“. Diese Möglichkeiten bieten Social Media Buttons, die beinahe auf jeder Webseite angebracht sind und mit deren Hilfe Nutzer in den sozialen Netzwerken ihr „Gefällt mir“ kundtun können. Das problematische dabei ist allerdings, dass gleichzeitig mit dem Laden der Webseite, die einen solchen Button enthält, Daten des Webseitenbesuchers sofort an den Netzwerkbetreiber übersendet werden, unabhängig davon, ob der Nutzer registriert oder nicht registriert, eingeloggt oder abgemeldet ist. Über den eingeloggten Nutzer werden dabei am meisten Daten gebündelt: Facebook beispielsweise kann den Nutzer anhand seines Nutzerprofils eindeutig identifizieren, seine IP-Adresse zuordnen und sein Internetverhalten anhand der besuchten Webseiten bestimmen, um damit gezieltere Werbeanzeigen zu schalten. 

Die bisherige Rechtsprechung 

Das LG Düsseldorf hat am 09.03.2016 entschieden, dass die Einbindung von Facebook-Buttons – selbiges dürfte aber auch für die ähnlich funktionierenden Buttons anderer sozialer Netzwerke gelten – ohne Einwilligung des Nutzers und ohne Aufklärung über Zweck und Funktionsweise des Buttons gegen § 3a UWG iVm § 13 TMG verstößt und damit unlauter ist. § 12 TMG sieht nämlich vor, dass personenbezogene Daten nur weitergegeben werden dürfen, wenn Rechtsvorschriften dies ausdrücklich erlauben oder der Betroffene in informierter Weise eingewilligt hat. Im Rahmen dieser Entscheidung ist auch die Frage aufgeworfen worden, aber offen geblieben, ob dynamische IP-Adressen personenbezogene Daten sind. Diese Frage hat der BGH als Vorlagefrage an den EuGH gestellt, der dies im Oktober 2016 auch entschieden hat: Dynamische IP-Adressen sind personenbezogene Daten nach § 3 Abs. 1 BDSG, wenn sie Rückschlüsse auf eine bestimmte oder bestimmbare Person zulassen. Dies ist laut EuGH der Fall, wenn der Webseitenbetreiber über rechtliche Mittel verfügt, die es ihm ermöglichen die konkrete Person zu ermitteln, die hinter der IP-Adresse steht. Mit dieser Maßgabe entscheidet sich der EuGH weder für den bisher vertretenen „absoluten Maßstab“, der es ausreichen lässt, wenn irgendein beliebiger Dritte die betroffene Personen identifizieren kann, noch für den „relativen Maßstab“, der das Vorliegen personenbezogener Daten nur annimmt, wenn die konkrete verarbeitende Stelle die Identifizierung der Person vornehmen könnte. Die Daten dürfen also nur erhoben werden, wenn der Nutzer informiert ist und ausdrücklich eingewilligt hat. Daher muss jeder Webseitenbetreiber noch vor Erhebung der Daten eine solche Einwilligungsmöglichkeit vorsehen. Ein Hinweis in der Datenschutzerklärung alleine reicht hierbei nicht.

Handlungsempfehlung für Webseitenbetreiber mit Social-Media Buttons 

In der Praxis werden derzeit zwei Lösungen für die Einbindung eingesetzt: Die sog. „zwei-Klick-Lösung“ und die „Shariff“-Lösung. Bei der „Zwei-Klick-Lösung“ muss der Nutzer durch ein aktives Anklicken den Social-Media-Button zunächst aktivieren und kann dann anschließend durch einen zweiten Klick Inhalte teilen oder liken. Eine Übermittlung der Daten wird so erst durch ein aktives Handeln des Nutzers ausgelöst, zuvor wird eine automatische Übermittlung verhindert. Die „Shariff“-Lösung stellt eine Weiterentwicklung der „zwei-Klick-Lösung“ dar und ermöglicht die Aktivierung schon durch einen Klick, wobei die Buttons von ihrem Erscheinungsbild her leichter erkennbar sind, als die Hinweis-Buttons der „Zwei-Klick-Lösung“ und für den Nutzer daher leichter und sicherer zu bedienen sind. Ob diese Lösungen jedoch absolut rechtskonform sind, ist gerichtlich nicht erklärt, sodass auch dieser Weg hinsichtlich etwaiger Rechtsunsicherheiten nur unter Vorbehalt zu empfehlen ist. Ein rechtssicheres Handeln kann derzeit wohl nur dadurch erreicht werden, dass die Page-Plugins sowie Like- und Sharebuttons nicht genutzt werden.

NOCH FRAGEN?

Wir freuen uns auf Ihre Anfrage zu diesem und weiteren Themen!

LG Wiesbaden zur rechtlichen Einordnung von SCRUM

Wir beleuchten das Urteil des LG Wiesbaden und gehen genauer darauf ein, welchen zivilrechtlichen Vorschriften SCRUM unterliegt.

LG Wiesbaden zur rechtlichen Einordnung von SCRUM

Einleitung

Das LG Wiesbaden hat am 30.11.2016 entschieden, dass für SCRUM das Werkvertragsrecht anzuwenden sei. Obwohl Scrum als agile Softwareentwicklung tendenziell dem Dienstvertrag unterfällt, scheint eine durchgehende Einordnung als Dienstvertrag nicht sachgerecht. 

Zum Sachverhalt 

Die Beklagte als sog. Projekt-Owner plante die Erstellung einer Internet-Plattform, die dazu dienen sollte, ehemalige Soldaten und potentielle Arbeitgeber aus der Wirtschaft zusammenzubringen. Diesbezüglich schloss die Beklagte mit der Klägerin als Programmierteam und zugleich auch SCRUM-Master einen LOI (Ein LOI – englisch Letter of Intent – ist eine unverbindliche Absichtserklärung zwischen zwei oder mehreren Vertragspartnern, in dem die Vertragsparteien bestätigen, dass sie in Verhandlungen über einen Vertragsabschluss stehen. Der LOI bildet i.d.R. die Grundlage für den anschließenden Vertrag. Er begründet keinerlei Rechtsansprüche.). Die Parteien vereinbarten, dass das Projekt im sog. SCRUM-Verfahren durchgeführt werden sollte. 

SCRUM ist ein agiler Prozess in der Software-Entwicklung. Der Begriff entstammt dem Englischen und bezeichnet das „Gedränge“ von Rugbyspielern um den Spielball. In der Software-Entwicklung wird der Begriff deswegen genutzt, weil sich das gesamte Team ähnlich wie beim Rugby täglich trifft, um sich gegenseitig abzustimmen und zu informieren. Beim SCRUM-Verfahren erfolgt die Softwareerstellung in kleinen Schritten orientiert an den vom Auftraggeber fortlaufend definierten Aufgaben oder vorgegebenen, in der Software abzubildenden Sachverhalten, ohne dass zuvor das Endergebnis der Entwicklung festgelegt ist. Dabei ist der SCRUM-Master dafür verantwortlich, dass das Projekt gelinkt und das gewünschte Ergebnis erzielt wird. Das Verfahren zeichnet sich dadurch ab, dass der Kunde am Anfang in Umrissen beschreibt, was er möchte. Die Software wird dann durch die Entwicklung sog. Sprints zur Projektreife entwickelt und programmiert. Diese Methode eignet sich besonders in den Fällen, in denen der Auftraggeber selbst nicht über genügende Kenntnisse verfügt, um wie bei der klassischen Softwareerstellung ein Lasten- und Pflichtenheft zu erstellen. 

Aus dem oben bezeichneten Projekt begehrt die Klägerin Schadensersatz. Die Parteien verhandelten über eine Projektbeendigung gegen Zahlung einer gewissen Summe. Die Beklagte leistete aber nur teilweise. 

Entscheidungsgründe des LG 

Das LG Wiesbaden wies die Klage als unbegründet ab. Nach der Auffassung des LG unterliegt das vorliegende Vertragsverhältnis den werkvertragsrechtlichen Vorschriften. Denn für die Parteien war nicht die Tätigkeit der Klägerin im Rahmen des Projekts entscheidend, sondern die Realisierung der angestrebten Plattform. Somit lag ein erfolgsabhängiges Schuldverhältnis vor. 

Der vereinbarte Erfolg – die Verwirklichung der Plattform – ist nicht eingetreten. Zwar handelt es sich hier nicht um eine klassische IT-Leistung, die eindeutig unter das Werkvertragsrecht einzuordnen wäre, sondern um eine Software-Erstellung im sog. SCRUM-System. Nach diesem System wird auf eine vorgeschaltete Planungsphase verzichtet, da die Planung unmittelbarer Bestandteil des Erstellungsprozesses ist und innerhalb der verschiedenen Sprints stattfindet. Obwohl die Verantwortlichkeiten der Beteiligten im Gegensatz zum klassischen Softwareerstellungsvertrag nicht eindeutig voneinander abzugrenzen sind, bleibt es bei der agilen Software-Erstellung bei der Konzeptionshoheit des Auftraggebers und der Ausführungsverantwortlichkeit des Auftragnehmers. 

Ferner vertritt die Beklagte die Auffassung, dass ein Vergütungsanspruch der Klägerin bereits aus dem Grund zu verneinen sei, dass die Leistung nicht fertiggestellt wurde. Jedoch scheitert der Werklohnanspruch der Klägerin nicht nur daran. Die Klägerin kann die Bezahlung des Werklohns schon vor Fertigstellung und Abnahme des Werkes verlangen, weil die Beklagte mit dem Ausgleich der fälligen Rechnungen der Klägerin in Verzug war und die Parteien deshalb die Zusammenarbeit beenden wollten. Aufgrund dessen scheitert der Werklohnanspruch nach der Auffassung des LG daran, dass die von ihr erbrachten Teilleistungen mangels einer hinreichenden Dokumentation für die Beklagte unbrauchbar und damit letztlich wertlos sind. Das seitens des LG eingeholte Sachverständigengutachten hat bei der Überprüfung der Java-Doc-Dokumentation festgestellt, dass eine übergreifende System-/Architektur-Dokumentation gefehlt hat. Diese System-Architektur ist nach den Ausführungen des Sachverständigen essentiell zum Verständnis des Sourcecodes. Ohne die System-Architektur kann eine Weiterführung der Arbeitsergebnisse der Klägerin durch einen Außenstehenden nicht durchgeführt werden. 

Stellungnahme 

Die Entscheidung des LG Wiesbaden statuiert ein Exempel im Hinblick auf die Vertragsgestaltung von Scrum. Obwohl agile Softwareentwicklungen, wie beispielsweise Scrum, tendenziell als Dienstvertrag einzustufen sind, ordnet das LG diese unter das Werkvertragsrecht ein. 

Dies hat zur Bedeutung, dass Scrum anwenderfreundlicher und zugleich haftungsreicher ist. Die Anwenderfreundlichkeit lässt sich auf die werkvertragsrechtlichen Vorschriften zurückführen. Zentrales Argument ist dabei, dass der Auftragnehmer einen Erfolg statt eine Leistung schuldet. Außerdem bestehen bei der Annahme eines Dienstvertrags keine Mängelrechte. 

Eine durchgehende Einordnung als Werkvertrag ist nicht sachgerecht, da die Eigenheit agiler Projektverfahren eine vertragsrechtliche Differenzierung erfordert. Es hat eine vertragsrechtliche Differenzierung zwischen der Phase bis zur Herstellung einer ersten Fassung einer lauffähigen und demonstrierbaren Grundfunktionalität und der darauffolgenden Phase der Anpassung und Weiterentwicklungen zu erfolgen. Erstere liegt ausschließlich im Verantwortungsbereich des Auftragnehmers. Dieser schuldet die Erbringung eines vereinbarten Erfolgs und ist daher klar unter das Werkvertragsrecht zufassen. Letztere Phase ist durch die starke Mitwirkung und Mitgestaltung des Auftraggebers geprägt und daher unter das Dienstvertragsrecht zu fassen. Nach dieser Differenzierung ist allenfalls die Annahme eines gemischt-typischen Vertrags sachgerecht.

NOCH FRAGEN?

Wir freuen uns auf Ihre Anfrage zu diesem und weiteren Themen!