This is not allowed under the LGPL, which mandates dynamic linking against the library. They copy-pasted FFmpeg code into their repo instead.
The problem here isn't a technical violation of the LGPL, it's that Rockchip doesn't own the copyright to FFMPEG and simply doesn't have the legal authority to release it under any license other than the LGPL. What they should have done is put their modified FFMPEG code into a forked project, clearly label it with an LGPL LICENSE file, and link against that.
I think the devs of that Chinese company seemed to immediately acknowledge the attribution.
Now the OSS community loses the OSS code of IloveRockchip, and FFmpeg wins practically nothing, except recognition on a single file (that devs from Rockchip actually publicly acknowledged, though in a clumsy way) but loses in reputation and loses a commercial fork (and potential partner).
> - Rockchip's code is gone > - FFmpeg gets nothing back > - Community loses whatever improvements existed > - Rockchip becomes an adversary, not a partner
This is all conjecture which is probably why you deleted it.
Their code isn't gone (unless they're managing their code in all the wrong ways), FFmpeg sends a message to a for-profit violation of their code, the community gets to see the ignorance Rockchip puts into the open source partnership landscape and finally... If Rockchip becomes an adversary of one of the most popular and notable OSS that they take advantage of, again, for profit then fuck Rockchip. They're not anything here other than a violator of a license and they've had plenty of warning and time to fix.
He offer perspective from a Chinese POV, so I think it is worth people reading it. ( Not that I agree with it in any shape or form )
You are right, and the FFmpeg devs are also 100% right and I perfectly understand that.
In fact I like the idea to push the big corps and strongly enforce devs' rights.
I think earlier enforcement would have been beneficial here, just that dropping a bomb after 1 year of silence and no reminder (and we still don't know if that was the case), is a bit unpredictable, so I wanted to raise that question
All they could say was "we are too busy with the other 1000s chips we have, we will delay this indefinitely".
Ridiculous.
"Distributing buildable source under Apache 2.0 would surely qualify too"
reconcile with
"doesn't own the copyright to FFMPEG and simply doesn't have the legal authority to release it under any license other than the LGPL"
They should be covered as an aggregation, provided the LGPL was intact.
Not sure what you're trying to say here. DMCA takedown enforcement is 100% the responsibility of the Online Service Providers per statute. It's the mechanism by which they receive safe harbor from liability for hosting infringing content.
Once a valid (from a process perspective) claim is submitted, the provider is required to take the claimed content down for 10 days. From there the counter claim and court processes can go back and forth.
You can post your thoughts, feelings, and opinions on google blog, and I can submit a DMCA and google is required to take down your thoughts feelings and opinions immediately without verification.
The simplest way to comply while keeping your incompatible license is to isolate the LGPL part into a dynamic library, there are other ways, but it is by far the most common.
thank you!
It's an open question (the FSF has their opinion, but it has never been adjudicated) if the GPL impacts dynamic linking.
One could argue that if one ships GPL dynamic libraries together with one's non GPLd code, one is shipping an aggregate and hence the GPL infects the whole, but its more complicated to say if one ships a non GPLd binary that runs on Debian, Redhat et al and uses GPLd libraries that they ship.
Seriously, if we copied in violation their code, how many hours would pass before a DMCA violation?
FLOSS should be dictatorial in application of the license. After all, its basically free to use and remix as long as you follow the easy rules. I'm also on the same boat that Android phone creators should also be providing source fully, and should be confiscated on import for failure of copyright violations.
But ive seen FLOSS devs be like "let's be nice". Tit for tat is the best game theory so far. Time to use it.
Also, it's better to gently apply pressure and set a track record of violators taking corrective measures so when you end up in court one day you've got a list of people and corporate entities which do comply because they believed that the terms were clear enough, which would lend weight to your argument.
Saying this as a GPL hardliner myself.
If you don’t own it and cannot legally relicense part as LGPL, you’re not allowed to publish it.
Just because you can merge someone else’s code does not mean you’re legally allowed to do so.
> This may or may not be possible
I am not sure what you are saying, that is different from the comment you replied to.
Fair use doesn't get thrown out the window because GPL authors have a certain worldview.
Second, there are a lot of non-copyrightable components to source code - if you can't copyright it - you certainly can't GPL it. These can be copied freely by anyone at any time.
In the specific ffmpeg case, you are allowed to dynamically link against it from a project with an incompatible license.
If they aren't compatible, then you can't use them together, so you have to find something else, or build the functionality yourself.
Copyleft licenses are designed to prevent you mixing code as the licenses are generally incompatible with mixing.
More permissive license will generally allow you to mix licenses. This is why you can ship permissive code in a proprietary code base.
As for linking, “weak copyleft” license allow you to link but not to “mix” code. This is essentially the point of the LGPL.
Patents != copyright
... yet, you did it anyway, without going into detail or providing any clue where these violations (as you claim) are.
If there's any substance to what you say, provide some details and proof, so it can be a constructive discussion, rather than just noise.
I'm honestly quite confused what FFmpeg is objecting to here, if ILoveRockchip wrote code, under a compatible license (which Apache 2.0 is wrt. LGPLv2+ which FFmpeg is licensed under) -- then that seems perfectly fine.
The repository in question is of course gone. Is it that ILoveRockchip claims that they wrote code that was written FFmpeg? That is bad, and unrelated to any license terms, or license compatibility ... just outright plagiarism.
The notice has a list of files and says that they were copied from ffmpeg, removed the original copyright notice, added their own and licensed under the more permissive Apache license.
To those downvoting, curious why? Many of the links are not viewable, since GitHub hides them, so any discussion becomes quite tricky.
https://archive.softwareheritage.org/browse/directory/ed4b20...
And yep, they only included the most openly permissive ones there (APL2 and MIT), completely skipping everything else. Ugh.