LWN.net Weekly Edition for January 13, 2005

Review: Linux Application Development, Second Edition

In the late 1990's, Linux began to attract large-scale attention beyond the relatively small, hacker community which had been working on it for some time. With all that attention came many new developers who liked what they saw and wanted to be a part of it. The book that many of those developers kept next to their keyboard was the classic Linux Application Development (LAD), by early Red Hat hackers Michael K. Johnson and Erik W. Troan. LAD was published in 1998, meaning that, at this point, it is vastly out of date. The Linux world does not stand still, and does not make life easy for those who would publish technical reference books. Trust your editor on this.

So it was a pleasant surprise to see a new edition of LAD show up in the mail. This core text, it turns out, has not gone out of maintenance after all.

According to the preface:

As of this writing, the web site has not caught up with that claim - it still discusses the first edition (and with no "entire content") to browse. One assumes that situation will be rectified in time. If the book is being released under some sort of free license, however, that is not stated explicitly.

The structure and content of the book has not changed all that much from the first edition: LAD still concerns itself with low-level Linux programming, system calls, and some C libraries. The updates are to be found in the details: the text now matches, for the most part, the interfaces provided by the 2.6 kernel and glibc 2.3. Some new interfaces (such as epoll()) have been covered, and there is a new chapter on security pitfalls and how to avoid them. The discussion of the socket interface covers IPv6, the regular expression discussion has been expanded, real-time signals are covered, etc.

With these changes, LAD is, once again, the definitive reference for the low-level Linux C API. Whether you need to learn about memory allocation debugging facilities, the details of process management, file descriptor magic, or more, you're likely to find what you need in this book. Much of that information is also available in generic Unix texts; the difference is that LAD looks at exactly what Linux offers. While Linux follows the relevant standards to a great degree, there are many places where Linux diverges from the standards or offers extra capabilities. A reference book which documents the Linux way of doing things is a good thing.

That said, your editor does have some quibbles with the second edition. One is that the update appears, in many places, to have been done in a hurry. The LGPL is called the "Library General Public License" - but it has not had that name for quite a few years now. The recommended system administration book is Sobel's A Practical Guide to Red Hat Linux 8. The (new) documentation of strace claims that it writes to the standard output, which is not true (it writes to stderr). Passwords, it claims, are usually stored in /etc/passwd. Many flags to the clone() system call are missing; a number of mmap() flags are absent as well. Your editor may have been willing to forgive all of this if the authors, while being nice enough to mention Linux Device Drivers, had noticed that a new edition has come out since 1998.

Perhaps more to the point, however, LAD may be falling behind the way that applications are being developed for Linux. Your editor has certainly done his time writing ioctl() calls to control TTY parameters - but not recently. The chapters on virtual consoles and S-Lang seem rather quaint. While a great deal of Linux software is still developed in C, quite a bit is not. After reading LAD, one might almost conclude that graphical applications simply do not exist under Linux. The authors clearly had to limit their scope, and they cannot be faulted for failing to document, say, the GNOME and KDE libraries. But the second edition could have been an ideal vehicle for pointing developers toward the sorts of tools being used for new code, and away from writing TTY-oriented applications.

That said, application developers still need to understand how to manage memory, create processes, handle signals, work with files, etc. The second edition of Linux Application Development fills that need and more; it is a most welcome update. It will, beyond doubt, find a location very near the keyboards of a great many Linux application hackers.

Comments (2 posted)

Debian and Mozilla - a study in trademarks

The Mozilla Foundation is the keeper of a number of increasingly important projects, including the Firefox web browser and the Thunderbird mail client. These programs are free software, licensed under the Mozilla Public License. Thus, one would think, distributors would have no trouble including these packages in their distributions. As the Debian Project's experience shows, however, free software can still come with certain kinds of strings attached.

The issue at hand is trademarks. Mozilla Foundation software comes with trademarked names, and the use of those names is governed by the Mozilla Trademark Policy. If you want to distribute software called "Mozilla Firefox" or "Mozilla Thunderbird," you must adhere to a strict policy which includes signing an agreement with the Foundation and making almost no changes to the software. No extensions may be added, the list of search engines cannot be changed (they paid to be there, after all), etc. This highly-restrictive policy was never going to work with the Debian Project's needs.

Another approach is the "community edition" policy. A wider (but still narrow) range of changes is allowed, and the distributor can use the names "Firefox Community Edition." The commands can be called firefox and thunderbird. The Foundation maintains a veto right over uses of the "community edition" names, however:

So anybody distributing a "community edition" must live with the possibility of receiving a "takedown notice" from the Mozilla Foundation at any time. The Foundation's goals are certainly understandable:

Most readers will agree that a spyware-enabled Firefox is a bad idea, though whether purveyors of spyware will have much respect for trademarks is an open question.

The Debian Project insists on shipping nothing but free software, and freedom certainly includes the right to modify the code. Debian currently includes patches which may go beyond the trademark policy's guidelines - an extension manager which understands multi-user systems, for example. A strict reading of the community edition guidelines suggests that not even security patches could be distributed without prior approval from the Mozilla Foundation. The Debian Project certainly wants to be able to distribute modified versions of the code; the Project is also known for a close and literal reading of licenses. So the Debian developers are concerned about the whole trademark issue.

The Mozilla Foundation wants to work with Debian to get past these issues:

This arrangement could possibly include allowing Debian to apply its own patches to Firefox and Thunderbird and still use the community names. The Foundation seems to have a fairly high level of trust in Debian's ability to keep the quality up. Debian's users are another story, however:

So it looks somewhat like the Foundation would like to make a special policy exemption for Debian. The problem there is that Debian-specific licenses violate section 8 of the Debian Free Software Guidelines. Those guidelines apply to software licenses, not trademark policies, but the principle remains the same. The Debian Project is unlikely to accept a policy which does not extend to its users.

The discussion has quieted - it may have gone into a non-public mode - so it is difficult to say where things stand now. If an agreement cannot be found, Debian will still be able to distribute Firefox and Thunderbird - they are free software - but different names will have to be chosen. "Iceweasel" has been the working code name for this scenario; many other names have been suggested as well. This outcome would not be pleasing to any of the parties involved, however; one assumes it will be avoided if at all possible.

Mozilla is unlikely to be the last project that decides that it wants to achieve some sort of quality control through its trademarks. That wish is understandable, but it is also very much at odds with the spirit of free software, which involves letting go of the code. One has to accept that not everybody will have the same idea of what makes "high quality." Incidents of free software projects being harmed by distribution of poorly-done modifications have been rare, and, perhaps, are not worth the worry that is being put into them here. Mozilla has done an outstanding job of creating powerful and useful software; now, perhaps, the Foundation may want to relax and trust its users just a little more.

Comments (49 posted)

IBM's patent pledge

On January 11, IBM announced that it would make 500 patents available for use in projects using Open Source Initiative (OSI) approved licenses. The list of patents and IBM's pledge is available as a PDF. According to the statement, IBM has indicated it will not assert any of the 500 patents against distributors of open source software, so long as the distributing party does not file lawsuits using patents or other intellectual property rights against open source software.

The list of patents ranges from a "Method and apparatus for batching the receipt of data packets" (U.S. Patent Number 5,260,942) to a "System and method for ensuring QoS in a token ring network" (5,642,421). Given that IBM has listed 500 patents, this reporter has not had time to read each patent, but suffice it to say that the patents cover a wide range of applications from human language processing to web services and data processing.

Reaction to IBM's move has been mixed. OSDL's Stuart Cohen is apparently in support of IBM's pledge, and Larry Lessig was also quoted as saying that it was "exciting".

Others were not so impressed. Florian Mueller points out that "We're talking about roughly one percent of IBM's worldwide patent portfolio. They file that number of patents in about a month's time." Mueller also called it a "diversionary tactic, which may be accurate given IBM's support of the European Patent Directive that has been denounced by many of the leading members of the open source community.

There is ample room for skepticism. IBM's move offers up only a small portion of its patent portfolio for use by open source projects. To put it another way, IBM is withholding the remainder of its patent portfolio, without any assurance that open source projects (with the exception of the Linux kernel) are safe from potential litigation.

We spoke to IBM's manager of worldwide Linux marketing strategy, Adam Jollans, about the patents. Jollans said that IBM was "seeing a shift from innovation in commercial companies to cooperative innovation", and that the patent pledge was a way to support that.

We asked why IBM picked 500 rather than 50 or 5,000, or simply giving open source a pass altogether. Jollans said that IBM "has to start somewhere" and that 500 was a number that would prove it was a significant announcement. No reason was given for holding back the majority of IBM's patent portfolio. Jollans did say that IBM's choice of patents was not random, and were picked because they were "500 that we believe will be useful" to open source.

IBM's move could also be seen as an attempt to take some of the steam out of the anti-software patent movement in Europe as the EU considers a motion to start over with the software patent directive. We also asked why IBM had not chosen to take a stand against software patents altogether. Jollans said that IBM supported patents, but that "patents should reflect innovation rather than just a general idea".

Jollans said that IBM is encouraging other companies to step up and offer the use of their patents for open source as well. Whether or not any companies will do so is yet to be seen.

By offering only a small sample of its patent portfolio, IBM is well-positioned to take offensive action should it ever decide to do so. If there were an open source project that IBM wanted to quash, there are more patents where the first 500 came from. IBM has shown no interest in launching patent attacks against free software, and the company certainly understands what such an attack would do to its standing in the community. Even so, there's no guarantee that IBM will always be so well-intentioned.

Ultimately, IBM's "patent pledge" is a good PR move, but little more. IBM has little to gain from asserting its patents against open source projects, and stands to benefit from the continued development of Linux and other open source projects. By offering a non-aggression pact towards open source projects, IBM effectively says it's OK to develop programs that might infringe on (some of) its patents, so long as those programs are available to IBM under open source terms. That's a far cry from the desired outcome of barring software patents altogether, but it's still a step in the right direction.

Comments (26 posted)