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.
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
I am going to work on communication and documentation issues around
that, and Will [Woods] is going to work on producing a tool which simply tests,
every day, whether you can a) install Rawhide fresh and b) update from
latest stable+updates to Rawhide. This serves two purposes: it both lets
you know whether it's worth actually attempting to install Rawhide that
day if you wanted to know, and if we track the results over time, it
provides an incentive to the developers to improve the reliability of
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:
The point is that this pool of people is in fact far larger than the
number of people who currently run Rawhide. It should at least include
the vast majority of packagers, yet from what I've seen, it seems that a
lot of Fedora packagers only run stable releases, which is a pretty
reliable indicator that we really could have more people running
But Bruno Wolff is worried that the bar is being set
too low: "you need to be able to rescue your system when booting
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:
Usually, also, if the problem is one that affects more than a few
people, someone will post a note about what's wrong and how to fix it to
the discussion list. Or, they would, if enough people ran Rawhide. :)
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
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
Comments (8 posted)
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
For these reasons, IT IS HEREBY ORDERED that Defendants and their
agents, officers, directors, employees and anyone acting on their
behalf are enjoined from making available on any internet website
any algorithm, computer code, software, technical information or
any other intellectual property or technical data relating to any
base station transceiver, unless they gather and preserve the
names, internet addresses and other identifiers of all persons or
entities who upload, download or otherwise access any such
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
The current GPL distributions of OpenBTS are offered for only
private experimental use, which is generally exempt from patent
licensing. Furthermore, OpenBTS is presently distributed as
software, not an actual, usable end product. Anyone using OpenBTS
is expected to comply with all applicable laws, including patent
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:
Thankfully, there's a loophole of sorts. Look closely at Section
6. It does not say you must distribute the source code. It just
says that you must make sure that people who have your product know
where to get that source code.
The specific GPLv3
text being referred to would appear to be section 6d, which reads, in part:
If the place to copy the object code is a network server, the
Corresponding Source may be on a different server (operated by you
or a third party) that supports equivalent copying facilities,
provided you maintain clear directions next to the object code
saying where to find the Corresponding Source. Regardless of what
server hosts the Corresponding Source, you remain obligated to
ensure that it is available for as long as needed to satisfy these
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
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)
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
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
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
first and agreed to establish virtualization
interoperability agreements with Red Hat without a Red
Hat signature on a patent shakedown.
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
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)
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
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)
As seen in this
, 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.
[PDF] is online. The patents involved are 6,175,789
(Vehicle computer system with open platform),
(Method and system for generating driving directions),
(Methods and Arrangements for Interacting with Controllable Objects
within a Graphical User Interface Environment Using Various Input
(Portable computing device-integrated appliance),
(Vehicle computer system with wireless internet),
(Common name space for long and short filenames),
(Common name space for long and short filenames, again), and
(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>>