[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Enabling and installing of "risky" ("patented") codecs - made easy

[This is a thread that I posted to pkg-multimedia-maintainers@lists.alioth.debian.org this morning and that led to a small discussion between Loic Minier and myself, see http://lists.alioth.debian.org/pipermail/pkg-multimedia-maintainers/2007-October/000506.html . I have attached Loic's first answer to this post, making it a rather long but hopefully interesting reading. However, I think it's better to discuss this topic with a broader audience.]

Dear Debian developers (and interested readers),

I'd like to discuss an issue with you that concerns me for a while now. I will be happy to read all of your opinions and suggestions!

You all know about the unsatisfying situation of some codec libraries that are commonly called 'risky' or 'patented'; namely lame, xvid and friends. While being perfectly free software on the one hand, licensed under the GPL or LGPL, they are surrounded by a cloud of patent FUD or even actual threat, which makes them unsuitable for Debian's main section [0]. Nevertheless on the user's side there is a demand for those codecs which can be whitnessed by the broad acceptance of unofficial repositories [see: http://popcon.debian.org/unknown/by_inst ]. Furthermore, there is nothing that might hold users back from using this software in Europe, because IIRC software patents do not exist on this continent.

With a basic set of libraries (e.g. lame, faac, xvid, x264) at least the following packages in Debian (I guess there are lots more) could be extended in their features: ffmpeg, gstreamer0.10-plugins-{bad,ugly}, libquicktime, etc. Some of these packages are already prepared for inclusion of those codecs, e.g. if you compile ffmpeg with 'DEB_BUILD_OPTIONS=risky' set or set some 'EXTRA_PLUGINS' in the gstreamer packages, you'll be awarded with enhanced features. While on the one hand it's nice to find such preparations in existing packages, there are still at least two defiencies left: (1) There is no consistency among these methods. (2) We do not make the needed codec libraries available, we do not even explain why we don't.

My suggestions:

(@2) We are already maintaining libdvdcss2 and x264 (which are definite candidates for maybe-illegal-in-some-countries) in our SVN and I think we should consider maintaining the other mentioned libraries (at least lame, faac and xvid), too [1]. I am not talking about uploading them to Debian, but at least making them available for compilation and packaging on the user's own computer [2]. Of course, Debian will not officially support this and it should be made clear to the user that what she is doing might be illegal in her country, etc.

(@1) We should try to introduce a Debian-wide standard for the affected packages and maybe even mark them e.g. in the package description, so the user knows: "If I compile this package with [e.g.] 'DEB_BUILD_OPTIONS=risky' set, I will get a feature-enhanced version of the software. I will need additional library packages, but I can compile them myself from the sources and the Debian packaging found at the pkg-multimedia SVN." Packages built this way will have the smallest possible interdiff with their 'official' counterparts [3]. Again, it should be made clear to the user that what she is doing is absolutely unsupported by Debian and not recommended by the maintainers and may be illegal in her country, etc.

What do you think? Is it worth the effort?
Please share your thoughts with me!


[0] Of course we should motivate people to use free and open formats for their media, e.g. OGG Vorbis, and I am strictly for it. But sadly the world isn't that perfect and your $20 MP3-player supports nothing but MP3 and your DVD-Player will play XVID but not Theora, etc...

[1] Similar effort has been put into the debian-unofficial.org project which has been founded by Daniel Baumann in 2005 but has recently lost priority (well, it died) because of his involvement in the Debian Live project (Well, I guess. Don't get me wrong, I consider Debian Live a great project, it's just a pity for d-u.o). Debian packaging can be found at http://svn.debian.org/wsvn/restricted/dists/trunk/ and may give a good starting point.

[2] I know there is already Chrstian Marillat's unofficial repository at www.debian-multimedia.org, where you can download binary packages for those codecs, but this situation is also suboptimal and I have some personal objections with it: First of all it is not a team-maintained project, but a one-man-show (well, maybe two-man). The packaging style differs very much from the 'official' counterparts in Debian; take ffmpeg or the gstreamer packages as examples. Also many of the packages are not up to the quality standards that Debian imposes (e.g. have a look at some of the debian/copyright files). Last but not least there is this 'unofficial', nearly 'amateurish' taste of this repository; e.g. the homepage does not even look remotely Debian-related. [Christian, if you read this, please do not take it as a personal offense. I highly appreciate the effort you put in your repository, but I have also already tried to contact you about my issues - whithout success.]

[3] The user could even run her own private repository tracking unstable with no more effort than constantly having 'DEB_BUILD_OPTIONS=risky' set. Of course, if she wants her packages to replace the 'official' ones, the Debian revision will have to be modified, e.g. ffmpeg_0.cvs20070307-6+risky1.

* Loic Minier answered:

I share your feelings; I think it would be useful for our users to
improve this situation and handle it cleanly and officially instead of
allowing the use of sometimes poor third party repos.  Our users waste
too much time and efforts on such things.

I think our goal should be to make it very easy to get binaries in the
end, which then can be automated by some GUI tool / hooks.

There are many technical / organizational problems to solve; I think
hosting the source and hosting the binaries are two things with
different requirements, but we might skip this distinction in the
initial efforts.  Different sources / binaries might also have various
problem types:
- infringement on actively enforced patent (where are the patents
  enforced/enforceable, hence country specific)
- copyright laws infringements (country specific)
- is source redistribution allowed while binary distribution isn't?
  (depends on the country as well)

These might be issues for source packages or for binary packages, or
for the act of distribution, the act of download, or the act of using
the software.

So perhaps there is a simple enough intersection of all constraints
which might allow setting up a limited archive in a permissive country,
but perhaps we should think at advanced long term solutions which would
- distinguishing packages issues
- selecting potential hosting countries
- selecting allowed download countries
- selecting the proper mechanism to obtain a binary (perhaps building
  from source in some cases)

Ultimately, we might have to:
- decorate our source packages with classification information (for
  example X-NotAutoBuildable, which might be useful for non-free, but I
- decorate our mirrors (and lists thereof) with availability
- handle new types of data describing law allowances
- build software to make this all "simply work"

The new copyright file format might allow for new extensions such as
documenting whether this or that source is know on $date to infringe on
an actively enforced patent in $country for (source|binary)
(distribution|use|download) etc.

But then while I'm ready to offer ideas on the above, I'm afraid this
is a huge task to actually achieve...

Loïc Minier


Dipl.-Phys. Fabian Greffrath

Ruhr-Universität Bochum
Lehrstuhl für Energieanlagen und Energieprozesstechnik (LEAT)
Universitätsstr. 150, IB 3/134
D-44780 Bochum

Telefon: +49 (0)234 / 32-26334
Fax:     +49 (0)234 / 32-14227
E-Mail:  greffrath@leat.ruhr-uni-bochum.de

Reply to: