Why the RTLinux patent license is a good thing.

I ran into Jim Ready, CEO of MontaVista, at the LinuxWorld Expo in New York City, and he's understandably happy about the MontaVista 2.1 release, which adds a lot of new functionality.

The secret to keeping an embedded distribution up to date, Jim says, is to keep sending any changes you make back to free software project maintainers. It's a mistake to fix things in your internal source tree that don't get fixed in the outside world because it makes upgrade time much more painful.

This doesn't mean that you should let your internal version track some random CVS tree. Of course you should keep a known good, stable version. But when you fix something, get desktop and server users of the upstream software to integrate and test it too.

What does this tactical advice from Jim have to do with the feature topic of this issue, which is real-time Linux? The key is to make sure that the free-software-development process stays alive and healthy. Mention real-time Linux, and many people wonder about the RTLinux patent situation. Do you really need a patent license to apply the dual-kernel approach?

Yes, but fortunately, the RTLinux patent controversy has been resolved, and well. The new license allows free use of the dual-kernel technique in pure GPL projects and even in non-GPL software running on the GPL version of RTLinux, but requires you to pay for a patent license if you distribute your software under different terms. Lineo is offering an RTLinux patent license in their BridgeWorks products, for example.

The RTLinux patent license was endorsed by the Free Software Foundation. Richard Stallman of the FSF has sometimes used a ``ready-fire-aim'' communications style, which makes some people not want to talk to him. That would be a mistake. You might disagree with Stallman's position that all software should be under the GPL or another free license, but the Free Software Foundation is one of only two attempts to define a code of conduct for software. The other is represented by UCITA and the current crop of shrink-wrap licenses, which take the opposite extreme. If you want to disagree with Stallman, write what you think is a fair license and use it.

Stallman's vision of users all having the right to copy and modify software under the terms of the GPL is exactly the kind of testing you want on your side before you put your name on a release. If you're selling a device, desktop and server users represent testing help, not lost revenue. And you can't get that help if you hold a patent, or use a patent under license, when it's not available to free software projects as the RTLinux patent is.

Where's the revenue in trying to collect patent license fees from a free software project? You can't get money from them; all you can do is try to shut them down. Companies that want to take the non-GPL or dual-license approach, that's another story. When they get license revenue, you can get license revenue.

Software patents are looking worse and worse for the economy as a whole as more of them get issued. Unfortunately, the trend worldwide seems to be to allow the patenting of more and more different kinds of content without adequate examinations. Mutual defense agreements like the RTLinux license will be an important tool to keep innovation going. Please keep it in mind if you get a software patent and want to be known for innovative products, not pointless litigation.

As you might expect in the real-time theme issue, Kevin Dankwardt continues his series on the taxonomy of real-time Linux with a look at kernel preemption. Whose kernel preemption patch does what? And where do you get it? It's all here on page 14. Part three of three will be next month, so collect them all.

If you're going to use the dual-kernel RTLinux approach, there are tools available to you for communicating between real-time tasks and regular Linux processes. Matt Sherer explains them on page 18.

Just a few miles away from Embedded Linux Journal's California office in Mountain View is NASA's Ames Research Center, home of an air show in the summer and much scientific research all year. Read about how NASA is using RTLinux, Qt and other Linux technology on page 8.

Libraries that are just too large for your image are a recurring problem, so techniques for keeping images small will be a key part of Embedded Linux Journal. Brian Finley doesn't just use Debian's PIC technique to reduce library size, though--he also makes some easy but space-saving filesystem tweaks. Find out how on page 44.