Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Bits from the DPL: Freedom and etch

Skip to first unread message

Anthony Towns

Aug 28, 2006, 2:40:05 PM8/28/06
Hello, world!

As a project, Debian is heavily committed to the ideals of free software.
That's not news to anyone reading this, I'm sure, as it's something
we've constantly worked to improve, whether that be by establishing our
Social Contract and the Debian Free Software Guidelines or by working
with other organisations such as Software in the Public Interest [0],
the Free Software Foundation [1], the Open Source Institute [2], or
Creative Commons [3] to further promote those ideals.

Another two major steps we have made towards the ideal of software
freedom over the course of the project has been removing the need to run
non-free software to contribute to Debian -- made possible by Werner
Koch's development of the GNU Privacy Guard (gnupg/gpg); and removing
the need to run non-free software on our own servers, which was completed
in May 2000 when we switched from qmail to postfix and exim for handling email [4].

The most recent efforts in relation to this ongoing goal have been in
paying increased attention to the freedoms provided for works other than
regular applications and libraries -- most notably documentation [5].

I believe the current expectation is that there will be absolutely
no problems ensuring that the Debian System will not only be composed
entirely of free applications and libraries, as it has for years, but
also of free documentation, free graphics, free videos, free fonts,
and free drivers.

At this point, there seem to be only three areas where we won't easily be
able to meet the goal of everything in the Debian System meeting the DFSG:

(a) License texts only rarely explicitly allow other authors to create
new, derivative licenses based on existing ones -- you either
use what's there, or get your own lawyer to draft something in
their own words.

(b) We generally aren't able to consider distributing truly large
"source" files, including losslessly encoded video, geographical
data sets, or the complete design specification for some fonts.

(c) A number of drivers in the Linux kernel include firmware to be
uploaded to the chipsets they support that is provided as
either a sequence of hex codes, or as a separate binary file --
while modifying the code is allowed, in many if not most or all
such cases, the firmware is effectively being provided without
useful source.

License texts themselves are not an easy issue to resolve, but this is
somewhat balanced out by that generally not being necessary -- and indeed
while we do encourage people to come up with modifications to software
they use, coming up with new and modified licenses is often a much worse
idea than reusing an existing free license, even if it has flaws.

Large source files and how we should deal with them have been an
unresolved concern for a long time -- Bug#38902 might give you some idea
just how long. Up until now we've dealt with it by simply packaging the
source in the form that we need it -- for which a reduced or compressed
form almost always suffices. It will probably be some time yet before
we can come up with a sensible technical approach here that balances out
the bandwidth and storage usage appropriately.

Firmware, however, is a much more immediately resolvable issue -- and
one that has already progressed signficantly over the past few years
as Linux's interface for loadable firmware has improved, and hardware
manufacturers gradually become more comfortable with releasing free
drivers and free firmware.

The major problem remaining for Debian in handling that, is that we
don't have a good way of supporting installs on hardware that needs
firmware that we don't have source for and have separated into the
non-free component. Joey Hess summarised the problems in dealing with
that to the -vote list [6] and estimated six months of work developing
the appropriate support in the installer, with presumably more time
needed after that for testing and quality assurance.

So the question is what should we do here? One approach would be to say
"we're committed to making the Debian System completely free, so until
that's done, we're not ready to release". Another is to say "we've made a
lot of improvements since sarge, on this score and others, so let's get
etch out now, and move onto the next bit after that". A third is to say
"we've committed to getting etch out, and to making it be completely
free -- if that means not supporting a range of hardware, so be it".

One way or another we're going to have to make a decision on what
approach to take fairly soon -- and general resolutions on how to square
up the approach we take are already being discussed on the debian-vote
list. Personally, I'd appreciate knowing which of the above goals Debian
users and developers actually think are the most important before deciding
I'm going to approach them; and to that end Jeroen van Wolffelaar has
kindly setup a couple of polls you might like to vote in.

Two polls for users are hosted on [7] to all registered
users, asking:

What is the most important for the release of Etch?
Release on time (early december)
Do not ship sourceless firmware in main
Support hardware that requires sourceless firmware


Since it appears Debian has to make a choice, which would you prefer we do?
Allow sourceless firmware in main
Drop support for hardware which requires sourceless firmware
Delay the release of etch
(so that we can support loading firmware from non-free)

Unfortunately you can't indicate your preferences, so you have to choose
one of them. You can leave comments, on the other hand; though I'm afraid
it's unlikely we'll be making "CowboyNeal" the most important priority for
etch no matter how many times it may be suggested as a write-in candidate.

Additionally Jeroen has setup a developer only poll [8] that does allow
preferences and is authenticated via GPG signatures in the same way
regular Debian votes are. Unlike regular votes, however, the current
results of the vote will be available before voting has closed.

Note that both these polls are just an informal way of finding out what
people think, and while they will be considered and taken into account,
they won't necessarily be the final word on the matter.

Thanks for your time!


Anthony Towns
Debian Project Leader

[0] As well as supporting Debian, SPI also supports activities of
OFTC, the PostgreSQL community, the Open Voting Foundation, and
most recently A number of groups that SPI has
supported in the past have since grown enough to justify their own
organisation, including the LSB (the Free Standards Group), Gnome
(the Gnome Foundation) and (OSI).

[1] Debian was originally an FSF project itself, and as well as sharing
a long association with the GNU Hurd project, we also work closely
with the FSF on software projects such as glibc and gcc, and in the
review and development of licenses such as the GNU Free Documentation
License and the drafting process for version 3 of the GNU General
Public License.

[2] Debian has been closely involved in OSI since its founding -- with
Eric Raymond joining Debian in the same week as both the DPLs of 2005
and 2006 in order to work with Bruce Perens on creating the "open
source" term, using the Debian Free Software Guidelines as a basis for
the Open Source Definition. Debian particularly supports both OSI's
ongoing work in introducing companies to the benefits and ideals of
free software, and the work of the OSI License Proliferation Committee
in encouraging reuse and compatability in software licensing.

[3] Evan Prodromou recently reported on the progress made in working with
Creative Commons on having their new licenses work match the Debian
Free Software Guidelines -- you can see more about that at:


[5] Such as working with the FSF on revising the GFDL to match Debian's
ideals of freedom, encouraging free software authors to use the same
license for their documentation as their software to ensure it's free,
and working with groups such as the Creative Commons to extend free
software principles into the domain of free works in general.




0 new messages