Leading items [LWN.net]

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:

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

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:

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

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)

The European software patent vote

September 24, 2003

This article was contributed by Joe 'Zonker' Brockmeier.

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:

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

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)

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:

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)

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:

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

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

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 becomes unnecessary.

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

Comments (16 posted)

Page editor: Jonathan Corbet
Next page: Security>>