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.
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 Social Links Navigation 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.
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
Key considerations
- Investor positioning can change fast
- Volatility remains possible near catalysts
- Macro rates and liquidity can dominate flows
Reference reading
- https://www.tomshardware.com/software/SPONSORED_LINK_URL
- https://www.tomshardware.com/software/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#main
- https://www.tomshardware.com
- Samsung Magician SSD software ‘High Severity’ vulnerability patched — upgrade to the newest v9.0.0 to prevent potential DLL hijacking and privilege escalation
- NVIDIA Rubin Platform, Open Models, Autonomous Driving: NVIDIA Presents Blueprint for the Future at CES
- China’s GPU cloud consolidates around Baidu and Huawei as domestic AI chips scale up — export controls leave gap open for homegrown solutions
- Now Generally Available, NVIDIA RTX PRO 5000 72GB Blackwell GPU Expands Memory Options for Desktop Agentic AI
- NVIDIA BlueField-Powered Cybersecurity and Acceleration Arrive on NVIDIA Enterprise AI Factory Validated Design
Informational only. No financial advice. Do your own research.