Slashdot Mirror
Lineo Pays To License Real-Time Linux Capability
An Anonymous Coward writes: "Embedded linux vendor Lineo has apparently caved in to Victor Yodaiken, and become the first software company to publicly announce the licensing of Yodaiken's patented process for running a general purpose operating system (such as Linux) as a task under a real-time kernel(such as RTLinux or RTAI)."
There's a special report at LinuxDevices which includes . . .
- text of the Lineo press release
- comments from Victor Yodaiken
- news of a non-patented open source alternative ("Adeos")
- a reference list about RTLinux and the RTLinux patent
- a whitepaper about Adeos
First off, I could give a fsck about what Stallman thinks.
Second, your rant is full of if's and but's. If Yodaiken changes the license, but we can't do this. Just be glad that Yodaiken holds the patent and not Micro$oft. Then you'd have no way to use the software at all.
Perhaps I'm wrong, but:
This License governs the royalty-free use of the process defined by U.S. Patent No. 5,995,745. Anyone can license the use of the Patented Process by agreeing to be bound by the terms of this License. Such person is considered to be the Licensee ("Licensee"). The Patented Process may be used, without any payment of a royalty, with two (2) types of software. The first type is software that operates under the terms of a GPL (as defined later in this License). The second type is software operating under Finite State Machine Labs Open RTLinux (as defined below). As long as the Licensee complies with the terms and conditions of this License and, where applicable, with the terms of the GPL, the Licensee may continue to use the Patented Process without paying a royalty for its use. You may use the Patented Process with software other than the two types mentioned above but you must first obtain a separate license for such use. The first step is to contact Finite State Machine Labs (www.fsmlabs.com).
That reads okay to me. Very similar to the GPL (in a sense). You don't have to pay unless you are charging people for it.
I really like the way this works. It prevents the co-opting of the abstract of the program for commercial use. For example the way IBM's early BIOS was clean-room reverse engineered to provide copyright-free alternatives. When it comes to GPL software I'd be happy to see a commercial entity have to pay to use the underlying idea of a program for commercial closed-source use while the GPL world get's to use it for free.
Maybe I'm a little naive, but it seems like the patent basically makes any attempt to cash in on the technology null and void, essentially keeping free software free.
I could an uproar if Victor was charging for the license, but he's explicitly not charging it for, and I can see where that would be beneficial.
Patents are a tool. In the wrong hands, they hurt; in the right hands, they don't.
Beware typoes.
Anyone have experience with one of these real-time Linux systems? How good are they at hard-real time tasks? I'd especially be interested in simulator applications.
That'll be very useful for high-bandwidth multimedia playback, which currently seems to be a problem for some UNIX-based systems such as Mac OS X. Is anyone looking at a Darwin port?
Tim
[Disclaimer: I work for MontaVista, and so am as biased as they come]
Interesting, that is. However, I doubt it'll gain them much.
MontaVista has been doing work on real-time Linux also -- not by putting another layer on top of or underneath the kernel, but by making it highly preemptible. Nigel Gamble (the fellow who did IRIX's real-time capabilities) has put together a patch which permits for some extremely low latencies. There are some other folks here working on the same thing. This has side-benefits for folks running SMP boxen, even if they don't need real-time capabilities, by making the spinlocks much more fine-grained. This patch is truly open source, and will hopefully some day make it into the mainline kernel.
We've recently inked a deal with Concurrent (http://www.ccur.com/corporate/pr/pr_208.html) that real-time folks might find interesting (as Concurrent has some interesting tools) and much of our real-time work has been known to readers of linux-kernel for quite some time. Additionally, our real-time patches are included in the kernels distributed with our products.
Note that I'm on a different project, so my knowledge of the real-time work we do is quite fuzzy. Suffice to say that we've got a highly preemptible Linux kernel already, and that it's still being improved. Hopefully someone else from MontaVista with better direct knowledge will also post.
Okay, question. If you're concerned about keeping it free, please state how it (your original) can possibly become unfree? Derivative works may be different, but your software itself will always be free. People will always be able to use it and improve it as long as it exists, regardless of the state of copyright.
A Government Is a Body of People, Usually Notably Ungoverned
It looks like somebody has beaten you to it.
-----
Free P2P Backup, Windows & Linux
Years ago, IBM had a realtime system kernel that ran on 360/370/43xx hardware called CP or control program. You ran the os of your choice on a virtual machine presented to you by CP. Oddly enough one of the uses for this was a port of UNIX to 360/370 type hardware. Others were typically VM-CMS for virtual machine cambridge monitor system aka virtual machine conversational monitor system, cics or "kicks" to name a few. Why is this not prior art where in one runs an ordinary os on top of a real time kernel? Why is the Yodaiken patent invalidated by the prior art of IBM? Would IBM license its rights to the same idea and reduction to art to the Linux community now that IBM is big on Linux? Why do we have to tolerate bogus patents and constant shake downs by those with the bogus patents. I thought the burden of showing the non-existance of prior art was on the potential patent filer and not the rest of us. Just asking. Does anyone else know of similar but different prior art for the so-called new idea of running an os as a task on a realtime kernel? Basically I am for innovation but it has the odd property that it has to be new.
The problem with this, besides the fact that the claim is a very broad one which covers software which other people might want to write, is that it perpetuates the idea of the GPL as being like a virus. I happen to agree. The GPL attempts to infect software in such a way that it dictates what an author may or may not do with their own software. You may agree or disagree with this. What this patent case does is far worse. This is *not* a case of a software author having the choice to infect their code with the GPL and make use of someone else's code in their project, or having the choice *not* to infect their code with the GPL and simply write all their own code, or else go find code to use that isn't covered by the GPL. This is about someone who believes in the GPL so much that they want to extend to software they haven't even written. The patent holder wishes to construe his patent so broadly as to force all programmers anywhere who wish to develop certain kinds of software to be covered by the GPL. That is truly bad. I don't personally like the GPL, but I understand that all those who put their software under the GPL have the right to do so, and all those who use software covered by the GPL do so understanding the legal consequences, and that's their freedom of choice. But trying to *force* others to make their software be under the GPL whether they want to or not is truly despotic. Software patents are wrong, whether it's a company like Microsoft trying to force some company under the Microsoft Hegemony, or some GPL fanatic trying to force someone else under the GPL hegemony. I think the supports of Free Software, and the supporters of Open Source software, should stand for, at the very least, personal freedom, and the right of an individual to write code as they see fit and to license it as they see fit. Forceful tendencies are reminiscent of the company practices of some companies which we always seem to portray as the "enemy". Have we become the enemy?
Windows 3.1 does not count as an OS. It ran on an OS called DOS. Now people might not want to call DOS an OS, but it fit that role even those not very well at it. Microsoft Windows up to 3.1 was just a program running in the operating system. So your RTOS was not running a general purpose OS if it was running Windows 3.1.
now we need to go OSS in diesel cars
The hypocrisy of the Free Software Movement(tm) has become so commonplace that it doesn't even surprise me anymore. First, since "software should not be owned" you're supposed to copyright it. Second, since software should be unrestricted, you should place it under a restrictive license.
Now, patents are evil, so lets all patent our ideas! This is not how patents should be! There should not be patents for algorithms, formulas or processes. Specifically, there should not be any patents for software unless they are non-algorithmic, novel, and unintuitive to a practitioner in the field.
No software covered by a patent can possibly meet the Free Software Definition.
A Government Is a Body of People, Usually Notably Ungoverned
Lower latency is a fine and useful thing for a number of things. But don't make the mistake of confusing low latency with hard realtime.
If I am driving a robot's servo controller using software to close the PID loop, I have to send now positions exactly at the servo rate, or the robot will "jerk", a potentially dangerous situation. If I am using the MontaVista low-latency patch, I still have no guarantee that I will be able to send out position updates at the servo rate. If Linux decides to swap out Netscape to disk, or someone hits eth0 with a ping flood, my robot will end up hitting the side of the workcell, and people might be hurt or killed.
If I am playing Quake, and Linux decided to swap Netscape out to disk, or someone hits eth0 with a ping flood, my frame rate my go down a little bit. With the low latency latches, it might go down a little less.
The point is, low latency does not provide any sort of a guarantee on response time. This is why we have things like RTLinux and RTAI -- to provide guaranteed reponse times for timing critical event handling.
-Erik -- --This message was written using 73% post-consumer electrons--
And it would help if you actually read the documents for which links are provided.
/different/ hard-real-time linux technology, RTAI.
What Lineo has done is paid for the right to tell customers "Yes, the Yodaiken patent is not a problem, it's been taken care of" when offering a
Lineo doesn't use, and doesn't plan to use, RTLinux. They're heavily vested in RTAI. Just got tired of customers asking "What about the Yodaiken patent?!"
You'd know that, if you'd read more than the submission.
This is just like television, only you can see much further.
It doesn't matter whether this patent is used to protect free software or whether the inventor allows GPL'ed software to use it, it is still a bad patent. It also doesn't matter that commercial entities are using patents that are just as bogus.
Now, a portfolio of good, strong patents used in this way might, in fact, help free software.
You are correct about the distinction, however even by that definition rtlinux is more 'hard' than MontaVista.
I have a positive modifier on Troll. When I mod someone Troll their karma should go UP!
Or at least, that's how I thought the distinction went.
No, both the running-Linux-as-a-process and kernel pre-emption techniques offer the same 'hard' real-time guarantees of scheduling latency. Obviously, they differ in their approach.
The Linux-as-a-process technique that Yodaiken has patented is both simpler to understand and implement. A small, new real-time kernel (the RTLinux kernel) runs the standard Linux kernel as a normal process. Real-time applications are written for the RTLinux kernel (there is a thunking layer which allows Linux processes to use RTLinux syscalls), and when a realtime application needs to service an event, the RTLinux kernel can interrupt Linux and schedule the realtime application instead. The major downside of this approach is that calling RTLinux syscalls from a Linux application involves this thunking layer, which is by its nature, somewhat costly and slow. It also means realtime programmers have an extra API to worry about.
The pre-emptible kernel approach, on the other hand, does away with an external kernel, by making the Linux scheduler itself able to interrupt and reschedule kernel code as well as the normal userspace code. If an event arrives that must be serviced within a certain timeframe, then the Linux scheduler simply stops whatever else the Linux kernel is doing and services the request. This is a much harder approach to get right, especially as it involves some significant redesign of the way kernel-space code is treated. However, ultimately, I think it is the more elegant solution, and it means that there need not be a thunking layer or extra API - existing realtime applications suddenly become able to do 'hard' realtime.
Note that 'hard' realtime is not necessarily about responding to events quickly, but merely that these events can be dealt with in a guaranteed time frame, which could range from microseconds to seconds. In practice, 'hard' realtime does usually mean fast however. 'Soft' realtime scheduling, such as what the standard Linux kernel offers, makes a best-effort attempt to reduce scheduling latency to a minimum, but does not provide a guarantee that an event will be dealt with within a certain time. In 'soft' realtime, a realtime event is ignored until any kernel code that is currently running reaches its next instruction to deliberately yield - rather like the way userspace code is treated under a co-operative multitasking OS.
Perhaps you were getting confused with the low-latency patches for the Linux kernel? These attempt to reduce realtime scheduling latency in the Linux kernel by adding extra points where the currently-running code is told to yield back to the scheduler (and also by tweaking some of the kernel algorithms). However, this does not mean that the scheduler can interrupt kernel code. Thus it represents merely an improvement on Linux's normal 'soft' realtime scheduling and not 'hard' realtime at all.