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

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

[Andrea Arcangeli]

[ 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/

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

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

[Anton Altaparmakov]

[Andrew Morton removed from CC: list as he doesn't want to be on it...]

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/

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[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

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

[Karim Yaghmour]

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

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

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

Next came the first version of the patent license. That version
violated the GPL itself, requiring you to register all the users
of the software with FSMLabs. Plus, it had the following "APPROVED
USE" section:
	In addition to the other terms and conditions of this License, use
	of the Patented Process is permitted, without fee or royalty, when used:

		A.	By software licensed under the GPL; or 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Best regards,

Karim

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

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

[Larry McVoy]

On Fri, May 24, 2002 at 07:05:13PM -0400, Karim Yaghmour wrote:
> This matter remained unchanged until the FSF came out later and
> declared publicly that the patent was violating the GPL. At that
> time, Eben Moglen came out and publicly explained the implications
> of the patent and the "corrected" patent license. Here is Eben's
> explanation:
> http://www.aero.polimi.it/~rtai/documentation/articles/moglen.html

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

> All would have been fine if things had ended there, but Victor then
> came out and threw more uncertainty about the matter:
> http://linuxdevices.com/articles/AT6164867514.html
> 
> Just when Eben Moglen was saying that real-time applications were
> not subject to the patent, Victor Yodaiken came out and said:
> "If you want to make, use, sell, distribute, import,
> etc. non-GPL software -- regardless of whether such software is labeled as
> an "application," "module," or anything else -- please make sure you have
> obtained competent legal advice regarding whether your software and its use
> is an approved use under the Open RTLinux Patent License or whether a
> license under the RTLinux patent must be secured to authorize your software
> and its use."

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

> At this point in time, all the bleeding-edge development being
> done in RTLinux is not available in GPL and must be purchased for
> a fee.
> 
> This isn't really a problem, since RTAI has now surpassed RTLinux
> in terms of capabilities, ports and support. The problem, however,
> is that the rtlinux patent is being used to wage an FUD campaign
> against RTAI.

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

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

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

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

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

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

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

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Larry McVoy]

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

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

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

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

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

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

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

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

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

[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-advocacy@rtlinux.org
rtai@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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Larry McVoy]

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

Yup, happens all the time.  

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

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

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

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

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

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

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

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

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

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Thunder from the hill]

Hi,

On Fri, 24 May 2002, Larry McVoy wrote:
> Then you have absolutely no beef with the FSMlabs patent.  Let's review:
> 
>     a) you get to use it if the stuff built on it, all of it, is GPLed.
>     b) you build on GPLed stuff.
> 
> Seems like you either have no problem or you aren't disclosing the whole
> story.  I really don't understand why there is a problem here.   100%
> GPLed is OK, so why do you have a problem?

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

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

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

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

3. They go buy another real time os implementation.

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

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

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

[Larry McVoy]

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

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

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

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Larry McVoy]

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

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

I don't buy your assertions for one second without some strong data to
back them up.  Just saying something doesn't make it so, show me the
data.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Robert Schwebel]

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. 

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

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

[Andrew Morton]

Robert Schwebel wrote:
> 
> 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?

-

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

[Robert Schwebel]

On Sat, May 25, 2002 at 06:06:46PM -0700, Andrew Morton wrote:
> 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    |
 +--------------------------------------------------------+

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

[Kurt Wall]

{CCs trimmed]

Scribbling feverishly on May 25, Karim Yaghmour managed to emit:
> 
> Larry McVoy wrote:
> > 4.  Contact FSMlabs, ask about licensing costs, compare to #3 and go with
> >     #4 if it makes sense.
> 
> Many people have said this before and I will say it again: Linux is
> fine as an open-source/free-software rtos, but as a non-free rtos it
> has no chance in front of the competition.

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

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

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

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

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

[Wolfgang Denk]

In message <20020525134709.L405@marta> Kurt Wall 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.
> 
> 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.

...which are the only available free / GPL solutions. This is  reason
enough  to  be  scared.  And  some  versions  of RTLinux are not even
available under  GPL  (like  RTLinux  for  MPC8xx  CPUs).  RTAI  _is_
available,  and  under  GPL, but the reputation is suffering under he
patent FUD.

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"There are things that are so serious that you can  only  joke  about
them"                                                    - Heisenberg

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

[Daniel Phillips]

On Saturday 25 May 2002 20:13, Wolfgang Denk wrote:
> In message <20020525134709.L405@marta> Kurt Wall 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.
> > 
> > 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.
> 
> ...which are the only available free / GPL solutions. This is  reason
> enough  to  be  scared.  And  some  versions  of RTLinux are not even
> available under  GPL  (like  RTLinux  for  MPC8xx  CPUs).  RTAI  _is_
> available,  and  under  GPL, but the reputation is suffering under he
> patent FUD.

Speaking for myself, this thread has completely changed my perception of
RTAI.  And yes, I am one of those who was taken in by the FUD.  Thankyou
to Karim for presenting the facts logically, with patience and restraint,
and I apologize for having listened overly much to the makers of the
greatest noise.

I'm particularly interested in the notion that properties we normally
think of as exclusively the domain of the kernel can be extended to user
space, in the way that RTAI creates a mechanism for hard realtime
scheduling, then extends it beyond the boundaries of the kernel.  Such
extension of a state machine rooted in the kernel is powerful and
useful.

When we blur the boundaries of the kernel in this way, we invite the
question: what is the kernel, really?  I see the function of the kernel
as being increasingly concerned with security, and the real heavy
lifting increasingly being carried out in user space, with only
occasional need to cross the kernel boundary, and that mainly for the
purpose of initializing some mechanism that allows work to be done
in user space.

An recent example of this trend is the work on user-space semaphores.  A
less recent example is the X15 html daemon, which reportedly outperforms
the in-kernel TUX daemon.

-- 
Daniel

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Mark Mielke]

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

> He ends his article with the following:
> "It seems to me, RTLinux is a fine system with great potential when thought
> of as an open-source project. I'm not sure it will fare as well when looked
> at as a commercial RTOS."

This looks exactly like a party line to me. In fact, the same
statement could be made by the FSF for every single application that
currently exists.

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

mark

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

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

                           http://mark.mielke.cc/

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

[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

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Daniel Phillips]

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.

-- 
Daniel

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

[Andre Hedrick]

On Sat, 25 May 2002, Daniel Phillips wrote:

> On Saturday 25 May 2002 19:49, Karim Yaghmour wrote:
> > > The thing that disgusts me is that this "patent" thing is used as a
> > > complete red herring, and the real issue is that some people don't like
> > > the fact that the kernel is under the GPL. Tough cookies.
> > 
> > I have no disagreement with the kernel being GPL.
> 
> I'd like to take this opportunity to take a turn back towards the original
> issue: supposing that Ingo's/Red Hat's patented extension to the dcache is
> accepted into the kernel.  Would not the GPL's patent trap provision
> prevent Red Hat from distributing the result, unless Red Hat also provides
> a license for the patent permitting unrestricted use *regardless of
> commercial or noncommercial use* of the patent in the context of the GPL'd
> code?  So it's either provide the license, or don't incorporate the code
> into Linux.  (The issue of whether it's a good thing that the latter course
> would also foreclose anybody else from using the same technique is
> separate.)
> 
> Supposing that Red Hat distributes a version of Linux accompanied with the
> appropriate license, so that the result can be distributed in compliance
> with the GPL: could Red Hat then prevent other distributors from
> distributing their own version of Linux that has the same extension?  I
> hope not, otherwise we have a real problem.

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

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

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

Andre Hedrick
LAD Storage Consulting Group

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

[Alan Cox]

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.

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

[Andre Hedrick]

On 26 May 2002, Alan Cox wrote:

> 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

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

[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

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Wolfgang Denk]

In message <Pine.LNX.4.44.0205251015350.6515-100000@home.transmeta.com>
you 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.

This is your interpretation, and it is not correct.

> 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

I'm not sure if you really bothered to read what Karim wrote. The GPL
itsef is not the problem, as long as you can draw a line between some
"base  system"  (which  is  strictly  GPL  -  like  RTAI)  and   some
application code.

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. It seems, this is not a  problem  with  Linux.  But
FSMlabs spreads FUD trying to prevent this for all RT stuff.

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?

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Testing can show the presense of bugs, but not their absence.
                                                   -- Edsger Dijkstra

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

[Larry McVoy]

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

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

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

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

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

[Wolfgang Denk]

In message <20020525110208.A15969@work.bitmover.com> you wrote:
> On Sat, May 25, 2002 at 07:50:30PM +0200, Wolfgang Denk wrote:
> > I do like it very much when all code I write is GPLed, but there  are
> > situations  where  a there are good reasons for some application code
> > to remain closed. 
> 
> Yeah, like you're trying to make money.  Which is fine.  But if that 

No. Actually this is _NOT_ my concern. I get payed for the software I
develop no matter if it's free software or propretary stuff, so  from
the monetary point of view I don't have to care.

> "application" needs to use the RT/Linux patent in order to work, it
> either has to buy a license or be GPLed.

But this is an ADDITIONAL restriction, which violates the GPL,  which
is the base of the RTL code, or isn't it?

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

What they say (in public), and what they actually do,  are  different
things.

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

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

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"If that makes any sense to you, you have a big problem."
                                  -- C. Durance, Computer Science 234

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

[Larry McVoy]

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

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

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

> > Maybe Victor should have used a different model: if no money changes hands,
> > then it's free to use the patent, if money changes hand, FSMlabs wants a 
> 
> Define  "if  money  changes  hand".  Let's  say  I  develop  a  smart
> controller  software for disk drives, and I give it (maybe for money,
> maybe for free, maybe under  GPL  or  not)  to  IBM  and  Maxtor  and
> Seagate.  The  disk manufacturers make modifications to the code, and
> embed it into their disk drives. Then they sell the  drives  to  Dell
> and HP and ... Those sell PCs to many, many vendors, who sell the PCs
> to you and men and ...

Definitely "money changed hands".

> > cut.  I think that was the intent, but as with all things, it's hard to 
> > state that clearly in a legal document.  If that was the intent, I support
> > it, I think it's perfectly reasonable.  
> 
> If that was the case, Victor should have been  able  to  explain  his
> intentions to anybody in public. Why did he never do that? But spread
> FUD instead?

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

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

[Wolfgang Denk]

In message <20020525114426.B15969@work.bitmover.com> you wrote:
>
> 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.

Let's talk about a specific example: we (DENX) published a patch  for
RTAI  and RTLinux to support the MPC8xx Embedded PowerPC controllers.
The patch has been on our FTP server since May 12,  2001.  One  month
latyer,  FSMLabs announced support for the MPC8xx in their commercial
version of RTLinux. Until today they only offer 8xx support in  their
commercial version, but not in the GPLed version.

Now tell me again who wants to make money off who's work?

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
The IQ of the group is the lowest IQ of a member of the group divided
by the number of people in the group.

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Larry McVoy]

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

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

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

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

[Wolfgang Denk]

In message <20020525133637.B17573@work.bitmover.com> 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"

You have seen what? Did you really compare RTAI  and  RT-Linux  code?
Which   "substantial   parts"   are  you  talking  about?  Please  be
specific!!!

> and the guy who did that work freely admitted that it was a fork of the 
> RT/Linux source base?

Yes, of course it was a fork at a very early point  of  the  develop-
ment. So what? Nobody denies that RTAI is based on the same core idea
as RT-Linux - that's why the RT-Linux patent _is_ an issue to RTAI.

On the other hand, a lot of significant features originaten in  RTAI,
and have been implemented in RT-Linux later - floating point support,
to name just one.

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

Too true.

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
In a business, marketroids, salespukes, and  lawyers  have  different
goals from those who actually do work and produce something. Usually,
is  is the former who triumph over the latter, due to the simple rule
that those who print the money make the rules.
         -- Tom Christiansen in <5jdcls$b04$2@csnews.cs.colorado.edu>

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

[Larry McVoy]

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

s/same core idea/same core code/

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

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

[Wolfgang Denk]

In message <20020525140532.A11297@work.bitmover.com> you wrote:
>
> > Yes, of course it was a fork at a very early point  of  the  develop-
> > ment. So what? Nobody denies that RTAI is based on the same core idea
> > as RT-Linux - that's why the RT-Linux patent _is_ an issue to RTAI.
> 
> s/same core idea/same core code/
> 
> Go search around, get the code you can still find on the net and start
> diffing.  So not only do the RTAI people have an issue with the patent,
> it looks like they'd better be conforming to the GPL as well.  Didn't

Ummm, please do not start spreading FUD. Instead  of  making  such  a
claim,  please  be  specific,  and  show  such  "substantial parts of
RT/Linux" code!


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

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Man is the best computer we can put aboard a spacecraft ...  and  the
only one that can be mass produced with unskilled labor.
                                                 -- Wernher von Braun

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

[Larry McVoy]

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

And why is that?  Could it be that RTAI is derived from RTL, and RTL is
GPLed, and it was illegal for RTAI to ever have been anything but GPL?
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

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

[Alan Cox]

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.

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

[Larry McVoy]

On Sun, May 26, 2002 at 03:46:22AM +0100, Alan Cox wrote:
> 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 

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

[Daniel Phillips]

On Saturday 25 May 2002 23:20, Wolfgang Denk wrote:
> In message <20020525140532.A11297@work.bitmover.com> you wrote:
> >
> > > Yes, of course it was a fork at a very early point  of  the  develop-
> > > ment. So what? Nobody denies that RTAI is based on the same core idea
> > > as RT-Linux - that's why the RT-Linux patent _is_ an issue to RTAI.
> > 
> > s/same core idea/same core code/
> > 
> > Go search around, get the code you can still find on the net and start
> > diffing.  So not only do the RTAI people have an issue with the patent,
> > it looks like they'd better be conforming to the GPL as well.  Didn't
> 
> Ummm, please do not start spreading FUD. Instead  of  making  such  a
> claim,  please  be  specific,  and  show  such  "substantial parts of
> RT/Linux" code!

Twice, Larry has ignored the challenge to provide specific examples that
support his claim that substantial parts of RTLinux have been incorporated
into the RTAI code, and instead has responded to other points in the same
posts.

My tentative conclusion is that Larry is unable to support his claim.

-- 
Daniel

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

[Robert Schwebel]

On Sat, May 25, 2002 at 02:05:32PM -0700, Larry McVoy wrote:
> s/same core idea/same core code/

Not true. Please note that the RTHAL (Realtime Hardware Abstraction Layer)
which is the core of RTAI was even available under DOS in Paolo
Mantegazza's group before it was ported to Linux. 

> Go search around, get the code you can still find on the net and start
> diffing. 

This may be true for early versions of RTAI, where everybody thought that
we are all working together in a friendly way as we have been used to in
the Linux community. 

The core has been completely reworked since then¹ - and it nevertheless is
under the GPL, so there is absolutely no problem with that. When there came
up doubts about the legal status of the stuff being under the LGPL in
former times the RTAI team has immediately investigated this, with the
result of the license situation we have today. 

> So not only do the RTAI people have an issue with the patent, it looks
> like they'd better be conforming to the GPL as well.

We do. Show us where we don't and we will immediately change it. 

> Didn't RTAI switch the copyright on "their" sourcebase to LGPL? 

It's different. There is the RTHAL patch, which goes into the kernel. This
one is GPL, as well as the HRT schedulers. 

All the infrastructure modules providing things like FIFOs, mailboxes,
tasklets and stuff are under the LGPL, meaning "give back when modifying
it, but be able to built something ontop of it which doesn't have to be
free". 

Robert
¹ There are surely small things which cannot be implemented in 
  another way - try to write a counting loop in another way than 
  for (i=0; i<N; i++) {printf(i);}
-- 
 +--------------------------------------------------------+
 | 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    |
 +--------------------------------------------------------+

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

[Robert Schwebel]

On Sat, May 25, 2002 at 10:55:46PM -0400, Albert D. Cahalan wrote:
> You could start by fixing the bug. Try "man 3 printf".

It's late and I didn't have much sleep over the last days. I think you got
the point. 

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

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

[Calin A. Culianu]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 244 bytes --]

> Robert
> ¹ There are surely small things which cannot be implemented in
>   another way - try to write a counting loop in another way than
>   for (i=0; i<N; i++) {printf(i);}
>

void loopie(int N)
{
	if (N) loopie(N-1);
	printf("%d ",N);
}

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

[Mark Mielke]

On Mon, May 27, 2002 at 01:28:13AM -0400, Calin A. Culianu wrote:
> > Robert
> > ¹ There are surely small things which cannot be implemented in
> >   another way - try to write a counting loop in another way than
> >   for (i=0; i<N; i++) {printf(i);}
> void loopie(int N)
> {
> 	if (N) loopie(N-1);
> 	printf("%d ",N);
> }

" ... cannot be [sensibly] implemented in another way ... "

As somebody else pointed out, a good optimizer should be able to
unroll most types of loops / functions. With sufficient capabilities,
an optimizer should turn both of the above into the same object code
(potentially a faster executing version, or a tighter set of
instructions, than either of the above, unoptimized).

But then again... this whole thread-line is a little off-topic... we
all know it is the better lawyer who wins, not the developer who can
deduce the potential origin of a piece of code... :-)

mark

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

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

                           http://mark.mielke.cc/

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

[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 <199704180908.DAA03790@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 <business@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
 * licensequestions@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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[David Schleef]

On Sat, May 25, 2002 at 01:36:37PM -0700, 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.

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

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

[Larry McVoy]

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

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

[David Schleef]

On Sat, May 25, 2002 at 08:17:49PM -0700, Larry McVoy wrote:
> 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...

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

[Larry McVoy]

On Sat, May 25, 2002 at 08:45:42PM -0700, David Schleef 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.
> 
> 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 

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

[Alan Cox]

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)

> 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

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

[Larry McVoy]

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.

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 

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

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

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

[Larry McVoy]

On Sun, May 26, 2002 at 04:17:07PM -0400, Alexander Viro wrote:
> > 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 

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

[Alan Cox]

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.

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.

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

[Larry McVoy]

On Sun, May 26, 2002 at 10:33:14PM +0100, Alan Cox wrote:
> 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 

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

[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

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

[Robert Schwebel]

Nicholas, 

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

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

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

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

[Larry McVoy]

On Sat, May 25, 2002 at 11:58:14PM -0400, Alexander Viro 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.

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 

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

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

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

[yodaiken]

On Sun, May 26, 2002 at 03:30:46AM -0400, Alexander Viro wrote:
> 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

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Larry McVoy]

On Sun, May 26, 2002 at 03:30:46AM -0400, Alexander Viro wrote:
> On Sat, 25 May 2002, Larry McVoy wrote:
> 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 

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

[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

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Mark Mielke]

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

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

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

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

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

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

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

mark

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

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

                           http://mark.mielke.cc/

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Robert Schwebel]

On Sat, May 25, 2002 at 02:33:58PM -0400, Mark Mielke wrote:
> From what I understand, Linux _is_ being considered for RT applications
> by quite a few heavy-weights in the field including IBM, Intel and quite
> a few others. 

Uhm, that shows that you don't have _any_ idea what's going on in the
automation field. IBM is an IT company, and Intel is a processor
manufacturer. We are talking about the world of signal processors and PLCs
here, where companies like Siemens, ABB, Schneider etc. are the big
players. 

> My limited observations suggest that the primary reasons people do not
> use Linux for their RT applications are:
> 
>     1) They don't trust it for 'high availability'.

Not correct. 

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

You would be wondering how fast you can port an application for another
RTOS to RTAI. There is even a module for RTAI/LXRT which lets you run
Matlab/RTW code natively on RTAI...

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

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

[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

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Daniel Phillips]

On Saturday 25 May 2002 20:44, Linus Torvalds wrote:
> 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."

Nice recovery, however, reading your original comment in context, it
appears that you were not aware of the method RTAI uses to prevent
priority inversions[1]:

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

So, since you thought that the priority inversion problem was not solved,
then you must not have known about the second set of services.

> Karim, I don't _need_ to download RTAI or ask you questions about how it
> works,

Oh, but I think you just showed that you do need to do that, I think we
all do.

-- 
Daniel

[1] And neither was I.

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

[Wolfgang Denk]

In message <Pine.LNX.4.44.0205251057370.6515-100000@home.transmeta.com>
Linus Torvalds 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"...

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Microsoft Multitasking:
                     several applications can crash at the same time.

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

[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!

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

[Albert D. Cahalan]

Linus Torvalds writes:

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

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

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

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

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

[Larry McVoy]

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

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

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Wolfgang Denk]

In message <20020525143333.A17889@work.bitmover.com> 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.  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.

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.

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
If ignorance is bliss, why aren't there more happy people?

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

[Larry McVoy]

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

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

[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
> >   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Apologizing for pointing out the obvious is not my style.

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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Wolfgang Denk]

In message <20020525150542.B17889@work.bitmover.com> Larry McVoy wrote:
> 
> Hey, I said "I suspect".  You can scream all you want but if the facts are

Yeah, that's the usual way to spread FUD.

> Apologizing for pointing out the obvious is not my style.

Obviously not.

For the third time - you wrote:

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

Can you please quote any such "substantial parts of RT/Linux  in  the
RTAI source"?

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
As long as we're going to reinvent the wheel again, we might as  well
try making it round this time.                        - Mike Dennison

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

[Larry McVoy]

On Sun, May 26, 2002 at 12:17:46AM +0200, Wolfgang Denk wrote:
> > > 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"
> 
> Can you please quote any such "substantial parts of RT/Linux  in  the
> RTAI source"?

Well, since you asked, how about you just go diff the include directories
of the two source bases.  That's a wonderful place to start.  Anyone who
spends 5 minutes in there will see that RTAI is derived from RTL.  Look at
the definition of the RT task struct, it's identical.  Look at the fifo.h
file, big chunks of it are identical.  Another fun thing is to just want
the directory structure of the two source trees, more clues that it is
RTL derived.  It's all been pushed around a lot but I'm not sure you can
take a source base and change it partially and then claim it is yours.
I know if this was my source base I'd be pissed off.

Here's some more, go contrast rt_task_make_periodic() in each of the 
source trees, pretty clearly RTL.  In fact, the scheduler code is really
easy to see that it's a ripoff.  Do a global substitute for 
    s/rtl_no_interrupts()/hard_save_flags_and_cli()/ 
and then start diffing, the code starts matching up more.

Furthermore, look at this:

    rtai-24.1.9/COPYING
	The intent of RTAI developers is to make the code that we write
	to be widely useful and that it can be copied and incorporated
	into other works, including libraries.	In addition, we wish
	to make it explicitly clear that linking proprietary code with
	RTAI is an acceptible use -- for these reasons, we have chosen
	the LGPL as the distribution license.

	However, at the current time, RTAI contains portions that are
	derived from GPL code, so if you are in a situation where the
	difference between GPL and LGPL is an issue, please ask.

    So which is it?  GPL or LGPL?  I thought you guys said you made it 
    clear that it was GPLed.

Anyway, you can jump up and down until you are blue in the face, it's
absolutely obvious to anyone who looks that the RTAI stuff is derived
from the RTL stuff.  Yeah, sure, it's evolved, but it's the same source
base and evolving it does not invalidate their license.  The COPYING
file in the *current* RTAI release is illegal.  You can't say "Well,
there is some GPL stuff in here, but we're releasing under the LGPL"
just because you feel like it.  Didn't you guys repeatedly state that
it was GPL, not LGPL?  And is it?  Not according to the download.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

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

[Wolfgang Denk]

In message <20020525161034.L28795@work.bitmover.com> Larry McVoy wrote:
>
> > > > 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"
> > 
> > Can you please quote any such "substantial parts of RT/Linux  in  the
> > 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

Larry, you know EXACTLY why I won't do this: I don't want to waste my
time.

> spends 5 minutes in there will see that RTAI is derived from RTL.  Look at

Nobody EVER denied this.

> 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

Ummm.... that's interface definitions, right? That's no code. This is
probably not "substantial parts of RT/Linux", or is it?

> 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

Stop! Let's keep this straight.

NOBODY ever denied that RT-Linux came first, and RTAI used  it  as  a
starting point.


But you claimed that there are "substantial parts of RT/Linux in  the
RTAI source".

Where ?!?!

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

If you were really interested, you could read
http://www.linuxdevices.com/articles/AT2899063844.html

The core is under GPL, and additional packages are under  LGPL.  Yes.
Any problem?

Are you worried that any Linux distribution of  your  choice  is  not
completely covered by GPL? That there are LGPLed libraries and things
like that?


> 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

Item: it's derived - correct. Nobody ever denied.

Item: it's evolved - correct. In fact, in many aspects it's much more
      advanced; you find many features in RTAI that are not available
      in RT-Linux (at least in the GPLed versions - don't  know  what
      they  are  selling  to thier customers). And you find an active
      community of developers for RTAI, which RT-Linux seems  not  to
      have  any more. And the RTAI mailing list is open for everyone,
      there are no censoring filters installed.

> file in the *current* RTAI release is illegal.  You can't say "Well,

Please explain?

> there is some GPL stuff in here, but we're releasing under the LGPL"

You can release some stuff onder one license,  other  stuff  under  a
second  license,  and  yet other stuff onder a third license. Is that
too difficult for you to understand?

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

You don't want to understand. Hell, you must be SCARED that there are
libraries in your GNU/Linux system that are under LGPL...


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.

That's the old strategy of FUD.



What a waste of time.

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
"He was so narrow minded he could see through  a  keyhole  with  both
eyes ..."

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

[Larry McVoy]

On Sun, May 26, 2002 at 01:54:37AM +0200, Wolfgang Denk wrote:
> > there is some GPL stuff in here, but we're releasing under the LGPL"
> 
> You can release some stuff onder one license,  other  stuff  under  a
> second  license,  and  yet other stuff onder a third license. Is that
> too difficult for you to understand?

That's all fine, but the RTAI COPYING file looks to me like a delibrate
attempt to mislead.  I'm pretty sure that a court of law would see it the
same way.  Add to that the the RTAI system is based in the RTL system,
which was obtained under the GPL, and that there are files which are
obviously derivative works with a LGPL license on them, and I think
you'd be squirming in front of judge with nowhere to run.

> Just for the record: you claimed  there  was  "substantial  parts  of
> RT/Linux  in  the  RTAI source"; when challenged to provide examples,
> you tried to evade several times; finally, you fell back to the  "but
> it's derived from RTL", which nobody ever denied.

No, I suggested you go look for yourself, just as I did.  It's called 
giving you a chance to back down gracefully.  You don't seem to want that
chance, OK, that's your call.  Let's explain the facts of life.  If you
start with a GPLed file and you enhance, bug fix, whatever, and the 
resulting work is what is known as a "derived work", it's still *all*
GPLed.  That's how the law works.  That was the whole point of how the
GPL was written, it was designed to not let people like you change the
rules without the permission of all the people who had copyrights on
that work.

I don't have to show entire files being identical to make the point,
all I have to show is that the files are derived from GPLed versions
of the same code.  Anyone with a brain would do what I did, go walk
the header files, find the common definitions, go look at the code that
implements those definitions, and know immediately it was derived work.
That's all it takes.  That's enough.  The law needs no more than that.

If you want to wiggle out from under the rules, you're going to need
what is known is a "clean room" reimplementation, wherein nobody who is
doing the work has ever seen the other code.  Otherwise it is virtually
impossible to avoid the derived work problem, and the burden is on you,
the person trying to change the rules, that it is not a derived work.
The court would presume, in a case like this, that it was.  You can 
try and push that back on me all you want, but I'm not the one you need
to convince.  You need to convince prospective customers that you have
clear rights to use what you are giving them, and in this case, that
looks virtually impossible.  I know about this stuff, I run a software
business, I personally negotiate the contracts, and no company with
any legal staff whatsoever would enter into contract with a vendor that
is not willing to state and prove that they have rights to what they
are selling.  That's contracts-101.

I get the feeling you want me to back down and go away.  Go Google around
and you'll find that I just don't, not until you prove that I'm wrong.
In this case, the more I dig into it, the more convinced I am that the
RTAI crowd is trying to rewrite history and that does nothing but make me
more motivated to stick around and make sure people look at this closely.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Robert Schwebel]

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. 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 (mantegazza@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 (mantegazza@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 (mantegazza@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    |
 +--------------------------------------------------------+

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

[Larry McVoy]

On Sun, May 26, 2002 at 01:56:09AM +0200, Robert Schwebel wrote:
> 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 (mantegazza@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 

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

[Robert Schwebel]

On Sat, May 25, 2002 at 08:40:26PM -0700, Larry McVoy wrote:
> 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    |
 +--------------------------------------------------------+

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

[Wolfgang Denk]

In message <20020526100539.M598@schwebel.de> Robert Schwebel wrote:
>
> 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. 

And to get this right: that fact that the "other"  parts  are  LGPLed
does  not  mean  that  the  RTAI team wants to keep it secret Cor put
restritctions on use - on contrary, we want  to  provide  RTAI  users
ADDITIONAL freedom - the freedom of the decision if they want to make
their application code GPLed or not.

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
As far as we know, our computer has never had an undetected error.
		                                           -- Weisert

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

[Thomas Gleixner]

On Sunday, 26. May 2002 00:05, Larry McVoy wrote:
>
> 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.
There's nothing obvious, if somebody complains about a questionable software 
patent and it's possible consequences for Linux.

Your "suspection" is just impertinent. Check out the source from CVS and look 
for the missing critical chunk, before heating up the flamewar.

-- 
Thomas
___________________________________
autronix automation GmbH
http://www.autronix.de gleixner@autronix.de

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

[Erwin Rol]

[-- Attachment #1: Type: text/plain, Size: 3651 bytes --]

On Sun, 2002-05-26 at 00:05, Larry McVoy wrote:
> > > 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            	 lm at bitmover.com           http://www.bitmover.com/lm 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

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

[Larry McVoy]

On Sun, May 26, 2002 at 12:34:11AM +0200, Erwin Rol wrote:
> RTAI is free software under the GPL, but that does

Not according to the COPYING file in the current RTAI release.  Go read it.
-- 
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 

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

[Robert Schwebel]

On Sat, May 25, 2002 at 03:05:42PM -0700, Larry McVoy wrote:
> 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    |
 +--------------------------------------------------------+

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

[Larry McVoy]

On Sun, May 26, 2002 at 01:37:35AM +0200, Robert Schwebel wrote:
> 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 

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

[Robert Schwebel]

On Sat, May 25, 2002 at 04:46:11PM -0700, Larry McVoy wrote:
> 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    |
 +--------------------------------------------------------+

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

[David Woodhouse]

lm@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

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

[Roman Zippel]

Hi,

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

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

[yodaiken]

On Sun, May 26, 2002 at 11:11:38AM +0100, David Woodhouse wrote:
> 
> lm@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

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

[Roman Zippel]

Hi,

On Sun, 26 May 2002 yodaiken@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

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

[yodaiken]

On Sun, May 26, 2002 at 04:09:46PM +0200, Roman Zippel wrote:
> Hi,
> 
> On Sun, 26 May 2002 yodaiken@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

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

[Roman Zippel]

Hi,

On Sun, 26 May 2002 yodaiken@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

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

[yodaiken]

On Sun, May 26, 2002 at 05:30:27PM +0200, Roman Zippel wrote:
> > 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

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

[Karim Yaghmour]

yodaiken@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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Larry McVoy]

Around and around we go - I'm seeing why Victor is sick of this.  A few
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 

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Wolfgang Denk]

In message <3CF1578E.774DF802@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.

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!

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
It is wrong always, everywhere and for everyone to  believe  anything
upon  insufficient  evidence.  - W. K. Clifford, British philosopher,
circa 1876

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

[Erwin Rol]

[-- Attachment #1: Type: text/plain, Size: 1329 bytes --]

On Sun, 2002-05-26 at 23:58, Wolfgang Denk wrote:
> In message <3CF1578E.774DF802@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.
> 
> 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!
> 

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: wd@denx.de
> It is wrong always, everywhere and for everyone to  believe  anything
> upon  insufficient  evidence.  - W. K. Clifford, British philosopher,
> circa 1876
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 232 bytes --]

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

[Robert Schwebel]

On Sun, May 26, 2002 at 11:58:31PM +0200, Wolfgang Denk wrote:
> 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    |
 +--------------------------------------------------------+

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

[Mark Mielke]

On Sun, May 26, 2002 at 05:45:50PM -0400, Karim Yaghmour wrote:
> Larry McVoy wrote:
> > Ask 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?

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

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

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

                           http://mark.mielke.cc/

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Roman Zippel]

Hi,

On Sun, 26 May 2002 yodaiken@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

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

[Nicholas Knight]

----- Original Message -----
From: <yodaiken@fsmlabs.com>
Sent: Sunday, May 26, 2002 7:21 AM

> On Sun, May 26, 2002 at 04:09:46PM +0200, Roman Zippel wrote:
> > Hi,
> >
> > On Sun, 26 May 2002 yodaiken@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.

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

[Daniel Phillips]

On Sunday 26 May 2002 16:21, yodaiken@fsmlabs.com wrote:
> On Sun, May 26, 2002 at 04:09:46PM +0200, Roman Zippel wrote:
> > Hi,
> > 
> > On Sun, 26 May 2002 yodaiken@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.

>From your August 12, 2000 linuxdevices interview:

   RL: OK, so let's talk about the "infamous" RTLinux patent. What's up with 
   that patent?

   ...

   RL: Could that potentially be used to block RTAI from being LGPL?

   Yodaiken: RTLinux is released under the GPL. I have an agreement with 
   Linus that nobody who uses RTLinux with Linux will have to pay royalties.

My question: do you stand by this, at least?  If so, will you put that in 
writing for the rest of us?  Did you really mean what you said, or did you 
add conditions later, such as 'only unmodified RTLinux blessed by me'?  If 
not, then I should be able to backport most RTAI features to RTLinux and call 
the result RTLinux.  Would that be consistent with your agreement with Linus?

-- 
Daniel

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

[Robert Schwebel]

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.  

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

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

[Erik Andersen]

On Sun May 26, 2002 at 12:58:27AM +0200, Robert Schwebel wrote:
> 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--

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

[Robert Schwebel]

On Sat, May 25, 2002 at 06:48:53PM -0600, Erik Andersen wrote:
> 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...

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

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

[Erik Andersen]

On Sun May 26, 2002 at 07:31:36AM +0200, Robert Schwebel wrote:
> 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--

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

[Daniel Phillips]

On Saturday 25 May 2002 07:20, Karim Yaghmour wrote:
> Larry McVoy wrote:
> 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.

Speaking for myself, I find the issue interesting, and this interest is not 
idle.

I would not take Larry's huffing and puffing as an indication of general 
sentiment.  He's pretty much going to have a kneejerk reaction in favor of 
fencing off the commons any time the issue comes up, that should be clear 
enough by now.

As for Larry's argumentation style, it is consists mostly of rhetoric and ad 
hominem attacks.  Considering that, I thought that you presented your points 
well and did not rise to take the flamebait overly quickly.

Advantage Karim.

-- 
Daniel

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

[Karim Yaghmour]

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

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

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

Karim

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

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

[Larry McVoy]

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

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

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

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

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

[Robert Schwebel]

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

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

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

Robert
-- 
 +--------------------------------------------------------+
 | 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    |
 +--------------------------------------------------------+

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

[Oliver Xymoron]

On Fri, 24 May 2002, Larry McVoy wrote:

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

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

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

Compare:

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

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

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

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

[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

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[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

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[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

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

[Larry McVoy]

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

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

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

[Linus Torvalds]

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

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

		Linus

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

[Daniel Phillips]

On Saturday 25 May 2002 06:27, Linus Torvalds wrote:
> 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 ]

This issue is easily dealt with by requiring root for the rt_task_init
call.

As for debugging the thing, Linus doth protest too much.

-- 
Daniel

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

[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
               karim@opersys.com
      Embedded and Real-Time Linux Expert
===================================================

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

[Robert Schwebel]

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

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

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

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

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

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

[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

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

[Daniel Phillips]

On Saturday 25 May 2002 19:27, Linus Torvalds wrote:
> On Sat, 25 May 2002, Robert Schwebel wrote:
> > 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.

What kind of argument is that?  As with many kernel features, "it may not be
the common case, but if it's *your* case, you care a lot".

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
and saying "just handle that running Linux as a task under some other OS" - 
Linux will continue to not be ready.  We have a choice of either addressing
the technical issues, or just admitting that Linux can't cut it in a factory.

This is the same dilemma as the one that lead to you finally realizing that
it really matters whether people's MP3 players skip or not.

-- 
Daniel

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

[Alan Cox]

On Sat, 2002-05-25 at 21:30, Daniel Phillips wrote:
> 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.

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

[Daniel Phillips]

On Sunday 26 May 2002 04:51, Alan Cox wrote:
> On Sat, 2002-05-25 at 21:30, Daniel Phillips wrote:
> > 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.

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 
see a VM that doesn't fall over in corner cases?  I don't accept 'never' as 
an anwswer to this.  Much of our current work - removal of the buffer cache, 
elimination of buffer heads in most roles, coalescing of the ide and scsi 
block flavors, introduction of reverse-mapping in the vm - moves the kernel 
in the direction of less complexity, in the sense that state transitions and 
subsystem interactions become easier to audit.

The day of the tiny, single purpose OS-let in industrial applications is 
pretty much over.  To illustrate, among the requirements we had was to 
support modern hardware such as accelerated video cards, and high level 
functions such as tcp stacks.  We even had to run a database on the machine, 
and a GUI.  Don't even think of asking the hardware engineers to design a 
two-processor system so that one of them can run a simplified OS.  They won't 
do it, because then they know perfectly well that one processor will do the 
job, and it did, is doing it today.  Reliably, and on what OS?  Dos.

Surely if DoS can do it, then Linux can do it better.  But not if we admit 
defeat before starting.

-- 
Daniel

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

[Alan Cox]

On Sun, 2002-05-26 at 05:11, Daniel Phillips wrote:
> 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).

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

[Daniel Phillips]

On Sunday 26 May 2002 21:37, you wrote:
> On Sun, 2002-05-26 at 05:11, Daniel Phillips wrote:
> > 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.

You're talking to one of those people.  There are all sizes of embedded 
systems.  I worked with both tiny ones, where the whole 'OS' consisted of 
2,000 lines of code or so, and large ones, with megabyte+ kernels.  There 
are even folks using Windows - all flavors - as an embedded OS.

Given that the world *has* changed and that people do build embedded
systems around what would have been unthinkably large OS kernels, the only
question left is which OS to work with.  Would you rather work with Linux
or Solaris, leaving aside, for the moment, the question of licensing?

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

You wish.  Sad to say, they stay much the same.  People remain people,
and budgets remain budgets.  Just as in the business app world, customers
can be much more easily convinced to spend their dollars for features
than for reliability.  They of course eventually pay for the reliability -
after the fact, when something has gone wrong.  It's the same as our game,
which goes something like: do the best job you can within the constraints
of your ability and the time you have available (which is normally none,
since the software for these embedded systems is always developed with
unrealistically tight deadlines) and then track down and fix the problems
that emerge.  The companies that are successful at this - largely through
luck I'd say - make money, and those that don't die.  It has very little
to do with analysis.

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

You remember I wasn't originally talking about appliances, right?  Anyway, 
in the time since I worked in that field, Moore's law hasn't stopped, and
now I have Linux running on the DSL modem under my desk.

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

That is too true, and it is a fact that the stonemasons want to use Linux.
The barons, however, are another matter, and it was the barons who
prevented me from using Linux in any capacity, let alone in the realtime
area.  At the time, the best you could say for Linux was: it doesn't
suck as much as windows.  Since then, there have been some positive
developments, but fundamental obstacles to widespread adoption of Linux
in the realtime space do remain, and yes, and I do believe that the
patent held by Victor is one of them, if not the main one.

-- 
Daniel

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

[Pavel Machek]

Hi!

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

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

[Robert Schwebel]

On Sat, May 25, 2002 at 10:27:24AM -0700, Linus Torvalds wrote:
> It results in the fact that you need to have a _clear_interface_ between
> the hard realtime parts, and the stuff that isn't.

Show me how you will implement a closed loop controller where the
application is _not_ implemented as a kernel module. I would really love to
do it this way, but unfortunately no one of the realtime programmers has
found a way how it can be achieved so far. 

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

Unfortunately, in the automation field nearly all applications are
closed-loop, and that means that the application itself is time critical. 

> > This is only correct for open-loop applications. Most real life apps are
> > closed-loop.
> 
> Most real life apps have nothing to do with hard-RT.

Perhaps in your life :-) It's different in mine, in Karim's, Wolfgang's,
Bernhard's, Steve's, Stuart's, Paolo's, Guennadi's, Thomas', Massimo's,
Pierre's, Lorenzo's, Giuseppe's, Erwin's, Dave's, Ian's, Alex' (just to
mention the RTAI team) and in that of all the thousands of engineers who
are working with Linux and RTAI every day. 

Please, take into account that there are people out there wo are working
with Linux in automation and control applications every day, and their
bread and butter _is_ realtime stuff. My experience is that this is
sometimes really hard to understand for people who normally work on
problems from the IT industry, you are not the only one.

Realtime may be someting exotic for "normal" PC users, but in the whole
industrial embedded world it is completely different. 

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

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

[Linus Torvalds]

On Sun, 26 May 2002, Robert Schwebel wrote:
>
> Show me how you will implement a closed loop controller where the
> application is _not_ implemented as a kernel module. I would really love to
> do it this way, but unfortunately no one of the realtime programmers has
> found a way how it can be achieved so far.

The thing is, if your whole app is really RT, then neither RTAI nor
RTLinux will help you all that much.

The "user space" in RTAI ends up being equally limited as any kernel
module in RTLinux. No dynamic memory allocation, no deep recursion, no
regular system calls. That's just fundamental to hard realtime, and has
nothing to do with any of the environments themselves.

The "advantage" of RTAI is a copyright license issue at that point,
nothing more (well, you get your own address space, but since you mustn't
fault anything anyway, the advantage is dubious, _and_ it certainly eats
into your performance). And as explained elsewhere, I don't find that to
be an advantage at all (and as pointed out by Larry, there seems to be
some dubious issues about the RTAI copyright itself).

Don't get me wrong - I'd love to say that it could be easily fixed by
doing xxxx, but the fact is that since the linux kernel itself isn't hard
realtime, the lack of kernel services really is unavoidable.

And once you lack kernel services, from a programming standpoint it
shouldn't really matter whether it's a kernel module or not. You've got
basically the same amount of (or rather, "lack of") support. A lot of
things are a lot easier in kernel mode (interrupts, IO etc), while you
might find loading the app etc easier in the RTAI model, for example. You
win some, you lose some.

Can we make the whole kernel truly hard-RT? Sure, possible in theory. In
practice? No way, José. It's just not mainline enough.

So I'm agreeing with you: for true hard RT, you need a kernel module. I
can't come up with a way to avoid any of the fundamental problems either..

			Linus

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

[Pierre Cloutier]

On Sun, 26 May 2002, Linus Torvalds wrote:
> On Sun, 26 May 2002, Robert Schwebel wrote:
> > Show me how you will implement a closed loop controller where the
> > application is _not_ implemented as a kernel module. I would really love
> > to do it this way, but unfortunately no one of the realtime programmers
> > has found a way how it can be achieved so far.
>
> The thing is, if your whole app is really RT, then neither RTAI nor
> RTLinux will help you all that much.
>
> The "user space" in RTAI ends up being equally limited as any kernel
> module in RTLinux. No dynamic memory allocation, no deep recursion, no
> regular system calls. That's just fundamental to hard realtime, and has
> nothing to do with any of the environments themselves.
>
> The "advantage" of RTAI is a copyright license issue at that point,
> nothing more (well, you get your own address space, but since you mustn't
> fault anything anyway, the advantage is dubious, _and_ it certainly eats
> into your performance). And as explained elsewhere, I don't find that to
> be an advantage at all (and as pointed out by Larry, there seems to be
> some dubious issues about the RTAI copyright itself).
>
> Don't get me wrong - I'd love to say that it could be easily fixed by
> doing xxxx, but the fact is that since the linux kernel itself isn't hard
> realtime, the lack of kernel services really is unavoidable.
>
> And once you lack kernel services, from a programming standpoint it
> shouldn't really matter whether it's a kernel module or not. You've got
> basically the same amount of (or rather, "lack of") support. A lot of
> things are a lot easier in kernel mode (interrupts, IO etc), while you
> might find loading the app etc easier in the RTAI model, for example. You
> win some, you lose some.
>
> Can we make the whole kernel truly hard-RT? Sure, possible in theory. In
> practice? No way, José. It's just not mainline enough.
>
> So I'm agreeing with you: for true hard RT, you need a kernel module. I
> can't come up with a way to avoid any of the fundamental problems either..
>

Hi:

Linus misses the most important feature of hard real time in user space.

RTAI deals with memory protection traps and terminates buggy code.
Linus must know that a bug in the kernel means trouble - trouble that may be, 
just may be, fsck may not be able to deal with in the aftermath...

So the concept is simple. Develop the real time code in user space under 
memory protection. When done move the stuff in the kernel (it is the same 
API) if performance demands it, otherwise why bother!

As to the patent issues I do not care. The patent will not hold in a court of 
law because there was prior knowledge. There are also filling timing issues...

I regret the FUD as it is advertising for the weak side of the force.

Best Regards,

Pierre Cloutier 



 

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

[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

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

[Pierre Cloutier]

On Sun, 26 May 2002, Linus Torvalds wrote:
> 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 ;)

Hi:

Sorry but you have it wrong:

"Because you have the same API, you can do the RT development in user space 
and then move it into the kernel once you know the code works."

Please do not underestimate the significance of this.

The API is limited. Yes. But it does provide me with the QNX like IPC I so 
cheerish - and that is all i need. Cheers!

Best Regards,

Pierre Cloutier

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

[Linus Torvalds]

On Sat, 25 May 2002, Linus Torvalds wrote:
>
> Can we make the whole kernel truly hard-RT? Sure, possible in theory. In
> practice? No way, José. It's just not mainline enough.

Side note: we could, of course, mark some spinlocks (and thus some
code-paths) as being RT-safe, and then make sure that those spinlocks -
when they disable interrupts - actually disable the _hw_ interrupts even
with the RT patches.

That would make those sequences usable even from within a RT subset, but
would obviously mean that those spinlocks have to be checked for latency
issues - because any user (also non-RT ones) would obviously be truly
uninterruptible within these spinlocks.

Every single RT person out there is already painfully aware of (and used
to) having to limit the set of functions he can use while RT, so this is
something you guys tend to be pretty familiar with..

So the "hard-RT" thing doesn't need to be a complete on/off thing.

This kind of "limited kernel functionality" tends to help only RT kernel
modules, though. Full system calls (except the trivial ones like
"getpid()", of course) simply tend to have to require too much "real"
infrastructure that they can't use the RT subset.

Also, some people will he happy to know that soft-RT ends up getting
continually improved, and many people might be able to find that just the
regular preemptible kernel gives good enough latency at least if you can
limit the workload on the machine (which, on embedded devices tends to be
somethin gyou take for granted anyway).

That may not make the hard RT people happier, but at least it might shrink
the number of the die-hard hard RT'rs.

"If you can't beat them, try to make them extinct" ;)

			Linus

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

[Oliver Xymoron]

On Sat, 25 May 2002, Linus Torvalds wrote:

>
>
> On Sat, 25 May 2002, Linus Torvalds wrote:
> >
> > Can we make the whole kernel truly hard-RT? Sure, possible in theory. In
> > practice? No way, José. It's just not mainline enough.
>
> Side note: we could, of course, mark some spinlocks (and thus some
> code-paths) as being RT-safe, and then make sure that those spinlocks -
> when they disable interrupts - actually disable the _hw_ interrupts even
> with the RT patches.
>
> That would make those sequences usable even from within a RT subset, but
> would obviously mean that those spinlocks have to be checked for latency
> issues - because any user (also non-RT ones) would obviously be truly
> uninterruptible within these spinlocks.

I'm sure you know this route is not very useful - there's practically
nothing that we can push across the hard RT divide anyway. We can't do
meaningful filesystem I/O, memory allocation, networking, or VM fiddling -
what's left?

Cleaning up soft RT latencies will make the vast majority of people who
think they want hard RT happy anyway.

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

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

[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

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

[yodaiken]

On Sat, May 25, 2002 at 09:20:32PM -0700, Linus Torvalds wrote:
> 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

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

[Oliver Xymoron]

On Sat, 25 May 2002, Linus Torvalds wrote:

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

Re: patent on O_ATOMICLOOKUP - Warning actual technical content.

[yodaiken]

On Sat, May 25, 2002 at 05:39:00PM -0700, Linus Torvalds wrote:
> Side note: we could, of course, mark some spinlocks (and thus some
> code-paths) as being RT-safe, and then make sure that those spinlocks -
> when they disable interrupts - actually disable the _hw_ interrupts even
> with the RT patches.
> 
> That would make those sequences usable even from within a RT subset, but
> would obviously mean that those spinlocks have to be checked for latency
> issues - because any user (also non-RT ones) would obviously be truly
> uninterruptible within these spinlocks.

How about something more useful: interval progress assurances? Such as
"during any 5  second  period this process will be able to read X meg of
data from a file and write Y meg"

So if I have an RT task that dumps data to a DVD at millisecond intervals,
I can be sure that the non-RT task that reads the FS and puts data 
into a buffer will never let me run out of frames on a given shared memory
size.

This is useful in itself for nonRT Linux too. It seems quite hard, but it
could be relatively robust, once it was in place - making a 1 millisecond
worst case turn into a 10 millisecond worst case would not break it.


---
BTW:
I'm ignoring the 10 billionth rehash of the RTLinux/RTAI debate since 
there seems very little purpose in not doing so.  People who have actual 
questions should feel free to ask me directly - publically or privately, I
don't mind. Those on tape loops can keep repeating themselves without
my assistance. 


-- 
---------------------------------------------------------
Victor Yodaiken 
Finite State Machine Labs: The RTLinux Company.
 www.fsmlabs.com  www.rtlinux.com

Re: patent on O_ATOMICLOOKUP - Warning actual technical content.

[Karim Yaghmour]

yodaiken@fsmlabs.com wrote:
> I'm ignoring the 10 billionth rehash of the RTLinux/RTAI debate since
> there seems very little purpose in not doing so.  People who have actual
> questions should feel free to ask me directly - publically or privately, I
> don't mind. Those on tape loops can keep repeating themselves without
> my assistance.

Every last time you said this you answered none of the questions I brought forth.
Are you serious this time that you will really answer questions?

I just want to make sure before I take the time for the n'th time to
write a list.

Karim

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

Re: patent on O_ATOMICLOOKUP - Warning actual technical content.

[Andrew Morton]

Karim Yaghmour wrote:
> 
> yodaiken@fsmlabs.com wrote:
> > I'm ignoring the 10 billionth rehash of the RTLinux/RTAI debate since
> > there seems very little purpose in not doing so.  People who have actual
> > questions should feel free to ask me directly - publically or privately, I
> > don't mind. Those on tape loops can keep repeating themselves without
> > my assistance.
> 
> Every last time you said this you answered none of the questions I brought forth.
> Are you serious this time that you will really answer questions?
> 
> I just want to make sure before I take the time for the n'th time to
> write a list.
> 

Just write the list, please.  I'm sure Victor will answer carefully.

Hopefully, together you will be able to answer the ultimate question:
"is anyone doing anything which prevents the work of Andrew Morton
from being available to its full audience?".

I would take a damnedly dim view of a "yes".

-

Re: patent on O_ATOMICLOOKUP - Warning actual technical content.

[Karim Yaghmour]

Andrew Morton wrote:
> Just write the list, please.  I'm sure Victor will answer carefully.

Ok, here we go again. Some of these questions are at the core of
many of the uncertainties I alluded to earlier. I've grouped my
questions in categories.

These questions aim at defining the scope of the patent:
1) If I implement a non-GPL real-time application (whether it be in
user-space or in kernel space) which runs on something other than RTLinux,
do I need to purchase an RTLinux patent license (or any form of license
from FSMLabs for that matter)?

(Don't make the assumption that I'm talking about just RTAI here. I'm talking
about a general rt application/task/process which runs on a RTLinux-like
entirely GPL microkernel. This includes RTAI, but can be something else.)

2) Say I use a modified RTLinux or RTAI or some other GPL RTLinux-like
microkernel beneath Linux. Are non-RT non-GPL user applications subject
to your patent? Are non-RT non-GPL modules?


These questions are aimed at understanding the status of the intellectual
property contributed to RTLinux:
3) Given Paolo Montegazza's contributions to RTLinux, why isn't his name
in any of the copyrights of any file?

4) (corrolary of 3) Has no one ever contributed to RTLinux?
a) If someone has, then why do the main header files not have any other name
than FSMLabs'?
b) If no one ever has, then why is there a list of 20 names in the CREDITS
file in RTLinux's source tree?

5) Are you selling the rtlinux fifo code in closed-source?

6) Does RTLinuxPro include any of the RTLinux work done by Woflgang Denk's Denx?


These questions are aimed at understanding the management of RTLinux:
7) Why isn't Michael Barbanov supervising the development of RTLinux anymore?
Also, why isn't his name on the patent in light of the following statement
in your article entitled "Cheap operating systems research and teaching with
Linux" presented in early '96 at the "Conference on Freely Redistributable
Software":
"The real-time operating system described in section 2.1 has been taken from
concept to a working system by Michael Barabanov and, in particular, the
design of the soft iret is due to him."?

8) Why have the following ports never been integrated in the RTLinux source
code?
a) SuperH: ftp://ftp.aandd.co.jp/pub/linuxsh/rtlinux/current/
b) StrongARM: http://www.imec.be/rtlinux/

9) What is the difference between RTLinuxGPL and RTLinuxPro (a features list
would be nice)? Are these part of the same project? What is the future of
the GPL RTLinux? I ask this because of your recent interview on LinuxDevices.com 
(http://www.linuxdevices.com/articles/AT2570821322.html)
where you state the following:
"The GPL/RTLinux work that we do loses money -- actually, we budget it
under "marketing"."

10) What rules do you apply for including outside contributions to RTLinux?
Are they allowed? If they are, then do contributors get royalties on the
closed-source versions of their code that you sell?


Finally, some questions to understand RTLinux's history:
11) Why isn't the Stodolksy paper about the software emulation of interrupts
mentionned in your patent even though Barbanov clearly recognizes it as the
pilar of the methods implemented in RTLinux?

12) Given that you said the following to Jerry Epplin in January 2000:
"The main purpose of the patent was defensive as I did not want to find
myself paying royalties to someone else to use my idea. But I have no
objections to collecting fees from people who want to do this on Windows."
(the full email is available here: http://lwn.net/2000/0210/a/vy-patent.html,
I would have provided the entry in the actual RTLinux mailing list archive,
but last I checked the entire month of January 2000 is missing.), why is your
main concern today to tax every person developing real-time solutions with
Linux? Also, if the main purpose of the patent was defensive, then why did
you file suit against Lineo last year? Isn't there a patent estoppel problem
here?

13) You filed the provisional patent application on the 23rd of December 1996.
Given the 1 year limitation about public disclosure, doesn't the following
posting dated October 13th 1995 mean that you should have filed the provisional
application prior to October 13th 1996?
----------------------------------------------------------------------
From: yodaiken@chelm.cs.nmt.edu (Victor Yodaiken)
Subject: Re: Real Time Linux
Date: 1995/10/13
Message-ID: <45kuji$1pq@chaos.aoc.nrao.edu>#1/1
references: <44tmh6$5h0@lyra.csx.cam.ac.uk>
organization: New Mexico Tech Computer Science Department
newsgroups: comp.os.linux.development.system


In article <44tmh6$5h0@lyra.csx.cam.ac.uk>,
Martin Beckett <mgb@mail.ast.cam.ac.uk> wrote:
>
>Can Linux be used as a real-time operating system ?

We are currently working on developing a RT-linux where Linux itself
runs as the lowest priority pre-emptable task under a
rt-very-micro-kernel.  


> I have a control application where the PC runs a camera with a frame rate of
> 1 KHz.  At the end of each frame it must respond to a status bit on an I/O 
> port and read the data.  
> But this must be done within about 100 microsec of the end of the frame.
>
> At the moment I run this under DOS with all the hardware interrupts turned off
> and use a tight loop to monitor the status bit.


So if your task ran every millisecond it would be happy? How much data
must it read?


We'll be looking for simple examples to test in the next few weeks.
----------------------------------------------------------------------

Thanks for your time Victor. Let me know if you need any clarifications
regarding any of those questions.

Best regards,

Karim

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

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

[Roman Zippel]

Hi,

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

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

[Daniel Phillips]

On Sunday 26 May 2002 02:07, Linus Torvalds wrote:
> And once you lack kernel services, from a programming standpoint it
> shouldn't really matter whether it's a kernel module or not.

You're way underestimating the importance of memory protection, both for 
debugging and for those that-can-never-happen-but-it-did system recovery
situations.

-- 
Daniel

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

[Calin A. Culianu]

On Sat, 25 May 2002, Linus Torvalds wrote:

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

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

[Robert Schwebel]

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

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

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

Realtime Linux Situation

[Robert Schwebel]

On Fri, May 24, 2002 at 07:05:13PM -0400, Karim Yaghmour wrote:
> 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.

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

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

[Andreas Dilger]

On May 24, 2002  17:18 -0400, Karim Yaghmour wrote:
> 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/

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

[Alan Cox]

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

> 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

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

[Andreas Dilger]

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

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

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

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

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

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

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

Siemens powermanagment patent? [was Re: patent on O_ATOMICLOOKUP [Re: [PATCH] loopable tmpfs (2.4.17)]]

[Pavel Machek]

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?

> 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

Re: Siemens powermanagment patent? [was Re: patent on O_ATOMICLOOKUP [Re: [PATCH] loopable tmpfs (2.4.17)]]

[Alan Cox]

On Mon, 2002-05-27 at 18:36, Pavel Machek wrote:
> 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

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

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

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

[Alan Cox]

> Just for reference I attached the 13 line long patch in -aa that is
> 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

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

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

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

[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
adam@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."

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

[Alan Cox]

On Mon, 2002-05-27 at 22:52, Adam J. Richter wrote: 
> 	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...

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

[peter]

"Adam J. Richter" <adam@yggdrasil.com> wrote:
> 	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).

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.

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

[Alan Cox]

On Tue, 2002-05-28 at 07:29, peter@horizon.com wrote:
> 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

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

[Robert Kaiser]

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

Now, that's a really nice comparison!

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

As for really safety critical stuff, it definitely does. I know from personal 
experience what it takes to certify software for use in aircrafts. Believe 
me, there is no chance that Linux as we know it could ever pass a DO-178B 
certification process. And for software in aircraft, that is a requirement. 
(Mind you, any form of Windoze doesn't stand a chance either). Similar 
regulations apply to other fields (such as medical devices) and it would 
scare me if that wasn't so. Just do a web search for "Therac-25" if you are 
interested in a (sad) story about what can happen if software in a medical 
device goes wrong.


> (I've seen machine for monitoring patients
> build from "not to use in life-support" chips and running linux.)

As long as the machine only *monitors*, that may be possible. If the machine 
were to e.g. administer medication, that would be a totally different story.

Rob

----------------------------------------------------------------
Robert Kaiser                         email: rkaiser@sysgo.de
SYSGO RTS GmbH
Am Pfaffenstein 14                    phone: (49) 6136 9948-762
D-55270 Klein-Winternheim / Germany   fax:   (49) 6136 9948-10

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

[Ed Vance]

On Sun, May 26, 2002, Alan Cox wrote:
> 
> 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 mediaeval 
> master mason, by intuition, 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).

It's another reason to pray when in a cathedral. :)

The tallest cathedrals that fell were usually doomed by soil instability
rather than design of the cathedral itself. Kind of like running Linux on a
bargain PC ...

---------------------------------------------------------------- 
Ed Vance              edv@macrolink.com
Macrolink, Inc.       1500 N. Kellogg Dr  Anaheim, CA  92807
----------------------------------------------------------------