Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
 help / color / mirror / Atom feed
From: "softworkz ." <softworkz-at-hotmail.com@ffmpeg.org>
To: FFmpeg development discussions and patches <ffmpeg-devel@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [ANNOUNCEMENT] almpeg
Date: Mon, 26 May 2025 12:21:24 +0000
Message-ID: <DM8P223MB03654A6411F2CAF32AAC9729BA65A@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <20250526113726.GQ29660@pb2>



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

  parent reply	other threads:[~2025-05-26 12:21 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-25 19:22 Michael Niedermayer
2025-05-25 22:29 ` Kieran Kunhya via ffmpeg-devel
2025-05-25 23:11   ` compn
2025-05-26  8:00 ` Rémi Denis-Courmont
2025-05-26  9:27   ` softworkz .
2025-05-26 11:26     ` Rémi Denis-Courmont
2025-05-26 11:44       ` softworkz .
2025-05-26 11:37     ` Michael Niedermayer
2025-05-26 11:49       ` softworkz .
2025-05-26 12:21       ` softworkz . [this message]
2025-05-26 17:21         ` Michael Niedermayer
2025-05-26 17:56           ` softworkz .
2025-05-26 20:59             ` Michael Niedermayer
2025-05-26 21:10               ` softworkz .
2025-05-26 21:35                 ` softworkz .
2025-05-26 21:56           ` softworkz .
2025-05-26 16:36 ` Michael Niedermayer
2025-05-28  1:09   ` Michael Niedermayer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DM8P223MB03654A6411F2CAF32AAC9729BA65A@DM8P223MB0365.NAMP223.PROD.OUTLOOK.COM \
    --to=softworkz-at-hotmail.com@ffmpeg.org \
    --cc=ffmpeg-devel@ffmpeg.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

Git Inbox Mirror of the ffmpeg-devel mailing list - see https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://master.gitmailbox.com/ffmpegdev/0 ffmpegdev/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 ffmpegdev ffmpegdev/ https://master.gitmailbox.com/ffmpegdev \
		ffmpegdev@gitmailbox.com
	public-inbox-index ffmpegdev

Example config snippet for mirrors.


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git