Veröffentlicht am 9 Kommentare

Stockfotos (Adobe Stock) und WordPress-Thumbnails

Du hast schon mal Stockfotos von Adobe Stock in deinem WordPress verwendet oder verwendest sie noch? Dann verstößt du eventuell gegen die Nutzungsbedingungen von Adobe Stock.

Aufgrund einer vergangenen Abmahnung bei einer mir bekannten Person wurden wir gezwungen, die Verwendung von Stockfotos von Adobe Stock genau zu prüfen. Unter Anderem war Gegenstand der Abmahnung, dass das Copyright in den Metadaten des verwendeten Bildes fehlt. (Ja, mir ist bewusst, dass die Fotografen mit Adobe einen Vertrag eingehen, der das eigenmächtige Handhaben von Lizenzverstößen durch die Fotografen von bei Adobe Stock bereitgestellten Bildern nicht erlaubt. Darum soll es aber hier nicht gehen.)

Grundsätzlich ist es erlaubt, Stockfotos von Adobe Stock zu verändern, wenn das erforderlich ist. Daher gingen wir immer davon aus, dass das Metadaten genauso betrifft und wir sie problemlos entfernen können. Das geht zum einen sehr schnell in Adobe Photoshop (denn das entsprechende Auswahlkästchen beim Export muss man explizit aktivieren, wenn man die Copyright-Informationen behalten will), zum anderen auch in den Standardeinstellungen von Imagify, das wir einsetzen.

Nutzungsbedingungen erlauben nicht das Entfernen von Copyright-Metadaten

Erst beim wiederholten Studieren der Nutzungsbedingungen (die als Lizenz für bei Adobe Stock lizenzierte Bilder gesehen werden muss) fiel mir unter 7. Einschränkungen folgendes auf:

(H) mit dem Stockmedium verbundene, urheberrechtlich geschütze Schutzrechtshinweise entfernen, verdecken oder ändern oder eine ausdrückliche oder stillschweigende Falschdarstellung abgeben, die besagt, dass Sie oder ein Dritter der Urheber oder Inhaber des Urheberrechts eines Stockmediums sind;

7.1 (H) Nutzungsbedingungen Adobe Stock

Die entsprechenden Copyright-Angaben in den Metadaten der Bilder sind als „urheberrechtlich geschützte Schutzrechtshinweise“ einzustufen und dürfen daher nicht entfernt werden.

Alle Bilder neu abspeichern

Als Resultat daraus mussten wir daher schnellstmöglich etwas ändern. Wir stellten die Standardeinstellung von Imagify um, sodass die Metadaten bei der Komprimierung nicht gelöscht werden und luden alle Stockfotos mit korrekten Metadaten neu hoch, um dieses Problem zu lösen.

Und was ist nun mit WordPress?

Kurze Zeit später bemerkte ich jedoch ein fatales Problem in Verbindung mit WordPress: Die ansonsten sehr nützliche Funktion, automatisch von Bildern verschiedene weitere Bildgrößen in Form von Thumbnails anzulegen, entfernte für diese Bildgrößen alle Metadaten komplett. Damit haben wir nun zwar kein Problem mehr mit dem Originalbild, aber mit allen daraus generierten Thumbnails.

Da diese im Grunde das gleiche Bild nur in anderer Auflösung darstellen, gelten hier die Nutzungsbedingungen von Adobe Stock nach wie vor.

Ergebnis

Möglicherweise verstehen jetzt so manche, warum ich mich zuletzt damit auseinandergesetzt habe, direkt nach dem Upload den Pfad eines hochgeladenen Bildes in die Mediathek herauszubekommen. Denn dort habe ich eine Funktion implementiert, die sich genau um das vorangegangene Problem zu beschäftigen: Die erforderlichen Metadaten in den Bildern über alle Bildvarianten hinweg zu kopieren. Denn nur so ist man meiner Ansicht nach konform hinsichtlich der Verwendung von Bildern von Adobe Stock innerhalb von WordPress.

9 Gedanken zu „Stockfotos (Adobe Stock) und WordPress-Thumbnails

  1. Sehr interessante Beobachtung! Gibt es denn eine einfache Art dieses Verhalten zu ändern? Oder ermöglicht es die Art und Weise, wie WordPress die anderen Bildgrößen generiert gar nicht, dass Metadaten erhalten bleiben können?

    1. Es gibt wohl einen Filter image_strip_meta in WP_Image_Editor, dieser funktioniert jedoch nur (laut entsprechendem Kommentar), wenn Imagick verwendet wird, da GD wohl generell die Metadaten des Bildes entfernt. Getestet habe ich das jedoch nicht.

  2. Ich bin dem mal nachgegangen und habe folgendes *offenes* Issue gefunden:
    https://github.com/libgd/libgd/issues/452

    Die GD-Bibliothek unterstützt also tatsächlich kein Durchreichen der Metadaten.

    image_strip_meta löscht aber auch keine Copyright-Daten, da iptc , xmp und EXIF geschützt sind und nicht entfernt werden, selbst wenn der Filter (wie standardmäßig) auf True steht.

    Allerdings scheint das nur bei JPGs zu klappen. Andere Bildformate machen wohl Probleme …

    Passt das zu deinen Ergebnissen?

    1. Leider nein. Ich hatte meinen Fokus primär auf JPG-Dateien. Und sowohl lokal als auch produktiv – auf beiden Systemen ist Imagick verfügbar – funktioniert es nicht. Allerdings habe ich nicht verifiziert, ob Imagick auch tatsächlich von WordPress verwendet wird.

      1. Unter Site Health (Website Zustand) wird im Info-Reiter ja bei „Media Handling“ angezeigt welcher Media Editor verwendet wird. Kannst du da mal schauen?

        1. Ah 🙂

          Lokal läuft tatsächlich nur GD, aber auf dem Produktivsystem läuft Imagick und dort habe ich initial überhaupt erst das Problem bemerkt.

          1. Welche Version von Imagick läuft denn? Hast du Zugang via SSH? Kannst du schauen welche Version von libjpeg da auf dem Server läuft? Die Profilverwaltung erfordert ggf. bestimmte Versionen.

            Und um welche Metadaten handelt es sich denn konkret bei Adobe Stock: XMP, EXIF, IPTC, wo genau speichert Adobe es und wird es überall gelöscht/nicht übernommen?

          2. Es läuft Version 3.5.1 von Imagick, zusammen mit PHP 7.4.25. Die genaue Version von libjpeg kann ich jetzt nicht direkt herausfinden, aber es läuft ein Ubuntu 20.04 dort und ich nehme nicht an, dass diese Bibliothek einfach verändert wurde, daher müsste es in diesem System verfügbare Version sein. Also nichts außergewöhnliches.

            Bei Adobe Stock handelt es sich sowohl um EXIF- als auch IPTC-Daten. In beiden sind die entsprechenden Copyrights definiert. Und Metadaten werden insgesamt und vollständig verworfen.

  3. Das Problem mit den anderen Bildformaten scheint dann eher eine Serverkonfiguration zu sein. PNG und WEBP erfordern weitere Bibliotheken, die vielleicht gar nicht oder in veralteten Versionen installiert sind.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.