Bug#522373: ftp.debian.org: Please clarify on acceptance policy of packages containing mpeg related algorithms

Fri Apr 3 07:27:42 UTC 2009

Package: ftp.debian.org
Severity: important

Hello ftp-master,

I'm filing this request as a bug for your convenience. The information
in this mail has been thoroughly discussed with Diego Biurrun, who is a
very active upstream contributor maintaining the build system for both
FFmpeg and MPlayer. I've tried several times to approach ftp-master on
this, but all my previous attempts have failed. On 2009/03/14, Joerg
Jaspert asked to me write another email, so here we go.

Currently the policy on the acceptance of packages containing code
implementing mpeg related algorithms is pretty inconsistent. For the
ffmpeg package, it has been decided at debconf7 that not even source
redistribution of mpeg *encoders* is allowed in debian. This is
documented in the ffmpeg package [1].

Technically, the debian ffmpeg package implements the "pruning" of the
ffmpeg tree using a small shell script called debian/strip.sh [2]. The
script does not actually remove the encoder implementations, but rather
makes them unreachable from the application code.  No decoders are being
disabled, only encoders are affected by [2].

Currently, [2] strips out the following encoders (in the notation as
used upstream):

 - h263
 - mpeg2video
 - mpeg4
 - msmpeg4

that list of encoders is most likely not complete, it is very possible
that additional encoders are left enabled in the debian package.
However, I have no detailed knowledge what encoders are affected by
ftp-master's policy, so again, I'm asking for clarification what ffmpeg
encoders need to be disabled for what exact reason. I need to ask for
the reason because it is not obvious at all what the term "mpeg related"
actually means. I'll outline my personal opinion on that further below.

This policy is very inconsistently enforced in the archive. Some
packages do not need to do this at all (xine, vlc, mplayer, to name only
the most prominent ones), some others are obviously not being accepted
in the archive at all (mjpegtools [3], transcode, etc). If I'm wrong
here, please correct me. I therefore ask for a clarification and
rationale of this requirement. I currently suspect that this is a
miscommunication and ftp-master did not actually mean to require the
stripping procedure to be applied. If that is the case, the encoders
will be disabled using configure switches provided by the upstream build
system, instead of patching the upstream source in the next upload.

Since my last enquiry, I've been in good contact with upstream, and we
had several phone-calls on that topic. Up to our current research, we
have made the following observations:

 - some patents relevant for the source code found in the FFmpeg package
   are held by the MPEG Licensing Association (MPEG LA) [4].

 - the MPEG LA has a rather straightforward patent policy. They charge
   for both encoders and decoders on a "sold unit" basis. We now really
   wonder where the restriction on "mpeg encoders" actually comes
   from. We know that for MP3 and AAC the charges for encoders are
   higher than for decoders [4], but again, that's not what we are
   talking about in this context.

 - FFmpeg does provide wrappers for libmp3lame and libfaac, but as these
   packages are not in debian, they are not being enabled. The wrappers
   are still available in the source package, though.

   NB: these wrappers are only used to *encode* MP3/AAC content!

 - As far as we understand [7] the MPEG LA does not charge royalities
   for "intermediate products", that are not sold or shipped directly to
   the enduser. We believe that source code falls under this definition.

 - Debian ships other unstripped copies of FFmpeg in other source
   packages. Most of them however (if not all) do not compile that copy.

Because of these observations, we feel that the requirement on the
source code pruning is rather pointless. We therefore ask for
clarification if that is actually necessary or not, and if yes, we
obviously must have overlooked some argumens. In that case we need to
know on what basis ftp-master requires the ffmpeg-source package to be
"stripped".

This discussion here is actually not limited the FFmpeg source package
in debian. In order for package maintainers to make the right decisions,
some guidance on ftp-master's policy is needed. Most helpful (and IMO
absolutely necessary) is a document that clarifies under which
conditions must which code be removed/disabled/mangled/etc. from
packages in Debian, and which of these modifications ftp-master requires
to be applied to the source as well. As soon as we all know what we are
talking about, we can go and fix packages.

For the FFmpeg package [6], I see several options:

 1. we accept ffmpeg unmodified in main
 2. we reject ffmpeg from main completely
    a) but allow an unmodified ffmpeg in non-free
    b) and don't allow even in non-free
 3. we introduce a new archive section for this class of packages and
    its reverse dependencies.

effects of 2a and 2b: this will cause a large portion of debian to be
dropped. ffmpeg has a large set of reverse dependencies, which would
need (a) to be dropped completely or in case of (b) moved to the
non-free section.

Of course you could argue that vendors selling hardware with
preinstalled mp3 decoders (etc) could be charged by patent trolls. For
this kind of users option 3 would be most convenient, since they would
sell their hardware without that extra section and explain how users
could install the missing packages.

But since we didn't have any problems so far, I don't think you can
claim these patents as "actively enforced". I was told in private by at
least ftp-masters (namely James Troup and Joerg Jaspert) that the status
"actively enforced" was the condition on that software is being rejected
from the archive. We (both the pkg-multimedia and FFmpeg upstream) now
wonder if this policy documented anywhere publicly? It would be a shame
if Debian would fail to document the policy on that matter.

As I don't see the algorithms that are disabled in debian's copy of the
FFmpeg package being covered by patents that are "actively enforced", I
think option 1 would be just fine for Debian. Quite the contrary, I take
it as indication that they are NOT actively enforced because debian
didn't have any troubles with them for literally YEARS!

[1]
http://git.debian.org/?p=pkg-multimedia/ffmpeg-debian.git;a=blob;f=debian/README.Debian;hb=HEAD

[2]
http://git.debian.org/?p=pkg-multimedia/ffmpeg-debian.git;a=blob;f=debian/strip.sh;hb=HEAD

[3]
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515850

[4]
http://mpegla.com

[5]
http://mp3licensing.com/royalty/

[6] as example for packages shipping algorithms related to mpeg
patents. The policy should then be applied to other packages like xine,
vlc, mjpegtools, transcode, x264, etc. as well

[7]
http://www.mpegla.com/m2/m2-agreement.cfm

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