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
; 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
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).
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
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)
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
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
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
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
[...] 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
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.
Comments (74 posted)
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
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,
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
Comments (115 posted)
Page editor: Jonathan Corbet
Next page: Security>>