🚀 go-pugleaf

I asked whether or not there were any plans for releasing GNU readline
under GLPL instead of GPL and got this response (thanks Len! :-)

    gmlm> FSF is waiting to see if lib-g++ and glibc get substantial
    gmlm> support from people who won't use GPLed libraries (to see if
    gmlm> the GLPL really helps any) before putting any other code
    gmlm> under the GLPL.

I wanted to get a bit more input from other FSF types; perhaps someone
can respond to these mutterings:

If the goal of this "test-flight" of the GLPL is to see how acceptable
it is to companies and organizations which produce *proprietary* code
(isn't that what this test is trying to gauge?), then I think that
restricting GLPL to lib-g++ and especially glibc is a mistake, because
IMHO those are the *least* likely candidates for popular use.

Why?  Because every UNIX system already comes with a libc.a which was
specifically written for that system.  Many such libraries have hacks
and tweaks to increase performance on that system.  It might be argued
that glibc is POSIX, etc., but most newer UNIX's ship with POSIX
conformance, etc.  And poprietary development efforts are by and large
funded by folks with enough money to keep relatively up-to-date with
new releases.

For example, my DG/UX system comes with an excellent set of standard
libraries, with a simple #define I can compile for BSD, SysVR3,
SysVR4, POSIX, XPG3, m88k BCS, m88k OCS and any combination; in short,
just about every real and de-facto standard around.  Also all my
header files are completely ANSI and POSIX compliant and have
correct prototypes.  There's just absolutely no incentive to port
and/or use glibc.

lib-g++ might be more useful since most systems don't come with one.
But very few organizations use C++ for developing proprietary programs
yet, so I doubt you'll see many proprietary products released using
C++ at all, much less using lib-g++ under GLPL, until far enough into
the future that this test will have been judged to be a failure.

In my case I have been unable to provoke a discussion on using GLPL at
DG with the people who might make such a decision, much as I'd like to
sound them out about it, because I haven't been able to come up with a
case where we might want to.  Until something we need is available
under GLPL I suspect this will continue to be the case :-(, and I
don't expect we'll ever need glibc and probably not libg++ for a
long while.

For these reasons it seems to me that lib-g++ and glibc are probably
not accurate barometers of the acceptance of the GLPL.  I think to get
a more accurate picture of whether the GLPL will fly or not you should
release libraries under GLPL with true value-added features which are
not contained on traditional UNIX systems but that proprietary
programs could benefit immensely from (such as GNU readline :-).

Any comments/responses from the FSF folks?

                                                                paul
-----
 ------------------------------------------------------------------
| Paul D. Smith                          |    paul_smith@dg.com    |
| Data General Corp.                     | pds@lemming.webo.dg.com |
| Network Systems Development Division   |                         |
| Open Network Systems Development       |   "Pretty Damn S..."    |
 ------------------------------------------------------------------