Xref: utzoo comp.lang.perl:1781 comp.sys.apollo:5770
Path: utzoo!attcan!uunet!ns-mx!iowasp.physics.uiowa.edu!maverick.ksu.ksu.edu!zaphod.mps.ohio-state.edu!usc!sdd.hp.com!apollo!carlton
From: carlton@apollo.HP.COM (Carlton B. Hommel)
Newsgroups: comp.lang.perl,comp.sys.apollo
Subject: Why perl can't ship as HP/Apollo base software
Message-ID: <4b8c2cb1.20b6d@apollo.HP.COM>
Date: 12 Jul 90 14:55:00 GMT
Sender: root@apollo.HP.COM
Reply-To: carlton@apollo.hp.com (Carlton B. Hommel)
Organization: Hewlett-Packard Apollo Division - Chelmsford, MA
Lines: 50

I've spent several hours over the past few weeks, trying to get perl included as
part of the next base software release.  It won't happen, for the following
reasons.

1.  The GNU GENERAL PUBLIC LICENSE
    Our legal department has explicitly told R&D that they are not allowed to do
    anything with any program that got anywhere near this document.  While I don't
    want to start a flame war about GNU, our lawyers feel it is too full of holes,
    and is just an court challenge waiting to happen.  This is not a reflection on
    Larry; I discussed potential ways around it with him.  Heck, we aren't even
    allowed to use GNU utilities (gcc, bison, ...) to produce binaries for product
    shipment.

2.  No Support
    When a computer company ships out software, they will end up taking bug reports
    on it.  No matter if you have UNSUPPORTED SOFTWARE all over the man pages, no
    matter if it is shipped in /usr/nosupport/bin, you will get phone calls, bug
    reports, and complaints about it.  Saying a utility is unsupported does not work.
    "But what about patch?", I asked.  We have shipped /usr/new/patch since sr10.
    Well, we got that straight off the Berkeley tape, and haven't touched it since.

    My volunteering to pass any incoming perl bugs to Larry, and comp.lang.perl,
    isn't good enough.  Some R&D group must be willing to take on the responsibility,
    and the appropriate groups are in the usual understaffed/overworked condition.
    Never mind that perl has one of the best test suites ever, or that the Configure
    script make compilation a no-brainer, or that Larry, Randall, and the varied
    hordes reading comp.lang.perl provide bugfixes within hours of a bug report -
    they cannot commit.
  
    Support doesn't just mean fixing bugs.  It also means politely saying "RTFM"
    after a customer trys something, and screams Bug.  Customer service has
    trained people in the Response Center to answer dumb awk and sed questions.
    They won't do it for perl without good reason.

In short, while R&D might think that perl is the best thing since V7, those dreaded
"business considerations" currently prevent our shipping this truely outstanding
utility.  So, how can perl get into Domain/OS, the Apollo software release?  Well,
since we, like most other big companies, follow the policy of jumping on whatever
standards bandwagons come down the pike, if perl makes it into Posix, 1003.?, OSF,
the next Berkeley distribution, or whatever, then we will pick it up.  However, I'm
afraid that perl might be just a little too late for any of these efforts.  

I've taken a shot at it here at HP/Apollo.  What about other companies?  If I can
say that our competition is shipping perl, that might swing some weight.  Is anyone
spearheading an effort to get perl included in the "Real Unix" standards?  

Carl Hommel
carlton@apollo.hp.com
Please note that the above is not an official position or stand of HP, merely the
reflection of discussions I have had with people at HP/Apollo.