carlton@apollo.HP.COM (Carlton B. Hommel) (07/12/90)
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.mike@tuvie (Inst.f.Techn.Informatik) (07/13/90)
In article <4b8c2cb1.20b6d@apollo.HP.COM>, carlton@apollo.HP.COM (Carlton B. Hommel) writes: > 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. > I think the GNU GENERAL PUBLIC LICENSE does *NOT* prohibit HP/Apollo from distributing perl with DOMAIN/OS. Quite on the contrary, the FSF explicitly say that companies should ship this stuff with their software. Of course, WITHOUT BILLING THE CUSTOMERS. I think I remember having read somewhere that OSF want to make GNU cc their `official' compiler? How will HP/Apollo follow this if the lawyers hate the GNU License? bye, mike ____ ____ / / / / / Michael K. Gschwind mike@vlsivie.at / / / / / Technical University, Vienna mike@vlsivie.uucp ---/ Voice: (++43).1.58801 8144 e182202@awituw01.bitnet / Fax: (++43).1.569697 ___/
glenn@bitstream.com (Glenn P. Parker) (07/13/90)
All Carl's reasons seem logical to me, but I would still like to have PERL on my Apollo 3500, even without support from HP/Apollo. I trust in the net for bugfixes and support more than I do Apollo. Apollo won't tell you about bugs unless you find them yourself (thanks a lot, guys). The net will tell you about bugs as soon as the first person finds them. And the turnaround is measured in days, not months. So what if HP/Apollo can't support it officially? Support it unofficially! Make it available for anonymous ftp/uucp, and enourage company participation in the process of improving the software via Usenet. If you submit that "business considerations" prevent you from doing what you know, in your heart, is right, you deserve to lose all your customers. Don't let the b*st*rds (oops, I mean lawyers) get you down! Damn the torpedoes! etc. No offense, Carl. I can only applaud your efforts to date, I just think you are giving up too soon. -- -------------------------------------------------------------------------- Glenn P. Parker Bitstream, Inc. uunet!huxley!glenn 215 First Street glenn@bitstream.com Cambridge, MA 02142-1270
mike@hpfcso.HP.COM (Mike McNelly) (07/14/90)
> In article <4b8c2cb1.20b6d@apollo.HP.COM>, carlton@apollo.HP.COM (Carlton B. Hommel) writes: > > 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. > > > I think the GNU GENERAL PUBLIC LICENSE does *NOT* prohibit HP/Apollo from > distributing perl with DOMAIN/OS. Quite on the contrary, the FSF explicitly say > that companies should ship this stuff with their software. Of course, > WITHOUT BILLING THE CUSTOMERS. > I think I remember having read somewhere that OSF want to make GNU cc their > `official' compiler? How will HP/Apollo follow this if the lawyers hate > the GNU License? > > bye, > mike > ____ ____ > / / / / / Michael K. Gschwind mike@vlsivie.at > / / / / / Technical University, Vienna mike@vlsivie.uucp > ---/ Voice: (++43).1.58801 8144 e182202@awituw01.bitnet > / Fax: (++43).1.569697 > ___/ Sorry, Mike, but large corporations have to deal with real legal opinions, not yours or mine. If the lawyers say that's the way it is, that's the way it is (for us). What OSF wanted to do for an official compiler is at best hearsay and probably not real accurate anyway. OSF is not yet in the mode of specifying an official compiler. Mike McNelly mike%hpfcla@hplabs.hp.com
eric@egsner.cirr.com (Eric Schnoebelen) (07/15/90)
In article <4b8c2cb1.20b6d@apollo.HP.COM> carlton@apollo.hp.com (Carlton B. Hommel) writes: - - 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. Sounds like a popular compliant.. A lot of people don't understand, and therefore won't come near, the GPL. My reading of the GPL says that you can ship the software licensed under it, as long as you don't charge extra for it, and you make the source available. And making source available is not that hard. Just include an additional product on the install tape, or an additional product tape that contains nothing but the GPL covered source. - 2. No Support - When a computer company ships out software, they will end up - taking bug reports on it. [...] - - 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. If you believe perl to already have an excellent self test suite, as well as excellent support, why not collect a small group to support it. From what I have seen the group needn't be more than one or two people, since the most popular answer will be "fixed in the next release" anyway.. (and by the time the next release is put out, Larry and Co. will have fixed all those problems anyway.. :-) - 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. - - 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? [ I've tried to stay vendor neutral until now. Now I'll put on my Convex employee hat. ] Well, Convex will be shipping perl as a supported product in the 9.0 release of the OS. We are also shipping gnu emacs as a portion of the standard release. We provide complete sources for the product that shipped with the release, as an optional product on the standard utilities release tape. Support for perl and gnu emacs comes out of the normal programming support pool for utilities and layered products. I am a portion of that programming support pool, and have yet to do any bug fixes, etc to the perl sources. I will admit to modifying Larry's Makefile to use the Convex standard install procedure, but other than that, I believe that we have not touched it. As a Convex employee, I'm glad that HP is not shipping perl with their OS, that gives us another leg up on them. (Not that Convex and HP directly compete in the market place.) As a perl user, I'm disappointed in their managements view about such a useful tool, and that I won't be able to find it on future versions of my HP workstation (except for the fact that tchrist will build it for internal use anyway) -- Eric Schnoebelen eric@cirr.com schnoebe@convex.com Artificial Intelligence is neither -- it consists of quite natural people programming computers to do dumb things. - Bob Spitzer
nazgul@alphalpha.com (Kee Hinckley) (07/16/90)
In article <9330003@hpfcso.HP.COM> mike@hpfcso.HP.COM (Mike McNelly) writes: >Sorry, Mike, but large corporations have to deal with real legal >opinions, not yours or mine. If the lawyers say that's the way it is, >that's the way it is (for us). *** Flame On *** And in one sentence you have summed up the difference between HP and Apollo. If that's the "HP Way", I pray that Apollo never becomes subsumed by it. Sorry, but I have no patience for lemmings. *** Flame Off *** A corporate lawyer's job is to protect their company. Unfortunately most of them take the easy way out and just say "no" rather than actually research the problem. I might point out that both Apple and NeXT ship GNU products, and NeXT at least, uses them in the production of the system. There is no legal reason not to do this. Question "authority". -kee -- Alphalpha Software, Inc. | motif-request@alphalpha.com nazgul@alphalpha.com |----------------------------------- 617/646-7703 (voice/fax) | Proline BBS: 617/641-3722 I'm not sure which upsets me more; that people are so unwilling to accept responsibility for their own actions, or that they are so eager to regulate everyone else's.
weiner@novavax.UUCP (Bob &) (07/17/90)
In article <4b8c2cb1.20b6d@apollo.HP.COM> carlton@apollo.HP.COM (Carlton B. Hommel) writes:
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 a
court challenge waiting to happen....Heck, we aren't even allowed
to use GNU utilities (gcc, bison, ...) to produce binaries for
product shipment.
I would really appreciate it if someone would elaborate on this. The
Apollo OS would be so much more usable if they included GNU Emacs with
it, but as this statement makes clear, Apollo's lawyers are leaning on
the conservative side. Notice that the conservative side need not be
the customer's side and hence one may question such a company's
commitment to providing its customers the best available tools.
The GNU license clearly states that aggregation of other programs with
theirs does not bring the other programs under the license agreement.
The only thing it is trying to protect is GNU software itself, not any
other software that is produced using GNU tools (then no one would be
able to use GNU Emacs).
Until a lawyer or a bright person can provide a convincing argument
otherwise, this sounds like nothing more than a cop out.
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.
This must be why Apollo's documentation doesn't even let people know
there is a very useful directory called /domain_examples. If a free,
unsupported tool is better than your proprietary tool, then you should
take it under your wing and ship it with your own fixes and your own
support. That way, your R&D people and your customers get the best
tools and still only have to support one of each type.
If Apollo has the resources to support Aegis, BSD, and SysV and all the
many revs of each (which it probably doesn't, hence the small number of our
support questions that ever get answered adequately), then it should be
able to pick up some of the most useful freeware and support that too.
It's just the not invented here or non proprietary enough syndrome once
again.
I say this as a daily Apollo user, if you can believe that. I hope
letters like this are being copies or e-mailed to HP/Apollo
vice-presidents so they can here what technical customers want.
--
Bob Weiner Usenet: ...!gatech!uflorida!novavax!weiner
Internet: weiner%novavax@bikini.cis.ufl.eduSRFERGU%ERENJ@PUCC.PRINCETON.EDU (Scott Ferguson) (07/18/90)
Let's see now... Apollo's got a conservative business outlook on things like GNU software... Sun, and MacIntosh seem to have a non-conservative business strategy... Sun and MacIntosh both seem to have been doing better than their competition in their respective markets... Do you suppose it's because the hardware's got an extra MHz on the clock? Or perhaps do these conservative "don't get involved with it" business directions seem to be hurting those who apply them? Scott Ferguson
domo@tsa.co.uk (Dominic Dunlop) (07/18/90)
[Note Followup-To above. Specify wider distribution if you feel it appropriate. This article has been separately possted to comp.std.unix as Volume-Number: Volume 20, Number 133, message id <10178@cs.utexas.edu>] In article <4b8c2cb1.20b6d@apollo.HP.COM> carlton@apollo.hp.com (Carlton B. Hommel) writes: >I've spent several hours over the past few weeks, trying to get perl included a s >part of the next base software release. It won't happen, for the following >reasons... > >1. The GNU GENERAL PUBLIC LICENSE >... > >2. No Support >... [Cogent, if besuited, explanations omited -- dig up original posting QUICK if interested.] > >In short, while R&D might think that perl is the best thing since V7, those dre aded >"business considerations" currently prevent our shipping this truely outstandin g >utility. Thanks for trying, Carl. >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 whatev er >standards bandwagons come down the pike, if perl makes it into Posix, 1003.?, O SF, >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 c an >say that our competition is shipping perl, that might swing some weight. Is an yone >spearheading an effort to get perl included in the "Real Unix" standards? > Not to my knowledge. Standardizing the shell and tools is quite enough work for now and the next year or two. (That's what 1003.2 is doing.) 1003.7, on system administration, might be interested, but they're currently developing a framework for administration -- trying to work out what the problem is before they propose a solution -- whereas the philosophy of perl, as applied to administration, is to make it easier to hack up ad-hoc solutions (and none the worse for that). -- Dominic Dunlop
meissner@osf.org (Michael Meissner) (07/26/90)
In article <1678@tuvie> mike@tuvie (Inst.f.Techn.Informatik) writes: | In article <4b8c2cb1.20b6d@apollo.HP.COM>, carlton@apollo.HP.COM (Carlton B. Hommel) writes: | > 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. | > | I think the GNU GENERAL PUBLIC LICENSE does *NOT* prohibit HP/Apollo from | distributing perl with DOMAIN/OS. Quite on the contrary, the FSF explicitly say | that companies should ship this stuff with their software. Of course, | WITHOUT BILLING THE CUSTOMERS. | I think I remember having read somewhere that OSF want to make GNU cc their | `official' compiler? How will HP/Apollo follow this if the lawyers hate | the GNU License? Since I'm the main support person for GCC at OSF, I guess I'm the best person to answer this. To the best of my knowledge what I'll say below is the current policy, but since I'm not a lawyer, nor a high level manager, nor do I play them on television, I can't speak for OSF in an official capacity. Officially, GCC is not part of our OSF/1 release. This is because there was some concern amongst some of our customers about the GPL, and the fact that it is anticipated that some of the companies porting OSF/1 will be using their own inhouse compilers instead of GCC. We will ship our version of GCC somewhere in the release media, and people can use it as long as they adhere to the GPL. I believe we will be shipping other sources in a similar fashion like many other companies do with unsupported software. As a side note, I was one of the people at Data General to get the ball rolling to use GCC as the released compiler. It took some doing, but the DG lawyers felt they could live with the contract. I guess any legal document can be subject to different interpretations by different lawyers. -- Michael Meissner email: meissner@osf.org phone: 617-621-8861 Open Software Foundation, 11 Cambridge Center, Cambridge, MA Do apple growers tell their kids money doesn't grow on bushes?