Re: [FFmpeg-devel] [RFC] Cherry picks vs merges

["Rémi Denis-Courmont" <remi@remlab.net>]

Le tiistaina 3. kesäkuuta 2025, 16.09.48 Itä-Euroopan kesäaika Michael 
Niedermayer a écrit :
> > So, which of his "modifications" (commits) have an explicit statement
> > "otherwise"?
> I see this:
> 
> commit 3ff6d301b27965b23ae5cf5211920ee16d6671c2
> Author: Anton Khirnov <anton@khirnov.net>
> Date:   Thu Oct 24 08:37:11 2024 +0200
> 
>     lavfi: add frame threading infrastructure
> 
>     Code under AGPL, use --enable-agpl to enable.
> 
> this code also has AGPL headers in source, there is no ambiguity here

Precisely, this specific changeset is *not* under GPL. My point is that the 
other changesets are ostensibly intended to be under the GPL, even if they 
touch files with LGPL or other license headers.

> [...]

> > >And it IS stated otherwise in these files by the license header in these
> > >files.
> > 
> > It is stated that the original files were under the LGPL (or GPL), nothing
> > else.
> Many new codecs and filters where added by Paul, and he used standard LGPL
> license headers for them.
> Thats not a "modified existing file with LGPL" case
> its genuinely new files where LGPL headers where used.

We can't know if that was on purpose or by accident. I agree that we can 
resaonably assume that those files are LGPL'd. If Paul intended otherwise, then 
that's his fault for not being careful.

The problem remains for files that were existing - unless he himself clarifies 
his licensing terms.

> [...]
> 
> > Fortunately, the record of changes does in fact exists: the Librempeg git
> > repo. But that being the case, we can't argue that you didn't notice that
> > the modifications didn't have a statement "otherwise".
> The files do have statements "otherwise", in the form of the LGPL license
> header

The *files* but not the *changes*.

> > And sure, that's just my interpretations, but what do you think Paul
> > *intended* here? If it come to that, the court, or more likely, FFmpeg
> > downstreams and reverse dependencies, will probably base their decision
> > on Paul's inferred intent, not mine, but also not yours.
> IANAL but according to the principle of contra proferentem, in case of
> ambiguity a clause should be interpreted against the party who wrote the
> clause not in favor.
> 
> That said, there is no real ambiguity, its LGPL headers, there is nothing
> that REMOVES this license. The statement ADDS a GPL v2 license.

It does not add a GPLv2 license. It adds code under the GPLv2 license and 
combines them with preexisting code under the LGPLv2.1.

One can choose to continue to redistribute like that in source form. But the 
moment one distributes the result of that combination in binary form, the only 
option is to relicense the LGPLv2.1 parts under GPLv2.

> That said, iam not sure how wise it is to discuss legal interpretations in
> public. Generally lawyers recommand against such things.

It is also unwise to knowingly create a situation that could mislead third 
parties into unwittingly committing copyright infringement.

And again, if I were you, I wouldn't be so worried about Paul suing me, as he 
probably lacks the motivation and finances to do so. Instead I would be wary of 
downstreams and reverse dependencies, dropping/forking FFmpeg because they 
don't want to move to the GPL.

IMO, merging all that stuff makes LGPL no longer viable for FFmpeg 
redistributors, as it would become too difficult and/or risky to distinguish 
what is and what is not LGPL-compatible.

At the same time, I expect that this proposal pissed Paul off, and merging 
would piss him off even harder. So I don't really see the point in this effort: 
pissing Paul off, upsetting people concerned about LGPL licensing, and 
pressuring the community to review a massive blob of code.

I didn't look at Paul's new code, but it does not look like there is a strong 
demand for merging it into FFmpeg, that would outweigh all those downsides.

-- 
Rémi Denis-Courmont
Tapio's place new town, former Finnish Republic of Uusimaa



_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".