[FFmpeg-devel] [POLL][RFC] Merge vs Cherry pick for integration of changes

[FFmpeg-devel] [POLL][RFC] Merge vs Cherry pick for integration of changes

[Michael Niedermayer via ffmpeg-devel]

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

Hi

Should we use a Merge or Cherry picks for integrating Pauls work ?

Following are 2 plans, as we execute either we may run into issues
and of course adapt them as needed. (or even switch)

Option M:
    This would be a merge of pauls last revission before files where
    switched to GPL and the command line tool to AGPL

    It would include all changes (except what is intentionally skiped)
    (This will look similar to how almpeg looks now)

    Fate tests would be added after the merge where sample media is
    publically available on our server.
    Reviews of Individual modules can be done after the merge where
    people want to do that.

Option C:
    Individual Modules (Codecs, Filters, Demuxers) would be submitted
    as patch(sets)

    This would include only the picked changes. Changes noone picks and
    posts would be missing.

    Each would go through the review process (some likely with "apply
    after timeout"). And during that review fate tests would be added
    where public samples are on our server.

M would likely integrate more changes, C less changes. C may be more work.

We currently have a point on the wiki for STF 2025 that would fund each
integrated module with 900€.
That way, whoever adds fate tests, makes changes the community wants in
a review, fixes bugs found by tests or review, could be funded.

It is possible that teh community adjusts the exact STF task / work / ...
before its deadline.

I think many people have already thought about the merge vs cherry pick
question. (it came up previously on the ML and in the GA) So maybe we can
just vote on it now over the next 8 days. Or if people want more discussion
first, we can do that too. We will see based on peoples replies.
Maybe use the first day to think and sleep over it or a quick discussion
and then vote in the next 7 days.

If you want to vote, please simply reply with "M" or "C" (and of course any
details, why you think thats the better option, if you want to add details)

Otherwise reply with "D" for "more Discussion" and details about what
you want to say/discuss.

thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Some Animals are More Equal Than Others. - George Orwell's book Animal Farm

[-- 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] [POLL][RFC] Merge vs Cherry pick for integration of changes

[Kieran Kunhya via ffmpeg-devel]

On Thu, 21 Aug 2025, 01:32 Michael Niedermayer via ffmpeg-devel, <
ffmpeg-devel@ffmpeg.org> wrote:

> Hi
>
> Should we use a Merge or Cherry picks for integrating Pauls work ?
>
> Following are 2 plans, as we execute either we may run into issues
> and of course adapt them as needed. (or even switch)
>
> Option M:
>     This would be a merge of pauls last revission before files where
>     switched to GPL and the command line tool to AGPL
>
>     It would include all changes (except what is intentionally skiped)
>     (This will look similar to how almpeg looks now)
>
>     Fate tests would be added after the merge where sample media is
>     publically available on our server.
>     Reviews of Individual modules can be done after the merge where
>     people want to do that.
>
> Option C:
>     Individual Modules (Codecs, Filters, Demuxers) would be submitted
>     as patch(sets)
>
>     This would include only the picked changes. Changes noone picks and
>     posts would be missing.
>
>     Each would go through the review process (some likely with "apply
>     after timeout"). And during that review fate tests would be added
>     where public samples are on our server.
>
> M would likely integrate more changes, C less changes. C may be more work.
>
> We currently have a point on the wiki for STF 2025 that would fund each
> integrated module with 900€.
> That way, whoever adds fate tests, makes changes the community wants in
> a review, fixes bugs found by tests or review, could be funded.
>
> It is possible that teh community adjusts the exact STF task / work / ...
> before its deadline.
>
> I think many people have already thought about the merge vs cherry pick
> question. (it came up previously on the ML and in the GA) So maybe we can
> just vote on it now over the next 8 days. Or if people want more discussion
> first, we can do that too. We will see based on peoples replies.
> Maybe use the first day to think and sleep over it or a quick discussion
> and then vote in the next 7 days.
>
> If you want to vote, please simply reply with "M" or "C" (and of course any
> details, why you think thats the better option, if you want to add details)
>
> Otherwise reply with "D" for "more Discussion" and details about what
> you want to say/discuss.
>
> thx
>

D

For the record, Paul had a note saying changes are under GPL. As I
understand you are ignoring legal advice saying this is a valid statement.

Can you confirm the legal advice you were given and that you are ignoring
it?

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] [POLL][RFC] Merge vs Cherry pick for integration of changes

[Michael Niedermayer via ffmpeg-devel]

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

Hi Kieran

On Thu, Aug 21, 2025 at 06:56:14AM -1000, Kieran Kunhya via ffmpeg-devel wrote:
[...]
> For the record, Paul had a note saying changes are under GPL. As I
> understand you are ignoring legal advice saying this is a valid statement.
> 
> Can you confirm the legal advice you were given and that you are ignoring
> it?

We have hired one of the leading copyright / IP law firms / lawyers

And the shortest summary is that code with LGPL headers can be used under LGPL.
The oppinion of the lawyer (which is much longer and more detailed) was
provided to the General Assembly of FFmpeg.

thx

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- 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] [POLL][RFC] Merge vs Cherry pick for integration of changes

[Kieran Kunhya via ffmpeg-devel]

On Thu, 21 Aug 2025, 07:53 Michael Niedermayer via ffmpeg-devel, <
ffmpeg-devel@ffmpeg.org> wrote:

> Hi Kieran
>
> On Thu, Aug 21, 2025 at 06:56:14AM -1000, Kieran Kunhya via ffmpeg-devel
> wrote:
> [...]
> > For the record, Paul had a note saying changes are under GPL. As I
> > understand you are ignoring legal advice saying this is a valid
> statement.
> >
> > Can you confirm the legal advice you were given and that you are ignoring
> > it?
>
> We have hired one of the leading copyright / IP law firms / lawyers
>
> And the shortest summary is that code with LGPL headers can be used under
> LGPL.
> The oppinion of the lawyer (which is much longer and more detailed) was
> provided to the General Assembly of FFmpeg.
>
> thx
>
> [...]
> --
> Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I know you won't believe me, but the highest form of Human Excellence is
> to question oneself and others. -- Socrates
>

This opinion contradicts the FFlabs lawyer which you said you were going to
use and provided a lengthy justification.

So you basically went around lawyers until you got the answer you want.

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] [POLL][RFC] Merge vs Cherry pick for integration of changes

[Niklas Haas via ffmpeg-devel]

On Thu, 21 Aug 2025 13:32:02 +0200 Michael Niedermayer via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> Hi
>
> Should we use a Merge or Cherry picks for integrating Pauls work ?
>
> Following are 2 plans, as we execute either we may run into issues
> and of course adapt them as needed. (or even switch)
>
> Option M:
>     This would be a merge of pauls last revission before files where
>     switched to GPL and the command line tool to AGPL
>
>     It would include all changes (except what is intentionally skiped)
>     (This will look similar to how almpeg looks now)
>
>     Fate tests would be added after the merge where sample media is
>     publically available on our server.
>     Reviews of Individual modules can be done after the merge where
>     people want to do that.
>
> Option C:
>     Individual Modules (Codecs, Filters, Demuxers) would be submitted
>     as patch(sets)
>
>     This would include only the picked changes. Changes noone picks and
>     posts would be missing.
>
>     Each would go through the review process (some likely with "apply
>     after timeout"). And during that review fate tests would be added
>     where public samples are on our server.
>
> M would likely integrate more changes, C less changes. C may be more work.
>
> We currently have a point on the wiki for STF 2025 that would fund each
> integrated module with 900€.
> That way, whoever adds fate tests, makes changes the community wants in
> a review, fixes bugs found by tests or review, could be funded.

D

Since you tagged the GA on this, I am going to go ahead and request that
a formal GA vote, which I assume will be conducted before any action, must
have the option to vote that we respect Paul's request (and arguably, his
legal right) to not merge his work into FFmpeg.

Even if you personally think the risk of Paul litigating FFmpeg in response
is neglible, and are willing to shoulder the potential costs of a legal battle
on your own shoulders, I do not think it sets a good precedent and will be
potentially damaging to the FFmpeg project's public image.

> It is possible that teh community adjusts the exact STF task / work / ...
> before its deadline.

I think that SPI/STF projects should also be voted on by the GA before being
approved for inclusion in the contract proposal.

We already have the infrastructure for this in place, and I am sure that the
majority of the GA members would rather spend 5 minutes of their time
reviewing each project proposal rather than having it handled in an ad-hoc
manner.

The last STF round already received a number of criticisms about lack of
transparency, so I think this would be a step in the right direction.
_______________________________________________
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] [POLL][RFC] Merge vs Cherry pick for integration of changes

[Diederick C. Niehorster via ffmpeg-devel]

On Fri, Aug 22, 2025 at 2:30 PM Niklas Haas via ffmpeg-devel
<ffmpeg-devel@ffmpeg.org> wrote:
>
> On Thu, 21 Aug 2025 13:32:02 +0200 Michael Niedermayer via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> > Hi
> >
> > Should we use a Merge or Cherry picks for integrating Pauls work ?
> >
> > Following are 2 plans, as we execute either we may run into issues
> > and of course adapt them as needed. (or even switch)
> >
> > Option M:
> >     This would be a merge of pauls last revission before files where
> >     switched to GPL and the command line tool to AGPL
> >
> >     It would include all changes (except what is intentionally skiped)
> >     (This will look similar to how almpeg looks now)
> >
> >     Fate tests would be added after the merge where sample media is
> >     publically available on our server.
> >     Reviews of Individual modules can be done after the merge where
> >     people want to do that.
> >
> > Option C:
> >     Individual Modules (Codecs, Filters, Demuxers) would be submitted
> >     as patch(sets)
> >
> >     This would include only the picked changes. Changes noone picks and
> >     posts would be missing.
> >
> >     Each would go through the review process (some likely with "apply
> >     after timeout"). And during that review fate tests would be added
> >     where public samples are on our server.
> >
> > M would likely integrate more changes, C less changes. C may be more work.
> >
> > We currently have a point on the wiki for STF 2025 that would fund each
> > integrated module with 900€.
> > That way, whoever adds fate tests, makes changes the community wants in
> > a review, fixes bugs found by tests or review, could be funded.
>
> D
>
> Since you tagged the GA on this, I am going to go ahead and request that
> a formal GA vote, which I assume will be conducted before any action, must
> have the option to vote that we respect Paul's request (and arguably, his
> legal right) to not merge his work into FFmpeg.
>
> Even if you personally think the risk of Paul litigating FFmpeg in response
> is neglible, and are willing to shoulder the potential costs of a legal battle
> on your own shoulders, I do not think it sets a good precedent and will be
> potentially damaging to the FFmpeg project's public image.
>
> > It is possible that teh community adjusts the exact STF task / work / ...
> > before its deadline.
>
> I think that SPI/STF projects should also be voted on by the GA before being
> approved for inclusion in the contract proposal.
>
> We already have the infrastructure for this in place, and I am sure that the
> majority of the GA members would rather spend 5 minutes of their time
> reviewing each project proposal rather than having it handled in an ad-hoc
> manner.
>
> The last STF round already received a number of criticisms about lack of
> transparency, so I think this would be a step in the right direction.

Absolute and strong +1, this is the better (series of) vote(s) to have.

Thanks Niklas,

All the best,
Dee
_______________________________________________
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] [POLL][RFC] Merge vs Cherry pick for integration of changes

[Michael Niedermayer via ffmpeg-devel]

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

Hi Niklas

On Fri, Aug 22, 2025 at 02:29:56PM +0200, Niklas Haas via ffmpeg-devel wrote:
> On Thu, 21 Aug 2025 13:32:02 +0200 Michael Niedermayer via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> > Hi
> >
> > Should we use a Merge or Cherry picks for integrating Pauls work ?
> >
> > Following are 2 plans, as we execute either we may run into issues
> > and of course adapt them as needed. (or even switch)
> >
> > Option M:
> >     This would be a merge of pauls last revission before files where
> >     switched to GPL and the command line tool to AGPL
> >
> >     It would include all changes (except what is intentionally skiped)
> >     (This will look similar to how almpeg looks now)
> >
> >     Fate tests would be added after the merge where sample media is
> >     publically available on our server.
> >     Reviews of Individual modules can be done after the merge where
> >     people want to do that.
> >
> > Option C:
> >     Individual Modules (Codecs, Filters, Demuxers) would be submitted
> >     as patch(sets)
> >
> >     This would include only the picked changes. Changes noone picks and
> >     posts would be missing.
> >
> >     Each would go through the review process (some likely with "apply
> >     after timeout"). And during that review fate tests would be added
> >     where public samples are on our server.
> >
> > M would likely integrate more changes, C less changes. C may be more work.
> >
> > We currently have a point on the wiki for STF 2025 that would fund each
> > integrated module with 900€.
> > That way, whoever adds fate tests, makes changes the community wants in
> > a review, fixes bugs found by tests or review, could be funded.
> 
> D
> 
> Since you tagged the GA on this, I am going to go ahead and request that
> a formal GA vote, which I assume will be conducted before any action, must
> have the option to vote that we respect Paul's request (and arguably, his
> legal right) to not merge his work into FFmpeg.

This here is a simple (and transparent) vote
Using the mailing list allows people also to discuss and explain their
reasonings (like you did here)

I do think there is value in hearing the reasonings of people and not
just seeing a number of how many are in favor vs against.


[...]

> > It is possible that teh community adjusts the exact STF task / work / ...
> > before its deadline.
> 
> I think that SPI/STF projects should also be voted on by the GA before being
> approved for inclusion in the contract proposal.

That was always possible, people can and could always discuss and object to
proposals.

What we submit to STF should be proposals that have a broad consensus not
51% behind them


> 
> We already have the infrastructure for this in place, and I am sure that the
> majority of the GA members would rather spend 5 minutes of their time
> reviewing each project proposal rather than having it handled in an ad-hoc
> manner.

The infrastructure will tell you what the majority voted for.
Not why
Nor will it lead to a consensus if theres none before

but open discussion can lead to consensus

thx

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

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu

[-- 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] [POLL][RFC] Merge vs Cherry pick for integration of changes

[Rémi Denis-Courmont via ffmpeg-devel]

Le perjantaina 22. elokuuta 2025, 15.59.14 Itä-Euroopan kesäaika Michael 
Niedermayer via ffmpeg-devel a écrit :
> > Since you tagged the GA on this, I am going to go ahead and request that
> > a formal GA vote, which I assume will be conducted before any action, must
> > have the option to vote that we respect Paul's request (and arguably, his
> > legal right) to not merge his work into FFmpeg.
> 
> This here is a simple (and transparent) vote
> Using the mailing list allows people also to discuss and explain their
> reasonings (like you did here)

I think that is common knowledge but here goes...

A public ballot, also known as plebiscite, is by nature a performative 
exercise.

A secret ballot allows people to express their opinion based purely on the 
technical and moral merits without the fear of a bad perception and self-
censorship.

> I do think there is value in hearing the reasonings of people and not
> just seeing a number of how many are in favor vs against.

It's fine to discuss/debate this publicly. That has nothing to do with how to 
decide. In fact, this obviously needs to happen before the *informed* decision 
is made.

As a member of the CC and the GA, I agree with Niklaas that any license change 
needs a GA vote. And obviously that preempts any discussion of how to merge 
the code.

-- 
Rémi Denis-Courmont
Villeneuve de Tapiola, ex-République finlandaise d´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] [POLL][RFC] Merge vs Cherry pick for integration of changes

[Michael Niedermayer via ffmpeg-devel]

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

On Sat, Aug 23, 2025 at 10:09:14AM +0300, Rémi Denis-Courmont via ffmpeg-devel wrote:
[...]
> As a member of the CC and the GA, I agree with Niklaas that any license change
> needs a GA vote. And obviously that preempts any discussion of how to merge 
> the code.

There is no license change.

thx

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato

[-- 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] [POLL][RFC] Merge vs Cherry pick for integration of changes

[Kieran Kunhya via ffmpeg-devel]

On Sat, 23 Aug 2025, 00:58 Michael Niedermayer via ffmpeg-devel, <
ffmpeg-devel@ffmpeg.org> wrote:

> On Sat, Aug 23, 2025 at 10:09:14AM +0300, Rémi Denis-Courmont via
> ffmpeg-devel wrote:
> [...]
> > As a member of the CC and the GA, I agree with Niklaas that any license
> change
> > needs a GA vote. And obviously that preempts any discussion of how to
> merge
> > the code.
>
> There is no license change.
>
> thx
>

The FFlabs lawyer did not see it that way.

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] [POLL][RFC] Merge vs Cherry pick for integration of changes

[Michael Niedermayer via ffmpeg-devel]

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

Hi Niklas

On Fri, Aug 22, 2025 at 02:29:56PM +0200, Niklas Haas via ffmpeg-devel wrote:
> On Thu, 21 Aug 2025 13:32:02 +0200 Michael Niedermayer via ffmpeg-devel <ffmpeg-devel@ffmpeg.org> wrote:
> > Hi
> >
> > Should we use a Merge or Cherry picks for integrating Pauls work ?
> >
> > Following are 2 plans, as we execute either we may run into issues
> > and of course adapt them as needed. (or even switch)
> >
> > Option M:
> >     This would be a merge of pauls last revission before files where
> >     switched to GPL and the command line tool to AGPL
> >
> >     It would include all changes (except what is intentionally skiped)
> >     (This will look similar to how almpeg looks now)
> >
> >     Fate tests would be added after the merge where sample media is
> >     publically available on our server.
> >     Reviews of Individual modules can be done after the merge where
> >     people want to do that.
> >
> > Option C:
> >     Individual Modules (Codecs, Filters, Demuxers) would be submitted
> >     as patch(sets)
> >
> >     This would include only the picked changes. Changes noone picks and
> >     posts would be missing.
> >
> >     Each would go through the review process (some likely with "apply
> >     after timeout"). And during that review fate tests would be added
> >     where public samples are on our server.
> >
> > M would likely integrate more changes, C less changes. C may be more work.
> >
> > We currently have a point on the wiki for STF 2025 that would fund each
> > integrated module with 900€.
> > That way, whoever adds fate tests, makes changes the community wants in
> > a review, fixes bugs found by tests or review, could be funded.
> 
> D
> 
> Since you tagged the GA on this, I am going to go ahead and request that
> a formal GA vote, which I assume will be conducted before any action, must
> have the option to vote that we respect Paul's request (and arguably, his
> legal right) to not merge his work into FFmpeg.
> 
> Even if you personally think the risk of Paul litigating FFmpeg in response
> is neglible, and are willing to shoulder the potential costs of a legal battle
> on your own shoulders, I do not think it sets a good precedent and will be
> potentially damaging to the FFmpeg project's public image.

So, lets just make a thought-experiment

1. Mr X forks FFmpeg.
2. Mr X merges Pauls (LGPL) code
3. Mr X adds everything he finds cool or inovative
4. Mr X maintains his fork and stops maintaining anything in FFmpeg
5. Mr X daily merges ffmpeg improvments (and maybe pauls if his code is GPL)
6. Mr X nicely tell FFmpeg that he objects to FFmpeg merging his code ;) ;) ;))))

will ffmpeg comply to this request ?

What if I join these forks, you know each of the forks will take ffmpeg
code and each others work. (within the bounds of each ones licenses)

FFmpeg will not integrate any improvments back ?

Thats how you suggest FFmpeg should be run ?

how could that work ?

thx

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

It is what and why we do it that matters, not just one of them.

[-- 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] [POLL][RFC] Merge vs Cherry pick for integration of changes

[Michael Niedermayer via ffmpeg-devel]

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

Hi

On Thu, Aug 21, 2025 at 01:32:02PM +0200, Michael Niedermayer via ffmpeg-devel wrote:
> Hi
> 
> Should we use a Merge or Cherry picks for integrating Pauls work ?
> 
> Following are 2 plans, as we execute either we may run into issues
> and of course adapt them as needed. (or even switch)

If neither Cherry picking nor Merging is choosen then I will remove
my STF proposal about that work before 1. September (unless the deadline
is extended).

Without that funding, i cannot offer going through individual modules.
That means someone else would need to volunteer doing this work
to have the "Cherry pick" option in the future.
(also consider code divergence with a future funding round)

For the "Merge" option, similarly, the loss of STF funding would mean a loss
of (funded) "per module" work. "Merge" will stay available from me but without
per module work. (someone else would have to do per module work, or no per module
work would be done)

OTOH with the Integration of pauls code, i will spend more time on FFmpeg
in the next 12 months, i would continue doing the fuzzing work as good as i
can and i will try to get the 8.1 release done in the next 3 months if people
want that.
Without the integration of the code, I will likely loose alot of my motivation
to contribute.

I hope "D" (if its choosen) will stand for Discussion and not Decline or even
eventual Death of FFmpeg.

thx

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- 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] Legal Advice Was: [POLL][RFC] Merge vs Cherry pick for integration of changes

[Michael Niedermayer via ffmpeg-devel]

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

Hi

Here is the legal advice that i was given.
The GA has the full text and that is much more detailed.
Iam posting the relevant parts so the whole community can see it.

"a claim that there is GPLv2 code in a file of
 FFmpeg origin that has the LGPLv2.1 license would be a breach of the FFmpeg's
 LGPLv2.1 license. While section 3 of the LGPLv2.1 would have allowed him to
 take the original FFmpeg files and change the license for them to GPLv2, he
 didn't follow the necessary steps to effectively change the license. So the
 original code he is building from is still under LGPLv2.1. Since code
 contributions to a copyleft work have to be under the /same /license as the
 code you are contributing to (Section 2(c), "You must cause the whole of the
 work to be licensed at no charge to all third parties under the terms of this
 License"), Paul's contributions to LGPLv2.1 files are under the LGPLv2.1
 license because he didn't exercise the option to change them to GPLv2 first. A
 claim otherwise would be admitting he is in breach of the FFmpeg license."

"You can safely assume that any new file he created with a license
 identifier in the file of LGPLv.2.1 is under the LGPLv2.1 license."

"Paul's response to your use of his code may be to relicense his code under
 the AGPL,* but he cannot change the license retroactively - you would have to
 accommodate the AGPL license for any later changes you adopt, but not for any
 code you are using from before a license change."

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- 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".