doering@kodak.kodak.com (Paul F. Doering) (09/12/90)
The 9/11/90 edition of the Wall Street Journal carries an article headlined "Limits Placed on Software Duplication" and begins with a statement to the effect that there are circumstances under which user's rights of duplication are restricted. Various unspecified sources express their opinions that the ruling by a US district court judge in Philadelphia defines fair use of copyrighted software narrowly. If so, the information actually given in the article doesn't support those opinions. (Notice that -- except for the headline, which I cite here to help readers of legitimately purchased copies of the WSJ find the article in question -- I am paraphrasing to avoid infringement.) :-) The case involves suits and countersuits between IBM and Allen-Myland Inc, a company that apparently makes a living by modifying IBM mainframes to enhance their utility to the people who own (not lease) those mainframes. After a lengthy litigation the surviving claim was IBM's that A-M had copied proprietary microcode already installed in these machines and should instead have bought extra copies of the microcode rather than duplicating what the customer had already bought and paid for. (I believe that A-M modified the copied microcode and then installed the modified version to meet requirements unique to the company that owned the IBM mainframe.) The judge's ruling confirmed IBM's position. Apparently the deciding (and defining) aspect was A-M's intention to use the copied software (microcode) for commercial gain. One presumes that if A-M were a not-for-profit organization, there would have been no basis for IBM's complaint. It would be interesting to guess what would have been the outcome if the computer owners were accused of modifying the microcode on their own IBM machines or if the modifications were being done altruistically by the Girl Scouts to earn an electronics badge. I can't see this decision as setting the narrow standard claimed by the article. It says nothing about my freedom to copy software for back-up, which is surely the most common reason for duplicating. It does not make even more illegal the already illegitimate practice of copying software in order to avoid having to pay the money rightfully due its creator. What it does establish specifically is that I can't buy a copy of your software product and then pay Fred over there to duplicate it and charge me a fee for modifying it to my specs. It establishes Fred's liability as the law-breaker in such a case. I can't see why that's a bulletin to anybody, can you? Given that the WSJ and I are reporting the facts with fair accuracy, do you think that this is such a precedent-setting moment in the history of computing? -- ======================= ==================================================== Paul Doering (for self) Enough small empty boxes thrown into a big empty box doering@kodak.com fill it up. ======================= ========================= -Carl Sandburg ===========
aglew@crhc.uiuc.edu (Andy Glew) (09/12/90)
>The case involves suits and countersuits between IBM and Allen-Myland Inc, a >company that apparently makes a living by modifying IBM mainframes to enhance >their utility to the people who own (not lease) those mainframes. After a >lengthy litigation the surviving claim was IBM's that A-M had copied >proprietary microcode already installed in these machines and should instead >have bought extra copies of the microcode rather than duplicating what the >customer had already bought and paid for. (I believe that A-M modified the >copied microcode and then installed the modified version to meet requirements >unique to the company that owned the IBM mainframe.) Hmm.... Isn't this like you buying a GM car, then taking it to one of those "Supe-it-up" garages, who take out the carburetor, build another carb that'll work like the original, only with better performance, and then putting the new carb in your car? -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]
utoddl@uncecs.edu (Todd M. Lewis) (09/12/90)
In article <AGLEW.90Sep11214735@dwarfs.crhc.uiuc.edu> aglew@crhc.uiuc.edu (Andy Glew) writes: > >Hmm.... Isn't this like you buying a GM car, then taking it to one of >those "Supe-it-up" garages, who take out the carburetor, build another >carb that'll work like the original, only with better performance, and >then putting the new carb in your car? No. It's more like doing the same thing to a rental car. Remember, you can hardly ever _buy_ software. You are only licensed to use it. _____ | Todd M. Lewis Disclaimer: If you want my employer's ||\/| utoddl@ecsvax.uncecs.edu ideas, you'll have to || || utoddl@ecsvax.bitnet, @unc.bitnet _buy_ them. | || utoddl@next1.mscre.unc.edu |___ ("Prgrms wtht cmmnts r lk sntncs wtht vwls." --TML)
malloy@nprdc.arpa (Sean Malloy) (09/12/90)
In article <1990Sep12.123323.1760@uncecs.edu> utoddl@uncecs.edu (Todd M. Lewis) writes: >In article <AGLEW.90Sep11214735@dwarfs.crhc.uiuc.edu> aglew@crhc.uiuc.edu (Andy Glew) writes: >>Hmm.... Isn't this like you buying a GM car, then taking it to one of >>those "Supe-it-up" garages, who take out the carburetor, build another >>carb that'll work like the original, only with better performance, and >>then putting the new carb in your car? >No. It's more like doing the same thing to a rental car. >Remember, you can hardly ever _buy_ software. You are only >licensed to use it. Close, but no cigar. These people have _bought_ the computers, and it is the microcode that is being altered. It's not software, it's firmware -- an integral part of the machine, without which the machine is incapable of running software. An almost exact analogy is to the new breed of cars with electronically-controlled fuel systems, where the mixture, timing, et al, is controlled by a ROM program in order to maximize fuel economy. There is an industry centered around replacing those ROMs with new ROMs programmed to give the car higher performance (at the expense of fuel economy). | "The three most dangerous Sean Malloy | things in the world are a Navy Personnel Research & Development Center | programmer with a soldering San Diego, CA 92152-6800 | iron, a hardware type with a malloy@nprdc.navy.mil | program patch, and a user | with an idea."
michaelb@wshb.csms.com ( WSHB Operations Eng) (09/12/90)
> >customer had already bought and paid for. (I believe that A-M modified the > >copied microcode and then installed the modified version to meet requirements > >unique to the company that owned the IBM mainframe.) > Hmm.... Isn't this like you buying a GM car, then taking it to one of > those "Supe-it-up" garages, who take out the carburetor, build another > carb that'll work like the original, only with better performance, and > then putting the new carb in your car? I believe it is more like buying a new GM car and having an electronics shop read the EPROM in the computer and make you a new copy with different variables. I wonder if GM will start sueing the aftermarket hot rodders? . . Michael -- Michael Batchelor--Systems/Operations Engineer #compliments and complaints WSHB - An International Broadcast Station of # letterbox@csms.com The Christian Science Monitor Syndicate, Inc. #technical questions and reports michaelb@wshb.csms.com +1 803 625 4880 # letterbox-tech@csms.com
mwm@raven.pa.dec.com (Mike (My Watch Has Windows) Meyer) (09/12/90)
In article <9496@skinner.nprdc.arpa> malloy@nprdc.arpa (Sean Malloy) writes:
Close, but no cigar. These people have _bought_ the computers, and it
is the microcode that is being altered. It's not software, it's
firmware -- an integral part of the machine, without which the machine
is incapable of running software. An almost exact analogy is to
the new breed of cars with electronically-controlled fuel systems,
where the mixture, timing, et al, is controlled by a ROM program in
order to maximize fuel economy. There is an industry centered around
replacing those ROMs with new ROMs programmed to give the car higher
performance (at the expense of fuel economy).
My understanding (from reading the article in the SJMN) is that the
the "improvements" included taking a multi-processors IBM mainframe
and turning it into a network of uniprocessor machines, including
copying the microcode needed to make this happen.
Useing the hotrod analogy, it's like taking your 944, and turning it
into 4 1-cylinder motorcycles by cloning the rest of the car around
it. In copying the ROM used to control the engine to those 4
motorcycles, you've violated the copyright on the ROM.
<mike
--
Come rain, come hail, come sleet, come snow Mike Meyer
You don't like to drive to slow mwm@relay.pa.dec.com
You're always in the passing lane decwrl!mwm
It's enough to drive me out of my brainmalloy@nprdc.arpa (Sean Malloy) (09/13/90)
In article <MWM.90Sep12104910@raven.pa.dec.com> mwm@raven.pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >In article <9496@skinner.nprdc.arpa> malloy@nprdc.arpa (Sean Malloy) writes: > is incapable of running software. An almost exact analogy is to > the new breed of cars with electronically-controlled fuel systems, > where the mixture, timing, et al, is controlled by a ROM program in > order to maximize fuel economy. There is an industry centered around > replacing those ROMs with new ROMs programmed to give the car higher > performance (at the expense of fuel economy). >My understanding (from reading the article in the SJMN) is that the >the "improvements" included taking a multi-processors IBM mainframe >and turning it into a network of uniprocessor machines, including >copying the microcode needed to make this happen. This was not apparent from the description of the situation as posted, which only described the company as going in and hacking the microcode. It still seems to me like a nonissue, though; all the microcode, regardless of how hacked it was, is still being used by the processors that ran it before it was modified. If the company that rewrote the microcode isn't retaining a copy of it, then it seems to me that IBM's gripe is essentially that they didn't get to charge big bucks to do the modification themselves -- to use the automotive analogy, like Ford suing you because you didn't use a Ford-employed mechanic when you had your engine bored and stroked. >Useing the hotrod analogy, it's like taking your 944, and turning it >into 4 1-cylinder motorcycles by cloning the rest of the car around >it. In copying the ROM used to control the engine to those 4 >motorcycles, you've violated the copyright on the ROM. More like making four motorized unicycles and copying the steering wheel and pedals. Sean Malloy | "Making something difficult Navy Personnel Research & Development Center | is no substitute for making San Diego, CA 92152-6800 | it impossible." malloy@nprdc.navy.mil |
mwm@raven.pa.dec.com (Mike (My Watch Has Windows) Meyer) (09/13/90)
In article <9504@skinner.nprdc.arpa> malloy@nprdc.arpa (Sean Malloy) writes: >My understanding (from reading the article in the SJMN) is that the >the "improvements" included taking a multi-processors IBM mainframe >and turning it into a network of uniprocessor machines, including >copying the microcode needed to make this happen. This was not apparent from the description of the situation as posted, which only described the company as going in and hacking the microcode. It still seems to me like a nonissue, though; all the microcode, regardless of how hacked it was, is still being used by the processors that ran it before it was modified. Yes, it wasn't apparent from the posted article. That's why I pointed out the other source of information I was using. I don't know enough about multi-processor IBM systems, but I can see two situations that would invole violations of the existing copyright laws: 1) The microcode only existed on one machine, and was run on the others by crossloading or shared memory. 2) The mp implementation is non-symmetric, and only the master ran the microcode in the first place. Either case involves creating new copies of the microcode, which is clearly a violation of the existing copyright laws (though may be considered to be fair use). I'm not saying that either of these cases it true, or that the decision was "right" in some sense. I'm trying to point out that there isn't enough information available to us here to decide if this is as silly as some of the other cases that have been decided in the recent past. <mike -- Come all you rolling minstrels, Mike Meyer And together we will try, mwm@relay.pa.dec.com To rouse the spirit of the air, decwrl!mwm And move the rolling sky.
utoddl@uncecs.edu (Todd M. Lewis) (09/14/90)
In article <9496@skinner.nprdc.arpa> malloy@nprdc.arpa (Sean Malloy) writes: >Close, but no cigar. These people have _bought_ the computers, and it >is the microcode that is being altered. It's not software, it's >firmware -- an integral part of the machine, without which the machine >is incapable of running software. Bzzzzzt. Firmware is software. I therefore must agree with your statement, rephrased: Without software the machine is incapable of running software. Firmware is protected by copyright. The altered microcode is a derivative work of copyrighted material. There is no grey area here. >An almost exact analogy is to >the new breed of cars with electronically-controlled fuel systems, >where the mixture, timing, et al, is controlled by a ROM program in >order to maximize fuel economy. There is an industry centered around >replacing those ROMs with new ROMs programmed to give the car higher >performance (at the expense of fuel economy). Yup. And of late there is a new breed of machines for wordprocessing, controled by word processing software. Dumping one word processor and using another in its place is routine. If the new word processor is a derivative work of the old one though, either somebody struck a deal or somebody broke the law. You are right in one sense--it is an almost exact analogy. > Sean Malloy | things in the world are a > malloy@nprdc.navy.mil | program patch, and a user Todd M. Lewis (utoddl@next1.mscre.unc.edu)
kurt@tc.fluke.COM (Kurt Guntheroth) (09/17/90)
...I can see
two situations that would invole violations of the existing copyright
laws:
1) The microcode only existed on one machine, and was run on the
others by crossloading or shared memory.
2) The mp implementation is non-symmetric, and only the master ran the
microcode in the first place.
Either case involves creating new copies of the microcode, which is
clearly a violation of the existing copyright laws (though may be
considered to be fair use).
Exactly. In case (1) If the original software made copies of itself, it
seems to imply a license to make those copies. If case (2) in fact involves
unique code, then that would be different.