Ich habe die Lösung nun überarbeitet. Jeder/m Streamer*in wird nun beim Stream Login direkt angezeigt, ob er/sie dem neuen API Feature zustimmen will oder nicht. Damit wird jeder vor die Wahl gestellt, ob er/sie die neue API freigeben möchte oder nicht und es kann auch von niemanden übersehen werden. Das kommt einer AGB Einwilligung sehr nahe, ohne wirklich eine zu sein.
Jetzt noch einmal “kurz” warum das Ganze. Dem Argument, ein entstehendes offenes/freies App Ökosystem damit zu beschneiden, halte ich entgegen, dass, wenn jetzt da draußen 20 - 30 Apps wären und jemand wirklich eine Klage anstrebte, der Schaden für dieses Ökosystem wesentlich größer wäre. Und das nur aufgrund meiner Nachlässigkeit vorab vom (vermeintlichen) Rechteinhaber eine Einwilligung für die Weitergabe von Daten (Bilder etc.) zu haben. Selbst Metadaten scheinen dabei eine Rolle zu spielen. Ich hätte diese bisher auch als frei und unbedenklich betrachtet.
In der ersten Variante speziell nur auf die Podlive App hinzuweisen und den Schalter so zu benennen, war einfach dem Umstand geschuldet, dass es halt bisher die einzige Anbindung ist. Im Rückblick betrachtet, war das ein falsches Signal. Ich möchte natürlich keine App diskriminieren.
Nun nehmen wir mal die Schadensersatzforderung aus dem Beispielurteil weiter oben. 150 € für den Text und 100 € für das Bild. Das klingt erstmal wenig, hinzukommen aber noch die Gerichts- und Anwaltskosten. Wenn sich die Klage dann auf 20 - 30 Apps erstreckt, wird die Schadensersatzforderung vermutlich ebenfalls höher ausfallen, insbesondere wenn gegen jeden App Entwickler eine einzelne Klage angestrebt wird. Multipliziert mit mehreren Stream Verletzungen.
Mir ist zwar auch unklar, wie realistisch das Worst-Case Szenario wirklich ist, aber undenkbar ist es nicht. Es kann Jahre lang gut gehen, doch eine einzige Klage kann die App Einnahmen von Monaten evtl. sogar Jahren vernichten. Wäre es da nicht besser, vor Gericht das Argument zu haben, das eine explizite Einwilligung vorgelegen hat?
Der Vergleich mit einem Podcatcher hinkt. Ein Podcatcher hat im Urzustand keinerlei Podcasts sondern wird vom Benutzer selbst befüllt. Das heißt, ein Rechteinhaber dürfte Probleme haben, zu beweisen auf welchen Endgeräten/Apps seine Rechte verletzt worden sind. Bei Podlive sieht das anders aus (siehe Podlive Struktur).
Im Sendegarten hatten wir schon den Fall, dass eine Podcasterwähnung und die Einbindung des Logos in eine Collage zur Folge hatten, vom betreffenden Podcastanbieter aufgefordert zu werden, dieses sofort zu entfernen. Das ist quasi genauso abwegig, weil der Podcast durch die Erwähnung auch nur Vorteile hatte.
Wenn ich es mir wünschen könnte, wäre ich natürlich auch bei der ersten Implementierung geblieben.
#Streams, die sich an einen definierten Nutzerkreis richten
Ein möglicher Grund sich gegen die API zu entscheiden sind auch Streams, die sich nur an einen definierten Personenkreis richten. In der ursprünglichen Version wurde jeder „Studio Link OnAir“-Stream sofort in der in Podlive-App angezeigt. Das ist, glaube ich, auch nicht jedem klar, dass er/sie plötzlich in X Geräten auftaucht und unmittelbar live gehört wird. Jetzt ist es deutlich und auch, wie sich das Verhalten anpassen lässt.
Dem kann man wieder entgegen halten, dass dann Studio Link OnAir nicht das richtige Tool dafür sei. Mag sein, aber wenn ich anfange, solche Nutzungsszenarien in Frage zu stellen und auszuschließen (über AGBs etc.), ist Studio Link dann wirklich noch ein offenes Projekt? Ich möchte eigentlich ungern (rechtswidrige Inhalte ausgenommen) als Plattform hier den Zugang künstlich beschränken.
Warum keine AGBs?
Das Problem ist, auch hier wäre ein Opt-In zwingend notwendig und die Frage ist auch wo, die AGBs akzeptiert werden müssten, um wirklich rechtskräftig zu sein. Im Zweifel vor dem Download, bzw. Öffnen der eigentlichen App selbst.
AGBs müssen ebenfalls rechtlich einwandfrei formuliert sein, ansonsten lockt das wieder Abmahnanwälte auf den Plan. Der Aufwand dafür ist also wesentlich höher und erfordert zusätzlich einen Opt-In auf Seite des Streamers. Da diese Erlaubnis auch nur nachträglich erfolgen kann, hätte das auch die gleichen Konsequenzen wie der Opt-In über den API Schalter.
Keine Bilder in der Podlive App
Ich glaube, ohne Grafiken wäre die App wirklich kaputt. Die Coverbilder machen in der App einen wichtigen Bestandteil aus. Abgesehen davon, scheint die Rechtslage bzgl. Metadaten zumindest uneindeutig. Hätte damit grundsätzlich aber weniger Bedenken.
Podlive Struktur
Technisch ist die Studio Link OnAir API gegenwärtig genau auf die Bedürfnisse von Podlive abgestimmt. Ob bzw. wann es eine öffentliche API geben wird, kann ich momentan nicht sagen. App EntwicklerInnen können mich aber gerne anschreiben.
Podlive holt sich über die Studio Link OnAir API alle Metadaten inclusive der Bilder ab, speichert diese und verkleinert sie für verschiedene Ansichten in der App. Darauf greift dann die App selbst zu. Das bedeutet, die Apps sind kein reiner Browser/View und Cache vom Studio Link Server oder von der API, sondern komplett auf einer eigenen Infrastruktur gehostet mit Übernahme und Verarbeitung der Daten. Da es sich dabei bisher nicht um datenschutzrelevante Inhalte handelte, hatte ich da auch zunächst keine Bedenken.
Aber mit Blick auf das Urheberrecht sieht das anders aus. Übernommen werden die Daten aktuell, wenn mindestens Titel, Beschreibung und ein Cover-Bild gesetzt sind. Das heißt, schon in der Ursprungsversion war es nicht mit nur einem Klick getan, um in der Podlive App zu landen.
Kommunikation/Fazit
Ich stimme zu, in der Kommunikation ist einiges schief gelaufen und da habe ich mit meiner Entscheidung auch dazu beigetragen. Mir ging - und geht - es wirklich um das Wohl aller Beteiligten, rechtlich einigermaßen sicher zu sein und jedem die Freiheit zu geben, sich auf der Plattform optimal entfalten zu können.
Am Tag vom Podlive Release erreichten mich mehrere Hinweise (nicht nur von Martin vom Metercast), die die automatische Datenweitergabe an Podlive ohne explizite Zustimmung kritisch sahen und die Ursprungsversion rechtlich in Frage gestellt haben.
Das hätte vielleicht durch eine bessere Kommunikation darüber, wie das Preismodell von Podlive nach der Betaphase aussieht, entschärft werden können. Manche sind davon ausgegangen, dass sich die Podlive App, nach dem Muster der Xenim App, über Spenden finanziert.
Es tut mir leid, wenn ich mit Hinzunahme der Opt-In Entscheidung jemanden verletzt habe. Ich habe ja selbst zahlreiche Entwicklungsstunden investiert, um Podlive ins „Studio Link OnAir“-Universum zu bekommen, und mir liegt auch sehr daran, dass @funkenstrahlen, @phranck und zukünftige Entwickler*innen damit erfolgreich sind.
Mir geht es allein darum, das System langfristig vor Schaden zu bewahren, die für mich (Studio Link) oder Podlive existentiell bedrohlich sein könnten. Diese Bedenken konnte kein Beitrag hier bisher vollständig aus dem Weg räumen. Meiner Einschätzung nach, ist es nach wie vor ein offenes Problem.
Ich denke und hoffe, dass Podlive sich trotzdem prächtig entwickeln wird. Keine Streamer*in dürfte nun noch den Opt-In-Hinweis übersehen können. Wenn ihr Verbesserungsvorschläge habt, nehme ich diese gerne entgegen.
Mir ist transparentes Handeln sehr wichtig und hoffe sehr, dass ich damit die Hintergründe die zu meiner Entscheidung geführt haben, ausreichend beleuchten konnte.
