LWN.net Weekly Edition for January 12, 2006

The coming Debian GFDL collision

The Debian Project's discomfort with the GNU Free Documentation License (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 documents.

• 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 access.

• 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.

See the 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 significantly higher.

Comments (41 posted)

Flash players for Linux

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 situation persists.

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:

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 this point.

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 either way.

Comments (19 posted)

Publicly funded free software security audits

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 called Coverity.

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 of ways:

• 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 this manner.

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)