Yodaiken goes for a patent on RTLinux

The RTLinux model has unquestioned utility, and everything was fine until early last year when it was noticed that Victor Yodaiken had been issued a patent for the technology, with the main claims being the two techniques described above. Yodaiken stated that the patent was mainly defensive, but that he intended to collect royalties on commercial use of the methods claimed in the patent while still protecting RTLinux users, but that the precise details had not yet been worked out. This revelation caused some consternation, but nothing could really be done until the RTLinux patent license had been finalized, so the situation rested momentarily.

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.

Is the patent enforceable?

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.
  
  
• 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.”

A loophole in the GPL?

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.

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.