Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Patents

Lineo Pays To License Real-Time Linux Capability 143

Posted by timothy from the now-how-much-would-you-pay?- dept.
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
There's an interesting quote where Yodaiken claims his patent will help open source."
This discussion has been archived. No new comments can be posted.

Lineo Pays To License Real-Time Linux Capability More

Lineo Pays To License Real-Time Linux Capability

Comments Filter:
  • Is there a specific reason why POSIX.4 support has not been added to the Linux kernel?

    Is it just a matter that nobody has gotten around to it yet or is there a reason why it would be a bad thing?

    Just curious...

  • I'm not seeing a problem here... (Score:5, Informative)

    by joshamania ( 32599 ) <jggramlichNO@SPAMyahoo.com> on Monday August 06, 2001 @01:54PM (#2111878) Homepage
    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.

    • This really could help open-source development - if there is a convenient method to license all this software to be used in for-sale products, companies would be much less likely to just use it and hope no one notices. Its easier to just pay the fee and know that you won't have any legal problems later.
    • RMS would make a wet spot out of you! You are
      taking it completely wrong. GPL made so that
      anyone can charge for software, but no one can
      restrict its use but a software author,
      if he changes his licence. But he can change his
      licence only for new changes, not for stuff he/she
      gave away. So no these terms are completely
      unacceptable for free software community.
      I wonder what linus will say, that stuff as general
      as RT extensions are being licenced under different
      restrictive licences. These guys cannot
      packaged kernels with RT software under restrictive
      licencing. They can sell/distribute only patches.
      2c
      • 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.

        • Re:I'm not seeing a problem here... (Score:1, Informative)

          by Anonymous Coward
          Just be glad that Yodaiken holds the patent and not Micro$oft. Then you'd have no way to use the software at all.

          I'm not sure you know Victor's intentions, so let me fill you in a little ...

          The RTLinux project on which Victor's patent is based was first implemented by Michael Barbanov as his master's thesis. Did we ever hear about Michael again? No, he's back in Russia and the patent doesn't even have his name on it. Why isn't Michael leading the project anymore ... why do we only hear about Victor now? ... go figure.

          This is an open-source project in the purest of open-source traditions, right? Wrong. All RTLinux's code is copyrighted by FSMLabs and if you came to contribute it is likely that they would integrate your code without proper attribution and it has happened in the past, including code taken from the kernel. Why? Because they need to be able to sell RTLinux's source code in closed-form and they can only do this if all of the code belongs to FSMLabs. Yes (if you didn't know about this) you can purchase the RTLinux source code in closed-form if you'd like. Yes, this is legal, but is it in the spirit of open-source, that's highly debatable?

          Victor first claimed that his patent was defensive, to protect himself against the evil empires who'd want to opress the OSS community. Yet, he later denied that he ever claimed that the patent was defensive. When pointed to previous RTLinux mailing list archives about his original statement, he didn't reply, but said archives have mysteriously become unavailable. Try accessing the January 2000 RTLinux mailing archives. Although all other archives are available, that one isn't. If it ever becomes available again, look at the January 27 posting by Victor, a copy of which can be found at LWN [lwn.net]

          What this community needs to realize is that Victor is not who he claims to be. He is after the money, open-source is really a secondary worry.
          • In the post you link to Victor claims his primary reason for the patent was defensive, but that he intended to charge for proprietory usage. This doesn't seem like very damning evidence on its own.

            The article isn't very clear on exactly what Lineo is doing, but if it's proprietory, it sounds like Victor is doing exactly what he said he would.

            Care to offer some more convincing evidence?
        • Ugh... people should be trying to start an uproar here, not sitting back and saying "at least so-and-so registered this stupidly obvious patent and not Microosft". Howcome it's OK to patent using a kernel with an OS, but not to patent a compression algorithm or a hyperlink?
    • The GPL doesn't say anything like that.
    • That sounds okay... the patent is licensed freely for use in any GPLed software. This would appear to conform to the GPL's provisions about patents (basically, you may not distribute the program without also granting a licence for any applicable patents) and it looks reasonable from common sense.

      It's not demanding any special fee for commercial use, so it counts as free software still (aka Open Source etc etc).

      At least, from the paragraph you quoted above everything seems fine. It would still be better for everyone if patent offices would refrain from granting monopolies on abstract ideas however...
      • It's not free software. As far as I understand it, it puts restrictions on how this software can be used, which is against one of the basic free software freedoms.
        • Well yes, the patent licence is about usage of the so-called 'invention', rather than about distributing copies. That's how patents work. But since the only condition is that the patent be used as part of a GPL (or similar) program, and any version of Linux fits this criterion, no extra restrictions are imposed *in practice* by the patent licence. Anything which used some code from Linux would have to be GPLed anyway.

          • IANAL but...

            From what I can tell this license is saying the only software that can use this patent for free is GPL software. (or RTLinux, but that's beside my point)

            So, none of the linux distros fit this criterion, because even if you stay with only the free branches, you're still going to have artistic, BSD, and other open licenses commingled. (see the gnu website [gnu.org] for more info on the GPL and free vs open software)

            That's if you interpret the license to mean *all* software used with it must be GPL'ed. However, I believe the author's intent is that the software implementing his patented algorithm must be GPL'ed, which would mean he's forcing the GPL seed into any project that wants to use it for free.

  • I love it. (Score:2, Informative)

    by BlenderHead-2001 ( 512595 )
    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.
    • But does that mean it could also prevent free software from co-opting the abstract of a program for free use?

      I'd hate to see BigSoftwareCompany sue the pants off an author because they wrote something that worked just like their patented underlying idea. "Not only are we protecting this IP, we're protecting anything that sort of looks like it"

      Xix.

  • Can Lineo's version of linux still be considered general purpose? Seems pretty geared towards specific functionality to me. I havne't read the patent, so maybe this is answered already.

  • Prior Art....Prior Art....Prior Art.... (Score:1, Interesting)

    by Anonymous Coward
    I can't believe this patent is still unchallenged...
    It was filed in 1997.

    Way before 1997, I was working with a commercial RTOS that ran Windows 3.1 as the lowest priority task.

    I would call that prior art... What's wrong here???
    Comments anyone???

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

      • People say (said) that Win3.1 was not an operating system because there was already an operating system, DOS, running under it.

        However, the same argument would apply to Linux running on top of RTLinux; the Linux "environment" relies upon the underlying system (RTLinux) to provide it with some (but not all) services. The situation with Win31. and DOS was quite similar -- Win3.1 relied on DOS for file I/O but on the other hand it managed the display resources by itself.

        Fopr this reason I would say (though I'm not a lawyer) that the example of Win3.1 running on top of an RTOS would seem to count as prior art.

        That said, there will certainly be specific claims in the Y patent which are not covered by this (potential) prior art, so the patent would not be completely invalidated.

        Also note that a patent covers not the doing of a thing, but the method by which that thing is done. For example, you can't get a patent on the wheel, but you can get a patent on a new way for making or using wheels. The fact that the wheel has existed for a long time doesn't mean that no new methods or inventions around it could exist. For example, it's probably possible to get a patent on a method for manufacturing identical sets of almost perfectly round wheels via nanotechnology (e.g. think - how do the nanobots know how much local curvature to apply, and how to they avoid generating a sphere rather than a disc). So, plenty of room for innovation even in established areas.

        Happily this probably means that there are ways of achieving this without falling afoul of the patent. On the down side, it's possible that nobody will figure out how to do it faster or more efficiently than the way that the patent specifies. That's life, but you can always wait for the patent to expire.

      • DOS _is_ an operating system, altough very, very, very lousy :o) A car priced at 2500$ is still a car, however most people won't respect it as such :o)

  • Is this a bad thing? (Score:5, Insightful)

    by Foggy Tristan ( 220356 ) on Monday August 06, 2001 @01:54PM (#2122507)
    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.

    • Re:Is this a bad thing? (Score:1, Insightful)

      by Anonymous Coward
      This is an empty argument which Victor has used over and over and over. Take a moment and imagine where the Linux kernel would have been had it been licensed under the same terms ... Nowhere, there's where it would be. If we limit the use of real-time in Linux to free software then no IBM will become involved in its development as has come to be with Linux. This patent effectively kills Linux's integration into the real-time systems market because there is no difference now between using QNX and Linux for real-time systems. You can use QNX's source code and play around with it as long as your project is free, but you have to pay when you use for a product. This is exactly the same thing with Linux. This patent has QNX, VxWorks and others laughing hard at us right now. Does this community really want to support Victor in this endeavour?

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

      Umm, free speech, or free beer? I could care less if I had to pay $100,000 a copy as long as it was liberated, not gratis. Doesn't look to be the case here.

  • As far as I can tell, there is nothing wrong with the patent.
    It permits free use of the code to anyone who wants to
    use it for non commercial purposes, and requires a seperate license for
    anyone who wants to use the code to make money. This is how patents
    should all be. Rather then the patent holder attempting to create something then extort
    insane ammounts of cash from anyone trying to use the technology.
    • 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.
      • software should not be owned ? who said that ? the only reason for copyrighting and patents is to get around the stupid laws which exist to deny people the right to share code. thats the whole point of the free software movement.
        if we patent all our ideas and make em freely available it prevents others from patenting them and locking them up in proprietary licenses. its a way to get around the stupid situation which exists in this country. nothing more nothing less. and i dont see how hypocrisy has anything to do with the goals of making open source software available to anyone who wants it with the minimum of restrictions..
        • software should not be owned ? who said that ? the only reason for copyrighting and patents is to get around the stupid laws which exist to deny people the right to share code. thats the whole point of the free software movement.

          You can share all you can muster under public domain. No laws are restricting you. I think you have misunderstood the concept of giving. If you give something with a constraint or expectation, you really haven't given anything at all.

          if we patent all our ideas and make em freely available it prevents others from patenting them and locking them up in proprietary licenses. its a way to get around the stupid situation which exists in this country.

          Just publicize the ideas and blueprints. It will become prior art, public knowledge and an unrestrictive benefit to the entire society.

          and i dont see how hypocrisy has anything to do with the goals of making open source software available to anyone who wants it with the minimum of restrictions..

          I wouldn't call it hypocricy, but rather lack of understanding. You see anything that isn't benefiting you as bad and something that is to be avoided. That's sad, for you, because you'll never be happy when you're not giving.

          - Steeltoe
        • software should not be owned ? who said that ?

          Richard M. Stallman, in his article "Why Software Should Not Be Owned."
      • What hypocrisy? This is the real world, and in the real world there are copyrights and patents, and there are private distributors of proprietary software incorporating copyrighted and patented information. That's it.

        So if you want to release Free Software, free in the libre sense that anyone can use it and improve it and still keep it free.

        The fact the developer of a given body of work can maintain his right to re-license the work is immutable (unless you are a musician or a hack ;)

        Licensing the work under different conditions than those of the GPL to a private entity who will use the work to create a non-free product is totally consistent with the idea of Free Software. It both allows the developer his choice of licensing, and allows the distribution of Free Software.
        • So if you want to release Free Software, free in the libre sense that anyone can use it and improve it and still keep it free.
          that should read:

          So if you want to release Free Software, free in the libre sense that anyone can use it and improve it and still keep it free, you have to do it under the prevailing conditions, using Copyright to protect the liberty of your work.

          Sorry about the double 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.

  • Anyone use a RT Linux in the field? (Score:3, Interesting)

    by JWhitlock ( 201845 ) <John-Whitlock@@@ieee...org> on Monday August 06, 2001 @02:01PM (#2128152)
    I'm working for a company that works with hard real-time systems, and I've been pondering testing Linux where we are currently using a propriatary system. While I don't like the idea of supporting a software patent, I'd still consider it if it was cheaper and was truly hard real-time (certain tasks are guarenteed to execute within a certain amount of time).

    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.

    • I'm working for a company that works with hard real-time systems, ...

      WTF is a hard real-time system?...

      is it:
      a) Pornographic?
      b) difficult?
      c) rigid?

      Shrugs

      • Re:huh? (Score:1)

        by Hast ( 24833 )
        Difficult is basically the gist of it. ;-)

        Seriously, a hard real-time system is one in/on which you can guarantee that your programs will have time to run. This means that the scheduler must be deterministic (On this most user OS's fail since they are more tweaked to making the computer seem fast.) and that it is possible to calculate execution times and maximum time a thread can be put on hold.

        Naturally it also, just like a normal real-time system, should have primitives for locking and algorithms for avoiding dead-locks.

        • Re:huh? (Score:1, Funny)

          by Anonymous Coward
          If I need a pulse to my heart every 50 milliseconds, then I wanna know that I can play quake on my pacemaker, and open a thousand Mozilla windows, and the worst that'll happen is that the mozilla windows will hardly ever get a timeslice. I want to know that if the kernel cant' read/write to an area of RAM, it's guaranteed not to miss a beat while it waits for the read request to "time out" -- every POSSIBLE time out is guaranteed to be fast enough to allow the scheduler to fulfill the promised tasks. Or, if you want to think of it in different terms, the system has to be in such a state that there will always be 0 latency between moving the mouse and seeing the cursor move on screen....that's very very very difficult to do. To "guarantee" that. Sure, it may be /usually/ like that, but you really need "proving algorithms" to guarantee you that each function you enter is made up of subfunctions that, when added up, are under the quota for the function. One of the things that this means is that you can't just have a generic "sort" function -- because it takes longer to sort a million records than it does just one. In other words, everything has to be in "constant time" -- and provably so. (In other words, you can forget about using the cos() function in math.h if you're not guaranteed that it will be constant time for values of null, 0, 1, 300, -32012, or any other value, acceptible or non-acceptible, including all possible error handling. That's hard.

    • Re:Anyone use a RT Linux in the field? (Score:1, Interesting)

      by Anonymous Coward
      Check out this article [ddjembedded.com] as well as others at ddj embedded site [ddjembedded.com]
    • Yes, I've used MontaVista's real-time distro. but only for soft real-time tasks. It could'nt keep up with transcoding ATM AAL-1 to AAL-1 at OC-48 Line rates. For Hard real-time requirements you just can't beat uC/OS-II.

  • real-time in user space (Score:3, Interesting)

    by tim_maroney ( 239442 ) on Monday August 06, 2001 @02:19PM (#2128316) Homepage
    Here's an interesting bit from an interview with Victor Yodaiken [linuxdevices.com].
    We have a new ability for real-time signal handlers in user tasks, where the user process makes an rtlinux_sigaction which will work like the POSIX sigaction, except the signal handlers run in realtime and there's an extension to allow us to catch periodic interrupts. As a result, the user process can designate a function to operate within hard real-time deadlines. And those functions run in the address space of that process, so they can share data with the process, and call functions libraries of the process.

    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

  • Not the only (or best) game on the market (Score:4, Interesting)

    by cduffy ( 652 ) <charles+slashdot@dyfis.net> on Monday August 06, 2001 @02:08PM (#2132056)
    [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.
    • As far as I understood it, MontaVista and FSM Labs aren't even in the same ballpark -- MontaVista's technology allows for running a normal Linux process with very low input/output latencies, on the order of a couple milliseconds. This is great for multimedia applications, particularly where you need immediade auditory-visual feedback from the user's actions without any perceptible delay, without doing a lot of OS-specific coding.

      RTLinux on the other hand is designed for hard real-time scheduling with microsecond latencies, but you have to write your programs for the RTLinux kernel (which runs Linux as a subprocess.) Which is great for industrial and scientific control/data acquisition applications, where you need to be guaranteed not to screw up the precise timing of your large deadly instrument, and can pay for custom programming.

      Or at least, that's how I thought the distinction went.

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

        • OK. I was under the impression that MontaVista had been doing something more like the low-latency patches. Thanks for the clarification.

          However, it still looks like [linuxdevices.com] MontaVista provides hard realtime with millisecond scheduluer latencies, while RTLinux is faster, in the range of 10 sec latency.

          • To clarify, MontaVista's low-latency patches produce soft realtime with millisecond scheduluer latencies, while RTAI and RTLinux produce hard determanistic realtime in the range of 10 ?sec latency.

            Visit realtimelinux.org [realtimelinux.org] for proper definitions of real time...

    • hard vs soft (Score:2, Insightful)

      by andersen ( 10283 )
      [Disclaimer: I work for Lineo, and I wish we hadn't caved in...]

      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.

      • ...and guaranteed response times are precisely what Nigel is working on.

        There are still a few places where >2ms (IIRC, which I quite possibly don't) delays are possible, but these *are* being addressed; we should be able to guarantee better than 1ms response times when complete. Yes, we know the soft/hard real-time difference, and do have means to address it -- but what I know of these strategies (overheard during lunchtime conversations) isn't really enough to provide details.

        I really do wish we had someone more deeply involved with the real-time patches posting here -- my information is more than a slight bit fuzzy.

        Finally, might I add: If one is running a robot, it makes much more sense to have a microcontroller which does nothing but send out position updates at a rate requested by the primary controller; that way, the fancier controlling system (doing all the networking and programmability that a real OS is needed to do) need only provide updates when there's a change in movement rate, and soft real-time becomes more suitable.

        • As for guaranteed response times from just Linux, I am extremely dubious. Yes, you can be fast. But you can't be fast, and handle an arbitrary load, and provide guaranteed respone time.

          As for robotics, let me warn you that my MS work was in Manufacturing Engineering (BS Mech Eng), was in robotics... Anyways, if one is running a robot, and is driving the robot to do path following in Cartesian space, then one must be doing the mapping from Cartesian space to joint space (i.e inverse kinematics) at the servo rate. Further, for proper trajectory generation one needs to check for nasty things like joint inversion, signularities, etc, and must also take into account constraints such as maximum joint positions, maximum joint speeds, etc. Oh, and you need to watch for asyncronous events that may cause you to modify the trajectory in mid move... Did I mention the cameras, being used for real time image analysis, and ridgid body transformations of target fiducials? I used to write code to do all this stuff. The holy grail of machine control would be to have a little microcontroller doing all that work.

          • I'm not saying that the trajectory generation parts should be done on the microcontroller -- merely that the individual movements should be done by a microcontroller, reducing the frequency at which the primary controller needs to signal. As long as the primary controller gives the microcontroller no signals which can't be respended to without violating constraints, the microcontroller need not worry about it; similarly, the microcontroller would be signaled in events where trajectory modifications &c. are needed. What I was suggesting was not moving the full motion control to the microcontroller, but rather having the primary controller only signal the microcontroller when a change in velocity is needed, as opposed to every time a stepper motor must move.

            (Of course, some constraints are still needed -- it wouldn't do for the controller to send a signal to the effect of "15 degrees rotation on joint X per second until I say otherwise" -- but "15 degrees rotation on joint X per second until I say otherwise or 45 degrees rotation have been reached" should work).

            Of course, I'm talking out of my ass here -- you've a great deal more experience in robotics than I. Hopefully, though, you can appreciate what I was trying to communicate.

            As for guaranteed response times from Linux, you're not the first person to be dubious. We'll be doing the whole major-press thing once we've Got It Right, and I look forward to that day.
            • I dunno, you're both way ahead of me, but I think what he meant was that in certain situations, especially with really complex robots doing really complex things, "15 per second until I say stop" isn't enough. (Though these situations may be more or less common, I have no clue.) For fluid, non-linear movement, you'd be sending so many signals to the microcontroller that its accuracy is wasted when the primary controller is inaccurate.
              • True -- but non-linear movement hardly seems the common case.

                Should he claim otherwise, of course, I haven't the background to contradict.

  • Hey, what about a sense of history here (Score:4, Interesting)

    by Anonymous Coward on Monday August 06, 2001 @02:17PM (#2142766)
    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.

    • Re:Hey, what about a sense of history here (Score:1, Informative)

      by Anonymous Coward
      Well, people were running RT-11 under RSX back around 1979. I also published MSX-11, a distributed MLS system, which had a variant that ran the MLS system as a network in a box, all running under RSX11D. (In that mode it was a test system.) That was published in DECUS #11-SP-6 back about 1979, in source. There are plenty of examples of running an OS under another OS, some even earlier than IBM's work. It was done on pdp8 way earlier, for example. Then too, VM/370 was a full virtual machine, not just os under os. Seems to me such an idea has so many prior implementations it would be tough to sustain, unless the patent is very specialized. As for hooking in realtime handling of various OS signals, that is very well covered in prior art.

    • Re:Hey, what about a sense of history here (Score:1, Informative)

      by Anonymous Coward
      AmigaDos did this too, if I remember correctly. It was a non-real-time OS running on top of the real-time Exec.

    • Re:Hey, what about a sense of history here (Score:1, Informative)

      by Anonymous Coward
      I saw a presentation back in in 1997 of a company who provided a real time solution of running Windows NT as a process in a real time kernel completely comparable to the RTLinux solution. Forgot the name of the package and the name of the company. When did Yodaiken file this patent?

    • Why are all the replies to this moderated down? Some of them are interesting, and relevant.

    • It's hard to prove a negative. The PTO is supposed to do some research to see if they can find prior art, but when it comes to software, they don't, even when to do so would apparently be quite trivial.
      • It's hard to prove a negative. The PTO is supposed to do some research to see if they can find prior art, but when it comes to software, they don't, even when to do so would apparently be quite trivial.

        No it isn't. The PTO system relise upon the honest of the applicants. The PTO does not have the expertise to search for prior art, never has, never will.

        The US PTO can't even perform searches of already issued patents competently, so what is the chance that in the 10 hours allowed for the average examination the clerk with a law degree is going to find prior art? An examiner does not need any actual experience of the field they are examining, just a relevant(ish) degree.

        What is meant to be the bar to malicious/criminal patent applications is the difficulty of enforcing the pieces of utter crap that get issued. Then Lemelson came along with his perjured 'bar codes' continuation of 'machine vision' and extorted a billion dollars.

        The system stinks and filling open source patents won't fix it. Unless someone wants to lay out $2,000,000 trying to enforce the patent it is worthless and pointless.

        People have ruyn one O/S under another for years, IBM are currently selling their ability to run multiple Linux VMs under their MVS O/S - which had the idea so long ago that the patents have expired years ago.

        I have only ever seen one patent that I could not work out a way to bust - Diffie-Helleman and that is long expired now. If the Open Source community start to use patents to try to force people to do everything their way I think they will have stopped being the solution and become the new problem. Its the type of mind control, silly-ass games that turn people off. I don't think the patents filled by the Open Source Community are likely to inconvenience me, just another patent to bust. The Open Source Community would probably have more problems if I started filling broad patents on my own work rather than putting everything into the public domain which I have done to date.

        You can't take the low road to the moral high ground.

  • 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?
    • The GPL does NOT infect ANYTHING, EVER. Not even in any symbolic sense.

      The GPL simply says that you can only use my GPL'ed code in your program if your code is also GPL'ed. You are completely free to not use my code. Yet so many people like you seem to feel that you should have the right to use my code under terms I never agreed to.

      If I offer you a free ice cream cone... you would do well to not later accuse me of ruining your diet. Your diet is your problem. I didn't shove the ice cream cone down your throat.

      And GPL'ed code doesn't infect other code.

    • The software author can choose NOT to use some GPL software just as much as they can choose NOT to use some GPL-like patent. I really don't see an issue with those kinds of patent terms.

      What is an issue here is whether a broad and abstract concept like this is valid for a patent at all. We know the USPTO doesn't even try to evaluate things like this. There's a lot of prior art here, although that prior art may not cover every way of doing things so there is room for some non-prior art stuff. Still, the abstractness of this is a big concern I have. The GPL-like terms are not. As long as people have a choice to use or not use something GPL'd (which may not be the case here) then GPL is OK.

    • Okay patents coupled with the GPL is a new paradigmn, if I understand right.

      Now whoever managed to get something patent can do with the patent whatever he wants, and if the guys is a stranger he can still do with the technology what he wants. If he decides the world may completly not use it for 20 years then it is so. If he decides only programmers with blond hair, born in November and having a green car from Mercedes may use his patent for free this is also so. If he decided people may only use it freely with the GPL than it's also so, it doesn't affect the public position of the GPL at all. As it wouldn't really change to public value of green mercedes or blond programmers born in November.

      I don't see a new 'virus' in there, if somebody wants to use a patent without the GPL he'll 'just' have to buy it from the patent holder, just the same way like if he would spread it properitary only. Hoping he's not a strange kind of guy :o)

      Well that above applies general to patents, Honestly I didn't read the patent paper to see if it holds any real new ideas, but from what I've seen from the far it seems to be a pretty obvious idea, something I've heared of years ago. (Running Linux as subtask in an RTOS) However from the far is too far to really judge :o)
    • You obviously did not read/understand the article. This is a hybrid-license. It combines the GPL and Commercial approaches to software licensing. Basically it rewards people who don't charge for their software by not charging them in return. And on the other side it charges people a fee to use it's technology when they in turn charge other people to use it. I see this as absolutely fair and really the best of both worlds. The commercial end is NOT forced to place their software under the GPL they can license it just like any other piece of commercial code. The only technical flaw I can perceive in this hybrid approach is that the originator of the software is able to reap increasing returns on the value of the software licensed to commercial users as the GPL user community improves the software.
      • What if I decide to do the same thing, just with the BSD-kernel? Will I suddenly become target for a patent license threat, just because this guy hates the BSD-license? How about all the other gazillion variations of licenses, or if I create my own?

        Why should he be granted a government controlled and enforced monopoly on such a trivial idea? As you had the brilliance of seeing, having people working for him for free. Why should I join the project or even bother porting it?

        I don't believe any means is necessary towards an end, and this is another example of that. Justifying something because it benefits you and your ideals, is a display of ego, narrow-mindedness and lack of understanding and compassion for others. Everyone has many good reasons (and bad ones) to do what they do, even in the corporate world. I know I didn't explain this well, but I hope you got the point.

        Btw, how can the GPL and a patent be legally combined? It can not, because the GPL states that further restrictions may not be imposed on the software (not the excact words). Especially not on use. Patents are such a restriction, so this is neither morally nor legally defendable IMHO.

        I really wonder why people think this is great, just because it seems to "benefit" free software. I can assure you, it does not. This can further alienate people in the corporate world from the GPL license. But you were going to use force and violence all along weren't you? (talking to those supporting this idea, not the parent poster who was rather sensible)

        There is no good side, the only good side is neutral.

        - Steeltoe

  • Y'all misunderstand (Score:3, Insightful)

    by alhaz ( 11039 ) on Monday August 06, 2001 @04:08PM (#2164035) Homepage
    And it would help if you actually read the documents for which links are provided.

    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 /different/ hard-real-time linux technology, RTAI.

    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.

  • nothing good will come of this (Score:3, Interesting)

    by janpod66 ( 323734 ) on Monday August 06, 2001 @05:06PM (#2164420)
    I believe the patent is an example of the kinds of bad patents granted these days: technology that was already obvious to people decades ago and even used in some commercial systems, but not patented at the time because the patent system doesn't allow it and not written up at the time because it was too trivial.

    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.

  • I'm surprised that Lineo paid to license this patent. There's prior art -- for example, Intel's real-time kernel that ran beneath Windows 3.1. They were showing this off in the late 80's-early 90's, as I recall, at the Embedded Systems Conference.
  • If Open Source developers start getting bogus software patents in the name of anti-commercialism, it's just going to start a big pissing contest as proprietary software companies will follow suit and try to grab up as many software patents as they can now before the next guy gets them. What we need is to put an end to patents altogether. They had their time, but are now only a roadblock to innovation in the modern age of computers, biotechnology, and instant dissemination of ideas. The world is a small place, while ideas are in infinite supply. Why are we still fighting?
    • It is not fighting. It is building good fences to maintain good neighbors.

      The patent system is supposed to aid investment and foster non-centralization of ideas.

      Who would put money into research in an environment in which the patented subject, once published, is not protected from use without subsidizing the original research?

      Patents encourage business diversity and de-centralization. In an patent-free society the organization that would survive is the biggest one (BigCorp) because they can execute the latest ideas most cheaply, undercutting any of those snot-nose startups who dare thinks they have an original idea.

      As with anything in this world, patents are a two edged sword. The imbalance in this case is the patenting process versus the legal system. It is more advantageous in a day and age of litigation to stock up with eventually baseless patents as weapons and shields in corporate warfare.

      The problem is not with patents. It is with the love of money overriding good moral judgement.

      • What is wrong with doing research on a contract basis rather than with patent licenses to repay the investment?

        Additionally, software patents are *always* bad because writing software is something that anyone can participate in. (zero cost of entry) Furthermore anything resembling an algorithm is only a piece of mathematical knowledge and should not be patentable.

        You suggest that a patent-free society would hurt startups. I would argue that startups can still copyright a specific implementation, market their products better, conduct business more efficiently than their big competitors, etc. If their competitors play dirty games, then you have a case for anti-trust.

        I think the problem IS with patents because the love of money WILL override moral judgment. You can't change human nature. Maybe we should have patents, but if it was up to me, about 90% of them would be thrown out as trivial.

Slashdot Top Deals

What the gods would destroy they first submit to an IEEE standards committee.

Close