Business
A developer's perspective on the RTLinux patent
This guest editorial at LinuxDevices.com takes a thoughtful look at the recently unveiled RTLinux patent, including a summary of what the patent says, the implications of the patent to the GPL status of RTLinux, and some of the issues and concerns that ma
"Us" vs. "Them"
If you follow the open-source software culture at all, you're aware of the us vs. them mentality that has developed. In the Slashdot view of the world, there are those who "get it" and those who don't.
If you get it, you build upon the body of open-source code that exists, and you hand all of your new code, including any inventions that it implements, back to the community. If you don't get it, you patent your inventions, implement them in software distributed under restrictive licenses, and sell the combination in a way that maximizes your profits. Few gray areas are seen in this bipolar view of people as either cooperative or competitive.
Complications
It should be no surprise that complications to this caricatured world view have arisen in recent years. We have Sun, traditionally viewed as nothing more than a Microsoft wannabe, releasing StarOffice under the GPL. We have Tim O'Reilly denouncing the Amazon.com patents to the cheers of the open-source crowd while continuing to sell most of his books under restrictive licenses.
But few cases show as close an intertwining of open and proprietary licensing as that of RTLinux, the real-time Linux add-on provided by Finite State Machines Labs (FSMLabs).
FSMLabs seems determined to fully pursue its right to collect patent fees for use of the technology, yet at the same time the technology is of little use to the company itself apart from its implementation on the open-source Linux operating system.
This article will attempt to unwind some of the complicated interaction between what is open and what is closed from the perspective of a developer and Linux advocate. As I'm not a lawyer, a legal perspective will be notably absent.
About RTLinux
RTLinux is a project started by Victor Yodaiken and Michael Barabanov when both were at New Mexico Tech. The two main techniques on which it is based can be stated simply . . .
Recently, the patent license was released. This license codifies the general principles that Yodaiken laid down early last year.
The RTLinux Patent
If you are a user of RTLinux, or of RTAI, the competing product built using the same two techniques as RTLinux, you will certainly want to read the patent license and judge whether it affects you. Its contents might be summarized as follows . . .
No one knows, of course, since to my knowledge Yodaiken hasn't yet attempted to enforce it in court. I can only provide a developer's perspective on whether the techniques patented are novel and non-obvious.
The question of who invented what, and exactly when, among these products is well beyond the scope of this article. However, I'm guessing that a legal challenge to the patent would include sorting out that question.
How does this patent square with the GPL?
Yodaiken is, of course, free to pursue his patent rights as he sees fit -- the GPL is irrelevant to this right. The only relevant question is the status of the RTLinux code, which is released under the GPL.
The fascinating thing about this case is this: FSMLabs appears to be releasing code freely with one hand, while restricting its use with the other.
Actually, I find nothing in the GPL that prohibits this behavior, although the GPL does seem to try to prohibit it. Specifically, the GPL states . . .
This suggests an interesting (albeit twisted) business model . . .
Is such a strategy within the spirit of the GPL?
Clearly not! It is inconceivable that the authors of the GPL (or of Linux) would wish to allow "copying, distribution, and modification" of the code but not running it.
The real questions are: Do the restrictions imposed by the patent license fall within the spirit of the GPL? And, more specifically, how do the restrictions square with the intentions of the developers of Linux?
Yodaiken contends they are within the spirit of the GPL. After all, the RTLinux license allows using the patented process if you are using a GPL OS and distributing the application under the GPL.
But it is the oft-stated position of Linus and other Linux contributors that they wish to allow proprietary code to be run under Linux. And the GPL states "... it is not the intent of this section [which defines a modified work] to claim rights or contest your rights to work written entirely by you ..." So neither the GPL nor the Linux developers seek to impose restrictions on your application.
Yodaiken's restrictions do not appear to fit within that spirit.
What to do?
Users of the patented process -- and for Linux users, this essentially means users of RTLinux or RTAI -- ought to consider how to deal with this issue. This includes even those see-no-evil folks who complain loudly on the RTLinux mailing list whenever the patent issue is raised. You need to consider whether you are using someone's code or methods without proper licensing.
* Warning * My comments in this section are meant to provide some guidelines for finding your way through the maze Yodaiken has constructed with his patent -- please do not consider this a substitute for legal advice!
Of course, negotiating a royalty agreement with FSMLabs is also an option. You can line RTLinux up with the crowd of commercial RTOS products and pick the best one. If you are committed to using Linux, RTLinux might be a good choice. On the other hand, with its unconventional programming model, bewildering-to-beginners API restrictions, and limited documentation, RTLinux is unlikely to fare well against better-established commercial competitors.
The bottom line
When Victor Yodaiken's patent first become known early last year, some observers were hopeful that it would be merely defensive, protecting open-source real-time application developers against some outside commercial predator. However, the recently released license makes it clear that the aims of the patent go well beyond the defensive -- it forms the basis for a unique hybrid open/closed software company.
Yodaiken has correctly pointed out that most open-source software companies have both open and closed source products; and many others (such as Trolltech) release one product under multiple licenses. But the particular hybrid licensing that he has constructed out of the GPL and his patent license is both fascinating and disturbing.
It seems to me, RTLinux is a fine system with great potential when thought of as an open-source project. I'm not sure it will fare as well when looked at as a commercial RTOS.
Author's bio: Jerry Epplin has written embedded software for the past fifteen years, primarily for medical devices. He wrote the first semaphore facility for RTLinux. He can be reached at jerry@linuxdevices.com
Related stories:
Talk back! Do you have questions or comments on this article? talkback here
If you follow the open-source software culture at all, you're aware of the us vs. them mentality that has developed. In the Slashdot view of the world, there are those who "get it" and those who don't.
If you get it, you build upon the body of open-source code that exists, and you hand all of your new code, including any inventions that it implements, back to the community. If you don't get it, you patent your inventions, implement them in software distributed under restrictive licenses, and sell the combination in a way that maximizes your profits. Few gray areas are seen in this bipolar view of people as either cooperative or competitive.
Complications
It should be no surprise that complications to this caricatured world view have arisen in recent years. We have Sun, traditionally viewed as nothing more than a Microsoft wannabe, releasing StarOffice under the GPL. We have Tim O'Reilly denouncing the Amazon.com patents to the cheers of the open-source crowd while continuing to sell most of his books under restrictive licenses.
But few cases show as close an intertwining of open and proprietary licensing as that of RTLinux, the real-time Linux add-on provided by Finite State Machines Labs (FSMLabs).
FSMLabs seems determined to fully pursue its right to collect patent fees for use of the technology, yet at the same time the technology is of little use to the company itself apart from its implementation on the open-source Linux operating system.
This article will attempt to unwind some of the complicated interaction between what is open and what is closed from the perspective of a developer and Linux advocate. As I'm not a lawyer, a legal perspective will be notably absent.
About RTLinux
RTLinux is a project started by Victor Yodaiken and Michael Barabanov when both were at New Mexico Tech. The two main techniques on which it is based can be stated simply . . .
- The computing hardware is put under the control of a simple real-time operating system. Linux itself is run as one task in this RTOS. The real-time portions of the application are implemented as the other tasks in the RTOS.
- To ensure that Linux cannot disable real-time interrupts that are needed by real-time tasks, the "disable interrupt" code in Linux is modified so that interrupts are still allowed, but only real-time interrupt handlers are executed -- Linux interrupt handlers are pended until an "enable interrupt" is executed.
- In this way, real-time tasks under the simple RTOS meet their deadlines, and Linux runs happily with whatever CPU time is left over. See some of the documents linked at the RTLinux website for detailed explanations of the technology.
Recently, the patent license was released. This license codifies the general principles that Yodaiken laid down early last year.
The RTLinux Patent
If you are a user of RTLinux, or of RTAI, the competing product built using the same two techniques as RTLinux, you will certainly want to read the patent license and judge whether it affects you. Its contents might be summarized as follows . . .
- The unmodified RTLinux approach -- If you use RTLinux unmodified, you don't have to pay any license fees provided you comply with the normal requirements imposed by the GPL. That is, modifications to Linux or RTLinux themselves must be GPL, but applications consisting of user-space programs or kernel modules need not be.
Note: the latter condition, i.e. that programs or modules that use RTLinux need not be GPL, applies only if you use RTLinux "out of the box" -- i.e. without modification. On the other hand, it appears that if you so much as fix a bug in RTLinux it no longer applies to you. - The GPL approach -- The license states that "... use of the Patented Process is permitted, without fee or royalty, when used .. [by] software licensed under the GPL ..." This condition would apply when, for example, a modified RTLinux is used.
I asked Yodaiken for a clarification of the term "used by". He states that the OS and the code that implements the patented process must be GPL, as must any application that makes use of the patented process. However, an application that does not make use of the process, but merely runs in the normal way under the OS, need not be GPL.
Further pressing that point, I asked whether a GPL application that uses RTLinux capabilities and must use the proprietary driver for some specialized third-party hardware would fall into this category. Yodaiken said yes, provided the driver wasn't used to hide application functionality. Yodaiken's intent here seems clear: you can use the process royalty-free in a GPL environment and application. The actual license language, on the other hand, is vague and likely to become lucrative fodder for lawyers. - Bookkeeping issues -- Regardless of whether you choose the unmodified RTLinux approach or the GPL approach, the license imposes certain procedural and bookkeeping requirements. You have to label any resulting product with the statement: "Used, under license, U.S. Patent 5,995,745". You have to distribute a copy of the license with your product. These seem harmless, but paragraphs 5 and 6 also seem to obligate you to notify FSMLabs via email whenever you include the patented process in your products.
Depending on how you read the two paragraphs, they could even obligate you to send FSMLabs a list of your customers! In this regard, I asked Yodaiken whether they obligate users to send their customer lists to FSMLabs. He replied that they do not -- that FSMLabs does not want anybody's confidential information. It is, of course, good that Yodaiken was so clear in his statement -- even better would be for the license itself to make that policy clear.
No one knows, of course, since to my knowledge Yodaiken hasn't yet attempted to enforce it in court. I can only provide a developer's perspective on whether the techniques patented are novel and non-obvious.
- The "OS on OS" technique -- It seems rather easy to find evidence of prior art for the first technique described above. Computing history is full of operating systems being run on top of operating systems. You can probably cite some yourself, but one of the more appropriate cases I recall from the dim past is that of iRMX for Windows 3.1, which was an RTOS that ran Windows as one task -- this corresponds neatly to the RTLinux model.
The OS on OS technique might also be vulnerable to a claim of obviousness. After all, even many non-specialists know these two facts . . .- operating systems run programs
- an operating system is itself a program
Surely it would be obvious to anyone skilled in the art that these two facts can be combined into . . .- it is possible to run an OS as one task of another OS.
- operating systems run programs
- The "deferred interrupt" technique -- This one doesn't seem particularly obvious, so you might go looking for some prior art. If you do, you'll probably find "Fast Interrupt Priority Management in Operating System Kernels", a paper written by Stodolsky, et. al. in 1993. At the time the paper was written, modifying the interrupt control hardware settings on most computers, and particularly PCs, was rather expensive in machine cycles. So instead of raising the interrupt mask at times when the processor should not be preempted, the authors proposed a method they called "optimistic interrupt protection," in which the interrupt was allowed to happen, but the execution of it was deferred depending on a software interrupt level maintained by the kernel. Thus the cost of changing the interrupt mask was saved on the optimistic assumption that the interrupt would seldom occur during critical times.
To me, this mechanism sounds very much like the one patented by Yodaiken. And it turns out that the similarity is acknowledged by Michael Barabanov in his master's thesis on RTLinux. Michael, a former student of Yodaiken's, was the primary implementer of RTLinux, and is now an employee of FSMLabs.
In the thesis he describes the RTLinux technique as "similar to that described in [the Stodolsky paper], but used for a different purpose." In fact, the techniques are the same in all important respects. Even the purposes are identical -- namely to ensure proper mutual exclusion. The only difference I see is in the motivation for using this technique rather than some other: performance, in the case of the Stodolsky paper; and ease of software integration, in the case of RTLinux.
Can you patent a motivation? Beats me -- ask your patent attorney.
The question of who invented what, and exactly when, among these products is well beyond the scope of this article. However, I'm guessing that a legal challenge to the patent would include sorting out that question.
How does this patent square with the GPL?
Yodaiken is, of course, free to pursue his patent rights as he sees fit -- the GPL is irrelevant to this right. The only relevant question is the status of the RTLinux code, which is released under the GPL.
The fascinating thing about this case is this: FSMLabs appears to be releasing code freely with one hand, while restricting its use with the other.
Actually, I find nothing in the GPL that prohibits this behavior, although the GPL does seem to try to prohibit it. Specifically, the GPL states . . .
- "... if a patent license would not permit royalty-free redistribution of the Program ..., then the only way you could satisfy both it and this License would be to refrain from distribution of the Program".
- Activities other than copying, distribution and modification are not covered by this License; they are outside its scope."
This suggests an interesting (albeit twisted) business model . . .
- Patent some software technique, borrow GPL software for the bulk of its implementation, and write a small amount of code to implement the patented part.
Is such a strategy within the spirit of the GPL?
Clearly not! It is inconceivable that the authors of the GPL (or of Linux) would wish to allow "copying, distribution, and modification" of the code but not running it.
The real questions are: Do the restrictions imposed by the patent license fall within the spirit of the GPL? And, more specifically, how do the restrictions square with the intentions of the developers of Linux?
Yodaiken contends they are within the spirit of the GPL. After all, the RTLinux license allows using the patented process if you are using a GPL OS and distributing the application under the GPL.
But it is the oft-stated position of Linus and other Linux contributors that they wish to allow proprietary code to be run under Linux. And the GPL states "... it is not the intent of this section [which defines a modified work] to claim rights or contest your rights to work written entirely by you ..." So neither the GPL nor the Linux developers seek to impose restrictions on your application.
Yodaiken's restrictions do not appear to fit within that spirit.
What to do?
Users of the patented process -- and for Linux users, this essentially means users of RTLinux or RTAI -- ought to consider how to deal with this issue. This includes even those see-no-evil folks who complain loudly on the RTLinux mailing list whenever the patent issue is raised. You need to consider whether you are using someone's code or methods without proper licensing.
- In-house use -- If you are developing an application for in-house use under RTLinux, it seems that you need not worry about it. The restrictions seem only to apply to systems distributed externally. And because RTLinux tends to be very popular with Unix-oriented developers working in academic labs, this includes a large class of users. Of course, the situation gets more complicated if the system you are developing ever moves out of the lab.
- GPL applications -- If you are developing a GPL application under RTLinux, you're also covered. You can distribute your application freely, and modify RTLinux to meet your needs. However, don't forget the requirements listed under "YOUR OBLIGATIONS" -- especially the "email FSMLabs" requirements, if you can determine what they mean.
- Unmodified-RTLinux applications -- If you plan to release your application under any license other than the GPL (including, presumably, the LGPL or any other open-source license) you're covered if you use RTLinux "out of the box", i.e. with no modifications whatsoever. As soon as you modify it, you fall out of this class. This approach effectively puts RTLinux in the same class as the many "look but don't touch" RTOS products that include source code. Again, the "YOUR OBLIGATIONS" requirements apply.
- RTAI -- Presumably, any application using RTAI would be prohibited, since RTAI is licensed under the LGPL rather than GPL (as required by the patent). Therefore, even a GPL application using RTAI would fail to meet the requirements for royalty-free distribution because RTAI itself is LGPL. Yodaiken is well aware of RTAI and its licensing, so this policy appears to have been deliberate. It's hard to imagine hordes of FSMLabs lawyers hunting down RTAI users in academic labs, though.
- Other situations -- If you don't fall under either the GPL or unmodified RTLinux provisions, I suppose you have two choices: ignore the patent; or, work out a licensing arrangement with FSMLabs. Ignoring a patent is, of course, risky. Developers considering a platform for a mission-critical application are unlikely to take this approach without first seeking legal advice. Of course, many mission-critical applications begin life as an informal study by a small group -- they cannot justify the expense or bureaucratic hassle of dragging a lawyer into the process at that stage.
Of course, negotiating a royalty agreement with FSMLabs is also an option. You can line RTLinux up with the crowd of commercial RTOS products and pick the best one. If you are committed to using Linux, RTLinux might be a good choice. On the other hand, with its unconventional programming model, bewildering-to-beginners API restrictions, and limited documentation, RTLinux is unlikely to fare well against better-established commercial competitors.
The bottom line
When Victor Yodaiken's patent first become known early last year, some observers were hopeful that it would be merely defensive, protecting open-source real-time application developers against some outside commercial predator. However, the recently released license makes it clear that the aims of the patent go well beyond the defensive -- it forms the basis for a unique hybrid open/closed software company.
Yodaiken has correctly pointed out that most open-source software companies have both open and closed source products; and many others (such as Trolltech) release one product under multiple licenses. But the particular hybrid licensing that he has constructed out of the GPL and his patent license is both fascinating and disturbing.
It seems to me, RTLinux is a fine system with great potential when thought of as an open-source project. I'm not sure it will fare as well when looked at as a commercial RTOS.
Author's bio: Jerry Epplin has written embedded software for the past fifteen years, primarily for medical devices. He wrote the first semaphore facility for RTLinux. He can be reached at jerry@linuxdevices.com
Related stories:
- RTLinux -- a hard real-time Linux add-on
- DIAPM-RTAI -- a Real-time Linux API
- Yodaiken unveils RTLinux patent license
- "The Infamous RTLinux Patent"
- Victor Yodaiken on the past, present, and future of RTLinux
- The GNU General Public License
Talk back! Do you have questions or comments on this article? talkback here