Leading items

Fedora looks to increase Rawhide testing

Development branches of a distribution are generally hard environments to use because they tend to frequently be in a broken state—so broken that it is impossible to get one's work done. Fedora Rawhide is such a branch, which, up until recently at least, came with the scary warning: "Rawhide eats babies". So it is a bit surprising to see an effort to increase the number of Rawhide users. The benefits for Fedora are obvious, but the number of headaches and complaints that could come from more users might offset the extra testing that it would get.

Rawhide horror stories abound, but, in general, its quality has been improving in recent times. As part of a report from his recent orientation at Red Hat headquarters, Adam Williamson posted some goals for Fedora QA to the fedora-testers mailing list. The first specific goal listed—and the one that attracted most of the comments on his post—was to "increase participation in Rawhide". Williamson was formerly a community liaison with Mandriva and recently took on a similar role in QA at Red Hat. He outlined some specific steps that the QA group wants to take with Rawhide:

Mark McLoughlin suggested coming up with some criteria for what a testable ("dogfoodable" in his words) Rawhide looks like. Changes that cause it to fall below that line—because it doesn't boot or some core functionality, like networking or graphics, doesn't work—should be added to bugzilla as a RawhideBlocker bug. Pressure could then be applied to get those bugs fixed quickly. Interested testers would also have an opportunity to see if Rawhide was in a testable state before installing or updating.

Concerns were expressed about just who should be considered a good candidate for testing Rawhide. McLoughlin thinks "we should keep trying out new things to get it to the stage that anyone involved in Fedora development should be able to run rawhide". Williamson agrees:

But Bruno Wolff is worried that the bar is being set too low: "you need to be able to rescue your system when booting fails. I think you pretty much need to be an amateur sysadm." Williamson, based at least partially on his Mandriva experiences, is not too worried about that problem:

It is clear that one can run into problems with Rawhide, but the author was able to write the bulk of this article—along with handling a few other normal tasks—on a laptop running Rawhide from February 24 with few problems. The display would not default to the 1280x800 resolution of the laptop—likely caused by bug 485913—but that could be worked around by use of the KDE display setting program. Wolff also reported some nasty boot problems and alluded to kernel modesetting issues both of which would be problematic for a regular user to overcome. Some grumpy guy from LWN, who often runs on the bleeding edge, pointed out a few other issues (with tomboy, cups, and others) that he has run into using Fedora 11 Rawhide.

But, the only kind of testing that is likely to find these kinds of problems is real-world day-to-day use of the distribution—a quick install test won't show them. It is the classic chicken-or-egg problem that distributions face. Most distributions opt for recommending that users stay away from their development branches, instead awaiting alphas, betas, or release candidates. Finding critical bugs at that point is much more painful, however. Fedora is trying to find a middle ground between getting buried in bug reports, while still finding bugs as early as possible in the process.

Each user has their pain threshold that they are willing to bear while helping to improve the free software they use. Some have a threshold near zero, while others have enough experience—or masochism—to be willing to deal with the kinds of messes that can result from tracking a development branch. It is best for all concerned to make sure that the right message is sent, so that the right people are using Rawhide. If expectations are not set correctly, it could well leave Fedora worse off than it was before. It is an interesting experiment, one worth keeping an eye on.

Comments (8 posted)

The trouble with OpenBTS

Last September, LWN pointed out the OpenBTS project, which is working toward the creation of a free GSM base station using GNU Radio and Asterisk. OpenBTS had just been demonstrated through the creation of a cellular network at Burning Man. More recently your editor, who had been looking in other directions, was surprised to learn that the OpenBTS developers are not allowed to tell anybody where to get the source from, despite the fact that it is available as free software. Intrigued, your editor decided to look into what is happening with OpenBTS.

OpenBTS is clearly an interesting project; who wouldn't like the potential of rolling their own cellular phone service? There are a number of potential applications, including special events like Burning Man, the creation of personal "femtocells," or the ability to explore how cellular handsets interact with base stations. The biggest target application, though, would appear to be the provision of inexpensive cellular service in parts of the world where the cellular industry sees no money to be made. In the rural parts of the developing world, potential customers simply cannot afford to pay normal cellular rates, and carriers fear that low-cost offerings, beyond being unprofitable, would endanger the higher rates charged in the cities. Using systems like OpenBTS, cheap hardware, and some interesting business models, it may well be possible to bring phone service into these areas in a way which is simultaneously affordable and acceptable to the large carriers.

So what is the problem with OpenBTS? One might think that an obvious trouble spot would be regulatory: spectrum for cellular services tends to be scarce and expensive. It is true that one cannot set up an OpenBTS station in the attic and expect to be left alone, but it also seems that the regulatory issues can often be dealt with, especially in places where cellular coverage does not exist. The real issues come from a different, all-too-familiar direction: "intellectual property" law.

When LWN first wrote about OpenBTS, the source code was not yet available. On October 24, 2008, the OpenBTS developers formally donated this code to the Free Software Foundation, putting it under the GPLv3 license in the process. OpenBTS is now part of the GNU Radio project. There has not yet been a GNU Radio release which includes OpenBTS, but interested parties can learn about it - and find out how to check out the current code repository - from the OpenBTS wiki on the GNU Radio site.

The transfer of the copyrights was the result of a direct intervention by John Gilmore, who, while certainly being motivated by the opportunity to improve GNU Radio, also likely saw the potential for trouble in the near future. The problem is that David Burgess, the primary author of the OpenBTS code, previously did GSM-oriented work for a company called Martone Radio Technology, Inc. Massimiliano Martone, the owner of this company, filed suit against David, alleging that the OpenBTS code contains Martone's proprietary information. David denies these charges, stating that GSM is documented in a series of open standards and, thus, cannot be proprietary. See this filing [PDF] for a lot of details about the history of the OpenBTS code, this case, and David's defense.

Whether this defense will hold remains to be seen; this case is pending as of this writing. The judge did, however, issue a preliminary injunction reading:

This is why nobody associated with Kestrel Signal Processing (David's company) can say anything about where the code is located. However, David does not own this code; the FSF owns it, and the FSF is not a party to this particular dispute. So the FSF is not subject to this injunction. The FSF is also uninclined to collect information on people who download its code. So the OpenBTS code remains available for anonymous download, this injunction notwithstanding. If Martone is able, somehow, to convince a judge that it has some claim on that code then the situation could change, but, for now, obtaining OpenBTS is possible - though Kestrel is not able to contribute any further changes to the FSF version.

There is, however, another issue that potential OpenBTS users need to be aware of. While the GSM standard is "open," in that it is publicly available, it is not a free standard; many parts of it are encumbered by patents. So anybody who wants to set up a production GSM base station powered by OpenBTS (or anything else, for that matter) must have acquired patent licenses from the various owners. Given that, one might wonder how the code can be distributed; David has posted an explanation on his weblog. It comes in two parts, the first of which is:

In other words, the FSF is distributing code with known restrictions on its use; this is a bit of a change for an organization which is not normally enamored of software which is only available for "private experimental use." But, evidently, this approach makes it possible to put the code out there under the GPL.

But, even if one accepts this reasoning, there is another problem to face: the GPLv3 text contains some strong language designed to protect users against patent problems. Anybody who (1) has the patent licenses necessary to actually deploy OpenBTS, and (2) contributes to or distributes the OpenBTS code must arrange for recipients to obtain the same patent protection. Needless to say, that is not really an option in this case; the owners of these patents (companies like AT&T, Ericsson, and Alcatel) have not expressed any great willingness to license them to OpenBTS users. So the only people who can distribute OpenBTS are, in general, those who can't actually make use of it. In other words, it would appear to be impossible to use OpenBTS in a commercial product in a way which satisfies both the patent requirements and the GPLv3 requirements.

Quoting David again:

The specific GPLv3 text being referred to would appear to be section 6d, which reads, in part:

So, as long as somebody is distributing OpenBTS without their own modifications, and they do not, themselves, hold licenses to the GSM patents, they need only point to the GNU Radio repository. This assumes that the operator of that repository is committed to making the source available for the requisite period of time - probably a good assumption when that operator is the FSF. That said, this is a fairly intricate dance designed to get around, in some sense, the patent licensing requirements of GPLv3.

And that is where things stand at the moment. In OpenBTS, we have a software platform which could be used to, among other things, bring affordable telephone service to large numbers of people who have no such service now. This code has been written to conform to published standards which are in use worldwide, and it has been freely licensed under GPLv3. Thanks to the current legal climate, though, this code currently has an uncertain future, a future which must certainly weigh on the minds of anybody considering making use of it.

Comments (36 posted)

SCALE7x: Courts have new "teeth" to limit software patents

A surprising decision from the second-highest court for US patent cases will put meaningful restrictions on the patentability of software here, Red Hat patent lawyer Rob Tiller said in a well-attended talk at the Southern California Linux Expo. In a surprise October ruling in the case of In re Bilski last year, the Court of Appeals for the Federal Circuit "threw out wholesale" the existing test for software patentability, and substituted a new, stricter one. "The test has teeth," said Tiller, who, as Vice President and Assistant General Counsel, IP for Red Hat, handles incoming patent threats and authored an amicus brief in the case.

The patent at issue was a business method for hedging commodities transactions; the Federal Circuit found the method unpatentable under a new test: in order to be patentable, a process must be either tied to a particular machine or apparatus, or must transform a particular article into a different state or thing. However, the court, "left to future cases the elaboration of the contours of the test," Tiller said. The Federal Circuit threw out its previous standard, which it set in the State Street Bank & Trust Co. v. Signature Financial Group, Inc. case in 1998. That decision, which opened the door to pure business method patents, allowed a patent on a mutual fund business method under a "useful, concrete and tangible result" test. In the Bilski decision [PDF], the Federal Circuit's chief judge, Paul R. Michel, wrote, "those portions of our opinions in State Street and AT&T relying solely on a 'useful, concrete and tangible result' analysis should no longer be relied on."

Questions remain about what kind of machine is "particular" enough. Will a patent applicant need to affect a real event outside the computer, such as the timing of a rubber-curing machine, or is moving electrons within a general-purpose computer enough? "This is something that courts and patent attorneys are scratching their heads about," Tiller said later. It's possible that a software-patent-friendly interpretation of Bilski could simply include a "general-purpose computer" in a patent claim, and trivially get around the requirement for a particular machine or apparatus. But, Tiller said, "It's hard to argue that a general purpose computer alone will suffice." Judge Pauline Newman wrote in dissent, "For the thousands of inventors who obtained patents under the court's now-discarded criteria, their property rights are now vulnerable."

"Bilski suggests that the Federal Circuit believes the Supreme Court is concerned with its work," Tiller said. In an unusual move, the Federal Circuit heard the case en banc, with all twelve judges involved, instead of in a smaller panel. Nine agreed on the ruling, with two against the new test and one dissenter writing that the court didn't go far enough. "They really are concerned that if you grant too much patent protection you could inhibit innovation," Tiller said. In the Red Hat amicus brief, Tiller summarized the often-heard economic arguments against software patents, and argued that the State Street test was inconsistent with the Supreme Court's previous patent decisions.

In a 1972 case, Gottschalk v. Benson, the Supreme Court ruled that an algorithm for converting binary-coded decimal data to binary was not patentable. Later, in a 1981 decision in the case of Diamond v. Diehr, the Supreme Court decided that a process for curing rubber that includes a computer-implemented algorithm is patentable. The Red Hat amicus brief says, "Diehr reaffirms that abstract ideas by themselves are unpatentable, and that only inventions that are sufficiently tangible are patentable."

The patent holder has requested that the Supreme Court hear the Bilski case, but the Supreme Court accepts few such requests, Tiller said. Groklaw covered the Bilski case thoroughly (Part 1, Part 2, Part 3) and called it "The End for the stupidest of the stupid patents."

Tiller got an easy round of applause when an audience member thanked him for Red Hat's refusal to sign a dubious patent agreement with Microsoft, as Novell did. Although Red Hat did not give ground to Microsoft's patent threats, Microsoft blinked first and agreed to establish virtualization interoperability agreements with Red Hat without a Red Hat signature on a patent shakedown.

Tiller also asked for some policy changes to ease the patent stress on the software business. "Since 1994, US litigation costs have substantially exceeded profits from patents," he said, except in the chemical and pharmaceutical industries. "If we can't have a subject matter exclusion for software, is there anything else that can be done?" he asked. Improving patent search tools would help, and requiring source code with a patent application would make it easier for working software developers to identify problem patents, since it's easier for them to read code than the tortured language of patent claims. An independent invention defense would also help, he said. "We ought to carve out the situation where a second inventor, just as creative but a little later, comes up with the same invention," he said. Senator Patrick Leahy of Vermont plans to re-introduce a bill to reform patent damages and reexamination requirements, Tiller said. "We in fact supported that bill."

Linux users can help with the patent problem. "Talk about this problem. Educate ourselves and educate others. Instead of fostering innovation it's hindering innovation," he said. "We have a large amount of work to do to educate people about this." Red Hat is also seeking prior art to help defend a lawsuit from a patent troll firm that is suing both it and Novell.

Comments (4 posted)

SCALE7x: Open source in an economic downturn

If you work with open source software, you have less to worry about in the current economic downturn, according to John Todd of Digium — the company behind the Asterisk telephony platform. Todd presented his ideas at SCALE in Los Angeles, arguing that many of the same factors that put jobs and revenue at risk in the proprietary software industry actually benefit open source projects and, by extension, provide job security for developers, implementers, and consultants who work with open source.

Businesses' motivations to adopt open source software solutions are not affected by hard economic times, Todd said: open source is often the best solution technically, and its well-understood benefits of lower total cost of ownership, flexibility, and customizability are just as real when budgets are flush as they are when budgets are lean. But decision makers focus on many of these factors in a downturn, which benefits open source. Cost becomes a life-or-death factor when the very survival of the business is on the line, he observed, while in better times companies may spend money for other reasons — to please investors, to keep up with appearances, or simply because they have the annual budget and do not want to end the year with a surplus. "Having no money, or the threat of no money, sharpens the mind about cost," Todd concluded.

Furthermore, making the best technical decision becomes more important in lean times, because the downside of being wrong is dire. And, he added, it is a well-known benefit of open source that if you choose an open source solution that turns out to be wrong, you can often code your way out of the problem, but at worst you have lost only time. With a proprietary solution, you cannot fix the problem yourself, and the vendor (under its own budget cuts) is less likely to be responsive to your requests for changes. In the end, you are out both time and money.

The slowing economy will also benefit open source in the increased availability of free resources, Todd said — first and foremost developer time. Laid-off developers continue to code in their spare time, in order to maintain their skills, learn new techniques, and simply because they enjoy it. Open source projects stand to gain from the increased pool of willing contributors along with increased availability of those who already participate in projects after-hours. Some coders leaving the proprietary world may even find jobs at companies that produce or support open source software or find roles in consulting. In addition, with businesses downsizing, surplus hardware equipment and bandwidth becomes available to be snapped up at low cost by both projects and open source companies. The hardware phenomenon happened after the dot com burst, he said, and may be repeated on an even larger scale this time due to the size of the economic recession.

Finally, Todd said, several recent developments make the timing of this recession especially good for open source to take advantage of. Unlike previous recessions, pervasive world-wide Internet, a rapidly-growing and connected open source community, and development tools that match or exceed anything available in the proprietary world are already in place. Although processors become cheaper every year, today virtualization and cloud computing make CPU cycles and storage available to anyone with zero capital expenditure. These factors benefit the open source movement more than they do proprietary companies because they are already integrated into the open source model.

Open source is not magic, Todd concluded. It is successful for well-known and well-understood reasons. But the tough economy reveals one dimension often hidden during more favorable conditions: open source is not vulnerable to the same pressures as proprietary software. No revenue stream is responsible for keeping open source code alive, but when the revenue stops, proprietary code dies. Commercial companies fire developers to cut expenses and must slow down as a result, but open source software continues to improve even when no money is coming in.

As logical as Todd's reasoning is, it was met with a small measure of skepticism from the audience. One listener challenged the assertion that layoffs would mean more spare time for developers to devote to open source coding. Aren't developers working longer hours for the same pay because of short-staffing, he asked? Todd replied that while it was true that many developers who have kept their jobs will find themselves working more hours, those hours are outweighed by the hours freed up by the developers laid off.

Todd concluded his talk by sharing some comments from Asterisk integrators and resellers, some of whom went so far as to deny that there was an economic downturn. They are statistical outliers, perhaps, but because their core business is replacing costly proprietary systems with open source alternatives, they are already "under the shield" of open source. Todd is making his entire presentation [PDF] available under Creative Commons Attribution-Noncommercial terms, and he invites others to contribute to the discussion. Todd's underlying premise is that open source "decouples the developer and what the developer produces from economics." Whatever your opinion on the causes or the future of the current economic recession, it is hard to argue with that proposition.

Comments (7 posted)

Microsoft sues TomTom

As seen in this TechFlash article, Microsoft has launched a patent suit against TomTom, a seller of (Linux-based) navigation devices. "It's believed to be the first time Microsoft has filed a patent suit over Linux, after claiming for years that elements of the open-source operating system violate its patents. However, Microsoft says open-source software is not the intended focal point of the action."

The complaint [PDF] is online. The patents involved are 6,175,789 (Vehicle computer system with open platform), 7,054,745 (Method and system for generating driving directions), 6,704,032 (Methods and Arrangements for Interacting with Controllable Objects within a Graphical User Interface Environment Using Various Input Mechanisms), 7,117,286 (Portable computing device-integrated appliance), 6,202,008 (Vehicle computer system with wireless internet), 5,579,517 (Common name space for long and short filenames), 5,758,352 (Common name space for long and short filenames, again), and 6,256,642 (Method and System for File System Management Using a Flash-Erasable, Programmable, Read-only Memory). Stay tuned, it could be interesting.

Comments (66 posted)

Page editor: Jonathan Corbet
Next page: Security>>