The Debian Project's discomfort with the GNU Free Documentation
(GFDL) has been clear for some time. To Debian developers (and
many others), the GFDL is not a free license for a few reasons:
- The "invariant sections" requirement allows an author to designate
parts of a document which cannot be changed or removed. This
requirement has a clear and transparent purpose: it keeps people from
circulating copies of GNU documents which lack the GNU Manifesto and
related text. Invariant sections are obnoxious at best; it is, for
example, impossible to use a chapter from one of the emacs manuals
without dragging along many pages of unrelated material. At worst,
invariant sections are non-free, since they restrict the right to create derivative
works. Almost nobody (outside of the Free Software Foundation) uses
invariant sections (and the related "cover texts") in GFDL-licensed
- The GFDL contains a section intended to keep manuals from being locked
up in digital restrictions management systems. That section is so
broadly written, however, that some people believe it disallows
storing a GFDL-licensed manual on an encrypted filesystem or even
setting the file permissions on the manual to disallow world-read
- The requirement that "transparent" copies of a document (think "source
code") be distributed with "opaque" copies strikes some as being
overly onerous. The license seems to require users to download
transparent copies whether or not they want them.
Debian position statement on the GFDL for more information on why the
project objects to this license.
Debian developer Anthony Towns recently circulated a proposal for a general resolution (since updated) on the
GFDL. The resolution would reiterate the project's objections to the
license, and generally bring the issue back into the foreground.
Previously, the developers had agreed to let GFDL-licensed documentation
slide so as to not delay the Sarge release. That release is now out, and
the Etch release is planned for December of this year. As things stand
now, the project will not be able to release Etch until all non-free
documentation has been removed - and that situation is unlikely to change.
The Debian folks would like to see this problem solved by the FSF, which
could make it vanish by releasing an updated version of the GFDL. The
transparent copy and DRM items seem amenable to easy fixes, leaving only
invariant sections to worry about. Even in the absence of a change of heart on
invariant sections, fixing the other issues would make documents which lack
such sections free. Tweaking the GFDL to allow the removal of invariant
sections would solve the problem completely.
Given that version 3 of the GPL is due to be unveiled (in draft form) on
January 16, it is probably safe to assume that the FSF is not devoting a
great deal of attention to tweaking the GFDL at this time. The FSF has, in
fact, proved quite resistant to making any changes to that license even
when there weren't other things going on. So a new GFDL before the
scheduled Etch release seems unlikely.
So, it is probable that there will be a mass purge of
GFDL-licensed documentation from the core Debian distribution. That
documentation will then languish in the non-free area, where Debian folks
will routinely sneer at it.
This purge will affect any free software project whose code is shipped by
Debian, and which has documentation licensed under the GFDL. As it
happens, there are a couple of smallish projects which fit that
description, called KDE and GNOME. Both of these projects will have to
find a way to address Debian's concerns, or see its code shipped without
the accompanying documentation.
The projects are starting to think about this issue. Recently, Jordi
Mallach posted a call for discussion on the
GNOME desktop-devel list, and Isaac Clerencia posted a very similar message to kde-devel. In fact,
the messages are so similar that one must conclude that the level of
cooperation between the two projects is higher than generally imagined. In
both cases, two options are presented: (1) create new
documentation-free tarballs, or (2) relicense or dual-license the
existing manuals so that Debian will see them as being free. The
dual-licensing idea is the one which is recommended.
The initial response in both projects has been somewhat unsympathetic to
the Debian project's position. It seems fair to say that quite a few
developers (and authors) don't really see a problem in need of a solution -
especially since neither project makes use of invariant sections. A GNOME
developer suggested that it was up to the
Debian project to either get the GFDL changed or to deal with every author
to get the licensing changed on their works. A KDE developer has flat-out refused to consider dual-licensing
his work. There are people in both camps who have problems with the GFDL,
but it appears that bringing about a licensing change will be hard to do.
So there does not appear to be an immediate solution at hand, and the
chances are good that Etch will ship without a great deal of
documentation. Debian Etch users will have to get their GNOME and KDE
manuals at the same time they stock up on MP3 encoders, libdvdcss, and that
Flash plugin they swear they never use. It's not the end of the world;
that documentation remains readily available. But it is an example of what
can happen when we are not sufficiently careful in our choice of licenses.
Picking the wrong license can lead to trouble down the road, and it can be
a hard choice to change.
This episode could also have been avoided if the FSF had been a bit more
responsive to the feedback it sought when the GFDL was released in draft
form. Most of the objections one hears now were voiced then, but they had
no effect on the final wording of the license. One can only hope that the
GPLv3 project, which begins next week, will produce a more
generally-acceptable final result. The stakes in that case are
Comments (41 posted)
One of the places where the Linux desktop tends to fall short of the
proprietary alternatives is its support for the Shockwave Flash media
format. The world is full of deprived Linux users who are unable to enjoy
the full benefits of singing, dancing advertisements on web pages. These
users are also deprived of cheesy games, delightful product demos, and
more. Clearly Linux will never be ready for the desktop as long as this
The truth of the matter is that the ability to deal with Flash is
occasionally useful. There is a place in the world for cheesy games. So
a free Flash player would be a nice addition to the Linux desktop. That
player may have just gotten a bit closer with the Free Software
Foundation's announcement of
Gnash, a GPL-licensed Flash player. According to the announcement:
Gnash is a project to build a SWF version 7 compliant flash player
with high-quality imaging. It is the most advanced free flash
player that currently exists, and an important addition to the GNU
project. The release of Gnash represents the achievement of one of
the free software movement's high priority projects.
It was quickly pointed out, however, that the FSF may have gotten a little
ahead of itself with this announcement. Gnash, as it stands now, is prone
to frequent crashes, does not work on 64-bit systems, and is generally not
ready for prime time. It is, however, at a point where it could
benefit from contributions from a wider group of developers, and attracting
those contributions is certainly what the FSF is really trying to do at
Others pointed out that Gnash is not the only free Flash player out there,
and that it might not even be the "most advanced" one. In particular, swfdec has been releasing for
some time now, with version 0.3.6 hitting
the net on January 10. Swfdec comes with a mozilla plugin (as does
Gnash), and GStreamer integration as well.
One important difference between these two projects was pointed out by
Christian Schaller: Gnash is licensed under the GPL, while swfdec uses the
LGPL. This difference could matter to a significant subset of potential
users. Much of what is found in Flash files, including MP3 audio and
various video formats, is covered by patents in some parts of the world.
The LGPL allows swfdec to be distributed alongside patent-encumbered code;
such distribution, instead, is not possible with Gnash. This restriction
will not matter to people who aren't interested in running code with patent
issues. But people who are less fussy about such issues, and who want a
Flash player that actually plays the Flash files they encounter on the net,
may care quite a bit.
Choice is a good thing, and the free software community may well benefit
from having multiple Flash players out there. But it is also probably true
that there is not a surplus of developers with time to contribute to this
sort of project. So it might benefit the community to have a discussion
about the relative importance of GPL licensing and the ability to
distribute non-free decoders. It is a choice with unfortunate consequences
Comments (19 posted)
The static analysis tool once known as the "Stanford Checker" has
occasionally shown up here on LWN. The Checker has often been applied to
the Linux kernel code base, resulting in the detection (and fixing) of
hundreds of bugs before they created trouble on production systems. It is
clearly a powerful tool, and it has often been hoped that the Checker would
be released as free software. That was not to be, however; instead, it
evolved into a proprietary product called "Prevent," offered by a company
The Coverity folks have occasionally posted information on problems found
with their software, and those bug reports have been appreciated. It now
looks like that stream of information is about to increase; Coverity has announced that it (along with
Stanford University) has received a grant from the U.S. Department of
Homeland Security to help improve the security of free software. To that
end, Coverity Prevent will be run against some 40 free software projects
(the release lists the kernel, Apache, MySQL, PostgreSQL, Sendmail,
FreeBSD, Mozilla, and GTK) and the results will go into a
publicly-available bug database. The project is described as "multi-year";
an initial availability date for the bug database was not provided.
Some people who have yet to fully understand free software have been heard
to wonder what benefits come from access to the source. These people may
not be programmers, and have no clue what they would ever do with that
code. Here is a clear example of why free software is better. All
users of the packages analyzed by Coverity Prevent will benefit in a number
- The number of bugs found in each package will be public information,
as will how that number changes over time.
- Users who are concerned about the security and reliability of the code
they use will be able to see just how responsive each project is to
the bugs which are found.
- Developers will - one hopes - learn from the types of bugs which are
consistently found in their packages and get better at avoiding them.
- These bugs - many of which are reliability and security problems
waiting to happen - will be fixed.
Proprietary software simply is not available for third-party auditing in
Most of this is not new; the auditing (and fixing) of free software is an
ongoing process. The free software community does not, yet, have tools
which are as good as Prevent, however, so its regular application to free
source should be a good thing. And the bug database should be full of
interesting information which will help potential users judge the relative
security of the covered projects.
One could argue that the Department's funds would have been better applied
to the creation of free tools which perform detailed static analysis of
code. Then all projects could benefit from the results. Still, direct
government support for free software is rare in the U.S. (especially
outside of scientific funding agencies), so this grant looks like a step in
the right direction.
There are risks involved in an effort like this. If developers are not
responsive to the bugs reported by Prevent, the bug database could become
an easy shopping list for malware authors. The bug database also offers
some FUD possibilities: similar databases do not exist for proprietary
software products. But we should not fear public disclosure of our bugs;
it makes us stronger in the end. This project, if it lives up to its
potential, will result in a higher-quality, more secure code base for all
free software users.
Comments (6 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: The CERT vulnerability list; AppArmor; A vast number of new vulnerabilities.
- Kernel: Looking forward to 2.6.16; The mutex API; Wireless networking.
- Distributions: Testing out the Xen live CD; Yellow Dog Linux 4.1; Damn Small Linux 2.1; Mono in Fedora Core; DebConf6 talks; IBLS; Secure Apt
- Development: Release 2.40 of Blender 3D Graphics, DWARF Debugging Standard V3,
new versions of PostgreSQL, ZODB, ooh323c, Zope, Rivendell, GARNOME,
GNOME, KTechlab, SQL-Ledger, Blender, Wine, OOo Label Templates, PEL,
- Press: 2006 predictions, MCP against Linux, EuroBSDCon coverage, MontaVista CEO
to step down, FAT patent upheld, using gd, ISPConfig review, WordPress 2.0
- Announcements: Asterisk monitor package, CrossOver Office 5.0.1, OpenVZ Debian VPS,
Open-source gains in Government, Blackberry survey, KDE at FOSDEM,
OSCON CFP, OLS CFP, PyCon keynotes, Qt Centre site.