patent on O_ATOMICLOOKUP [Re: [PATCH] loopable tmpfs (2.4.17)]
Karim Yaghmour
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
> > 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
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
> This matter remained unchanged until the FSF came out later and
> 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
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
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.
>
> 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
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
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
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
> 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
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
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
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
> 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
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
> "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
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
> 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
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
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
> 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
> 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
> 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
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
>
> 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
> 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
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
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
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
> 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
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
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
> 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
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
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
> 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...
Linus Torvalds
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
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
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
> > "application" needs to use the RT/Linux patent in order to work, it
> > either has to buy a license or be GPLed.
>
> 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
> 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
> > which means that user apps that can preempt the kernel cannot use them.
> 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.
> 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...
-
Karim Yaghmour
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
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
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
> 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
> 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.
>
> 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
> > and the guy who did that work freely admitted that it was a fork of the
> > RT/Linux source base?
>
> 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
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
> > 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?
>
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
> - 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
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
> 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
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"
> 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. (I
know that are not in good C code). Yuo can notice that I make delayed task
ready only in the timer handler which also does the usual scheduling,
rt_schedule switches only among ready tests. I have added a kind of
signalling in that every time a task is rescheduled it calls a signal
function that can enable interrupts. So the Linux timer is fired from your
basic timer isr routine if it returns with SFIF enabled after the time
interrupt or by simply using sti() in the signa_linux_timer function when
Linux is rescheduled. This seems to work or at least it works with your
testings and in my opinion it should be correct. If you have any comment or
find the approach faulty for more general applications please advice me so
that I'll avoid loosing time. In fact, as you'll notice from the code, I'm
designing semaphore, messages and rpc within rt-kernel, and I want to avoid
building on a sand foundation. Also notice that the code of my modifications
is available, anybody interested, with a good heart and willingness to take
the risk should let me know and I'll provide it as it is. I have no web or
ftp service available. A lot of testing is still needed for a full
implementation.
Paolo.
static void rt_schedule(void)
{
RT_TASK *task;
--------------------------------------------------------------------------
In this case, Paolo sent a big chunck of code. Wonder what became of this
code Paolo sent to Michael ... ???
Here's Paolo's first mention of what would later be know as RTAI
(date: Mon 9 Jun 1997):
--------------------------------------------------------------------------
Is there anyone interested in a different rt_sched module implementing the
following functions?
extern int rt_task_init(RT_TASK *task, void (*rt_thread)(int), int data,
int stack_size, int priority, int uses_fpu,
void(*signal)(void));
extern int rt_task_delete(RT_TASK *task);
extern void rt_save_init_fpu(void);
extern void rt_restore_fpu(void);
--------------------------------------------------------------------------
The mail goes on to provide an extensive list of functions.
Here's an e-mail discussing the FPU problems I mentionned RTLinux had
and how Paolo was the first to implement the solution and to provide
code (date: Tue 18 Nov 1997):
--------------------------------------------------------------------------
Till Christian Sering Replied to the idea of setting linux as an FPU rtlinux
task as follows:
>Hi,
>
>did I get it right. Your solution would be to assume linux is using the
>FPU by default and thus the linux task must be marked as using the FPU.
>Sounds like a very good solution to me - but is it right,that FPU
>exceptions generated in rtlinux still need to be handled in rtlinux?
>
>Greetings,
>
> Till!
This is the solution I implemented in my variant of rtlinux, that can be
easily adapted to the official release as well. I do not care to serve the
FPU execeptions. In fact my idea is to program the FPU to discard them in
the user module which must contain all the tests needed to avoid FPU
exceptions in advance during the debug phase, stripping the redundant ones
off when every thing works o.k. Clearly it is not a very brilliant solution
but has solved my problems so far. I think that FPU exceptions in real time
applications, e.g. control, should not happen as they are an indication that
something has gone out of control. In any case my opinion is that real time
FPU exception services should be slimlined and in the rtkernel.
Ciao,
Paolo.
--------------------------------------------------------------------------
Again, Paolo was the first to implement and RTLinux followed ...
And Victor, Please explain the following:
The RTLinux fifo code used to have the following copyright header:
/*
* RT-FIFO devices
*
* 1997, Michael Barabanov
*
* A lot of this code is stolen from fs/pipe.c
*
*/
Notice the last phrase ... :
Now, checkout the new license:
/*
* (C) Finite State Machine Labs Inc. 1995-2000 <busi...@fsmlabs.com>
*
* Released under the terms of GPL 2.
* Open RTLinux makes use of a patented process described in
* US Patent 5,995,745. Use of this process is governed
* by the Open RTLinux Patent License which can be obtained from
* www.fsmlabs.com/PATENT or by sending email to
* licenseq...@fsmlabs.com
*/
/*
* Includes a tiny bit of code from Linux fs/pipe.c copyright (C) Linus Torvalds.
*
*/
Somehow, the "A lot of this code is __stolen__ from fs/pipe.c" got
changed to "Includes a tiny bit of code from Linux fs/pipe.c".
Amazing what a little change of words will do ...
Tell me now Victor, are you selling the the fifo code in closed-source?
Because if you are you now owe Linus Torvalds and all the other contributors
to the file royalties on every closed-source copy you sold. That is,
if they agree to their code being sold.
And what about all the code Paolo submitted? You owe him royalties too
don't you?
As I said, there is plenty of this stuff in RTLinux. So please Victor,
next time you accuse others of lacking honesty I suggest you follow
Michael's advice and look at your own eye first.
</mail entitled: More from the history department ...>
Karim
===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================
Karim Yaghmour
Larry McVoy wrote:
> 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.
And that's precisely one of the symptoms of this problem: No one
knows and the intellectual property owner has made no effort to
provide any explanation either. Instead, he's been trying to
spread as much uncertainty as possible.
Larry McVoy
> > 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.
>
> spread FUD, but also lies and insults.
Hey, I said "I suspect". You can scream all you want but if the facts are
that the patent license allows 100% GPLed stuff for free, and you are saying
that it is all 100% GPLed, and yet you continue to complain, what conclusion
would you like people to draw? I'm pointing out the obvious one.
It's as if FSMlabs had a patent on colors and they said anyone using green
and nothing but green is OK, no charge. And there was a group of people
who swear up and down that all they do is green yet they continue to complain
about the patent. If you were watching that, wouldn't you wonder if they
were telling you the whole truth?
Let's review:
- we all agree that one possible way to guarentee that you are not in
violation of the free use license for the RTL patent is if 100% of
the code is GPLed, right?
- you and the other RTAI guys swear up and down that it is all GPLed.
So what's the problem?
> Larry, I consider this a personal insult, and hereby request you (1)
> to withdraw this statement in public and (2) to apologize to the RTAI
> comunity for it.
Show me where I've done anything worth apologizing for and I'll consider it.
Apologizing for pointing out the obvious is not my style.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Erwin Rol
> > > 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.
> >
> > We do have to worry something about: people like you who not only
> > spread FUD, but also lies and insults.
>
> Hey, I said "I suspect".
Well you suspected wrong. And even before you made that statement
several developers explained that they make money in a other way than
via RTAI, and others like myself told you they just code RTAI in their
spare time. So the statement is pure FUD, especialy since the whole RTAI
sources are available on the website, and helll you can even follow
every little change in the CVS, no critical chunks missing.
> You can scream all you want but if the facts are
> that the patent license allows 100% GPLed stuff for free, and you are saying
> that it is all 100% GPLed, and yet you continue to complain, what conclusion
> would you like people to draw? I'm pointing out the obvious one.
When things don't apply to one self in person it doesn't mean you should
not care about them. RTAI is free software under the GPL, but that does
not mean we want to force the users of RTAI to also use the GPL, and
with the binary module exception of the kernel and the LXRT for
userspace we gave them the freedom to choose a license of their own. The
patent takes this freedom away, as patents always take freedoms away.
>
> It's as if FSMlabs had a patent on colors and they said anyone using green
> and nothing but green is OK, no charge. And there was a group of people
> who swear up and down that all they do is green yet they continue to complain
> about the patent. If you were watching that, wouldn't you wonder if they
> were telling you the whole truth?
>
> Let's review:
> - we all agree that one possible way to guarentee that you are not in
> violation of the free use license for the RTL patent is if 100% of
> the code is GPLed, right?
> - you and the other RTAI guys swear up and down that it is all GPLed.
>
> So what's the problem?
>
> > Larry, I consider this a personal insult, and hereby request you (1)
> > to withdraw this statement in public and (2) to apologize to the RTAI
> > comunity for it.
>
> Show me where I've done anything worth apologizing for and I'll consider it.
> Apologizing for pointing out the obvious is not my style.
Maybe you should try it some time, you know what they say about ppl that
dare to admit they are wrong.
- Erwin
Karim Yaghmour
Larry McVoy wrote:
> > 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
> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
What's "obvious"? Which part of HTTP download don't you understand?
http://www.aero.polimi.it/RTAI/
Get the thing, untar it, patch the kernel and off you go. Nothing's
missing here.
Or maybe you prefer CVS:
http://cvs.rtai.org/index.cgi/
Please, point me to the missing files or tell me that the above
sites don't give you packages you can download/compile/use to obtain
real-time. I've been using and coding in RTAI for the past 2.5 years
and I've never heard about this before.
Or maybe both Wolfgang and I misunderstood your explanation and you
were actually refering to RTLinux?
Karim
===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================
Larry McVoy
> RTAI is free software under the GPL, but that does
Not according to the COPYING file in the current RTAI release. Go read it.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Robert Schwebel
> The RTAI current release COPYING says that it is LGPL, not GPL.
Wrong.
"we have chosen the LGPL as the distribution license."
The "distribution" is much, much more than the schedulers and the patches.
When in doubt please look at the header files of every single source file
to find out about it's specific license.
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 |
+--------------------------------------------------------+
Larry McVoy
> > > 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"
>
> RTAI source"?
Well, since you asked, how about you just go diff the include directories
of the two source bases. That's a wonderful place to start. Anyone who
spends 5 minutes in there will see that RTAI is derived from RTL. Look at
the definition of the RT task struct, it's identical. Look at the fifo.h
file, big chunks of it are identical. Another fun thing is to just want
the directory structure of the two source trees, more clues that it is
RTL derived. It's all been pushed around a lot but I'm not sure you can
take a source base and change it partially and then claim it is yours.
I know if this was my source base I'd be pissed off.
Here's some more, go contrast rt_task_make_periodic() in each of the
source trees, pretty clearly RTL. In fact, the scheduler code is really
easy to see that it's a ripoff. Do a global substitute for
s/rtl_no_interrupts()/hard_save_flags_and_cli()/
and then start diffing, the code starts matching up more.
Furthermore, look at this:
rtai-24.1.9/COPYING
The intent of RTAI developers is to make the code that we write
to be widely useful and that it can be copied and incorporated
into other works, including libraries. In addition, we wish
to make it explicitly clear that linking proprietary code with
RTAI is an acceptible use -- for these reasons, we have chosen
the LGPL as the distribution license.
However, at the current time, RTAI contains portions that are
derived from GPL code, so if you are in a situation where the
difference between GPL and LGPL is an issue, please ask.
So which is it? GPL or LGPL? I thought you guys said you made it
clear that it was GPLed.
Anyway, you can jump up and down until you are blue in the face, it's
absolutely obvious to anyone who looks that the RTAI stuff is derived
from the RTL stuff. Yeah, sure, it's evolved, but it's the same source
base and evolving it does not invalidate their license. The COPYING
file in the *current* RTAI release is illegal. You can't say "Well,
there is some GPL stuff in here, but we're releasing under the LGPL"
just because you feel like it. Didn't you guys repeatedly state that
it was GPL, not LGPL? And is it? Not according to the download.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Robert Schwebel
> Let's review:
> - we all agree that one possible way to guarentee that you are not in
> violation of the free use license for the RTL patent is if 100% of
> the code is GPLed, right?
> - you and the other RTAI guys swear up and down that it is all GPLed.
>
> So what's the problem?
That part of RTAI which uses the patented process is GPLed. Other parts,
which don't, are LGPL. Don't spread vague assumptions - tell us where you
think to have found a license violation or be quiet. It's not very helpful
to tell things in public which are simply not true.
> Show me where I've done anything worth apologizing for and I'll consider
> it.
You blame the RTAI developers for license violations without any proof.
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
> 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.
That's also my experience:
- I have been on all major automation trade shows in Germany for about 5
years
- I am the author of one of the two German books about Embedded Linux and
of lots of articles about Linux for automation
- I have organized the largest developer conference in Germany about "Linux
for industrial applications"
During all that activities I have talked to hundrets of people who are
either already working with Linux or considering it's use. What Karim says
here does exactly reflect the mood of the people.
Larry McVoy
> You blame the RTAI developers for license violations without any proof.
The RTAI current release COPYING says that it is LGPL, not GPL. OK,
now go read the source. There is absolutely *zero* doubt in my mind that
that code is derived from the RTLinux source tree. And I'd be happy to
be called as an expert witness in court and walk the court through the
diffs, there is no way anyone would disagree.
And in spite of the RTAI guys changing lots of stuff, the source base in
which they were working was GPLed. In order for them to change the license,
they have to prove that it was not a derived work. Let's see, it's the
trying to solve the same problem, it started with the same source base,
you can still look at it and see that it was the same source base, and
you think they'll wiggle out of a derived work restriction? Not a chance.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Robert Schwebel
> 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.
Uhm, that shows that you don't have _any_ idea what's going on in the
automation field. IBM is an IT company, and Intel is a processor
manufacturer. We are talking about the world of signal processors and PLCs
here, where companies like Siemens, ABB, Schneider etc. are the big
players.
> 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'.
Not correct.
> 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.
You would be wondering how fast you can port an application for another
RTOS to RTAI. There is even a module for RTAI/LXRT which lets you run
Matlab/RTW code natively on RTAI...
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 |
+--------------------------------------------------------+
Linus Torvalds
On Sun, 26 May 2002, Robert Schwebel wrote:
>
> Show me how you will implement a closed loop controller where the
> application is _not_ implemented as a kernel module. I would really love to
> do it this way, but unfortunately no one of the realtime programmers has
> found a way how it can be achieved so far.
The thing is, if your whole app is really RT, then neither RTAI nor
RTLinux will help you all that much.
The "user space" in RTAI ends up being equally limited as any kernel
module in RTLinux. No dynamic memory allocation, no deep recursion, no
regular system calls. That's just fundamental to hard realtime, and has
nothing to do with any of the environments themselves.
The "advantage" of RTAI is a copyright license issue at that point,
nothing more (well, you get your own address space, but since you mustn't
fault anything anyway, the advantage is dubious, _and_ it certainly eats
into your performance). And as explained elsewhere, I don't find that to
be an advantage at all (and as pointed out by Larry, there seems to be
some dubious issues about the RTAI copyright itself).
Don't get me wrong - I'd love to say that it could be easily fixed by
doing xxxx, but the fact is that since the linux kernel itself isn't hard
realtime, the lack of kernel services really is unavoidable.
And once you lack kernel services, from a programming standpoint it
shouldn't really matter whether it's a kernel module or not. You've got
basically the same amount of (or rather, "lack of") support. A lot of
things are a lot easier in kernel mode (interrupts, IO etc), while you
might find loading the app etc easier in the RTAI model, for example. You
win some, you lose some.
Can we make the whole kernel truly hard-RT? Sure, possible in theory. In
practice? No way, José. It's just not mainline enough.
So I'm agreeing with you: for true hard RT, you need a kernel module. I
can't come up with a way to avoid any of the fundamental problems either..
Linus
Robert Schwebel
> It results in the fact that you need to have a _clear_interface_ between
> the hard realtime parts, and the stuff that isn't.
Show me how you will implement a closed loop controller where the
application is _not_ implemented as a kernel module. I would really love to
do it this way, but unfortunately no one of the realtime programmers has
found a way how it can be achieved so far.
> 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.
Unfortunately, in the automation field nearly all applications are
closed-loop, and that means that the application itself is time critical.
> > 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.
Perhaps in your life :-) It's different in mine, in Karim's, Wolfgang's,
Bernhard's, Steve's, Stuart's, Paolo's, Guennadi's, Thomas', Massimo's,
Pierre's, Lorenzo's, Giuseppe's, Erwin's, Dave's, Ian's, Alex' (just to
mention the RTAI team) and in that of all the thousands of engineers who
are working with Linux and RTAI every day.
Please, take into account that there are people out there wo are working
with Linux in automation and control applications every day, and their
bread and butter _is_ realtime stuff. My experience is that this is
sometimes really hard to understand for people who normally work on
problems from the IT industry, you are not the only one.
Realtime may be someting exotic for "normal" PC users, but in the whole
industrial embedded world it is completely different.
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
> So you split your problem into the RT device driver and the user. And of
> story.
Not possible with closed loop applications.
> 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.
I personally and every other RTAI developer I know is pretty happy with the
Kernel being under the GPL. We are all very active free software
developers, supporters and promoters, believe me. That's not the problem.
We are only talking about the "closed-loop-applications" problem here.
Robert Schwebel
> s/same core idea/same core code/
Not true. Please note that the RTHAL (Realtime Hardware Abstraction Layer)
which is the core of RTAI was even available under DOS in Paolo
Mantegazza's group before it was ported to Linux.
> Go search around, get the code you can still find on the net and start
> diffing.
This may be true for early versions of RTAI, where everybody thought that
we are all working together in a friendly way as we have been used to in
the Linux community.
The core has been completely reworked since thenน - and it nevertheless is
under the GPL, so there is absolutely no problem with that. When there came
up doubts about the legal status of the stuff being under the LGPL in
former times the RTAI team has immediately investigated this, with the
result of the license situation we have today.
> 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.
We do. Show us where we don't and we will immediately change it.
> Didn't RTAI switch the copyright on "their" sourcebase to LGPL?
It's different. There is the RTHAL patch, which goes into the kernel. This
one is GPL, as well as the HRT schedulers.
All the infrastructure modules providing things like FIFOs, mailboxes,
tasklets and stuff are under the LGPL, meaning "give back when modifying
it, but be able to built something ontop of it which doesn't have to be
free".
Robert
น There are surely small things which cannot be implemented in
another way - try to write a counting loop in another way than
for (i=0; i<N; i++) {printf(i);}
Robert Schwebel
> Well, since you asked, how about you just go diff the include directories
> of the two source bases. That's a wonderful place to start. Anyone who
> spends 5 minutes in there will see that RTAI is derived from RTL.
Nobody has ever disputed that they have the same origin. And some of the
very obvious things are even so old that they have been there long before
RTL and RTAI came into existence, and some are like my "for" loop example.
> Here's some more, go contrast rt_task_make_periodic() in each of the
> source trees, pretty clearly RTL. In fact, the scheduler code is really
> easy to see that it's a ripoff.
Here are the license headers of the schedulers:
-----------8<----------
robert@callisto:~/embedded/rtai-24.1.9/upscheduler ! head -n 6 rtai_sched.c.ml
/*
COPYRIGHT (C) 2000 Paolo Mantegazza (mante...@aero.polimi.it)
This program is free software; you can redistribute it and/or modify
it under the terms of version 2 of the GNU General Public License as
published by the Free Software Foundation.
---------->8----------
robert@callisto:~/embedded/rtai-24.1.9/mupscheduler ! head -n 6
rtai_sched.c.ml
/*
COPYRIGHT (C) 2000 Paolo Mantegazza (mante...@aero.polimi.it)
This program is free software; you can redistribute it and/or modify
it under the terms of version 2 of the GNU General Public License as
published by the Free Software Foundation.
-----------8<----------
robert@callisto:~/embedded/rtai-24.1.9/smpscheduler ! head -n 6
rtai_sched.c.ml
/*
COPYRIGHT (C) 2000 Paolo Mantegazza (mante...@aero.polimi.it)
This program is free software; you can redistribute it and/or modify
it under the terms of version 2 of the GNU General Public License as
published by the Free Software Foundation.
---------->8----------
Where is your problem? I don't see anything else than pure GPL.
It's the same with the patches, which don't have a license file, but as
patches for an original GPLed kernel they are surely GPL as well.
> The COPYING file in the *current* RTAI release is illegal. You can't say
> "Well, there is some GPL stuff in here, but we're releasing under the
> LGPL"
Wrong. Some files in the distribution are derived from GPLed work, and they
are GPLed. Others are not, and they are LGPLed.
Robert
Pierre Cloutier
> On Sun, 26 May 2002, Robert Schwebel wrote:
> > application is _not_ implemented as a kernel module. I would really love
> > to do it this way, but unfortunately no one of the realtime programmers
> > has found a way how it can be achieved so far.
>
Hi:
Linus misses the most important feature of hard real time in user space.
RTAI deals with memory protection traps and terminates buggy code.
Linus must know that a bug in the kernel means trouble - trouble that may be,
just may be, fsck may not be able to deal with in the aftermath...
So the concept is simple. Develop the real time code in user space under
memory protection. When done move the stuff in the kernel (it is the same
API) if performance demands it, otherwise why bother!
As to the patent issues I do not care. The patent will not hold in a court of
law because there was prior knowledge. There are also filling timing issues...
I regret the FUD as it is advertising for the weak side of the force.
Best Regards,
Pierre Cloutier
Andrew Morton
>
> On Sat, May 25, 2002 at 12:41:07PM -0400, Karim Yaghmour wrote:
> > 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.
>
> That's also my experience:
>
> - I have been on all major automation trade shows in Germany for about 5
> years
>
> - I am the author of one of the two German books about Embedded Linux and
> of lots of articles about Linux for automation
>
> - I have organized the largest developer conference in Germany about "Linux
> for industrial applications"
>
> During all that activities I have talked to hundrets of people who are
> either already working with Linux or considering it's use. What Karim says
> here does exactly reflect the mood of the people.
>
Could you please tell us, just so it is really clear, what these people's
concerns are? What obstacles they see to using Linux in this industry?
-
Linus Torvalds
On Sat, 25 May 2002, Pierre Cloutier wrote:
>
> Linus misses the most important feature of hard real time in user space.
>
> [ Short answer: debuggability ]
I didn't miss it, but it hasn't come up, and I don't think it's actually
all that much an issue of "RTLinux vs RTAI", but simply an issue of "do
you have the same API in user land as in a module"?
Because if you have the same API, you can do non-RT development in user
land, and then just move it over once you know the basic code "works".
Since the API is bound to be fairly limited, that shouldn't be much of a
problem, but I have no idea what the actual development environments
offer, and I have ansolutely zero interest in trying on the RT
"straighjacket" myself ;)
Linus
Linus Torvalds
On Sat, 25 May 2002, Linus Torvalds wrote:
>
> Can we make the whole kernel truly hard-RT? Sure, possible in theory. In
> practice? No way, José. It's just not mainline enough.
Side note: we could, of course, mark some spinlocks (and thus some
code-paths) as being RT-safe, and then make sure that those spinlocks -
when they disable interrupts - actually disable the _hw_ interrupts even
with the RT patches.
That would make those sequences usable even from within a RT subset, but
would obviously mean that those spinlocks have to be checked for latency
issues - because any user (also non-RT ones) would obviously be truly
uninterruptible within these spinlocks.
Every single RT person out there is already painfully aware of (and used
to) having to limit the set of functions he can use while RT, so this is
something you guys tend to be pretty familiar with..
So the "hard-RT" thing doesn't need to be a complete on/off thing.
This kind of "limited kernel functionality" tends to help only RT kernel
modules, though. Full system calls (except the trivial ones like
"getpid()", of course) simply tend to have to require too much "real"
infrastructure that they can't use the RT subset.
Also, some people will he happy to know that soft-RT ends up getting
continually improved, and many people might be able to find that just the
regular preemptible kernel gives good enough latency at least if you can
limit the workload on the machine (which, on embedded devices tends to be
somethin gyou take for granted anyway).
That may not make the hard RT people happier, but at least it might shrink
the number of the die-hard hard RT'rs.
"If you can't beat them, try to make them extinct" ;)
Erik Andersen
> On Sat, May 25, 2002 at 10:22:00AM -0700, Linus Torvalds wrote:
> > So you split your problem into the RT device driver and the user. And of
> > story.
>
> Not possible with closed loop applications.
Indeed. For example -- suppose I have an application that is driving a
robot. My application needs to calculate the target values for
each joint position in such that I can plot out the jerk,
acceleration, velocity, and position in cartesian space of a tool
moving in joint space (i.e. lots of 4x4 matrix multiplications,
often involving a full 3D model of the workcell) And I need to
send each new set of target values to the controller at the servo
rate or the robot will stutter.
But if only it were that easy... Since the target values we are
talking about is actually just the amount of current being sent
to the servo motors. So also at the servo rate, I must read the
encoders for each joint to get its actual position (as opposed to
nominal postition) and feed that into a control routine
(typically using a PID routine using PID gains that vary
non-linearly per arm position, intertial loading, phase of the
moon, etc) which then varies the actual per-axis servo motor
current to make the cartesian-space path of the tool match the
nominal path.
So now we have a full 3D model of the robot, the non-liner model
of the robot PID-gain space, the entire (application specific)
workcell model, the robot specific forward and inverse kinematics
routines, and the entire trajectory planning subsystem. And of
course we now need the real-time IO subsystem to handle are the
thousands of this-and-that sensors (think PLC-type behavior).
etc, etc, etc. All this in the kernel? Nah...
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
Roman Zippel
On Sat, 25 May 2002, Linus Torvalds wrote:
> (and as pointed out by Larry, there seems to be
> some dubious issues about the RTAI copyright itself).
Linus, please don't blindly believe Larry, so far he pointed out
nothing. :-(
bye, Roman
Alan Cox
> 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 - I think you are out of order. If you are going to make serious
allegations like that then back them up with proof, and preferably on a
different mailing list.
Alan Cox
> 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.
And the work distributed is an OS kernel which includes copyright
material from Linus, you, and thousands of others. The GPL additional
restrictions clause is pretty clear. The examples covered in the GPL
even explicitly discuss patents and requirements to distribute GPL
licensed code in the presence of a patent.
Alan Cox
> A short time ago I made my living by programming large factory machines that
> can kill people in an instant. I would have loved to use Linux, but it was
> not ready at the time. As long as core developers continue to ignore the
> need for realtime capability in the kernel itself - as opposed to waving hands
This has nothing to do with real time. The capacity of computer science
to formally validate a system (and if it can kill people it should be
formally proven in something like Z) is not sufficient for a system so
complex. Such a device needs a tiny verifiable kernel core.
Andre Hedrick
> On Sat, 2002-05-25 at 21:29, Andre Hedrick wrote:
> > 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.
>
> And the work distributed is an OS kernel which includes copyright
> material from Linus, you, and thousands of others. The GPL additional
> restrictions clause is pretty clear. The examples covered in the GPL
> even explicitly discuss patents and requirements to distribute GPL
> licensed code in the presence of a patent.
Excellent and nice explaination of the facts, as you can express it clear
and exact without adding FUD :-)
Cheers,
Andre Hedrick
LAD Storage Consulting Group
David Schleef
> 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.
I was told this too. Being familiar with both RTAI internals and
(in the past) RTLinux internals, I found this statement to be
rather questonable. However, since I hadn't gone over _every line_
of the code, I couldn't be sure.
So I wrote a perl script that compares two entire source trees, and
looks to see which source lines are similar, ignoring whitespace,
punctuation, etc. It turned out to be surprisingly good at its
task -- I checked RTAI against other projects that I work on,
and it showed me all the segments of code that I copied between the
projects. I checked RTAI against itself, and it showed me that all
the examples are very similar. I checked RTAI against the kernel,
and it picked up matches between the patch files in the RTAI source
and the files that the patches patch in the kernel source.
I checked RTAI vs. RTLinux, and it turned up 2 things: an example
written by Jerry Epplin, and the implementation of rt_printk(),
which was written by me. Neither of these were "originally" in
RTLinux, they were both "originally" posted to the RTLinux mailing
list.
There was one more match that was publicly claimed as copying by
the maintainer of RTLinux -- a few fields in the scheduler structure.
The script caught those, too, once I set the threshhold down to 3
lines, which also picked up hundreds of mismatches. But strangely, I
found the same lines in an OS textbook dated 1987. I wonder who
copied whom.
[By the way, if someone reminds me, I'll make the script available
for download. It's quite useful.]
> 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?
No, it was never a fork. RTAI, in its DOS form, existed before
RTLinux.
> Second, that's what patents are all about, it's about protecting your
> investment.
Then why doesn't USENIX or New Mexico Tech own it? They were the
ones that paid for the development of RTLinux.
dave...
Larry McVoy
> On Sat, 2002-05-25 at 22:23, Larry McVoy wrote:
> > 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 - I think you are out of order. If you are going to make serious
> allegations like that then back them up with proof, and preferably on a
> different mailing list.
Sorry Alan, but they asked for it. All day long they have been saying
stuff that isn't true. "The RTAI core is now released under the GPL"
and then you go look and it says LGPL. And the claims that they respect
the GPL in the parts that came from RTL is crap, go look at the copyrights
they put on the files, files they didn't create, and it says LGPL, not GPL.
Go read the code and then see what you think. It's blatent. You either
haven't read the code or I just don't understand your position. It's
exactly like someone took a GPLed device driver, enhanced it, and then
decided that they could put their different and incompatible license on it.
Don't take my word for it, go read the code.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Oliver Xymoron
>
>
> On Sat, 25 May 2002, Linus Torvalds wrote:
> >
> > Can we make the whole kernel truly hard-RT? Sure, possible in theory. In
> > practice? No way, José. It's just not mainline enough.
>
> Side note: we could, of course, mark some spinlocks (and thus some
> code-paths) as being RT-safe, and then make sure that those spinlocks -
> when they disable interrupts - actually disable the _hw_ interrupts even
> with the RT patches.
>
> That would make those sequences usable even from within a RT subset, but
> would obviously mean that those spinlocks have to be checked for latency
> issues - because any user (also non-RT ones) would obviously be truly
> uninterruptible within these spinlocks.
I'm sure you know this route is not very useful - there's practically
nothing that we can push across the hard RT divide anyway. We can't do
meaningful filesystem I/O, memory allocation, networking, or VM fiddling -
what's left?
Cleaning up soft RT latencies will make the vast majority of people who
think they want hard RT happy anyway.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Larry McVoy
> I checked RTAI vs. RTLinux, and it turned up 2 things: an example
> written by Jerry Epplin, and the implementation of rt_printk(),
> which was written by me. Neither of these were "originally" in
> RTLinux, they were both "originally" posted to the RTLinux mailing
> list.
>
> There was one more match that was publicly claimed as copying by
> the maintainer of RTLinux -- a few fields in the scheduler structure.
> The script caught those, too, once I set the threshhold down to 3
> lines, which also picked up hundreds of mismatches.
Good luck making that stick in court. First of all, the RTAI guys have
admitted over and over that RTAI is a fork of the RTLinux source base.
Your claims that that isn't true are countered by principles from both
parties in question. Second of all, both source bases have evolved
since the fork. Whether your script catches the common heritage or
not has no meaning, the fact remains that one is derived from the
other, and as such has to be GPLed.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Larry McVoy
> On Sat, May 25, 2002 at 04:10:34PM -0700, Larry McVoy wrote:
> > Well, since you asked, how about you just go diff the include directories
> > of the two source bases. That's a wonderful place to start. Anyone who
> > spends 5 minutes in there will see that RTAI is derived from RTL.
>
> Nobody has ever disputed that they have the same origin.
Actually, people have, and in this thread.
> robert@callisto:~/embedded/rtai-24.1.9/upscheduler ! head -n 6 rtai_sched.c.ml
> /*
> COPYRIGHT (C) 2000 Paolo Mantegazza (mante...@aero.polimi.it)
>
> This program is free software; you can redistribute it and/or modify
> it under the terms of version 2 of the GNU General Public License as
> published by the Free Software Foundation.
>
> Where is your problem? I don't see anything else than pure GPL.
My first problem is that this is a partial sampling of the source base.
My second problem is that Paolo Mantegazza isn't the original author of
that file.
> > The COPYING file in the *current* RTAI release is illegal. You can't say
> > "Well, there is some GPL stuff in here, but we're releasing under the
> > LGPL"
>
> Wrong. Some files in the distribution are derived from GPLed work, and they
> are GPLed. Others are not, and they are LGPLed.
Well, I find it misleading. It makes it sound like you have rights to that
code that you don't and it makes it sound like it is LGPLed. How would you
feel if someone included your GPLed work in a package and put the LGPL in
the COPYING file? And slapped their copyrights on your work?
Larry McVoy
> > Good luck making that stick in court. First of all, the RTAI guys have
> > admitted over and over that RTAI is a fork of the RTLinux source base.
>
> hasn't. I understand why others talk about RTAI and RTLinux forking,
http://www.tux.org/pub/devel/LINUX-LAB/RTAPPS/paolo/myrtlinux-0.6.README
> I actually _do_ my research.
Me too. I've been here before, I was one of about 8 people who actually
knew that AT&T should have won the BSD lawsuit because I diffed the code.
And you can't diff it with a perl script, that simply doesn't work. The
only real ways that I know of are
a) have a human do it, function by function
b) compile the code to an expression tree and then diff the expression
trees.
Alexander Viro
On Sat, 25 May 2002, Larry McVoy wrote:
> Good luck making that stick in court. First of all, the RTAI guys have
> admitted over and over that RTAI is a fork of the RTLinux source base.
> Your claims that that isn't true are countered by principles from both
> parties in question. Second of all, both source bases have evolved
> since the fork. Whether your script catches the common heritage or
> not has no meaning, the fact remains that one is derived from the
> other, and as such has to be GPLed.
Larry, can it. 4.4BSD was derived from v6->v7->32V - nobody had ever
denied that. So was USG "codebase"<spit>. Didn't change the outcome
of lawsuit.
And for fuck sake, stop harping on "GPL is the only free license, anyone
who prefers something else wants to use code as revenue source" tune -
$DEITY witness, FSF wankers are more than enough. It was my impression
that unlike them you _do_ pretend to have some amount of intellectual honesty.
For the record - the only reason why I'm using GPL for kernel work is
the license on the rest of kernel. My preference for situations when
I get to choose is either BSD license (short one) or Artistic - _not_ GPV,
thank you very much. For very simple reasons - I don't care who uses
the code and don't think that forcing contributions works better than
letting people contribute if they want to do that.
If somebody chooses to use these "free for GPLed works" patents - fine,
but at least have a decency to admit that it's a bit more complex than
"if you want to make money on my work I want a part of it".
I don't give a damn for RT systems in general and RTLinux/RTAI in particular,
but I'm getting really sick and tired from the density of crap in this thread.
Folks, it stinks. On both sides.
Grrr... As if dealing with "product" of Sun-employed cretins was not enough
interactions with idiocy for one day...
David Schleef
> On Sat, May 25, 2002 at 07:09:13PM -0700, David Schleef wrote:
> > I checked RTAI vs. RTLinux, and it turned up 2 things: an example
> > written by Jerry Epplin, and the implementation of rt_printk(),
> > which was written by me. Neither of these were "originally" in
> > RTLinux, they were both "originally" posted to the RTLinux mailing
> > list.
> >
> > There was one more match that was publicly claimed as copying by
> > the maintainer of RTLinux -- a few fields in the scheduler structure.
> > The script caught those, too, once I set the threshhold down to 3
> > lines, which also picked up hundreds of mismatches.
>
> admitted over and over that RTAI is a fork of the RTLinux source base.
Paolo (the maintainer) hasn't. I (the second largest contributor)
hasn't. I understand why others talk about RTAI and RTLinux forking,
since the _projects_ forked, and the _ideas_ forked, but the _code_
was always separate. At some point, a person gives up trying to
argue the point, and just says "it forked". But when you get down
to brass tacks, there was no code fork, because there was never one
code base.
There was some sharing of code in the beginning, typically code that
was sent to the RTLinux mailing list by third parties. In that case,
the code was copyrighted by the individual. The fact that it later
showed up in RTLinux as "copyright VJY associates" does not change
the fact that Paolo got it from the original author.
> Your claims that that isn't true are countered by principles from both
> parties in question. Second of all, both source bases have evolved
> since the fork. Whether your script catches the common heritage or
> not has no meaning, the fact remains that one is derived from the
> other, and as such has to be GPLed.
Oh yeah -- I forgot to mention that I was talking about comparing
the original version of RTAI and the contemporary version of RTLinux.
I also checked a number of other combinations, including the last
version of RTLinux that Paolo says that he looked at, and recent
RTAI releases.
I'm not claiming that RTAI is 100% perfect with respect to licensing.
But I have spend many weeks in the past chasing down alleged
plagiarism problems, and I can't find any. So I'm relatively
certain.
I actually _do_ my research.
dave...
Larry McVoy
> > there is some GPL stuff in here, but we're releasing under the LGPL"
>
> second license, and yet other stuff onder a third license. Is that
> too difficult for you to understand?
That's all fine, but the RTAI COPYING file looks to me like a delibrate
attempt to mislead. I'm pretty sure that a court of law would see it the
same way. Add to that the the RTAI system is based in the RTL system,
which was obtained under the GPL, and that there are files which are
obviously derivative works with a LGPL license on them, and I think
you'd be squirming in front of judge with nowhere to run.
> Just for the record: you claimed there was "substantial parts of
> RT/Linux in the RTAI source"; when challenged to provide examples,
> you tried to evade several times; finally, you fell back to the "but
> it's derived from RTL", which nobody ever denied.
No, I suggested you go look for yourself, just as I did. It's called
giving you a chance to back down gracefully. You don't seem to want that
chance, OK, that's your call. Let's explain the facts of life. If you
start with a GPLed file and you enhance, bug fix, whatever, and the
resulting work is what is known as a "derived work", it's still *all*
GPLed. That's how the law works. That was the whole point of how the
GPL was written, it was designed to not let people like you change the
rules without the permission of all the people who had copyrights on
that work.
I don't have to show entire files being identical to make the point,
all I have to show is that the files are derived from GPLed versions
of the same code. Anyone with a brain would do what I did, go walk
the header files, find the common definitions, go look at the code that
implements those definitions, and know immediately it was derived work.
That's all it takes. That's enough. The law needs no more than that.
If you want to wiggle out from under the rules, you're going to need
what is known is a "clean room" reimplementation, wherein nobody who is
doing the work has ever seen the other code. Otherwise it is virtually
impossible to avoid the derived work problem, and the burden is on you,
the person trying to change the rules, that it is not a derived work.
The court would presume, in a case like this, that it was. You can
try and push that back on me all you want, but I'm not the one you need
to convince. You need to convince prospective customers that you have
clear rights to use what you are giving them, and in this case, that
looks virtually impossible. I know about this stuff, I run a software
business, I personally negotiate the contracts, and no company with
any legal staff whatsoever would enter into contract with a vendor that
is not willing to state and prove that they have rights to what they
are selling. That's contracts-101.
I get the feeling you want me to back down and go away. Go Google around
and you'll find that I just don't, not until you prove that I'm wrong.
In this case, the more I dig into it, the more convinced I am that the
RTAI crowd is trying to rewrite history and that does nothing but make me
more motivated to stick around and make sure people look at this closely.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Linus Torvalds
On Sat, 25 May 2002, Oliver Xymoron wrote:
>
> I'm sure you know this route is not very useful - there's practically
> nothing that we can push across the hard RT divide anyway. We can't do
> meaningful filesystem I/O, memory allocation, networking, or VM fiddling -
> what's left?
Atomic memory allocation, for one. Potentially very useful.
> Cleaning up soft RT latencies will make the vast majority of people who
> think they want hard RT happy anyway.
I certainly personally agree with you, but the hard-liners don't.
Remember: it took the hard-RT community a long time to accept radical new
things like CPU caches, and some of them _still_ like the ability to lock
down cachelines..
Linus
Larry McVoy
> > Good luck making that stick in court. First of all, the RTAI guys have
> > admitted over and over that RTAI is a fork of the RTLinux source base.
> > parties in question. Second of all, both source bases have evolved
> > since the fork. Whether your script catches the common heritage or
> > not has no meaning, the fact remains that one is derived from the
> > other, and as such has to be GPLed.
>
> denied that. So was USG "codebase"<spit>. Didn't change the outcome
> of lawsuit.
That's because of 2 reasons:
a) AT&T was apparently unfamilier with diff(1)
b) Bill Jolitz choose to keep his mouth shut so that 4BSD would get
freed up. And got publicly humilated for it and still held his
tongue.
Here's a clue: go diff bmap() in 4.x BSD and in 32V. Word for word, bit
for bit, comment for comment, identical when I did it. And I think anyone
can verify that, both versions of the code are out there now. And I also
think that you, Al, would agree that bmap() is a pretty profound part of
the file system. That AT&T let that one slip is mind boggling.
> If somebody chooses to use these "free for GPLed works" patents - fine,
> but at least have a decency to admit that it's a bit more complex than
> "if you want to make money on my work I want a part of it".
Huh? You lost me. For the record, I do think it's that simple. And in
personal conversations with Victor, he's indicated that it is that simple.
What else do you think is there? I'm missing some subtlety here, bang me
on the head with it.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
yoda...@fsmlabs.com
> I certainly personally agree with you, but the hard-liners don't.
> Remember: it took the hard-RT community a long time to accept radical new
> things like CPU caches, and some of them _still_ like the ability to lock
> down cachelines..
I recently heard a gentleman from Boeing Civil Aviation speak on how they
are considering what to do now that their stock of static memory, no-OO,
cacheless 68Ks are dwindling and their "tested to death tiny subset of ADA"
has no compiler vendors.
It's an interesting problem at least to some of us.
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com www.rtlinux.com
Robert Schwebel
> You could start by fixing the bug. Try "man 3 printf".
It's late and I didn't have much sleep over the last days. I think you got
the point.
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
People are doing this (or at least something similar) in reality these
days... :-)
Hopefully, your post shows clearly why there are users out there who don't
want to make such complex algorithms open source, and I must say I can
understand them.
Robert Schwebel
> Could you please tell us, just so it is really clear, what these people's
> concerns are? What obstacles they see to using Linux in this industry?
Uncertainty. The situation today is that they are using operating systems
like WindowsCE, VxWorks, QNX or other proprietary operating systems. The
problem is that if you use an operating system for the industry you need to
make sure that you can support your product (=hardware: motion controller
or whatever) for about 10 to 15 years. That's pretty different to the IT
industry! Note also that these applications are very different from IT
applications: they are in most cases not of general use, but only if you
have the special hardware.
This is the reason why _lots_ of people still use home brown solutions
based on DOS: they have the whole system under their control, nobody can
obsolete them the most significant part of their system.
Industry people like Linux because it gives them exactly the combination of
freedom (=control over the source) and modern technology they need (note
that ethernet as a fieldbus replacement is a very promising technology).
On the other hand, Linux still has a rest of the hacker image, at least to
the conservative automation people. When they hear that there is a patent
problem regarding to realtime they often see their central requirement
violated: longterm availability. Even the slightest sign of a potential
problem makes them often say: "Then we better stay with closed sorce,
because that's what we know."
We don't require much: most of what's _technicall_ necessary is already
there. We just want the same right that every Linux programmer has for it's
software: decide ourself about the license of our self made application.
Is tat too much?
Karim Yaghmour
Larry McVoy wrote:
> RTAI crowd is trying to rewrite history and that does nothing but make me
> more motivated to stick around and make sure people look at this closely.
Larry, you've missed the entire point here. You can dismiss the RTAI crowd
all you want, but you can't take away the fact that developers are choosing
not to use Linux in the embedded field because of serious intellectual
property issues regarding its real-time capabilities. This matter goes
far beyond RTAI and would still apply even if you were to write a new rt
micro-kernel for Linux from scratch without starting from either RTAI or
RTLinux. Nothing you have said until now changes this fact.
Karim
===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================
Alexander Viro
On Sat, 25 May 2002, Larry McVoy wrote:
> Here's a clue: go diff bmap() in 4.x BSD and in 32V. Word for word, bit
> for bit, comment for comment, identical when I did it. And I think anyone
> can verify that, both versions of the code are out there now. And I also
> think that you, Al, would agree that bmap() is a pretty profound part of
> the file system. That AT&T let that one slip is mind boggling.
You are tripping. bmap() is obviously different in 32V and 4.2BSD -
filesystems are different and yes, it _is_ a profound part of filesystem.
Hint: there is no fucking way you'll find realloccg() called in 32V
bmap() or defined anywhere in the first place. The only thing that
does match is use of function and fact that old and new filesystems
have similar data structure for indirect, etc. blocks. Notice that
it's similar, not identical - e.g. use of fragments in FFS changes
quite a few things.
What the hell are you smoking? Of all things that could be shared,
picking bmap() takes either something way stronger than dope or
complete lack of clue on the things aforementioned function is
supposed to do.
> > If somebody chooses to use these "free for GPLed works" patents - fine,
> > but at least have a decency to admit that it's a bit more complex than
> > "if you want to make money on my work I want a part of it".
>
> Huh? You lost me. For the record, I do think it's that simple. And in
> personal conversations with Victor, he's indicated that it is that simple.
> What else do you think is there? I'm missing some subtlety here, bang me
> on the head with it.
Simple: $FOO prefers to put his code under free license other than GPL.
And does that without any plans to make money out of it. For any
number of reasons. $BAR has "GPL or pay" patent. Well, too fscking
bad, $FOO can't do what he wants to. Nothing to do, should've researched
the situation better and yes, life is tough. OK so far?
Now comes GPL advocate and says that the only reason why $FOO would
get in trouble here was (obviously) that he wanted to make money and
didn't want to share. Which is demonstrably false.
Now, whether I have a problem with $BAR or not is a separate story.
What I _do_ have a problem with, though, is GPL advocate and his, er,
judgement. Still sounds too subtle?
Frankly, I can see very few possible reasons:
* you are on a serious trip
* you really don't know about free licenses other than GPL.
* you are pulling ESR and expecting that reference to a
holy cow (in this case "free == GPL" crap) will help.
Again, I don't fscking care for RT-anything. I'm not too fond of
software patents of any nature, to put it mildly, but that's a
separate story. What _really_ pisses me off is a sight of apparently
clued guy using this sort of rethorics and pretending that non-GPL ==
commercial.
Robert Schwebel
> My first problem is that this is a partial sampling of the source base.
> My second problem is that Paolo Mantegazza isn't the original author of
> that file.
We'll discuss that on the RTAI mailing list.
> Well, I find it misleading. It makes it sound like you have rights to that
> code that you don't and it makes it sound like it is LGPLed.
You are right, and be sure we'll do our best to clarify the situation as
good as possible. Take into account that the license change took place just
recently and there are surely things left which have to be cleaned up. It
is common agreement between the RTAI team that patches and schedulers are
GPL, self-developed services are LGPL.
Sidenote: before the 24.1.9 release we publically asked on the RTAI mailing
list if we have missed somebody in the "authors" file:
http://www.realtimelinux.org/archives/rtai/20024/0066.html
Nobody has spoken up who is not listed there so far.
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 |
+--------------------------------------------------------+
Erik Andersen
> On Sat, May 25, 2002 at 06:48:53PM -0600, Erik Andersen wrote:
> > So now we have a full 3D model of the robot, the non-liner model
> > of the robot PID-gain space, the entire (application specific)
> > workcell model, the robot specific forward and inverse kinematics
> > routines, and the entire trajectory planning subsystem. And of
> > course we now need the real-time IO subsystem to handle are the
> > thousands of this-and-that sensors (think PLC-type behavior).
> > etc, etc, etc. All this in the kernel? Nah...
>
> People are doing this (or at least something similar) in reality these
> days... :-)
Oh I know they are. I was doing all of this stuff while in grad
school back in 1996, and later at my first job I was doing this
stuff too. Had to use LynxOS back then. Would have been nice if
we could have used Linux... I was watching RTLinux closely back
then -- long before the patent problem. :)
> Hopefully, your post shows clearly why there are users out there who don't
> want to make such complex algorithms open source, and I must say I can
> understand them.
That was the hope. So people would understand that this isn't
the type of application where you can just squirrel away the
real-time bits in a device driver... Its got to be the whole
thing,
-Erik
--
Erik B. Andersen http://codepoet-consulting.com/
--This message was written using 73% post-consumer electrons--
David Woodhouse
l...@bitmover.com said:
> 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?
It's been asserted that the patent licence requires that _all_ userspace
apps running on the system by GPL'd. Yet there are many Free Software
applications in a standard Linux distribution that are under
GPL-incompatible licences. Apache, xinetd, etc...
If that interpretation is true, it _would_ be a problem, and not just for
those trying to make money from it.
--
dwmw2
Roman Zippel
On Sun, 26 May 2002, David Woodhouse 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?
>
> It's been asserted that the patent licence requires that _all_ userspace
> apps running on the system by GPL'd. Yet there are many Free Software
> applications in a standard Linux distribution that are under
> GPL-incompatible licences. Apache, xinetd, etc...
>
> If that interpretation is true, it _would_ be a problem, and not just for
> those trying to make money from it.
It is a possible interpretation. The problem is that there is very broad
patent, a very vague patent licence and patent owner, who refuses to
answer the most simple questions. :-(
bye, Roman