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!
Cheers,
Fabian
[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
allow:
- 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
digress)
- decorate our mirrors (and lists thereof) with availability
information
- 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...
Bye,
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: