Answer about Incident between MPP & FFmpeg

[HermanChen]

We sincerely apologize for drawing so much attention to the MPP library; this matter should have stayed a issue among our media-framework developers. To start with, we wish to clarify that our intention was never to misappropriate FFmpeg’s code or render it proprietary. We hold deep respect for the spirit of open source and have always been committed to promoting open-source principles: We also hold deep respect for the FFmpeg pioneers on video codec technology and meant no offense.

We develop the H.265/VP9/AV1 decoders and their hardware drivers under the Apache license in MPP also with with the original goal of keeping all code open-source and ensuring ease of use for users. Regrettably, due to our insufficient experience in open-source code development the stream header parser source code had 12 files which source code were from FFmpeg libavcodec but removed the FFmpeg LGPL notices.

https://github.com/rockchip-linux/mpp/blob/develop/mpp/codec/dec/av1/av1d_codec.h
https://github.com/rockchip-linux/mpp/blob/develop/mpp/codec/dec/av1/av1d_cbs.c
https://github.com/rockchip-linux/mpp/blob/develop/mpp/codec/dec/av1/av1d_cbs.h
https://github.com/rockchip-linux/mpp/blob/develop/mpp/codec/dec/av1/av1d_parser2_syntax.c
https://github.com/rockchip-linux/mpp/blob/develop/mpp/codec/dec/h265/h265d_codec.h
https://github.com/rockchip-linux/mpp/blob/develop/mpp/codec/dec/h265/h265d_parser.c
https://github.com/rockchip-linux/mpp/blob/develop/mpp/codec/dec/h265/h265d_ps.c
https://github.com/rockchip-linux/mpp/blob/develop/mpp/codec/dec/vp9/vp9d_codec.h
https://github.com/rockchip-linux/mpp/blob/develop/mpp/codec/dec/vp9/vp9d_parser.c
https://github.com/rockchip-linux/mpp/blob/develop/mpp/codec/dec/vp9/vp9data.h
https://github.com/rockchip-linux/mpp/blob/develop/mpp/codec/dec/vp9/vpx_rac.c
https://github.com/rockchip-linux/mpp/blob/develop/mpp/codec/dec/vp9/vpx_rac.h

This issue remained unresolved for an extended period. To ensure full transparency, we would like to elaborate on the handling process as follows.

On February 24, 2024, issue #530 (rockchip-linux/mpp#530) was opened. We responded promptly with respect and immediately initiated preparations for a fix. But after studying the license details, we realised that simply restoring the LGPL headers would convert the entire MPP library to LGPL-licensed code. While this is acceptable for dynamically linked libraries, it would mandate that any project statically linking MPP also adopt the LGPL license. To avoid this mixed-license scenario, we decided to develop a brand-new parser.

Unfortunately, we underestimated the complexity and effort required for this task, and ongoing day-to-day work commitments continuously interfered with progress. Consequently, the development work came to a standstill, and the issue remained unresolved for an unreasonably long time. We sincerely apologize to the open-source community, FFmpeg, and all affected users for this prolonged delay.

To rectify the non-compliant behavior and address the issue comprehensively, we have implemented the following concrete measures:

• a) Submitted a counter-notification to Github and formally committed to resolving this issue on December 29, 2025..
• b) Published a patch that restores the LGPL statements on the three FFmpeg codec parser files, which is now available for review by FFmpeg members: fff87da
• c) Re-started the development of the replacement parser, so that MPP can return to a pure Apache licence.

Again we acknowledge the error that removing FFmpeg LGPL license while using the FFmpeg code and also appologize for the long delay of fixing it.
Thanks for all the supervision and feedback from the open-source community. We will complete the remaining work and restore the MPP library as the community expected.

In accordance with GitHub’s policies, if FFmpeg accepts our counter-notification, the MPP repository will be restored within 10 to 14 days. While the main repository is down, this personal repo can serve as a temporary mirror for anyone who needs to keep using the code.

Thanks again for your attention — we‘re heading back to writing code.

[kodawah]

is this AI?

[HermanChen]

No, I am human and I wrote it.
but it ran through DeepSeek and Kimi for a quick polish😉

[WoodenGlaze]

I dont think this will be enough to resolve it, given the fact that someone decided to put a rockchip copyright notice under the ffmpeg teams notice.

This entire situation reeks of bad faith, especially given the fact that others have been able to license the code you guys used w/o issues, as they didnt attempt to change licenses, and didnt alter copyright headers.

Seems like Chinese Open Source has long ways to go, licenses aren't that hard to navigate, if you try.

[nyanmisaka]

https://www.gnu.org/licenses/old-licenses/lgpl-2.0.html

In fact, according to LGPL-2.0 license section 2-b), it is permitted to retain the original copyright notice and add your own copyright notice, changes, and date after modifying the source code files. The imported code has been modified to be compatible; simply copying and pasting will not work.

If your question has any similarity to MPP's previous mistakes, it's this: how can you uphold the rights of the LGPL without reading its contents?

[LikeLakers2]

With all due respect:

On February 24, 2024

That date is nearly two years ago.

Even if we assume the worst case, it should not have taken two years for Rockchip to implement a fix to a copyright issue - unless the copyright issue was being ignored entirely.

If you need help understanding licensing and how to navigate copyright issues, please, speak to a lawyer. I'm sure Rockchip has lawyers on staff that would be more than happy to keep the company out of legal trouble.

[IngwiePhoenix]

The question on my mind is, if this has been looming for two years, why did you never reach out to the FFmpeg team and ask to work together on a solution?

I aknowledge that the following statement ought to be biased by what I see, read and experience; but why is it, that chinese developers/manufacturers are so... "quiet"? Talk, communicate, interact. This is the easiest way to work on a solution. Just sitting in your office and cooking something on your own won't resolve everything; actually communicating can go a long way.

Signaling to FFmpeg that you understood and received their complains and that you are willing to work with them to resolve this is worth so much more than any line of code.

I rely on RockChip products in my homelab a lot (the RK3588 is one of my favorite chips actually) and I have learned a lot in several sectors from reading your code.

The FFmpeg peeps might be a little spicy at times, but they're also just human. x) Talk to them, collaborate, and you may just find a new path or more options.

I wish you all the best with this development! :)

[HermanChen]

The question on my mind is, if this has been looming for two years, why did you never reach out to the FFmpeg team and ask to work together on a solution?

I aknowledge that the following statement ought to be biased by what I see, read and experience; but why is it, that chinese developers/manufacturers are so... "quiet"? Talk, communicate, interact. This is the easiest way to work on a solution. Just sitting in your office and cooking something on your own won't resolve everything; actually communicating can go a long way.

Signaling to FFmpeg that you understood and received their complains and that you are willing to work with them to resolve this is worth so much more than any line of code.

I rely on RockChip products in my homelab a lot (the RK3588 is one of my favorite chips actually) and I have learned a lot in several sectors from reading your code.

The FFmpeg peeps might be a little spicy at times, but they're also just human. x) Talk to them, collaborate, and you may just find a new path or more options.

I wish you all the best with this development! :)

Through the recent repo update, we’ve been swamped with customer issues. At the same time, we needed to maintain the open-source kernel driver for all Rockchip SoCs.

Last year we closed more than 160 Redmine tickets, but three times as many remain open.

In a commercial setting, both internal and external customers always take top priority. Because the backlog is so large, long-term yet important tasks are constantly postponed by urgent short-term fixes.

By “quiet,” we mean we simply don’t have spare bandwidth to talk with external developers.
Perhaps only after we retire—or if the company shuts down—will we finally have time for that communication.

[HermanChen]

With all due respect:

On February 24, 2024

That date is nearly two years ago.

Even if we assume the worst case, it should not have taken two years for Rockchip to implement a fix to a copyright issue - unless the copyright issue was being ignored entirely.

If you need help understanding licensing and how to navigate copyright issues, please, speak to a lawyer. I'm sure Rockchip has lawyers on staff that would be more than happy to keep the company out of legal trouble.

Develop a new splitter and parser required a lot of time and many rounds of verification, not to mention the resulting issues which will be amplified by hundreds of customers. The effort is really underestimated.

The lawyer’s suggestion is to develop the new parsers. So we now give this issue top priority and handle it full-time.

[nosoul78]

In a commercial setting, both internal and external customers always take top priority. Because the backlog is so large, long-term yet important tasks are constantly postponed by urgent short-term fixes.

By “quiet,” we mean we simply don’t have spare bandwidth to talk with external developers.
Perhaps only after we retire—or if the company shuts down—will we finally have time for that communication.

Something to consider is that you (Rockchip) are only able to serve those commercial customers today thanks to the work of those "external developers you don't have spare bandwidth for". You've said it yourself that writing the parser code from scratch is a big undertaking, so FFmpeg have saved you lots of trouble (and money).

When you own all the code, it's doesn't matter. But it's a different story when you take someone else's code and profit off it. Saying you don't have time to talk to them after violating their license is rather disrespectful. I feel like your customers would care more about such incidents rather than whatever other "urgent" issues are in the backlog. Especially since they are/were also at risk of perpetuating the license violation.

[HermanChen]

In a commercial setting, both internal and external customers always take top priority. Because the backlog is so large, long-term yet important tasks are constantly postponed by urgent short-term fixes.

By “quiet,” we mean we simply don’t have spare bandwidth to talk with external developers.
Perhaps only after we retire—or if the company shuts down—will we finally have time for that communication.

Something to consider is that you (Rockchip) are only able to serve those commercial customers today thanks to the work of those "external developers you don't have spare bandwidth for". You've said it yourself that writing the parser code from scratch is a big undertaking, so FFmpeg have saved you lots of trouble (and money).

When you own all the code, it's doesn't matter. But it's a different story when you take someone else's code and profit off it. Saying you don't have time to talk to them after violating their license is rather disrespectful. I feel like your customers would care more about such incidents rather than whatever other "urgent" issues are in the backlog. Especially since they are/were also at risk of perpetuating the license violation.

Yes, so we realize it now, And we revert the license and start replacing the code now.

[HermanChen]

new commit b13eb80 move all parser to libmpp_ext.so

[hbiyik]

new commit b13eb80 move all parser to libmpp_ext.so

this file is not in install target cmake --install does not work.

and why do you dlopen, you can link it without any license issues

[IngwiePhoenix]

and why do you dlopen, you can link it without any license issues

I think this is a result of them, literally, hurrying/speeding. I looked at the diff and noticed that the way libmpp_ext.so is set up is a little odd. Not "wrong" per-se, but definitively not how you'd do it.

I was more surprised to not find any dlsym(...) calls though.