Hi softworkz On Mon, May 26, 2025 at 09:27:17AM +0000, softworkz . wrote: > > > > -----Original Message----- > > From: ffmpeg-devel <ffmpeg-devel-boun...@ffmpeg.org> On Behalf Of Rémi > > Denis- > > Courmont > > Sent: Montag, 26. Mai 2025 10:01 > > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg > > > > Hi, > > > > Le 25 mai 2025 22:22:52 GMT+03:00, Michael Niedermayer > > <mich...@niedermayer.cc> a écrit : > > >Note the license of this code is a bit wonky. The files have one > > >license and theres another one in LICENSE.md. > > >While I belives legally this allows one to choose either. I suggest > > >you check this with a lawyer. > > > > You do realise that FFmpeg does the exact same thing: > > - have a top-level license file (with the same name even) explaining, or > > trying to explain, which file is under which license, > > - carry a copy of every GNU licenses as separate files. > > From my understanding and what I've read, a specific license in a source > file header is generally considered to take precedence over what's stated > in any accompanying files. There are also recommendations specifically > about relicensing LGPL code under GP, recommending to change all source > file headers accordingly. > Also, you cannot (effectively) relicense specific changes only, simply > because nobody can know what those changes would be - given that the > prescribed form of distribution is source code, not a version control > repository. In turn, to properly re-license LGPL to GPL, the whole > source files need to be re-licensed under GPL and that needs to be > indicated as such. > >
> Generally, I believe that we should at least try to come to
> an agreement. The GPL may create a kind of one-way situation,
> but if we would decide to do some project reorganization, code style
> and variable naming unification and other global improvements which
> involve lots of changes to many files, then that one-way flow would
> start congesting in a very inconvenient way as well.
The way it is ATM, is that
1. code that is GPL in ffmpeg, everything can be merged (because it must be GPL)
2. code that is LGPL in ffmpeg, we can merge LGPL code
3. code that is not in ffmpeg, we can include GPL and LGPL with correct
headers and set gpl depandancy in configure accordingly
4. we can provide a seperate repository that includes everything and is GPL
we dont have to make a choice about changing mainline to GPL
Its Pauls code and he must make a choice what license he wants his code to
be under. ATM most files contain LGPL headers
If he chooses to actually relicense everything to GPL he has to replace
these headers and he will loose users by switching to a more restrictive
license. But he cannot have it both ways, if the code is LGPL then its
LGPL for everybody
>
> An agreement must involve benefits for both sides, and also allow
> each side to pursue their goals. Maybe it would be acceptable
> when there's a regulation that guarantees a period of "n years"
> before things get into FFmpeg.
Thats not how the GPL and LGPL works.
We also cannot demand that paul waits n years before using FFmpeg code
in his fork.
Also this "wait n years" is really bad for the users of the codebase
as it results in 2 codebases, and especially for libraries thats a
pain for users
The best thing would be if paul would return, and thats what I pushed
for, for a long time and ive talked (emailed actually) with him and so
far had no luck.
We could certainly find employment for paul if he returns or also
have him be the official libavfilter maintainer
But IMO, if paul wants his fork to be a competing product instead
then we need to treat it accordingly, the same way he competes with
us. And that means we should integrate all features and bugfixes
within the constraints of the licenses.
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf
signature.asc
Description: PGP signature
_______________________________________________ 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".
