LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
->One big page
This page
Previous weekFollowing week
| |||||||||||||
LWN.net Weekly Edition for August 13, 2009The unending story of cdrtoolsCertain 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:
Anyway, if you are showing good will with fixing the current
problem by starting to distribute the legal original software
again, I may give you some time to recover from the mistake of
switching to the illegal fork.
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:
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.
KDE struggles with feature requestsSometimes 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:
[...] there's a certain sort of
bullying going on there where certain individuals, fewer with each release i
might add, feel that if they just SHOUT LOUD AND ANNOYINGLY ENOUGH AT US that
we'll relent, break our designs, go back on what we're trying to do and give
them what they are used to at the expense of everyone else.
[...] but i won't go back on various design decisions and throw out all the benefits we're reaping due to those decisions. i refuse to fall into some misguided knee-jerk-to-the-latest-random-user-moaning design "methodology" 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:
now, i'm all for a proper feature request system. bugzilla is not that, a wiki
is not that, random emails are not that, a blog is not that. FATE, as used by
opensuse, gets pretty damn close though (and it even has a kde client). one
day i'll probably just say "screw bugs.kde.org for feature requests" and have
someone set up a FATE install for plasma. and then we can get on to the
business of proper feature request work flow.
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:
Unkind and unrealistic. Without bug/wish reports how do you know what
features people value? Again, just a kind reply of 'coming, but not yet' is
not too much to ask, but often too much to get.
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:
the user community that interacts with F/OSS projects such as KDE really needs
to start understanding how this all works and taking some responsibility in
their actions. as developers we're expected to be paragons of behavior, but
really it's cooperative between all of us. except that the user community
tends to still lack a clear set of shared values and ethics when it comes to
these things.
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:
[...] it needs workflow improvements, but at
least it's collaborative, it's positive, it's easy for users to use and it
looks pretty. we need to improve things like brainstorm and see more systems
like it.
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:
[...] But even if we developed a whole plethora of tools
that encourage positive contribution, respect for others, world peace,
community spirit and ponies, we would still have to deal with the
appearance of trolls who'll crap on everyone's parade with negativity
and shortsightedness. In today's Internet culture I see no way around
it, so we can't hold the community responsible for their existence. Of
course every individual in the community is responsible for how they
respond to and deal with such types, so maybe that's where we should
be focusing our efforts
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.
Ubuntu's multisearch surpriseIf 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:
Change #2 is just an artifact of collecting the usage data. We
could only see what parts of the FF UI people were using to do
searches if we sent them to our custom page. This usage data is
important because it helps us channel design and development
resources to useful features, and is also important because it can
be tied to revenue generation.
Generating revenue that supports the project is a feature, not a bug. However, we are mindful of not throwing the baby out with the bath water. In other words, we must strike the balance of continuing to deliver a top notch user experience while taking advantage of revenue opportunities. 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:
We regularly change features for software during the development
release; also we add new stuff to our default installs that will
get automatically installed if you opted into ubuntu-desktop; I
agree that it might have been better to move this to a standalone
package and seeding that through ubuntu-desktop; but then its just
an intermediate thing what you see now and you can always disable
it in Tools -> Addons for the time being.
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.)
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||||