[FFmpeg-devel] [ANNOUNCEMENT] almpeg

[FFmpeg-devel] [ANNOUNCEMENT] almpeg

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1640 bytes --]

Hi all

Id like to announce that ive setup a repository to merge pauls work of
the last 2 years.

* Currently ive merged everything up to first february 2025
* all fate tests pass
* Some filters and decoders where split in 2 versions
    thats because either teh added chanegs are buggy, break API/cmd line interface
    or plain the 2 versions are actively developed and too diverged

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.

git@git.ffmpeg.org:almpeg

all ffmpeg developers should have write access to it (if you dont,
send me private mail/ping and expect 1-2 days to fix)

If you want to fix any mistakes in this, thats welcome!
currently gitlog mails are just sent to me, this can be changed if people want

Now, what is this good for ?
Once teh merges match the current date, we can either
* just merge it (with 0 conflicts)
* cherry pick from it easily (its closer to FFmpeg)
    We can also for the cherry picking easily collaborate
    using the almpeg repository and commit requested changes from
    patch review to it

PS: today it seems a merge between master and almpeg has just 22 conflicts
a direct merge from pauls code with master has 1145 conflicts

thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

[Kieran Kunhya via ffmpeg-devel]

Hi Michael,

Here is how this should be handled.

"Hi Paul,

I'm sorry for aggressively trying to force SDR into the FFmpeg project
over a period of several weeks in spite of objections from you and the
community causing you to leave.
FFmpeg is now a better community* and we would love it if you could come back.

Regards,
Michael Niedermayer
"
* Narrator: It is not a better community

Regards,
Kieran Kunhya

On Sun, May 25, 2025 at 8:23 PM Michael Niedermayer
<michael@niedermayer.cc> wrote:
>
> Hi all
>
> Id like to announce that ive setup a repository to merge pauls work of
> the last 2 years.
>
> * Currently ive merged everything up to first february 2025
> * all fate tests pass
> * Some filters and decoders where split in 2 versions
>     thats because either teh added chanegs are buggy, break API/cmd line interface
>     or plain the 2 versions are actively developed and too diverged
>
> 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.
>
> git@git.ffmpeg.org:almpeg
>
> all ffmpeg developers should have write access to it (if you dont,
> send me private mail/ping and expect 1-2 days to fix)
>
> If you want to fix any mistakes in this, thats welcome!
> currently gitlog mails are just sent to me, this can be changed if people want
>
> Now, what is this good for ?
> Once teh merges match the current date, we can either
> * just merge it (with 0 conflicts)
> * cherry pick from it easily (its closer to FFmpeg)
>     We can also for the cherry picking easily collaborate
>     using the almpeg repository and commit requested changes from
>     patch review to it
>
> PS: today it seems a merge between master and almpeg has just 22 conflicts
> a direct merge from pauls code with master has 1145 conflicts
>
> thx
>
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Many things microsoft did are stupid, but not doing something just because
> microsoft did it is even more stupid. If everything ms did were stupid they
> would be bankrupt already.
> _______________________________________________
> 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".
_______________________________________________
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".

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

[compn]

On Sun, 25 May 2025 23:29:45 +0100, Kieran Kunhya via ffmpeg-devel
wrote:

> Hi Michael,
> 
> Here is how this should be handled.

stop with this nonsense.

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

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

[Rémi Denis-Courmont]

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.

Do you think that means that anyone can pick any listed license for FFmpeg? Are you saying that anyone can take your FFmpeg IP under MIT or BSD licenses? Or take the GPL code as LGPL code?

I and probably most people here think otherwise. That's not how this works and as a major copy-left open-source developer, you should know that.

Librempeg, as a whole, is AGPL. And if you strip the AGPL bits, it's GPLv2. All you're going to achieve with this mail is infuriate Paul by encouraging people to literally steal his IP.


And then it's utterly impossible for such a massive changeset to be reviewed. So even if it weren't for the license incompatibilities, there's no way we could merge into FFmpeg.
_______________________________________________
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".

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

[softworkz .]

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

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

[Rémi Denis-Courmont]

Hi,

Le 26 mai 2025 12:27:17 GMT+03:00, "softworkz ." <softworkz-at-hotmail.com@ffmpeg.org> a écrit :
>
>
>> -----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.

That's also my understanding. If a file has an explicit license header, that applies to that file. Otherwise the default license in the ad-hoc licensing summary document applies, unless the file content cannot be copyrighted.

The verbatim license files provided at the top level are only there to meet the GNU license requirement to provide a copy of the license to the licensee. Their sole presence does *not* automatically imply any validity scope.

> (...) 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.

This is a moot point IMO, and depends what you mean by "properly". You can always combine LPGL and GPL (same major versions). If the process of combination makes the different parts indistinguishable, e.g., compilation, then the result is GPL.

>Generally, I believe that we should at least try to come to 
>an agreement. The GPL may create a kind of one-way situation,

Switching FFmpeg to the GPL is a guaranteed immediate fork trigger. We have plenty of downstream open-source projects and FFmpeg contributors who need LGPL terms because their own project is LGPL or GPL-incompatible, and/or because their transitive downstreams are GPL-incompatible.

That would be a pretty dramatic decision that would need a GA vote, and is better avoided if one doesn't want to split the community further (this is *not* a position statement from me, just a predictive observation).
_______________________________________________
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".

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Rémi Denis-
> Courmont
> Sent: Montag, 26. Mai 2025 13:26
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg
> 
> Hi,
> 
> Le 26 mai 2025 12:27:17 GMT+03:00, "softworkz ." <softworkz-at-
> hotmail.com@ffmpeg.org> a écrit :
> >
> >
> >> -----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.
> 
> That's also my understanding. If a file has an explicit license header, that
> applies to that file. Otherwise the default license in the ad-hoc licensing
> summary document applies, unless the file content cannot be copyrighted.
> 
> The verbatim license files provided at the top level are only there to meet
> the GNU license requirement to provide a copy of the license to the licensee.
> Their sole presence does *not* automatically imply any validity scope.
> 
> > (...) 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.
> 
> This is a moot point IMO, and depends what you mean by "properly". You can
> always combine LPGL and GPL (same major versions). If the process of
> combination makes the different parts indistinguishable, e.g., compilation,
> then the result is GPL.

There is just one way of relicensing that is explicitly provisioned by the Gnu licenses and that is to relicense LGPL under GPL. But not the other way round.
For example, when there's a file from an LGPL project like FFmpeg and somebody creates derivative work from it (in the sense of "all the modifications I made are licensed under GPL"), then you must relicense the whole file under GPL (while still indicating the origin and license of the origin) - because nobody can know which changes you made - so you have to relicense the whole file under GPL. This case is explicitly provisioned for. (but only in that direction, not reverse).

> >Generally, I believe that we should at least try to come to
> >an agreement. The GPL may create a kind of one-way situation,
> 
> Switching FFmpeg to the GPL is a guaranteed immediate fork trigger. We have
> plenty of downstream open-source projects and FFmpeg contributors who need
> LGPL terms because their own project is LGPL or GPL-incompatible, and/or
> because their transitive downstreams are GPL-incompatible.
> 
> That would be a pretty dramatic decision that would need a GA vote, and is
> better avoided if one doesn't want to split the community further (this is
> *not* a position statement from me, just a predictive observation).

No no no nonoooo! 😊

This is not what I meant. I meant to say that it's difficult for us because
the GPL licensing (when done in a valid way) forbids us to merge changes 
from there to FFmpeg, i.e. "one-way". 

Best regards
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".

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 4302 bytes --]

Hi softworkz

On Mon, May 26, 2025 at 09:27:17AM +0000, softworkz . wrote:
> 
> 
> > -----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.

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

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Michael
> Niedermayer
> Sent: Montag, 26. Mai 2025 13:37
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg
> 
> Hi softworkz
> 
> On Mon, May 26, 2025 at 09:27:17AM +0000, softworkz . wrote:
> >
> >
> > > -----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.
> 
> 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.

This is not about licenses. This is about how negotiations can work. 
We want his code under LGPL and he wants exclusive features in his
project. And he might want to license under LGPL, which he can't do
because then, FFmpeg would absorb everything instantly.
It's about a possible agreement - independent from any licensing.


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

And then, all Ffmpeg code is poisoned with GPL code and nothing usable
anymore. Who would want that?

Best,
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".

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Michael
> Niedermayer
> Sent: Montag, 26. Mai 2025 13:37
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg
> 
> Hi softworkz
> 
> On Mon, May 26, 2025 at 09:27:17AM +0000, softworkz . wrote:
> >
> >
> > > -----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.
> 
> 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

Yes, but the intention is that new work is licensed under GPL. 

Right now, the LGPL headers take precedence and you can safely consider
it as LGPL, but you can do that exactly one time, because after that
he'll update the headers, because then we'd have declared war.

We can do that. As mentioned, we could continuously re-organize the 
project in a way that there's no reasonable merging and updating possible 
anymore, but eventually, there won't be a winner.


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

That's the wrong question and the most unlikely outcome at all.
Instead, ask him what he wants, under which conditions he could possibly
imagine to stream code back-and-forth between projects, maybe mention
the suggestion I made. It says 'n' and there's a wide range of possible
values for that n.

I'm not sure how others see it, but I'd rather wait a bit for certain 
features (as LGPL) than getting the project contaminated with GPL code.
And when you really need something, you can still cherry-pick it anyway.

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

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 5775 bytes --]

Hi

On Mon, May 26, 2025 at 12:21:24PM +0000, softworkz . wrote:
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Michael
> > Niedermayer
> > Sent: Montag, 26. Mai 2025 13:37
> > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg
> > 
> > Hi softworkz
> > 
> > On Mon, May 26, 2025 at 09:27:17AM +0000, softworkz . wrote:
> > >
> > >
> > > > -----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.
> > 
> > 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
> 
> Yes, but the intention is that new work is licensed under GPL. 
> 
> Right now, the LGPL headers take precedence and you can safely consider
> it as LGPL, but you can do that exactly one time, because after that
> he'll update the headers, because then we'd have declared war.

Iam not sure Paul will change to GPL, because it would be ineffective
for what he seems to want to achieve. But i could easily be wrong.

Just hypothetically:
1. we merge or cherry pick all his features (LGPL)
2. he changes to GPL, now he has 0 features we dont have
3. he works for 2 more years to accumulate new features
4. we have a branch/repo called almpeg thats his code + our code and all GPL

He would loose all LGPL users, the situation for GPL would be
that we provide the same features still



[...]
> > 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.
> 
> That's the wrong question and the most unlikely outcome at all.
> Instead, ask him what he wants, under which conditions he could possibly
> imagine to stream code back-and-forth between projects, maybe mention
> the suggestion I made. It says 'n' and there's a wide range of possible
> values for that n.

i see no advantage for us to agree to n>0
It gives Paul an advantage but theres nothing we gain from it

Just think of linux. Someone forks linux lets call it fr33-linux
and he adds support for a major and important new CPU architecture
why would linux mainline not add that feature as soon as they can?

They might re-implement it if there are technical reasosn but in
what universe would they wait 2 or 3 or 5 years before linux
supports it!?


But i certainly was and am open to talk with paul.


> 
> I'm not sure how others see it, but I'd rather wait a bit for certain 
> features (as LGPL) than getting the project contaminated with GPL code.
> And when you really need something, you can still cherry-pick it anyway.

but we dont really contaminate anything with GPL code

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"    - "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Michael
> Niedermayer
> Sent: Montag, 26. Mai 2025 19:21
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg
> 
> Hi
> 
> On Mon, May 26, 2025 at 12:21:24PM +0000, softworkz . wrote:
> >
> >
> > > -----Original Message-----
> > > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Michael
> > > Niedermayer
> > > Sent: Montag, 26. Mai 2025 13:37
> > > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg
> > >
> > > Hi softworkz
> > >
> > > On Mon, May 26, 2025 at 09:27:17AM +0000, softworkz . wrote:
> > > >
> > > >
> > > > > -----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.
> > >
> > > 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
> >
> > Yes, but the intention is that new work is licensed under GPL.
> >
> > Right now, the LGPL headers take precedence and you can safely consider
> > it as LGPL, but you can do that exactly one time, because after that
> > he'll update the headers, because then we'd have declared war.
> 
> Iam not sure Paul will change to GPL

Doesn't the first sentence say that he has done that already?
(by intention, irrespective of valid or not) 

https://github.com/librempeg/librempeg/blob/master/LICENSE.md


> because it would be ineffective
> for what he seems to want to achieve.

Yes, it is ineffective. But it would be even more ineffective to license 
under LGPL, because everything would go into FFmpeg right away.

Like I said before, the GPL is the defense against FFmpeg to build
some relevance and unique advantages over FFmpeg.


> Just hypothetically:
> 1. we merge or cherry pick all his features (LGPL)
> 2. he changes to GPL, now he has 0 features we dont have

He already considers "all his features" as licensed under GPl.

> 3. he works for 2 more years to accumulate new features
> 4. we have a branch/repo called almpeg thats his code + our code and all GPL

IMO, that's not a desirable outcome. It would be much better
to have his contributions under LGPL. 




> [...]
> > > 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.
> >
> > That's the wrong question and the most unlikely outcome at all.
> > Instead, ask him what he wants, under which conditions he could possibly
> > imagine to stream code back-and-forth between projects, maybe mention
> > the suggestion I made. It says 'n' and there's a wide range of possible
> > values for that n.
> 
> i see no advantage for us to agree to n>0
> It gives Paul an advantage but theres nothing we gain from it

There is: having the code as LGPL. 


> But i certainly was and am open to talk with paul.

I'd make at least an attempt before going the hard way.


> > And when you really need something, you can still cherry-pick it anyway.
> 
> but we dont really contaminate anything with GPL code

Okay, so if all this will just remain in "almpeg" with GPL - what's the 
benefit?
He appears to be updating regularly from FFmpeg, so if I would want 
FFmpeg + his work under GPL - then I could use his project directly - no?

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

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 1168 bytes --]

Hi sw

On Mon, May 26, 2025 at 05:56:06PM +0000, softworkz . wrote:
[...]

> > But i certainly was and am open to talk with paul.
>
> I'd make at least an attempt before going the hard way.

I intended to wait for him to contact me, but sure ill
mail him first then


>
>
> > > And when you really need something, you can still cherry-pick it anyway.
> > 
> > but we dont really contaminate anything with GPL code
> 
> Okay, so if all this will just remain in "almpeg" with GPL - what's the 
> benefit?
> He appears to be updating regularly from FFmpeg, so if I would want 
> FFmpeg + his work under GPL - then I could use his project directly - no?


in what you write, replce GPL by LGPL as in:

> He appears to be updating regularly from FFmpeg, so if I would want
> FFmpeg + his work under LGPL - then I could use his project directly - no?

I mean, you seem to think this argument doesnt work if the license is LGPL
why would it be different with the GPL?

thx

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Michael
> Niedermayer
> Sent: Montag, 26. Mai 2025 23:00
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg
> 
> Hi sw
> 
> On Mon, May 26, 2025 at 05:56:06PM +0000, softworkz . wrote:
> [...]
> 
> > > But i certainly was and am open to talk with paul.
> >
> > I'd make at least an attempt before going the hard way.
> 
> I intended to wait for him to contact me, but sure ill
> mail him first then

┈┈┈┈┈┈▕▔╲
┈┈┈┈┈┈┈▏▕
┈┈┈┈┈┈┈▏▕▂▂▂
▂▂▂▂▂▂╱┈▕▂▂▂▏
▉▉▉▉▉┈┈┈▕▂▂▂▏
▉▉▉▉▉┈┈┈▕▂▂▂▏
▔▔▔▔▔▔╲▂▕▂▂▂▏
⠀   
                          

> > > > And when you really need something, you can still cherry-pick it anyway.
> > >
> > > but we dont really contaminate anything with GPL code
> >
> > Okay, so if all this will just remain in "almpeg" with GPL - what's the
> > benefit?
> > He appears to be updating regularly from FFmpeg, so if I would want
> > FFmpeg + his work under GPL - then I could use his project directly - no?
> 
> 
> in what you write, replce GPL by LGPL as in:
> 
> > He appears to be updating regularly from FFmpeg, so if I would want
> > FFmpeg + his work under LGPL - then I could use his project directly - no?
> 
> I mean, you seem to think this argument doesnt work if the license is LGPL
> why would it be different with the GPL?

Ah yes - that's because it is a built-in "feature" of the LGPL that everybody
is allowed to relicense derivative work from LGPL code under a GPL license.
But it is not allowed to do this in the other direction.
That's what I meant to express by saying that it's a one-way path.

Best,
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".

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of softworkz .
> Sent: Montag, 26. Mai 2025 23:10
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg
> 
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Michael
> > Niedermayer
> > Sent: Montag, 26. Mai 2025 23:00
> > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg
> >
> > Hi sw
> >
> > On Mon, May 26, 2025 at 05:56:06PM +0000, softworkz . wrote:
> > [...]
> >
> > > > But i certainly was and am open to talk with paul.
> > >
> > > I'd make at least an attempt before going the hard way.
> >
> > I intended to wait for him to contact me, but sure ill
> > mail him first then
> 
> ┈┈┈┈┈┈▕▔╲
> ┈┈┈┈┈┈┈▏▕
> ┈┈┈┈┈┈┈▏▕▂▂▂
> ▂▂▂▂▂▂╱┈▕▂▂▂▏
> ▉▉▉▉▉┈┈┈▕▂▂▂▏
> ▉▉▉▉▉┈┈┈▕▂▂▂▏
> ▔▔▔▔▔▔╲▂▕▂▂▂▏
> ⠀
> 
> 
> > > > > And when you really need something, you can still cherry-pick it
> anyway.
> > > >
> > > > but we dont really contaminate anything with GPL code
> > >
> > > Okay, so if all this will just remain in "almpeg" with GPL - what's the
> > > benefit?
> > > He appears to be updating regularly from FFmpeg, so if I would want
> > > FFmpeg + his work under GPL - then I could use his project directly - no?
> >
> >
> > in what you write, replce GPL by LGPL as in:
> >
> > > He appears to be updating regularly from FFmpeg, so if I would want
> > > FFmpeg + his work under LGPL - then I could use his project directly - no?
> >
> > I mean, you seem to think this argument doesnt work if the license is LGPL
> > why would it be different with the GPL?
> 
> Ah yes - that's because it is a built-in "feature" of the LGPL that everybody
> is allowed to relicense derivative work from LGPL code under a GPL license.
> But it is not allowed to do this in the other direction.

Sorry, I falsely assumed this was commonly known (I'm not primarily an OSS guy).
Now, you might probably need to re-read my messages in this thread, because without
knowing about that "one-way" issue, most of what I wrote, won't have made much sense, I fear 😊 

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

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Michael
> Niedermayer
> Sent: Montag, 26. Mai 2025 19:21
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg
> 
> Hi
> 
> On Mon, May 26, 2025 at 12:21:24PM +0000, softworkz . wrote:

[..]

> > I'm not sure how others see it, but I'd rather wait a bit for certain
> > features (as LGPL) than getting the project contaminated with GPL code.
> > And when you really need something, you can still cherry-pick it anyway.
> 
> but we dont really contaminate anything with GPL code

This is also related to the one-way relationship between LGPL and GPL:
Assuming all file headers are properly set up to indicate GPL, when you 
would merge a fix from him into FFmpeg - even when it's for example a filter 
developed by himself earlier and was provided under LGPL - if you merge that 
fix (under GPL) into the FFmpeg filter source file (LGPL), the filter will
no longer be LGPL but turn into GPL by merging the GPL fix.

That's what I mean by saying that FFmpeg would become contaminated by 
GPL code.

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

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 473 bytes --]

Hi

On Sun, May 25, 2025 at 09:22:52PM +0200, Michael Niedermayer wrote:
> Hi all
> 
> Id like to announce that ive setup a repository to merge pauls work of
> the last 2 years.
> 
> * Currently ive merged everything up to first february 2025

another month merged, now up to 1st March 2025

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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

Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg

[Michael Niedermayer]

[-- Attachment #1.1: Type: text/plain, Size: 656 bytes --]

On Mon, May 26, 2025 at 06:36:58PM +0200, Michael Niedermayer wrote:
> Hi
> 
> On Sun, May 25, 2025 at 09:22:52PM +0200, Michael Niedermayer wrote:
> > Hi all
> > 
> > Id like to announce that ive setup a repository to merge pauls work of
> > the last 2 years.
> > 
> > * Currently ive merged everything up to first february 2025
> 
> another month merged, now up to 1st March 2025

another month merged, now up to 1st April 2025

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

[-- Attachment #2: Type: text/plain, Size: 251 bytes --]

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