The semiconductor manufacturer is Rockchip, who makes a ton of SoC’s for single board computers. Rockchip has apparently copied ffmpeg’s code without attribution and changed the license to a permissive one from LGPL
Terrible headline. Should have just been “Rockchip has…”.
Am I showing my age if I say that Tomshardware used to be decent?
Yes, you are, but you’re also correct.
If I had published a popular library under LGPL, and then found out that a chip company stole my code by ignoring/removing the license (change to less restrictive in attribution) I would perhaps go as far as subtly block my code from ever properly functioning on the company’s chips, until the license is respected.
People might have forgot what happened in linux kernel with the “nvidia shim module”. Those were actually banned, non-gpl compatible kernel module cannot use gpl-only symbols from the kernel. What happened here is even worse, straight up violating the license from the authors.
GPL license should have a version that could cheaply be defended by the victim of the license violation, if a verbatim violating copy is found. Some €€/month bill could pileup while a violating copy is proven to be distributed.
edit: minor fixes.
Sounds like it will be fixed soon
https://github.com/HermanChen/mpp/commit/fff87da91706d92913ba0254cee8c27eb093ae16
https://github.com/HermanChen/mpp/issues/73
Only after they were forced to. They’re criminal trash.
The verbiage of the first sentence is very telling.
We sincerely apologize for drawing so much attention…
…which to me reads as…
We’re sorry to our shareholders that we got caught with our pants down.
Oh wow, so they actually stripped off the attribution to ffmpeg and slapped their own name and license in place of it. Now they’re forced to restored the license they’re working to rewrite it all themselves so they can delete the copyrighted code. They’re so sorry though.
I bought a Rockchip SBC (Orange Pi 5+), and when it worked it was awesome…but man, the software support (mainly kernel space) is just not there. Exercise in frustration to get everything working at the same time.
Currently running armbian. I don’t think HW acceleration is working, and I don’t think HDMI out is even working, but for my use case it’s a stable config…for now.
I think that might be the same RK3588 chip as the Bananapi M7 which I did a write-up on last year. Trying a different kernel might help with your issue - it did for me.
https://blog.kumio.org/posts/2025/01/bananapim7-hvm.html#kernel-versions
I should probably update the table for trixie.
Bookmarked, thanks!
Ffmpeg are kinda assholes and squelch innovation tbh.
Dude, all Rockchip had to do to avoid this was a bit of license-related bookkeeping. They’re a corporation, so they’re used to dealing in bookkeeping and contracts. Someone at their end whose job it is to track this stuff either screwed up or let this through on purpose, assuming they wouldn’t be caught (more likely the latter, because China).
How would preventing companies from making their changes private squelch innovation? If people stop enforcing open source licenses, then companies would never contribute to the very same project they use. Ffmpeg is making innovation easier by forcing rockchip to publish their code.
If a company has to release their whole product as open source, they likely can’t make back their investment on development.
This particular case may be cut and dry, but I’ve had ffmpeg come after my company just for having an embedded Linux solution that uses off-the-shelf ffmpeg libraries. They claimed we had to release all of our custom libraries and app source and environment that were in the same product even though they didn’t have a line of ffmpeg code in them. As a small company, we couldn’t afford the litigation, so we just dropped the project.Ah, so it’s personal, got it.
Well calling them assholes is kinda personal, no?
You’re complaining you couldn’t make back your investment on a project that leveraged other people’s code.
Code that was released under a GPL license.
What the fuck makes you think anyone gives a shit about your opinion of how unfair it is that you can’t profit from their code?
I contribute to open source plenty. My company hardly makes any profit. We put it all back into r&d because we like making stuff. Employing engineers then allows them to also contribute to open source. But we have to sell stuff to keep things going. And if we made improvement to the ffmpeg source, we’d definitely publish it. But we didn’t. We just used it in an embedded solution which had a bunch of custom apps gluing it all together. We did what many others have done, but ffmpeg decided to try to shake us down (they literally asked for a payout to make it go away). Corporate litigation is stupidly expensive and not what we want to spend our time on. I don’t really care. We had fun making the device and learned a bunch. We just also learned to avoid ffmpeg like the plague.
Wydm? Rockchip copied their code, changed the license and didnt attribute FFmpeg. FFmpeg is a small team of enthusiasts who are responsible for plenty of important innovation and remain largely unpaid even with such substantial widespread use of their code in like SOOOO MANY big software projects. It isn’t their fault that people aren’t following the simple rules of the license to use their code.
In this case, sure, idk. I’ve had a project shut down because ffmpeg threatened law suits unless we open sourced our own custom libraries that work along side ffmpeg. And it’s not just the source code, they want full build environments. Our lawyers wouldn’t touch it, so we just shut it all down. Now I use gstreamer and avoid ffmpeg like the plague.
@CannonFodder @Neptr You were bundling LGPL source into your project. Their request was right, you were violating their license; if you had just used upstream FFmpeg by requiring systems to install it from the package i.e .deb dependency or downloading it directly from their releases and having their binary fully separate, you wouldn’t have had any pushback.
It was an embedded system. The user wouldn’t be able to download and install stuff, they just turn the thing on. The ffmpeg libraries were provided as is as separate files in the system.
If that’s their policy, ok. But it means we can’t use it in embedded systems.@CannonFodder Policy? It’s the legal license you agreed to when you copied their code. It’s not like they rug pulled you; it’s open, and you should have read it before you even started. If you are commercial, look into FOSSA; you need an SCA for license compliance. Your way around this for LGPL was to make a fork and then compile the fork and use those compiled libraries if you needed airgapped. The moment anything touches that code, like if you static link all code that is touching it now needs to now be public too. If you dynamically link as long as the full code for that file is open you’re covered.
I’m actually baffled you didn’t even bother reading their license for a commercial product and chalked it up to they have some policy.
We switched to dynamic libraries, but they still wouldn’t let it go. It seemed a distinction without a difference, but we did it as we thought it would put us in the clear. And yes it should have, but little of this has actually been tested in court. So smaller companies can’t risk the huge legal cost, even if they know they’re in the right. So ffmpeg killed the project for no good reason - like I said: they’re assholes. And I don’t think forking it would have made any difference, the fork is still covered by the same license. The project was still just a prototype , but with ffmpeg’s harassment we dropped it and used something else for subsequent projects. When we actually touch open source code usefully, we always share it even if we never make a product that uses it.
Talk about blame shifting. FFmpeg didn’t kill the project. Your own negligence did.
It was an embedded system. The user wouldn’t be able to download and install stuff, they just turn the thing on. The ffmpeg libraries were provided as is as separate files in the system.
The LGPL (v2.1 and later which is relevant for FFmpeg) is very clear that when linking libraries, the recipient (user) must be able to relink after making changes to the library and recompiling it. How do you figure that this part of the license is compatible with an embedded system where the user would have no access to the software side, rendering the user unable to do said relinking? As long as the user would not be able to use a modified version of FFmpeg with your system, you are automatically not in compliance with the license. Your system couldn’t use any LGPL-licensed software, not restricted to FFmpeg, so this is completely on you.
We switched to dynamic libraries, but they still wouldn’t let it go. It seemed a distinction without a difference, but we did it as we thought it would put us in the clear. And yes it should have
No, it shouldn’t, and you would know that if you looked into the LGPL license.
Ffmpeg are kinda assholes and squelch innovation tbh.
In this case it was your own greed. When you decide you have to alter your product to be able to make a profit because you’re not allowed to ghoul on others’ free work, you can’t blame those who provide the software free of charge. They have absolutely no obligation to let you make a profit by not honoring the license of their own work.
Your reasoning is basically the same as the entire rotten-to-the-core AI industry: “if we need to honor the licenses of the works we use, we would never be able to make money!” Boo fuckin’ hoo.
Also, the irony of you claiming FFmpeg squelches innovation by making you honor the license, for a product where you would like to lock the user out from being able to make modifications is just… top notch. Innovation is only good when it suits your needs, apparently, not the end user.
@CannonFodder The switching of your linking afterward doesn’t change the requirement you violated and needed to comply with, which was to open source the code that touched it.
No, it wouldn’t and shouldn’t have just dropped all the required because you complied when caught; this is equivalent to saying you parked in a handicap spot and then, when asked, moved your car and said you expected not to get fined now and the police are harassing you for such.
I get the frustration, but I know as a business owner you wouldn’t sign a legal document without reading it or understanding what you’re setting yourself up for. Yet this seems to be exactly your process with software licenses. You need a Software Composition Analysis (SCA) if you do not have the time or the energy to read the licenses; this will prevent you from falling into the same hole.
PS: this has been heavily tried in court look at QT LPGL licensing enforcement cases this is a known license and known requirements.
It was an embedded system. The user wouldn’t be able to download and install stuff, they just turn the thing on.
As someone who likes to actually own and customise all my devices, devs like you are the bane of my existence. Read up on software licensing, and pay special attention to the history of its enforcement and what it enabled us. Then please reconsider your user hostile stance.
There’s a time and place, no? You buy a $30k video switcher with support, do you really want to fuck with the internals or just get the company to add/fix features you need. It’s impossible for the company to support you once you’ve fucked with the thing.
I understand open source - we use it and we contribute. But that doesn’t mean we can open source all our code. We have competitors who would abuse that. If no one can make a living selling code, then there will be no one to support open source.
I would at least Google something before you state an opinion.
I have personal experience. I don’t need to Google it, thanks.
FAFO. and don’t expect sympathy.
I don’t need sympathy. I just warn others to steer clear of ffmpeg.
Couldn’t you rather provide the name of your company, so we know what software we should steer clear of?
I don’t see why drivers or similar shouldn’t be GPL or LGPL…
