[PATCH] Updating real-time and nanokernel maintainers

[PATCH] Updating real-time and nanokernel maintainers

[Karim Yaghmour]

Please apply.

diff -urN linux-2.6.0/MAINTAINERS linux-2.6.0-correct-maintainers/MAINTAINERS
--- linux-2.6.0/MAINTAINERS	2003-12-17 21:58:57.000000000 -0500
+++ linux-2.6.0-correct-maintainers/MAINTAINERS	2003-12-18 14:21:49.000000000 -0500
@@ -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:	rpm@xenomai.org
+L:	adeos-main@nongnu.org
+W:	www.adeos.org
+S:	Maintained
+
  ADVANSYS SCSI DRIVER
  P:	Bob Frey
  M:	linux@advansys.com
@@ -1664,11 +1671,11 @@
  L:	linux-kernel@vger.kernel.org
  S:	Maintained

-RTLINUX  REALTIME  LINUX
-P:	Victor Yodaiken
-M:	yodaiken@fsmlabs.com
-L:	rtl@rtlinux.org
-W:	www.rtlinux.org
+RTAI: REAL-TIME APPLICATION INTERFACE
+P:	Paolo Mantegazza
+M:	mantegazza@aero.polimi.it
+L:	rtai-dev@rtai.org
+W:	www.aero.polimi.it/~rtai/
  S:	Maintained

  S390


Karim
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 514-812-4145

Re: [PATCH] Updating real-time and nanokernel maintainers

[Zwane Mwaikambo]

On Thu, 18 Dec 2003, Karim Yaghmour wrote:

> diff -urN linux-2.6.0/MAINTAINERS linux-2.6.0-correct-maintainers/MAINTAINERS
> --- linux-2.6.0/MAINTAINERS	2003-12-17 21:58:57.000000000 -0500
> +++ linux-2.6.0-correct-maintainers/MAINTAINERS	2003-12-18 14:21:49.000000000 -0500
> @@ -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:	rpm@xenomai.org
> +L:	adeos-main@nongnu.org
> +W:	www.adeos.org
> +S:	Maintained
> +
>   ADVANSYS SCSI DRIVER
>   P:	Bob Frey
>   M:	linux@advansys.com
> @@ -1664,11 +1671,11 @@
>   L:	linux-kernel@vger.kernel.org
>   S:	Maintained
>
> -RTLINUX  REALTIME  LINUX
> -P:	Victor Yodaiken
> -M:	yodaiken@fsmlabs.com
> -L:	rtl@rtlinux.org
> -W:	www.rtlinux.org
> +RTAI: REAL-TIME APPLICATION INTERFACE
> +P:	Paolo Mantegazza
> +M:	mantegazza@aero.polimi.it
> +L:	rtai-dev@rtai.org
> +W:	www.aero.polimi.it/~rtai/
>   S:	Maintained

I'd say take them both out, neither have code in the kernel.

Re: [PATCH] Updating real-time and nanokernel maintainers

[Karim Yaghmour]

Zwane Mwaikambo wrote:
> 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
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 514-812-4145

Re: [PATCH] Updating real-time and nanokernel maintainers

[Zwane Mwaikambo]

On Thu, 18 Dec 2003, Karim Yaghmour wrote:

>
> Zwane Mwaikambo wrote:
> > 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.

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

Re: [PATCH] Updating real-time and nanokernel maintainers

[Karim Yaghmour]

Zwane Mwaikambo wrote:
> 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.

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
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 514-812-4145

Re: [PATCH] Updating real-time and nanokernel maintainers

[Nick Piggin]

Karim Yaghmour wrote:

>
> Zwane Mwaikambo wrote:
>
>> 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.
>
>
> 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...?

Re: [PATCH] Updating real-time and nanokernel maintainers

[Karim Yaghmour]

Nick Piggin wrote:
> I agree with Zwane. People have enough trouble using MAINTAINERS
> as it is. Using it to pat each others backs makes it less useful.

I understand what you mean.

> 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
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 514-812-4145

Re: [PATCH] Updating real-time and nanokernel maintainers

[Jörn Engel]

On Thu, 18 December 2003 19:11:55 -0500, Karim Yaghmour wrote:
> Nick Piggin wrote:
> 
> >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

-- 
Victory in war is not repetitious.
-- Sun Tzu

Re: [PATCH] Updating real-time and nanokernel maintainersy

[yodaiken]

I haven't looked recently, but I did have code in the kernel, thanks
all the same.


On Fri, Dec 19, 2003 at 10:41:23AM +0100, J?rn Engel wrote:
> On Thu, 18 December 2003 19:11:55 -0500, Karim Yaghmour wrote:
> > Nick Piggin wrote:
> > 
> > >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
> 
> -- 
> 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 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/

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

[Karim Yaghmour]

yodaiken@fsmlabs.com 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
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 514-812-4145

Re: [PATCH] Updating real-time and nanokernel maintainersy

[Linus Torvalds]

On Sun, 21 Dec 2003, Karim Yaghmour wrote:
> 
> 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

[Jamie Lokier]

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

[Karim Yaghmour]

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

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

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

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

> 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
-- 
Author, Speaker, Developer, Consultant
Pushing Embedded and Real-Time Linux Systems Beyond the Limits
http://www.opersys.com || karim@opersys.com || 514-812-4145