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 <an...@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-requ...@ffmpeg.org with subject "unsubscribe".
