patent on O_ATOMICLOOKUP [Re: [PATCH] loopable tmpfs (2.4.17)]

84 views
Skip to first unread message

Karim Yaghmour

unread,
May 24, 2002, 7:05:13 PM5/24/02
to

Thanks for taking the time to look at this Linus. 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.

Best regards,

Karim

===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Andreas Dilger

unread,
May 24, 2002, 7:09:37 PM5/24/02
to
On May 24, 2002 23:37 +0100, Alan Cox wrote:
> > What, so there are _no_ patents or other restrictions on any of then
> > commercial embedded OS vendor products?
>
> Thousands of them. Some of them like the Siemens power management patent
> really hurt Linux too.

Yes, that was my (weak) attempt at sarcasm.

> > PPS- I also think "defensive patents" on Linux are also a bad idea,
> > because (a) the Linux source code is surely "published" and any
> > ideas therein already constitute prior art for the sake of
> > defending a patent infringement suit, and (b) since patents can
> > be bought and sold any "defensive patents" might fall into the
> > wrong hands if the patent holder goes bankrupt and the assets are
> > sold off to the highest bidder - bad news for the entire Linux
> > community.
>
> Those defensive patents also provide scope for trading stuff with other
> companies, and finally never forget that if you own patents and say its
> a stupid idea you carry a *lot* more weight.

Well, the problem I try to highlight here is as follows (for example):
a)
- FSMlabs goes out of business
- they owe money to creditors
- creditors see patent as an asset to be sold to recoup some money
- nasty company buys patent rights
b)
- nasty company has lots of money, buys FSMlabs outright
- nasty company does not license patent for free to GPL software users

Now, like I said, IANAL, but it may be that the _license_agreement_
which allows one to use the patent is between FSMlabs and GPL software
users. If the patent is transferred to the nasty company, wouldn't that
make the original license agreement = (void *)NULL? The nasty company
may be under no obligation to have favourable (=free) license terms for
the patent.

If I tell someone "you can sleep in my basement for free" and then I
sell my house, I doubt the new house owners are under any obligation
to let that person stay in their basement for free, or at all.

Cheers, Andreas
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/

Linus Torvalds

unread,
May 24, 2002, 7:27:24 PM5/24/02
to

On Fri, 24 May 2002, Karim Yaghmour wrote:
>
> This matter remained unchanged until the FSF came out later and
> declared publicly that the patent was violating the GPL.

Side note: they did this, apparently while Caldera was in the process of
suing FSMlabs over the fact that they didn't want to pay for their
OpenUnix usage... Hmm..

> I could have understood that this was indeed genuine, but here we
> have Eben Moglen, a respected lawyer,

I would be a _lot_ happier with Moglen if he didn't have so many ties to
the FSF, and being biased. These days you can apparently buy a "gpl
compliance certification" from the FSF for $20k. Those kinds of ties do
_not_ make me any happier about the FSF's status as an independent entity.

The RT part of an app under RTLinux has to be a kernel module anyway, and
as I personally consider the GPL to be the only kind of module I care
about, I think that is good.

Whatever non-RT tools used to visualize the RT data equally clearly aren't
covered by _that_ particular patent, so I think the whole thing is a
complete and utter red herring.

Linus

Larry McVoy

unread,
May 24, 2002, 7:22:28 PM5/24/02
to
On Fri, May 24, 2002 at 07:05:13PM -0400, Karim Yaghmour wrote:
> 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

Eben Moglen is the lawyer for the FSF, right? So he's hardly objective
about this topic, right? Isn't his point to try and get everything to
be GPLed?

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

So? Eben is not objective on the topic, FSMlabs holds the patents, if you
listen to what Eben says, that's meaningless. He is not a judge, he is not
objective, he's got a particular ax to grind. That's fine, except for one
thing: he doesn't hold the patent. So if you are going to listen to anyone,
I'd be listening to 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.

Doesn't the RTAI
a) make use of the patent and
b) allow for parts that aren't GPLed?

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

Ahh, I get it. I think I see the problem. You are applying GPL rules
to the RTLinux patent. You're saying that the boundary where the patent
applies stops at the same place as the boundary where the GPL stops.
I'll bet that is the cause of all the confusion. The patent and the
GPL have no correlation. It's completely up to FSMlabs to define what
is an application and what is not. And it's a very reasonable thing
for them to consider everything which runs on top of the RTLinux substrate
to be required to be covered by the GPL. That's certainly within their
rights. You can't take the GPL rules and impose that on his patent
license, the two have nothing to do with each other. He who holds
the patent makes the rules.

I think the bottom line is that the RT idea that Victor came up with is
pretty cool, it is obviously something that you want, and so you get to
live with those rules. Listening to a lawyer's opinion, when that
lawyer works for the FSF and is charged with furthering the cause of
the FSF, that's just asking for trouble. He isn't going to give you
an unbiased view. I think Victor's suggestion is good - if you want to
know what the rules are, consult your own lawyer.

As someone who's been down this path pretty extensively, I do not think
that you are seeing it clearly, you are mixing the patent and the GPL
and you are not entitled to do that. FSMlabs has to play by the GPL
rules for any modifications they make to the kernel, but you have to
play by their rules if you use their patent. You can't apply the GPL
rules and expect those to override the patent rules, it doesn't work
like that.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

Alexander Viro

unread,
May 24, 2002, 7:53:17 PM5/24/02
to

On Fri, 24 May 2002, Larry McVoy wrote:

> I think the bottom line is that the RT idea that Victor came up with is
> pretty cool, it is obviously something that you want, and so you get to
> live with those rules.

... which stinks (note: "stinks" != "illegal"). I'm quite comfortable
with "my code - my rules"; basically, it's "thou shalt not plagiarize".
"my ideas - my rules", though... Let's just say that we had been there
and while 16c Italy definitely had its charm, Cardano/Tartaglia wankfest
was not part of it.

Karim Yaghmour

unread,
May 24, 2002, 11:13:27 PM5/24/02
to

Linus Torvalds wrote:

> On Fri, 24 May 2002, Karim Yaghmour wrote:
> >
> > This matter remained unchanged until the FSF came out later and
> > declared publicly that the patent was violating the GPL.
>
> Side note: they did this, apparently while Caldera was in the process of
> suing FSMlabs over the fact that they didn't want to pay for their
> OpenUnix usage... Hmm..

Speaking of suing, did you know that FSMLabs filed suit against Lineo
in the federal court of Delaware last June. Lineo's licensing of FSMLabs
"technology" only came after that.

> > I could have understood that this was indeed genuine, but here we
> > have Eben Moglen, a respected lawyer,
>
> I would be a _lot_ happier with Moglen if he didn't have so many ties to
> the FSF, and being biased. These days you can apparently buy a "gpl
> compliance certification" from the FSF for $20k. Those kinds of ties do
> _not_ make me any happier about the FSF's status as an independent entity.

Aside from your personal opinion about the FSF and Moglen, I find it
unfortunate that you don't take the time to investigate this a little
bit further on your own before dismissing it altogether.

> The RT part of an app under RTLinux has to be a kernel module anyway,

This is incorrect, see below.

> and as I personally consider the GPL to be the only kind of module I care
> about, I think that is good.

First:
There's another real-time extension for Linux called RTAI that is unrelated
to RTLinux.

Second:
I said in my previous email that RTAI provides a facility to enable user-space
processes to become hard-real-time tasks using a single system call. There
are no modules involved in this. You start the RT process exactly as you
would start another process on the command line and it enters hard-real-time
mode using the call I mentionned earlier.

Here's an example:

int main(int argc, char *argv[])
{

...
mlockall(MCL_CURRENT | MCL_FUTURE);

if (!(hrttsk = rt_task_init(hrttsk_name, 1, 0, 0))) {
printf("CANNOT INIT MASTER TASK\n");
exit(3);
}

if (oneshot) rt_set_oneshot_mode();
else rt_set_periodic_mode();
period = (int) nano2count((RTIME)periodns);
start_rt_timer(period);

if (uspsh) rt_usp_signal_handler(handler);

if (softhard) {
rt_make_hard_real_time();
}

rt_task_make_periodic(hrttsk, rt_get_time() + period, period);

...
}

Starting from the call to rt_mak_hard_real_time() this Linux _process_
has now become a hard-real-time task scheduled by RTAI.

Mind you, all of this is in __USER-SPACE__. There are no modules involved.

Yet, even though this is entirely done in user-space, this isn't allowed
by the patent.

> Whatever non-RT tools used to visualize the RT data equally clearly aren't
> covered by _that_ particular patent, so I think the whole thing is a
> complete and utter red herring.

I'm sorry, but I'm missing the point here about visualization tools.
Such tools are not part of any of the real-time Linux community's
concerns.

That said, if you feel better seing this as a red herring, then feel
free to do so. Real-time developers who actually have to choose a real
OS for their application, however, are seing Linux as the red herring.
And as long as you continue to ignore this problem, they will continue
to choose other OSes over Linux.

I don't like to be saying any of this, but this is exactly what is
happening every day in the field.

Karim

===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================

Linus Torvalds

unread,
May 24, 2002, 11:25:38 PM5/24/02
to

On Fri, 24 May 2002, Karim Yaghmour wrote:
>
> > The RT part of an app under RTLinux has to be a kernel module anyway,
>
> This is incorrect, see below.

This is _correct_.

The fact that under RTAI it isn't the case does not change the fact that
under RTLinux it _is_.

> I'm sorry, but I'm missing the point here about visualization tools.
> Such tools are not part of any of the real-time Linux community's
> concerns.

With RTLinux, you have to split the app up into the "hard realtime" part
(which ends up being in kernel space) and the "rest".

Which is, in my opinion, the only sane way to handle hard realtime. No
confusion about priority inversions, no crap. Clear borders between what
is "has to happen _now_" and "this can do with the regular soft realtime".

Your claim was that RTLinux made realtime hard to do with licensing
concerns. MY claim is that if you actually were to use RTLinux, you
wouldn't _have_ any licensing concerns: the kernel module would have to be
GPL (both because the kernel wants it that way _and_ because you get the
liences to the patent that way), and the user-level code that uses
whatever data the RT module produces is no longer hard realtime at all.

Clean separation, both from a license standpoint _and_ from a purely
technical standpoint.

Linus

Karim Yaghmour

unread,
May 24, 2002, 11:46:25 PM5/24/02
to

Linus Torvalds wrote:
> On Fri, 24 May 2002, Karim Yaghmour wrote:
> > This is incorrect, see below.
>
> This is _correct_.
>
> The fact that under RTAI it isn't the case does not change the fact that
> under RTLinux it _is_.

Fine, but aren't you the least bit interested in seing how it is done in
the other real-time Linux implementation?

> > I'm sorry, but I'm missing the point here about visualization tools.
> > Such tools are not part of any of the real-time Linux community's
> > concerns.
>
> With RTLinux, you have to split the app up into the "hard realtime" part
> (which ends up being in kernel space) and the "rest".
>
> Which is, in my opinion, the only sane way to handle hard realtime. No
> confusion about priority inversions, no crap. Clear borders between what
> is "has to happen _now_" and "this can do with the regular soft realtime".

There are no priority inversions in the case of RTAI hard-real-time processes
either. They get scheduled exactly as other real-time processes and they
can have priority even over real-time tasks within modules.

Moreover, I would like to point out that many real-time developers like
to have memory protection for their tasks. Hard-real-time in the kernel
with RTLinux isn't possible. Hard-real-time in user-space with RTAI
is.

There is no reason that what happens _now_ shouldn't have memory protection
and what happens later should.

> Your claim was that RTLinux made realtime hard to do with licensing
> concerns. MY claim is that if you actually were to use RTLinux, you
> wouldn't _have_ any licensing concerns: the kernel module would have to be
> GPL (both because the kernel wants it that way _and_ because you get the
> liences to the patent that way), and the user-level code that uses
> whatever data the RT module produces is no longer hard realtime at all.

Sure. I'm not contesting the merits of using GPL modules. True, this
is the best way to go. However, not everyone has this option and my
claim is that this is one of the facts that is putting Linux out in the
cold in front of the competition in regards to rt.

That said, I wouldn't be using RTLinux, I'd be using RTAI to implement
both the collection and visualization tasks in user-space. The separation
between what's hard-rt and what's soft-rt could then be done either on
a process basis or even separate C files within the same program.

Again, why should hard-rt tasks not use memory protection when they can?

> Clean separation, both from a license standpoint _and_ from a purely
> technical standpoint.

Again, from a purely technical standpoint, there are many advantages in
having the hard-rt tasks in user-space. As for the licensing standpoint,
the issues "should" also be very clear: since the hard-rt tasks are in
user-space, then they are covered by the GPL-exclusion put in place in
the Linux kernel.

I say "should" because nothing is clear in the current situation and
this is pivotal in developers' decision to use or not to use Linux.

Karim

===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================

Linus Torvalds

unread,
May 25, 2002, 12:27:08 AM5/25/02
to

On Fri, 24 May 2002, Linus Torvalds wrote:
>
> You know what? I don't care. If the RTAI people are trying to make it easy
> for non-GPL module people, I have absolutely zero interest.

[ Clarification: here "module" is not just "the thing you insert with
insmod". In RTAI it's a mlock'ed user-level thing that has higher
priority than the kernel, and can thus trivially crash the system.
Whether it runs in CPL0 or CPL3 is immaterial at that point - a crash is
a crash, and I'm not interested in systems where I cannot debug the
thing that caused it ]

Linus

Larry McVoy

unread,
May 25, 2002, 12:25:33 AM5/25/02
to
On Fri, May 24, 2002 at 09:08:27PM -0700, Linus Torvalds wrote:
> It all tends to boil down to a device driver in the end, and the amount of
> support you're willing to give it. Soft realtime can handle the rest.
>
> Personally, I'm _not_ interested in making device drivers look like
> user-level. They aren't, they shouldn't be, and microkernels are just
> stupid.

Amen to that.

--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

Karim Yaghmour

unread,
May 25, 2002, 12:31:22 AM5/25/02
to

Larry McVoy wrote:
> Eben Moglen is the lawyer for the FSF, right? So he's hardly objective
> about this topic, right? Isn't his point to try and get everything to
> be GPLed?

As I said, the FSF and Eben's public message are not the entire story,
but only part of it.

> So? Eben is not objective on the topic, FSMlabs holds the patents, if you
> listen to what Eben says, that's meaningless. He is not a judge, he is not
> objective, he's got a particular ax to grind. That's fine, except for one
> thing: he doesn't hold the patent. So if you are going to listen to anyone,
> I'd be listening to FSMlabs.

Exactly, so would I. Except that they haven't been very verbose. All we
ever got from them was "speak to your lawyer". Sure that's fair enough,
but my entire point is: This uncertainty and lack of clarity is hurting
Linux very badly.

> > 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.
>
> Ahh, I get it. I think I see the problem. You are applying GPL rules
> to the RTLinux patent. You're saying that the boundary where the patent
> applies stops at the same place as the boundary where the GPL stops.

Not really. I'm saying that Linux is in deep-shit (sorry for the wording)
because of this patent and until someone gets rid of it, other OSes will
be chosen instead of it.

It matters little whether I look at this from the copyright perspective
or from the patent perspective. What I'm trying to highlight is that the
current real-time Linux patent/copyright situation is killing Linux in
an entire application field.

It doesn't matter if we agree/disagree with any of the players involved,
whether it be me, Victor, the FSF, Moglen, Linus, or God konws who. What
I'm pointing out is that the current situation is killing Linux in an
entire application field and that it needs to be sorted out.

> I'll bet that is the cause of all the confusion. The patent and the
> GPL have no correlation. It's completely up to FSMlabs to define what
> is an application and what is not. And it's a very reasonable thing
> for them to consider everything which runs on top of the RTLinux substrate
> to be required to be covered by the GPL. That's certainly within their
> rights.

It most certainly is. I have no disagreement with you there.

> You can't take the GPL rules and impose that on his patent
> license, the two have nothing to do with each other. He who holds
> the patent makes the rules.

Again, I agree. I don't question any of this and I perfectly understand
the copyright/patent laws involved.

> I think the bottom line is that the RT idea that Victor came up with is
> pretty cool,

Well, here I disagree. "came up with" is very strong wording. Care to
look at a paper by Stodolsky, Chen, and Bershad entitled "Fast Interrupt
Priority Management in Operating System Kernels" published in 1993 as
part of the Usenix Microkernels and Other Kernel Architectures Symposium.
That is one paper that describes the software emulation of interrupts.

In fact, this paper is so crucial to RTLinux that Barbanov writes the
following about it in his masters thesis:
"It turns out that using software interrupts [23], together with several
other techniques, it is nevertheless possible to modify Linux so as to
overcome these problems. The idea to use software interrupts so that a
general-purpose operating system could coexist with a hard real-time
system is due to Victor Yodaiken (personal communications)."

Curiously, though, this paper is recognized by Barbanov as a pilar of
the RTLinux technique, it is never mentionned in the literature reference
to the patent.

> it is obviously something that you want, and so you get to

> live with those rules. Listening to a lawyer's opinion, when that
> lawyer works for the FSF and is charged with furthering the cause of
> the FSF, that's just asking for trouble. He isn't going to give you
> an unbiased view. I think Victor's suggestion is good - if you want to
> know what the rules are, consult your own lawyer.

I have no problem consulting the lawyer. What I am saying is that
developers who have to fear being sued over their use of an OS
because of loose patents will simply avoid using the OS altogether
and stick with the established OSes who never got anyone in trouble
(or, at least, the majority of people).

> As someone who's been down this path pretty extensively, I do not think
> that you are seeing it clearly, you are mixing the patent and the GPL
> and you are not entitled to do that. FSMlabs has to play by the GPL
> rules for any modifications they make to the kernel, but you have to
> play by their rules if you use their patent. You can't apply the GPL
> rules and expect those to override the patent rules, it doesn't work
> like that.

Thanks for taking the time to explain, but I think the issues go
far beyond copyright and patent applicability. The issues goes to
the heart of developers' perception of a technology. Today, most
developers who take a deep look at using Linux for real-time apps
simply avoid it. We can choose to look at this from whichever
perspective we want. The bottom line is that Linux is just no being
used in those apps. And the one main reason we got to this is the
existence of the patent. As simplistic as it may sound, take the
patent away and the entire problem disappears. No more fuss about
GLP/non-GPL and no more fuss about which abstraction is allowed,
processes, kernels, modules etc.

Cheers,

Karim

===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================

Linus Torvalds

unread,
May 25, 2002, 12:08:27 AM5/25/02
to

On Fri, 24 May 2002, Karim Yaghmour wrote:
>
> There is no reason that what happens _now_ shouldn't have memory protection
> and what happens later should.

Sure there is.

What happens _now_ happens in an interrupt, which means that it had better
be in a kernel module. And yes, you can (and apparently do) add low-level
task switching etc, at the expense of a slower interrupt response time.

Most people don't need that. In fact, most people could probably do
perfectly well with just soft realtime, and to a lot of those people "hard
realtime" is just a marketing term.

It all tends to boil down to a device driver in the end, and the amount of
support you're willing to give it. Soft realtime can handle the rest.

Personally, I'm _not_ interested in making device drivers look like
user-level. They aren't, they shouldn't be, and microkernels are just
stupid.

> Sure. I'm not contesting the merits of using GPL modules. True, this


> is the best way to go. However, not everyone has this option and my
> claim is that this is one of the facts that is putting Linux out in the
> cold in front of the competition in regards to rt.

You know what? I don't care. If the RTAI people are trying to make it easy


for non-GPL module people, I have absolutely zero interest.

In contrast, I _am_ interested if the kernel module is required to be (a)
small, (b) clear (c) GPL. You seem to not care about any of the three
things _I_ care about.

That's ok. The GPL means that you don't have to agree with me.

> Again, from a purely technical standpoint, there are many advantages in
> having the hard-rt tasks in user-space.

That's simply not true.

In user space, you'll never get the kinds of low overheads for the _true_
hard realtime, and to me that just says that what you're talking about is
really mostly just a slightly hardened soft-realtime.

Linus

Karim Yaghmour

unread,
May 25, 2002, 12:48:00 AM5/25/02
to

Karim Yaghmour wrote:
> > I'll bet that is the cause of all the confusion. The patent and the
> > GPL have no correlation. It's completely up to FSMlabs to define what
> > is an application and what is not. And it's a very reasonable thing
> > for them to consider everything which runs on top of the RTLinux substrate
> > to be required to be covered by the GPL. That's certainly within their
> > rights.
>
> It most certainly is. I have no disagreement with you there.

Actually, I forgot something here. The way patent law works is that they
don't have power on anything that doesn't implement their patent. RT
tasks don't implement any part of their patent and _should_, therefore,
not be subject to their patent. You can dislike Eben, but here's what
he had to say about this particular issue:
"Anything which is not part of the patent's claims is not covered by
the patent, and can be done by anyone anywhere anytime, without regard
to the patent."

Since RT tasks haven't been patented, it follows that Victor can't
force you to use GPL tasks instead of non-GPL ones. He can, however,
force you to only distribute GPL RTLinux-like microkernels. That
was the essence of Eben's explanation. And, as I understanding, this
isn't really just an "opinion" but really follows from patent law.
But since Victor, Linus and yourself are dismissing his counsel,
rt developers are back to square 1.

Karim

===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================

Larry McVoy

unread,
May 25, 2002, 12:44:02 AM5/25/02
to
On Sat, May 25, 2002 at 12:31:22AM -0400, Karim Yaghmour wrote:
> Exactly, so would I. Except that they haven't been very verbose. All we
> ever got from them was "speak to your lawyer". Sure that's fair enough,
> but my entire point is: This uncertainty and lack of clarity is hurting
> Linux very badly.

Err, I'm willing to believe that this is all hurting you badly, from what
I can gather, you make your money off of RTAI. That means you have a
beef with FSMlabs because they hold the patent on technology you need
for your revenue stream. That's a problem for you, butI fail to see
who that turns into a problem for Linux.

> Not really. I'm saying that Linux is in deep-shit (sorry for the wording)
> because of this patent and until someone gets rid of it, other OSes will
> be chosen instead of it.

Actually, the RT that FSMlabs does works under BSD as well. So I suspect
that part of the reason people choose other OSes is because of licensing,
not because of any fear of the patent.

> It matters little whether I look at this from the copyright perspective
> or from the patent perspective. What I'm trying to highlight is that the
> current real-time Linux patent/copyright situation is killing Linux in
> an entire application field.

Oh, come on. Yeah, there have been lots of visible failures but my
opinion is that it is exaclty because of a lack of anything like this
patent. You need a business model. If you have no IP then it's
awfully hard to sell what you don't own for more than the next guy.
The free market will drive the price down to the absolute minimum
possible, which will amount to consulting fees for enhancements and
bug fixes and that's it. Life is hard.

> > You can't take the GPL rules and impose that on his patent
> > license, the two have nothing to do with each other. He who holds
> > the patent makes the rules.
>
> Again, I agree. I don't question any of this and I perfectly understand
> the copyright/patent laws involved.

OK, that's great, then deal with the reality as it stands. If you think
the patent is invalid, you are welcome to challenge it in court. If you
aren't going to do that, then I fail to see how raising a stink here is
going to help you. If anything, it's going to make more clear that you
don't own the technology on which you depend for your revenue. Not a
good business position...


--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

Karim Yaghmour

unread,
May 25, 2002, 12:52:44 AM5/25/02
to

Linus Torvalds wrote:
> Most people don't need that. In fact, most people could probably do
> perfectly well with just soft realtime, and to a lot of those people "hard
> realtime" is just a marketing term.

Actually, most people I know think that it's the other way around:
real-time==hard-real-time and soft-real-time==marketing buzzword.

> > Sure. I'm not contesting the merits of using GPL modules. True, this
> > is the best way to go. However, not everyone has this option and my
> > claim is that this is one of the facts that is putting Linux out in the
> > cold in front of the competition in regards to rt.
>
> You know what? I don't care.

Fine by me, it's your kernel.

> If the RTAI people are trying to make it easy
> for non-GPL module people, I have absolutely zero interest.

Ok, so you think that having hard-rt in user-space was all done for evading
the patent?

FYI, this was designed and implemented in late 1999, early 2000. At the time,
all this patent crap hadn't surfaced yet!

So please, before declaring "zero interest" for our work, at least check it
out first.

> In contrast, I _am_ interested if the kernel module is required to be (a)
> small, (b) clear (c) GPL. You seem to not care about any of the three
> things _I_ care about.

I don't see where I said this. I do care about all of those things. Heck,
the entirety of the tools I developped are GPL. I sell 0$ of closed-source
software. >>>0$<<<

In addition to those a,b,c, I actually care about the proliferation of
the Linux kernel into a field which seriously needs it. What I have
witnessed in the field is that Linux is simply not used because of the
reasons I mentionned earlier.

It evades me, why you shouldn't care about Linux's proliferation in that
field and that you so easily dismiss the real-time Linux community's
worries which I am relaying to you.

> > Again, from a purely technical standpoint, there are many advantages in
> > having the hard-rt tasks in user-space.
>
> That's simply not true.
>
> In user space, you'll never get the kinds of low overheads for the _true_
> hard realtime, and to me that just says that what you're talking about is
> really mostly just a slightly hardened soft-realtime.

No. This is true hard-real-time. For God's sake, download RTAI and do
the measurements yourself if you don't want to take my word for it.
These hard-real-time processes are truely hard-hard-hard-realtime!!!

Karim

===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================

Larry McVoy

unread,
May 25, 2002, 1:00:02 AM5/25/02
to
On Sat, May 25, 2002 at 12:48:00AM -0400, Karim Yaghmour wrote:
> "Anything which is not part of the patent's claims is not covered by
> the patent, and can be done by anyone anywhere anytime, without regard
> to the patent."

Sure. As long as it does not depend on the patent to work. I don't care
if Victor says that you have to love your mother in order to license his
patent. If that's what he says, those are the terms. You are *paying*
for the right to use the patent. His terms are that you are 100% GPL
all the way through. OK, so deal with that.

Eben is absolutely right - if you want to do something completely unrelated
to the patent, which does not use any aspect of the patent, you are in the
clear. Unfortunately for you & Eben, that's irrelevant if what you are
doing doesn't work without RT/Linux. If that's true, you're using his patent
and you have to pay his price.

I really don't see the problem anyway. FSMlabs worked long and hard to
produce their work. And took the time and effort to patent it. And they
allow you to use it for free if you are working on 100% free stuff. That's
pretty reasonable. Your only complaint seems to be that you can't make
money off of it without licensing the technology. Why don't you just
license it and be done with it?


--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

Karim Yaghmour

unread,
May 25, 2002, 1:20:30 AM5/25/02
to

Larry McVoy wrote:
> Err, I'm willing to believe that this is all hurting you badly, from what
> I can gather, you make your money off of RTAI. That means you have a
> beef with FSMlabs because they hold the patent on technology you need
> for your revenue stream. That's a problem for you, butI fail to see
> who that turns into a problem for Linux.

Oh wow, people and their arguments now get to be judged on this mailing list
because of their revenue stream???

I'm certainly not going to start discussing how much I make and where
it comes from, but I can assure you that RTAI is currently not part
of my revenue stream and that I'm making a very good living without
it.

> Oh, come on. Yeah, there have been lots of visible failures but my
> opinion is that it is exaclty because of a lack of anything like this
> patent. You need a business model. If you have no IP then it's
> awfully hard to sell what you don't own for more than the next guy.
> The free market will drive the price down to the absolute minimum
> possible, which will amount to consulting fees for enhancements and
> bug fixes and that's it. Life is hard.

Again, I sell 0$ of software.

But all this is total crap Larry and, for what's it's worth, I find
your comments quite insulting.

I like real-time and embedded software and enjoy working on it. The
fact that I'd like to see more of it being done with Linux is really
a desire to be working on the best of everything I like: Linux,
real-time and embedded.

> the patent is invalid, you are welcome to challenge it in court. If you
> aren't going to do that, then I fail to see how raising a stink here is
> going to help you. If anything, it's going to make more clear that you
> don't own the technology on which you depend for your revenue. Not a
> good business position...

Thanks Larry, that's really helpful. Instead of finding actual arguments,
researching the mailing lists, asking potential rt users, doing
some background checks, and trying out the software, all you can find
to say is that you "fail to see how raising a stink here is going to
help" me.

Forget about who I am and forget about what I do and please don't take
my word for anything I wrote. Ask around. Try posting your questions to
the following lists and see what you get or even try the archives:
rtl-ad...@rtlinux.org
rt...@rtai.org

It seems that the LKML prefers to ignore the issue. Fair enough. I
did my part, I conveyed the worries of the rest of real-time Linux
community. My own personnal future is certainly not at stake here,
but Linux's is.

Thanks anyway Larry,

Karim

===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================

Larry McVoy

unread,
May 25, 2002, 1:39:50 AM5/25/02
to
On Sat, May 25, 2002 at 01:20:30AM -0400, Karim Yaghmour wrote:
> Oh wow, people and their arguments now get to be judged on this mailing list
> because of their revenue stream???

Yup, happens all the time.

> Again, I sell 0$ of software.
>

> I like real-time and embedded software and enjoy working on it. The
> fact that I'd like to see more of it being done with Linux is really
> a desire to be working on the best of everything I like: Linux,
> real-time and embedded.

Then you have absolutely no beef with the FSMlabs patent. Let's review:

a) you get to use it if the stuff built on it, all of it, is GPLed.
b) you build on GPLed stuff.

Seems like you either have no problem or you aren't disclosing the whole
story. I really don't understand why there is a problem here. 100%
GPLed is OK, so why do you have a problem?

> Thanks Larry, that's really helpful. Instead of finding actual arguments,
> researching the mailing lists, asking potential rt users, doing
> some background checks

Err, I was on the program committee for Usenix which rejected (over
my heated objections) the RT/Linux paper. Their idiotic comments were
"it doesn't do posix so it sucks". See Linus' comment about drivers,
I share that point of view. Drivers are not for people who want to be
programming in userspace.

My point is that I've been watching this area for a long time, I know
who you are, I know what RTAI is, I know the timelines, and while I'm
sure there are many people who know it all in much more detail than I,
I'm hardly what you'd call ignorant in the area.

> My own personnal future is certainly not at stake here,
> but Linux's is.

Personally, if I were depending on RT/whatever for my business, I'd be
much happier getting it from someone with a business model that makes
sense. It's in my best interest to know that they are going to be there
tomorrow, with enough revenue to develop and support the product. So
in that sense, I couldn't disagree more.

--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

Karim Yaghmour

unread,
May 25, 2002, 2:05:13 AM5/25/02
to

Larry McVoy wrote:
> Seems like you either have no problem or you aren't disclosing the whole
> story. I really don't understand why there is a problem here. 100%
> GPLed is OK, so why do you have a problem?

It seems that you have a very hard time seing why I would be defending
something when I'm not making any $ out of it. RMS isn't making any $
from GPL software. Is he then hiding something?

The problem isn't what I do with it. The problem is Linux's usage in
this application field. Beyond what I do with it, there's Linux's
usage in the embedded field and the freedom that comes with its use.
Linux is simply not being put to use in that field. Our everyday lives
continue to be controlled by devices which no ones knows what runs
in them. Apart from Windows, our entire society is based on software
which we have never seen. Planes, cars, satellites, phones, etc. are
all running some sort of OS which we've never seen (so to speak).
How good is this to any of us?

> > Thanks Larry, that's really helpful. Instead of finding actual arguments,
> > researching the mailing lists, asking potential rt users, doing
> > some background checks
>
> Err, I was on the program committee for Usenix which rejected (over
> my heated objections) the RT/Linux paper. Their idiotic comments were
> "it doesn't do posix so it sucks". See Linus' comment about drivers,
> I share that point of view. Drivers are not for people who want to be
> programming in userspace.
>
> My point is that I've been watching this area for a long time, I know
> who you are, I know what RTAI is, I know the timelines, and while I'm
> sure there are many people who know it all in much more detail than I,
> I'm hardly what you'd call ignorant in the area.

Well, for one thing, I didn't call you an ignorant. I'm glad you are aware
of the facts. I can't say I support/disapprove of Usenix's decision (since
I wasn't there) and I certainly have no objection in FSMLabs making money
out of their work, as I said previously many times on the rt mailing lists.
But when it comes to using a patent to tie Linux's entire future in one
field of application to one vendor and one vendor only, I have a very strong
objection.

> > My own personnal future is certainly not at stake here,
> > but Linux's is.
>
> Personally, if I were depending on RT/whatever for my business, I'd be
> much happier getting it from someone with a business model that makes
> sense. It's in my best interest to know that they are going to be there
> tomorrow, with enough revenue to develop and support the product. So
> in that sense, I couldn't disagree more.

I won't elaborate on this, but I understand why you disagree.

Karim

===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================

Thunder from the hill

unread,
May 25, 2002, 3:59:10 AM5/25/02
to
Hi,

On Fri, 24 May 2002, Larry McVoy wrote:
> Then you have absolutely no beef with the FSMlabs patent. Let's review:
>
> a) you get to use it if the stuff built on it, all of it, is GPLed.
> b) you build on GPLed stuff.
>

> Seems like you either have no problem or you aren't disclosing the whole
> story. I really don't understand why there is a problem here. 100%
> GPLed is OK, so why do you have a problem?

I think the point he's tryin' to make is somewhere else than that. There
are lots of companies running embedded devices (oh yes, I can tell ;-),
and as long as it is a) not clear and/or b) impossible by license to use
real time linux w/their licenses, they won't.

Embedded and real time devices are "The Future" for lots of companies. And
of course they're going to want to sell it. Currently, they have three
ways:

1. They try RTAI and don't have any licensing problems, but they are very
unsure about it, since certain people keep telling that RTAI is crap

2. They get used to RTLinux, where they are altogether forced to use
either GPL or their license. This isn't exactly a way of choice.

3. They go buy another real time os implementation.

Most will decide for 3., since it's the easy and virtually obvious way.
Thus, Linux isn't going to get very far in respect to embedded devices. I
suppose _THAT'S_ the point he was trying to make.

Regards,
Thunder
--
Was it a black who passed along in the sand?
Was it a white who left his footprints?
Was it an african? An indian?
Sand says, 'twas human.

Robert Schwebel

unread,
May 25, 2002, 5:05:42 AM5/25/02
to
On Fri, May 24, 2002 at 04:27:24PM -0700, Linus Torvalds wrote:
> Whatever non-RT tools used to visualize the RT data equally clearly
> aren't covered by _that_ particular patent, so I think the whole thing is
> a complete and utter red herring.

Unfortunately, it is not only visualisation programs we are talking about,
but also fast data processing algorithms, which are bread and butter of the
users of realtime controllers. See my other post for an example.

Robert
--
+--------------------------------------------------------+
| Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de |
| Pengutronix - Linux Solutions for Science and Industry |
| Braunschweiger Str. 79, 31134 Hildesheim, Germany |
| Phone: +49-5121-28619-0 | Fax: +49-5121-28619-4 |
+--------------------------------------------------------+

Robert Schwebel

unread,
May 25, 2002, 5:02:44 AM5/25/02
to
On Fri, May 24, 2002 at 10:00:02PM -0700, Larry McVoy wrote:
> Sure. As long as it does not depend on the patent to work.

Larry, please read what Eben Moglen wrote in the article quoted by Karim.

One can think of the FSF whatever one wants (I personally very much dislike
RMS' fanatism, although I like the general idea behind free software), but
just taking what Eben has written sounds very sane to me.

Robert Schwebel

unread,
May 25, 2002, 5:08:30 AM5/25/02
to
On Fri, May 24, 2002 at 08:25:38PM -0700, Linus Torvalds wrote:
> With RTLinux, you have to split the app up into the "hard realtime" part
> (which ends up being in kernel space) and the "rest".
>
> Which is, in my opinion, the only sane way to handle hard realtime. No
> confusion about priority inversions, no crap. Clear borders between what
> is "has to happen _now_" and "this can do with the regular soft realtime".

... which in turn results in the situation that applications must be
implemented as kernel modules.

> Your claim was that RTLinux made realtime hard to do with licensing
> concerns. MY claim is that if you actually were to use RTLinux, you
> wouldn't _have_ any licensing concerns: the kernel module would have to
> be GPL (both because the kernel wants it that way _and_ because you get
> the liences to the patent that way), and the user-level code that uses
> whatever data the RT module produces is no longer hard realtime at all.

This is only correct for open-loop applications. Most real life apps are
closed-loop.

Karim Yaghmour

unread,
May 25, 2002, 12:20:22 PM5/25/02
to

Larry McVoy wrote:
> 4. Contact FSMlabs, ask about licensing costs, compare to #3 and go with
> #4 if it makes sense.

Many people have said this before and I will say it again: Linux is
fine as an open-source/free-software rtos, but as a non-free rtos it
has no chance in front of the competition.

You can dimiss those who haven't chosen #4 as much as you want and
find all the reasons to justify your dismissal. It remains that the
embedded/rt market is closed to Linux because of the current situation.

Karim

===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================

Larry McVoy

unread,
May 25, 2002, 12:25:57 PM5/25/02
to
On Sat, May 25, 2002 at 12:20:22PM -0400, Karim Yaghmour wrote:
>
> Larry McVoy wrote:
> > 4. Contact FSMlabs, ask about licensing costs, compare to #3 and go with
> > #4 if it makes sense.
>
> Many people have said this before and I will say it again: Linux is
> fine as an open-source/free-software rtos, but as a non-free rtos it
> has no chance in front of the competition.
>
> You can dimiss those who haven't chosen #4 as much as you want and
> find all the reasons to justify your dismissal. It remains that the
> embedded/rt market is closed to Linux because of the current situation.

Hmm, then why did Lineo license the patent? Why is FSMlabs still in
business?

I don't buy your assertions for one second without some strong data to
back them up. Just saying something doesn't make it so, show me the
data.


--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

Larry McVoy

unread,
May 25, 2002, 12:14:44 PM5/25/02
to
On Sat, May 25, 2002 at 01:59:10AM -0600, Thunder from the hill wrote:
> I think the point he's tryin' to make is somewhere else than that. There
> are lots of companies running embedded devices (oh yes, I can tell ;-),
> and as long as it is a) not clear and/or b) impossible by license to use
> real time linux w/their licenses, they won't.
>
> Embedded and real time devices are "The Future" for lots of companies. And
> of course they're going to want to sell it. Currently, they have three
> ways:
>
> 1. They try RTAI and don't have any licensing problems, but they are very
> unsure about it, since certain people keep telling that RTAI is crap
>
> 2. They get used to RTLinux, where they are altogether forced to use
> either GPL or their license. This isn't exactly a way of choice.
>
> 3. They go buy another real time os implementation.

4. Contact FSMlabs, ask about licensing costs, compare to #3 and go with


#4 if it makes sense.

If we were hearing about lots of companies who want to use RT/Linux
and have choosen not to do so because of the licensing, there might be
cause for concern. I'm sure there are companies who have choosen to
skip RT/Linux once they realized it wasn't free, that's too bad, but
not the end of the world. In the long run, it's probably good because
somebody has to emerge with a business model which will allow them to
make enough money to support the RT stuff.

Karim Yaghmour

unread,
May 25, 2002, 12:41:07 PM5/25/02
to

Larry McVoy wrote:
> > You can dimiss those who haven't chosen #4 as much as you want and
> > find all the reasons to justify your dismissal. It remains that the
> > embedded/rt market is closed to Linux because of the current situation.
>
> Hmm, then why did Lineo license the patent? Why is FSMlabs still in
> business?

I'm not denying that there are clients who will still choose to pay
FSMLabs. But they're a staff of less than 10, so that's not very indicative
of anything else than minor market interest for the technology.

As for Lineo, they've been in financial trouble for some time, so their
situation is rather telling.

> I don't buy your assertions for one second without some strong data to
> back them up. Just saying something doesn't make it so, show me the
> data.

Developers will simply not come out in the cold and say we chose OS xyz
instead of Linux because of the rtlinux issues. But talk to them in
private and then you get an entirely different picture.

One sympton of the current situation is the recent study by the VDC
which I alluded to earlier:
http://www.linuxdevices.com/articles/AT6328992055.html

When asked what the #1 factor inhibiting the use of Linux, developers
answered "real-time limitations".

This speaks for itself.

Karim

===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================

Linus Torvalds

unread,
May 25, 2002, 1:27:24 PM5/25/02
to

On Sat, 25 May 2002, Robert Schwebel wrote:
> >
> > Which is, in my opinion, the only sane way to handle hard realtime. No
> > confusion about priority inversions, no crap. Clear borders between what
> > is "has to happen _now_" and "this can do with the regular soft realtime".
>
> ... which in turn results in the situation that applications must be
> implemented as kernel modules.

That's a load of bull.

It results in the fact that you need to have a _clear_interface_ between
the hard realtime parts, and the stuff that isn't.

Yes, that does imply a certain amount of good design. And it requires you
to understand which parts are time-critical, and which aren't.

> This is only correct for open-loop applications. Most real life apps are
> closed-loop.

Most real life apps have nothing to do with hard-RT.

Linus

Linus Torvalds

unread,
May 25, 2002, 1:22:00 PM5/25/02
to

On Sat, 25 May 2002, Thunder from the hill wrote:
>
> 2. They get used to RTLinux, where they are altogether forced to use
> either GPL or their license. This isn't exactly a way of choice.

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.

Oliver Xymoron

unread,
May 25, 2002, 1:34:29 PM5/25/02
to
On Fri, 24 May 2002, Larry McVoy wrote:

> On Sat, May 25, 2002 at 12:48:00AM -0400, Karim Yaghmour wrote:
> > "Anything which is not part of the patent's claims is not covered by
> > the patent, and can be done by anyone anywhere anytime, without regard
> > to the patent."
>
> Sure. As long as it does not depend on the patent to work. I don't care
> if Victor says that you have to love your mother in order to license his
> patent. If that's what he says, those are the terms. You are *paying*
> for the right to use the patent. His terms are that you are 100% GPL
> all the way through. OK, so deal with that.
>
> Eben is absolutely right - if you want to do something completely unrelated
> to the patent, which does not use any aspect of the patent, you are in the
> clear. Unfortunately for you & Eben, that's irrelevant if what you are
> doing doesn't work without RT/Linux. If that's true, you're using his patent
> and you have to pay his price.
>
> I really don't see the problem anyway. FSMlabs worked long and hard to
> produce their work. And took the time and effort to patent it. And they
> allow you to use it for free if you are working on 100% free stuff. That's
> pretty reasonable.

What's completely unreasonable is that they patented something they damn
well knew has existed for decades. Yes, it's a neat trick that they were
able to do it with Linux with low overhead, but people have been using
UNIX as guests atop VM layers for a long time, and guess what? They've
been doing realtime interrupt processing on those same machines. Hell,
there are half a dozen products that do this with DOS and Windows that
predate RTLinux, like iRMX. In fact, look no further than the PC on your
desk's power switch which triggers an interrupt in so-called system
management mode - effectively a real-time layer that pre-empts your OS.
This has been in laptops in some form or another since at least the
386SLC.

Same goes for this "embedded protocol objects" patent. The patent is so
vague about what it's actually patenting that it certainly runs afoul of
the zero-copy buffering scheme from the IO-Lite paper we all read a few
years ago, never mind simple readv/writev (and your own IO-doohickeys!).

Compare:

http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/
netahtml/PTO/search-bool.html&r=2&f=G&l=50&co1=AND&d=PG01&s1=
'molnar+ingo'.IN.&s2='red+hat'&OS=IN/%22molnar+ingo%22+AND
+%22red+hat%22&RS=IN/%22molnar+ingo%22+AND+%22red+hat%22

http://www.usenix.org/publications/library/proceedings/osdi99/
full_papers/pai/pai.pdf

--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."

Karim Yaghmour

unread,
May 25, 2002, 2:22:18 PM5/25/02
to

Linus Torvalds wrote:
> - I think the microkernel approach is fundamentally broken. Karim claims
> there is no priority inversion, but he must have his blinders on. Every
> single spinlock in the kernel assumes that the kernel isn't preempted,
> which means that user apps that can preempt the kernel cannot use them.

Blinders ehh... Well, if you would care to ask I would answer.

In reality, what you point out is actually a non-issue since the hard-rt
user-land tasks are not allowed to call on normal Linux services. They
can only call on RTAI services which are exported by an extra soft-int.
These services are hard-rt, so there's no problem there.

Please, download the thing and play with it. Or, at the very least, ask
about how it works and we'll be glad to explain.

Karim

===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================

Kurt Wall

unread,
May 25, 2002, 1:47:09 PM5/25/02
to
{CCs trimmed]

Scribbling feverishly on May 25, Karim Yaghmour managed to emit:


>
> Larry McVoy wrote:
> > 4. Contact FSMlabs, ask about licensing costs, compare to #3 and go with
> > #4 if it makes sense.
>

> Many people have said this before and I will say it again: Linux is
> fine as an open-source/free-software rtos, but as a non-free rtos it
> has no chance in front of the competition.

Sorry, I must have lost track of this argument. I thought the point of
contention was the RTLinux patent, which seems pretty clear on the key
issue: if your stuff is GPL, we're GPL; if you make money, we want a slice
of the pie. Now it almost sounds like you're telling us that the real
issue is that you can't make your own Linux-as-nonfree-rtos. Well, I'm not
very smart, so maybe I've misunderstood.

> You can dimiss those who haven't chosen #4 as much as you want and
> find all the reasons to justify your dismissal. It remains that the
> embedded/rt market is closed to Linux because of the current situation.

That dog won't hunt. There are more players in the Linux embedded/RT space
than RTAI and RTLinux, which you have conveniently overlooked throughout
this entire thread. Maybe at this time none of them are ready for $300
IPO pops, but you can't make the argument that "RT is closed to Linux"
when your only data points are RTAI and RTLinux.

Kurt
--
So, what's with this guy Gideon, anyway? And why can't he ever
remember his Bible?

Larry McVoy

unread,
May 25, 2002, 2:02:08 PM5/25/02
to
On Sat, May 25, 2002 at 07:50:30PM +0200, Wolfgang Denk wrote:
> I do like it very much when all code I write is GPLed, but there are
> situations where a there are good reasons for some application code
> to remain closed.

Yeah, like you're trying to make money. Which is fine. But if that
"application" needs to use the RT/Linux patent in order to work, it
either has to buy a license or be GPLed.

It's somewhat two faced that the protesters here are arguing that
everything has to be free in order for Linux to be used as a RT platform,
but then come back and complain that the FSMlabs patent says everything
has to be free if you don't want to pay.

Maybe Victor should have used a different model: if no money changes hands,
then it's free to use the patent, if money changes hand, FSMlabs wants a
cut. I think that was the intent, but as with all things, it's hard to
state that clearly in a legal document. If that was the intent, I support
it, I think it's perfectly reasonable.

--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

Karim Yaghmour

unread,
May 25, 2002, 1:49:19 PM5/25/02
to

I'll be short, no worry.

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

The VDC report is no FUD. As the link I gave states, this is a "survey
of 11,000 embedded systems developers." Their #1 reason for not using
Linux: real-time limitations.

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

I have no disagreement with the kernel being GPL.

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

I didn't say that. I said the current situation, with all that it involves,
is hurting Linux. The GPL requirement is only part of the picture.

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

Fair enough. Note that I'm not betting against you, I'm just trying to
point out a problem. Whether you care to deal with this is problem is
an entirely different issue.

Karim

===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================

Karim Yaghmour

unread,
May 25, 2002, 2:32:46 PM5/25/02
to

Kurt Wall wrote:
> Sorry, I must have lost track of this argument. I thought the point of
> contention was the RTLinux patent, which seems pretty clear on the key
> issue: if your stuff is GPL, we're GPL; if you make money, we want a slice
> of the pie. Now it almost sounds like you're telling us that the real
> issue is that you can't make your own Linux-as-nonfree-rtos. Well, I'm not
> very smart, so maybe I've misunderstood.

Don't take my word for it. Here's an article written by Jerry Epplin in
February 2001:
http://www.linuxdevices.com/articles/AT2094189920.html

He ends his article with the following:
"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."

As for my own opinion, please reread my first post. It clearly says that
the current rtlinux patent situation (in its entirety) is a show-stopper
for Linux. Everything I said after that all boils down to explaining this
point of view.

> That dog won't hunt. There are more players in the Linux embedded/RT space
> than RTAI and RTLinux, which you have conveniently overlooked throughout
> this entire thread. Maybe at this time none of them are ready for $300
> IPO pops, but you can't make the argument that "RT is closed to Linux"
> when your only data points are RTAI and RTLinux.

Care to look at the VDC report conducted over 11,000 developers. Result:
the #1 fact inhibiting Linux's adoption in the embedded space is
"real-time limitations."

Don't listen to me, listen to 11,000 developers ...

Mark Mielke

unread,
May 25, 2002, 2:38:34 PM5/25/02
to
On Sat, May 25, 2002 at 02:32:46PM -0400, Karim Yaghmour wrote:
> February 2001:
> http://www.linuxdevices.com/articles/AT2094189920.html

> He ends his article with the following:
> "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 looks exactly like a party line to me. In fact, the same
statement could be made by the FSF for every single application that
currently exists.

Would they be right? We each draw our own conclusions.

mark

--
ma...@mielke.cc/ma...@ncf.ca/ma...@nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

Linus Torvalds

unread,
May 25, 2002, 2:12:03 PM5/25/02
to

On Sat, 25 May 2002, Wolfgang Denk wrote:
>
> What do you think: it it OK (both from the legal and from the ethic
> point of view) that somebody writes and distributes proprietary
> application code?

That's not my point.

My point is that from a technical standpoint, I think giving user land
higher priorities than the kernel is _wrong_.

It gets you into all the priority inversion stuff, where you suddently
must not do simple system calls because the regular kernel locks are no
longer safe to use. That's a HUGE design mistake, and a classic one. Yes,
others have done it that way. A billion flies _can_ be wrong - I'd rather
eact lamb chops than shit.

In short:

- I think the microkernel approach is fundamentally broken. Karim claims
there is no priority inversion, but he must have his blinders on. Every
single spinlock in the kernel assumes that the kernel isn't preempted,
which means that user apps that can preempt the kernel cannot use them.

(Or RTAI just handles the priority inversion the way that it has been
handled in other places: by dropping the priority on the floor when
calling into the kernel. Whatever. It's still priority inversion, and
it's still broken).

It's worse than that. Something as simple as growing your stack a bit
too much will cause a hard kernel failure (or failure of the RT part,
assuming that the priority is dropped). Karim claims to give "user
land" hard-real-time abilities, but the fact is, it's not "user land"
any more. it's a limited shadow, and a _perversion_ of what user land
is supposed to be all about.

This is my _technical_ reason for saying that user-land hard realtime
sucks, and SHOULD NOT BE DONE. That way lies madness, and crap.

- My other argument is one of FUD against the patent. People claim that
the RTLinux patent stands in their way, and they are full of _crap_.

- The patent only covers a specific way of doing things, which as
far as I can tell isn't even an issue with RTAI. In short, the
RTLinux patent has about as much to do with "holding up
real-time development on Linux" as every other patent out there.

- Yes, if you go the RTLinux way, you either need to make your RT
kernel modules GPL'd, or you need to pay FSMlabs. Since I would
strongly suggest you make kernel modules GPL'd anyway, this just
isn't an issue. The fact that FSMlabs can get people to pay for
their patent is just another "tax on stupidity".

And "tax on stupidity" is fine by me. People who don't want to
use the GPL might as well pay for it, either by paying FSMlabs
or by paying somebody else. I don't care.

Have I made myself sufficiently clear by splitting up the issues into a
technical part and a FUD part?

Linus

Linus Torvalds

unread,
May 25, 2002, 2:44:39 PM5/25/02
to

On Sat, 25 May 2002, Karim Yaghmour wrote:
>
> Blinders ehh... Well, if you would care to ask I would answer.
>
> In reality, what you point out is actually a non-issue since the hard-rt
> user-land tasks are not allowed to call on normal Linux services. They
> can only call on RTAI services which are exported by an extra soft-int.
> These services are hard-rt, so there's no problem there.

.. which was exactly what I said:

"..every single spinlock in the kernel assumes that the kernel isn't


preempted, which means that user apps that can preempt the kernel
cannot use them."

Karim, I don't _need_ to download RTAI or ask you questions about how it
works, because this is fundamental "RT-101" stuff. This is what priority
inversion is all about: if you make user land more important than the
kernel, it _cannot_ stay RT and use kernel services.

I went on to say:

"Karim claims to give "user land" hard-real-time abilities, but the
fact is, it's not "user land" any more. it's a limited shadow, and a
_perversion_ of what user land is supposed to be all about."

Which certainly should have told you that I understood the limitations of
RTAI very well indeed. And I reject them.

Linus Torvalds

unread,
May 25, 2002, 2:52:24 PM5/25/02
to

On Sat, 25 May 2002, Wolfgang Denk wrote:
> > On Sat, 25 May 2002, Wolfgang Denk wrote:
> > >
> > > What do you think: it it OK (both from the legal and from the ethic
> > > point of view) that somebody writes and distributes proprietary
> > > application code?
> >
> > That's not my point.

> ...


> > Have I made myself sufficiently clear by splitting up the issues into a
> > technical part and a FUD part?
>

> Yes, and I completely agree with you.
>
> Nevertheless, you din't answer above question with a clear "yes" or
> "no"...

Am I going to sue the RTAI people for doing something like what they are
doing, considering it "illegal" or "immoral"? Obviously the answer there
is "no". It's not illegal to disagree with my opinions (*).

But I don't want to have their FUD down my throat either.

Getting people to say "patent issues" to some random inquiry isn't all
that hard. It's something that it's easy to blame all your problems on,
and it's something that the open source crowd tends to lap up a bit too
eagerly in my opinion ("ooh, if it weren't for those evil patents, we'd
rule the world").

It's a hot button, and as such a really easy target for FUD.

Linus

(*) Although it obviously _should_ be. Mwhaahahahahaaa... You unbelievers
will all be shot when the revolution comes!

Larry McVoy

unread,
May 25, 2002, 2:44:26 PM5/25/02
to
On Sat, May 25, 2002 at 08:26:12PM +0200, Wolfgang Denk wrote:
> > "application" needs to use the RT/Linux patent in order to work, it
> > either has to buy a license or be GPLed.
>
> But this is an ADDITIONAL restriction, which violates the GPL, which
> is the base of the RTL code, or isn't it?

Don't mix the GPL and the patent rules, they are not the same thing.
To the extent that RTL code is derived from GPLed code, it has to
obey the GPL, that's true. But the patent does not have to obey the
GPL, one are is copyright law (that's what covers the GPL) and the
other is patent law.

FSMlabs can make any rules they want for their license of their patent.
The fact that the GPL doesn't want additional restrictions has no bearing
on the patent law.

> > Maybe Victor should have used a different model: if no money changes hands,
> > then it's free to use the patent, if money changes hand, FSMlabs wants a
>

> Define "if money changes hand". Let's say I develop a smart
> controller software for disk drives, and I give it (maybe for money,
> maybe for free, maybe under GPL or not) to IBM and Maxtor and
> Seagate. The disk manufacturers make modifications to the code, and
> embed it into their disk drives. Then they sell the drives to Dell
> and HP and ... Those sell PCs to many, many vendors, who sell the PCs
> to you and men and ...

Definitely "money changed hands".

> > cut. I think that was the intent, but as with all things, it's hard to
> > state that clearly in a legal document. If that was the intent, I support
> > it, I think it's perfectly reasonable.
>

> If that was the case, Victor should have been able to explain his
> intentions to anybody in public. Why did he never do that? But spread
> FUD instead?

Well, as someone who has been working in a somewhat similar manner, I can
say that there is a very unhealthy tendency for the free software community
to be fanatical and somewhat self destructive on these topics. There are
piles of people who want to make money off of your work and have absolutely
no intention in sharing that money. And they get pissed as hell when you
figure out a way to force them to share that money. After a while, you
get pretty sick of people yelling at you and you just start to ignore them.
I've spoken with Victor about this topic a few times and while I will not
speak for him in specifics, I will say he's equally unthrilled with a lot
of what gones on. It's tiresome.


--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

Mark Mielke

unread,
May 25, 2002, 2:33:58 PM5/25/02
to
On Sat, May 25, 2002 at 02:22:18PM -0400, Karim Yaghmour wrote:
> Linus Torvalds wrote:
> > - I think the microkernel approach is fundamentally broken. Karim claims
> > there is no priority inversion, but he must have his blinders on. Every
> > single spinlock in the kernel assumes that the kernel isn't preempted,
> > which means that user apps that can preempt the kernel cannot use them.
> Blinders ehh... Well, if you would care to ask I would answer.
> In reality, what you point out is actually a non-issue since the hard-rt
> user-land tasks are not allowed to call on normal Linux services. They
> can only call on RTAI services which are exported by an extra soft-int.
> These services are hard-rt, so there's no problem there.
> Please, download the thing and play with it. Or, at the very least, ask
> about how it works and we'll be glad to explain.

None of which proves that it is the right way to do things.

From what I understand, Linux _is_ being considered for RT applications
by quite a few heavy-weights in the field including IBM, Intel and
quite a few others. The patent issue that you present does not seem to be
discouraging them in any way.

My limited observations suggest that the primary reasons people do not
use Linux for their RT applications are:

1) They don't trust it for 'high availability'.

2) They already have their application mostly written, or
completely written, for some other RT operating system, and
it would cost too much to switch.

Issues such as patents are quite common place and extremely regular
for any serious company that produces RT applications. They *expect*
to have to pay for a good operating system. In fact, if they didn't
have to pay, they become suspicious, usually with good reason.

mark

--
ma...@mielke.cc/ma...@ncf.ca/ma...@nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada

One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...

http://mark.mielke.cc/

-

Karim Yaghmour

unread,
May 25, 2002, 2:45:56 PM5/25/02
to

Mark Mielke wrote:
> None of which proves that it is the right way to do things.

So, this is all about the "right way"? So the right way is to have
everything in the kernel without memory protection?

> >From what I understand, Linux _is_ being considered for RT applications
> by quite a few heavy-weights in the field including IBM, Intel and
> quite a few others. The patent issue that you present does not seem to be
> discouraging them in any way.

True, but see who you're pointing to: Intel and IBM. Both patent heavywheights.
Do you really think they're going to run scared because of one tiny company
with a questionnable patent? I personnally don't. They probably even have
patents which invalidate the rtlinux patent.

Those who do run scared are all those who develop embedded apps and don't
have the size of IBM or Intel to carry them. And there a great deal of those.

Karim

===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================

Karim Yaghmour

unread,
May 25, 2002, 3:14:40 PM5/25/02
to

Linus Torvalds wrote:
> "..every single spinlock in the kernel assumes that the kernel isn't

> preempted, which means that user apps that can preempt the kernel
> cannot use them."

I misread this paragraph, the rest of my reply follows from this laps.

I said there was no "priority inversion" in the sense that there are
no priority inversion problems during the execution of such user-space
rt tasks. From a purely static perspective, however, the user-space
rt tasks do indeed come to have a higher priority than the kernel.
No fuss there.

That being said, I differ on your judgement of this method.

Karim Yaghmour

unread,
May 25, 2002, 3:52:19 PM5/25/02
to

Larry McVoy wrote:
> I've spoken with Victor about this topic a few times and while I will not
> speak for him in specifics, I will say he's equally unthrilled with a lot
> of what gones on. It's tiresome.

Just a general observation. Your arguments are indeed the same. I've
had the same discussion I've had with you with Victor many times.

There is, however, some differences between your situations. I can
rewrite a software that does similar things as yours and sell it
or give it away using whichever license I like. I can't write a similar
software to Victor's and sell it or give it away using whichever
license I like.

There's no need to reply and point out that that's what patents are all
about. I can see that for myself. I'm just pointing out that your
situation is not exactly the same as Victor's.

Andre Hedrick

unread,
May 25, 2002, 4:29:27 PM5/25/02
to
On Sat, 25 May 2002, Daniel Phillips wrote:

> On Saturday 25 May 2002 19:49, Karim Yaghmour wrote:
> > > 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.
> >
> > I have no disagreement with the kernel being GPL.
>

> I'd like to take this opportunity to take a turn back towards the original
> issue: supposing that Ingo's/Red Hat's patented extension to the dcache is
> accepted into the kernel. Would not the GPL's patent trap provision
> prevent Red Hat from distributing the result, unless Red Hat also provides
> a license for the patent permitting unrestricted use *regardless of
> commercial or noncommercial use* of the patent in the context of the GPL'd
> code? So it's either provide the license, or don't incorporate the code
> into Linux. (The issue of whether it's a good thing that the latter course
> would also foreclose anybody else from using the same technique is
> separate.)
>
> Supposing that Red Hat distributes a version of Linux accompanied with the
> appropriate license, so that the result can be distributed in compliance
> with the GPL: could Red Hat then prevent other distributors from
> distributing their own version of Linux that has the same extension? I
> hope not, otherwise we have a real problem.

They can, because they provide the source to do so.
Now does it have to be modular loaded, I suspect.
The have every right to prevent people from using their stuff.
There is no ruling standard body to force compliance.
GPL is enforced by the author, owner, copyright holder.
It may have started out under on dominion, but after MOSIX and the
unilatteral (sp) force binary module inclusion, that set the stage to tear
down the theory of GPL enforcement.

But now we venture to embedded space of changes, and there they do not
provide source code even if you are a customer.
So GPL is becoming a LARK.

But then again it has no real business model and I expect to be deleted
form the thread so I will do so before others.

Andre Hedrick
LAD Storage Consulting Group

Larry McVoy

unread,
May 25, 2002, 4:36:37 PM5/25/02
to
On Sat, May 25, 2002 at 03:52:19PM -0400, Karim Yaghmour wrote:
> Larry McVoy wrote:
> > I've spoken with Victor about this topic a few times and while I will not
> > speak for him in specifics, I will say he's equally unthrilled with a lot
> > of what gones on. It's tiresome.
>
> There is, however, some differences between your situations. I can
> rewrite a software that does similar things as yours and sell it
> or give it away using whichever license I like. I can't write a similar
> software to Victor's and sell it or give it away using whichever
> license I like.

A couple of points. If you are going to rewrite, then you should rewrite.
I'm told, and I've seen, that there substantial parts of RT/Linux in the
RTAI source base. Isn't it true that RTAI used to be called "my-rtai"
and the guy who did that work freely admitted that it was a fork of the
RT/Linux source base?

Second, that's what patents are all about, it's about protecting your
investment. I think you should get used to dual use licensing of patents,
I expect to see a lot more of this as people start to realize that giving
away the software and hoping that people will magically give you money
just doesn't work. There are a lot of people who value free software,
want to support it, and will do so if it is really free. On the other
hand, as soon as money enters the equation, the rules will change and
you're just going to have to deal with that.


--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

Larry McVoy

unread,
May 25, 2002, 5:05:32 PM5/25/02
to
On Sat, May 25, 2002 at 10:51:34PM +0200, Wolfgang Denk wrote:
> > and the guy who did that work freely admitted that it was a fork of the
> > RT/Linux source base?
>
> Yes, of course it was a fork at a very early point of the develop-
> ment. So what? Nobody denies that RTAI is based on the same core idea
> as RT-Linux - that's why the RT-Linux patent _is_ an issue to RTAI.

s/same core idea/same core code/

Go search around, get the code you can still find on the net and start
diffing. So not only do the RTAI people have an issue with the patent,
it looks like they'd better be conforming to the GPL as well. Didn't
RTAI switch the copyright on "their" sourcebase to LGPL? So explain to
me how you can take a GPLed source base, change it, and then change the
license. Are you saying that 100% of that source base has been rewritten?

Linus Torvalds

unread,
May 25, 2002, 4:53:41 PM5/25/02
to

On Sat, 25 May 2002, Daniel Phillips wrote:
>
> I'd like to take this opportunity to take a turn back towards the original
> issue: supposing that Ingo's/Red Hat's patented extension to the dcache is
> accepted into the kernel. Would not the GPL's patent trap provision
> prevent Red Hat from distributing the result, unless Red Hat also provides
> a license for the patent permitting unrestricted use *regardless of
> commercial or noncommercial use* of the patent in the context of the GPL'd
> code?

Absolutely.

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.

Linus

Larry McVoy

unread,
May 25, 2002, 5:23:17 PM5/25/02
to
On Sat, May 25, 2002 at 11:20:48PM +0200, Wolfgang Denk wrote:
> > RTAI switch the copyright on "their" sourcebase to LGPL? So explain to
> > me how you can take a GPLed source base, change it, and then change the
> > license. Are you saying that 100% of that source base has been rewritten?
>
> Did you notice that the RTAI core is now released under GPL?

And why is that? Could it be that RTAI is derived from RTL, and RTL is
GPLed, and it was illegal for RTAI to ever have been anything but GPL?


--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

Albert D. Cahalan

unread,
May 25, 2002, 5:22:43 PM5/25/02
to
Linus Torvalds writes:

> - Yes, if you go the RTLinux way, you either need to make your RT
> kernel modules GPL'd, or you need to pay FSMlabs. Since I would
> strongly suggest you make kernel modules GPL'd anyway, this just
> isn't an issue. The fact that FSMlabs can get people to pay for
> their patent is just another "tax on stupidity".

I think you misunderstand, but maybe I do...

To get a free patent license, EVERYTHING must be GPL.
Not just the real-time part! So that would be:

1. the RT microkernel (OK)
2. the RT "app" (OK)
3. Linux itself (OK)
4. normal Linux apps (ouch!)

Karim Yaghmour

unread,
May 25, 2002, 5:19:44 PM5/25/02
to

Linus Torvalds wrote:
> 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.

There is no garantee that this is precisely what will happen in the future.

What if MS threw a couple of millions at Victor to buy his patent (that's
not that far-fetched since Victor has shown a very clear intent to make
money off of his patent and since MS is clearly intent on crushing Linux)
and then said that all GPL uses of this patent are prohibited? What then?

Karim

===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================

Larry McVoy

unread,
May 25, 2002, 5:33:33 PM5/25/02
to
On Sat, May 25, 2002 at 05:22:43PM -0400, Albert D. Cahalan wrote:
> To get a free patent license, EVERYTHING must be GPL.
> Not just the real-time part! So that would be:
>
> 1. the RT microkernel (OK)
> 2. the RT "app" (OK)
> 3. Linux itself (OK)
> 4. normal Linux apps (ouch!)

Whether that is true or not I don't know. But I do know that if all the
stuff was GPLed, then you are safe no matter what, right? In other words,
there is a path you can take which makes it safe. And according to all the
RTAI people, that path should be completely acceptable, they all are quick
to tell you that everything they do (now) is GPLed and that's how they want
it. If that's true, no worries. I suspect the reality is that some/most
of the code is GPLed but there is some critical chunk that is not GPLed
and you don't get source and that's the revenue stream. If I'm wrong, the
RTAI folks have nothing to worry about.


--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm

Karim Yaghmour

unread,
May 25, 2002, 5:14:17 PM5/25/02
to

Larry McVoy wrote:
> A couple of points. If you are going to rewrite, then you should rewrite.
> I'm told, and I've seen, that there substantial parts of RT/Linux in the
> RTAI source base. Isn't it true that RTAI used to be called "my-rtai"
> and the guy who did that work freely admitted that it was a fork of the
> RT/Linux source base?

Well, this is standard Victor FUD. He's been repeating this to everyone with
an ear to listen. He has yet to show us a single line of code which is
supposidely taken from RTLinux. But just to satisfy the curiosity of those
who may beleive this sort of stuff, I'm including below an email I had
sent to Victor (+ CC the rtl-advocacy mailing list) about _explicit_ copyright
violations within RTLinux. It should be an interesting read.

Note that the attached email was never answered.

Again, if anyone cares to show the RTAI team actual lines of code that
match between RTLinux and RTAI, we'll be glad to investigate. Until then,
this whole issue remains a classic case of FUD againt RTAI.

> Second, that's what patents are all about, it's about protecting your
> investment. I think you should get used to dual use licensing of patents,
> I expect to see a lot more of this as people start to realize that giving
> away the software and hoping that people will magically give you money
> just doesn't work. There are a lot of people who value free software,
> want to support it, and will do so if it is really free. On the other
> hand, as soon as money enters the equation, the rules will change and
> you're just going to have to deal with that.

You're just trying to justify the continued existence of the software
industry. My belief is that the existence of large enterprises that sell
software (whether they sell copyright licenses for it or patent licenses
for, it's the same business model) is very much questionnable at this point.

Here's for the email I mentionned:
<mail entitled: More from the history department ...>
Just for those who may have believed Victor's claim on the rtl-advocacy
list that I wasn't honest and those of you on the RTAI mailing list who
want to know how come the RTAI folks don't really like what Victor is doing,
I've added some interesting historic tidbits from the RTLinux mailing
list.

This stuff dates back to 1997 and at the time the RTLinux mailing
list was still on NMT's server, management of RTLinux's code was still
in Michael's hand (but this just on the point of changing), VJY associates
(which later became FSMLabs) wasn't in the picture, RTLinux was still
a big kernel patch instead of a modularized package (it later became
modularized after ...), Victor was still a professor at NMT, and lots
of contributions were being sent from left and right both privately
and publicly.

So here's for history's sake:

Here's a reply by Michael Barbanov to Paolo's message regarding the
periodic mode of the 8254 (date: Fri 18 Apr 1997):
--------------------------------------------------------------------------
In message <1997041809...@charon.cs.nmt.edu>, Prof. Paolo Mantegazza wrote:
>Rt-linux is really nice in that it allows to gain an easy access to the
>hardware while keeping the services of linux. However the timer shooting
>technique adopted, while being extremely flexible, requires to much i/o time
>to program the 8254. Is it correct that each i/o blocks the bus for 1 to 1.5
>microseconds?. In fact I did not get anything better than the performance
>cited in rt-linux accompaning paper even by using a 200Mhz PentiumPro
>against a 120 Mhz Pentium. This seems to be confermed by R. Wilhelm recent
>mail. In control and data acquisition problems where there is always a high
>frequency master periodic task at high frequency and precise timings the
>usual mode 2 programming requires just the EOI output of the timer isr and
>should lead to improve performances. In this view I have modified rt_time.c
>and rt_prio_sched.c and it seems that the performances can increase
>substantially. In fact the rect_wawe test can be run with a 10 us ticking to
>give a 50Khz neat squarewave, 1 ns uncertainty, while operating the X
>environment with somewhat sluggish but acceptable, it can depend on your
>idea of acceptable, performances. So if one can accept a fixed time
>resolution that can be an alternative approach. Comments are welcomed. Warm
>thanks again to rt-linux fellows for their work. I think that the
>possibility of adding a user layer within the kernel made possible by the
>way thay have handled the interrupts will be usefull for many other
>applications.
>Greeting, Paolo.

Yes, it's true that the programming of the 8254 timer takes a lot of time (I
think each outb takes even more than 1.5us). The use of mode 2 (periodic
interrupts) can be reasonable for some applications.
--------------------------------------------------------------------------
Notice that peridic mode wasn't in RTLinux, but it was explained by Paolo
and implemented by Paolo first.

But wait, here's more:

This message was sent by Paolo in response to a question by Michael on
how to simulate Linux timer interrupts (date: Tue 22 Apr 1997):
--------------------------------------------------------------------------
>How do you simulate Linux timer interrupts, BTW?
Dear Michael,
below you'll find the code of my scheduling and timer handler functions.