Chinese semiconductor outfit has Linux MPP repository on Github disabled after a DMCA takedown request — FFmpeg team accuses it of using libavcodec code without attribution

News
By published

Enforcement could send ripples through Linux multimedia stacks, SBC communities, Android builds, and more.

Rockchip showing its wares
(Image credit: Rockchip)

Leading Chinese fabless semiconductor company Rockchip has had one of its major software repositories taken down in response to a DMCA takedown notice. Specifically, its rockchip-linux / mpp repository on GitHub is currently inaccessible, after the FFmpeg team complained about Rockchip’s cavalier attitude concerning intellectual property ownership, attribution, and matters of copyright infringement. Rockchip uses this code to accelerate video de/coding on its popular SoCs. If the situation isn’t remedied, it could have broad implications for users of Linux multimedia stacks, SBC communities, Android builds, and more.

FFmpeg’s complaint

FFmpeg shares its multimedia processing toolkit under the LGPL-license, and it alleges that Rockchip has infringed its copyrighted work on the libavcodec library, which contains numerous audio and video parsers and decoders for various formats.

You might assume that this is free and open source software, so little harm has been done. However, Rockchip’s Linux MPP (Media Processing Platform) code on GitHub has wholesale copied swathes of FFmpeg code, removed any attribution, and re-licensed it under Apache, which is incompatible with FFmpeg’s LGPL license. LGPL requires the original license and attribution to be preserved. Moreover, Apache adds patent clauses that LGPLv2.1 does not permit.

Rockchip dragged its feet for years

FFmpeg appears to have been quite patient in trying to converse with Rockchip devs to iron out issues ahead of this takedown. There is evidence of chats between FFmpeg and Rockchip devs taking place on Twitter/X and GitHub since early 2024, as a video from Brodie Robertson shows (h/t Hackaday).

In this chat history, we see a Rockchip dev admitting to copying the FFmpeg code in the manner they did “due to lack of understanding” about LGPL and Apache licensing conflicts.

Also in 2024, the Chinese company grumbled about being busy, but pledged fixes would come. However, the last archived response from a Rockchip dev, from last November, stated that “there are too many chips to verify and suspend…” which reduced any hope of a friendly settlement, provoking action.

What now?

FFmpeg has faced some criticism for this DMCA takedown, which GitHub has honored. However, remember that its code has been copied and re-licensed with new authorship claimed, despite large sections of code being identical and preserving original FFmpeg dev comments.

(Image credit: Future)

A proposed remedy to the situation, from FFmpeg, is as follows: “remove false authorship claims; restore original attribution and copyright notices; distribute the code under an LGPL-compatible license (e.g., LGPL itself, GPL, AGPL, etc.).” The nuclear option of “remove all infringing files” is also available, as is a choice to rewrite all the code without leaning on FFmpeg sources.

If the DMCA isn’t resolved, it isn’t just an annoyance for Rockchip. Linux, Android, and SBC devs, reliant on Rockchip’s MPP for hardware-accelerated video playback, might have to fall back to doing this processing in software (with multiple negative impacts). If the downstream developers continue to use MPP, they risk losing trust, losing OS support, and facing legal risks.

Google Preferred Source

Follow Tom's Hardware on Google News, or add us as a preferred source, to get our latest news, analysis, & reviews in your feeds.

Mark Tyson
Mark Tyson
News Editor

Mark Tyson is a news editor at Tom's Hardware. He enjoys covering the full breadth of PC tech; from business and semiconductor design to products approaching the edge of reason.

10 Comments Comment from the forums
  • bit_user
    Nothing is stopping Rockchip from just moving their code to a different hosting platform. FFMPEG should get a lawyer, if they don't already have one, and pursue legal action, if Rockchip continues to distribute the code in binary form (as I expect they will).

    Yes, it'll mean some people's Rockchip-based devices might stop getting updates and newer devices are late to market. However, license terms need to be respected and examples must be made to drive that point home to other potential offenders.

    Rockchip can still change course and respect the original license. It would be ironic if their main reason for violating FFMPEG's IP was to protect their own IP (i.e. patents).
    Reply
  • utroz
    Rockchip has preliminarily fixed the issues and they are being looked at by ffmpeg and others for compliance before being posted to the main rockchip github repo. This is from their developers github. https://github.com/HermanChen/mpp/commit/fff87da91706d92913ba0254cee8c27eb093ae16
    Github issue logs detailing the issue.
    https://github.com/HermanChen/mpp/issues/73
    https://github.com/HermanChen/mpp/issues/71
    Reply
  • bit_user
    utroz said:
    Rockchip has preliminarily fixed the issues and they are being looked at by ffmpeg and others for compliance before being posted to the main rockchip github repo. This is from their developers github. https://github.com/HermanChen/mpp/commit/fff87da91706d92913ba0254cee8c27eb093ae16
    Why did they ever change the licensing, in the first place? They must not only restore the copyright & license to the source code, but also comply with all the terms!

    Clearly, this wasn't just a matter of the changes in that commit, or they'd have done it long ago. They must've had reasons for dragging their feet.
    Reply
  • utroz
    bit_user said:
    Why did they ever change the licensing, in the first place? They must not only restore the copyright & license to the source code, but also comply with all the terms!

    Clearly, this wasn't just a matter of the changes in that commit, or they'd have done it long ago. They must've had reasons for dragging their feet.
    I think it has something to do with the original Ffmpeg lgpl licence not allowing code derivatives to become closed source. This is especially an issue if a company uses a rockchip soc using the code and doesn't want anyone to see the changes they made to the Ffmpeg code. The Apache license allows derivatives to become closed source iirc. Them removing ffmeg copyright is just kind of weird and I really can't see the legitimate reason for it. It makes it look like they're claiming they wrote all the code which they did not. But that is the only way they could make the entire code base Apache license. So basically I'm thinking the company's RockChip sell chips to want everything to be Apache license so that when they customize it they can close source everything and have it all be proprietary.
    Reply
  • bit_user
    utroz said:
    I think it has something to do with the original Ffmpeg lgpl licence not allowing code derivatives to become closed source.
    That is fundamental to LGPL. You can't change that and still have it be LGPL, which is why it must've been switched to Apache.

    utroz said:
    This is especially an issue if a company uses a rockchip soc using the code and doesn't want anyone to see the changes they made to the Ffmpeg code.
    That's the tradeoff. If you want to use LGPL code, then you must share your modifications. Period. If you don't like that, then you must write your own from scratch or find another upstream. You can't just take someone else's code and change the license on it!

    When someone publishes copyrighted source code, they get to decide the terms under which it's shared. That's the license. If you want to use their source code, you must adhere to the license terms. One of the terms in LGPL is that you cannot change the license on that or any derivative. If you cannot agree to the terms, you should not use the code. It's really simple.
    Reply
  • wujj123456
    Apache is also an open-source license. The major difference is that you can retain the rights of patents and you are not required to distribute future modification to your customers. Unless they are like Qualcomm who double-dip and require you to license their patents first before you can even buy their solutions, Apache license doesn't benefit them directly as they've obviously released the code already.

    The fact that they go out of their way to wipe the licenses from code means they know exactly what they are doing. This is almost certainly for their customer (likely OEMs who make end products) that want to make further changes on top of their code base but not forfeiting their patents or releasing their code. The interaction is simply the customer dictating that the code you give us must be among these licenses or we aren't doing business with you. How you do that is none of their business. At least they can pretend that they do not know as the code comes from the chip vendor.

    I worked for one major US mobile chip company in my first job. There are some kernel API explicitly exported as GPLv2 to prevent proprietary drivers from using them. One crappy thing companies do is to call those API in kernel and export that wrapper as non-GPLv2. This is technically legal or at least in grey area never challenged AFAIK. I refused to do that and it escalated all the way to the department lead who signed-off the patch. Why? OEM customers want proprietary drivers and they demand that the code we provide is compatible with that.

    I always think ffmpeg is too kind. Their code is abused in so many products because media library is huge and hard to do. It would be great if they actual sue one of the end OEMs and force them to release all other source code while invalidating their rights to the patents. This would teach a lesson for both sides, where the chip vendor is shielding the risk for their customers (i.e., OEMs). It will turn the table around so that the OEMs become the one that are eager to enforce the license compliance in order to protect their own interests.
    Reply
  • bit_user
    wujj123456 said:
    The fact that they go out of their way to wipe the licenses from code means they know exactly what they are doing. This is almost certainly for their customer (likely OEMs who make end products) that want to make further changes on top of their code base but not forfeiting their patents or releasing their code.
    That's a good point. It might've been by request from their customers. If so, then they should've written their own implementation, instead of ripping off LGPL code and pretending they wrote it.

    wujj123456 said:
    I worked for one major US mobile chip company in my first job. There are some kernel API explicitly exported as GPLv2 to prevent proprietary drivers from using them. One crappy thing companies do is to call those API in kernel and export that wrapper as non-GPLv2. This is technically legal or at least in grey area never challenged AFAIK.
    Oh, the Linux kernel has been cracking down on that. It's one of the factors that pushed Nvidia to finally write an open source driver.
    https://www.phoronix.com/news/Linux-Kernel-Blocking-NV-NetGPU https://www.phoronix.com/news/Linux-6.6-Illicit-NVIDIA-Change
    wujj123456 said:
    OEM customers needed this or we can't do power control. It's not like we need that when we release our code anyway.
    Huh? Why could you not write & use a GPL-compliant driver to do power control?

    wujj123456 said:
    media library is huge and hard to do.
    ISO/IEC does publish reference implementations of their codecs. This includes all of the MPEG standards, AFAIK, and effectively covers H.264 and H.265.

    I'm not sure about other standards organizations or what license terms those reference implementations are published under. Usually, their performance is pretty poor, but that can be addressed if the license is favorable.

    wujj123456 said:
    It would be great if they actual sue one of them and force them to release all other compiled source code while invalidating their rights to the patents. They should have made an example of it long time ago.
    Agreed!
    Reply
  • wujj123456
    bit_user said:
    Huh? Why could you not write & use a GPL-compliant driver to do power control?
    Userspace power control can involve a lot from patented algorithms to hardware register details that are proprietary. Meanwhile, it has to hook up with the corresponding kernel API in order to either get necessary information from the kernel or influence kernel decisions.

    PS: I edited my comment to make some points more clear but overall opinion is the same. If others can't find the quotes, that's my fault...
    Reply
  • bit_user
    wujj123456 said:
    Userspace power control can involve a lot from patented algorithms to hardware register details that are proprietary.
    My understanding is that, while the kernel is GPL, its userspace API is not. That's how Mesa can be MIT-licensed, for instance.
    https://docs.mesa3d.org/license.html
    For those who don't know, Mesa is the userspace portion of the open source graphics stack, on Linux.
    Reply
  • wujj123456
    bit_user said:
    My understanding is that, while the kernel is GPL, its userspace API is not. That's how Mesa can be MIT-licensed, for instance.
    https://docs.mesa3d.org/license.html
    For those who don't know, Mesa is the userspace portion of the open source graphics stack, on Linux.
    Sorry I wasn't clear there. The "userspace" power control is more like the setup of nvidia driver. There is a kernel module dealing with hardware registers while interfacing with the kernel API and providing their own API for the userspace drivers. This is affected by the GPLv2 exports and OEMs want the kernel module to be proprietary to protect their secrets when they modify our kernel modules. This part, in the ideal world should just be part of the kernel source, not some proprietary blob loaded from the outside.

    The user space driver that communicates with the kernel module is not controversial. It's considered good practice to reduce the privileged code execution whenever possible regardless the business interest behind it.
    Reply