Playing around with radio-frequency transmission and reception used to be
restricted to those of us with hardware skills. That has been changing for
some years, though, as processors get faster and software techniques
advance; now, many radio transmitters and receivers are built with simple
(but flexible) hardware. The hard work of generating the signal to be
transmitted is done in software. Some wireless network adapters work that
way now, as do a number of other devices. There is a well-advanced project
- GNU Radio
enables experimenters to do amazing things with software defined radio
A potential problem with such devices is that users could, perhaps, modify
the software and cause the radio to operate in ways which are not compliant
with local spectrum-use regulations. Regulatory agencies tend to frown on
such use - and on manufacturers which make it easy for their devices to be
used in non-compliant ways. Fear of this sort of tampering is one of the
excuses given by wireless adapter vendors for not releasing free drivers
for their devices. It has also been an occasional concern for Linux
distributors who include free drivers. In general, the combination of
SDR and free software has long been the cause of worry and fear, and that
has slowed progress on that front.
The Software Freedom Law Center has made an attempt to address that fear by
doing an analysis of the U.S. Federal
Communications Commission's regulations with regard to the use of free
software in software-defined radio systems. The
resulting white paper is a bit of a challenging reading experience (it
may be clearer than the FCC regulations, but it still reads like legalese),
but it is probably worthwhile for anybody who is concerned about the
interaction of SDR and free software.
The white paper starts by looking at the scope of the FCC's regulations
with regard to SDR systems. It is noted that many such systems (a wireless
router, for example) contain full Linux distributions within them. Almost
the entire distribution, however, is unrelated to the device's radio
functionality and, thus, is not subject to FCC regulation. Any device
software which does not interact directly with the radio is unregulated and
can be free software.
Next, the SFLC points out that, by its reading, the FCC's regulations only
apply to device manufacturers. They do not, in particular, apply to
independent software developers. This conclusion is important: it says
that distributors who ship free drivers for SDR devices are not bound by
the FCC's rules unless those drivers directly operate the radio in
The down side is that manufacturers of software-defined radio devices
really cannot provide free drivers if those drivers could be modified to
enable non-compliant operation. The FCC expects that the security measures
within these devices will be implemented in a way which resists casual
tampering, and it has been clear on its worries that implementing those
measures in free software will not yield a sufficiently robust solution.
So, if the hardware can be easily programmed to do non-compliant things, it
looks like the FCC expects the driver which programs the device to be a
non-modifiable binary blob. The SFLC notes that the door is not entirely
closed, and that a vendor which can demonstrate sufficient robustness with
a fully free-software implementation could still get certification. But it
would not be easy.
The white paper concludes this way:
The SDR rules promulgated by the FCC represent a positive
development for FOSS developers working in the wireless space. The
rules allow FOSS developers not affiliated with device
manufacturers to continue work on their software without
restriction. They allow SDR manufacturers to employ FOSS for most
of the functionality of their devices, and they leave open the
possibility that a device using a purely FOSS-based software
platform could also pass FCC certification if it managed to
demonstrate the soundness of its security strategy.
It may be a positive development, but only to an extent; as long as the FCC
is saying that SDR devices must contain binary blobs to be certified in the
U.S., we will not have complete control over our devices.
One should note that this document only discusses U.S. regulations. The
FCC is certainly a prominent regulator, and its decisions have worldwide
impact, but it is not the only regulatory body out there. Every country
has its own rules, and some of them have regulatory agencies which are
rather more nervous than the FCC; people who have studied the issue often
note that Japan can be a very bad place to play loose with spectrum
regulations. So, while a partially-green light from the FCC may be
somewhat comforting, it's really only a small piece of the larger problem.
Spectrum use and regulation is an important issue; it will have an
increasing impact on our ability to communicate freely as time goes by.
Improving software techniques promise to open up the spectrum in
interesting ways, making it possible for more bits to be carried in ways
which are difficult to intercept or interfere with. It has been argued
that, as a result of improving technology, the need (and justification) for
heavy-handed regulation is fading, at
least over broad parts of the spectrum. The success of WiFi shows what can
happen when even a small bit of spectrum is freed; imagine what could
happen if the full innovative power of the free software community could be
unleashed on flexible, software-defined radio systems. That is why any
progress toward openness on the SDR front is a good thing, even if it
remains far from what we really want.
Comments (20 posted)
Don Marti attended Greg Kroah-Hartman's Linux Symposium talk on the kernel
development process; he wrote an informative article (titled Linux
contributor base broadens
) about it. The article states:
In the latest kernel release, the most active 30 developers
authored only 30% of the changes, while two years ago, the top 20
developers did 80% of the changes, he said. Kroah-Hartman himself
is now doing more code reviewing than coding. "That's all I do, is
read patches these days," he said.
An important part of this is that Greg presented this change as a
good thing. The kernel has a far broader developer base than it once did,
with patches for any given release coming from almost 1000 different
people. We have a growing development community which is healthy and
Seeing what the mainstream media makes of things can be great fun
sometimes. This time around, ComputerWorld UK picked up Don's
article, running the same text but giving it a new title: Are
top Linux developers losing the will to code? Slashdot picked it up
under that title, then Wired chimed in with Core
Linux Developers Stuck In Middle Management Mode, complete with a
picture of a necktie-wearing employee wielding a stapler and a telephone.
The prize must go to the Jem Report's The coders and
the talkers, though; this article breaks new ground completely:
Linus' [sic] job is leaning more towards spokesman than
programmer. He's been a relatively effective manager up until now,
but I think that effectiveness will begin to erode rapidly with
time. The further you get away from the actual work, the less you
are able to accurately judge the appropriateness of other people's
work. You need to stay in the game -- you need to keep your skills
in condition. If you don't, you might understand the theory pretty
well, but you'll get further and further away from being in touch
with its application. Linus has become more of a talker and less of
It seems we have trouble here. While we weren't looking, the Linux kernel
drifted into a Dilbertesque realm and is now controlled by people who don't
actually create software anymore. World Domination, it would seem, is now
in grave doubt.
Or perhaps all of this is just silly nonsense, an extreme extrapolation
taken from a couple of sentences spoken at a Linux developer conference.
If one wanted to investigate this subject further, a good starting place
might be the 2.6.22 changelog; there one can
see just how many patches our pointy-haired top-level maintainers have
contributed over the latest development cycle. Here's a subset:
One could add more names to the list, but the end result would be about the
same: the top-level kernel maintainers are not among the most prolific
contributors (except maybe for David Miller - but, then, he's an exception
in many regards), but neither are they absent from the game. They are
still hacking on the code and cranking out the patches.
From some of the articles that have been posted, one might think that
subsystem maintainers spend the rest of their time attending meetings and
writing weekly reports. What they are actually doing is working with
patches - lots of patches - and with developers. A subsystem maintainer
must review code, decide whether it is appropriate for the kernel, and, if
not, give the developer guidance on how to make it better. Incoming patch
streams must be merged together, and decisions must be made on which ones
are ready for any given development cycle. It is a task which requires the
maintainers to keep their hands deep in the code. Subsystem maintainers
who do not touch the code, and who do not maintain a deep understanding of
how the kernel works are not likely to remain maintainers for very long.
So the broadening of the kernel development community - and the associated
need for more work by subsystem maintainers - is not really costing us our
best developers. They are not "losing the will to code." The things that
cost us developers are elsewhere: a somewhat adversarial process which
turns off some people, general burnout, or getting a job which takes their
attention away from contributing to the community. All very normal stuff.
In the Linux kernel community we may have our share of Dogberts, but we
need not lose much sleep over the threat of pointy-haired subsystem
maintainers bringing the process to a halt. Instead, they have helped the
kernel development process to
scale to a level beyond that of almost any other software development
project anywhere; that is a good thing, not a sign of trouble.
Comments (9 posted)
Matt Asay (pronounced "ay-see") studied law at Stanford University
- Larry Lessig was one of his professors - before he joined Lineo, a
pioneering embedded Linux company. He later moved to Novell, and then to
his current employer, Alfresco, which
produces open source enterprise content management software. He also
founded the Open Source
Business Conference, and writes an influential blog called The Open Road. Glyn
Moody talked to him about why he became a GPL believer and how to create a
billion-dollar revenue open source company.
How did your work with Larry Lessig come about?
I had what started off as a summer internship at Lineo, and I loved it
almost from day one. It turned into a full-time job which I continued doing
for the last two years of law school. [Larry Lessig] was teaching a class
"open sources", and I thought: "Well, I work for an open source
company; surely I'm qualified to take the class."
I read his book [Code and Other Laws of
Cyberspace] and thought it was fantastic, and ended up in this class
with him, where I found out that he was much more persuasive in the book
than he was in the class. In the class, all of these grand-sounding things
about freedom and whatnot, and how good it was for the industry, didn't
sound as good to me when I was trying to make a living selling the stuff:
Lineo went through the first year of being just phenomenally successful, to
the second year of collapsing.
At the time, what I was hearing was: "This open source software is
great. Everybody loves it." And the "everybody loves it" was true, but that
didn't translate into people paying for it, at least in my experience. And
so I had a fundamental disagreement with him that open source had a long
future ahead of it. When you can only rely on the developers to scratch
their itches, and their itches may not be the itch of these big companies
that buy software, how could open source have any sort of a future ahead of
And so we just battled constantly. But that turned into a grudging respect
on my part. I wanted to write my third-year paper on open source
licensing. He agreed to be my adviser for it - which sounds better on paper
than it was in reality, because he was traveling like a madman and so I
never actually got to see him.
In that paper
there's this mea culpa
, where you effectively say: "Well, actually
I've decided that I was wrong about the GPL." What made you change your
I recognized that my experience at Lineo was maybe atypical for the
industry. I hadn't encountered enterprise software yet. I just didn't know
that that would be a different beast, but it turns out it is. In the
embedded world, developers rule. Developers are happy to sustain themselves
and to support themselves. In the enterprise world, for whatever reason,
they'd rather save time, and spend some money. In the embedded world, they
were happy to save money and spend time on the code. I think it was
watching Red Hat more than anything else: Red Hat slowly proved that you
can make money in open source.
How did you come to work for Novell?
While I was still working at Lineo, I contacted somebody that I had had to
lay off, and said: "Will you come back? We need you back." And he said:
"No, I won't, but will you come work for me at Novell?" I was just coming
up on graduation, and [it] says something about how rocky the last few
months at Lineo were that Novell actually looked like a stable place to
My initial job at Novell was trying to get hardware and software companies
to support Netware, which you can imagine was a somewhat thankless task. It
was about that time that I said: "The one thing that I know is interesting
is open source." That's where I had just come from. So I went to our
potential partners, saying: "Well, Netware is not very interesting, but
Novell and Linux are." At the time, a lot of Novell's applications or
infrastructure ran on Linux, such as eDirectory. So that became my story,
going around talking about how they should support Novell's Linux story,
even though Novell, aside from running some of its applications on Linux,
didn't really have one.
I was probably one of three people in the company that had any
understanding of open source, and any desire to do anything
there. Fortunately, one of those three was Chris Stone, the vice
chairman. In December 2002, when the Linux Business Office was formed, he
asked me if I would be part of that. It was designed as a group to advise
him and push the company toward open source.
The unfortunate thing is that there were a lot of people that had been
there for ten, fifteen years. There were people who just dug in their heels
and said, "No, our software is better and our technology is better. Surely
they'll realize that Microsoft technology stinks." They just didn't get
While you were at Novell, you set up the Open Source Business Conference
(OSBC) in July 2003: what you were trying to achieve with that?
OSBC was born out of the frustration that I had with both Novell and Lineo,
and played out in class with Lessig: how do you make money on this stuff
that everybody thinks is so great? If it's so great, surely somebody would
pay money for it, and if we could get people to pay money for it, there
would be a lot more of it.
I was coming back from LinuxWorld or something, I was sitting with a
friend, complaining to him about this great open source stuff that nobody
knows how to make any money on. I said: "You know, I should do a conference
on this, get all the smart people together." And he said: "Well, do it."
So I contacted the two people in open source that I knew had money - Jason
Matusow at Microsoft and Dan Frye at IBM. They both committed $30,000 to
it. So, yeah: the interesting little fact with the Open Source Business
Conference is that the first person to give money to it was Microsoft.
Did you decide to leave Novell or to join Alfresco?
I decided to leave Novell about a year before I left Novell. I was still
fulfilling my Novell duties, but thinking strategically in a vacuum. I
started talking with a range of different open source companies; over the
course of a year, I think I must have met every single open source company
on the planet.
The one thing that I didn't have at any of the companies that I'd been with
was real mentorship on the business side. I felt like I knew the open
source side reasonably well, but in terms of how to grow a company, I
didn't really have that. So here was a company founded by the founder of
Documentum, took it from zero to a billion dollars, and the former CEO of
Business Objects who'd taken it from, I think, 50 million to 500 million
[dollars]. Clearly, here was something I could learn from them.
When I first contacted them, I was coming over to speak at LinuxWorld UK
and I thought: "Who are the open source companies in the UK? Well, I'll
contact Alfresco. They look really interesting." But I thought that I
wouldn't be at all interesting to them. They were these guys with this
great pedigree. Clearly, they didn't need any help.
On their side, they were thinking: "We don't know anything about open
source; we're an open source company. Clearly, we need a lot of help." And
here's this guy that seems to know something about open source, contacting
them out of the blue. I only found out later that they were really excited
to get involved with me. From my side, I was thinking: "Well, I really
don't have that much to offer, but hopefully they'll take me on out of
charity." It was a good match.
So how did they come to launch an open source company, not knowing anything
about open source?
Funny you should ask that: most of the open source companies that are out
there are launched by people who don't know anything about open source, and
it shows. I think the best open source companies have been those that were
launched by developers first. So, arguably, that's JBoss, Red Hat, MySQL,
where the community came before the company. The company was an
In Alfresco's case, we're pioneering somewhat, because the company
definitely came before the community. I think that's a really difficult
thing to do. I think it's hard to fake community, but I also think it's
really important [to have one].
How these guys got started, is they had actually started another company
and it failed. When they tried to explain to me what the product was, I
can't understand it, and they can't really explain it, so that's one reason
it failed. The other thing was it just became evident to them that it was
really hard to go in there and plop a million-dollar proposition on these
They decided: "Look. How can we distribute our products in such a way that
people can get easy access to it, and they don't have to pay these insane
amounts of money?" They perceived from their efforts that this enterprise
sales model, and the enterprise pricing model, was broken. It wasn't going
to work very much anymore. And they said: "Oh, it's open source!"
Maybe a year after that, they said: "Why don't we start an open source
content management company?" because that's what John Newton, one of the
founders, knew really well. But this time, we'll do Documentum part two,
and this time we'll give the product away for free. And it sounded like a
great proposition, except for the free part, and that's what we've been
figuring out ever since.
What was the licensing model when you first joined?
It was a Sugar[CRM]
model, so 70
percent of the code was open source under the [Mozilla Public License], and
30 percent was proprietary. But that is a terrible model on a range of
scores. One that was continuously coming up was: we just developed this
new feature; should it be open source or should it be proprietary? We were
constantly having to struggle with this.
So we moved to a model where it was 100 percent open source - but it was
not really open source, because my definition of open source is that it has
to be under an OSI-approved license, and this was Mozilla Public License
plus Attribution, which had a contentious time out in the
market. Attribution said you had to have a "Powered by Alfresco" logo on
every screen with a little subtext that said: "This software will burst
into flames at any second. Run screaming from the room when you see it. Or
you can pay us and then everything will be alright."
Again, that worked for a little bit, but there started to be this fervor
around "Attribution isn't real open source". I hadn't really thought
about it up to that point. Internally, the same thing came around: why are
we doing this? We thought it was open source, but now we're hearing from at
least a vocal part of the open source developing community that this won't
fly. So we scrapped that in June of last year, 2006.
Part of my job was going out and talking with customers, finding out why
they were buying us and whether or not they would continue to pay money for
the value we were providing if they weren't forced to. In the process of
doing that we discovered some interesting things. A lot of companies were
coming to us directly and saying: "We just want to pay you." They were
sidestepping the step of using the free product and then being forced into,
for whatever reason, our proprietary plug-ins or enhancements or whatnot.
A lot of them had an internal policy that they wouldn't use software unless
they had a support contract.
We were fortunate: most of our customers were big companies. I think that
made it a little bit easier for us to make the decision to go GPL, which we
eventually made last year, because our customers were the kinds that would
pay for support. I think it might be a more difficult decision for some of
I know for us, the plus side of it is that our press mentions went up, our
leads went up, our sales are up 140 percent, our average sales price is up
- everything has gone up since we went GPL. Part of that may be that we're
just becoming better known as a company, so the brand is selling it, but I
credit a lot of it to the GPL. We are more developer-friendly. More
developers that work at big companies or other companies are downloading us
and trying us out. They can trust the code before they trust the company,
because at the end of the day, they own the code. They don't have to come
back to us.
Looking ahead, what does Alfresco aspire to become in the long term?
Well, I think Red Hat's going to beat us to it, but my personal goal is to
be the first pure-play, open source software company to be a billion
dollars in annual revenues - just prove that you can do it by giving the
software away for free.
In terms of product ambition, we would like to see content management used
by everybody on the planet. It depends on how broadly you define content
management, and that's one of the things that we're working on. Today,
it's a roughly three billion dollar market, but within any enterprise, only
five percent of the people in the enterprise actually use a content
management system. So we're trying to bring down the cost and [improve] the
ease of use so that it's as easy to use a content management system as it
is to send an email, as it is to search and Google, as it is to blog.
Are we going to see open source dominating software within ten years, say?
I think that every software company on the planet, within the next year,
will be doing significant open source software within their walls,
including Microsoft. In fact, Microsoft has actually been an early adopter
because they perceive the threat more acutely than most.
I believe that within ten years most of the software will be delivered in
open source-esque fashion, either as software as a service, or directly
through open source. The general trend, I think, is that software will
become a service over the next ten years. That's not to say that there
won't be heavy outposts of traditional software. [But] just look around at
the start-ups that are being funded: it's very hard to get a traditional
proprietary software company funded right now.
What were your first thoughts when you heard about the Microsoft-Novell deal?
I was extremely disappointed because if there's any company that didn't
need to do that, it was actually Novell. Because Novell has patents that
go to the heart of both Microsoft's Windows Server business and its Office
business. Novell was under absolutely no threat of ever being sued by
The reason they did it is to try to club Red Hat. Novell thinks it has an
interest in destroying Red Hat; really what Novell needs is for Red Hat to
continue to be successful and for Novell to learn how to be successful with
I just remember thinking: Here's Novell. It's best chance of surviving in
the future is to move toward more of an open source model, and it's just
basically told the very community that could feed it that it didn't want
it. It was cutting itself off from its future. I think it's done itself
irreparable harm now. I just think Novell will have a very hard time ever
gaining credibility again as an open source vendor.
Are there any threats that you see facing open source as it grows in the future?
I worry that diluted forms of open source will come to be viewed as
acceptable, and that's why I think the OSI is so important. When I look
around at my peers, they're arguing for an expanded definition of what open
source means - they want this Attribution [variant] to be accepted, they
want various different licensing models to be accepted as open source.
I do worry that if we bastardize the concept of open source to make it
lowest common denominator business-friendly, then we lose the power of open
source. Because the greatest threat to Microsoft and to these proprietary
software companies is not a weak form of open source, but it's the full,
pure open source. Frankly, it's GPL'd open source.
It sounds like you've become quite religious about it.
I've come 180 degrees on it, and I am a little bit religious on it, because
ultimately, coming back to the point I was arguing against Larry Lessig in
law school, I think freedom does matter. What's odd is that it actually
matters as much to the vendor as it does to the customer.
For the long-term success of open source vendors, they need to realize that
freedom is in their interest, too. When you throw away all the safety
nets, the proprietary crutches, it forces you to do business in a way
that's overwhelmingly positive for customers. And if you can do that, then
you'll be successful.
Glyn Moody writes about open source at opendotdotdot
Comments (3 posted)
Page editor: Jake Edge
Inside this week's LWN.net Weekly Edition
- Security: Security research: buy low, sell high?; New vulnerabilities in PPC kernel, dar, gfax, vlc
- Kernel: The 2.6.23 merge window opens; Virtio; Video4Linux2: streaming I/O.
- Distributions: Looking forward to Mandriva 2008; new releases of 64 Studio 2.0 rc1 and CentOS 5 i386 Live CD
- Development: The Synfig 2D Animation package, Samba adopts GPLv3, MIDI for Ardour,
new versions of BusyBox, Traverso, PLplot, GARNOME, GNOME,
gEDA/gaf, GnuPG, FreedroidRPG, Claws Mail, Qsynth, gnucflow, sather,
- Press: Dell expands Linux offerings, Fair Use Day, coverage of aKademy, OLS and Robocup,
Georg Greve interview, Gaming in Ubuntu, Intel classmate PC review,
Siag office review.
- Announcements: Canonical releases Storm, IBM to give free access to standards, Intel and
Novell support KDE, semantic layer for KDE4, Microsoft on GPLv3, SourceForge
award nominees, rPath Certified Software Appliance Architect Curriculum,
hardware4linux.info and Medwiki launched, GPLv3 launch video.