Rockchip MPP ist ein von der Firma Rockchip entwickeltes Software-Framework zur hardwarebeschleunigten Audio- und Videoverarbeitung.
Rockchip MPP ist keine Firma, sondern ist ein Software-Framework (Middleware), das die chinesische Halbleiterfirma Fuzhou Rockchip Electronics Co., Ltd. entwickelt hat. Ein Software-Framework ist ein vorgefertigter Programmier-Rahmen, der u.a. mehrfach verwendbare Bausteine, Schnittstellen (APIs) und feste Strukturen umfasst.
Hersteller soll fremden Code genutzt haben
Dieses Mal sind es bei Rockchip MPP keine Probleme im Code, die die Ursache darstellen. Auslöser ist eine DMCA-Notice aus dem Umfeld von Ffmpeg. FFmpeg ist ein freies Open-Source-Softwareprojekt, das Werkzeuge und Bibliotheken zur Aufnahme, Umwandlung, Kodierung, Dekodierung und Wiedergabe von Audio- und Videodaten bereitstellt.
Der Vorwurf der Entwickler ist schlicht und einfach: Code aus libavcodec soll in MPP gelandet sein – rund um die Codecs AV1, H.265 und VP9. Der Teil, der das Fass zum Überlaufen gebracht hat, ist, dass man Hinweise auf den Ursprung des Codes und des Erstellers komplett entfernt hat. Als ob das noch nicht alles wäre, hat man auch noch die Lizenz geändert, die nicht zur ursprünglichen Lizenz passt.
GitHub sperrt nicht alles, sondern nur genau genug
So läuft es üblicherweise bei DMCA-Anfragen. Es betrifft nicht das gesamte Repository, sondern nur die kritisierten Pfade, die man in der Meldung aufgeführt hat.
Das MPP-Repo ist grundsätzlich noch erreichbar. Der gesamte Gerätebaum, das README und die Branches. Nur wenn man explizit an die betroffenen Stellen geht, welche in der DMCA-Meldung stehen, erscheint die Meldung „451 Unavailable For Legal Reasons“. So beispielsweise bei den Parser- und Header-Dateien, an denen Builds und SDKs hängen.
Das ist auf den ersten Blick eine Gemeinheit, da man zunächst denkt, alles sei normal, bis man in einer Untergruppe versteht, dass etwas nicht passt und es nicht mehr weitergeht.
Warum MPP in der Praxis so zentral ist
MPP ist der Zugriff auf den verbauten Videoencodings-Chipsatz. Wenn der fehlt, kann es problematisch werden. Dann macht die CPU den Job, den eigentlich der Chip übernehmen soll. Die Folge ist mehr Last, mehr Wärme und weniger Reserven für andere Aufgaben, die im Hintergrund laufen.
Und ja, es sind „nur“ ein paar Dateien betroffen. Genau das ist das Problem. Parser sind Kleinteile, aber ohne die Kleinteile baut es keiner. Wenn die fehlen oder blockiert sind, zerschießt es dir die Builds und SDKs. An sich ist dies eigentlich keine besondere Angelegenheit. Aber es ist halt nervig, wenn es gestern ging und heute einfach nicht mehr.
Rockchip hat sich festgelegt
Es gibt ein Statement im Issue. Dort wird eingeräumt, dass Parser-Dateien in MPP gelandet sind und dass die Lizenz-Hinweise wieder rein sollen. Parallel läuft eine DMCA-Counter-Notice. Als Ausweg wird ein Rewrite angekündigt, damit die Apache-Lizenz nicht weiter auf fremdem Unterbau klebt.
Dazu gibt es einen sichtbaren Reparaturversuch im Code. Ein Commit stellt bei mehreren Dateien die Header wieder zurück in Richtung „FFmpeg / LGPL“.
Zum Glück ist damit erkennbar das die Situation wie sonst bei vielen Firmen einfach stillschweigend ausgesessen wird. Aber erledigt ist es auch nicht, bis die “geflaggten” Pfade wieder sauber sind und die Copyrightbeschwerde nicht mehr existiert oder keinen Angriffspunkt mehr hat und ins Leere läuft.
Warum das für Linux, SBCs und Android nicht egal ist
MPP ist bei Rockchip der Zugang, um auf die verbaute Videohardware zuzugreifen. Wenn genau dieser essenzielle Teil der Architektur problembehaftet ist, sind zuerst diejenigen betroffen, die am engsten am Upstream der Pakete hängen. BSPs, Vendor-SDKs, Community-Images. In der SBC-Ecke kam es von jetzt auf gleich, und man saß auf dem Trockenen, weil die Hersteller-SDKs ins Leere liefen, als das Repo plötzlich – in diesem Fall muss man sagen: legitimerweise – einen DMCA-Strike erhielt.
Für uns heißt das nicht, dass ein Stream, auf dem Gerät, plötzlich anfängt zu ruckeln. Bestehende Geräte mit vorhandener Paketinstallation haben nicht auf einmal keinen Zugriff mehr auf die vorhandenen Pakete, nur weil GitHub seinen Pflichten nachkommt und einen Pfad in einem Repository sperrt. Für Maintainer heißt es aber leider, Mirror, Fork, Fixes irgendwo festmachen, damit überhaupt noch reproduzierbar gebaut werden kann. Das kostet Zeit und Nerven und zieht die Single-Board-Computer-Bastlerszene weiter auseinander, weil am Ende jeder sein eigenes Süppchen kocht. Auf dem einen SBC funktioniert es, auf dem anderen wieder nicht. Es ist einfach eine Situation entstanden, die nicht hätte sein müssen. Es ist alles etwas weiter fragmentiert, als unbedingt nötig.
Android ist nicht anders, nur weniger transparent vom System her. Vieles läuft dort in Vendor-Trees, vieles wird als Paket weitergereicht. Aber gebaut und gepflegt werden muss es trotzdem. Wenn eine zentrale Quelle sich durch Ignoranz rechtlich ins Aus schießt, wird aus „läuft“ schnell „könnte laufen“, wenn der Hersteller seinen Job richtig macht.
Fazit zum Thema Rockchip MPP
Am Ende ist es eine einfache Sache. Es geht nicht um Meinungen oder Interpretationen von Lizenzen, sondern um wichtige Dateien. Wenn GitHub 451 darauflegt, ist MPP für alle, die bauen, nur noch so halb verlässlich. Und das betrifft nicht nur Rockchip, sondern alle, die diesen Kram als normalen Upstream einplanen.
FFmpeg hat die Sache damit in die Öffentlichkeit gerückt. Rockchip muss die Sache nun sauber umschreiben oder mit passender Lizenz und Entwicklernennung neu aufbauen. Bis dahin läuft es wie immer. Es gibt Mirrors, Forks, Pinning, Workarounds. Nicht, weil das jemand toll findet, sondern weil sonst nichts reproduzierbar bleibt. Solange das Lizenzproblem weiterhin über allem schwebt, ist das keine durchgängige, sondern eine absolut üble Situation.
