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
(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
According to the preface:
You can now browse and search the entire content of this book at http://ladweb.net
to make this book even
more useful to you.
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)
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
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:
Community members and organizations can start using the "Firefox
Community Edition" and "Thunderbird Community Edition" trademarks
from day one, but the Mozilla Foundation may require individuals or
teams to stop doing so in the future if they are redistributing
software with low quality and efforts to remedy the situation have
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:
...we need to keep enough control over our trademarks to make sure
they are a sign of quality and safety. It needs to be impossible,
for example, for someone to release a product called 'Firefox' that
has added spyware. We want to avoid someone building a
highly-optimized but unstable build and passing it off as
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:
We want people to use Thunderbird in Debian, and to know they are
using Thunderbird, and to get the high quality experience people
get from using our Thunderbird. And we want to come to some
arrangement with Debian to make that possible.
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:
However, you guys want the freedom to ship software that sucks -
or, more to the point and more likely, want to be able to easily
give your software to other people and allow them to make it suck
and then ship it. If that software ships using our trademarks, then
that is incompatible with our trademark goals. So if we can't come
to some arrangement that lets Debian use them but asks
redistributors to contact us or remove them, then it's increasingly
looking like we can't square this circle.
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)
On January 11, IBM announced
that it would make 500 patents available for use in projects using Open Source Initiative
The list of patents and IBM's pledge is available as a
. 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
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
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
Comments (26 posted)
Page editor: Jonathan Corbet
Next page: Security>>