Providing non-stripped ffmpeg libraries

[Reinhard Tartler]

Fabian Greffrath <greffrath at leat.rub.de> writes:

> Reinhard Tartler schrieb:
>> I've also considered bringing that to the TC, but I've decided to write
>> the DPL first. Answer pending as well.
>
> This is unexpected! When was that?

Why was that unexpected?

So far, I've written 2 mails:

20.04, 10:08, Subject: #522373: Please clarify on acceptance policy of
                       packages containing mpeg related algorithms

06.05, 09:06, Subject: Re: (Overlapping) bits from the DPL

> Well, if we follow the way that we just discussed (i.e. upload the
> unstripped ffmpeg source to the Debian archive, keep the encoders
> disabled in the binary packages and inform ftp-master about it) there
> are two possible groups of reactions that we may receive:
>
> - Either we get no feedback from ftp-masters
>   or they finally bless the upload
>
> - or the package gets removed from the archive
>   or we get a harsh statement to immediately strip the ffmpeg source
>   in a new upload
>
> Both cases will lead us to a point from which we can work better than
> now: Either our packages are finally accepted or the problem escalates
> and we need answer from the CTTE. So I realy think it's worth trying!

I think most likely they will not remove the package but ask us to
revert that change in the next upload without properly explaining
why. But even that would be something that we could escalate somewhere.

>> In any case, if you have other packages that are in a similar position,
>> feel free to write the DPL as well.
>
> Let's see what we have here: lame, xvid, x264, mjpegtools, transcode,
> mencoder, faac, ... need some more? ;)

for MP3 and AVC there are documented cases where patent holder did act.
So maybe it would be smarter to *not* start wth lame and x264.

-- 
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4