LWN.net Weekly Edition for August 13, 2009

The unending story of cdrtools

Certain unwelcome stories seem to never really go away. One may think that an issue has been resolved, only to be attacked by a zombie version years later. It has been almost exactly three years since LWN last wrote about license problems with cdrtools; the combination of GPL- and CDDL-licensed code in that package rendered the whole undistributable. Linux distributors responded by switching to cdrkit - a fork of cdrtools taken from a release prior to the problematic license changes - and it seemed like the problem was solved in an optimal way. The community had eliminated a licensing problem with an important package and disconnected from a difficult upstream maintainer at the same time.

But these problems are never solved, it seems. In June, Jörg Schilling, the author of cdrtools, wandered into the fedora-legal list with a request for Fedora to resume shipping the "original, legal" cdrtools software. After a discussion of the type that typically follows Jörg around, Tom "spot" Callaway stepped in with a definitive response (short version: "no") which pretty much brought the discussion to an end.

Life got quiet again until early July, when Luis Medinas suggested that openSUSE might want to switch back to cdrtools. That was Jörg's cue to make one of his predictable appearances, inspiring an even longer and stronger version of the kind of discussion that tends to follow him around. This time Jörg made a direct lawsuit threat against SUSE, but showed his forgiving side too:

One might well wonder about the reversal of roles here; now it's Jörg who is complaining about the legality of cdrkit. His complaints have been posted to the web. They include the fact that the "wodim" CD recorder packaged in cdrkit is installed as "cdrecord" (a GPL violation, he says), the lack of detailed change information within the source files, the failure to print a copyright notice "as intended by the original author," an (unspecified) failure to distribute "complete" source, and a couple of alleged violations of German copyright law (which, it seems, forbids any change which Jörg disapproves of). All told, it is a long series of complaints resulting from a simple fork of a GPL-licensed program.

Most observers do not take these claims seriously. The complaint about the cdrecord binary is (somehow) based on the preamble of the GPL - which is not part of the binding terms. Section 2a of the GPL does require dated notifications of changes, but it's a rare project which carries those notifications within the source files themselves, as Jörg is demanding. The complaint about copyright notices is interesting. Cdrecord has traditionally been a verbose utility, and that verbosity has extended to Jörg's thoughts about Linux distributors and kernel developers. For example, version 2.01.01a01 (from 2004) would print things like:

    Warning: Running on Linux-2.6
    There are unsettled issues with Linux-2.5 and newer.
    If you have unexpected problems, please try Linux-2.4 or Solaris.

    SuSE Linux is known to ship bastardized and defective versions of cdrecord.
    SuSE is unwilling to cooperate with the authors.
    If you like to have a working version of cdrtools, get the
    original source from ftp://ftp.berlios.de/pub/cdrecord/

(The current version, 2.01.01a63, has lost some of that language). The removal of some of that verbosity is what he is complaining about. But GPL section 2c only requires the printing of "an appropriate copyright notice" (not any specific notice), and it only applies to programs which read commands interactively, which wodim does not do. So this claim, like the others, has failed to create widespread worry.

In short, many in the community seem to see Jörg as a sort of comic figure, but that should not be allowed to obscure an important fact: there are some points worth noting behind his complaints. These include:

• Jörg alleges that openSUSE is shipping two related, legally problematic packages: vcdimager and libcdio. Both packages are GPL-licensed and hosted with the GNU project, but other distributions have recognized problems with them; Debian has shipped a patched version since 2004, and Fedora users must get it from an external repository. Fedora also does not ship libcdio, which is alleged to have suffered a license change which is not acceptable to the original author of the code.

• Cdrkit is nearly unmaintained. The mailing list for changes is a quiet and lonely place. Jörg states that hundreds of unfixed bugs have been introduced into cdrkit. The reality, as shown by distribution bug trackers, is a bit less spectacular, but it is true that some bugs exist which might not be present in cdrecord - which is actively maintained by Jörg.

The first issue needs to be taken seriously; it is never a good idea to distribute code with problematic or disputed licensing. The fix here is relatively straightforward: stop distributing that code if the license cannot be verified, and, possibly, reimplement it (as Sun is said to have done with libcdio).

The second may be harder. The freedom to fork a package out from under an uncooperative maintainer is one of the fundamental features of free software. But forking is expensive; it only works if somebody else does the work which has been pulled away from that maintainer. An unmaintained fork is just more dead code. If cdrkit reaches a point where it fails to work for users, distributors will be left with an unpalatable choice: continue to ship unmaintained code, or go back to the original, with its difficult maintainer and incompatible licensing. It would be much nicer to find somebody willing to put some time into this important tool. CD recording is a detailed and tricky task, but we have plenty of people in our community with the necessary skills to work in that area.

Comments (46 posted)

KDE struggles with feature requests

Sometimes developers have a prickly relationship with their users. Users may have unrealistic, or overly demanding, requests that can be difficult to respond to. The most vocal of these users are often unwilling to take "no"—or even "not yet"—for an answer. Some KDE developers are currently struggling with that problem, and trying to find ways to smooth the dialog between users and developers.

In a posting to the kde-devel mailing list, Pau Garcia i Quiles wondered where KDE 3 features that were missing from KDE 4 should be collected. He noted that there are various places users were complaining about these missing features (including an openSUSE web page that collects them), but no central location for KDE to track such things. His suggestion: "Can we start something like that in UserBase, for people to tell us what they miss in KDE4 from KDE3? Or have a special category in Bugzilla?"

That set off a bit of a rant from Aaron J. Seigo about user complaints:

Seigo also noted that the openSUSE list doesn't "mention _at all_ the actually useful features that are missing", and, that, when he commented on that wish list item, he "got yelled at by two different people on the report, completely without cause". Frustration is obvious in his posting, and he noted that it was probably not quite the response Garcia expected, but he wanted to make it clear that the current options were not working:

Anne Wilson noted that the users Seigo is referring to are just a "*very* vocal minority" that "can only be ignored". She is concerned with the users who are trying to make a difference with their bug reports and feature requests, only to be treated as if they are part of that loud minority. She disagreed with Seigo's suggestion that users should either write—or pay for—the code, or just be patient:

But, Seigo sees things somewhat differently. He points to this vocal minority as part of the reason that KDE projects aren't "paying much attention to feature requests made on bugs.kde.org". Once again, he places the blame largely at the feet of the user community:

There was some discussion of changing various bug tags, particularly WONTFIX, as it is regularly misinterpreted, to try to alleviate the problem. That is unlikely to mollify the users who are most vocal, though. Trying to ensure that features and bugs closed as WONTFIX get some kind of explanation will probably help with, but not eliminate, the problem, as well. Andreas Pakulat points out that it is a social problem: "people are getting used to be able to shout, rant and moan on the net without ever being held responsible for the possible damage they do with that".

One idea that seems to be gaining some traction is to use KDE Brainstorm, which was suggested as a place to gather features by Stefan Majewsky. Aside from some usability issues that seem like they could be dealt with relatively easily, Brainstorm provides a means to discuss new (or missing KDE 3) features, while allowing users to vote on those they find most important. Seigo sees it as a starting point:

But the problem is more than just work flow. From the postings in the thread, some KDE developers are finding it difficult to work with the user community, largely because of the behavior of a few of its members. Parker Coates is unconvinced that a tool-driven process will eliminate the problem:

Due to the very vocal, and largely negative, reaction to the release of KDE 4 more than a year and a half ago, there is still a great deal of frustration within the project—for both users and developers. While there are certainly some important points in the developers' messages, the tone is such that they also could be taken as an indictment of all users—something that is clearly not intended.

This is a problem that certainly isn't limited to KDE, as other projects have or will run into the same kinds of problems. There is a delicate balance between ignoring the "vocal minority" and ignoring the user community as a whole. The latter could easily lead a project to completely lose touch with the needs of its users, to the point where those users end up walking away. That is an outcome both sides want to—and should—avoid. Finding better ways to handle feature requests, while avoiding the conflicts with the few who will not be civil, is a good step on that path.

Comments (74 posted)

Ubuntu's multisearch surprise

If you are a Linux distributor, you have a number of possible ways to upset your user base. Breaking existing, well-established functionality is one of them. Another would be to install software which appears to be monitoring user activity behind their backs. Seeming to make money off of these activities will not help. Extra points are awarded for doing it all as a surprise. Ubuntu has risked all of the above with the "multisearch" Firefox extension included in the current "Karmic Koala" alpha release.

The bug report filed on July 21 had to do with broken functionality. It seems that, when using the version of Firefox distributed with the third Karmic alpha release, typing a search string into the "awesome bar" no longer takes the user directly to the first search result from Google. Instead, users end up at a Google "search partner" page listing the results and, of course, advertisements. Other quick searches, including stock quotes and currency conversions, also break. A related change is that opening a new tab now brings up an Ubuntu search page instead of a blank page - a change that some users find jarring.

It turns out that Ubuntu has placed a new Firefox extension, called "multisearch," into the Karmic alpha release. In essence, multisearch rewires the various search mechanisms built into the browser, causing them all to pass through Ubuntu's partner page. It can be disabled by going into the "Tools->Add-ons" menu, but, by default, it is installed and active on all systems.

So why was this done? Rick Spencer, Ubuntu's desktop engineering manager, explained the reasoning in a fair amount of detail. The "new tab" change is an attempt to improve the user experience - something that Mozilla developers are working on as well. The search change lets Ubuntu know which search mechanisms are being used most; beyond that, he said:

Ubuntu users are not necessarily opposed to the idea of revenue going toward the development of their distribution; it's a "feature" they can support. Many of them are, however, rather less thrilled about their search data being used to that end. Rick's explanation - "it's simply the same data that is already sent to Google and Mozilla: the requested search, and the channel for the search" - does not appear to have made anybody feel any better. As might be imagined, some of the more vocal users are throwing around words like "spyware" and "privacy violations." But even calmer voices are concerned that this "feature" was silently added to their systems, that it is not something they wish to have around, and that there has been little talk of privacy protections for the accumulated data.

Apologies from the Ubuntu side have been few and far between. Ubuntu Mozilla maintainer Alexander Sack justifies the change this way:

Of course, one should bear in mind that default Ubuntu installations are "opted in" to the ubuntu-desktop metapackage; very few users will have deliberately made that choice.

The other thing to bear in mind is that this feature appears in an alpha release - and that users did indeed make a deliberate choice to install that release. It's not uncommon to find unpleasant surprises in alpha-quality distributions, even if it's a bit more uncommon for those surprises to have been introduced deliberately. Alexander says that multisearch "is not intended to stay forever - at least not in its current form." One can interpret that to mean that some of the more annoying failures will be fixed. It's possible that the entire thing will be taken out before the end of the alpha-test period. But nobody from Canonical is saying that now.

A great deal of trust is placed in Linux distributors; they have the ability to inflict all kinds of unpleasant behavior on their users. Distributors seen to abuse that trust are not likely to retain their users for all that long, though. The beauty of free software shows through in a few ways here: undesirable behavior is very hard to hide, it is quite easy to remove, and, if all else fails, one can switch to a different distribution with minimal pain. Ubuntu is probably not losing any users over this episode - yet. But any user of this distribution who is concerned about this behavior may want to watch closely to see what decisions are made between now and the final Karmic Koala release.

(Update: multisearch was removed from Ubuntu on August 11.)

Comments (115 posted)