Re: RMS is at it again

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   From: Ulrich Drepper <drepper@redhat.com>
   Date: 26 Jun 2000 14:45:41 -0700

   A few weeks ago RMS started the next attack on me (a single mail,
   followed by indirect tries to take influence, followed by another mail
   today).

Could any of us try to press him to back off?

IMHO a steering committee wouldn't make sense for a project with the
number of people actively contributing that we have now.  In a sense
libc-hacker already is that steering committee.  A formal steering
committee means more burocracy, which we don't need at all.

In my opinion you're functioning pretty good as maintainer of glibc.
Your response time is very low, and glibc is one of the cleanest GNU
projects around.

   Since I don't see any room for maneuvers I see three ways out (those
   longer on this list will remember his last attempt and find the
   possibilities quite similar):

   1. Nothing changes.  Probably the best for the project, worst for RMS'
      ego.

Indeed.  Can't you just ignore RMS and continue what you've been doing
the past few years?

   2. If people want this, I'll split from the FSF and create a "Free libc"
      or whatever.  No restrictions imposed by the FSF (which will make
      many possible contributors happy, especially on the Linux side) will
      hinder the development.

I don't believe this will lead to more contributers.  I don't expect
those people "on the Linux side" who would be made happy by this, to
bring anything constructive to us.

I'm a bit afraid that moving away from the FSF would significantly
increase the amount of politcal flaming.

      It also means that the new code developed on this side (as opposed to
      a potentially continued FSF version) can be used by the FSF since
      assignments are missing.  It also means that the manual cannot be
      printed and sold anymore unless they find somebody to duplicate the
      work).

That would probably mean that other GNU projects wouldn't benefit from
changes made to things like regex.c and strftime.c anymore.

      This approach would only ease my (and probably your) work and will be
      attractive at least in the Linux arena.  Don't know about Hurd.

I don't think "Linux-only" would be good for the project.  The fact
that glibc is actually used on the Hurd, forces us to split out
kernel-dependent stuff, which IMHO is good.

It would probably not be acceptable to use your "Free libc" for the
official GNU system (AKA the Hurd).  That would probably mean that
we'de have to start some sort of "Free Hurd" too.  Otherwise the Hurd
would probably die, which is a bit of a pity since it's so much fun to
hack at.

   3. If #2 is not what people want, I'll step down completely.  Glibc is
      now at a point where it more or less does what I want and I can go
      back to actually using it.

Which means that glibc will become maintainerless, forcing RMS to seek
a new maintainer, which he probably won't find amoung any of us.  That
should teach him!

Seriously, I wouldn't want to force you to step down, but I'm not at
all confident that #2 is a viable option.

Mark