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

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

[Michael Niedermayer]

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

Hi all

almpeg is now merged upto 1 months ago. (and since last merge it contains
bits of AGPL code)

The question now is, how does the community want to proceed from here?

I think there are mainly 2 options

1. People review almpeg/master, fix any issues they want fixed, change anything
   they want changed and then we just "git merge" it.

2a. People cherry pick individual commits one by one and or diff between
    almpeg and mainline and post these for review like any other patches
2b. People review these patches
2c. patches or almpeg is updated according to reviews and this is repeated
    until everyone is happy
2d. patches are applied to mainline and the diff between almpeg and mainline
    decreases. (so one can always consider diff hunks to be things that need
    to be worked on either update almpeg to mainline or mainline to almpeg)

I do intend to post a small set of patches from almpeg so we can
see how the cherry picking style method would work.
How merging would look you can basically see in almpeg/master already

Into which of the 2 options would you be more eager to put your time?
(I think it really matters where you want to put your time not so
much where you want others to put their time ...)

PS: also theres STF, is someone interrested in doing more patch reviews when it
is payed ? If so, say something, i think we either way need more reviewers and
STF would be one way to incentivize more reviewing

PS2: yes we can vote about cherry pick vs merge if people want but i suspect
its more a question about will and time than vote.

thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What is kyc? Its a tool that makes you give out your real ID, while criminals
give out a forged ID card.

[-- 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] [RFC] Cherry picks vs merges

[Kieran Kunhya via ffmpeg-devel]

On Sun, 1 Jun 2025, 16:22 Michael Niedermayer, <michael@niedermayer.cc>
wrote:

> Hi all
>
> almpeg is now merged upto 1 months ago. (and since last merge it contains
> bits of AGPL code)
>
> The question now is, how does the community want to proceed from here?
>
> I think there are mainly 2 options
>
> 1. People review almpeg/master, fix any issues they want fixed, change
> anything
>    they want changed and then we just "git merge" it.
>
> 2a. People cherry pick individual commits one by one and or diff between
>     almpeg and mainline and post these for review like any other patches
> 2b. People review these patches
> 2c. patches or almpeg is updated according to reviews and this is repeated
>     until everyone is happy
> 2d. patches are applied to mainline and the diff between almpeg and
> mainline
>     decreases. (so one can always consider diff hunks to be things that
> need
>     to be worked on either update almpeg to mainline or mainline to almpeg)
>
> I do intend to post a small set of patches from almpeg so we can
> see how the cherry picking style method would work.
> How merging would look you can basically see in almpeg/master already
>
> Into which of the 2 options would you be more eager to put your time?
> (I think it really matters where you want to put your time not so
> much where you want others to put their time ...)
>
> PS: also theres STF, is someone interrested in doing more patch reviews
> when it
> is payed ? If so, say something, i think we either way need more reviewers
> and
> STF would be one way to incentivize more reviewing
>
> PS2: yes we can vote about cherry pick vs merge if people want but i
> suspect
> its more a question about will and time than vote.
>

Librempeg has this licence statement:

All Librempeg modifications, and any new files not available in FFmpeg, are
licensed under GPL v2, unless stated otherwise.

So how do you plan to merge?

Kieran

>
_______________________________________________
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] [RFC] Cherry picks vs merges

[James Almer]

[-- Attachment #1.1.1: Type: text/plain, Size: 437 bytes --]

On 6/1/2025 12:22 PM, Michael Niedermayer wrote:
> Hi all
> 
> almpeg is now merged upto 1 months ago. (and since last merge it contains
> bits of AGPL code)
> 
> The question now is, how does the community want to proceed from here?
Full stop.

Not only you're trying to bypass explicit a license notice on 
technicalities, but also doing something that will further piss off Paul 
instead of convincing him to come back.


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 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] [RFC] Cherry picks vs merges

[Michael Niedermayer]

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

Hi James

On Sun, Jun 01, 2025 at 02:27:37PM -0300, James Almer wrote:
> On 6/1/2025 12:22 PM, Michael Niedermayer wrote:
> > Hi all
> > 
> > almpeg is now merged upto 1 months ago. (and since last merge it contains
> > bits of AGPL code)
> > 
> > The question now is, how does the community want to proceed from here?
> Full stop.
> 

> Not only you're trying to bypass explicit a license notice on
> technicalities,

This is a serious accusation.

Code is either under the LGPL license or it is not.
It cannot be sometimes under the LGPL license, the license headers
on the files in question, distrinbuted by Paul are unmodified
LGPL headers. There is no extra notice or anything in these headers.

If paul wants them to be GPL he can change these headers at any time.

And the "explicit license notice" you refer to is this:

"All Librempeg modifications, and any new files not available in FFmpeg, are licensed under GPL v2,
 unless stated otherwise."

And it IS stated otherwise in these files by the license header in these
files.

That said, with open source and free software it is the morally correct
thing, if one makes changes to code, to return these changes to the parent
project under the same license as the parent project.
This is morally the ONLY correct thing one can do.

The technicality is that one can change the LGPL to a GPL or AGPL.
The purpose of this is allowing to combine LGPL with GPL or AGPL
NOT to fork a project and prevent the parent project and its users
from having access to the modifications.

You can listen to some interviews by linus torvalds if you think
my point here is crazy.
I will reply to the rest of your mail seperately to keep this from becoming
too long

But one thing id like to mention here, your accusation escalates this
in a way that could reduce the chance of paul returning. And
I tried my best and i talked (emailed) with paul in the last days.
You knew i was working on this and i would have appreciated a private
message over a public accusation

thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus

[-- 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] [RFC] Cherry picks vs merges

[compn]

On Sun, 1 Jun 2025 21:23:20 +0200, Michael Niedermayer wrote:

> Hi James
> 
> On Sun, Jun 01, 2025 at 02:27:37PM -0300, James Almer wrote:
> > On 6/1/2025 12:22 PM, Michael Niedermayer wrote:  
> > > Hi all
> > > 
> > > almpeg is now merged upto 1 months ago. (and since last merge it contains
> > > bits of AGPL code)
> > > 
> > > The question now is, how does the community want to proceed from here?  
> > Full stop.
> >   
> 
> > Not only you're trying to bypass explicit a license notice on
> > technicalities,  
> 
> Code is either under the LGPL license or it is not.
> It cannot be sometimes under the LGPL license, the license headers
> on the files in question, distrinbuted by Paul are unmodified
> LGPL headers. There is no extra notice or anything in these headers.
> 
> If paul wants them to be GPL he can change these headers at any time.
> 
> And the "explicit license notice" you refer to is this:
> 
> "All Librempeg modifications, and any new files not available in FFmpeg, are licensed under GPL v2,
>  unless stated otherwise."
> 
> And it IS stated otherwise in these files by the license header in these
> files.

yes, see for example baptiste's ffmbc fork where he explicitly changed
the license in all files to GPLv2  https://github.com/bcoudurier/FFmbc

Also, please everyone, stop speaking for Paul and let him speak for
himself. if he wants to.

Developers leave, come back, and leave again. its a project made up of
volunteers. No one is forced to join and forced to stay forever.

-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] [RFC] Cherry picks vs merges

[James Almer]

[-- Attachment #1.1.1: Type: text/plain, Size: 2851 bytes --]

On 6/1/2025 4:23 PM, Michael Niedermayer wrote:
> Hi James
> 
> On Sun, Jun 01, 2025 at 02:27:37PM -0300, James Almer wrote:
>> On 6/1/2025 12:22 PM, Michael Niedermayer wrote:
>>> Hi all
>>>
>>> almpeg is now merged upto 1 months ago. (and since last merge it contains
>>> bits of AGPL code)
>>>
>>> The question now is, how does the community want to proceed from here?
>> Full stop.
>>
> 
>> Not only you're trying to bypass explicit a license notice on
>> technicalities,
> 
> This is a serious accusation.
> 
> Code is either under the LGPL license or it is not.
> It cannot be sometimes under the LGPL license, the license headers
> on the files in question, distrinbuted by Paul are unmodified
> LGPL headers. There is no extra notice or anything in these headers.
> 
> If paul wants them to be GPL he can change these headers at any time.
> 
> And the "explicit license notice" you refer to is this:
> 
> "All Librempeg modifications, and any new files not available in FFmpeg, are licensed under GPL v2,
>   unless stated otherwise."
> 
> And it IS stated otherwise in these files by the license header in these
> files.

This is the technicality i was talking about. The fact he copy-pasted a 
boilerplate LGPL header in all new files being used as a way to invoke 
the "unless stated otherwise" part of the notice.

I'm not against merging his changes, and i apologize if what i said 
before sounded like an accusation, but the way i want this to go forward 
is with him being ok with it, and not us trying to find a way to 
workaround what was seemingly his intention to license his changes a 
certain way.

> 
> That said, with open source and free software it is the morally correct
> thing, if one makes changes to code, to return these changes to the parent
> project under the same license as the parent project.
> This is morally the ONLY correct thing one can do.
> 
> The technicality is that one can change the LGPL to a GPL or AGPL.
> The purpose of this is allowing to combine LGPL with GPL or AGPL
> NOT to fork a project and prevent the parent project and its users
> from having access to the modifications.
> 
> You can listen to some interviews by linus torvalds if you think
> my point here is crazy.
> I will reply to the rest of your mail seperately to keep this from becoming
> too long
> 
> But one thing id like to mention here, your accusation escalates this
> in a way that could reduce the chance of paul returning. And
> I tried my best and i talked (emailed) with paul in the last days.
> You knew i was working on this and i would have appreciated a private
> message over a public accusation

Paul showed up on IRC a week or so ago and said you did not email him. 
If that changed in the last couple days, why didn't you or him mention it?


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 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] [RFC] Cherry picks vs merges

[Michael Niedermayer]

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

Hi James

On Sun, Jun 01, 2025 at 05:01:09PM -0300, James Almer wrote:
> On 6/1/2025 4:23 PM, Michael Niedermayer wrote:
> > Hi James
> > 
> > On Sun, Jun 01, 2025 at 02:27:37PM -0300, James Almer wrote:
> > > On 6/1/2025 12:22 PM, Michael Niedermayer wrote:
> > > > Hi all
> > > > 
> > > > almpeg is now merged upto 1 months ago. (and since last merge it contains
> > > > bits of AGPL code)
> > > > 
> > > > The question now is, how does the community want to proceed from here?
> > > Full stop.
> > > 
> > 
> > > Not only you're trying to bypass explicit a license notice on
> > > technicalities,
> > 
> > This is a serious accusation.
> > 
> > Code is either under the LGPL license or it is not.
> > It cannot be sometimes under the LGPL license, the license headers
> > on the files in question, distrinbuted by Paul are unmodified
> > LGPL headers. There is no extra notice or anything in these headers.
> > 
> > If paul wants them to be GPL he can change these headers at any time.
> > 
> > And the "explicit license notice" you refer to is this:
> > 
> > "All Librempeg modifications, and any new files not available in FFmpeg, are licensed under GPL v2,
> >   unless stated otherwise."
> > 
> > And it IS stated otherwise in these files by the license header in these
> > files.
> 
> This is the technicality i was talking about. The fact he copy-pasted a
> boilerplate LGPL header in all new files being used as a way to invoke the
> "unless stated otherwise" part of the notice.
> 

> I'm not against merging his changes, and i apologize if what i said before
> sounded like an accusation, but the way i want this to go forward is with
> him being ok with it, and not us trying to find a way to workaround what was
> seemingly his intention to license his changes a certain way.

If Paul and everyone agrees, of course thats better and I would prefer that too.

But also keep in mind he didnt ask us if he can take our LGPL code.


> 
> > 
> > That said, with open source and free software it is the morally correct
> > thing, if one makes changes to code, to return these changes to the parent
> > project under the same license as the parent project.
> > This is morally the ONLY correct thing one can do.
> > 
> > The technicality is that one can change the LGPL to a GPL or AGPL.
> > The purpose of this is allowing to combine LGPL with GPL or AGPL
> > NOT to fork a project and prevent the parent project and its users
> > from having access to the modifications.
> > 
> > You can listen to some interviews by linus torvalds if you think
> > my point here is crazy.
> > I will reply to the rest of your mail seperately to keep this from becoming
> > too long
> > 
> > But one thing id like to mention here, your accusation escalates this
> > in a way that could reduce the chance of paul returning. And
> > I tried my best and i talked (emailed) with paul in the last days.
> > You knew i was working on this and i would have appreciated a private
> > message over a public accusation
> 
> Paul showed up on IRC a week or so ago and said you did not email him. If
> that changed in the last couple days, why didn't you or him mention it?

The dates & subject of the mails i sent to paul:
80754  sF 0527  0:26 To Paul B Mahol (1,4K) Collaboration and Contributions to FFmpeg
80755  sF 0527  1:42 To Paul B Mahol (1,8K) Re: Collaboration and Contributions to FFmpeg
80757  sF 0527 14:05 To Paul B Mahol (2,6K) Re: Collaboration and Contributions to FFmpeg
80759  sF 0527 15:30 To Paul B Mahol (6,2K) Re: Collaboration and Contributions to FFmpeg
80780  sF 0529 22:15 To Paul B Mahol (2,5K) Re: Collaboration and Contributions to FFmpeg

I also received replies from him between these

He was pissed that he was not considered / contacted by fflabs. I showed him a small
part of a private mail that i sent to jb in 2016. Where paul was #2 of the people
i recommanded for FFlabs.

My last mail (only the part i wrote) (and this mail remains unawnsered as of today):

I cannot read your mind, if there is something that you want,
you have to tell me, what you want.

One thing i can propose, is that you could become libavfilter subsystem
maintainer. This would give you authority in libavfilter.

About FFlabs, if you want to join FFlabs, you have to say so.
What i can say is, that i will support that and i expect that this
request would be successfull.

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The difference between a dictatorship and a democracy is that every 4 years
the population together is allowed to provide 1 bit of input to the government.

[-- 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] [RFC] Cherry picks vs merges

[Kieran Kunhya via ffmpeg-devel]

On Sun, 1 Jun 2025, 20:23 Michael Niedermayer, <michael@niedermayer.cc>
wrote:

> Hi James
>
> On Sun, Jun 01, 2025 at 02:27:37PM -0300, James Almer wrote:
> > On 6/1/2025 12:22 PM, Michael Niedermayer wrote:
> > > Hi all
> > >
> > > almpeg is now merged upto 1 months ago. (and since last merge it
> contains
> > > bits of AGPL code)
> > >
> > > The question now is, how does the community want to proceed from here?
> > Full stop.
> >
>
> > Not only you're trying to bypass explicit a license notice on
> > technicalities,
>
> This is a serious accusation.
>

Changing the licence based on a technicality (that would not stand up in
court) is also a serious step.

FFmpeg should get legal advice before doing this and there should be a vote.

I am astonished how flippantly this is being treated.

Kieran
_______________________________________________
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] [RFC] Cherry picks vs merges

[Baptiste Coudurier]

> On Jun 1, 2025, at 2:55 PM, Kieran Kunhya via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> 
> On Sun, 1 Jun 2025, 20:23 Michael Niedermayer, <michael@niedermayer.cc>
> wrote:
> 
>> Hi James
>> 
>> On Sun, Jun 01, 2025 at 02:27:37PM -0300, James Almer wrote:
>>> On 6/1/2025 12:22 PM, Michael Niedermayer wrote:
>>>> Hi all
>>>> 
>>>> almpeg is now merged upto 1 months ago. (and since last merge it
>> contains
>>>> bits of AGPL code)
>>>> 
>>>> The question now is, how does the community want to proceed from here?
>>> Full stop.
>>> 
>> 
>>> Not only you're trying to bypass explicit a license notice on
>>> technicalities,
>> 
>> This is a serious accusation.
>> 
> 
> Changing the licence based on a technicality (that would not stand up in
> court) is also a serious step.

It has happened in the past and I don’t think this is a technicality as Compn mentioned :)

Changing the license is mandatory.

> FFmpeg should get legal advice before doing this and there should be a vote.
> 
> I am astonished how flippantly this is being treated.
> 

Well that’s what the courts are for when there is disagreement.

— 
Baptiste Coudurier

_______________________________________________
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] [RFC] Cherry picks vs merges

[Vittorio Giovara]

On Sun, Jun 1, 2025 at 5:32 PM Michael Niedermayer <michael@niedermayer.cc>
wrote:

> > I'm not against merging his changes, and i apologize if what i said
> before
> > sounded like an accusation, but the way i want this to go forward is with
> > him being ok with it, and not us trying to find a way to workaround what
> was
> > seemingly his intention to license his changes a certain way.
>
> If Paul and everyone agrees, of course thats better and I would prefer
> that too.
>

I don't agree.


> But also keep in mind he didnt ask us if he can take our LGPL code.
>

"our" lgpl code? There is no "our" in a copyleft license. There is
authorship that grants permission to use and take the code as needed (and
defined by the license) regardless of us, them, or you.


> > > That said, with open source and free software it is the morally correct
> > > thing, if one makes changes to code, to return these changes to the
> parent
> > > project under the same license as the parent project.
> > > This is morally the ONLY correct thing one can do.
>

Not unless the maintainers of the original project acted in such a way to
split the community irreparably.
It happened a bunch of times in the history of foss, for example with
xfree, libreoffice and so on: the license change prevented "stealing"
contributions and the better codebase with a more mature community took
over. What is morally incorrect is trying to solve a social problem in a
technical way.

At any rate, maybe the TC can intervene and decide what to do?
Thanks
-- 
Vittorio
_______________________________________________
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] [RFC] Cherry picks vs merges

[Marton Balint]

On Sun, 1 Jun 2025, James Almer wrote:

> On 6/1/2025 4:23 PM, Michael Niedermayer wrote:
>>  Hi James
>>
>>  On Sun, Jun 01, 2025 at 02:27:37PM -0300, James Almer wrote:
>>>  On 6/1/2025 12:22 PM, Michael Niedermayer wrote:
>>>>  Hi all
>>>>
>>>>  almpeg is now merged upto 1 months ago. (and since last merge it
>>>>  contains
>>>>  bits of AGPL code)
>>>>
>>>>  The question now is, how does the community want to proceed from here?
>>>  Full stop.
>>>
>>
>>>  Not only you're trying to bypass explicit a license notice on
>>>  technicalities,
>>
>>  This is a serious accusation.
>>
>>  Code is either under the LGPL license or it is not.
>>  It cannot be sometimes under the LGPL license, the license headers
>>  on the files in question, distrinbuted by Paul are unmodified
>>  LGPL headers. There is no extra notice or anything in these headers.
>>
>>  If paul wants them to be GPL he can change these headers at any time.
>>
>>  And the "explicit license notice" you refer to is this:
>>
>>  "All Librempeg modifications, and any new files not available in FFmpeg,
>>  are licensed under GPL v2,
>>    unless stated otherwise."
>>
>>  And it IS stated otherwise in these files by the license header in these
>>  files.
>
> This is the technicality i was talking about. The fact he copy-pasted a 
> boilerplate LGPL header in all new files being used as a way to invoke the 
> "unless stated otherwise" part of the notice.
>
> I'm not against merging his changes, and i apologize if what i said before 
> sounded like an accusation, but the way i want this to go forward is with him 
> being ok with it, and not us trying to find a way to workaround what was 
> seemingly his intention to license his changes a certain way.

+1. Yeah, Paul changing the license was not nice, but ffmpeg as a project 
merging his work against his will would not be nice either, even if it 
might be legally OK, it certainly would not be OK morally.

Regards,
Marton
_______________________________________________
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] [RFC] Cherry picks vs merges

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Marton
> Balint
> Sent: Montag, 2. Juni 2025 09:41
> To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Cherry picks vs merges
> 
> 
> 
> On Sun, 1 Jun 2025, James Almer wrote:
> 
> > On 6/1/2025 4:23 PM, Michael Niedermayer wrote:
> >>  Hi James
> >>
> >>  On Sun, Jun 01, 2025 at 02:27:37PM -0300, James Almer wrote:
> >>>  On 6/1/2025 12:22 PM, Michael Niedermayer wrote:
> >>>>  Hi all
> >>>>
> >>>>  almpeg is now merged upto 1 months ago. (and since last merge it
> >>>>  contains
> >>>>  bits of AGPL code)
> >>>>
> >>>>  The question now is, how does the community want to proceed from here?
> >>>  Full stop.
> >>>
> >>
> >>>  Not only you're trying to bypass explicit a license notice on
> >>>  technicalities,
> >>
> >>  This is a serious accusation.
> >>
> >>  Code is either under the LGPL license or it is not.
> >>  It cannot be sometimes under the LGPL license, the license headers
> >>  on the files in question, distrinbuted by Paul are unmodified
> >>  LGPL headers. There is no extra notice or anything in these headers.
> >>
> >>  If paul wants them to be GPL he can change these headers at any time.
> >>
> >>  And the "explicit license notice" you refer to is this:
> >>
> >>  "All Librempeg modifications, and any new files not available in FFmpeg,
> >>  are licensed under GPL v2,
> >>    unless stated otherwise."
> >>
> >>  And it IS stated otherwise in these files by the license header in these
> >>  files.
> >
> > This is the technicality i was talking about. The fact he copy-pasted a
> > boilerplate LGPL header in all new files being used as a way to invoke the
> > "unless stated otherwise" part of the notice.
> >
> > I'm not against merging his changes, and i apologize if what i said before
> > sounded like an accusation, but the way i want this to go forward is with
> him
> > being ok with it, and not us trying to find a way to workaround what was
> > seemingly his intention to license his changes a certain way.
> 
> +1. Yeah, Paul changing the license was not nice, but ffmpeg as a project
> merging his work against his will would not be nice either, even if it
> might be legally OK, it certainly would not be OK morally.
> 
> Regards,
> Marton
> _______________________________________________

Assuming for a moment, we would not care about moral behavior at all.
(which doesn't mean I don't)

What would happen if we merge everything?

- We would gain 2.5 years of work
- He will change all license headers
- The doors will be closed for all future

That leads to the strategical question: Is it worth doing that?

Well - I don't beiieve so. It requires thinking in longer terms.

We should negotiate and try to find an agreement, also be insisting
when it doesn't lead to an immediate result.

But as there appears to be contact now, we should probably just wait 
for the outcome anyway.

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] [RFC] Cherry picks vs merges

[Michael Niedermayer]

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

Hi all

On Sun, Jun 01, 2025 at 11:31:49PM +0200, Michael Niedermayer wrote:
> Hi James
> 
> On Sun, Jun 01, 2025 at 05:01:09PM -0300, James Almer wrote:
> > On 6/1/2025 4:23 PM, Michael Niedermayer wrote:
> > > Hi James
> > > 
> > > On Sun, Jun 01, 2025 at 02:27:37PM -0300, James Almer wrote:
> > > > On 6/1/2025 12:22 PM, Michael Niedermayer wrote:
[...]
> > > That said, with open source and free software it is the morally correct
> > > thing, if one makes changes to code, to return these changes to the parent
> > > project under the same license as the parent project.
> > > This is morally the ONLY correct thing one can do.
> > > 
> > > The technicality is that one can change the LGPL to a GPL or AGPL.
> > > The purpose of this is allowing to combine LGPL with GPL or AGPL
> > > NOT to fork a project and prevent the parent project and its users
> > > from having access to the modifications.
> > > 
> > > You can listen to some interviews by linus torvalds if you think
> > > my point here is crazy.
> > > I will reply to the rest of your mail seperately to keep this from becoming
> > > too long
> > > 
> > > But one thing id like to mention here, your accusation escalates this
> > > in a way that could reduce the chance of paul returning. And
> > > I tried my best and i talked (emailed) with paul in the last days.
> > > You knew i was working on this and i would have appreciated a private
> > > message over a public accusation
> > 
> > Paul showed up on IRC a week or so ago and said you did not email him. If
> > that changed in the last couple days, why didn't you or him mention it?
> 
> The dates & subject of the mails i sent to paul:
> 80754  sF 0527  0:26 To Paul B Mahol (1,4K) Collaboration and Contributions to FFmpeg
> 80755  sF 0527  1:42 To Paul B Mahol (1,8K) Re: Collaboration and Contributions to FFmpeg
> 80757  sF 0527 14:05 To Paul B Mahol (2,6K) Re: Collaboration and Contributions to FFmpeg
> 80759  sF 0527 15:30 To Paul B Mahol (6,2K) Re: Collaboration and Contributions to FFmpeg
> 80780  sF 0529 22:15 To Paul B Mahol (2,5K) Re: Collaboration and Contributions to FFmpeg
> 
> I also received replies from him between these
> 
> He was pissed that he was not considered / contacted by fflabs. I showed him a small
> part of a private mail that i sent to jb in 2016. Where paul was #2 of the people
> i recommanded for FFlabs.
> 
> My last mail (only the part i wrote) (and this mail remains unawnsered as of today):

Pauls awnsers are inline below:


> 
> I cannot read your mind, if there is something that you want,
> you have to tell me, what you want.
> 
> One thing i can propose, is that you could become libavfilter subsystem
> maintainer. This would give you authority in libavfilter.

"Not interested in such pathetic position."


> 
> About FFlabs, if you want to join FFlabs, you have to say so.
> What i can say is, that i will support that and i expect that this
> request would be successfull.

"Sadly that ship has sailed."


[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued

[-- 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] [RFC] Cherry picks vs merges

[Michael Niedermayer]

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

Hi softworkz

On Mon, Jun 02, 2025 at 08:23:41AM +0000, softworkz . wrote:
> 
> 
> > -----Original Message-----
> > From: ffmpeg-devel <ffmpeg-devel-bounces@ffmpeg.org> On Behalf Of Marton
> > Balint
> > Sent: Montag, 2. Juni 2025 09:41
> > To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [RFC] Cherry picks vs merges
> > 
> > 
> > 
> > On Sun, 1 Jun 2025, James Almer wrote:
> > 
> > > On 6/1/2025 4:23 PM, Michael Niedermayer wrote:
> > >>  Hi James
> > >>
> > >>  On Sun, Jun 01, 2025 at 02:27:37PM -0300, James Almer wrote:
> > >>>  On 6/1/2025 12:22 PM, Michael Niedermayer wrote:
> > >>>>  Hi all
> > >>>>
> > >>>>  almpeg is now merged upto 1 months ago. (and since last merge it
> > >>>>  contains
> > >>>>  bits of AGPL code)
> > >>>>
> > >>>>  The question now is, how does the community want to proceed from here?
> > >>>  Full stop.
> > >>>
> > >>
> > >>>  Not only you're trying to bypass explicit a license notice on
> > >>>  technicalities,
> > >>
> > >>  This is a serious accusation.
> > >>
> > >>  Code is either under the LGPL license or it is not.
> > >>  It cannot be sometimes under the LGPL license, the license headers
> > >>  on the files in question, distrinbuted by Paul are unmodified
> > >>  LGPL headers. There is no extra notice or anything in these headers.
> > >>
> > >>  If paul wants them to be GPL he can change these headers at any time.
> > >>
> > >>  And the "explicit license notice" you refer to is this:
> > >>
> > >>  "All Librempeg modifications, and any new files not available in FFmpeg,
> > >>  are licensed under GPL v2,
> > >>    unless stated otherwise."
> > >>
> > >>  And it IS stated otherwise in these files by the license header in these
> > >>  files.
> > >
> > > This is the technicality i was talking about. The fact he copy-pasted a
> > > boilerplate LGPL header in all new files being used as a way to invoke the
> > > "unless stated otherwise" part of the notice.
> > >
> > > I'm not against merging his changes, and i apologize if what i said before
> > > sounded like an accusation, but the way i want this to go forward is with
> > him
> > > being ok with it, and not us trying to find a way to workaround what was
> > > seemingly his intention to license his changes a certain way.
> > 
> > +1. Yeah, Paul changing the license was not nice, but ffmpeg as a project
> > merging his work against his will would not be nice either, even if it
> > might be legally OK, it certainly would not be OK morally.
> > 
> > Regards,
> > Marton
> > _______________________________________________
> 
> Assuming for a moment, we would not care about moral behavior at all.
> (which doesn't mean I don't)
> 
> What would happen if we merge everything?
> 

> - We would gain 2.5 years of work

yes, thats true
if we merge back improvments we gain these improvments, thats always
true for every improvment.


> - He will change all license headers

Everyone who forked can change all license headers
2 years ago, 1 year ago, today, tomorrow, in a year or never.

The license one chooses certainly has an impact on them

What exact impact does this have on us ?
we merge new codecs and filters (that we otherwise do not have) with GPL
headers and conditional on --enable-gpl

We can still provide every codec or filter where someone made significant
improvments under GPL as a seperate filter or codec


> - The doors will be closed for all future

As i predicted elsewhere privately, I do not belive Paul will return
unless his fork fails.
The more successfull his fork is, the less likely it is that he will
return

Also its like 18 months since paul forked and the way he speaks really
doesnt sound like he intends to return currently. We have a ship that
we need to sail we cant keep looking at a new competitor thats moving
ahead hoping he will turn around and join us.
We have to accelerate. He will join us when he falls behind
not when he is ahead.

thx

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates

[-- 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] [RFC] Cherry picks vs merges

[Rémi Denis-Courmont]

Hi,


>If paul wants them to be GPL he can change these headers at any time.

I agree with your implication that Paul *should* have modified the license headers either globally or as he modified files.

But that does not make the top-level license statement moot.

>And the "explicit license notice" you refer to is this:
>
>"All Librempeg modifications, and any new files not available in FFmpeg, are licensed under GPL v2,
> unless stated otherwise."

So, which of his "modifications" (commits) have an explicit statement "otherwise"? I guess none or almost none.

What do you think designates "all Librempeg modifications" and *not* "any new [file] not available in FFmpeg" in the text above?

Would you consider that any file that we add to FFmpeg post-fork would automatically void the license text about "new files", since those files would no longer be "not available in FFmpeg"?

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

If we are going to nit-pick the licensing terms, then Paul is arguably violating the LGPL/GPL in those files by not clearly recording the modifications and their license.

In other words, if we were ridiculously literal about it, Librempeg would be illegal, thus Almpeg would be illegal, and thus we couldn't merge any of this anyway.

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

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.

>That said, with open source and free software it is the morally correct
>thing, if one makes changes to code, to return these changes to the parent
>project under the same license as the parent project.
>This is morally the ONLY correct thing one can do.

That's a very overreaching generalisation. If  I start an LGPL project with a generous sponsor giving me Bay area level pay for the effort, and someone forks it into GPL in their free time, I fail to see how that would be immoral.

This is no different than a downstream project utilising a library under a less permissive license than the library.

In fact, I believe FFmpeg itself contains some code that was relicensed from liberal licenses and yet we didn't systematically feed the changes back, did we?

>You knew i was working on this and i would have appreciated a private
>message over a public accusation

That's not fair. You were given advisory warnings by people as they learnt of this and on the same channel as you informed of this (this ML), including by myself.

You had every right to dispose of your time and carry on but you can't say that you were not warned.
_______________________________________________
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] [RFC] Cherry picks vs merges

[Kieran Kunhya via ffmpeg-devel]

>
> > - The doors will be closed for all future
>
> As i predicted elsewhere privately, I do not belive Paul will return
> unless his fork fails.
> The more successfull his fork is, the less likely it is that he will
> return
>
> Also its like 18 months since paul forked and the way he speaks really
> doesnt sound like he intends to return currently. We have a ship that
> we need to sail we cant keep looking at a new competitor thats moving
> ahead hoping he will turn around and join us.
> We have to accelerate. He will join us when he falls behind
> not when he is ahead.
>

What a "friendly" way to talk about the biggest developer of the last
decade in FFmpeg.

All the talk here about how important it is to work on things for fun and
when someone goes and does it, he is treated as a "competitor".

Not to mention emailed with text clearly from ChatGPT.

Kieran
_______________________________________________
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] [RFC] Cherry picks vs merges

[Michael Niedermayer]

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

Hi Remi

On Mon, Jun 02, 2025 at 06:38:54PM +0300, Rémi Denis-Courmont wrote:
[...]
> >And the "explicit license notice" you refer to is this:
> >
> >"All Librempeg modifications, and any new files not available in FFmpeg, are licensed under GPL v2,
> > unless stated otherwise."
> 
> 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


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


[...]

> 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


> 
> 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.
The "unless stated otherwise" excempts the AGPL code from receiving the GPL v2

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


[...]

> In fact, I believe FFmpeg itself contains some code that was relicensed from liberal licenses and yet we didn't systematically feed the changes back, did we?

If we did not, we should do that.


> 
> >You knew i was working on this and i would have appreciated a private
> >message over a public accusation
> 
> That's not fair.

all members of fflabs where aware of it as i asked about the license situation it in the private
fflabs IRC channel. I asked there because fflabs/jb has a lawyer

[...]

thx

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

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.

[-- 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] [RFC] Cherry picks vs merges

[Kieran Kunhya via ffmpeg-devel]

>
> all members of fflabs where aware of it as i asked about the license
> situation it in the private
> fflabs IRC channel. I asked there because fflabs/jb has a lawyer
>

Do you understand that the lawyer of FFlabs represents the interests of
FFlabs and does not represent the interests of FFmpeg?

Kieran

>
_______________________________________________
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] [RFC] Cherry picks vs merges

[Michael Niedermayer]

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

Hi

On Tue, Jun 03, 2025 at 11:38:11PM +0100, Kieran Kunhya via ffmpeg-devel wrote:
> >
> > all members of fflabs where aware of it as i asked about the license
> > situation it in the private
> > fflabs IRC channel. I asked there because fflabs/jb has a lawyer
> >
> 
> Do you understand that the lawyer of FFlabs represents the interests of
> FFlabs and does not represent the interests of FFmpeg?

I understand that if i hire a lawyer, he would represent my interrests
If i ask SPI (which i did as well), they would represent SPI interrests

FFmpeg cannot hire a lawyer. So its easy to complain that it didnt

FFlabs depends on FFmpeg so its interrests in terms of FFmpeg complying
to all laws should be aligned here

And you are at the same level here, you can ask any lawyer you want.

thx

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

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin

[-- 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] [RFC] Cherry picks vs merges

[Kieran Kunhya via ffmpeg-devel]

> FFlabs depends on FFmpeg so its interrests in terms of FFmpeg complying
> to all laws should be aligned here

Interesting, so the person that complains about FFlabs having too much
corporate control over FFmpeg is now ok to assume FFlabs legal opinion
"align[ing]" with FFmpeg.


Kieran
_______________________________________________
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] [RFC] Cherry picks vs merges

[compn]

On Mon, 2 Jun 2025 08:23:41 +0000, softworkz . wrote:

> What would happen if we merge everything?
> 
> - We would gain 2.5 years of work
> - He will change all license headers
> - The doors will be closed for all future

there is no door closed forever. gplv2 code is still open source and
ffmpeg has many files with gplv2 copyright.

licensing between lgpl and gplv2 only really affects people who
sell/distribute ffmpeg.

since people who sell ffmpeg want a different license, they can pay to
have an author relicense their work. which has happened many times in
ffmpeg's 20+year history.

-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] [RFC] Cherry picks vs merges

[Rémi Denis-Courmont]

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

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

[Tomas Härdin]

sön 2025-06-01 klockan 21:23 +0200 skrev Michael Niedermayer:
> And the "explicit license notice" you refer to is this:
> 
> "All Librempeg modifications, and any new files not available in
> FFmpeg, are licensed under GPL v2,
>  unless stated otherwise."
> 
> And it IS stated otherwise in these files by the license header in
> these
> files.

These conflicting texts are reason enough not to touch this code unless
we're fine with upgrading the license to GPLv2. I don't think the
project should get into a legal fight over something like this

Given how everything has moved to the cloud, upgrading to GPLv2
wouldn't necessarily be a bad thing. We should also consider upgrading
the fftools to AGPL for the same reason

> That said, with open source and free software it is the morally
> correct
> thing, if one makes changes to code, to return these changes to the
> parent
> project under the same license as the parent project.
> This is morally the ONLY correct thing one can do.

This is incredibly spooked. Paul plays the license game the way he sees
fit, as does everyone else

> The technicality is that one can change the LGPL to a GPL or AGPL.
> The purpose of this is allowing to combine LGPL with GPL or AGPL
> NOT to fork a project and prevent the parent project and its users
> from having access to the modifications.

Only users that want to downgrade the license are prevented from doing
so. I'm sure Paul is also aware of the concept of license trolling

/Tomas
_______________________________________________
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] [RFC] Cherry picks vs merges

[Baptiste Coudurier]

> On Jun 4, 2025, at 11:06 AM, Tomas Härdin <git@haerdin.se> wrote:
> 
> sön 2025-06-01 klockan 21:23 +0200 skrev Michael Niedermayer:
>> And the "explicit license notice" you refer to is this:
>> 
>> "All Librempeg modifications, and any new files not available in
>> FFmpeg, are licensed under GPL v2,
>>  unless stated otherwise."
>> 
>> And it IS stated otherwise in these files by the license header in
>> these
>> files.
> 
> These conflicting texts are reason enough not to touch this code unless
> we're fine with upgrading the license to GPLv2. I don't think the
> project should get into a legal fight over something like this

There are no legal fights until somebody starts one.
The courts are here to settle disagreements and different understandings.

The fact is that there is even disagreement on whether there is ambiguity
on the way the fork was re-licensed. Interpretation can be subtle.

> Given how everything has moved to the cloud, upgrading to GPLv2
> wouldn't necessarily be a bad thing. We should also consider upgrading
> the fftools to AGPL for the same reason
> 
>> That said, with open source and free software it is the morally
>> correct
>> thing, if one makes changes to code, to return these changes to the
>> parent
>> project under the same license as the parent project.
>> This is morally the ONLY correct thing one can do.
> 
> This is incredibly spooked. Paul plays the license game the way he sees
> fit, as does everyone else

We are also free to play the same license game.

Nonetheless, if the modifications are good, we need to incorporate them in
some way, so what is the alternative proposed ?

New filters and codecs will be added with —enable-gpl, that’s a given.

— 
Baptiste
_______________________________________________
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] [RFC] Cherry picks vs merges

[Michael Niedermayer]

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

On Wed, Jun 04, 2025 at 01:42:42PM -0700, Baptiste Coudurier wrote:
> 
> > On Jun 4, 2025, at 11:06 AM, Tomas Härdin <git@haerdin.se> wrote:
> > 
> > sön 2025-06-01 klockan 21:23 +0200 skrev Michael Niedermayer:
> >> And the "explicit license notice" you refer to is this:
> >> 
> >> "All Librempeg modifications, and any new files not available in
> >> FFmpeg, are licensed under GPL v2,
> >>  unless stated otherwise."
> >> 
> >> And it IS stated otherwise in these files by the license header in
> >> these
> >> files.
> > 
> > These conflicting texts are reason enough not to touch this code unless
> > we're fine with upgrading the license to GPLv2. I don't think the
> > project should get into a legal fight over something like this
> 
> There are no legal fights until somebody starts one.
> The courts are here to settle disagreements and different understandings.
> 
> The fact is that there is even disagreement on whether there is ambiguity
> on the way the fork was re-licensed. Interpretation can be subtle.
> 
> > Given how everything has moved to the cloud, upgrading to GPLv2
> > wouldn't necessarily be a bad thing. We should also consider upgrading
> > the fftools to AGPL for the same reason
> > 
> >> That said, with open source and free software it is the morally
> >> correct
> >> thing, if one makes changes to code, to return these changes to the
> >> parent
> >> project under the same license as the parent project.
> >> This is morally the ONLY correct thing one can do.
> > 
> > This is incredibly spooked. Paul plays the license game the way he sees
> > fit, as does everyone else
> 
> We are also free to play the same license game.
> 
> Nonetheless, if the modifications are good, we need to incorporate them in
> some way, so what is the alternative proposed ?

ATM, iam waiting for jb/fflabs lawyer.
If that reply never comes or is ambigous ill have to pay a lawyer to get
a clear reply.

once that reply is in, we can discuss. And if theres no consensus we
can vote. (mainly merge vs cherry pick but we could vote on license too)

I think most agree that the base license for FFmpeg should stay LGPL
and that new codecs and filters will all be added under the most
permissive license thats possible. But if theres a disagreement
that can be discussed and voted on too.


> 
> New filters and codecs will be added with —enable-gpl, that’s a given.

yes i see it the same way.

about GPL licensed modifications to LGPL code. (assuming anything falls in this
category)

It would just be rethinking from --enable-gpl to "git pull almpeg ...


thx

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin

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