I've been involved in fighting this patent for the last 2 years. During this time, I have met and talked with many people about this issue. Today, I can assure you that the rtlinux patent is definitely a show-stopper for Linux.

As it stands now, Linux will never be a viable embedded OS until someone gets rid of the rtlinux patent. As a matter of fact, many people in the industry decide to go with WinCE precisely because of the rtlinux patent.

Many in the real-time Linux community are very worried by the fact that the kernel developers do indeed see real-time as a niche market because the members of the real-time Linux community see the damage being done to Linux's penetration in the embedded field because of the patent.

As the latest VDC report indicates (http://www.linuxdevices.com/articles/AT6328992055.html), the no. 1 factor inhibiting Linux's adoption as an embedded OS is indeed real-time.

It is no wonder that the established embedded vendors (WindRiver, QNX, etc.) feel no threat from Linux. They know that every time Linux will be evaluated, it will be put aside because of the patent.

Given that the embedded field is poised to overtake the desktop and the server in terms of number of devices deployed, it would seem to me that this is much more than just a niche market.

Until the rtlinux patent is dismissed, Linux will remain on the fringes of the real-time and embedded application field. Unfortunately.

That patent is expressly licensed for GPL'd kernels, ie Linux.

It might be an issue with some other OS, but not Linux.

See "http://www.fsmlabs.com/about/patent/openpatentlicense.htm".

I've heard a lot of discussions about ho this kind of "license to Open Source software" kinds of patents have long been discussed as ways to subvert the patent system the same way that the copyleft itself subverts the copyrights.

Even the FSF supports this particular patent (they used to have some issues about the patent license being revocable, but now you have the patent license "as long as the licensee compiles with this license and the terms of the GPL".

[ Actually, the FSF is slightly unhappy about the fact that that patent license expressly picks out GPL v2, the same way the _kernel_ explicitly mentions that only v2 of the GPL is the default. Victor, like me, does not trust the FSF to remain faithful to its original licenses. ]

In short, it you start playing fast and lose with the GPL, you lose the patent rights too. Too bad. But if you stay true, that license is yours, for free. Exactly like the GPL requires.

I understand what you are saying, but I think that there is a large part of the history of the rtlinux patent that has not been properly communicated to the kernel developers. I will try my best to explain this in the following, but feel free to ask questions if things need clarifications. There is only so much I can put in one mail.

When the patent was first noticed by Jerry Epplin in early 2000, he posted a question about it on the rtlinux mailing list. Here is Victor's reply at the time: http://lwn.net/2000/0210/a/vy-patent.html The message clearly says: "The main purpose of the patent was defensive ..."

So the real-time Linux community waited for what was to follow.

Next came the first version of the patent license. That version violated the GPL itself, requiring you to register all the users of the software with FSMLabs. Plus, it had the following "APPROVED USE" section:

In addition to the other terms and conditions of this License, use of the
Patented Process is permitted, without fee or royalty, when used:

A.      By software licensed under the GPL; or

B.      By software that executes within an Open RTLinux Execution
        Environment - whether that software is licensed under the GPL or not.

Basically, Victor was saying that anyone wanting to write a real-time application must either license it under GPL or use FSMLabs' Open RTLinux Execution Environment, a version of RTLinux distributed by FSMLabs.

Many in the real-time Linux community were, evidently, displeased with this turn of events and tried to obtain clarifications from Victor. To this day, however, the real-time Linux community is still waiting for the answers to very basic questions such as: "Does anyone developping a non-GPL application for RTAI (the other real-time Linux extension) have to pay licensing fees to FSMLabs?"

This matter remained unchanged until the FSF came out later and declared publicly that the patent was violating the GPL. At that time, Eben Moglen came out and publicly explained the implications of the patent and the "corrected" patent license. Here is Eben's explanation: http://www.aero.polimi.it/~rtai/documentation/articles/moglen.html

Basically, this calmed things down and the RTAI development team, including myself, tried to comply with Eben's recommendations.

All would have been fine if things had ended there, but Victor then came out and threw more uncertainty about the matter: http://linuxdevices.com/articles/AT6164867514.html

Just when Eben Moglen was saying that real-time applications were not subject to the patent, Victor Yodaiken came out and said: "If you want to make, use, sell, distribute, import, etc. non-GPL software -- regardless of whether such software is labeled as an "application," "module," or anything else -- please make sure you have obtained competent legal advice regarding whether your software and its use is an approved use under the Open RTLinux Patent License or whether a license under the RTLinux patent must be secured to authorize your software and its use."

This was certainly not helpful. When I asked Victor why he did this, he said "I can't offer legal advice. My understanding is that these things can be quite complex."

I could have understood that this was indeed genuine, but here we have Eben Moglen, a respected lawyer, publicly clarfying a situation and instead of backing his position or keeping simply silent, Victor comes out and casts a doubt on the very clarifications made by Eben.

The story goes on and the real-time Linux community is still in limbo. At this stage, my understanding is that the FSF is very upset with Victor's latest comments. But the FSF's point of view or its dealings with Victor's patent are only a partial picture of this story.

In reality, the patent is but the tip of the iceberg.

To get the real picture, you must understand what has happened to the various real-time projects in existence: RTAI and RTLinux. Today, RTAI has clearly taken the lead as the primary real-time addition to Linux. But it only got there because all the developers who work on it today were, at one point or another, very interested in making contributions to RTLinux. In every instance, they were turned down or dismissed by Victor. And in most instances, those who were turned down went to work on RTAI.

And there is a very logical reason for this. FSMLabs dual-licenses RTLinux in closed-source form to many of its clients. This involves that it be the owner of all the code within RTLinux. And indeed, if you take a look at the core files making up RTLinux, they all belong to FSMLabs and FSMLabs alone. There is nothing wrong with this per se. But it does affect the development policy of RTLinux since no outside contributions are ever included in RTLinux's codebase.

At most, there is "contributors" file with some names, but no copyrights in the files. Which begs for a very fundamental question: Has no one ever made a contribution to RTLinux? If someone has, then why are there no names in those file headers except FSMLabs'?

At this point in time, all the bleeding-edge development being done in RTLinux is not available in GPL and must be purchased for a fee.

This isn't really a problem, since RTAI has now surpassed RTLinux in terms of capabilities, ports and support. The problem, however, is that the rtlinux patent is being used to wage an FUD campaign against RTAI.

Hence, someone who currently wants to do real-time in Linux digs a little and finds RTLinux and RTAI. He then tries to get the latest and greatest in RTLinux and realizes that the GPL RTLinux is actually a bait-and-switch. So he takes a closer look at RTAI, but as soon as he does this he sees all these warnings given out by Victor about RTAI and decides to drop Linux altogether and use another OS.

This isn't an imaginary scenario. This has happened time and again with many very big name users. I can provide you with email addresses of people you ask about this.

To sum up, anyone today wanting to do real-time development with Linux faces a barrage of uncertainty. Even if he uses the now GPL RTAI, he doesn't know whether he needs to purchase licenses for his non-GPL applications.

Notice that the argument that the rt tasks running on RTAI must also be GPL because RTAI is GPL doesn't hold because RTAI allows normal Linux processes to become full hard-real-time tasks. This is done through a single call to the RTAI layer rt_make_hard_real_time(). When this function is called, RTAI steals the task from the Linux scheduler and schedules it himself. Hence, the entire task is in user-space.

And as the copyright notice in the kernel sources says, user applications are not subject to the GPL. You added this yourself because you felt that application developers should not be subject to the GPL. The real-time Linux community only expects the same. We don't want a non-GPL real-time executive or a non-GPL OS. All we want is the right to develop applications using our licenses as others are for Linux. We have tried to obtain this through discussion and through enforcement of the GPL. Every time, we faced FUD and unanswered questions. The only venue left today is a total dismissal of the patent.

One last thing: Clearly, if non-GPL applications were not allowed with Linux, we wouldn't be talking today. The same holds for non-GPL RT apps.

I hope this has provided some insight regarding the current situation. As I said before, feel free to ask for more clarifications if need be.

Ehh. That's just because of fud. Your (2) is _not_ the choice.

Does the RT part have to be GPL? Yes. Big whoopte-do. So does kernel modules in general, if they are clearly derived works of Linux (which, in something like this, is pretty obviously the case).

So you split your problem into the RT device driver and the user. And of story. Stop this stupid FUD.

The thing that disgusts me is that this "patent" thing is used as a complete red herring, and the real issue is that some people don't like the fact that the kernel is under the GPL. Tough cookies.

Stop making excuses. I'm personally really happy with having another reason why people should make all their kernel modules GPL'd. I see way too many problems with things like the nVidia kernel modules etc, and I realize that the GPL scares away some people, and I don't care.

Some people (you and Karim) seem to think that the GPL requirement si going to hurt Linux in the embedded space. Fair enough. That's what all the BSD people claimed was the case about Linux in server space, Linux on the desktop, or Linux anywhere.

Personally, I'll just bet on open source myself. Even in the embedded space. And anybody who bets against me, I just don't care about, because it has zero impact on me.

Patents are bad, but I think peoples "charge the red flag" reactions to them are also bad.

I think it was Alan who just suggested to Andrea that he'd ask for an explicit piece of paper _saying_ it was ok, instead of paniccing.

I don't much like patents, but we're forced to live with them. I suspect the best thing we can do is to use them as well as we can. Which is why I don't personally think it's a problem that RedHat, FSMlabs etc get patents.

Can those patents result in trouble? Sure as hell. But let's put it this way: I'm a _lot_ happier about a RedHat/FSMlabs patent that gets licensed to GPL users than I am about a patent by somebody who would want to screw with the GPL.

As I understand the errata involved yes you can. If so please make sure the PII specific kernel panics on a ppro because subtle locking failure is not a pleasant result when someone runs the wrong kernel.

PII specific also means you can assume MMX is present which may be useful in future page copying accelerations

With the recent flurry of inclusions, the trivial@rustcorp.com.au Trivial Patch Monkey has passed 100 patches which have filtered into the various kernels: 5 into 2.2, 55 into 2.4 and 71 into 2.5. Linus and Marcelo now seem well trained to take the patches (although the bogus attribution is a problem).

With this surprising success (I thought the damn thing would die after a few days), I will be continuing to provide the service, which only takes me about an hour a week.

Usage notes:

1. Please provide one patch per email, even if it means 50 emails.
2. Make sure your diffs are -p1 compliant, ie: +++ linux/drivers/net/foo.c
3. MIME is fine.
4. CC'ing trivial is fine: I usually only forward the patch if a kernel has been released since.
5. I actually read the patches, so don't expect real-time response.

FYI, most patches are: (1) janitorial fixes from new people who can't get Linus or linux-kernel to read their patches (aka. Alan Cox Mode), and (2) one-liners from experienced kernel hackers who wouldn't bother retransmitting themselves (aka. Drop Prevention Mode).

Cool! As one who watched the whole fla^H^H^Hdiscussion about a 'patch penguin' with great interest, I'm very happy to hear of the success of your trivial patch monkey. :)

I've not used it yet, but I'll remember it when I have one-liners. :)

Well, thanks. Maybe you have an example of what you mean above? If I take other people's work, I credit them, and I don't think I did so far at all, but definitely not "a lot".

I will surely pick pieces, though - this is what this process is all about.

Anyway, since you don't understand anything about the internals of the kbuild process at all (neither kbuild-2.4 nor 2.5), as you now proved publically multiple times, but are just aiming at proving your abilities in making politics on l-k, don't expect me to answer any further mails on this (and save yourself the effort to reply to this one, but I know you won't).

Linus sees Kai as being the most promising fellow to integrate kbuild2.5 right now (see http://marc.theaimsgroup.com/?l=linux-kernel&m=102307114005894&w=2) and Kai is willing to take it on in just the way Linus wants. It's probably worth giving Kai and Linus the benefit of the doubt for a while, even if it does mean having to rejigger the kbuild-2.5 patch each time Linux accepts one of Kai's patches.

I personally am anxious to see kbuild-2.5 make it into the kernel, but I also feel it can only benefit from a strong review of the sort that comes about during gradual evolution of the kernel build process towards the techniques used by kbuild-2.5.

Thanks to everyone, Keith, Daniel, Thunder, and Kai, who are working (together or not!) on moving the kernel build process into the modern era.

Side note, just to explain _why_ I prefer it done this way, so that people can understand - even if they don't necessarily have to agree with - why this is my preferred approach.

There's actually several reasons:

• I always hate "flag day" patches. Do they happen? Sure. Some people have already given examples of such big flag-day patches, the ALSA merge being one prime example. That doesn't mean that I like them any more for that.

  In short: if at all possible, I _much_ prefer gradual merges, where "gradual" really means that features are added one-by-one (and that does _not_ mean "build up the infrastructure slowly, so that the final 'flag-day' patch itself is small but has large ramifications")

• Kai has already shown that he can merge with me easily, and actually took one traditional flag-day-project (ISDN: every single merge was a flag-day merge), and has turned that into a very easy gradual merge for me. I used to dread ISDN merges, these days I don't even have to think about them.
• Kai obviously already knows the build system, as he has been doing a lot of incremental stuff on it already.
• Kai isn't an enthusiastic kbuild-2.5 supporter. In fact, he tends to be a bit down on some of it. Which is a plus in my book: it means that whatever Kai tries to push my way I'll feel just that much more comfortable with as having had critical review.

So let's see how it works out. Maybe it won't, but this would seem workable at least in theory.