LWN.net Weekly Edition for September 25, 2003

The new Fedora Project

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 $9 million).

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:

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 packages:

• 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 products.

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:

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. The 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 something like:

There is a good chance that things will work out that way.

Comments (19 posted)

The European software patent vote

Members of the European Parliament (MEPs) passed Arlene McCarthy'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 Infrastructure (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 enacted.

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:

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:

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:

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)

HP offers indemnification

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:

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)

SCO to Red Hat: you have no complaint

Red Hat filed suit against the SCO group back at the beginning of August. At that time, SCO's response was nothing if not aggressive:

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 from.

If you go back to SCO's response to the suit, the company quotes a letter saying:

SCO's Linux license FAQ contains this statement:

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:

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.

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.

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:

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 fight.

Comments (16 posted)