Podlive Release - Verpasse nie mehr eine Livesendung!

simondueckert · 2017-07-04T18:59:08.785Z

iPhone neu gestartet, dann ging es, danke!

derrobert · 2017-07-04T19:33:49.386Z

Ich persönlich gehe glaube ich alle Deine Punkte problemlos mit und würde jederzeit unterschreiben, dass so viel wie irgend möglich von dem, was produziert wird, frei verfüg-, abruf-, pars- und indexierbar sein sollte.

Auch Tims Argument, dass die API keine Sonderregelung für einzelne Clients beinhalten sollte, unterschreibe ich so.

Einzig der Ton, mit dem der angekündigten Änderung begegnet wurde, war mir zu harsch.

Ggf. könnte man den Kompromiss finden, dass die API nicht die Einstellung “Möchte ich bei Podlive auftauchen” beinhaltet, sondern “Möchte ich in Drittdiensten mit meinem Livestream gelistet werden”. Quasi die robots.txt für StudioLink Streams. Daran müssen sich dann alle Clients, die die API konsumieren, halten.

Ich kann verstehen, dass das einige (Tim) albern finden werden, da die dahinterliegenden Informationen ja andernorts frei verfügbar sind, würde da aber immer dagegen halten, dass ich mich als Sendender bewußt dafür entscheide, wenn ich im Ultraschall-Interface auf den entsprechenden Knopf drücke. Mittelfristig in die Zukunft gedacht gibt es ggf. eben die von Ralf angesprochenen 20 Clients à la Podlive und ich möchte eben nicht in diesen auftauchen (warum das im Einzelnen auch immer der Fall sein sollte - hier sollten wir meiner Meinung nach immer die Entscheidung des Einzelnen zunächst akzeptieren, so sinnlos sie uns persönlich auch vorkommen mag). Man hätte dann gar keine Möglichkeit (sowohl technisch als auch gedanklich) zu überblicken, in welchen Clients man seinen Stream gewhitelistet hat und in welche nicht. Daher “blanket opt-in” oder eben nicht.

Von mir also Daumen hoch an @sreimers für die Änderung - ggf. in Zukunft mit dem Wunsch daraus ein “indexierbar” Setting zu machen, was zwar Podlive als Auslöser hatte aber sonst Nichts mehr direkt mit Podlive zu tun hat.

rstockm · 2017-07-04T19:36:33.137Z

derrobert:

Mittelfristig in die Zukunft gedacht gibt es ggf. eben die von Ralf angesprochenen 20 Clients à la Podlive und ich möchte eben nicht in diesen auftauchen (warum das im Einzelnen auch immer der Fall sein sollte - hier sollten wir meiner Meinung nach immer die Entscheidung des Einzelnen zunächst akzeptieren, so sinnlos sie uns persönlich auch vorkommen mag). Man hätte dann gar keine Möglichkeit (sowohl technisch als auch gedanklich) zu überblicken, in welchen Clients man seinen Stream gewhitelistet hat und in welche nicht. Daher „blanket opt-in“ oder eben nicht.

Aber erkläre doch bitte hier meinen Punkt 2: warum ist das beim Streaming ein potentielles Problem, aber nicht bei den normalen Clients? Ich würde das wirklich gerne verstehen. Es hat diese Debatte nie bei den Clients gegeben - warum also jetzt?

derrobert · 2017-07-04T19:38:35.176Z

Kann ich Dir nicht erklären, da ich nicht der mit dem Problem bin.

Ich sehe das ähnlich wie Du, maße mir nur nicht an aus meiner Sichtweise eine allgemeingültige Regel abzuleiten. Nur weil ich kein Problem damit habe, dass meine Inhalte überall verstreamt und verindexiert werden, heisst das doch noch lange nicht, dass das andere auch so sehen. Und ggf. haben die ja valide Einwände.

rstockm · 2017-07-04T19:40:35.240Z

derrobert:

Nur weil ich kein Problem damit habe, dass meine Inhalte überall verstreamt und verindexiert werden, heisst das doch noch lange nicht, dass das andere auch so sehen. Und ggf. haben die ja valide Einwände.

Nun bevor man aber eine bestehende Infrastruktur einfach so umwirft, hätte ich da dann doch gerne logisch nachvollziehbare Argumente. Weil „ich will das halt nicht“ kann man einfach lösen: einfach den Dienst nicht nutzen und ein anderes Streaming verwenden.
Es geht ja gerade darum, dass jetzt FÜR ALLE etwas umgestellt werden soll. Dafür möchte ich bitte, bitte vernünftige Argumente haben in Bezug auf meine Punkte 1. und 2.

derrobert · 2017-07-04T20:16:53.826Z

Wenn ich das richtig übersehe, wirft hier niemand irgendwas um. Es gab eine Nachfrage, Sebastian hat eine Option eingebaut, es wurde bekannt gegeben und die Reaktionen darauf hier waren Unverständnis und “Blödsinn”. Meine Kommentare drehten sich zu 95% um den Ton der Reaktionen (wie schon dreimal gesagt). Inhaltlich bin ich bei Dir - argumentativ finde ich Extremhaltungen immer etwas schwierig. So eine Community lebt halt von verschiedenen Inputs - auch von solchen, die wir beide ggf. nutzlos finden.

Die Änderung ist da, wenn Du den Schalter für sinnlos hälst, nutz ihn halt nicht (das Argument geht auch in die andere Richtung). Mein Vorschlag, die Einstellung etwas “allgemeiner” zu machen, findest Du oben.

P.S.: Unter “Umwerfen” bestehender Infrastruktur verstehe ich etwas anderes als “eine Option hinzufügen”. Dir ist ja nichts abhanden gekommen, andere haben etwas dazugewonnen.

rstockm · 2017-07-04T21:00:47.554Z

derrobert:

P.S.: Unter „Umwerfen“ bestehender Infrastruktur verstehe ich etwas anderes als „eine Option hinzufügen“. Dir ist ja nichts abhanden gekommen, andere haben etwas dazugewonnen.

Das ist falsch. Kein neuer Podcast wird - ohne selbst aktiv zu werden - jetzt in Podlive gelistet. Das ist das Prinzip von Opt-In und senkt die Attraktivität der App massiv da 70% der Podcasts das verbaseln oder übersehen werden.
Deine „nur eine Option“ wäre ein Opt-Out gewesen.

phranck · 2017-07-04T21:01:42.775Z

derrobert:

Wenn ich das richtig übersehe, wirft hier niemand irgendwas um.

Oh doch! Dieser neue Schalter wirft so ziemlich Alles um! Sebastian ist auf unser Bitten netterweise nur einen Kompromiss eingegangen, dass der Content fuer eine Woche bestehen bleiben kann, wie er gerade vorhanden ist. Eine Woche - in der Hoffnung, dass dann das Gros der Podcaster den Schalter im Interface findet - wir hatten heute schon diverse Nachfragen, wo sich dieser denn befinde -, und sie so wie bisher von Vielen live gehoert werden koennen.

Waehre Sebastian auf diesen Kompromiss nicht eingegangen, dann haetten wir in logisch konsequenter Folge unsere Datenbank sofort leeren muessen, und haetten eine "funktional kaputte"™ App. Das nenne ich sehr wohl eine „Infrastruktur umwerfen“.

derrobert · 2017-07-04T21:14:32.637Z

Daher hier ja die Ankündigung. Ich sehe darin weiterhin kein Problem.

derrobert · 2017-07-04T21:16:57.408Z

Ihr bietet ein kommerzielles Produkt auf der Basis einer Community-getriebenen API an. Entschuldige, wenn sich mein Mitleid in Grenzen hält. Ich verstehe Dein/Euer Problem, habe aber mit Sebastian die Erfahrung gemacht, dass er, obschon gut beschäftigt, durchaus bereit ist zu kommunizieren und solche Änderungen in Zukunft sicherlich nicht mehr von heute auf morgen einführt sondern Euch und anderen eine gewisse Vorlaufzeit bietet. Das ist in meinen Augen ein Kommunikations-Problem und kein systemisches.

Wie fast alles in diesem Thread.

jonasschoen · 2017-07-04T21:41:18.520Z

Guten Abend zusammen,

interessant, was sich hier für unerwartete Diskussionen entwickeln können. Nachdem ich den Thread gelesen und etwas nachgedacht habe, finde ich folgende zwei Möglichkeiten sinnvoll:

1. OnAir nur nutzbar, wenn dem Auslesen der API von externen Anbietern ohne Einschränkungen zugestimmt wird

Diese Option ist entspricht @timpritlove’s und @rstockm’s Auffassung und dafür müsste StudioLink im Prinzip wieder in den Ausgangszustand von vor ein paar Stunden gebracht werden. Sollte sich Sebastian (@sreimers) dazu entscheiden, fände ich aber eine Übergangsphase sinnvoll, in der den OnAir-Nutzern (Audio-Produzenten) ein Hinweis angezeigt wird, dass es eine API gibt, diese offen ist und es konkret ein Produkt (und in Zukunft vielleicht weitere) gibt, die die Streams in einer kostenpflichtigen App anzeigen. Bei der Weiternutzung des Dienstes nach einer festgelegten Frist würde diese Tatsache (die ja im Prinzip keine Änderung ist) als akzeptiert gelten, wie man das von AGB-Änderungen großer Anbieter kennt. Aus meiner Sicht sollte bei dieser Option auch eine Möglichkeit gegeben werden, seinen Podcast restlos von OnAir zu löschen.

2. OnAir bekommt ein Opt-out für Erscheinen in externen Angeboten via API

Diese Option greift @derrobert’s Verweis auf die robots.txt bei Webcrawlern auf. Die Inhalte jeder öffentlichen Webseite sind auch öffentlich einsehbar, egal ob mit oder ohne Webcrawler. Allerdings bietet die robots.txt eine Möglichkeit, Webcrawlern (und somit vor allem Suchmaschinen) mitzuteilen, dass man dort nicht gelistet werden möchte. Ob dies berücksichtigt wird, ist eine andere Frage, aber die Idee basiert eben auf dem freundlichen Einverständnis verschiedener Akteure. Und es stimmt schon, dass damit die Auffindbarkeit des eigenen Angebots stark eingeschränkt werden kann, wenn man denn möchte. Diese Option würde den OnAir-Nutzern (Audio-Produzenten) eine Wahlmöglichkeit geben mit dem Standard, dass gelistet wird. Auch hier müsste Sebastian eine Änderung vornehmen, die vermutlich aber nur im Umbennenen der Option und Umkehrung der Funktion besteht.

Beide meiner Vorschläge widersprechen dem, was Sebastian bereits umgesetzt hat und es würde sicher etwas zu Verwirrungen führen, wenn es jetzt noch einmal geändert wird. Und ich möchte auch klar betonen, dass es Sebastians Entscheidung ist und ich mich nicht darin einmischen möchte, wie er seine Plattform gestaltet, denn am Ende haftet er womöglich. Langfristig macht es aus meiner Sicht aber schon Sinn, hier eine durchdachte Lösung zu finden, die für Podcaster möglichst einfach bedienbar ist (deshalb wenn Opt-out, weil wahrscheinlich selten) und es Entwicklern wie @funkenstrahlen und @phranck ermöglicht, in einer App auch wirklich ein großes Angebot der streamenden Podcasts zu präsentieren.

Danke für’s Lesen, gute Nacht

simondueckert · 2017-07-04T21:46:07.881Z

Wir sind ja im Podcasting nicht die ersten, die mit dem Thema Rechte an Metadaten zu tun haben. So sehr mir die Idee völlig freier Metadaten in Feeds gefällt, sehe ich doch auch im Bereich des Bloggings Urteile, die die Verwendung von Metadaten als Urheberrechtsverletzung sehen (http://www.zdnet.de/41539840/urheberrechtsverletzung-durch-einbinden-eines-rss-feeds, http://www.moenikes.de/ITC/2011/06/28/rss-feeds-einbinden-ohne-entsprechende-rechtseinraumung-ist-rechtswidrig).

Tim’s Argument, die Podcatcher Apps nutzen die Metadaten auch, stimmt zwar, ich kann aber auch verstehen, dass sich wenig risikofreudige Entwickler dieser möglichen rechtlichen Gefahr nicht aussetzen möchten. David Weinberger hat mal in einer tollen Rede in der Library of Congress (http://www.hyperorg.com/blogger/2004/11/21/library-of-congress-mp3s/) gesagt, das online die Grenze zwischen Daten und Metadaten verschwimmt und genau in diesem Graubereich sind wir hier.

343max · 2017-07-05T02:58:21.794Z

Erst mal möchte ich hier sagen, wie sehr ich mich freue, dass jemand einen Studiolink Client für iOS zu bauen. WMR hat schon 14 Follower, was mehr ist als ich gedacht hätte. Ich schau mir den noch mal etwas genauer an und werde ihn gerne kräftig bewerben wenn er funktioniert. Die 4$ die ich abdrücken musste finde ich angemessen. Ich weiß wie schwer es ist mit iOS Software Geld zu verdienen und werde mich nicht über Preise für eine gute App beschweren die weniger kostet als ein Kaffee. Danke für die ganze Arbeit!

Des weiteren finde ich ja sehr erleichternd, das – anders als ich anfangs befürchtete – niemand abgemahnt wurde oder juristisch bedroht oder sonst wie angepisst wurde sondern sich alles ja doch in einem zivilisiertem Rahmen bewegt und jeder mit jedem redet. Da finde ich den ganzen Aktionismus mal eben alle Podcasts rauszukegeln und die Wortwahl dann doch ziemlich übertrieben und unglücklich. Soweit ich das überschauen kann hat hier niemand irgendwen zu irgendwas gezwungen. Ich halte auch das Risiko einer Abmahnung für relativ gering und das finanzielle Risiko für überschaubar. Wenn euch was a eurer App liegt solltet ihr sie nicht ohne Not so beschneiden, weil ich die Angst, dass die meisten Podcasts aus Unwissenheit oder Verpeiltheit nicht dabei wären für extrem berechtigt halte. Hätte ich nicht zufällig auf einen Tweet geantwortet hätte ich diese ganze Diskussion hier nie mitbekommen. Irgendwann hätten sich dann vielleicht mal Hörer bei mir beschwert und alles wäre unnötig kompliziert und langwierig gewesen. Um ehrlich zu sein: weil ich heute nicht mehr an den Rechner komme und morgen nicht mehr dran denke kann es immer noch passieren, das ich vergesse mich einzuopten. Und wenn nicht für WMR dann eben für nerds.fm, sobald man mehr als einen Podcast haben kann. Bitte, macht es zumindest opt-out und nicht opt-in.

Und meine Meinung zu der ganzen Debatte nun auch noch: es sollte keine Möglichkeit zum opt-out geben. Zum einen halte ich die Interpretation der CC-Lizenz, das sie sich auch darauf bezieht, das sie nicht innerhalb einer kommerziellen Software dargestellt/angespielt werden darf für arg talibanesk. Nach der Logik dürften CC-NC Bilder/Videos/Musik auch nicht in kommerziellen Browsern wie Safari, Edge oder Chrome abgespiegelt werden, oder auf kommerziellen Hardwareplayern oder Autoradios. Ich finde diese Interpretation als juristischer Laie zumindest extrem abwegig. Damit kommen wir zum zweiten Punkt: meine Tweets stehen schon seit Jahren unter einer CC-NC Lizenz, was übrigens die Welt Kompakt mehrfach nicht davon abgehalten hat mich ungefragt abzudrucken. Was würde nun Twitter tun wenn ich sie auffordern würde meine Tweets nicht mehr in kommerziellen Clients wie Tweetbot anzuzeigen? Falls sie überhaupt reagieren würden würden sie mir vermutlich freundlich daraufhinweisen, dass ich ja gern meinen Account löschen kann. Und das solltet ihr auch tun (das hinweisen, nicht das löschen). Es macht die Software für euch als Entwickler, für die Hörer und für die Macher unnötig komplizierter und senkt ihren Nutzen enorm. Es dürfte den Supportaufwand um einiges erhöhen. Wenn man eine Schnappatmung bekommt, weil sich jemand nebenbei mit seiner kostenlosen geilen Infrastruktur ein Trinkgeld dazu verdient dann ist die Lösung des Problems ganz einfach: einfach die Plattform nicht mehr nutzen. Aber so weit ich das sehe scheint das in diesem Thread ja wirklich niemand zu wollen, weswegen es ja noch absurder ist, warum es das Feature und die Diskussion überhaupt gibt.

rstockm · 2017-07-05T07:19:03.213Z

Mal eben auf der Metaebene:

343max:

Da finde ich den ganzen Aktionismus mal eben alle Podcasts rauszukegeln und die Wortwahl dann doch ziemlich übertrieben und unglücklich. [/quote]

…

[quote]Und meine Meinung zu der ganzen Debatte nun auch noch: (…) Zum einen halte ich die Interpretation der CC-Lizenz, das sie sich auch darauf bezieht, das sie nicht innerhalb einer kommerziellen Software dargestellt/angespielt werden darf für arg talibanesk.

<3

Das ist so perfekt-typisch Internetforum: Man ärgert sich so über die übertriebene Wortwahl aller Schreibenden, dass man 10 Zeilen später erst mal die dickste Wortkeule des ganzen Threads rauspackt

Aber dass sich @343max und ich einmal in irgendwas inhaltlich einig sind, kommt auch mal gar nicht so häufig vor

johannes_k · 2017-07-05T08:38:59.729Z

derrobert:

(warum das im Einzelnen auch immer der Fall sein sollte - hier sollten wir meiner Meinung nach immer die Entscheidung des Einzelnen zunächst akzeptieren, so sinnlos sie uns persönlich auch vorkommen mag)

Ich denke nicht, dass man die sinnlosen Entscheidungen Einzelner akzeptieren muss/sollte. Das ist zwar erstmal „nett“ gedacht, aber wenn man diese Einstellung weiter denkt höchst gefährlich.

derrobert · 2017-07-05T13:49:28.611Z

Weiß zwar nicht, was daran gefährlich sein soll, die Standpunkte anderer Menschen als solche zu akzeptieren, aber es hat ja niemand gesagt, dass auf alle Meinungen oder Inputs auch sofort reagiert werden soll.

Grundsätzlich geht es doch nur darum nicht alle Feature-Wünsche sofort als “Blödsinn” abzutun, nur weil man sich selber in diesem Moment nicht vorstellen kann, wozu das gut sein soll. Nicht mehr aber eben auch nicht weniger.

funkenstrahlen · 2017-07-05T15:08:34.751Z

Wir nutzen für Podlive die API von Studiolink. Wir sind daher davon abhängig welche Daten Studiolink über die API freigibt.

Ich habe Verständnis dafür, dass Studiolink sich rechtlich absichern möchte, welche Daten über eine API nach außen geteilt werden dürfen. Dafür gibt es mehrere Möglichkeiten - einige wurden hier ja schon besprochen. Studiolink hat sich für ein Opt-In entschieden.

Wir versuchen gerade das Beste daraus zu machen, indem wir die Podcaster darauf aufmerksam machen und hoffen, dass viele diesen Schalter umlegen. Wir versuchen die Unannehmlichkeiten für die User der App möglichst gering zu halten indem wir den Podcasts eine Woche Zeit geben den Schalter zu aktivieren bevor er dann nächste Woche tatsächlich seine Wirkung entfaltet.

Ich hoffe wir können das Thema bald abhaken und stattdessen darüber nachdenken welche Features wir mit der App realisieren können.

sreimers · 2017-07-05T15:41:27.793Z

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.

phranck · 2017-07-05T16:22:30.853Z

sreimers:

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.

Und das hat mich von Anfang an stutzig gemacht. Ich komme bei solchen Aussagen zu dem Schluss, dass das gleiche Konzept Podlive ohne Probleme akzeptiert worden waere, wuerde die App nichts kosten. Das ist ein bisschen viel Konjunktiv, ich weiss. Aber was haette eine Spendenfinanzierung am Gesamtkonzept geaendert?

rstockm · 2017-07-05T19:52:08.019Z

sreimers:

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.

Brauchbare Lösung würde ich sagen, da sehr „in your face“ - den Text finde ich auch schon gut, müsste man mal durch Leute die jetzt den ganzen Hintergrund nicht kennen beurteilen lassen.