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 non-compliant ways.
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:
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.Linux contributor base broadens) about it. The article states:
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 robust.
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:
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:
Developer Patches Andi Kleen 70 Andrew Morton 79 David Miller 193 Greg Kroah-Hartman 14 James Bottomley 13 Linus Torvalds 20 Russell King 61
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.
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 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 it?
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.
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 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.
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.
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 companies.
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.
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 our peers.
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.
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.
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.
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 Linux.
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.
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.
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.
Page editor: Jake Edge
Next page: Security>>
Copyright © 2007, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds