patent on O_ATOMICLOOKUP [Re: [PATCH] loopable tmpfs (2.4.17)]
Andrea Arcangeli
On Fri, May 24, 2002 at 11:03:25AM -0700, Dan Kegel wrote:
> software patent on Tux... http://lwn.net/daily/
I'm more lucky than most of you because the original article is in
Italian so I can understand all the details. btw, I noticed the italian
linux community is very aware and responsive (we even had a law proposal
to help the free software IIRC).
Just for reference I attached the 13 line long patch in -aa that is
being requested to be put under this patent:
http://l2.espacenet.com/espacenet/viewer?PN=WO0217597&CY=ep&LG=en&DB=EPD
the code is available also from here:
ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/kernels/v2.4/2.4.19pre8aa4/60_atomic-lookup-5
and in the tux patches at www.redhat.com/~mingo/ that I merged in my
tree and that are shipped with various vendor kernels.
Now dropping this feature from tux is a matter of a few hours and it
cannot make difference if your vfs working set fits in dcache, but
that's not the problem. I wonder what's next, should I apply for a
patent for the classzone algorithm in the memory balancing or is Ingo
going to patent the O1 scheduler too? Ingo, Alan, Arjan, DaveM are so much
worried about binary only modules, Alan even speaks about the DMCA all
over the place, this is an order of magnitude worse, this even forbids
you to use this tequnique despite you may invented it too from scratch
and it's your own idea too. To make the opposite example despite IBM is
a big patent producer IBM even allowed the usage of their RCU patents in
the linux kernel (I've the paperwork under my desk and Linus should have
received too), and other stuff donated to gcc and probably much more
that I don't know about, IMHO exactly to avoid linux to be castrated by
patents. So this news is totally stunning from my part.
I think it is in the interest of the US gov to do something to avoid
these three patents to pass and hurt the linux developement. I think
this is a breakpoint and they cannot ignore those issues at this point.
If they act now, they will stop the problem at its root and we don't
risk a fragmentation. Until it was only rtlinux to be patented that is
never been a showstopper because real time apps are a niche market and
they're not mainstream but the O_ATOMICLOOKUP API is even exported to
userspace! (for all the wrong reasons btw, because that's not yet part
of mainline for some unknown reason but if mainline collides on some
number I will notice in a jiffy and the collision could be resolved so
it's a minor problem compared to the patent) Even Ingo said once a few
years back to l-k that somebody should do something to at least avoid
the application of patentes to linux (I can search and forward you the
email if you're curious) and I certainly agreed with that opinion.
I can probably do nothing more than to write this email just to give
more awareness about the technical parts of the problem, so not really
much, but at least if the thing passes I felt I did all I could to try
to avoid it.
I would also suggest to apply the below patch to mainline (if something
to avoid collisions on the O_ flag #defines that as said is a minor
problem after all).
diff -urN 2.4.15pre1/fs/namei.c atomic-lookup/fs/namei.c
--- 2.4.15pre1/fs/namei.c Wed Oct 24 08:04:22 2001
+++ atomic-lookup/fs/namei.c Fri Nov 9 04:34:12 2001
@@ -448,9 +448,13 @@
{
struct dentry *dentry;
struct inode *inode;
- int err;
+ int err, atomic;
unsigned int lookup_flags = nd->flags;
+ atomic = 0;
+ if (lookup_flags & LOOKUP_ATOMIC)
+ atomic = 1;
+
while (*name=='/')
name++;
if (!*name)
@@ -519,6 +523,9 @@
/* This does the actual lookups.. */
dentry = cached_lookup(nd->dentry, &this, LOOKUP_CONTINUE);
if (!dentry) {
+ err = -EWOULDBLOCKIO;
+ if (atomic)
+ break;
dentry = real_lookup(nd->dentry, &this, LOOKUP_CONTINUE);
err = PTR_ERR(dentry);
if (IS_ERR(dentry))
@@ -582,6 +589,9 @@
}
dentry = cached_lookup(nd->dentry, &this, 0);
if (!dentry) {
+ err = -EWOULDBLOCKIO;
+ if (atomic)
+ break;
dentry = real_lookup(nd->dentry, &this, 0);
err = PTR_ERR(dentry);
if (IS_ERR(dentry))
@@ -924,6 +934,8 @@
if (f & O_DIRECTORY)
retval |= LOOKUP_DIRECTORY;
+ if (f & O_ATOMICLOOKUP)
+ retval |= LOOKUP_ATOMIC;
return retval;
}
diff -urN 2.4.15pre1/include/asm-alpha/fcntl.h atomic-lookup/include/asm-alpha/fcntl.h
--- 2.4.15pre1/include/asm-alpha/fcntl.h Sun Sep 23 21:11:40 2001
+++ atomic-lookup/include/asm-alpha/fcntl.h Fri Nov 9 04:34:12 2001
@@ -20,6 +20,7 @@
#define O_DIRECTORY 0100000 /* must be a directory */
#define O_NOFOLLOW 0200000 /* don't follow links */
#define O_LARGEFILE 0400000 /* will be set by the kernel on every open */
+#define O_ATOMICLOOKUP 01000000 /* do atomic file lookup */
#define O_DIRECT 02000000 /* direct disk access - should check with OSF/1 */
#define F_DUPFD 0 /* dup */
diff -urN 2.4.15pre1/include/asm-i386/fcntl.h atomic-lookup/include/asm-i386/fcntl.h
--- 2.4.15pre1/include/asm-i386/fcntl.h Sun Sep 23 21:11:40 2001
+++ atomic-lookup/include/asm-i386/fcntl.h Fri Nov 9 04:34:12 2001
@@ -20,6 +20,7 @@
#define O_LARGEFILE 0100000
#define O_DIRECTORY 0200000 /* must be a directory */
#define O_NOFOLLOW 0400000 /* don't follow links */
+#define O_ATOMICLOOKUP 01000000 /* do atomic file lookup */
#define F_DUPFD 0 /* dup */
#define F_GETFD 1 /* get close_on_exec */
diff -urN 2.4.15pre1/include/asm-ia64/fcntl.h atomic-lookup/include/asm-ia64/fcntl.h
--- 2.4.15pre1/include/asm-ia64/fcntl.h Thu Nov 16 15:37:42 2000
+++ atomic-lookup/include/asm-ia64/fcntl.h Fri Nov 9 04:34:12 2001
@@ -28,6 +28,7 @@
#define O_LARGEFILE 0100000
#define O_DIRECTORY 0200000 /* must be a directory */
#define O_NOFOLLOW 0400000 /* don't follow links */
+#define O_ATOMICLOOKUP 01000000 /* do atomic file lookup */
#define F_DUPFD 0 /* dup */
#define F_GETFD 1 /* get close_on_exec */
diff -urN 2.4.15pre1/include/asm-ppc/fcntl.h atomic-lookup/include/asm-ppc/fcntl.h
--- 2.4.15pre1/include/asm-ppc/fcntl.h Tue Nov 6 02:04:53 2001
+++ atomic-lookup/include/asm-ppc/fcntl.h Fri Nov 9 04:34:42 2001
@@ -23,6 +23,7 @@
#define O_NOFOLLOW 0100000 /* don't follow links */
#define O_LARGEFILE 0200000
#define O_DIRECT 0400000 /* direct disk access hint */
+#define O_ATOMICLOOKUP 01000000 /* do atomic file lookup */
#define F_DUPFD 0 /* dup */
#define F_GETFD 1 /* get close_on_exec */
diff -urN 2.4.15pre1/include/asm-sparc/fcntl.h atomic-lookup/include/asm-sparc/fcntl.h
--- 2.4.15pre1/include/asm-sparc/fcntl.h Sun Sep 23 21:11:42 2001
+++ atomic-lookup/include/asm-sparc/fcntl.h Fri Nov 9 04:34:12 2001
@@ -20,6 +20,7 @@
#define O_DIRECTORY 0x10000 /* must be a directory */
#define O_NOFOLLOW 0x20000 /* don't follow links */
#define O_LARGEFILE 0x40000
+#define O_ATOMICLOOKUP 0x80000 /* do atomic file lookup */
#define O_DIRECT 0x100000 /* direct disk access hint */
#define F_DUPFD 0 /* dup */
diff -urN 2.4.15pre1/include/asm-sparc64/fcntl.h atomic-lookup/include/asm-sparc64/fcntl.h
--- 2.4.15pre1/include/asm-sparc64/fcntl.h Sun Sep 23 21:11:42 2001
+++ atomic-lookup/include/asm-sparc64/fcntl.h Fri Nov 9 04:34:12 2001
@@ -20,6 +20,7 @@
#define O_DIRECTORY 0x10000 /* must be a directory */
#define O_NOFOLLOW 0x20000 /* don't follow links */
#define O_LARGEFILE 0x40000
+#define O_ATOMICLOOKUP 0x80000 /* do atomic file lookup */
#define O_DIRECT 0x100000 /* direct disk access hint */
diff -urN 2.4.15pre1/include/linux/errno.h atomic-lookup/include/linux/errno.h
--- 2.4.15pre1/include/linux/errno.h Fri Aug 17 05:02:27 2001
+++ atomic-lookup/include/linux/errno.h Fri Nov 9 04:34:12 2001
@@ -21,6 +21,9 @@
#define EBADTYPE 527 /* Type not supported by server */
#define EJUKEBOX 528 /* Request initiated, but will not complete before timeout */
+/* Defined for TUX async IO */
+#define EWOULDBLOCKIO 530 /* Would block due to block-IO */
+
#endif
#endif
diff -urN 2.4.15pre1/include/linux/fs.h atomic-lookup/include/linux/fs.h
--- 2.4.15pre1/include/linux/fs.h Tue Nov 6 02:04:53 2001
+++ atomic-lookup/include/linux/fs.h Fri Nov 9 04:34:12 2001
@@ -1260,6 +1260,7 @@
#define LOOKUP_POSITIVE (8)
#define LOOKUP_PARENT (16)
#define LOOKUP_NOALT (32)
+#define LOOKUP_ATOMIC (64)
/*
* Type of the last component on LOOKUP_PARENT
*/
Andrea
-
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/
Anton Altaparmakov
Hi,
At 21:26 24/05/02, Andrea Arcangeli wrote:
>[ speaking for myself in this whole email, and CC'ed l-k ]
>
>On Fri, May 24, 2002 at 11:03:25AM -0700, Dan Kegel wrote:
> > software patent on Tux... http://lwn.net/daily/
This patent was filed on August 22, 2001. If this is after the code came
into public existence this would constitute prior art and hence invalidate
the patent... Of course I have no idea when the code you pointed out was
released...
In either case, software patents are not allowed in the European Union
(yet), so we would just need to have an european kernel... (-;
Best regards,
Anton
--
"I've not lost my mind. It's backed up on tape somewhere." - Unknown
--
Anton Altaparmakov <aia21 at cantab.net> (replace at with @)
Linux NTFS Maintainer / IRC: #ntfs on irc.openprojects.net
WWW: http://linux-ntfs.sf.net/ & http://www-stu.christs.cam.ac.uk/~aia21/
Karim Yaghmour
Just wanting to put the record straight here about the rtlinux patent.
Andrea Arcangeli wrote:
> risk a fragmentation. Until it was only rtlinux to be patented that is
> never been a showstopper because real time apps are a niche market and
> they're not mainstream
I've been involved in fighting this patent for the last 2 years. During
this time, I have met and talked with many people about this issue. Today,
I can assure you that the rtlinux patent is definitely a show-stopper for
Linux.
As it stands now, Linux will never be a viable embedded OS until someone
gets rid of the rtlinux patent. As a matter of fact, many people in the
industry decide to go with WinCE precisely because of the rtlinux patent.
Many in the real-time Linux community are very worried by the fact that
the kernel developers do indeed see real-time as a niche market because
the members of the real-time Linux community see the damage being done to
Linux's penetration in the embedded field because of the patent.
As the latest VDC report indicates
(http://www.linuxdevices.com/articles/AT6328992055.html), the no. 1
factor inhibiting Linux's adoption as an embedded OS is indeed real-time.
It is no wonder that the established embedded vendors (WindRiver, QNX,
etc.) feel no threat from Linux. They know that every time Linux will
be evaluated, it will be put aside because of the patent.
Given that the embedded field is poised to overtake the desktop and the
server in terms of number of devices deployed, it would seem to me
that this is much more than just a niche market.
Until the rtlinux patent is dismissed, Linux will remain on the fringes
of the real-time and embedded application field. Unfortunately.
Karim
===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================
Linus Torvalds
On Fri, 24 May 2002, Karim Yaghmour wrote:
>
> I've been involved in fighting this patent for the last 2 years. During
> this time, I have met and talked with many people about this issue. Today,
> I can assure you that the rtlinux patent is definitely a show-stopper for
> Linux.
_Why_?
That patent is expressly licensed for GPL'd kernels, ie Linux.
It might be an issue with some other OS, but not Linux.
See "http://www.fsmlabs.com/about/patent/openpatentlicense.htm".
I've heard a lot of discussions about ho this kind of "license to Open
Source software" kinds of patents have long been discussed as ways to
subvert the patent system the same way that the copyleft itself subverts
the copyrights.
Even the FSF supports this particular patent (they used to have some
issues about the patent license being revocable, but now you have the
patent license "as long as the licensee compiles with this license and the
terms of the GPL".
[ Actually, the FSF is slightly unhappy about the fact that that patent
license expressly picks out GPL v2, the same way the _kernel_ explicitly
mentions that only v2 of the GPL is the default. Victor, like me, does
not trust the FSF to remain faithful to its original licenses. ]
In short, it you start playing fast and lose with the GPL, you lose the
patent rights too. Too bad. But if you stay true, that license is yours,
for free. Exactly like the GPL requires.
Linus
Alexander Viro
On Fri, 24 May 2002, Andrea Arcangeli wrote:
> Now dropping this feature from tux is a matter of a few hours and it
> cannot make difference if your vfs working set fits in dcache, but
> that's not the problem. I wonder what's next, should I apply for a
> patent for the classzone algorithm in the memory balancing or is Ingo
> going to patent the O1 scheduler too? Ingo, Alan, Arjan, DaveM are so much
> worried about binary only modules, Alan even speaks about the DMCA all
> over the place, this is an order of magnitude worse, this even forbids
> you to use this tequnique despite you may invented it too from scratch
> and it's your own idea too. To make the opposite example despite IBM is
> a big patent producer IBM even allowed the usage of their RCU patents in
> the linux kernel (I've the paperwork under my desk and Linus should have
> received too), and other stuff donated to gcc and probably much more
> that I don't know about, IMHO exactly to avoid linux to be castrated by
> patents. So this news is totally stunning from my part.
For once I have to agree with Andrea. Software patents do not
magically become better if you allow GPLed software to make use of them.
It's one thing to put your _code_ under whatever license you like. That
defines what you consider acceptable use and what - inexcusable plagiarism.
"Using what I'd learnt from your work" and "lending the book I've
bought to a friend" are equally old and respectable things. Hell, the former
might very well be older, for all we know. Both may be inconvenient to, ahem,
producers of intellectual property. It doesn't make attempts to limit them
morally acceptable.
Don't get me wrong - I despise the "let's abolish IP rights" crowd.
Plagiarism is Wrong and author has absolute right to choose the conditions
for use of the things he'd written. However, there is a line between "you
are using my code" and "you had learnt something from my code".
Patenting crosses that line - it puts restriction on the way one
could use the things he'd learnt from your code. Yes, mere putting your
code under GPL doesn't stop somebody from using the results of your efforts
in the ways you don't approve - he still can learn from your work and use
what he'd learnt in a work of his own. Yes, I can see the attraction of
prohibiting that. Just as I can see the attraction of bribery that had
created DMCA - with fairly close motivations behind it.
Both DMCA and software patents may be legal, but that doesn't make
use of either of them morally acceptable from my point of view. YMMV. It's
sad to see Ingo pulling that crap - I believe that he has reasons that sound
good to him, but... reasons don't make results smell any sweeter.
I've heard an excuse for playing these games (not from Ingo, so I have
no idea whether it has any relation to this case). It goes along the lines
"commercial companies are doing that anyway and that poses a threat; having
patents of our own gives ammo for defence against that threat". That sounds
nice, but... there's an old saying - "don't play games with the devil". It's
not that you can't win - devil is a piss-poor player. But those who do win
tend to find the rules suddenly changed under them. And then there are
bystanders caught in crossfire...
Andreas Dilger
> Just wanting to put the record straight here about the rtlinux patent.
IANAL or an embedded software expert, but...
> I've been involved in fighting this patent for the last 2 years. During
> this time, I have met and talked with many people about this issue. Today,
> I can assure you that the rtlinux patent is definitely a show-stopper for
> Linux.
>
> It is no wonder that the established embedded vendors (WindRiver, QNX,
> etc.) feel no threat from Linux. They know that every time Linux will
> be evaluated, it will be put aside because of the patent.
What, so there are _no_ patents or other restrictions on any of the
commercial embedded OS vendor products? I would imagine that you need
to pay some sort of license fee to those vendors in order to use their
code for products you sell.
I imagine that the rtlinux patent is also available for license, and
will only have a small per-usage fee <= other commercial license fees.
If not then the patent holder is foolish and there is no point in having
the patent in the first place.
Cheers, Andreas
PS - I'm not in favour of patents for Linux at all, but saying "you
can't use rtlinux because of the patent" doesn't make sense.
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.
--
Andreas Dilger
http://www-mddsp.enel.ucalgary.ca/People/adilger/
http://sourceforge.net/projects/ext2resize/
Alan Cox
> commercial embedded OS vendor products? I would imagine that you need
> to pay some sort of license fee to those vendors in order to use their
> code for products you sell.
Thousands of them. Some of them like the Siemens power management patent
really hurt Linux too.
> 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.
It means you have to file the patent first, which is a pain. The whole
Software patent thing is a huge disaster and one they are lobbying very
hard to push into europe and via the backdoors of unaccountable
undemocratic bodies like the WTO. They have to, otherwise the demise of
the USA as a viable economy rapidly accelerates because its only the US
afflicted by this mess.
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.
I'd suggest Andrea does something else. Ask the Red Hat people for a formal
confirmation he can use it, just like IBM with RCU. I have this funny feeling
that he'll get an extremely positive response.
Alan
Alan Cox
> being requested to be put under this patent:
In the USA it probably is covered by that patent yes
> Now dropping this feature from tux is a matter of a few hours and it
> cannot make difference if your vfs working set fits in dcache, but
> that's not the problem. I wonder what's next, should I apply for a
> patent for the classzone algorithm in the memory balancing or is Ingo
> going to patent the O1 scheduler too? Ingo, Alan, Arjan, DaveM are so much
> worried about binary only modules, Alan even speaks about the DMCA all
> over the place, this is an order of magnitude worse, this even forbids
> you to use this tequnique despite you may invented it too from scratch
> and it's your own idea too. To make the opposite example despite IBM is
The DMCA also forbids you from using both content and ideas of your own.
If you had a clever idea about disabled access to an ebook its jail. Patents
are bad but don't trivialise the other stuff.
> a big patent producer IBM even allowed the usage of their RCU patents in
> the linux kernel (I've the paperwork under my desk and Linus should have
> received too), and other stuff donated to gcc and probably much more
> that I don't know about, IMHO exactly to avoid linux to be castrated by
> patents. So this news is totally stunning from my part.
So mail the Red Hat legal people and ask them to land similar paperwork
under your desk if you feel you need it (remember the GPL on 'no additional
restrictions' . Lots of people are following this kind of path - RTLinux may
have been first but lots of stuff like QV30 have followed similar "GPL ok"
type paths.
Like it or not patents owned and controlled by the free software community
are a neccessary thing in the short term. Yes software patents need reform,
and their addition to patent law avoiding in most of the world. Code is
speech, imagine being able to patent a book plot, or suing George Bush
because you had a patent on pro war rhetoric ?
Alan
Alexander Viro
On Fri, 24 May 2002, Alan Cox wrote:
> Like it or not patents owned and controlled by the free software community
> are a neccessary thing in the short term. Yes software patents need reform,
> and their addition to patent law avoiding in most of the world. Code is
> speech, imagine being able to patent a book plot, or suing George Bush
> because you had a patent on pro war rhetoric ?
*LOTS* of prior art on that one.
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
===================================================
Andreas Dilger
> > What, so there are _no_ patents or other restrictions on any of then
> > commercial embedded OS vendor products?
>
> 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/
-
Larry McVoy
> This matter remained unchanged until the FSF came out later and
> declared publicly that the patent was violating the GPL. At that
> time, Eben Moglen came out and publicly explained the implications
> of the patent and the "corrected" patent license. Here is Eben's
> explanation:
> http://www.aero.polimi.it/~rtai/documentation/articles/moglen.html
Eben Moglen is the lawyer for the FSF, right? So he's hardly objective
about this topic, right? Isn't his point to try and get everything to
be GPLed?
> All would have been fine if things had ended there, but Victor then
> came out and threw more uncertainty about the matter:
> http://linuxdevices.com/articles/AT6164867514.html
>
> Just when Eben Moglen was saying that real-time applications were
> not subject to the patent, Victor Yodaiken came out and said:
> "If you want to make, use, sell, distribute, import,
> etc. non-GPL software -- regardless of whether such software is labeled as
> an "application," "module," or anything else -- please make sure you have
> obtained competent legal advice regarding whether your software and its use
> is an approved use under the Open RTLinux Patent License or whether a
> license under the RTLinux patent must be secured to authorize your software
> and its use."
So? Eben is not objective on the topic, FSMlabs holds the patents, if you
listen to what Eben says, that's meaningless. He is not a judge, he is not
objective, he's got a particular ax to grind. That's fine, except for one
thing: he doesn't hold the patent. So if you are going to listen to anyone,
I'd be listening to FSMlabs.
> At this point in time, all the bleeding-edge development being
> done in RTLinux is not available in GPL and must be purchased for
> a fee.
>
> This isn't really a problem, since RTAI has now surpassed RTLinux
> in terms of capabilities, ports and support. The problem, however,
> is that the rtlinux patent is being used to wage an FUD campaign
> against RTAI.
Doesn't the RTAI
a) make use of the patent and
b) allow for parts that aren't GPLed?
> One last thing: Clearly, if non-GPL applications were not allowed
> with Linux, we wouldn't be talking today. The same holds for non-GPL
> RT apps.
Ahh, I get it. I think I see the problem. You are applying GPL rules
to the RTLinux patent. You're saying that the boundary where the patent
applies stops at the same place as the boundary where the GPL stops.
I'll bet that is the cause of all the confusion. The patent and the
GPL have no correlation. It's completely up to FSMlabs to define what
is an application and what is not. And it's a very reasonable thing
for them to consider everything which runs on top of the RTLinux substrate
to be required to be covered by the GPL. That's certainly within their
rights. You can't take the GPL rules and impose that on his patent
license, the two have nothing to do with each other. He who holds
the patent makes the rules.
I think the bottom line is that the RT idea that Victor came up with is
pretty cool, it is obviously something that you want, and so you get to
live with those rules. Listening to a lawyer's opinion, when that
lawyer works for the FSF and is charged with furthering the cause of
the FSF, that's just asking for trouble. He isn't going to give you
an unbiased view. I think Victor's suggestion is good - if you want to
know what the rules are, consult your own lawyer.
As someone who's been down this path pretty extensively, I do not think
that you are seeing it clearly, you are mixing the patent and the GPL
and you are not entitled to do that. FSMlabs has to play by the GPL
rules for any modifications they make to the kernel, but you have to
play by their rules if you use their patent. You can't apply the GPL
rules and expect those to override the patent rules, it doesn't work
like that.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
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
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.
>
> Side note: they did this, apparently while Caldera was in the process of
> suing FSMlabs over the fact that they didn't want to pay for their
> OpenUnix usage... Hmm..
Speaking of suing, did you know that FSMLabs filed suit against Lineo
in the federal court of Delaware last June. Lineo's licensing of FSMLabs
"technology" only came after that.
> > I could have understood that this was indeed genuine, but here we
> > have Eben Moglen, a respected lawyer,
>
> I would be a _lot_ happier with Moglen if he didn't have so many ties to
> the FSF, and being biased. These days you can apparently buy a "gpl
> compliance certification" from the FSF for $20k. Those kinds of ties do
> _not_ make me any happier about the FSF's status as an independent entity.
Aside from your personal opinion about the FSF and Moglen, I find it
unfortunate that you don't take the time to investigate this a little
bit further on your own before dismissing it altogether.
> The RT part of an app under RTLinux has to be a kernel module anyway,
This is incorrect, see below.
> and as I personally consider the GPL to be the only kind of module I care
> about, I think that is good.
First:
There's another real-time extension for Linux called RTAI that is unrelated
to RTLinux.
Second:
I said in my previous email that RTAI provides a facility to enable user-space
processes to become hard-real-time tasks using a single system call. There
are no modules involved in this. You start the RT process exactly as you
would start another process on the command line and it enters hard-real-time
mode using the call I mentionned earlier.
Here's an example:
int main(int argc, char *argv[])
{
...
mlockall(MCL_CURRENT | MCL_FUTURE);
if (!(hrttsk = rt_task_init(hrttsk_name, 1, 0, 0))) {
printf("CANNOT INIT MASTER TASK\n");
exit(3);
}
if (oneshot) rt_set_oneshot_mode();
else rt_set_periodic_mode();
period = (int) nano2count((RTIME)periodns);
start_rt_timer(period);
if (uspsh) rt_usp_signal_handler(handler);
if (softhard) {
rt_make_hard_real_time();
}
rt_task_make_periodic(hrttsk, rt_get_time() + period, period);
...
}
Starting from the call to rt_mak_hard_real_time() this Linux _process_
has now become a hard-real-time task scheduled by RTAI.
Mind you, all of this is in __USER-SPACE__. There are no modules involved.
Yet, even though this is entirely done in user-space, this isn't allowed
by the patent.
> Whatever non-RT tools used to visualize the RT data equally clearly aren't
> covered by _that_ particular patent, so I think the whole thing is a
> complete and utter red herring.
I'm sorry, but I'm missing the point here about visualization tools.
Such tools are not part of any of the real-time Linux community's
concerns.
That said, if you feel better seing this as a red herring, then feel
free to do so. Real-time developers who actually have to choose a real
OS for their application, however, are seing Linux as the red herring.
And as long as you continue to ignore this problem, they will continue
to choose other OSes over Linux.
I don't like to be saying any of this, but this is exactly what is
happening every day in the field.
Karim
===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================
Linus Torvalds
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, 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
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
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 ]
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
===================================================
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
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 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
> 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
--
+--------------------------------------------------------+
| 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
> 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.
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
> 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
> 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.
Being one of the RTAI developers, I can strongly support what Karim says
here. In the begining everyone tried to help with RT-Linux, as people have
been used to in the Linux community. But it quickly turned out that
FSM-Labs is not interested in contributions; whole ports of RT-Linux
disappeared magicaly after being sent in (ask Wolfgang Denk about some
PowerPC stuff). Nobody knows how much of the stuff went into the closed
source version of RTL. That's simply not what developers were used to, so
everybody switched over to RTAI, where people are working together and
respecting each other.
> 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.
People from the industry are really, really interested in using Linux for
their realtime applications, but if you tell them about the patent
situation they just use another OS. Not because one could not find a
legally correct solution for them, but simply because of the FUD.
To understand the situation it is important do realize that in the realtime
world simple _applications_ must be _implemented_ as modules (not taking
LXRT into account here).
Here's how a typical realtime application (a motor controller) looks like:
------------------------------------------------------------
| Controlling Application: sets parameters, communication | (1)
| over ethernet, fieldbusses, webserver, ... (user space) |
------------------------------------------------------------
|
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Application: for example a special controlling algorithm + (2)
+ +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| |
=================== ===================
| Driver for the | | Driver for | (3)
| A/D Converter | | an actuator |
=================== ===================
| |
------------------- -------------------
| A/D Converter | | D/A Converter | (4)
------------------- -------------------
| |
------------------- -------------------
| Position Sensor | | Actuator (Motor)| (5)
------------------- -------------------
In this scheme layers (2) and (3) must fulfill realtime requirements. If
this would be a non-realtime application you would simply put (2) into user
space and make it a normal process. Unfortunately, with RTAI/RTL you must
implement it as a module to get realtime performance (which is necessary,
because you have to calculate the output values from the input values in a
fixed timing scheme).
What we have in the "normal" Linux world is that the drivers (3) are
implemented as modules, and I perfectly agree with anyone who says that
_drivers_ should be GPL. I propose this for all of my customers, and until
now noone of them had an objection.
But with applications it is different: think of a motion controller
manufacturer: his IP is the controll algorithm, and he simply cannot make
it open source.
> 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.
This is what I said above: the application (2) from the realtime scenario
is the logical equivalient to normal user processes in vanilla Linux. So if
the situation would really be that non-GPL RT-applications are not allowed
then Linux is dead in the embedded world - people will simply not consider
to use it any more. It would be completely equivalent to forbiding closed
source user space applications on Linux.
Robert
PS: before anybody objects: like Karim I did not sell a single closed
source program so far. What we are talking about here is _acceptance_
of a technology in an application field, not about personal enrichment.
--
+--------------------------------------------------------+
| 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 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.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
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
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, 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.
Linus
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
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.."
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?
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
===================================================
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
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
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
===================================================
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 ...
Karim
===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================
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
> > single spinlock in the kernel assumes that the kernel isn't preempted,
> > which means that user apps that can preempt the kernel cannot use them.
> Blinders ehh... Well, if you would care to ask I would answer.
> In reality, what you point out is actually a non-issue since the hard-rt
> user-land tasks are not allowed to call on normal Linux services. They
> can only call on RTAI services which are exported by an extra soft-int.
> These services are hard-rt, so there's no problem there.
> Please, download the thing and play with it. Or, at the very least, ask
> about how it works and we'll be glad to explain.
None of which proves that it is the right way to do things.
From what I understand, Linux _is_ being considered for RT applications
by quite a few heavy-weights in the field including IBM, Intel and
quite a few others. The patent issue that you present does not seem to be
discouraging them in any way.
My limited observations suggest that the primary reasons people do not
use Linux for their RT applications are:
1) They don't trust it for 'high availability'.
2) They already have their application mostly written, or
completely written, for some other RT operating system, and
it would cost too much to switch.
Issues such as patents are quite common place and extremely regular
for any serious company that produces RT applications. They *expect*
to have to pay for a good operating system. In fact, if they didn't
have to pay, they become suspicious, usually with good reason.
mark
--
ma...@mielke.cc/ma...@ncf.ca/ma...@nortelnetworks.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
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...
-
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
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
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
===================================================
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!
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
===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================
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.
Karim
===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================
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
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
> > 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?
--
---
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"
> and the guy who did that work freely admitted that it was a fork of the
> RT/Linux source base?
Well, this is standard Victor FUD. He's been repeating this to everyone with
an ear to listen. He has yet to show us a single line of code which is
supposidely taken from RTLinux. But just to satisfy the curiosity of those
who may beleive this sort of stuff, I'm including below an email I had
sent to Victor (+ CC the rtl-advocacy mailing list) about _explicit_ copyright
violations within RTLinux. It should be an interesting read.
Note that the attached email was never answered.
Again, if anyone cares to show the RTAI team actual lines of code that
match between RTLinux and RTAI, we'll be glad to investigate. Until then,
this whole issue remains a classic case of FUD againt RTAI.
> Second, that's what patents are all about, it's about protecting your
> investment. I think you should get used to dual use licensing of patents,
> I expect to see a lot more of this as people start to realize that giving
> away the software and hoping that people will magically give you money
> just doesn't work. There are a lot of people who value free software,
> want to support it, and will do so if it is really free. On the other
> hand, as soon as money enters the equation, the rules will change and
> you're just going to have to deal with that.
You're just trying to justify the continued existence of the software
industry. My belief is that the existence of large enterprises that sell
software (whether they sell copyright licenses for it or patent licenses
for, it's the same business model) is very much questionnable at this point.
Here's for the email I mentionned:
<mail entitled: More from the history department ...>
Just for those who may have believed Victor's claim on the rtl-advocacy
list that I wasn't honest and those of you on the RTAI mailing list who
want to know how come the RTAI folks don't really like what Victor is doing,
I've added some interesting historic tidbits from the RTLinux mailing
list.
This stuff dates back to 1997 and at the time the RTLinux mailing
list was still on NMT's server, management of RTLinux's code was still
in Michael's hand (but this just on the point of changing), VJY associates
(which later became FSMLabs) wasn't in the picture, RTLinux was still
a big kernel patch instead of a modularized package (it later became
modularized after ...), Victor was still a professor at NMT, and lots
of contributions were being sent from left and right both privately
and publicly.
So here's for history's sake:
Here's a reply by Michael Barbanov to Paolo's message regarding the
periodic mode of the 8254 (date: Fri 18 Apr 1997):
--------------------------------------------------------------------------
In message <1997041809...@charon.cs.nmt.edu>, Prof. Paolo Mantegazza wrote:
>Rt-linux is really nice in that it allows to gain an easy access to the
>hardware while keeping the services of linux. However the timer shooting
>technique adopted, while being extremely flexible, requires to much i/o time
>to program the 8254. Is it correct that each i/o blocks the bus for 1 to 1.5
>microseconds?. In fact I did not get anything better than the performance
>cited in rt-linux accompaning paper even by using a 200Mhz PentiumPro
>against a 120 Mhz Pentium. This seems to be confermed by R. Wilhelm recent
>mail. In control and data acquisition problems where there is always a high
>frequency master periodic task at high frequency and precise timings the
>usual mode 2 programming requires just the EOI output of the timer isr and
>should lead to improve performances. In this view I have modified rt_time.c
>and rt_prio_sched.c and it seems that the performances can increase
>substantially. In fact the rect_wawe test can be run with a 10 us ticking to
>give a 50Khz neat squarewave, 1 ns uncertainty, while operating the X
>environment with somewhat sluggish but acceptable, it can depend on your
>idea of acceptable, performances. So if one can accept a fixed time
>resolution that can be an alternative approach. Comments are welcomed. Warm
>thanks again to rt-linux fellows for their work. I think that the
>possibility of adding a user layer within the kernel made possible by the
>way thay have handled the interrupts will be usefull for many other
>applications.
>Greeting, Paolo.
Yes, it's true that the programming of the 8254 timer takes a lot of time (I
think each outb takes even more than 1.5us). The use of mode 2 (periodic
interrupts) can be reasonable for some applications.
--------------------------------------------------------------------------
Notice that peridic mode wasn't in RTLinux, but it was explained by Paolo
and implemented by Paolo first.
But wait, here's more:
This message was sent by Paolo in response to a question by Michael on
how to simulate Linux timer interrupts (date: Tue 22 Apr 1997):
--------------------------------------------------------------------------
>How do you simulate Linux timer interrupts, BTW?
Dear Michael,
below you'll find the code of my scheduling and timer handler functions. (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
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
===================================================
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!)
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
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:
> 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.
Karim
===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================
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
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
===================================================
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
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
> RTAI is free software under the GPL, but that does
Not according to the COPYING file in the current RTAI release. Go read it.
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
> 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 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
> 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.
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...
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
> 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
--
+--------------------------------------------------------+
| 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
> 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 |
+--------------------------------------------------------+
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
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--
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?
-
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
> 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.
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.
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...
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
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, 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
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 lm at bitmover.com http://www.bitmover.com/lm
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.
>
> 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.
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...
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...
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.
>
> Paolo (the maintainer) hasn't. I (the second largest contributor)
> 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.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
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
> > 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.
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
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
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
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
--
+--------------------------------------------------------+
| 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
> 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 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?
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 |
+--------------------------------------------------------+
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.
-
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/
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 |
+--------------------------------------------------------+
Der Herr Hofrat
> > > 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.
>
> 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.
>
david - you know the code.
rtai-24.1.6a/fifo/rtai_fifos.c:line 25-31:
*/
ACKNOWLEDGEMENT NOTE: besides naming conventions and the idea of a fifo handler
function, the only remaining code from RTL original fifos, as written and
copyrighted by Michael Barabanov, should be the function "check_blocked"
(modified to suite my style). However I like to remark that I owe to that code
my first understanding of Linux devices drivers (Paolo Mantegazza).
/*
in rtai-1.6:oldfifos/rtai_fifos.c:line 1-9:
/* Modification of RTL-FIFO devices by Paolo Mantegazza */
/* The original RTL_FIFOS are developped and copyrighted by Michael */
/* Barabanov, 1997, who derived them from fs/pipe.c in Linux, which is in */
/* turn copyrighted with "Copyright (C) 1991, 1992 Linus Torvalds". */
/* This modified version is for use with the RTAI module. It works in the */
/* same way as its original counterpart, but now you can chose either a */
/* task queue for bottom halves or an immediate wake up, plus assigning a */
/* static user buffer. */
/* See functions: rtf_create_using_bh and rtf_create_using_bh_and_usr_buf. */
In my opinion it is obvious that the RT comunity that was RTLinux and RTAI for
quite a while was "stealing" ideas and code from each other - and that is a
very good thing to happen in GPL'ed environments, there was for a long time
one mailing list and that was being shared in a productive manner by both
groups. The fact that the two groups splitt up and are fighting each
other is what is really hurting both sides a lot and probably also hurting
Linux in the market that has interest in hard-realtime.
hofrat
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
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--
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
yoda...@fsmlabs.com
>
> 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.
That interpretation is not just false, it is silly.
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com www.rtlinux.com
Oliver Xymoron
> 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.
Dunno. That implies reservations on the Linux side - generally RT apps
are going to be sensitive to memory exhaustion. Given that, it's easier
just to budget for them all up front and carve that memory out at boot.
Not that I'm against a reservation scheme. I've been arguing for one for
a while to avoid deadlocks with network storage.
> > 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.
Making subsystems of the kernel RT-safe won't buy much for them and won't
help latencies. The people who would want you to do that are from the
buzzword camp.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Roman Zippel
On Sun, 26 May 2002 yoda...@fsmlabs.com wrote:
> > 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.
>
> That interpretation is not just false, it is silly.
Then why don't you specify in the license what "use of the Patented
Process" means?
bye, Roman
Robert Schwebel
On Sun, May 26, 2002 at 11:13:25AM +0200, Der Herr Hofrat wrote:
> In my opinion it is obvious that the RT comunity that was RTLinux and
> RTAI for quite a while was "stealing" ideas and code from each other -
> and that is a very good thing to happen in GPL'ed environments, there was
> for a long time one mailing list and that was being shared in a
> productive manner by both groups. The fact that the two groups splitt up
> and are fighting each other is what is really hurting both sides a lot
> and probably also hurting Linux in the market that has interest in
> hard-realtime.
I strongly support this statement, and I'm pretty sure all the RTAI
developers do the same. It would be _much_ better for all people involved
in the realtime Linux development if we would work _together_ like in the
very beginning instead of fighting each other. Too much energy has been
wasted yet.
And honestly, I'm also thinking that even from the commercial point of
view, a situation where the realtime Linux community joins it's forces to
create the best General Purpose Realtime Operating System on earth in terms
of _technical_ arguments would not be a bad one. For _everyone_, FSM-Labs
and the rest of the world.
But that's just my 0.02 Euro.
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 |
+--------------------------------------------------------+
yoda...@fsmlabs.com
> Hi,
>
> On Sun, 26 May 2002 yoda...@fsmlabs.com wrote:
>
> > > 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.
> >
> > That interpretation is not just false, it is silly.
>
> Then why don't you specify in the license what "use of the Patented
> Process" means?
>
> bye, Roman
It means just what it says.
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com www.rtlinux.com
-
yoda...@fsmlabs.com
> 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.
I have no trouble with other non-commercial licenses - in fact we have
donated a bunch of them to universities. We use GPL for the same reason
you do.
What I do have trouble with is arguments like:
"I am a 100% GPL advocate and my only thought is the greater
good of all human kind and the glory of Free Software. However,
in order to advance Free Software, it is my sad duty to
attach non-GPL proprietary code to your code released under GPL
and to derived versions. Of course, I may reluctantly
take money for doing this work, but it's not the money that counts,
it is my pure motivation - according to me. "
I have heard literally thousands of such arguments in the last 4 years.
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com www.rtlinux.com
-
Roman Zippel
On Sun, 26 May 2002 yoda...@fsmlabs.com wrote:
> > Then why don't you specify in the license what "use of the Patented
> > Process" means?
>
> It means just what it says.
For that I would need a patent lawyer, what I can't afford.
On the other hand other people did get an advice from a lawyer, these
people asking you again if the interpretation of that lawyer is correct
and they get no answer from you, so that they still don't know if they get
sued by you.
bye, Roman
Nicholas Knight
> On Sun, May 26, 2002 at 04:09:46PM +0200, Roman Zippel wrote:
> > Hi,
> >
> > On Sun, 26 May 2002 yoda...@fsmlabs.com wrote:
> >
> > > > 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.
> > >
> > > That interpretation is not just false, it is silly.
> >
> > Then why don't you specify in the license what "use of the Patented
> > Process" means?
> >
> > bye, Roman
>
> It means just what it says.
I'm going to stick my nose in here because this is just getting plain
absurd.
Having read the patent license as best I can, I'm going to ask a question
that evidently nobody has felt the need to ask plainly and clearly. Either
that, or nobody has bothered to actually read the patent license.
If I modify the Open RTLinux software that FSMLabs provides, and distribute
the modified version under the GPL, and then use a feature I added through
the modification in a program I'm distributing under a non-GPL license, am I
in violation of the Open RTLinux patent license?
This seems to be what's confusing people. And is a little confusing to me,
but my guess is that the answer is "yes, you are in violation of the patent
license".
The "use it for whatever you want unmodified" terms of the patent license
seem stupidly straightforward, so I can't see how THAT is causing any
confusion.
Karim Yaghmour
I've posted a list of questions Victor following what you said:
"People who have actual questions should feel free to ask me
directly - publically or privately, I don't mind."
Since many of the others who share my concerns would like to see
these questions answered, I think it would be a very positive
step if you would take the time to answer them.
Thank you,
Karim
===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================
Larry McVoy
> You are tripping. bmap() is obviously different in 32V and 4.2BSD -
> filesystems are different and yes, it _is_ a profound part of filesystem.
You're right, I was tripping, I don't know what I was smokng, I know that
code path and they can't be the same. That said...
> 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.
Oh, come on, read the code side by side, I'm doing it now (kind of fun, too,
it's been a long time since I've been in here). If you have BK installed,
or have tkdiff, run that on the two functions side by side. You're absolutely
right, they aren't identical (what was I thinking? Shame on me, I've worked
on this code, it's impossible for them to be the same by definition), but
one is clearly an extension of the other. This is *not* a rewrite. Or if
it is, I didn't get the memo where they changed the definition of rewrite.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Karim Yaghmour
Hello Nicolas,
Der Herr Hofrat wrote:
> In my opinion it is obvious that the RT comunity that was RTLinux and RTAI for
> quite a while was "stealing" ideas and code from each other
Apart from the fact that I find your mail very positive, I am glad that someone
who was part of FSMLabs freely acknowledges the above.
Karim
===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================
yoda...@fsmlabs.com
> > It means just what it says.
>
> For that I would need a patent lawyer, what I can't afford.
> On the other hand other people did get an advice from a lawyer, these
> people asking you again if the interpretation of that lawyer is correct
> and they get no answer from you, so that they still don't know if they get
> sued by you.
If you are using purely GPL software or some other non-commercial software
then you don't need a lawyer. If you are using standard Linux software
that does not make use of the method, you don't need a a lawyer. If you
are developing commercial RT software that does make use of the method, then
there is no generic and simple rule, just as there is no generic and simple
rule for what is "derived work" and what is "simple aggregation".
People who are developing such software can (A) ask us for specific
information about whether we think the software is covered or
(B) get their own legal advice. If we say that a commercial license is not
required, they can rely on it. What we cannot offer is a rule that
can be defeated by syntactic means. For example, writing a chunk of code
that is practicing the method, and splitting it into parts so you
can hide the valuable IP in one component while GPL'ing the
rest, is not acceptable. Taking what is certainly an OS module that
is required to be GPL and turning on the "user mode" bit and calling it
an "application" does not work either. Similarly, I doubt
as one can write a non-GPL module for gcc, run it under NetBSD as a BSD
kernel module and claim benefit of the BSD License to close it.
Our patent is a US patent: people in Europe who say they are worried about
RTLinux patent issues may really have more to worry about if they are
using code that should be inheriting our GPL license and are incorporating
it in non-GPL software without our permission.
Well, there are also some
somewhat similar German software patents that might also worry them.
Embedded software is one of the most highly patented areas. It is beyond
irony when our European friends tell us that companies like Schneider
are horrified by the existence of the patent. Please forgive my
cynicism, but most of the complaints seem to come from people who want to
write software for money for customers that own
huge patent portfolios. If you are engaged in such a business, then you
clearly have no principled disagreement with patent and other
software licenses. As Churchill put it, we have established what you are,
we are only quibbling about the price.
I don't claim to be writing software in order to benefit mankind. We
have a business that, like old-fashioned businesses, stresses
profits although I hope very much we are living up to our ethical
principles as well.
For both ethical and practical business reasons, we are
in no way inclined to try to strangle off competing uses of the patented
method. Our commercial license fees are _low_ and we have not turned down
anyone who asked for licenses.
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com www.rtlinux.com
-
Karim Yaghmour
yoda...@fsmlabs.com wrote:
> If you are using purely GPL software or some other non-commercial software
> then you don't need a lawyer. If you are using standard Linux software
> that does not make use of the method, you don't need a a lawyer.
Not needing a lawyer != not needing to purchase a license.
Hence, would it be fair to rephrase this last portion as follows:
"If you are using purely GPL software or some other non-commercial software
then you don't need __to purchase a license from FSMLabs__. If you are using
standard Linux software that does not make use of the method, you don't need
__to purchase a license from FSMLabs__.
A simple yes/no will suffice.
> If you
> are developing commercial RT software that does make use of the method, then
> there is no generic and simple rule,
What is "use of the method"? Can you provide a list of approved uses, a
list of uncertain uses, and a list of uses requiring a license? Surely
FSMLabs' business records contain enough information to provide future
potential users with clear-case scenarios.
> just as there is no generic and simple
> rule for what is "derived work" and what is "simple aggregation".
> People who are developing such software can (A) ask us for specific
> information about whether we think the software is covered or
> (B) get their own legal advice.
(A) has been attempted before and I know people to which you provided
unclear answer over the phone to the following question:
"Do I need to purchase a license from FSMLabs if I write an RTAI rt applications?"
Care to answer it now? This is a fairly straight-forward non-convoluted
case.
(B) does not preclude you from suing the users. So lawyers will always
bet on the safe side and say "don't use Linux".
> If we say that a commercial license is not
> required, they can rely on it. What we cannot offer is a rule that
> can be defeated by syntactic means.
Why not? Don't you have enough practical examples within your day
to day business to provide us with clear no-nonense example scenarios?
> For example, writing a chunk of code
> that is practicing the method, and splitting it into parts so you
> can hide the valuable IP in one component while GPL'ing the
> rest, is not acceptable. Taking what is certainly an OS module that
> is required to be GPL and turning on the "user mode" bit and calling it
> an "application" does not work either.
What is the "user mode" bit? Does your statement apply to the RTAI hard-rt
user-space applications which have been described earlier on this list?
> Similarly, I doubt
> as one can write a non-GPL module for gcc, run it under NetBSD as a BSD
> kernel module and claim benefit of the BSD License to close it.
I don't think that such a comparison can be applied. For one thing, the
FSF does not own a patent on gcc. Your particular case is quite unique in
the open source world. You're the only open source contributor who has
decided to license his software in GPL and then use a patent to collect
royalties on the commercial use of this work.
> Our patent is a US patent: people in Europe who say they are worried about
> RTLinux patent issues may really have more to worry about if they are
> using code that should be inheriting our GPL license and are incorporating
> it in non-GPL software without our permission.
> Well, there are also some
> somewhat similar German software patents that might also worry them.
So too should your clients be very worried as to the code you are selling
them. Any one of the current RTAI developers can now sue you and your
clients for code theft. Not only is this based on the RTAI team's
assesment, but this is now publicly substantiated by your own employees.
RTAI developers may have mislabeled some licenses, but they sure as hell
don't sell closed-source versions of the resulting code.
> Embedded software is one of the most highly patented areas. It is beyond
> irony when our European friends tell us that companies like Schneider
> are horrified by the existence of the patent. Please forgive my
> cynicism, but most of the complaints seem to come from people who want to
> write software for money for customers that own
> huge patent portfolios. If you are engaged in such a business, then you
> clearly have no principled disagreement with patent and other
> software licenses. As Churchill put it, we have established what you are,
> we are only quibbling about the price.
Clearly, you have no moral leg to stand on Victor. The fact that no
other open source contributor or company established by said contributor
has chosen to license his software in GPL and then use a patent to
collect royalties clearly shows that you are at odds with the spirit
of open source.
Long gone is the time when this debate was about "moral purity".
This debate is about how your patent is causing Linux not to be used
in an entire application field and what are the possible future avenues.
At this point, I would like to point out that an ex-parte patent reexamination
costs 2,000USD to be started and any member of the public can participate
in providing "prior art" once the process has started. The only issue
to watch out for here is that the initiating party can only use this
process once. After that, he is forbiden to ever start another ex-parte
patent reexamination on said patent. So whoever thinks about trying this
should better be well prepared and have good counsel. One thing that this
is certain, however, is that there is no lack of "prior art" as I am sure
anyone on this list can testify.
There's also the inter-partes reexamination, but I don't think it can
be applied to this patent given the timeline of its passing into law.
But I may be wrong.
> I don't claim to be writing software in order to benefit mankind. We
> have a business that, like old-fashioned businesses, stresses
> profits although I hope very much we are living up to our ethical
> principles as well.
As I was telling Larry earlier. The software industry as we know it is an
endangered species. You have established your business of very shaky
foundations and are endangering both you, your users/clients and Linux.
> For both ethical and practical business reasons, we are
> in no way inclined to try to strangle off competing uses of the patented
> method. Our commercial license fees are _low_ and we have not turned down
> anyone who asked for licenses.
The problem isn't the price of your license, it is its very existence.
BTW, you still haven't answered my questions.
Cheers,
Karim
===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================
Roman Zippel
On Sun, 26 May 2002 yoda...@fsmlabs.com wrote:
> If you are using purely GPL software or some other non-commercial software
> then you don't need a lawyer. If you are using standard Linux software
> that does not make use of the method, you don't need a a lawyer. If you
> are developing commercial RT software that does make use of the method, then
> there is no generic and simple rule, just as there is no generic and simple
> rule for what is "derived work" and what is "simple aggregation".
If you still don't want to explain what "use of the Patented
Process" means, you should better remove that license and just say that
every use of the patent in any form has to be licensed individually. That
would be far more honest. As the license stands now it's more cause for
confusion than helpful.
Everyone likes bitching about the FSF, but at least they clerly explain
what they mean. If yoy can't do that, don't mention the GPL in your
license. Your are only using it as an excuse to call your license "open".
bye, Roman
Larry McVoy
words of advice and then I hope we're done with this thread because I
don't know what else can be said which hasn't been said before.
On Sun, May 26, 2002 at 02:00:42PM -0400, Karim Yaghmour wrote:
> What is "use of the method"?
Ask a lawyer.
> "Do I need to purchase a license from FSMLabs if I write an RTAI
> rt applications?"
Ask a lawyer.
> What is the "user mode" bit? Does your statement apply to the RTAI hard-rt
> user-space applications which have been described earlier on this list?
Ask a lawyer.
> > Similarly, I doubt
> > as one can write a non-GPL module for gcc, run it under NetBSD as a BSD
> > kernel module and claim benefit of the BSD License to close it.
>
> I don't think that such a comparison can be applied.
If you want to know for sure, hire a lawyer.
> So too should your clients be very worried as to the code you are selling
> them. Any one of the current RTAI developers can now sue you and your
> clients for code theft.
Sounds like you need a lawyer.
> RTAI developers may have mislabeled some licenses, but they sure as hell
> don't sell closed-source versions of the resulting code.
Snort. "may have mislabeled". Snort.
> As I was telling Larry earlier. The software industry as we know it is an
> endangered species.
Tell that to Microsoft, watch them laugh.
> BTW, you still haven't answered my questions.
I read your whole posting carefully, a couple of times. You're basically
asking for free legal advice from a party whom with you compete, may possibly
sue, and/or may be sued by. Do you seriously expect answers or are you
just posturing? Rhetorical question, please don't answer it.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Alan Cox
> The Linux core *is* tiny, and for that reason attractive for this purpose.
> I agree that it is still too complex to verify formally, and we've suffered
> because of that, i.e., when will we see the last truncate race? When will we
The Linux core is -huge- by embedded standards. These people think of
stuff like vxworks as pretty large too. On truely embedded devices you
are talking a kernel under 32K in size, probably under 16K if well
tuned.
Chasing down obscure truncate races in a PC is irritating but doable,
you can run huge test sets and you can get answers that it doesn't
happen under workloads likely to trigger it - but you can't *prove* it.
The moment you get involved in things that kill people when they go
wrong, the rules change. At the point where you get the device back if
it goes wrong it also becomes very convenient to build extremely small
OS cores. The problem that is biting people now is that the markets
demand both complexity plus sophisticated feature sets _and_ they want
the stability. Software costs for appliances have gone through the roof
as margins go through the floor.
That helps Linux in the sense that part of the strategy is to build a
system that is shared cost and testing over many vendors and many
products, but it doesn't alter the basic problem that computer science
isn't really up to it. Right now we are building cathedrals in the same
way as a medaeival master mason, by intutition, experience, and testing.
We have no more idea than they do if any given edifice will come
crashing down (as several large medaeival ones indeed did).
Alan Cox
> 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
And then went on to cite bmap which is clearly different. Yes Larry, now
would you mind returning to the ward like a good patient 8)
> 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.
b) doesn't work because copyright does not apply to the fundamental
algorithms. If you want to look at it at that level you need to remember
there are many different implementations which are very different but
which in pure mathematics are strictly identical.
Alan
Larry McVoy
> On Sun, 2002-05-26 at 05:03, Larry McVoy wrote:
> > 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
>
> And then went on to cite bmap which is clearly different. Yes Larry, now
> would you mind returning to the ward like a good patient 8)
Sniffle, whimper. It is clearly different in that it calls out to the
BSD allocation policy, which is completely different.
However, if you diff the code, there is more than enough which is the same
that there is now way you can call that a rewrite of bmap(). I was wrong in
saying it was bit for bit identical, but other than showing me to be a clutz,
it doesn't detrack from the point.
But I'm headed for he ward. Sniff.
> > 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.
>
> b) doesn't work because copyright does not apply to the fundamental
> algorithms. If you want to look at it at that level you need to remember
> there are many different implementations which are very different but
> which in pure mathematics are strictly identical.
Is this theory or practice, Alan? We're not talking about pure copyright,
we're also discussing derived works. And anyway, I'd like you to cite a
case where two independently developed substantial chunks of code compile
to the same expression tree. I'm sure you can find strcmp() implementations
which do, but I'd be surprised if you could find a stdio implementation that
was, and you sure as hell won't find two file system implementations that do.
Righ? Or do you have a counter example?
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Alexander Viro
On Sun, 26 May 2002, Larry McVoy wrote:
> On Sun, May 26, 2002 at 08:40:44PM +0100, Alan Cox wrote:
> > On Sun, 2002-05-26 at 05:03, Larry McVoy wrote:
> > > 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
> >
> > And then went on to cite bmap which is clearly different. Yes Larry, now
> > would you mind returning to the ward like a good patient 8)
>
> Sniffle, whimper. It is clearly different in that it calls out to the
> BSD allocation policy, which is completely different.
Um... In 4.2 - more or less so. In 4.4 - way more than that:
* ffs_bmap() is not doing any allocations now
* ffs_balloc() does (and is an analog of old bmap()) and it contains
a *lot* more code than bmap() had - handling of fragments, stuff forced
by new VM _and_ seriously different overall structure of code.
WTF? 4BSD code is out there, in SCCS, no less. Goes back
to 1982 or so. It's not that checking it would be a problem - grab
the 4th CD from Kirk's 4-parter (CSRG archives) and see yourself.
BTW, having _that_ converted to BK might be an interesting thing.
To do that one would need to take file moves into account, but they'd
got enough snapshots of the tree to reconstruct that...
Alan Cox
> > there are many different implementations which are very different but
> > which in pure mathematics are strictly identical.
>
> Is this theory or practice, Alan? We're not talking about pure copyright,
> we're also discussing derived works. And anyway, I'd like you to cite a
> case where two independently developed substantial chunks of code compile
> to the same expression tree. I'm sure you can find strcmp() implementations
> which do, but I'd be surprised if you could find a stdio implementation that
> was, and you sure as hell won't find two file system implementations that do.
> Righ? Or do you have a counter example?
I was very careful to say "pure mathematics". With perfect optimisation
all implementations of the same algorithm should produce the same parse
tree.
I can think of lots of trivial counter examples. The most obvious of
which is that given any set beginning pascal type homework the parse
tree of all the implementations with the noise/comments/names filtered
out is probably going to be identical.
The same exercise on library implementations of qsort, strcmp and so
forth are probably also going to show that.
Larry McVoy
> > Sniffle, whimper. It is clearly different in that it calls out to the
> > BSD allocation policy, which is completely different.
>
> Um... In 4.2 - more or less so. In 4.4 - way more than that:
> * ffs_bmap() is not doing any allocations now
> * ffs_balloc() does (and is an analog of old bmap()) and it contains
I think I was looking at 4.3Tahoe, but it doesn't matter, what I was
thinking about was your comment about frags, that makes things quite
different. And I know, err, am pretty sure, that by this point Kirk
had worked over the allocation policy to keep things in the same
cylinder group when possible and I don't think that the original
file system was quite as careful.
> WTF? 4BSD code is out there, in SCCS, no less. Goes back
> to 1982 or so. It's not that checking it would be a problem - grab
> the 4th CD from Kirk's 4-parter (CSRG archives) and see yourself.
Yup, got it. I've had some fun in there.
> BTW, having _that_ converted to BK might be an interesting thing.
> To do that one would need to take file moves into account, but they'd
> got enough snapshots of the tree to reconstruct that...
Yes, I know, it's on my list of things to do. There are some compat issues,
it isn't a trivial thing, but we can and will do it. Another thing I plan
to do is to build up BK repositories of all the BSD docs as well as all the
troff docs. I really like troff, I'm not a fan of latex or word, troff
still works better for me but I think many people abandoned it out of a
lack of documentation. And when that's done, I'll make man page versions
of all the stupid info stuff so I can say "man whatever" and get what
I need.
Wandering well into the weeds....
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Larry McVoy
> On Sun, 2002-05-26 at 20:06, Larry McVoy wrote:
> > > there are many different implementations which are very different but
> > > which in pure mathematics are strictly identical.
> >
> > Is this theory or practice, Alan? We're not talking about pure copyright,
> > we're also discussing derived works. And anyway, I'd like you to cite a
> > case where two independently developed substantial chunks of code compile
> > to the same expression tree. I'm sure you can find strcmp() implementations
> > which do, but I'd be surprised if you could find a stdio implementation that
> > was, and you sure as hell won't find two file system implementations that do.
> > Righ? Or do you have a counter example?
>
> I was very careful to say "pure mathematics". With perfect optimisation
> all implementations of the same algorithm should produce the same parse
> tree.
And I was very careful to ask for a specific counter example. In theory,
I'm sure you may be right, but theory doesn't count. We were discussing
how to show that the code was the same, in other words, we're in the
context of practice, you said it wouldn't work, and I said show me an
example. You don't get to fall back on theory, I specifically asked for
a real world example.
> The same exercise on library implementations of qsort, strcmp and so
> forth are probably also going to show that.
Right. I already agreed that the trivial cases would do it. What about
stdio? That's pretty simple set of interfaces, and I doubt that even
the gnu one and the v7 one compile to the same expression tree.
Let's put it this way: do you know of any expression tree, compiled
from two from scratch different implementations of the same thing,
with more than 5000 nodes, which results in the same thing? Not only
do you not, I'd go so far as to predict you'll never find one no matter
how long you look. Sure, you limit the solution space down to something
like strcmp, the set of possible expression trees is probably in single
digits or so. That doesn't prove anything other than you're looking at
a simplistic case.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Karim Yaghmour
Larry McVoy wrote:
> Ask a lawyer.
...
> Ask a lawyer.
...
> Ask a lawyer.
...
> If you want to know for sure, hire a lawyer.
> Sounds like you need a lawyer.
In one single mail about the rtlinux patent issue you have to tell me 5 times
to see a lawyer and you expect developers to actually evaluate Linux for real
use in real-time apps?
> Snort. "may have mislabeled". Snort.
:)
> > As I was telling Larry earlier. The software industry as we know it is an
> > endangered species.
>
> Tell that to Microsoft, watch them laugh.
So you're siding with Microsoft?
> I read your whole posting carefully, a couple of times. You're basically
> asking for free legal advice from a party whom with you compete, may possibly
> sue, and/or may be sued by.
You read the posting carefully and this is all you find to say?
> Do you seriously expect answers or are you
> just posturing? Rhetorical question, please don't answer it.
I don't feel the need to impress you Larry, but I do actually expect to
obtain actual answers as Victor himself promissed and I would invite
everyone wanting to hear those answers to speak up.
Karim
===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================
Erwin Rol
> In message <3CF1578E...@opersys.com> Karim Yaghmour wrote:
> >
> > I don't feel the need to impress you Larry, but I do actually expect to
> > obtain actual answers as Victor himself promissed and I would invite
> > everyone wanting to hear those answers to speak up.
>
> Maybe we all are just mis-interpreting him.
>
> Victor: It cannot be _that_ difficult to reply to each of Karim's
> questions with a clear "Yes" or "No". Please reply!
>
Having asked similar question and never getting a useful answers, i also
am interested in the answers to those questions.
- Erwin
> Wolfgang Denk
>
> --
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: w...@denx.de
> It is wrong always, everywhere and for everyone to believe anything
> upon insufficient evidence. - W. K. Clifford, British philosopher,
> circa 1876
Mark Mielke
> Larry McVoy wrote:
> > Ask a lawyer.
> ...
> ...
> In one single mail about the rtlinux patent issue you have to tell me 5 times
> to see a lawyer and you expect developers to actually evaluate Linux for real
> use in real-time apps?
I doubt developers spend much time evaluating any more than the technical
details.
Developers shouldn't be expected to evaluate fields that are not within
their expertise. No sensible company would put the ball entirely in the
court of one or three developers.
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:
> > In one single mail about the rtlinux patent issue you have to tell me 5 times
> > to see a lawyer and you expect developers to actually evaluate Linux for real
> > use in real-time apps?
>
> I doubt developers spend much time evaluating any more than the technical
> details.
Depends on the type of development you're doing, but future viability and
basic legal implications are certainly part any good engineering study.
> Developers shouldn't be expected to evaluate fields that are not within
> their expertise. No sensible company would put the ball entirely in the
> court of one or three developers.
True, and upon asking the lawyers, the company would tell the developers
that they don't have the green light to use Linux. Which gets us back
right where we started.
Karim
===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================
Robert Schwebel
> A definitive statement from Victor would indeed be VERY helpful.
> Maybe we all are just mis-interpreting him.
>
> Victor: It cannot be _that_ difficult to reply to each of Karim's
> questions with a clear "Yes" or "No". Please reply!
We all know what will happen, because we have played this game a thousand
times before: he won't answer. He simply is not interested in a
clearification of the situation.
I know of not a single company besides FSM-Labs who does not answer if you
have questions about the use of their products but points you to a lawyer.
Lately I've talked to some people from a German company who has even
contacted FSM-Labs, because they want to use RTAI for a product and wanted
to be sure if they needed to buy a patent license or not. Even that
potential FSM-Labs customer was roughly told to ask a lawyer.
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 |
+--------------------------------------------------------+
Calin A. Culianu
> 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.
No, a lot of the time, the entire application is the algorithm -- in
Kernel space, as a module, very close to the driver. For further
clarification, see Robert's post regarding the layout of a typical
realtime application in RTLinux or RTAI.
>
> 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.
Can you clarify this? Most computing in general has nothing to do with
hard RT? Or are you saying that most real life engineers that use an RTOS
are simply doing overkill?
Pavel Machek
> > What, so there are _no_ patents or other restrictions on any of then
> > commercial embedded OS vendor products? I would imagine that you need
> > to pay some sort of license fee to those vendors in order to use their
> > code for products you sell.
>
> Thousands of them. Some of them like the Siemens power management patent
> really hurt Linux too.
Can you elaborate on this one?
> I'd suggest Andrea does something else. Ask the Red Hat people for a formal
> confirmation he can use it, just like IBM with RCU. I have this funny feeling
> that he'll get an extremely positive response.
Does he need to ask permission? Code is GPL-ed, "no additional
restrictions" in GPL should shield him...
Pavel
--
(about SSSCA) "I don't say this lightly. However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
Alan Cox
> Hi!
>
> > > What, so there are _no_ patents or other restrictions on any of then
> > > commercial embedded OS vendor products? I would imagine that you need
> > > to pay some sort of license fee to those vendors in order to use their
> > > code for products you sell.
> >
> > Thousands of them. Some of them like the Siemens power management patent
> > really hurt Linux too.
>
> Can you elaborate on this one?
Siemens own a patent on what basically amounts to keeping per task power
management settings.(US 6,298,448)
>
> > I'd suggest Andrea does something else. Ask the Red Hat people for a formal
> > confirmation he can use it, just like IBM with RCU. I have this funny feeling
> > that he'll get an extremely positive response.
>
> Does he need to ask permission? Code is GPL-ed, "no additional
> restrictions" in GPL should shield him...
I think the GPL is sufficient, but if he wishes to be cautious and ask
for a formal confirmation Red Hat will be happy to oblige.
Alan
Adam J. Richter
If Red Hat is able to leave the licensing issues for their
Linux patents unresolved and they still manage to be regarded as being
in good standing with most contributors and would-be customers, then,
in the coming months, many other Linux companies will take this is a
green light to file for many patents and remain silent when asked to
explictly grant permission to the public to practice the patents in
free software. There is little or no business reason to publicly
grant such permission if one can get away with not doing so.
Although other companies today already have many patents that
they could argue are infringed by certain free software components.
The Linux patents are different as a practical matter, however, in
that the chance of prevailing in that argument will be greater when
if alleged infringer is using the code for which the patent was
originally submitted.
Eventually, as some companies are bought or go out of
business, it is a statistical certainty that some of these patents
will pass into the control of parties that do not care about the GPL's
penalties for enforcing a software patent (after all, that would allow
litigation only against copiers of the software, and a copyright owner
would have to sue, which is approximately already the level of danger
one has with an unlicensed software patent).
Adam J. Richter __ ______________ 575 Oroville Road
ad...@yggdrasil.com \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
Alan Cox
> If Red Hat is able to leave the licensing issues for their
> Linux patents unresolved and they still manage to be regarded as being
Nobody intends to leave in unresolved. It's simply a matter of coming up
on the Friday of a long weekend when most folk are not back until
Tuesday. I think everything will have been appropriately addressed
including the questions of the 'what if IBM/AOL/Sony/.. buy Red Hat' [1]
kind
Alan
[1] Pick a bogus rumour, any rumour...
Larry McVoy
be off on some other list, but I don't know what that is. Alan will be
sending out the guards to herd me back into the ward, but I've escaped
for the moment and I'll make the best of it :)
On Mon, May 27, 2002 at 02:52:13PM -0700, Adam J. Richter wrote:
> Eventually, as some companies are bought or go out of
> business, it is a statistical certainty that some of these patents
> will pass into the control of parties that do not care about the GPL's
> penalties for enforcing a software patent
If the free software community is ever going to really compete with the
non-free software community, they simply have to come up with a better
business model than giving it away and trying to make money on support.
It's economics 101 - a free market will go to whomever can provide the
needed service most cheaply. With no barrier to entry, that means as
soon as the price gets high enough, someone will resell the product for
less. Which results in razor thin profits, if any at all.
In my opinion, it's time for the free software fanatics to ease off and
let some moderates come in and try and define a reasonable compromise.
We all need to realize that we can let businesses figure it out themselves
and we may not like what they decide, or try and define a compromise
that can be lived with. Whether you like it or not, the patent ploy
works and there isn't a damn thing you can do about it if it is a legit
patent.
If you hold the "It's GPL or bugger off" position, people will figure out
how to work around it and it is virtually certain you won't like what they
do. If you offer them some sort of reasonable compromise, I'll bet they
take it. If you don't, you get to live with whatever their nasty evil
business minds dream up.
This whole line of reasoning is why I detest the OSI and Eric Raymond
in particular. They had a chance to define a "Buiness Source License"
or some other compromise and get the world to consider it as an option.
Instead, they just made a lot of noise and for what? Ask yourself -
how much more open source is there in the world today versus 5 years ago.
Imagine that pile. Now take the OSI out of the picture and tell me what
would not be in that pile anyway. Bloody little. The OSI squandered a
golden opportunity to really change the world, and I find that depressing
beyond words.
Sorry, I'm wandering. The discussion I'd like to see is one in which
people explored the values they hold dear and tried to come up with a
business model which preserves those values and allows that business
to compete with the likes of Microsoft. Yeah, yeah, I know that Linux
kicks butt for print serving and web serving, but the 99% reason it
does is price. It's not because Linux has new compelling features that
Microsoft doesn't have, it's because it's hard for Microsoft to compete
with stuff that costs zero dollars. The problem isn't where we are,
the problem is where we are going (or more to the point, not going).
How is Linux and open source ever going to be a leader, producing new
applications, new protocols, new languages, new markets when it doesn't
generate the incredible amounts of revenue needed to build all that?
Ask yourself - how much open source is a reimplementation of what has
already been designed and implemented, and how much is fundamentally new?
That new stuff costs huge dollars, not because of the cost of building it,
but because of the cost of building all the crap that turned out bad
but provided the insight that lead to the new stuff. It's really not
that hard to reimplement something, open source has proven that beyond
all doubt. What it hasn't proven is that open source leads to new ideas,
products, and markets. So far, open source follows, it doesn't lead.
A reasonable business model might change that. There may be other ways
to change it, but something needs to change or 20 years from now there
will be open source versions of all the current popular apps, but still
playing catch up on the next generation.
My 2 cents.
--
---
Larry McVoy lm at bitmover.com http://www.bitmover.com/lm
Karim Yaghmour
I agree that this should go on some other list, but 'til then, here are my 2c.
No offense Larry, but many of your arguments are the same used by Microsoft
to push their vision of publicly available source.
Larry McVoy wrote:
> It's economics 101 - a free market will go to whomever can provide the
> needed service most cheaply.
I will take the liberty of rephrasing to illustrate my point of view:
"a free market will go to whomever can provide the needed service."
The question is: Can you provide the service? Of course if the service
you are selling is common knowledge, then you've got nothing to sell
your competitor can't. But if you're part of building the technology
then you're certainly in a know-how monopoly position. This is why I
don't think any of the kernel developers will ever be out of a job.
The drawback to this is that you simply can't scale a knowledge-based
company the way you do with a classical intellectual-property-based
company. The way I see it, the software industry will look increasingly
like that of other speciality fields such as law and medicine. Sure, any
doctor can administer a serum, but not every doctor can actually perform
robotic heart-surgery. He who can perform robotic heart-surgery can
offer something other doctors can't. Same will be with the software field.
> In my opinion, it's time for the free software fanatics to ease off and
> let some moderates come in and try and define a reasonable compromise.
Can you suggest a list of names of some "moderates"?
> If you hold the "It's GPL or bugger off" position, people will figure out
> how to work around it and it is virtually certain you won't like what they
> do. If you offer them some sort of reasonable compromise, I'll bet they
> take it. If you don't, you get to live with whatever their nasty evil
> business minds dream up.
I predict the inverse. Of course, people will actually try to use patents to
restrict free and open source software. And of course, they will push this
as hard and as far as they can. The community, however, will always find
alternative ways to obtain the same results and, in the end, no client wil
use the patent holder's products or services. Instead, they will use the
community's alternative solutions.
You would like the open source and free software communities to get used
to having their rights being violated. I think the software "manufacturers"
better get used to the fact that they can't outsmart the community,
regardless of the legal/political/financial tools they use.
As I said earlier, the current software business model is an endangered
species.
Best regards,
Karim
===================================================
Karim Yaghmour
ka...@opersys.com
Embedded and Real-Time Linux Expert
===================================================
Austin Gonyou
On Mon, 2002-05-27 at 18:15, Karim Yaghmour wrote:
...
> I predict the inverse. Of course, people will actually try to use patents to
> restrict free and open source software. And of course, they will push this
> as hard and as far as they can. The community, however, will always find
> alternative ways to obtain the same results and, in the end, no client wil
> use the patent holder's products or services. Instead, they will use the
> community's alternative solutions.
>
> You would like the open source and free software communities to get used
> to having their rights being violated. I think the software "manufacturers"
> better get used to the fact that they can't outsmart the community,
> regardless of the legal/political/financial tools they use.
I tend to agree with Karim here for sure. It's human nature to overcome
adversity, and this is adversity in one frame of mind, not from
different points of view. (Just to clarify the MPAA see adversity in
certain aspects of the OSS community I think, but they're the opressors,
not us).
Also, in the paragraph about "GPL or bugger off", if you feel it's over
the top, then it's possible others will too, and then it's simply
survival of the fittest. People must change to a degree, but the message
they carry is, and probably will remain, the same.
Austin
pe...@horizon.com
> If Red Hat is able to leave the licensing issues for their
> Linux patents unresolved and they still manage to be regarded as being
> in the coming months, many other Linux companies will take this is a
> green light to file for many patents and remain silent when asked to
> explictly grant permission to the public to practice the patents in
> free software. There is little or no business reason to publicly
> grant such permission if one can get away with not doing so.
>
> Although other companies today already have many patents that
> they could argue are infringed by certain free software components.
> The Linux patents are different as a practical matter, however, in
> that the chance of prevailing in that argument will be greater when
> if alleged infringer is using the code for which the patent was
> originally submitted.
>
> business, it is a statistical certainty that some of these patents
> will pass into the control of parties that do not care about the GPL's
> litigation only against copiers of the software, and a copyright owner
> would have to sue, which is approximately already the level of danger
> one has with an unlicensed software patent).
Forgive me for not trimming this, but it's so well said that it deserves
to be read again.
Whatever Red Hat does, it will be setting a precedent that will guide
later followers. It can expect to be on the other end of the deal
later, so "do unto others as you would have them do unto you" is
very relevant here.
Just in case someone thinks this isn't a critical issue, remember that
at least one hostile power, in the form of Microsoft:
- Has repeatedly described Linux as a number-one threat
- Has lots of lawyers, guns and money. Well, if not guns, experience
at software patent litigation.
- Is in the habit of buying companies for bits of intellectual property
that interest them
- Is famous for gutting those companies in gruesome ways
- Has already identified (Hallowe'en documents) software patents as
the most promising tool to attack free software
- Is watching very carefully.
If it's difficult to face the possibility of Red Hat at a bankruptcy
auction, consider threeguysinagarage.com. And remember what the Church
of Scientology did to the Cult Awareness Network.
I don't mean to accuse Red Hat of anything in advance of the evidence, but
the legal obligations of a publicly traded company to its stockholders are
commonly interpreted as a requirement for purely selfish and utterly venal
(and generally very short-sighted) behaviour. That makes me nervous.
Andre Hedrick
Obviously it would be in everyone's best interest to set a position of
live and let live. Everyone assumes they are going to do the wrong thing,
and that shows how the general community is thinking how do I get my piece
of the pie. I guess we have reached the level of BSD now.
Maybe people should give then the benefit of the doubt; othewise, where do
we start the forks we have already, but not officially labelled as such?
$DISTRO-linux
This is what the larger business interests are hoping for the lemmings to
run off the cliff. If they (UBL) is successful in fragmenting the
community then that interested party(ies) will be able to morph
GPL->BSDish and the game is over.
$0.02 and keep the change!
Andre Hedrick
LAD Storage Consulting Group
If you are a (UBL) interest holder, up yours dude!
pe...@horizon.com
> live and let live. Everyone assumes they are going to do the wrong thing,
> and that shows how the general community is thinking how do I get my piece
> of the pie. I guess we have reached the level of BSD now.
Perhaps I didn't take enough care in emphasizing
>> I don't mean to accuse Red Hat of anything in advance of the evidence
I'm worried, but still hopeful. For starters, Alan Cox is on the inside,
and I own T-shirts describing his opinion on software patents.
I just wanted to echo Adam Richter's statement that Red Hat's actions
are going to have broad consequences, and I hope they'll think about
them carefully. He showed remarkable insight, and expressed it very
well.
Gilad Ben-Yossef
> If the free software community is ever going to really compete with the
> non-free software community, they simply have to come up with a better
> business model than giving it away and trying to make money on support.
> It's economics 101 - a free market will go to whomever can provide the
> needed service most cheaply. With no barrier to entry, that means as
.........^^^^^^^^
> soon as the price gets high enough, someone will resell the
> product for
..^^^^^^^
> less. Which results in razor thin profits, if any at all.
Software is not a "product" any more then a lawyer argument in a case is
a "product" or an architect plan for a building is a "product". That's
the whole problem in a nut shell. If you continue to view software as a
sellable object then the business model indeed doesn't make sense. Then
again, if you try to look at a lawyers argument in a case as the
"product" of the law firm then that same business plan doesn't make
sense either. After all, in most countries I'm aware of, a lawyer
argument cannot be effectivly copyrighted. Of course, this doesn't stop
lawyers from make a living. Just ask anyone at Microsoft legal
depratment... ;-)
Most "Open Source service companies" that I'm aware off don't understand
the implications. They're not built like a small law firm that may be
large one day; they're built like a company that tries to be a 90 pound
world class gorrila backed by Vulture Capital. Sorry, but it doesn't
work like this: you have to walk before you can run.
So there's a business model and it works for years in other fields.
Maybe the problem is that people this path is it isn't "sexy" - they
will have to lose the dream of being High Tech millionares who built a
megacorporation and start thinking like a small time law firm, which
might one day be big. Maybe they don't like to work in a consultant kind
of way. I can understand that and it's OK, but there is a business
model.
The way Open Source (or Free) software works is to multiply the "use
value" of software by killing the "sell value". But here is the
interesting part: it increases the "use value" of the open/free software
in a given niche, but kills the "sell value" of ALL software competing
in that niche. This is why it's going to win, cold hard economic facts
and no need for FSF like ideology (not that there's anything wrong with
that... ;-))))
And BTW I'm OK with patents as long as their licensed for free to GPLed
software (maybe add a clause that makes this irreversable?).
> How is Linux and open source ever going to be a leader, producing new
> applications, new protocols, new languages, new markets when it doesn't
> generate the incredible amounts of revenue needed to build all that?
A. Who cares? We're having fun.
B. It already is in many senses.
I even think that A leads to B, but that's just me...
> Ask yourself - how much open source is a reimplementation of what has
> already been designed and implemented, and how much is fundamentally new?
Ask yourself - how much science is a reimplmentation of what has
already been researched and implmented, and how much is fundamentally
new?
If I remember correctly Linus quoted some dead guy about this once,
something about standing on the shoulders of giants...
OK, I'll now go back to being a quiet little lurker... ;-)
--
Gilad Ben-Yossef <gi...@benyossef.com>
http://benyossef.com
"Hail Eris! All Hail Discordia!"
Peter Wächtler
> I agree that this should go on some other list, but 'til then, here are my 2c.
>
> No offense Larry, but many of your arguments are the same used by Microsoft
> to push their vision of publicly available source.
>
Huh?
Just a quick suggestion: keep Linux open (THE operating system) as basis
for future development, enhancement. I think it's called "public facility"
like power plants and infrastructure that is needed for a healthy society
(at least politicians shall work for the publics benefit).
Applications and other value add are produced and provided by third
parties and SOLD. You can do that legally TODAY. With the laws and
licenses (e.g. LGPL) used TODAY.
Microsoft wants to control almost everything (on computers).
If they place a new API on their system, the whole industry has to
follow. Hey, what's up with the laws that should protect me (and others)?
Uh, they have to provide a hook for another email/web client!
Who thinks that this is adequate? Who is guilty of what?
Who cares?
Alan Cox
> On Tuesday 28 May 2002 09:53, Gilad Ben-Yossef wrote:
> > And BTW I'm OK with patents as long as their licensed for free to GPLed
> > software (maybe add a clause that makes this irreversable?).
>
> only must the GPL be accommodated, but all open source licenses. And it
> is not enough to be free as in "without cost": it must also be free of
> additional restrictions.
I don't think you can realistically expect all open source licenses like
the BSD one to be accomodated. Otherwise people would ship binary apps
linked with a BSD licensed libpatent.o/c that was useless to anyone. The
GPL restrictions happen to work very nicely in terms of making a patent
available for free software (or one definition thereof), the BSD license
alas doesn't.
Ingo Oeser
> If the free software community is ever going to really compete with the
> non-free software community, they simply have to come up with a better
> business model than giving it away and trying to make money on support.
Why? Users are always in the need of support. They just don't
like to pay for it. That's why they ask the UseNet, Webforums and
the like.
> It's economics 101 - a free market will go to whomever can provide the
> needed service most cheaply. With no barrier to entry, that means as
> soon as the price gets high enough, someone will resell the product for
> less. Which results in razor thin profits, if any at all.
The barrier of entry is building up a support (and testing) group for the
intended audience. That's not easy, so many companies fail to
offer it at a reasonable price and thus with those razor thin
profits. But it is still being tried.
Selling knowlegde works better, then selling IP and leads to
more innovation, because you ALWAYS have to think and rebuild
your knowledge and cannot just develop (or buy) sth. and be done
with it.
> Whether you like it or not, the patent ploy works and there
> isn't a damn thing you can do about it if it is a legit patent.
This stuff works only for lawyers revenues, not for getting
something done. Attacking other and defending a your own property
is important and effective in the short run, but your army will
be out of food soon, if you have more soldiers then farmers
getting sth. done.
Look at the hold times of patents and look at the things you can
do with it. You are not forced to market it, you will not loose
it in a reasonable timeframe (which would be 2-3 years for all
software) or at reasonable events (>70% market share) and you
might even not be forced to license it.
Patents are intellectual property, where intellectual property
can be copied without limits (only the intellectual capacity of
people ;-)) without loosing its public value.
Even now IP doesn't matter that much, because on the biggest
market (the consumer one) it depends on marketing, how big your
revenues are and not really on the superiority of your IP.
And now lets check, what revenue streams Patents create:
Creation:
- If you have an idea, you must check whether it's patented and
a reasonably new idea
-> revenue stream from creator to a lawyer doing the patent research
-> revenue stream from creator to a expert checking the idea
whether its new
-> revenue stream from creator to the patent office for
registering it
While you own it:
- Defending it
-> revenue stream from owner to a lawyer for defending you on court
- Using it
-> revenue stream from owner to laboratory to develop it further
-> revenue stream from owner to factory to produce it
-> revenue stream from owner to marketing dept. to market it
-> revenue stream to owner from sales dept. for selling it
- License it
-> revenue stream to owner from licensee for using it
Getting rid of it:
- Selling it:
-> revenue stream from new owner to old owner
- Trading it for another one:
-> no revenues involved or only involved on one side
While you not own it anymore:
- If you encounter the same problem again
+ you have to license your old patent again
-> revenue stream from creator to owner (stupid laws?)
+ you can think hard, to solve it better this time
-> creation of new patent, revenue streams as described there
+ you can think not so hard, to solve it just different enough
to not violate your old patent (common practise)
-> creation of new patent, revenue streams as described there
- If you want to use a product with your patent included
+ You have to pay the license like everyone else
-> revenue stream from creator to owner (stupid laws?)
So you can easily see, how much the creator who PROVIDED the IP
for the patent will get.
Patents where intended to protect the creators, but are in fact
protecting the owners and make the creators replacable with
cheaper engineers (doing the testing and further development)
after they wrote down the idea and the patent is filed.
This is not very motivating for doing real in depth research or
basic research and leads to the things we see now with OS
development: We benchmark a lot, tune a lot but real ideas are
rare, because they are expensive and nobody pays them.
Analyzing the revenue streams without patents or with more limited
patents (xref: s.a.) is left as an exercise for you to better
defend your arguments ;-)
> If you hold the "It's GPL or bugger off" position, people will figure out
> how to work around it and it is virtually certain you won't like what they
> do. If you offer them some sort of reasonable compromise, I'll bet they
> take it. If you don't, you get to live with whatever their nasty evil
> business minds dream up.
The FSF is fighting against software patents. Better would be to
fight for reasonable adopting software patents to the life cycle
of software and fighting for more revenues to the creators (who
actually getting the work done).
> Ask yourself - how much open source is a reimplementation of what has
> already been designed and implemented, and how much is fundamentally new?
Reimplementation from specification is needed to improve the
quality of the implementation itself. Software reimplementation
is an important part of its life cycle. Also new variants of an
interface and behavior description (which can be patented) are
needed to provide the user with more options and the programmer
with more practise.
Thats the quest of free and open source: Trying to be better.
Trying to be new is the quest of the commercial development,
because new things are the only thing the consumer buys and they
will simply not pay for you correcting your mistakes.
> That new stuff costs huge dollars, not because of the cost of building it,
> but because of the cost of building all the crap that turned out bad
> but provided the insight that lead to the new stuff.
Right. So please make this patented crap (not marketed) and also
the new stuff (marketed) public knowlegde after 1 year and 3 years.
> It's really not
> that hard to reimplement something, open source has proven that beyond
> all doubt. What it hasn't proven is that open source leads to new ideas,
> products, and markets. So far, open source follows, it doesn't lead.
It merely collects and implements public knowledge, that is
scattered everywhere in the world. I look at it as a source code
library for my own (or my employers) needs.
> A reasonable business model might change that. There may be other ways
> to change it, but something needs to change or 20 years from now there
> will be open source versions of all the current popular apps, but still
> playing catch up on the next generation.
Do we want to change that? I don't.
I have no problems paying for bleeding edge and paying nearly
zero for being 2 years behind. People that need bleeding edge are
enough and willing to pay. But I'm also willing to pay for decent
support ;-)
Regards
Ingo Oeser
--
Science is what we can tell a computer. Art is everything else. --- D.E.Knuth
Alan Cox
> Whatever Red Hat does, it will be setting a precedent that will guide
> later followers.
We know this. Red Hat has blazed trails before, as with the IPO friends
and family arrangement. Equally feedback is valuable. It is important we
get it right, and can I ask folks if we don't quite get it right on
round 1 to provide feedback to the Red Hat legal folks. *Productive*
feedback.
Alan
Jonathan Corbet
> be off on some other list, but I don't know what that is.
For what it's worth, something like the Free Software Business List, which
has a (rather minimalistic) web page at http://www.crynwr.com/fsb/,
welcomes this sort of discussion.
jon
Jonathan Corbet
Executive editor, LWN.net
cor...@lwn.net
Gilad Ben-Yossef
> In a message dated 5/28/2002 3:55:00 AM Eastern Daylight Time,
> gi...@benyossef.com writes:
>
>
> > On Tue, 2002-05-28 at 01:24, Larry McVoy wrote:
> >
> > > If the free software community is ever going to really compete with the
> > > non-free software community, they simply have to come up with a better
> > > business model than giving it away and trying to make money on support.
> > > needed service most cheaply. With no barrier to entry, that means as
> > > soon as the price gets high enough, someone will resell the
> > > product for
> > > less. Which results in razor thin profits, if any at all.
> >
> > a "product" or an architect plan for a building is a "product".
>
> be work products, and if I hire a lawyer to draw up a contract for
> me or an architect to design a building for me, unless our agreements
> say otherwise, I own the contract or the building plans.
>
Of course you *can*, but do you (or anyone else) actually does this?
AFAIK this is not a very common business model.
Gilad.
--
Gilad Ben-Yossef <gi...@benyossef.com>
Code mangler, senior coffee drinker and VP SIGSEGV
Qlusters ltd.
"A billion flies _can_ be wrong - I'd rather eat lamb chops than shit."
-- Linus Torvalds on lkml
Oliver Pitzeier
I get this error when trying to compile kernel 2.5.18 on alpha.
Please help me!
[ ... ]
gcc -D__KERNEL__ -I/root/linux-2.5.18/include -Wall -Wstrict-prototypes
-Wno-trigraphs -O2 -fomit-frame-pointer -fno-strict-aliasing -fno-common
-pipe -mno-fp-regs -ffixed-8 -mcpu=ev5 -Wa,-mev6
-DKBUILD_BASENAME=do_mounts -c -o do_mounts.o do_mounts.c
In file included from /root/linux-2.5.18/include/linux/thread_info.h:10,
from /root/linux-2.5.18/include/linux/spinlock.h:7,
from /root/linux-2.5.18/include/linux/tqueue.h:16,
from /root/linux-2.5.18/include/linux/sched.h:10,
from do_mounts.c:4:
/root/linux-2.5.18/include/linux/bitops.h: In function
`get_bitmask_order':
/root/linux-2.5.18/include/linux/bitops.h:77: warning: implicit
declaration of function `fls'
In file included from do_mounts.c:13:
/root/linux-2.5.18/include/linux/suspend.h:4:25: asm/suspend.h: No such
file or directory
make[1]: *** [do_mounts.o] Error 1
make[1]: Leaving directory `/root/linux-2.5.18/init'
make: *** [_dir_init] Error 2
[ ... ]
Greetz,
Oliver
Ivan Kokshaysky
> I get this error when trying to compile kernel 2.5.18 on alpha.
Just intended to post the patch... :-)
- sync up with new pte/pfn/page/tlb macros
- pcibios_init() should return int;
- find last bit set: ctlz for ev67 and above, generic for others.
> /root/linux-2.5.18/include/linux/suspend.h:4:25: asm/suspend.h: No such
> file or directory
I'm not sure what to do with this. I doubt that we ever want this
file on alpha. For myself I moved "#include <asm/suspend.h>"
under #ifdef CONFIG_SOFTWARE_SUSPEND and everything compiles.
Ivan.
--- 2.5.18/arch/alpha/kernel/signal.c Sat May 25 05:55:26 2002
+++ linux/arch/alpha/kernel/signal.c Mon May 27 16:06:22 2002
@@ -18,6 +18,7 @@
#include <linux/smp_lock.h>
#include <linux/stddef.h>
#include <linux/tty.h>
+#include <linux/binfmts.h>
#include <asm/bitops.h>
#include <asm/uaccess.h>
--- 2.5.18/arch/alpha/kernel/osf_sys.c Sat May 25 05:55:16 2002
+++ linux/arch/alpha/kernel/osf_sys.c Mon May 27 16:06:22 2002
@@ -33,6 +33,7 @@
#include <linux/file.h>
#include <linux/types.h>
#include <linux/ipc.h>
+#include <linux/namei.h>
#include <asm/fpu.h>
#include <asm/io.h>
--- 2.5.18/arch/alpha/kernel/pci.c Sat May 25 05:55:19 2002
+++ linux/arch/alpha/kernel/pci.c Mon May 27 17:07:15 2002
@@ -193,12 +193,12 @@ pcibios_align_resource(void *data, struc
#undef MB
#undef GB
-static void __init
+static int __init
pcibios_init(void)
{
- if (!alpha_mv.init_pci)
- return;
- alpha_mv.init_pci();
+ if (alpha_mv.init_pci)
+ alpha_mv.init_pci();
+ return 0;
}
subsys_initcall(pcibios_init);
--- 2.5.18/include/asm-alpha/page.h Sat May 25 05:55:29 2002
+++ linux/include/asm-alpha/page.h Mon May 27 16:27:39 2002
@@ -95,8 +95,12 @@ extern __inline__ int get_order(unsigned
#define __pa(x) ((unsigned long) (x) - PAGE_OFFSET)
#define __va(x) ((void *)((unsigned long) (x) + PAGE_OFFSET))
#ifndef CONFIG_DISCONTIGMEM
-#define virt_to_page(kaddr) (mem_map + (__pa(kaddr) >> PAGE_SHIFT))
-#define VALID_PAGE(page) (((page) - mem_map) < max_mapnr)
+#define pfn_to_page(pfn) (mem_map + (pfn))
+#define page_to_pfn(page) ((unsigned long)((page) - mem_map))
+#define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT)
+
+#define pfn_valid(pfn) ((pfn) < max_mapnr)
+#define virt_addr_valid(kaddr) pfn_valid(__pa(kaddr) >> PAGE_SHIFT)
#endif /* CONFIG_DISCONTIGMEM */
#define VM_DATA_DEFAULT_FLAGS (VM_READ | VM_WRITE | VM_EXEC | \
--- 2.5.18/include/asm-alpha/pgtable.h Sat May 25 05:55:22 2002
+++ linux/include/asm-alpha/pgtable.h Mon May 27 16:27:39 2002
@@ -179,11 +179,12 @@ extern unsigned long __zero_page(void);
#endif
#if defined(CONFIG_ALPHA_GENERIC) || \
(defined(CONFIG_ALPHA_EV6) && !defined(USE_48_BIT_KSEG))
-#define PHYS_TWIDDLE(phys) \
- ((((phys) & 0xc0000000000UL) == 0x40000000000UL) \
- ? ((phys) ^= 0xc0000000000UL) : (phys))
+#define KSEG_PFN (0xc0000000000UL >> PAGE_SHIFT)
+#define PHYS_TWIDDLE(pfn) \
+ ((((pfn) & KSEG_PFN) == (0x40000000000UL >> PAGE_SHIFT)) \
+ ? ((pfn) ^= KSEG_PFN) : (pfn))
#else
-#define PHYS_TWIDDLE(phys) (phys)
+#define PHYS_TWIDDLE(pfn) (pfn)
#endif
/*
@@ -199,12 +200,13 @@ extern unsigned long __zero_page(void);
#endif
#ifndef CONFIG_DISCONTIGMEM
+#define pte_pfn(pte) (pte_val(pte) >> 32)
+#define pte_page(pte) pfn_to_page(pte_pfn(pte))
#define mk_pte(page, pgprot) \
({ \
pte_t pte; \
\
- pte_val(pte) = ((unsigned long)(page - mem_map) << 32) | \
- pgprot_val(pgprot); \
+ pte_val(pte) = (page_to_pfn(page) << 32) | pgprot_val(pgprot); \
pte; \
})
#else
@@ -219,10 +221,20 @@ extern unsigned long __zero_page(void);
\
pte; \
})
+#define pte_page(x) \
+({ \
+ unsigned long kvirt; \
+ struct page * __xx; \
+ \
+ kvirt = (unsigned long)__va(pte_val(x) >> (32-PAGE_SHIFT)); \
+ __xx = virt_to_page(kvirt); \
+ \
+ __xx; \
+})
#endif
-extern inline pte_t mk_pte_phys(unsigned long physpage, pgprot_t pgprot)
-{ pte_t pte; pte_val(pte) = (PHYS_TWIDDLE(physpage) << (32-PAGE_SHIFT)) | pgprot_val(pgprot); return pte; }
+extern inline pte_t pfn_pte(unsigned long physpfn, pgprot_t pgprot)
+{ pte_t pte; pte_val(pte) = (PHYS_TWIDDLE(physpfn) << 32) | pgprot_val(pgprot); return pte; }
extern inline pte_t pte_modify(pte_t pte, pgprot_t newprot)
{ pte_val(pte) = (pte_val(pte) & _PAGE_CHG_MASK) | pgprot_val(newprot); return pte; }
@@ -233,20 +245,6 @@ extern inline void pmd_set(pmd_t * pmdp,
extern inline void pgd_set(pgd_t * pgdp, pmd_t * pmdp)
{ pgd_val(*pgdp) = _PAGE_TABLE | ((((unsigned long) pmdp) - PAGE_OFFSET) << (32-PAGE_SHIFT)); }
-#ifndef CONFIG_DISCONTIGMEM
-#define pte_page(x) (mem_map+(unsigned long)((pte_val(x) >> 32)))
-#else
-#define pte_page(x) \
-({ \
- unsigned long kvirt; \
- struct page * __xx; \
- \
- kvirt = (unsigned long)__va(pte_val(x) >> (32-PAGE_SHIFT)); \
- __xx = virt_to_page(kvirt); \
- \
- __xx; \
-})
-#endif
extern inline unsigned long
pmd_page_kernel(pmd_t pmd)
--- 2.5.18/include/asm-alpha/tlb.h Sat May 25 05:55:25 2002
+++ linux/include/asm-alpha/tlb.h Mon May 27 16:06:22 2002
@@ -1 +1,15 @@
+#ifndef _ALPHA_TLB_H
+#define _ALPHA_TLB_H
+
+#define tlb_start_vma(tlb, vma) do { } while (0)
+#define tlb_end_vma(tlb, vma) do { } while (0)
+#define tlb_remove_tlb_entry(tlb, pte, addr) do { } while (0)
+
+#define tlb_flush(tlb) flush_tlb_mm((tlb)->mm)
+
#include <asm-generic/tlb.h>
+
+#define pte_free_tlb(tlb,pte) pte_free(pte)
+#define pmd_free_tlb(tlb,pmd) pmd_free(pmd)
+
+#endif
--- 2.5.18/include/asm-alpha/bitops.h Sat May 25 05:55:27 2002
+++ linux/include/asm-alpha/bitops.h Mon May 27 16:27:39 2002
@@ -315,6 +315,20 @@ static inline int ffs(int word)
return word ? result+1 : 0;
}
+/*
+ * fls: find last bit set.
+ */
+#if defined(__alpha_cix__) && defined(__alpha_fix__)
+static inline int fls(int word)
+{
+ long result;
+ __asm__("ctlz %1,%0" : "=r"(result) : "r"(word & 0xffffffff));
+ return 64 - result;
+}
+#else
+#define fls generic_fls
+#endif
+
/* Compute powers of two for the given integer. */
static inline int floor_log2(unsigned long word)
{
Adam J. Richter
>I don't think you can realistically expect all open source licenses like
>the BSD one to be accomodated. Otherwise people would ship binary apps
>linked with a BSD licensed libpatent.o/c that was useless to anyone. The
>GPL restrictions happen to work very nicely in terms of making a patent
>available for free software (or one definition thereof), the BSD license
>alas doesn't.
You could license all programs that consist entirely of
free software. That way, BSD, LGPL, and MPL software that did
not link in proprietary software would be allowed too, but your
example of a proprietary program that linked in the BSD'ed
libpatent.o/c would not be covered by this permission.
Licensing all programs that consist entirely of free
software would address issues like GPL'ed software that contains
content that is GPL compatible but not GPL'ed, future versions of
the GPL, what happens if a court ruling opens a loophole in the
GPL, and practicing the patent with free software in other free
operating systems.
Adam J. Richter __ ______________ 575 Oroville Road
ad...@yggdrasil.com \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
Alan Cox
> You could license all programs that consist entirely of
> free software. That way, BSD, LGPL, and MPL software that did
> not link in proprietary software would be allowed too, but your
> example of a proprietary program that linked in the BSD'ed
> libpatent.o/c would not be covered by this permission.
Define "free software" using only legally defined phrases which have
precedent. In fact put four people in a room and get them to define free
software.
> software would address issues like GPL'ed software that contains
> content that is GPL compatible but not GPL'ed, future versions of
If its linked then it is GPL in the linked form, otherwise you wouldn't
be allowed to link it
Alan
Andre Hedrick
There is a major problem with your argument.
"FREE" is covered in BLACK's Book.
"RELEASE" is not. RMS specifically picked "RELEASE" in the GPL to force a
litigation in court. "RELEASE" is subjective to the reviewing body.
Cheers,
Andre Hedrick
LAD Storage Consulting Group
-
Eric W. Biederman
> Jumping on the chance to cause more discussion... This probably ought to
> be off on some other list, but I don't know what that is. Alan will be
> sending out the guards to herd me back into the ward, but I've escaped
> for the moment and I'll make the best of it :)
[snip]
> If you hold the "It's GPL or bugger off" position, people will figure out
> how to work around it and it is virtually certain you won't like what they
> do. If you offer them some sort of reasonable compromise, I'll bet they
> take it. If you don't, you get to live with whatever their nasty evil
> business minds dream up.
To a certain extent other people's business model is none of your
business. The only people who have a reasonable right to ask that
question is the company itself, and it's investors. And support is
far from being the only viable GPL compatible business model.
Most new businesses fail, even when they are using known proven
business models. It is execution, and being in the right place at the
right time that make a successful company.
For the GPL or bugger off folks, unless you have a business model
that delivers GPL'd code to them, you don't make any money from them.
Not offering them the GPL violates ``The customer is always right''.
Of course it is perfectly fine to concentrate on those people who you
can figure out how to make money from.
There is only one test for a successful business model, is the company
here making money 20 years from now. That test is going to take a
while.
Eric
Pavel Machek
> isn't really up to it. Right now we are building cathedrals in the same
> way as a medaeival master mason, by intutition, experience, and testing.
> We have no more idea than they do if any given edifice will come
> crashing down (as several large medaeival ones indeed did).
Well, inability to prove cathedral stability did not stop those people
from building them, and inability to prove stability of Linx does not
stop people from using it, too. (I've seen machine for monitoring patients
build from "not to use in life-support" chips and running linux.)
Pavel
--
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Adam J. Richter
>On Tue, 2002-05-28 at 18:13, Adam J. Richter wrote:
>> You could license all programs that consist entirely of
>> free software. That way, BSD, LGPL, and MPL software that did
>> not link in proprietary software would be allowed too, but your
>> example of a proprietary program that linked in the BSD'ed
>> libpatent.o/c would not be covered by this permission.
>
>Define "free software" using only legally defined phrases which have
>precedent. In fact put four people in a room and get them to define free
>software.
Many if not all legal documents contain more than
"only legally defined phrases which have precedent." I'm sure Red Hat
has signed many. You can reasonably find a definition that covers 99%
of what people consider free software and make subsequent grants later.
In the other direction, if you accidentally include some less than
free software, that should not matter much if you are only taking out
these patents for "defensive" purposes.
Example definitions might be: "public domain or any license
certified by the Open Software Initiative", "a license that has
no more restrictions than version 2 of the GNU General Public License
as published by the Free Software Foundation ("or any subsequent
version"?)." You could also cut and paste from OSI or Debian bullet
items.
More importantly, licensing patents only for pure GPL'ed use
is unlikely to become a norm that you can expect broad adoption of
in free software businesses, as many of them tend to be proponents of
slightly different copying permissions. If we have a bunch of patents
licensed for GPL-only, another bunch for MPL-only, another bunch for
pure-BSD only, then the patent proliferation that I described
yesterday will still probably occur.
You have a fleeting opportunity to possibly head most of this
off, but you have to look beyond just your favorite license. Many
developers and even companies' managements identify strongly with their
favorite licenses, and feel personally about their ability to develop
free software under those licenses. If the GPL developers don't shield
the Apache developers, the X developers, the BSD developers, and the
MPL developers so that their ability to continue with the free software
portion of their activities has been respected, do you really think
they'll shield GPL development from their patents?
Adam J. Richter __ ______________ 575 Oroville Road
ad...@yggdrasil.com \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
Alan Cox
> Example definitions might be: "public domain or any license
> certified by the Open Software Initiative", "a license that has
The OSI approves things like the BSD license which is a convenient open
door for anyone to use such patents in proprietary code with a tiny
useless BSD licensed library. That doesn't further free software, it
doesn't provide opportunities for co-operative cross licensing to get
GPL rights to other patents from the proprietary world and so forth.
Being in a position where as part of the normal processes of proprietary
software design we can get other companies to give free software access
to some patents in return for access to use some our stuff proprietary
is a win.
I would worry much more about the million odd patents IBM have, where
IBM have no general statement of this nature than the Red Hat ones.
Perhaps once the Red Hat statement is published IBM can be persuaded to
show willing ?
> More importantly, licensing patents only for pure GPL'ed use
> is unlikely to become a norm that you can expect broad adoption of
> in free software businesses, as many of them tend to be proponents of
> slightly different copying permissions. If we have a bunch of patents
> licensed for GPL-only, another bunch for MPL-only, another bunch for
> pure-BSD only, then the patent proliferation that I described
> yesterday will still probably occur.
I would agree to an extent. Certainly purely GPL is excluding stuff
which has identical 'all of package' rules like db3, Qt free editions,
and much of KDE.
> free software under those licenses. If the GPL developers don't shield
> the Apache developers, the X developers, the BSD developers, and the
> MPL developers so that their ability to continue with the free software
> portion of their activities has been respected, do you really think
> they'll shield GPL development from their patents?
There is little evidence of that having happened with code, its also
possible to extend lists of licenses, clarify them for specific product
and so forth.
Alan
Jonathan Corbet
> I would worry much more about the million odd patents IBM have, where
> IBM have no general statement of this nature than the Red Hat ones.
> Perhaps once the Red Hat statement is published IBM can be persuaded to
> show willing ?
For what it's worth, the Red Hat statement is at:
http://www.redhat.com/legal/patent_policy.html
No patent enforcement against you if you're using a Red Hat-approved open
source license - their list does not include BSD.
jon
Jonathan Corbet
Executive editor, LWN.net
cor...@lwn.net
Jamie Lokier
> Alan said:
> > I would worry much more about the million odd patents IBM have, where
> > IBM have no general statement of this nature than the Red Hat ones.
> > Perhaps once the Red Hat statement is published IBM can be persuaded to
> > show willing ?
>
> For what it's worth, the Red Hat statement is at:
>
> http://www.redhat.com/legal/patent_policy.html
>
> No patent enforcement against you if you're using a Red Hat-approved open
> source license - their list does not include BSD.
The Red Hat-approved licences don't include LGPL either.
Red Hat's definition of "Open Source/Free Software" ("means any software
which is licensed under an Approved License.") could do with some
clarification.
I wonder what their stance is if I dual license under BSD and GPL. Do I
have to be explicit about it? Or is that too loose - must it be GPL only?
I wonder if that means I have to explicitly list my high performance web
server, which takes advantage of the patented directory lookup of
course, as dual licensed under GPL and LGPL, or if that is taken as
implied.
etc.
-- Jamie
Nicholas Knight
From: "Jamie Lokier" <l...@tantalophile.demon.co.uk>
To: "Jonathan Corbet" <corb...@lwn.net>
Cc: <linux-...@vger.kernel.org>; "Alan Cox" <al...@lxorguk.ukuu.org.uk>
Sent: Wednesday, May 29, 2002 9:15 AM
Subject: Re: business models [was patent stuff]
> Jonathan Corbet wrote:
> > Alan said:
> > > I would worry much more about the million odd patents IBM have, where
> > > IBM have no general statement of this nature than the Red Hat ones.
> > > Perhaps once the Red Hat statement is published IBM can be persuaded
to
> > > show willing ?
> >
> > For what it's worth, the Red Hat statement is at:
> >
> > http://www.redhat.com/legal/patent_policy.html
> >
> > No patent enforcement against you if you're using a Red Hat-approved
open
> > source license - their list does not include BSD.
>
> The Red Hat-approved licences don't include LGPL either.
>
> Red Hat's definition of "Open Source/Free Software" ("means any software
> which is licensed under an Approved License.") could do with some
> clarification.
>
The definition of "defensive patent" could do with some reassesment.
The only way I can see a software patent as truely defensive, is if it's
explicitly
licensed for use by anyone, anywhere, for anything, under any software
license.
The only thing it should be used to defend against is someone else patenting
it
and denying Red Hat the right to use it, it shouldn't be used to prevent
others,
no matter who they are, from using it.
If there's a proper name for what Red Hat now has, it's "Free Software
Foundation Compliant" and "Linux Specific". This isn't a defensive patent,
it's
a patent filed for the express purpose of preventing systems besides Linux
from taking advantage of the techniques covered by the patent.
Off the top of my head, I can think of only one at least somewhat-known OS
licensed under any of their "approved" licenses, and that's AtheOS (GPL).
Relatively few people use AtheOS yet, and I doubt that will change soon.
On the other hand, at the very front of my mind at all times are the names
of
three fairly well-known systems that are in fairly wide-spread use and are
decidedly open source:
FreeBSD (significant widespread use)
NetBSD
OpenBSD
I don't care what anybody's personal opinion of these systems is, they are
Free and Open Souce in every sense of the terms, and a lot of people use
them. There's just one problem, they're frequently in direct competition
with Linux. And since Red Hat is decidedly the front-man of the U.S.
Linux distribution market, they are directly in competition with Red Hat.
Rather convenient that they can't make use of the patent, isn't it?
Of course, if Red Hat went to the logical conclusion of opening the patent
for use, Microsoft would end up able to use the patent, and I doubt anyone
but Microsoft would really want that. Hence this solution:
Explicitly license the patent to anyone and everyone, EXCEPT Microsoft.
Why do I not have a problem with not allowing Microsoft to use it?
Simple, they've been caught, in very recent history, using very illiegal
business practices. They shouldn't have the right to use their *own*
patents.
Of course, this still leaves it open to other competitors, and we can't have
that, now can we?
> I wonder what their stance is if I dual license under BSD and GPL. Do I
You certainly could, but I doubt there would be any point. The software
has to be under the terms of the GPLv2, IBM PL v1, CPL v0.5, QPLv1,
or any of Red Hat's Open Source licenses in order for the patented
method to be used.
> have to be explicit about it? Or is that too loose - must it be GPL only?
>
> I wonder if that means I have to explicitly list my high performance web
> server, which takes advantage of the patented directory lookup of
> course, as dual licensed under GPL and LGPL, or if that is taken as
> implied.
I could see splitting components up, some under GPL, some under LGPL.
But then you have the issue you're already familier with with FSMLabs'
patent, calls to the GPL'd code may have to be made by GPL'd code only.
Adam J. Richter
>On Wed, 2002-05-29 at 04:21, Adam J. Richter wrote:
>> Example definitions might be: "public domain or any license
>> certified by the Open Software Initiative", "a license that has
>The OSI approves things like the BSD license which is a convenient open
>door for anyone to use such patents in proprietary code with a tiny
>useless BSD licensed library. [...]
I addressed that previously: you can license just the case
where the entire program is free software. Patents restrict use, not
just copying. So, it is hard to argue against the enforceability of
"user does the link" subversion when it comes to patents, which I
infer is your principal objection.
>I would worry much more about the million odd patents IBM have, [...]
I addressed that previously:
| Although other companies today already have many patents that
| | they could argue are infringed by certain free software components.
| The Linux patents are different as a practical matter, however, in
| that the chance of prevailing in that argument will be greater when
| if alleged infringer is using the code for which the patent was
| originally submitted.
[...]
>> If the GPL developers don't shield
>> the Apache developers, the X developers, the BSD developers, and the
>> MPL developers so that their ability to continue with the free software
>> portion of their activities has been respected, do you really think
>> they'll shield GPL development from their patents?
>There is little evidence of that having happened with code,
Linux distribution vendors make a lot of money from combining
and selling the work of these other free software development
communities. These other communities currently do a lot of work to
ensure that their software runs under our GPL'ed kernel and LGPL'ed C
library. The GPL developers are supported in the other direction too:
plenty of GPL'ed software runs under BSD-permission platforms like
tcl, or Apache or on BSD. Even with the Linux kernel, you have Dave
Hinds relicensing his MPL pcmcia drivers for GPL linking, and sixty
two modules in linux-2.5.18 contain MODULE_LICENSE declarations of
"Dual BSD/GPL", plus two others that are just BSD.
You would have no Linux distribution if you only shipped
GPL'ed software, or even if the non-GPL free software communities
stopped their continuing substantial efforts to ensure that their
applications run Linux, compile under GCC and binutils, and
interoperate with a host of other GPL'ed components.
What more should the non-GPL free software communities have
done that now justifies your not licensing your patents for their free
software development?
>its also
>possible to extend lists of licenses, clarify them for specific product
>and so forth.
If you "extend lists of licenses" _at the outset_, you will
discourage patenting of the non-GPL software you use. Otherwise, I
think the practice will quickly proliferate if other free software
companies see that their users and contributors tolerate Red Hat
taking out patents on free software implementations and licensing it
GPL-only. I think subsequent extensions would have less of of a
standards setting effect.
Adam J. Richter __ ______________ 575 Oroville Road
ad...@yggdrasil.com \ / Milpitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
David Weinehall
> On Tue, 2002-05-28 at 18:13, Adam J. Richter wrote:
> > You could license all programs that consist entirely of
> > free software. That way, BSD, LGPL, and MPL software that did
> > not link in proprietary software would be allowed too, but your
> > example of a proprietary program that linked in the BSD'ed
> > libpatent.o/c would not be covered by this permission.
>
> Define "free software" using only legally defined phrases which have
> precedent. In fact put four people in a room and get them to define free
> software.
>
> > software would address issues like GPL'ed software that contains
> > content that is GPL compatible but not GPL'ed, future versions of
>
> If its linked then it is GPL in the linked form, otherwise you wouldn't
> be allowed to link it
An interesting question is whether the licensing terms used for this
patent would pass the DFSG (Debian Free Software Guidelines)?!
/David
_ _
// David Weinehall <t...@acc.umu.se> /> Northern lights wander \\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
Greg KH
>
> An interesting question is whether the licensing terms used for this
> patent would pass the DFSG (Debian Free Software Guidelines)?!
According to the folks on debian-legal, there's already other portions
of the kernel that do not pass those guidelines :)
greg k-h
Oliver Pitzeier
Greetz,
Oliver
David Woodhouse
If you're not capable of reading the list archives, and picking up the
patches which I believe I recall seeing, then no - I suspect you are indeed
beyond help.
--
dwmw2
Perry The Cynic
> The definition of "defensive patent" could do with some reassesment.
>
> The only way I can see a software patent as truely defensive, is if it's
> explicitly
> licensed for use by anyone, anywhere, for anything, under any software
> license.
> The only thing it should be used to defend against is someone else patenting
> it
> and denying Red Hat the right to use it, it shouldn't be used to prevent
> others,
> no matter who they are, from using it.
There is a much more aggressive use that arguably is still defensive. It's
a formal codification of the way patents are often used by corporations
these days. It goes like this:
"You have a license to use this patent, without fees or restrictions, in
any of your products as long as you do not raise any claims from any of
*your* patents, of any form, against any of our products, except when
such patent includes license terms that are no worse than this license."
In real life, this is hellaciously hard to express in such a way that it
can't be worked around. (One obvious attack is to fork off an "independent"
subsidiary that raises patent claims on your behalf.) Which is why this kind
of strategy is usually implemented by staff lawyers playing "tit for tat"
with the other guy's staff lawyers.
Cheers
-- perry
---------------------------------------------------------------------------
Perry The Cynic pe...@cynic.org
To a blind optimist, an optimistic realist must seem like an Accursed Cynic.
---------------------------------------------------------------------------
Oliver Pitzeier
> On Tue, May 28, 2002 at 04:29:15PM +0200, Oliver Pitzeier wrote:
> > I get this error when trying to compile kernel 2.5.18 on alpha.
>
> Just intended to post the patch... :-)
>
> - sync up with new pte/pfn/page/tlb macros
> - pcibios_init() should return int;
> - find last bit set: ctlz for ev67 and above, generic for others.
>
> > /root/linux-2.5.18/include/linux/suspend.h:4:25: asm/suspend.h: No
> > such file or directory
>
> I'm not sure what to do with this. I doubt that we ever want
> this file on alpha. For myself I moved "#include
> <asm/suspend.h>" under #ifdef CONFIG_SOFTWARE_SUSPEND and
> everything compiles.
Yes. It does! Great job! But there are new problems with 2.5.20. I try
to catch 'em. I may find the gizmo... :o)
I you want to know the error:
gcc -D__KERNEL__ -I/usr/src/linux-2.5.20/include -Wall
-Wstrict-prototypes -Wno-trigraphs -O2 -fomit-frame-pointer
-fno-strict-aliasing -fno-common -pipe -mno-fp-regs -ffixed-8 -mcpu=ev5
-Wa,-mev6 -DKBUILD_BASENAME=main -c -o main.o main.c
In file included from /usr/src/linux-2.5.20/include/linux/pagemap.h:10,
from /usr/src/linux-2.5.20/include/linux/blkdev.h:9,
from /usr/src/linux-2.5.20/include/linux/blk.h:4,
from main.c:25:
/usr/src/linux-2.5.20/include/linux/highmem.h:80:42: macro
"clear_user_page" passed 3 arguments, but takes just 2
/usr/src/linux-2.5.20/include/linux/highmem.h:114:45: macro
"copy_user_page" passed 4 arguments, but takes just 3
In file included from /usr/src/linux-2.5.20/include/linux/pagemap.h:10,
from /usr/src/linux-2.5.20/include/linux/blkdev.h:9,
from /usr/src/linux-2.5.20/include/linux/blk.h:4,
from main.c:25:
/usr/src/linux-2.5.20/include/linux/highmem.h: In function
`clear_user_highpage':
/usr/src/linux-2.5.20/include/linux/highmem.h:80: `clear_user_page'
undeclared (first use in this function)
/usr/src/linux-2.5.20/include/linux/highmem.h:80: (Each undeclared
identifier is reported only once
/usr/src/linux-2.5.20/include/linux/highmem.h:80: for each function it
appears in.)
/usr/src/linux-2.5.20/include/linux/highmem.h:79: warning: unused
variable `addr'
/usr/src/linux-2.5.20/include/linux/highmem.h: In function
`copy_user_highpage':
/usr/src/linux-2.5.20/include/linux/highmem.h:114: `copy_user_page'
undeclared (first use in this function)
make[1]: *** [main.o] Error 1
make[1]: Leaving directory `/usr/src/linux-2.5.20/init'
make: *** [init] Error 2
Greetz,
Oliver