Attending Linux trade shows is a lot of hassle, particularly when you have
to drive a couple of states to make it to the location. However, this is
greatly mitigated by the fact that one has the opportunity to speak face to
face with some of the more interesting people in the Linux community. This
week at Linux World Conference & Expo, I had the chance to speak with
Eben Moglen, President and Executive Director of the Software Freedom Law
Center.
The interview touched on the
Software Freedom Law Center, the revision process for the GPL version 3 and
several other topics.
LWN: What's the status of the Software Freedom Law Center, what kind of
activities are going on, and its funding?
The status is making a law firm is an interesting activity, particularly if
you're building a small business on Manhattan island. I've spent more time
on real estate and physical details of making it work than I thought we
would, but we're successfully housed and we're hiring lawyers and we've
been recruiting clients and releasing some press about the clients we've
recruited and that process is scaling up, we expect Dan Ravicher my junior
partner and I to have at least two more lawyers, maybe three more hired
during the next few months and we will be looking to hire some young
people, freshly graduating from law school this coming spring and
entertaining our first international fellows starting this year.
As for funding, we've received now two rounds of funding from OSDL, which
has been acting as our agent for collecting from a number of vendors, they
have been gratifyingly reliable in the funding of our firm, and I have no
reason to believe that there will be any difficulty. I think the principle
that better support for developers is good for business is now firmly in
everybody's mind and we have been very graciously entrusted with the task
of making that happen.
LWN: A while back, you said something about getting an answer from Linus on
the Linux kernel license. Since there is a COPYING file that makes it clear
that the kernel is governed under the GPL, where's the uncertainty?
If the kernel is pure GPL, then I think we would all agree that non-GPL,
non-free loadable kernel modules represent GPL violations. Nonetheless, we
all know that there are a large number of such modules and their existence
is tolerated or even to some degree encouraged by the kernel maintainers,
and I take that to mean that as an indication that there is some exception
for those modules.
The kernel also maintains a technical mechanism, namely the GPL-only
symbols and tainting structure, which seems to suggest an API for the
connection of non-GPL'ed code to the kernel, which also seems to me a
strong indication of the presence of an exception. The difficulty as a
lawyer, even a lawyer that is reasonably knowledgeable about these matters,
is that I don't understand what the terms of that exception are.
So, say I want to audit a system, say an embedded product, in which I find
non-GPL loadable kernel modules present, how do I know whether that fits
within an exception which is legitimately available to third parties and
when it is not?
Linus has said over the years a number of things about how he would not
object to anything that was not in obvious bad taste, or ugly, or awkward
or unacceptable and I understood, I think, what he meant at each of those
particular times. But it would be helpful in applying an analysis from a
lawyer's point of view, and think about the problem.
One very important area is the problem faced by people who make
software-controlled radios, which they want to run in systems which make
use of the Linux kernel and other GNU and free software. Those parties may
feel they're under regulatory orders not to release source code modules,
because regulators in Japan and Europe and the United States have all, to
differing degrees, made clear to manufacturers of radio transmission
hardware that if they allow after-market modification that violates
spectrum control regulations they may be in trouble. The Japanese in
particular have been very strong in their wording.
So then there are parties in the world who think they are in legal trouble
on one side with the regulators if they do release source code for loadable
kernel modules that drive their software-controlled radios, and they don't
know if they're in legal trouble on the other side if they don't release
source code. For those parties, in particular, it would be very helpful if
the kernel developers had decided to formalize the nature of their
exceptions, and the Free Software Foundation and I have made a few attempts
to discuss that matter with kernel developers. I had conversations with Ted
Ts'o, I talked to Linus about it and I understood there were some
reluctances to clarify, in a full and complete way, what was going
on. There may have even been disagreements among kernel developers about
that, I wouldn't know. But I continue to think that it would be useful, for
a whole variety of people who are trying in good faith to do the very best
they can, and who may be navigating some dodgy legal territory, for them to
be able to refer to something beyond the COPYING file which -- with all due
respect -- I think probably doesn't contain all the terms that are relevant
to the use of the kernel.
LWN: So, if the kernel is covered solely by the GPL, you would see
proprietary modules as an infringement?
Yes. I think we would all accept that. I think that the degree of
interpenetration between kernel modules and the remainder of the kernel is
very great, I think it's clear that a kernel with some modules loaded is a
"a work" and because any module that is dynamically loaded could be
statically linked into the kernel, and because I'm sure that the mere
method of linkage is not what determines what violates the GPL, I think it
would be very clear analytically that non-GPL loadable kernel modules would
violate the license if it's pure GPL.
LWN: Should distributors of proprietary modules then be worried about infringement?
As a matter of fact, I think they are worried about it, and that's why I
think that clarifying the license terms would be helpful. If there are no
exceptions and that were stated very clearly then they would know that's
not the way to do what they're doing. If there are some exceptions
available, for example for people who have no legal choice, they'd like to
know what those rules are and I'm sure lots of other lawyers around the
community would too.
LWN: The Free Software Foundation put out a press release
about a year ago
saying that the reason that SCO was attacking the Linux kernel and not
attacking GNU was because of the FSF copyright assignment policies of the
FSF, do you still see it that way, and why is the kernel vulnerable when
GNU is not, in that case?
I think what I said then was not that the reason was, because I truly
didn't know what the reason was why Mr. McBride did anything at all. I
think what I said was, I took from the fact that they were fulminating a
great deal about the illegality of the GPL and the badness of the Free
Software Foundation, and yet weren't objecting to our code was because they
knew it would be particularly easy to show that they were wrong.
I think that what I said was, that a process of taking a copyright
assignment process from each contributor, accompanied by a legal indemnity,
promising that the code was the code of the contributor and that there was
nobody else with a dominating interest in it and doing so at the point of
an indemnification promise to the Free Software Foundation produced a very
strong chain link fence between us and claims of the kind that SCO was
throwing around and I thought that constituted an indication of a cautious
and prudent model of how to put free software together which Stallman had
been following since long before I worked with him in the construction of
the GNU Project. That didn't mean I think, that it was the only way to put
together code that is strong, but where it works, it's a highly desirable
model to pursue.
Linus eventually found another formula, which suited his view of the way
the kernel development process works for introducing some accountability in
the contributions process, and I thought that was a very good idea, and I
said so. I think that if all the free software in the world were assembled
in the most prudent and conservative fashion, that Mr. McBride and his
colleagues would have found no place to even begin with the FUD with which
they began. I think it's also important to point out that we all thought
those accusations were baseless to start with and had good reasons to think
they were baseless to start with. There wasn't anything wrong with how the
kernel is put together. If there was a statement to make, it was simply the
way the kernel is put together doesn't prove on its face the cleanliness of
how it was put together with the degree of strength that otherwise could
have been mustered.
I would advise clients of the Software Freedom Law Center, in light of SCO
and many other things to begin their projects in ways that document and
protect more carefully that structure of how free software is put
together. But I understand completely how Linus Torvalds, living in Finland
as a University of Helsinki undergraduate, unadvised by counsel, would not
have chosen what I would now recommend to my clients to choose.
LWN: You made a comment about patent holders shaking down users of free
software for royalties. I haven't heard of any situations where this is
happening, can you tell us how bad the problem is, why it's not being made
public when it happens?
Well, I think I can say why it isn't being made public, when a manufacturer
of products with embedded free software, or user on a large scale of free
software is the subject of claims such as this, from a company such as
Microsoft, if they take a license and pay it's because they want peace and
quiet. If what they want is peace and quiet, they'll be quiet about how
they procured peace. The result of which, we won't hear except in an
indirect way. That's why it's not public.
Why it's not a good idea is that each one of those parties that procures
peace and quiet for itself is doing harm to the others in the ecology. Each
one that takes a license strengthens the apparent patent claim that they
are paying tribute on. The result of which is to strengthen the hand by
which the troll tends to pick somebody else up later on. From an ecological
point of view, we're concerned about the health of the entire
community. You'd like to say to such people, before you pay that license
fee, can you talk to about why that patent FUD may be just FUD? Could we
discuss what we know about the patents held by the parties shaking you
down? Could we present to you why maybe those patents aren't very strong
and maybe not an appropriate basis for the payment of tribute. In other
words, could we maintain a united, consolidated front.
The problem with the private license deals, they affect our solidarity and
our ability to act defensively as a community together. And whether they're
done publicly or not by the party who took the license, there's always a
risk they'll be trumpeted by the patent holder as a sign of the strength of
its patent and the degree to which other people should be afraid. So, when
I have some reason to believe that some such situation is in progress, I
often make an attempt to communicate with the party taking out a license,
and often they won't talk and they prefer peace and quiet. I think that
more respect for the needs of the community would be an appropriate leaven
in their decision-making process?
LWN: How bad is the problem? Is this happening a great deal?
Well, I'm not in a position to say how often it's happened of course, since
I'm sure I only know about a fraction of when it's going on. It's pure
chance when we discover it, sometimes. I think it's bad for the reason I
have suggested, that everybody knows... the patent problem is a real
problem, and it needs a real solution. And you see people like the Open
Source Development Labs stepping up and trying to create collaborative
means to address the problem. Everything that subtracts energy from that
attempt to collaborate to solve the problem, is in itself making the
problem worse.
Without unduly criticizing businesses that are making business decisions,
they're paying money to have peace, which is perfectly understandable to do
and may be culturally particularly appropriate in certain national
settings, I think that overall it creates difficulty for us, it aggravates
the problem of patents overall.
LWN: There's a draft bill in the House right now, that would restructure
the patent system, would it be good for free software?
It would not be bad for free software if it passes. That is to say there's
nothing in that bill that aggravates the problem. Many things that were
originally proposed in that bill that would have been good have been
removed in the process of discussion.
My particular analysis is that, at the
moment, the legislative process is stalled. I do not expect any movement in
that legislative process. I think that, for the moment, that initiative is
in the deep freeze. My analysis is that the power of pharma to control what
happens to patents in the United States Congress is nearly absolute. The
Princeton health economist, Uva Rinehart, who was a major advisor to the
Clinton task force and is one of the most knowledgeable health care
economists in the United States referred recently in a National Public
Radio report I was listening to, to the pharmaceutical companies'
"substantial equity stake in the United States Congress," and I thought that was
a very elegant way of putting it.
My belief is that until such time as there is a deal which includes the
pharmaceutical companies, there is very little enthusiasm in the United
States Congress for meaningful patent reform.
I must say, as a person who represent parties who are very afraid of what
patents can do to them, I think that this operation is very largely a
sideshow. I think it was intended to give the impression that things were
being done, and I think that people, in good faith, who want good outcomes,
nobly put their shoulders to the wheel and tried to turn it. But I do not
believe it will turn this time. I don't think it's going to turn
until we make some serious attempt either to disengage the interests of
pharma from IT and pursue sector-based relief from the patent problem or
until we step up to the problem that the patent system doesn't work very
well under 21st century conditions and no matter what the pharmaceutical
companies think it needs serious reform.
LWN: You've encouraged free software developers to get patents on unique
ideas. Is that happening much, and what resources are there for developers
who want to obtain patents?
The grave difficulty in operating in this direction, which Mr. Stallman and
I have been thinking about for years now, in order to be efficient in
obtaining patents, you need to associate patent lawyers with patent agents
with engineers in the very early stages of design and development of
inventions.
You need to have people there right along, it's very inefficient to try
after a project is over to develop the patent applications. Moreover, in
the United States patent law, once you have gone on sale, which includes
public distribution of free software, you have a year to file a patent
application and after that you may not file at all.
The consequence of which is that there are both resource constraints and
deadlines, which are very serious given the way that the free software
development process works. Having patent agents and lawyers working along
side developers is not a possibility. It's not efficient and it's not the
way our community operates.
The result is that the process of getting patents for free software, to
build a pool, is almost impracticable while the developer community is
spread very thin and very little of it works for large technology
businesses with established processes for the getting of patents.
On the other hand, resources may flow towards that in the same way that
they have flowed towards the Software Freedom Law Center. I think that one
of the most important things said in the OSDL announcement yesterday is
that there would be resources for patent prosecution, that is for getting
patents, available to developers who came forward and wanted their patents
to go into the patent commons. That represents the first significant
movement behind patent prosecution, behind getting patents. It's one of the
things I hope people will notice about what OSDL has said, because I think
it's an important strategic advance.
Will it work in that sense across the enormous range of free software
projects? No, I don't think so, we're just at the beginning, we'd have to
scale that in many different directions. But, in some crucial projects,
important to our commercial partners in this process, and large numbers of
users, and tightly coordinated development teams that have worked in large
technology companies and know how the patent-getting processes work, in a
range of conditions that are satisfied only in some parts of our community,
I think there will be some real progress. I think you will see our
inventions patented and there will be some cross-licensing negotiations
that will be effective for us in gaining some use of other people's patent
claims free of legal difficulty.
LWN: In the framework you talked about, these patents would be assigned to
the commons, so that they couldn't decide to abuse them.
One of the things we need to do is arrange all of the legal infrastructure
so that it works well for everybody. Yes, I think that's a reasonable thing
to expect, there will be safeguards to prevent that kind of change of
heart...
LWN: Let's talk about DRM. If the GPL requires distribution of scripts that
control compilation and installation of an executable, does that extend to
the binary keys for DRM?
I think the answer to that question is no. Under the existing GPL 2, the
better argument would be that those are not covered by the definition of
complete and corresponding source code under section 3 of the license. One
could change that definition in a future version of the GPL, and say, for
example, it's a straightforward idea, you could say the encryption keys
that make it possible to run this software on the hardware on which you are
receiving the software.
It is a possible approach. I think there are very significant difficulties
with it, including the possibility we would pinch off a whole system of
hardware in the world and say "free software doesn't run there." I think
that might be a strategic mistake for the free software world, to say "we
are going to write off a whole generation and form of hardware and not even
attempt to bring freedom there..." I think we would risk leaving a whole
lot of people in a condition of unfreedom for a long time.
I think unless
we are prepared to be more sophisticated in our approach to this -- this is
a very ham-fisted approach, the idea that you buy a computer and are not
allowed to be in charge of it. It's a very anti-consumer thing to
do. Instead of building an electric fence around it, as though it were some
kind of bad place we don't want to go. I think we have a duty to bring
freedom there if we can, and we need to empower consumers to reject such
hardware and my hope is that in a future version of the GPL, we will devise
something elegant and effective at using the gravitational force of freedom
to unlock that place over there, and not just seal it off.
LWN: You talked a bit at the beginning about software-controlled radios and
why they're important, do you want to add to that?
I've published pieces about that. If we are interested in freedom,
generally, one of the things that we have to recognize about the 20th
century is that there was a great degree of unfreedom that was generated by
control over spectrum. Governments around the world either controlled
spectrum themselves or delegated control to a small number of powerful
people, and that affected 20th century politics very, very deeply.
It was also a technical response to a problem that doesn't exist with
intelligent devices that exist in the 21st century... the technical
rationale for the concentration of spectrum in a few hands is gone, and
there never was a social rationale for that concentration of spectrum. It
was never the case that the public trust that held the common property of
the airwaves needed to be dealt with in a concentrated fashion for social
or political reasons, the only justification ever given was a technical
one.
So from my point of view, the world of devices that know about the spectrum
and deal with it intelligently can promise more democracy in media than we
ever had before, just as the web did for publication of text and is now
doing for video. We need to be alert to the fact that the way we deal with
software-controlled radios and the ability for people to use the spectrum
themselves the way they want to, is a very important political and social
issue in the 21st century. That's why I pay very close attention to how the
free software world interacts with the world of spectrum control and
regulation. 15 years from now, that's where the action is and I want to get
the early stuff right if it's at all possible to do so.
LWN: Can we talk a little about the GPL revision process? When you did the
GFDL process, some people thought they weren't listened to. What did you
learn from the process?
I don't disagree with you that the process that was applied to the
publication and modification of the GNU Free Documentation License would
not work very well for the GPL version 3. And I think you've given reason,
there's a very small group of people who need to be satisfied by and to use
the license and in the other case, there's everybody on Earth... The GPL
involves affecting a much broader community of stakeholders, much more
various and much more complicated, we need to be in touch with that
community as much as we can, and I think the process on that scale is a
much different process.
I also should say that although it is true the number of people using the
GNU FDL isn't that large, the number of people objecting to the FDL wasn't
all that large either. There were a small number of people who wanted to
say something and have their views heard. Whether they were heard or
whether they thought they were heard is two different questions... I don't
think there was a word written on that subject that I didn't read. Many
words written on that subject I had no desire to respond to because I
thought that response would only increase the intensity of the
discussion... my goal in helping the Free Software Foundation construct a
new GPL is to increase the lucidity without increasing the intensity. I
hope there is a lot less shouting and a lot more thinking next time around
by all parties.
LWN: Do you think that's likely?
I do. If you want to know what I think we've learned, I think we've learned
some things about increasing the lucidity without increasing the
intensity.
We'd like to thank Eben Moglen for taking the time to talk with LWN.
Comments (22 posted)
The SUSE Linux distribution has had a large and dedicated following for
many years. SUSE users appreciate the combination of the distribution's
administration tools, large selection of packages, and "German
engineering." This distribution has always been relatively closed in its

development process, however. There is no development version available, and even
beta tests have been closed affairs. SUSE has not, as a rule, invited its
users to be a part of the development process.
The opening up of the SUSE distribution was bound to happen, sooner or
later. Maintaining a major distribution is a major bit of work. But major
distributions have user communities which can help with that work, and
which can be the source of no end of good ideas as well. Bringing in the
user
community can improve the distribution, ensure wider testing, and, as a
bonus, further bind those users with the distribution. People
tend to be more enthusiastic about software which they have helped to shape
and polish. Red Hat figured this out some years ago, and most other major
distributions are created with a great deal of outside involvement.
SUSE Linux is now attempting to follow a similar path through the openSUSE project, which was officially announced
on August 9. OpenSUSE will play a
role similar to Red Hat's Fedora; it is a free distribution, developed with
community input, which will help to drive the development of SUSE's high-end
commercial offerings. Unlike Fedora, however, openSUSE will continue to be
available as a retail, boxed product. In this way, Novell hopes to make
the distribution as accessible as possible.
Since openSUSE is new, it lags Fedora in a number of ways. At the top of
the list would be the lack of an ongoing development version of the
distribution. The announcement of openSUSE included a beta release for
openSUSE 10.0, which is a step in the right direction (see our review
on this week's Distributions
Page). The occasional
beta release, however, is not the same as a bleeding-edge development
repository along the lines of Rawhide, Debian unstable, or Ubuntu's
"breezy." Your editor, who has not had a successful Rawhide update in some
time, currently finds his enthusiasm for development repositories to be at a
relatively low point. But the fact remains that making the current
development version of a distribution available facilitates early testing
and feedback. It also provides an experience some users want: riding the
leading edge of a fast-moving distribution is a great way to taste - and
participate in - the vitality of the free software community as a whole.
The openSUSE
"how to participate" page shows some parallels with the early Fedora
days. The first and foremost way for people to participate at this time is
to test packages and report bugs. Interested people are also encouraged to
submit patches, write documentation, or apply for a job. There is
currently no way for outside developers to apply changes or provide
packages themselves; the roadmap page states that
"a first version" of a build server will be made available in early 2006.
Given the frustration experienced by would-be Fedora developers, the
openSUSE folks would be well advised to get that infrastructure in place in
short order.
Some things are missing from the openSUSE site altogether. There is, for
example, no discussion of how openSUSE will be governed. Who will make
decisions on distribution policy, which packages will be included, etc.?
Fedora, instead, launched with detailed plans for various sorts of advisory
boards - and promptly ignored them all. More recently, Red Hat has been
talking about loosening its firm grip on Fedora; very little has been said,
instead, about just how independent openSUSE will be from Novell's
management.
Also missing is any discussion of the security update policy for openSUSE
releases. SUSE's security response tends to be rapid and thorough. The
same has traditionally been true of Red Hat, but Fedora brought with it a
new policy on security patches. Updates tend to come quickly from Fedora,
but the short period for security support makes Fedora a
relatively difficult platform for any sort of production use. That suits
Red Hat's goals nicely, of course - Red Hat is wanting to sell its
enterprise support offerings. It would not be entirely surprising to see
openSUSE take a similar path; hopefully the project will post a security
update policy in the near future so that its users will know what to
expect.
If the openSUSE project is to be successful, it must find a way to attract
developers and users, and to keep them happy. There is quite a variety of
community distribution projects out there, and many of them do not have any
apparent conflicts of interest with corporate goals. OpenSUSE will have to
distinguish itself from those other distributions somehow. The openSUSE
FAQ gives a hint as to how the project's leaders are hoping to proceed:
The openSUSE project explicitly looks beyond the technical
community to the broader non-technical community of computer users
interested in Linux... Only the openSUSE project refines its Linux
distribution to the point where non-technical users can have a
successful Linux experience.
The "only" claim is certainly debatable, but, with SUSE Linux as a base,
the openSUSE project has a solid base upon which to build in that
direction. There will always be room for a well-designed, robustly-built,
user-oriented Linux distribution.
Comments (3 posted)
It has been some time since the SCO Group has graced the LWN front page.
That situation is just fine with us; there is no end of more interesting
stuff happening out there. A couple of events this week merit a bit of
attention, though. Even as it heads toward total irrelevance, the SCO
Group is worth watching.
SCO launched its annual SCO Forum (evidently a rather smaller event this
year) with a
delightful open letter from Darl McBride. The letter, in some ways, is
classic Darl; full of bluster and easy to refute. It's almost like the
good old days, before SCO's lawyers finally got him to keep his mouth
closed. Others have taken on the task of writing detailed rebuttals of
this letter; there is no real point in doing it here.
What is truly worth noting in the latest open letter, however, is that it
contains no threats to sue anybody. Darl, instead, seems to have concluded
that he should maybe think about trying to sell some software. As a
result, his letter is all about showing why OpenServer is better than
Linux. It is FUD from one end to the other, but it is boilerplate
commercial FUD of the type we have seen before. Darl seems to be working
from the playbook that Microsoft discarded (as ineffective) some years
ago. The "Linux has no support" line is a holdover from the 1990's. It
didn't work then; there is no real reason for us to worry about it now.
The SCO Group seems to have concluded that the litigation lottery ticket is not going
to pay off, and so is putting its effort into plan B. Had the company
done that a few years ago, it might have gotten somewhere. At this point,
however, SCO seems unlikely to survive the countercharges being leveled
against it. Novell's attempt to force SCO's remaining cash into an escrow
account could, on its own, suffice to end the show - before companies like IBM
and Red Hat even begin to get their licks in.
Some additional amusement can be found in IBM's
deposition of Erik Hughes, a SCO employee. One widely-reported outcome
from this deposition (which was just recently unsealed) is that it seems
likely that UnixWare's "Linux Kernel Personality" product included Linux
kernel code for a couple of releases. If that is indeed the way of things,
SCO may have been in violation of the GPL - at the same time it was
charging copyright infringements by others.
Remember the "Chris and Darl show" teleconferences from the early days of
the IBM suit? One could almost get nostalgic about those bizarre
exercises. Your editor would always try to get a question in, but,
somehow, tragically, time always ran out before the question could be
asked. In August, 2003, a message was sent
to SCO's Blake Stowell and Chris Sontag asking a question which was not
heard during the teleconference: noting that the 2.4 kernel was still
available from SCO's FTP server, your editor asked just how SCO was able to
reconcile its claims over the kernel with the GPL and its distribution of
vast amounts of code over which it could have no possible claim. An
interesting, private conversation resulted, in which a SCO employee stated
that he did
not think the GPL was valid. Nothing publishable ever came from the
exchange, however, and your editor had long since forgotten about it.
It can be a surprising experience to run across one's name unexpectedly in
a legal document. IBM's lawyers, it seems, found that old message and
brought it up in the Hughes deposition. Your editor, it seems, was one of
a group of "long-haired smelly's" asking about the contradictions inherent
in SCO's continued distribution of Linux while claiming that it contained
SCO's proprietary code. The continued availability of the kernel on SCO's
site has been well documented; the "smelly's" helped to document that SCO
knew it was a violation of the GPL at the time.
In retrospect, it seems clear that IBM's lawyers could have disposed of the
SCO threat on their own. That notwithstanding, the community's
"distributed defense" response to this attack is notable. As a group, we
dug up vast amounts of information, poked holes in SCO's claims, and
singlehandedly won the PR battle (which IBM could not engage in). Anybody
contemplating an attack on the free software community will need to think
long and hard about how to handle the community's response. On the other
hand, the sheer buffoonery of SCO's attack presents a risk of its own:
somebody may well decide that SCO's failure resulted from poor execution,
rather than an inherently bad idea. Should that happen, we may have to go
through all of this again.
[Coming soon: the Grumpy and Malodorous Editor's Guide to All-Natural
Deodorants.]
Comments (11 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: mod_spambot; New vulnerabilities in gaim, sysreport, ucd-snmp, and xpdf.
- Kernel: Robust network-based block I/O; kzalloc(); Merging GFS; Realtime preemption overview.
- Distributions: First Look at SUSE Linux 10.0; Red Hat: Fedora Foundation moving forward; Debian Core Consortium launches; cdmedic
- Development: The Cairo Vector Graphics Library, new versions of
DomainKeys library, active port forwarder, Scapy, mod_spambot, demexp,
DSpace, Ecasound, JAPA, Rivendell, PYWM, Open Clip Art Library,
pyGame Utilities, KMidimon, OpenOffice.org, Gourmet, OmegaT, POE, gputils,
Valgrind.
- Press: Qt, the GPL, Business and Freedom, GPLv3 process and software patents,
OSCON 2005, Linux World, SCO's future, Municipal WiFi ban?, ClamAV patent
problem, NX examination.
- Announcements: LinuxWorld press releases, open letter from Darl McBride, Wine Installer Challenge, Hollywood pushing closed hardware, Open Source Press Release Database, numerous Calls for Papers.
- Letters: The threat of virtual machines; Free software ratings.
Next page:
Security>>