Other LWN stuff:
 Daily Updates
 Calendar
 Linux Stocks Page
 Book reviews
 Penguin Gallery

 Archives/search
 Use LWN headlines
 Advertise here
 Contact us

Recent features:
- RMS Interview
- 2001 Timeline
- O'Reilly Open Source Conference
- OLS 2001
- Gaël Duval
- Kernel Summit
- Singapore Linux Conference
- djbdns

Here is the permanent site for this page.

See also: last week's LWN.

Leading items and editorials

The patent itself is relatively simple as these things go. It covers the particular method used by RTLinux to achieve real time performance. Two techniques are called out as the core of what RTLinux does:

• Running a general-purpose operating system (i.e. Linux) as a low-priority process under a real-time system. The general purpose system is not allowed to block the real-time system from executing whenever it needs to.

• Placing an emulation layer between hardware interrupts and the general-purpose system. Linux thinks it is working with interrupts as always, but RTLinux is pulling the strings behind the scenes.

As things stand now, if you have a real-time system that uses the above techniques, you are subject to Mr. Yodaiken's patent - at least, in the United States. So the patent license may just be of interest.

The license allows for royalty-free use of the patented technology in two situations. They are:

• If the software involved is licensed under the GPL.

• If the software is running with the "Open RTLinux Execution Environment" as distributed by FSMLabs - Mr. Yodaiken's company. Note that this exemption applies only to an unmodified version of RTLinux. Even though RTLinux is licensed under the GPL, making modifications to it forfeits the right to royalty-free use of the patent if your software is proprietary.

Anybody who uses the RTLinux technology is required to send a message to FSMLabs giving their contact information and indicating agreement with the terms of the license. Anybody who makes commercial use of the patented technology, or makes a commercial distribution of software that uses that technology is required to keep "complete and accurate records" and to make them available to FSMLabs on demand. Any use of the technology must also include labeling that says "Used, under license, U.S. Patent No. 5, 995,745," and must include a copy of the license itself. Failure to comply with any of the above can result in the termination of the ability to use the technology.

For more information on the patent and licensing terms, see this article on LinuxDevices.com by Jerry Epplin.

What are the implications of the RTLinux patent and its license? There are a few aspects of this issue that are worth looking at.

What is Victor Yodaiken attempting to do with this patent? Mr. Yodaiken was kind enough to talk with us while waiting for a dentist appointment (some things are even less appealing than talking to the press). His position is that he has made an innovation that he has a right to exploit. Nonetheless, he wishes to make it freely available to anybody who is working with code licensed under the GPL. He sees this as a fulfillment of his obligation to the free software community.

Those who want to use the RTLinux method and do not want to license their code under the GPL are, according to Mr. Yodaiken, doing proprietary work. Such people should be both willing and able to pay for the previous proprietary work (such at the RTLinux patent) that they make use of. He sees people who wish to use RTLinux in proprietary products without paying as would-be free riders, and sees no justification for any complaints that they might make.

The only reasons to be upset about the RTLinux patent, he says, are (1) you are absolutely opposed to software patents in general, or (2) you want to do proprietary work without paying. Mr. Yodaiken expresses respect for those who are opposed to software patents (while disagreeing with them), but has little patience for those who wish to make money off other peoples' work.

A concise statement of his position may be found in this posting to the realtime list:

In summary: my opinion is that I owe the GPL community a license to use the RTLinux method for GPL code. And I owe RTLinux users a license to use RTLinux. I don't see any reason why I must otherwise subsidize other people's proprietary software projects.

Next question: what does this patent mean for RTAI? RTAI is a competing real-time Linux project headed up by Paolo Mantegazza in Milan, Italy. It differs from RTLinux in numerous ways, but uses the same fundamental technique as RTLinux. It is, thus, arguably subject to the RTLinux patent.

RTAI could offer no end of difficulties with regard to this patent. It is licensed under the LGPL, not the GPL. There are companies that have an interest in making proprietary products with RTAI; Lineo, for example, is an RTAI supporter. RTAI does not acknowledge the RTLinux patent, and it is unlikely that many RTAI users have sent in their acceptance messages.

Relations between RTLinux and RTAI, and especially between Mr. Yodaiken and Mr. Mantegazza, have always been rather tense. Each side claims the better technology, while simultaneously complaining that ideas and code have been stolen by the other. Some RTAI users have feared for some time that the real purpose of the RTLinux patent was to shut down the competition.

Certainly the RTAI camp does not intend to change much in recognition of this patent. LWN had a conversation with Mr. Mantegazza, and he was quite clear on what he thought: "Mr. Yodaiken has only been allowed to patent air, but air has been around forever with nobody thinking to patent it."

When asked if RTAI users should register with FSMLabs and indicate their acceptance of the patent license, he responded:

Not in your dreams, they should act as if there were nothing there.... RTAI will continue as if the patent did not exist. Remember that the patent is valid only in the USA, and the USA is not the world. Plus...the patent could also vanish like a soap bubble at the first legal test.

From Italy, that is an easy position to take. Companies in the U.S., however, may need to be more careful. We asked Lineo how it plans to handle this issue. The company is not talking much about it, but we did hear from Ryan Tibbits, Lineo's general counsel: "Lineo questions the validity of the patent, especially in the spirit of the open source community."

Mr. Yodaiken has long avoided committing himself on exactly what the status of RTAI is. Talking with LWN, he stated that he welcomes competing projects that take his GPL code and explore new paths, and that those using RTAI with GPL code need not worry about their right to do so. With regard to whether RTAI users need to accept the patent license and register, he responded:

As of the current moment, individual users need to determine whether they are using the RTLinux process and whether they need to register. Questions can be sent to licensequestions@fsmlabs.com

Not the clearest of answers. But Mr. Yodaiken has stated that he has no wish to cause trouble for RTAI, and hopes to come to an "amicable settlement."

Finally: what does this whole situation imply for the free software industry? As free software companies cast around looking for reliable ways to make money, it would not be surprising to see more of them turning to the sorts of intellectual property protection that this community has traditionally disliked. The free software industry, thus far, has been refreshingly different from the intellectual property driven proprietary world, and it will be discouraging if proprietary techniques and code make a comeback. That is not the "revolution" we were hoping to see.

This episode could also have an immediate effect on the adoption of free software: companies looking at real-time platforms may decide that the situation looks too messy and pass over Linux altogether. There are several well established, proprietary real-time solutions available; if RTAI is under a patent cloud and RTLinux is, itself, proprietary, why not look at the whole range of options? It is not inconceivable that this patent could relegate Linux to a very small role in the hard real-time sector.

LWN has long held that software patents are damaging and best done without. It remains to be seen if this particular patent turns out to be a problem or not; its owner does appear to be sincere in his desire not to cause problems for (pure) GPL applications. But the mixture of software patents and free software can only lead to software that is less free; this is not an example that we would like to see repeated.

Interview: David Sifry. While at LinuxWorld, LWN editor Michael J. Hammel interviewed David Sifry, CTO and co-founder of Linuxcare. The discussion wandered over a large range of topics, including the troubles Linuxcare has experienced over the last year, the company's plans for the future and the merger with Turbolinux, the Linux Standard Base, and more.

Feature: a look at djbdns. Last week's LWN weekly edition makes the point that the net needs free alternatives to BIND. A number of users of the djbdns DNS server complained (politely) that our overview did not do justice to that package, which they see as a viable alternative to BIND. It turns out they were right.

In an effort to set things straight, we put together a detailed look at djbdns as a separate feature article. Therein we examine the design of djbdns and conclude that it may well be ready to challenge BIND, though some other factors may limit its adoption.

Inside this week's Linux Weekly News:

• Security: SSH trademark issue surfaces, XFree86 fixes show up, finally, and more SSH security problems are aired.
• Kernel: Zero-copy networking meets the powder rule; user-mode Linux.
• Distributions: ODS Linux and NBROK Linux.
• Development: ZRadiale, GNOME 2.0 plan, KDE 2.1 schedule, Apache-Tcl.
• Commerce: 'Business Ethics' in the Open Source Community?, Conflict emerges among Free Software Companies.
• History: Three years since "Fired for choosing Linux?"; complaints about "open source."
• Letters: Ssh trademark; we get taken to task for underestimating djbdns.

This Week's LWN was brought to you by:

• Jonathan Corbet, Executive Editor
• Elizabeth O. Coolbaugh, Managing Editor
• Michael J. Hammel, Senior Editor

Next: Security