Updating real-time and nanokernel maintainers
PATCH 1/1 Updating real-time and nanokernel maintainers
Please apply.
MAINTAINERS +12 -5
@@ -181,6 +181,13 @@ W: http://www.tu-darmstadt.de/~tek01/projects/linux.html S: Maintained +ADEOS: ADAPTIVE DOMAIN ENVIRONMENT FOR OPERATING SYSTEMS +P: Philippe Gerum +M: [email protected] +L: [email protected] +W: www.adeos.org +S: Maintained + ADVANSYS SCSI DRIVER P: Bob Frey M: [email protected]
@@ -1664,11 +1671,11 @@ L: [email protected] S: Maintained -RTLINUX REALTIME LINUX -P: Victor Yodaiken -M: [email protected] -L: [email protected] -W: www.rtlinux.org +RTAI: REAL-TIME APPLICATION INTERFACE +P: Paolo Mantegazza +M: [email protected] +L: [email protected] +W: www.aero.polimi.it/~rtai/ S: Maintained S390
Karim
Signature · 3 lines
Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || [email protected] || 514-812-4145
Quoted 22 lines · Karim Yaghmour
diff -urN linux-2.6.0/MAINTAINERS linux-2.6.0-correct-maintainers/MAINTAINERS
MAINTAINERS +7
-1@@ -181,6 +181,13 @@ W: http://www.tu-darmstadt.de/~tek01/projects/linux.html S: Maintained +ADEOS: ADAPTIVE DOMAIN ENVIRONMENT FOR OPERATING SYSTEMS +P: Philippe Gerum +M: [email protected] +L: [email protected] +W: www.adeos.org +S: Maintained + ADVANSYS SCSI DRIVER P: Bob Frey M: [email protected]@@ -1664,11 +1671,11 @@ L: [email protected] S: Maintained -RTLINUX REALTIME LINUX
MAINTAINERS line 1679
Quoted 10 lines
MAINTAINERS +5
-4-P: Victor Yodaiken -M: [email protected] -L: [email protected] -W: www.rtlinux.org +RTAI: REAL-TIME APPLICATION INTERFACE +P: Paolo Mantegazza +M: [email protected] +L: [email protected] +W: www.aero.polimi.it/~rtai/ S: Maintained
I'd say take them both out, neither have code in the kernel.
Quoted 2 lines · Zwane Mwaikambo
On Thu, 18 Dec 2003, Karim Yaghmour wrote:
I'd say take them both out, neither have code in the kernel.
RTLinux has never had code in the kernel, but it still had a mention in the maintainers file for quite a number of years. I think that these entries are really pointers for those who are interested in this area of Linux's use. As such, RTAI is the only real free software real-time Linux extension and I think it deserves mention. Nowadays, rtlinux.org is only an alias for fsmlabs.com, which I think pretty much sums up the situation.
Karim
Signature · 3 lines
Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || [email protected] || 514-812-4145
Quoted 5 lines · Karim Yaghmour
Quoted 2 lines · Zwane Mwaikambo
On Thu, 18 Dec 2003, Karim Yaghmour wrote:
I'd say take them both out, neither have code in the kernel.
Quoted 8 lines
RTLinux has never had code in the kernel, but it still had a mention in the maintainers file for quite a number of years. I think that these entries are really pointers for those who are interested in this area of Linux's use. As such, RTAI is the only real free software real-time Linux extension and I think it deserves mention. Nowadays, rtlinux.org is only an alias for fsmlabs.com, which I think pretty much sums up the situation.
But you're forgetting what the MAINTAINERS file is for. I can't but help thinking that this is linked with the email you sent earlier, but that's just me. Frankly i reckon this particular case could be settled by removing both from MAINTAINERS as neither has code in the 2.6 linux kernel. Anybody looking for realtime Linux kernel capabilities can just do a Google.
Thanks
Quoted 6 lines · Zwane Mwaikambo
But you're forgetting what the
MAINTAINERSfile is for. I can't but help thinking that this is linked with the email you sent earlier, but that's just me. Frankly i reckon this particular case could be settled by removing both fromMAINTAINERSas neither has code in the 2.6 linux kernel. Anybody looking for realtime Linux kernel capabilities can just do a Google.
Yes, yes, and guess what shows up top on that google results list :)
Seriously though, the final decision isn't mine. I've submitted the patch and I personally think that it's more than justfied. I'll leave it to the wisdom of the people in charge to make the appropriate decision.
Karim
Signature · 3 lines
Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || [email protected] || 514-812-4145
Quoted 11 lines · Karim Yaghmour
Quoted 6 lines · Zwane Mwaikambo
But you're forgetting what the
MAINTAINERSfile is for. I can't but help thinking that this is linked with the email you sent earlier, but that's just me. Frankly i reckon this particular case could be settled by removing both fromMAINTAINERSas neither has code in the 2.6 linux kernel. Anybody looking for realtime Linux kernel capabilities can just do a Google.
Quoted 6 lines
Yes, yes, and guess what shows up top on that google results list :)
Seriously though, the final decision isn't mine. I've submitted the patch and I personally think that it's more than justfied. I'll leave it to the wisdom of the people in charge to make the appropriate decision.
I agree with Zwane. People have enough trouble using MAINTAINERS as it is. Using it to pat each others backs makes it less useful.
As Zwane said, neither have code in the kernel, so I don't see how you think it is justified...?
Quoted 2 lines · Nick Piggin
I agree with Zwane. People have enough trouble using
MAINTAINERSas it is. Using it to pat each others backs makes it less useful.
I understand what you mean.
Quoted 2 lines
As Zwane said, neither have code in the kernel, so I don't see how you think it is justified...?
It is justified in the same way that the RTLinux entry was justified for those many years. But the bottom line is as I said it before, I personally have no take in this, and I certainly don't want to start a debate on the use of the MAINTAINERS file, others are much more apt than myself to make the proper judgement call on the proper use of that file.
Karim
Signature · 3 lines
Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || [email protected] || 514-812-4145
Quoted 7 lines · Karim Yaghmour
Quoted 2 lines · Nick Piggin
As Zwane said, neither have code in the kernel, so I don't see how you think it is justified...?
It is justified in the same way that the RTLinux entry was justified for those many years.
Which is another way of saying not at all. Unless the file is renamed to NEAT_PROJECTS, take out any non-maintainers.
Jörn
Signature · 2 lines
Victory in war is not repetitious. -- Sun Tzu
Re: [PATCH] Updating real-time and nanokernel maintainersy
I haven't looked recently, but I did have code in the kernel, thanks all the same.
Quoted 22 lines · J?rn Engel
Quoted 7 lines · Karim Yaghmour
Quoted 2 lines · Nick Piggin
As Zwane said, neither have code in the kernel, so I don't see how you think it is justified...?
It is justified in the same way that the RTLinux entry was justified for those many years.
Which is another way of saying not at all. Unless the file is renamed to
NEAT_PROJECTS, take out any non-maintainers.Jörn
Signature · 7 lines
Victory in war is not repetitious. -- Sun Tzu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Signature · 5 lines
--------------------------------------------------------- Victor Yodaiken Finite State Machine Labs: The RTLinux Company. www.fsmlabs.com www.rtlinux.com 1+ 505 838 9109
Re: [PATCH] Updating real-time and nanokernel maintainersy
Quoted 2 lines · [email protected] wrote:
I haven't looked recently, but I did have code in the kernel, thanks all the same.
Are you saying that there's code in the kernel that is subject to your patent?
If there is, then it should definitely be taken out. First, as Linus has stated recently (and as has been the policy for a while), the kernel should avoid having any patented code
(http://www.ussg.iu.edu/hypermail/linux/kernel/0312.2/0624.html).
Second, "RTLinux Free" is being ported over to Adeos
(http://www2.fsmlabs.com/pipermail/rtl/2003-December/013178.html).
Best regards,
Karim
Signature · 3 lines
Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || [email protected] || 514-812-4145
Re: [PATCH] Updating real-time and nanokernel maintainersy
Quoted 4 lines · Karim Yaghmour
If there is, then it should definitely be taken out. First, as Linus has stated recently (and as has been the policy for a while), the kernel should avoid having any patented code
That's not true.
The kernel should have no patented code THAT DOESN'T HAVE A LICENSE.
There are several cases where this came up: RCU is one obvious one, but there were also issues with Intel's initial submissions of some of the networking drivers where they didn't want to originally release under the GPL because of worrying about patents they owned.
The email you quote expressly says "unless you can get the patent holder to grant a license". And the RTLinux patents were licensed to GPL'd projects. See the RTLinux "open patent license".
I don't understand why people continually complain about the RTLinux patents. I bet it's because Victor has all the easy charm of Larry McVoy, but I don't see why people still continue to spread obvious mis-information about the situation.
It's doubly discgusting with some of the people who were trying to spread all the FUD and mis-information were doing so because they were themselves doing a non-GPL microkernel, and they complained about how the patents were somehow against the GPL and wanted to get community support by trying to make out the situation to be somehow different from what it was.
I'm not a supporter of software patents, but while I dislike them, I don't dislike them _nearly_ as much as I dislike dishonest people.
Linus
Re: [PATCH] Updating real-time and nanokernel maintainersy
Quoted 4 lines · Linus Torvalds
There are several cases where this came up: RCU is one obvious one, but there were also issues with Intel's initial submissions of some of the networking drivers where they didn't want to originally release under the GPL because of worrying about patents they owned.
It's commonly understood that patents licensed to _all_ GPL'd projects are ok by the GPL, but when they are limited to _specific_ GPL'd projects they would violate the GPL.
So for example it would not be acceptable _if_ Red Hat's patents were licensed just for Red Hat Linux, but it's fine because Red Hat licenses its patents for all GPL projects.
In the Linux kernel, 2.6.0, I see two minor problems and one major. First the minors:
1. Code under arch/m68k contains this notice:
You are hereby granted a copyright license to use, modify, and distribute the SOFTWARE so long as this entire notice is retained without alteration in any modified and/or redistributed versions, and that such modified versions are clearly identified as such. No licenses are granted by implication, estoppel or otherwise under any patents or trademarks of Motorola, Inc.
The copyright is a BSD-like license, no problem there. But the part about patent licenses appears to either contradict the GPL, or imply that there are no patents to license anyway.
2. Documentation/sound/alsa/SB-Live-mixer.txt draws our attention to 10 patents that are relevant to the SB-Live-mixer implementation.
It doesn't say we're licensed to use them.
3. The MTD flash translation layer patent(s) may not be acceptably licensed. It's obvious that they are against the spirit of GPL; I'm not sure if they satisfy the letter, and that's after reading the GPL carefully (but I'm not a lawyer). From drivers/mtd/ftl.c:
LEGAL NOTE: The FTL format is patented by M-Systems. They have granted a license for its use with PCMCIA devices:
"M-Systems grants a royalty-free, non-exclusive license under
any presently existing M-Systems intellectual property rights necessary for the design and development of FTL-compatible drivers, file systems and utilities using the data formats with PCMCIA PC Cards as described in the PCMCIA Flash Translation Layer (FTL) Specification."
Use of the FTL format for non-PCMCIA applications may be an infringement of these patents. For additional information, contact M-Systems (http://www.m-sys.com) directly.
The difficulty is that a person is not free to use the code in ftl.c (and some other files) on any computer they want, nor to take the code and use it in other ways.
This paragraph is from the the preamble of the GPL:
Finally, any free program is threatened constantly by
software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must
~~~~~~~~~~~~~~~
be licensed for everyone's free use or not licensed at all.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
It isn't clearly stated whether that means everyone's free use generally, or everyone's free use provided they are only using it on a PCMCIA device.
If the latter is permitted, then I hazard that everyone's free use provided they are only using it on Red Hat Linux is also permitted. That sounds absurd, so by reductio ad absurdum the MTD license is _not_ sufficient license to include the code in drivers/mtd/ in any GPL project, including Linux.
Finally, the config help entry for CONFIG_FTL has this to say:
You may find that the algorithms used in this code are patented unless you live in the Free World where software patents aren't legal - in the USA you are only permitted to use this on PCMCIA hardware, although under the terms of the GPL you're obviously permitted to copy, modify and distribute the code as you wish. Just not use it.
~~~~~~~~~~~~~~~
If the author is correct, then it _is_ permitted to copy, modify and distribute code, and the patent restriction comes into play _only_ when the code is used. In other words, distributing GPL'd source which has patent-infringing uses is fine for the distributor; only the person who uses the code is infringing and may be liable.
However I venture to suggest the author of the config help entry is not a lawyer either, and we should not take his words too precisely.
-- Jamie
Re: [PATCH] Updating real-time and nanokernel maintainersy
In reply to Linus TorvaldsQuoted 7 lines · Linus Torvalds
Quoted 3 lines
If there is, then it should definitely be taken out. First, as Linus has stated recently (and as has been the policy for a while), the kernel should avoid having any patented code
That's not true.
The kernel should have no patented code THAT DOESN'T HAVE A LICENSE.
You're right, I didn't use the _exact_ same wording, but you seem to be seeing an intent to deceive where there was none.
Quoted 1 line
The email you quote expressly says "unless you can get the patent holder to grant a license". And the RTLinux patents were licensed to GPL'd projects. See the RTLinux "open patent license".
As in May 2002, you're still reading the license but ignoring the FUD spread by the patent holder.
But all that RTLinux patent business is really beside the point (and has been for quite some time.) The point is that the RTLinux patent is a non-issue at this stage because I basically applied the other thing you were suggesting in that above-mentioned email: "find an unencumbered algorithm." The Adeos nanokernel is such an algorithm and, if I read you correctly, should therefore be preferable to one which is patented and somehow licensed for use by GPL software.
Quoted 4 lines
I don't understand why people continually complain about the RTLinux patents. I bet it's because Victor has all the easy charm of Larry McVoy, but I don't see why people still continue to spread obvious mis-information about the situation.
Well, I have to dare ask: Do you really understand the situation?
Fact is, I don't personally care about the RTLinux patent anymore, and neither do any of the folks who had taken part in the May 2002 debate on the topic. Why? Because we've implemented a nanokernel that can provide deterministic response times based entirely on scientific publications that pre-date the preliminary patent filling by more than one year, and which is therefore not subject to the patent.
I've personally written a book on the topic of building embedded Linux systems, and have been in constant contact with people building such systems for quite a few years. I may not know everything, but my knowledge, limited as it may be, tells me that Linux has a serious problem in regards to its use in real-time applications because of continued FUD coming from statements such as those made by Victor in the interview I'm referring to in my earlier email.
Technically, though, (and this is really the most important point I have to make in this email):
THE RTLINUX PATENT IS __NOT__ AN ISSUE ANYMORE BECAUSE OF THE ADEOS NANOKERNEL.
So my question to you is this: Do you prefer continue supporting those who are holding a patent against Linux or those who have found a way to obtain the same results using a method which is unencumbered by patents?
My patch for replacing the RTLinux entry wasn't a complaint about the RTLinux patent, it's just a reflection of the de-facto situation regarding Linux's use in real-time applications.
Quoted 1 line
It's doubly discgusting with some of the people who were trying to spread all the FUD and mis-information were doing so because they were themselves doing a non-GPL microkernel, and they complained about how the patents were somehow against the GPL and wanted to get community support by trying to make out the situation to be somehow different from what it was.
Non-GPL microkernel? Sorry, I don't know anything about that.
What I, and everyone involved in this, did ask for (and you can read the original in my initial response to you in the May 2002 thread here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=102228176631331&w=2) is for non-GPL _applications_. And I continue to maintain that the FUD spread by statements such as those made by Victor in his latest interview about the fact that hard-real-time applications are somehow encumbered by a patent is hurting Linux.
As for the alleged FUD you seem to think the likes of me are spreading, then care to read Victor's latest interview? Here's Victor quoting "a guy from one of the huge telecommunications equipment companies": "We are very aware of the RTLinux technology, but your patent makes things awkward for us."
Does this or does this not hurt Linux?
Quoted 1 line
I'm not a supporter of software patents, but while I dislike them, I don't dislike them _nearly_ as much as I dislike dishonest people.
It's not unheard of for people in a position of influence to blunder. I think you are mistaken here, and will not entertain a tit-for-tat response to your ad-hominem attacks. You seem to be unaware of the issues and/or refuse to seek further understanding. That is your choice, and if nothing else, you are consistent in not wanting to revisit your stance on RTLinux. The bottom line is that it's your own OS that is suffering. I'm certainly in no position to impose it upon you to help your own self, and I certainly can't help you if you don't want to be helped, but I will continue my efforts to further Linux's use in the real-time field because I believe this is a worthy goal.
Best regards,
Karim
Signature · 3 lines
Author, Speaker, Developer, Consultant Pushing Embedded and Real-Time Linux Systems Beyond the Limits http://www.opersys.com || [email protected] || 514-812-4145