May 2003 Archives

The SCO saga

| No Comments

By now, everyone in the industry has heard about SCO filing a $1 Billion law-suit against IBM.

The whole story is quite bizarre. It began with the SCO accusing IBM of contract violation and appropriation of trade secrets. They alledged IBM had stolen IP from SCO (during project Monterey on which they collaborated) and alledge IBM took SCO IP and added it to Linux. They contest that Linux couldn't have achieved its current enterprise features and power without appropriating their code - a claim that is as easily dismissed as it is laughable.

SCO obviously haven't done their homework...

As soon as the community finds out which parts of the code are supposed to be infringing, a horde of developers will descend upon the problem, rewrite any code that is infringing, and dissolve the problem on the spot.

This is assuming that there is even any merit in their claims anyway. And this is far from clear. The analysis below just rips to shreds all the claims made by SCO:

SCO will be left with their lawyers trying to chase down the culprits (if any). And Linux - indeed, the entire Open/Free community - will continue to survive, and thrive. This is a mere distraction that cannot divert the cause.

One cannot help but wonder why Microsoft is resorting to such dirty tactics too. Obviously Linux is far more a threat to them than we imagined, given they are trying to prop up SCO with cashola... Read more analysis.

Due credit

| No Comments

This blog is my reply to an article by Hans Reiser on NewsForge, regarding credit and Free Software.

Motivation

The assertion that FS/OSS developers work for ego is on shaky ground to say the least. There are so many unsung heroes that turn the Free/Open wheel, contributing in so many different areas, that they couldn't possibly all get the prominent recognition for their work that Hans is suggesting.

While ego probably does play a part, the most powerful motivation in FS/OSS has to be altruism. People write code, provide support on mailing lists and IRC, submit patches, and undertake a myriad of other helpful tasks. Because people value the freedom, and people want to help others. For a job well done, the recognition will come. There are plenty of people who do not seek out accolades, but whose contributions are recognised and whose reputation is built on their work - and not a flair for self-promotion. In an altriuistic world, the contribution is the reward.

Established Practice

There are already several long-established practices for giving credit in software. The most obvious is the "About" box. Most GUI software has an option in the main menu that displays the version, copyright notice, and author credits. The credit information is easily accessible, but does not interfere with the day-to-day running of the software. Command-line programs can have an "--about" option to do the equivalent.

Credit is also present in the AUTHORS file distributed with the software, in the READMEs, in the copyright/license notice, in all copies of the software source code, and in CVS logs. And maybe even in an easter egg. These practices have been around for a long time, and seem to have been sufficient for the vast majority of developers. The information is easily accessible, but not intrusive. In-your-face credit tends to provoke a negative reaction from users, rather than inviting accolades. Surely all these should be sufficient?

Citations

When an author writes an academic paper, citations are inserted for many reasons. And citations are inserted typically in a numbered style [3], or in a short-author/year style [Reis03]. The style of citation is designed to be minimally intrusive to the reader of the text to minimise interruption to the flow. But there is sufficient information there to look up the bibliography and find the desired information; author, title, journal, and so on. This directly parallels the existing practices above. The information is non-intrusive yet easily available. Full credit is given, but the reader (or user) is not overwhelmed by the information.

Where would you stop?

If every FS/OSS developer were to follow Reiser's lead (adding the 24-line credits to the reiserfs-utils program), then Linux would rapidly become unusable.

When I type 'ls -l', should it come up with a list of authors of binutils? But it also uses glibc, so we would have to credit those fine folk. It was compiled with gcc, so we should credit them too. And this code will eventually use the kernel to do the work, so Linus, Alan, and a cast of thousands deserve their name in lights. And of course, since I run ext3, those authors should get fair credit too. So before I actually see the output of the 'ls' command, I would be blasted with probably about 500 odd names. Hmmm - BSD is looking better. But wait - didn't they already go through the process of removing the obnoxious advertising clause? Isn't this just the sort of thing Reiser is proposing?

When I play a CD, do we need to pop up a dialog showing the names of the developers of Gnome, Gtk, Libc, gcc, Alsa, Linux? And what about the poor engineers at Sony who made my CD player? The unsung heroes at Intel who designed my motherboard? And so on...

Obviously the issue rapidly descends in absurdity. So where do we stop? First we ought to ask ourselves if the existing practices are appropriate? They certainly seem to be for the vast majority of developers.

Screensavers

The idea of the screensaver is novel, but fraught with practical problems. Apart from the obvious: it would have to be optional, it would not be available for servers, headless systems, non-GUI installations, kiosks, embedded systems, etc etc. But aside from all that is the idea that it should be the default. By mandating that the credits screensaver be installed by default, Reiser is limiting peoples' freedom to choose what (if any) screensaver they should use. Once users (or distributions) start to become hamstrung by onerous conditions that developers place upon their software, they will simply seek out more free alternatives.

I like the idea of providing a credits screensaver, but strictly as an option, alongside the many other screensavers that are availble for the user to choose from. And it is important that they still have the choice.

Plagiarism

Recently Reiser accused the Debian project of plagiarism. Apparently a screenful of credits is displayed when the user runs certain command-line programs from the reiserfs tools package. This rather intrusive list was disabled by the maintainer, for usability reasons. The copyright notices and all other legal requirements of the GPL under which ReiserFS is distributed, were complied with. However, upon learning this, Reiser fired off a flame to the debian-devel list, accusing Debian of plagiarism and unethical behaviour, amongst other things.

Unfortunately, it was not clear from Reiser's posts, just what he was complaining about, and it took a while for the situation to be understood. But the rather concerning thing was, that rather than contact the Debian maintainer privately and discuss his objections and come to a mutual agreement, he chose to flame the entire project in public, with very serious allegations. Rather than engage the maintainer in a civil manner to resolve the problem amicably, he chose to flame the entire project with baseless allegations and rambling diatribes.

This flae spawned a very long thread, that covered all sorts of issues. The GPL, the GFDL, credits, invariant sections and all sorts of topics. There were many important points raised, not all directly relevant to the point in question.

Reiser chose to release his code under the GPL. Yet he seeks to impose additional restrictions against users of his software, making it less free, and incompatible with the GPL. The credits blurb is not the same thing as the copyright notice; the latter is a legal requirement, while the inclusion and display of the credits is not covered by the license.

Why couldn't the software contain a line like:

ReiserFS is Free Software, distributed under the GPL
Use the '--credits' flag to show a list of contributors to this project

This is clear, unobtrusive, retains the spirit and respects the letter of the GPL, and still permits the user to see the credits without having it thrust upon them.

The ITK packaging saga...

| No Comments

Flying in the face of conventional wisdom, I decide that my first real packaging task for Debian is going to be The Insight Toolkit (ITK), a set of medical image processing libraries, for segmentation and registration. (I use this for my research.)

ITK is large, complex, has a non-trivial build system, consists of multiple shared libraries, Doxygen documentation, example programs, applications, and more. Typically the sort of thing you would avoid trying to package, at least until you had packaged some simpler programs.

I love a good challenge...

I started the packaging process a few weeks ago, beginning by examining how VTK is packaged. It is from a related project, and uses the same build tool (CMake). So I set about figuring out how to make it build. It turns out that the first 90% took about 10% of the effort...

The first problem was getting CMake to behave. Since Debian has very strict packaging guidelines, I needed to make sure the end result of the build would follow policy. And I needed to automate the build process, whereas you typically use CMake interactively to set it up.

Fortunately, after Maitland Bottoms (VTK maintainer) advised me on how to prime the build process with the CMakeCache file, I got the build going.

After a while, I got the control, rules and other related debian/* files set up mostly properly, and got a build going. With a small amount of tweaking, I eventually had the thing building.

But ITK puts the libraries in /usr/lib/InsightToolkit, along with the .cmake configuration files. If I left them there, it would potentially go against policy (not sure on that point) and it would certainly require modifying /etc/ld.so.conf, something I didn't want to do lightly. Instead I chose to move the libraries up to /usr/lib, leave the cmake files where they were, and change the build scripts to suit. A few more tweaks later, and it was mostly working ok.

But then came the shared libraries...