Last July, Red Hat let it be known the Red Hat Linux, as a retail product,
was coming to an end. Red Hat's customers would be steered, instead, at
the company's "enterprise" products, which are aimed at corporate needs
and, incidentally, bring in a lot more revenue to the company. The
company's strategy has had some success; Red Hat's recently announced
quarterly results show an increase to about 26,000 Enterprise Linux
subscriptions. Those subscriptions brought in almost $15 million in
revenue over the quarter (enterprise services brought in another
What replaced Red Hat Linux at that time was the "Red Hat Linux Project,"
an attempt to transform the process of making Red Hat's core distribution
into a more open, community-oriented project. Now, this distribution has
gone through another change, as announced
on September 22:
Red Hat and Fedora Linux are pleased to announce an alignment of
their mutually complementary core proficiencies leveraging them
synergistically in the creation of the Fedora Project, a paradigm
shift for Linux technology development and rolling early deployment
The rest of the announcement, thankfully, is in English.
The old Fedora Linux
Project was an independent effort to create a set of high-quality
add-on packages for Red Hat Linux. Fedora had managed to put together a
set of policies, a development community, and an initial set of packages.
Red Hat, in its effort to kick-start the Red Hat Linux Project, saw value
in all of those things. So now the two projects have merged into a single
entity called the Fedora project.
The project stuck with the Fedora name, among other reasons, so that the
resulting distribution would not run into trademark problems with the Red
Hat name. (There may yet be confusion with the Fedora Project hosted at Cornell, which is
developing a free digital repository management system.)
Red Hat is still putting together policies and documentation for the new
project, so some of the details are still coming into focus. The project
leadership role will be in the capable hands of Michael K. Johnson, one of
the Red Hat originals. There will be a a steering committee appointed by
Red Hat; it currently consists of Karen Bennet, Cristian Gafton, Michael
K. Johnson, Jeff Law, and Stephen Tweedie. The plan also calls for an
advisory committee, the makeup and duties of which has not yet been
determined. Finally, there will be a "technical committee," which is
simply the union of the steering and advisory committees.
The Fedora project's output will consist of three distinct sets of
- The Fedora Core will be something that looks like the current
Red Hat Linux distribution. It will be the basic distribution that is
released by the Fedora project; everything that is in the core
distribution will be approved by the steering committee.
- The Fedora Extras is a set of additional packages which
complement the core distribution. The Extras are strict add-ons; they
cannot conflict with or replace packages in the core distribution.
Among other things the Extras will be a sort of staging ground for
packages (and their maintainers) to prove themselves before being
admitted to the Core
distribution. The technical committee will decide which packages get
to be in the Extras.
- The Fedora Alternatives is the "contrib" area of the Fedora
project; just about any package can be in the Alternatives as long as
it is free software and doesn't run into legal problems.
The project planners also foresee a "Fedora Legacy" area for the
maintenance of older packages, and a "third party" area that will become
the Fedora equivalent of Debian's non-free. Red Hat will have nothing to
do with the non-free code, however.
According to the posted schedule, the
"test 2" release of the Fedora core is due on September 25.
There is a third test release planned for October 13, and the final
release should be out on November 3. Then work begins on "Fedora
Core 2", which will be, with luck, based on the 2.6 kernel.
To succeed, Fedora must attract a significant amount of community interest
and input. Red Hat needs external developers to help with the maintenance
of the distribution and bring in new packages. It also very much needs
an active user community which will test and deploy the Fedora
distribution; to a great extent, Fedora will be part of the quality control
process that packages go through before becoming part of the enterprise
Bringing in developers will require making them feel like something other
than unpaid Red Hat employees. That means giving Fedora a life outside of
the company. Red Hat seems to understand that need;
for example, Red Hat's Havoc Pennington says:
Red Hat will be doing a lot of development and other work on the
Fedora Project, but it's not a product that you can buy from
us. We're working on the Fedora Project in the same way that we
work on other projects such as Mozilla or the Linux kernel.
Of course, this claim is not entirely true: Red Hat does not name, by fiat,
the members of any "steering committees" for Mozilla or the kernel. But
the idea the company is trying to get across is clear: Fedora, as a
project, is separate from Red Hat and its products.
degree to which that is true, and to which Red Hat can step back and let
Fedora find its own path will
be crucial to Fedora's success. Letting go could be hard for Red Hat to do;
almost anybody who has done business with that company will attest that Red
Hat, while well-intentioned, very much likes to retain control over the
projects it works on. Red Hat also has a history of working well with the
free software community, however; they understand well how the free
development process works. So when the company says
Anyway, it's not just about what Red Hat developers work on
anymore. Anybody can drive the project in a different direction by
developing the code and making a case for including it.
There is a good chance that things will work out that way.
Comments (19 posted)
Members of the European Parliament (MEPs) passed Arlene
's proposed patent directive this Wednesday, with numerous amendments
that may mean a victory for the open source community and others opposed
to software and business practice patents. The full text of the passed directive
is available for those who are interested (thanks to James Heald). As a result of the Foundation for a Free Information
(FFII) and many others, software patents in Europe
have been staved off -- for now.
However, we have miles to go with regards to the directive. This vote is
not the final say in the matter. The European Parliament will vote again
on the directive, but after it has been addressed by the European
Commission (EC). It's entirely possible that the directive passed by the
parliament will be rejected by the EC, or that the original directive
without the amendments will be approved by the EC. LWN reader Ciaran
O'Riordan notes that in the
event that the original is approved, Parliament will not have a second
chance to address the directive and McCarthy's original draft will be
Under the amended directive, an inventor may patent a "programmed
device," but patents on software and business methods are specifically
excluded. Amendment 3a specifically disallows any patents in the field
of data processing, while 2b specifically requires an invention to be
"susceptible of industrial application." Amendment 2d specifies
"industry" as the "automated production of material goods." Presumably
this means that one cannot patent entertainment devices or other goods
specifically targed for consumer use.
Further, patent applications for programmed devices must include "a
well-functioning and well documented reference implementation of such a
program is published as part of the patent description without any
restricting licensing terms." This means that, should the amended
directive go through, inventors will not be able to prevent
interoperability with their devices through obscurity. Readers in the
United States may be interested to know that the U.S. government has chimed
in with opposition to article 6a, which states that patents can not be
used to block interoperability:
Member States shall ensure that, wherever the use of a patented
technique is needed for a significant purpose such as ensuring
conversion of the conventions used in two different computer systems or
networks so as to allow communication and exchange of data content
between them, such use is not considered to be a patent infringement.
The amended directive is a vast improvement over McCarthy's original
proposal. However, Jonas Maebe, a Belgian FFII representative, says the
approved draft still needs work:
The recitals were not amended thouroughly. One of them still claims
algorithms to be patentable when they solve a technical problem. But we
have all the ingredients for a good directive. We've been able to do the
rough sculpting work. Now the patching work can begin. The spirit of the
European Patent Convention is 80% reaffirmed, and the Parliament is in a
good position to remove the remaining inconsistencies in the second
That assumes, of course, that there is a second reading to be had. When
speaking to Parliament during the Plenary Debate the day before the
vote, EC Commissioner Frits Bolkestein issued (PDF format) a not-too-veiled threat to remove parliament from the process entirely:
If we fail in our efforts to achieve a harmonisation of patent law
relating to computer-implemented inventions in the European Union, we
may well be confronted with a renegotiation of the European Patent
Convention. The process of renegotiation of the European Patent
Convention would not require any contribution from this parliament. So
the situation is clear: there is a single objective but a choice of
means. Either we proceed using the community method, or we take a back
seat and watch while member states go via the route of an
intergovernmental treaty. It is clear that proceeding via this
Parliament would give European citizens a greater say in patent
legislation, an area which is so crucial to our economy.
A renegotiation of the European Patent Convention could be a worst-case
scenario for users of open source. While those who stood in opposition
to the original draft deserve congratulations and the opportunity to
enjoy their victory, they'll have little time to rest.
Comments (4 posted)
On September 23, HP held a press conference in which it extended an
indemnification offer to its Linux customers. If you buy a Linux system
from HP, the company will take on any liability that may eventually be
incurred toward SCO for the use of Linux. HP will also take on defense
against lawsuits filed by SCO. All a customer has to do (beyond buying
the system from HP) is to have a support contract and refrain from making
changes to the code.
To some, this move appears to have vindicated SCO's claims. Certainly SCO
didn't miss the opportunity rush out an even stranger
than usual press release on the subject:
HP's actions this morning reaffirm the fact that enterprise end
users running Linux are exposed to legal risks. Rather than deny
the existence of substantial structural problems with Linux as many
Open Source leaders have done, HP is acknowledging that issues
exist and is attempting to be responsive to its customers' request
for relief. HP's actions are driving the Linux industry towards a
licensing program. In other words, Linux is not free.
It is classic SCO to claim that indemnification supports its claims, after
arguing for months that the lack of indemnification supports it claims.
The market, in any case, read things slightly differently; SCO's stock fell
almost 10% after HP's announcement and SCO's PR.
In fact, a different interpretation makes a great deal of sense. HP, as a
company, has certainly made its share of mistakes. But HP is smart enough
not to wander into the path of a company prone to billion-dollar lawsuits
without being sure of its ground. HP is a Unix licensee; it has everything
it needs to verify for itself whether Unix code has truly been copied into
Linux or not. The obvious conclusion is that HP has decided that it has
little to fear. It would appear that SCO's bluff has been called.
Comments (1 posted)
Red Hat filed suit against the SCO group back at the beginning of August.
At that time, SCO's
was nothing if not aggressive:
Be advised that our response will likely include counterclaims for
copyright infringement and conspiracy. I must say that your
decision to file legal action does not seem conducive to the
long-term survivability of Linux.
That response was filed on September 15; thanks to Groklaw, the text
of SCO's response is now available online. It reads rather differently
than Darl McBride's preview had suggested. Rather than escalate the fight
with counterclaims and conspiracy charges, SCO is now trying to make the whole
thing go away.
The core of SCO's argument is that it has never actually threatened to sue
Red Hat, so Red Hat cannot ask for relief. There is nothing to be relieved
There are no allegations that SCO has contacted Red Hat and
informed it that its product violates SCO's copyrights. Nor has SCO
done so. There are no allegations that SCO has conveyed to Red Hat
either expressly or implicitly that it intends to sue Red Hat to
enforce its copyrights. Nor has SCO done so. There are no
allegations that SCO has sued any other entity for infringement. -
Nor has SCO done so.
If you go back to SCO's response to the suit, the company quotes a letter
At the time of your letter, we had expected the possibility of a
global resolution of SCO's intellectual property claims against all
Linux-related companies that would have likely included Red Hat. This
effort has apparently stalled, through no fault of SCO.
SCO's Linux license
FAQ contains this statement:
All distributions of Linux 2.4 and later versions of the kernel
contain major infringments, regardless of whether Linux is being
used in a commercial or non-commercial environment.
Since Red Hat is unarguably a "Linux-related company," the first statement
above could certainly be read to imply the existence of intellectual
property claims against it. Since Red Hat's products include 2.4 and later
kernels, the second statement is a clear claim that Red Hat's products
contain "major infringements." But now SCO is trying to say that such
claims do not exist.
This quote is also worth noting:
Red Hat, however, has never had any license from SCO providing
access to SCO's trade secrets or other confidential information
and, to SCO's knowledge, has not stolen or otherwise
misappropriated any of SCO's trade secrets or confidential
information. Therefore, unlike companies that have contractual
obligations to SCO, Red Hat has no legal or factual basis for
apprehension of suit by SCO with respect to trade secrets or
confidential information it has licensed from SCO, and its claims
in Count II can be summarily dismissed.
So, if you work with Linux, and you have never signed a contract with SCO,
you should have little to worry about. SCO states here that it has never
claimed that Red Hat Linux (at least) infringes upon its copyrights, and
SCO states explicitly that Red Hat cannot have stolen its trade secrets.
If nothing else, SCO's statements serve as another warning against signing
contracts with that company.
SCO goes on to say that, even if Red Hat could prove that it is right to be
worried about being sued, the court still should not hear the case.
The previously filed SCO v. IBM Case addresses most, if not all, of
the issues of copyright infringement and misappropriation. If these
issues are decided against SCO in that case, then Red Hat's lawsuit
One wonders how the IBM case can handle "most, if not all, of the issues of
copyright infringement" when, as stated earlier in SCO's response, "There
are no allegations that SCO has sued any other entity for infringement.
Nor has SCO done so."
The IBM case is a breach of contract case which has nothing to do with
copyright infringement. One presumes that
the judge in the Red Hat case will notice that.
SCO claims that the rest of Red Hat's complaints (mostly variations on
violations of fair trade laws) should be dismissed because SCO's behavior
is a simple exercise of its first amendment ("freedom of speech") rights.
SCO's Public Statements fall outside the scope of the Lanham Act
and related state law claims and are protected under the First
Amendment to the U.S. Constitution. The Public Statements also
address or relate to pending or potential litigation and are
privileged under the common law doctrine of litigation immunity.
According to SCO, even its "Linux license" is actually speech related to
ongoing litigation, and thus protected. A footnote in SCO's filing makes
the interesting additional claim that "SCO has never asserted in any
statement that individual, non-corporate users of Linux may be liable to
SCO, or otherwise would need to purchase a right to-use-license."
The filing finishes out with this fun little argument:
Indeed, SCO's Public Statements are also part of a wider debate in
the technology and music industries about the scope of intellectual
property protection in a digital age. As open source software
development becomes prevalent and digital music can be downloaded
for free, many people are simply ignoring copyright and patent
laws. Many public commentators recognize this disintegration of
property rights as a danger to our economic system. In a small way,
SCO's Public Statements are part of this debate. This is an
additional factor that weighs in favor of holding SCO's Public
Statements as fully-protected speech, not subject to the Lanham Act
or associated state law claims. It would pervert the First
Amendment to allow the Lanham Act to chill broad debate about the
relative merits, and problems, with open source software.
Free software developers are, in other words, the moral equivalent of those
who distribute copyrighted music over the net. And it is SCO's right to
be "part of this debate" by making its claims against Linux.
The conclusion that comes from a thorough reading of SCO's response is
clear: SCO does not want this fight, and is doing what it can to make it go
away. This is not a surprising position; a company which has picked an
intellectual property fight with IBM has little need or desire for other
legal distractions. SCO's move for dismissal looks weak, however,
especially when one considers that it has contradicted many of its own
claims in public statements elsewhere. The Red Hat suit is not good news
for SCO, and it is unlikely to be shrugged off so easily.
SCO is also weakening any case it might have against any other
Linux-related company. After going to such lengths to state that Red Hat
has nothing to fear from SCO, and that the IBM case covers everything, SCO
will will have to find some truly compelling "new evidence" before it can
turn around and file another Linux-related lawsuit. As SCO backs away from
its increasingly indefensible claims of direct infringement, all it really
has left is a contract dispute with IBM. It is not surprising that SCO
wants to free itself of the Red Hat suit and concentrate on its one, big
Comments (16 posted)
Page editor: Jonathan Corbet
Inside this week's LWN.net Weekly Edition
- Security: A different sort of bad week; new vulnerabilities in ipmasq, portable OpenSSH, ProFTPd, others.
- Kernel: dev_t expands; Selectable I/O schedulers; The beginning of the end for devfs
- Distributions: The Great Package Management Experiment
- Development: gLabels Version 1.92.0,
new versions of Speex, ZODB, CUPS, PyX, SPTK, wxWindows, Evolution, Mozilla,
Parrot, Perl, Python, Squeak.
- Press: Boot Linux faster, Open Choice Awards, Lobbying for Linux,
Linux in Schools, Vixie on VeriSign.
- Announcements: PIXIL released as open-source, Sophos acquires ActiveState,
PHP Survey Results, Open Source for non-profits, The PHP|Cruise.
- Letters: SCO Linux license; servers and tools; Sun and Linux