Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

["softworkz ." <softworkz-at-hotmail.com@ffmpeg.org>]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@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
> <michael@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.

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.
When you do your own things on top of a project as big as FFmpeg,
you'll get inevitably to a point where you want have certain 
things merged upstream to get rid of the burden of continuously
curating the divergences - so maybe there's a fit of interests in
some way. 


sw


_______________________________________________
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".