smb@ulysses.att.com (Steven Bellovin) (05/09/91)
In article <NIX.91Apr29140634@valis.asd.sgi.com>, nix@asd.sgi.com (Sold to the highest Buddha) writes: > dc@caveat.berkeley.edu (Dave Cottingham) writes: > > Is this include file patent a hoax, > > I posted the same question several months ago and got nothing back in > the way of references. As far as I'm concerned it's a net.legend. The patent number is 4,674,040, issued on June 16, 1987 to Barbara Barker, Irene Hernandez, and Rex McCaskill, and is assigned to (blare of trumpets) IBM. RMS kindly provided me with the number a few weeks ago; I just got a copy of the patent. The essence of what they're saying is new is that they keep a back-pointer to the include file. If you take the merged file, and run it through some formatter, and then edit the result, the changes are fed back to the included files. That said, they are trying to claim more or less the #include directive. Well, not exactly -- to quote their Claim 1 precisely, they claim A method for merging a portion of one document into another document, said method comprising: (a) including a reference to said another document to said portion; and (b) causing said portion to be merged with said another document and displayed in merged form. So to violate their patent, one would have to have a facility that let you specify just a *portion* of a file to be included... Big change, right? Not obvious to ``one skilled in the art''? Subsequent claims mention that the merged document must be in editable form, that it must include the back pointers, that changes are propagated back (the real thing they did, or think they did), and another claim I'm having trouble translating from the legalese. Other sins in the patent include using ``cursor'' as a verb. I confess -- I disagree with Stallman about the concept of software patents. We've had our email discussions on the subject. But I think we can all agree that abuses of the patent system are another matter entirely. --Steve Bellovin
jbuck@janus.Berkeley.EDU (Joe Buck) (05/09/91)
>> dc@caveat.berkeley.edu (Dave Cottingham) writes: >> Is this include file patent a hoax, In article <14730@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes: >The patent number is 4,674,040, issued on June 16, 1987 to Barbara Barker, >Irene Hernandez, and Rex McCaskill, and is assigned to (blare of trumpets) >IBM. RMS kindly provided me with the number a few weeks ago; I just >got a copy of the patent. In that case (unless it took the Patent Office 10 years or more to process the application), clearly there is no danger of gcc or g++ being found in violation of the patent, since the first C compiler that used #include as it is now used is far, far, older than 1987, and court decisions have made it clear that using prior art is never a violation of a patent, even if the patent is found to be valid (IBM's patent would then be restricted to be much narrower in scope, covering only the specific application it was filed for). Still, the patent clearly should not be granted, because it claims things that had been in common use for years. I was concerned that this might be a much older patent, in which case there really would be a danger. -- Joe Buck jbuck@janus.berkeley.edu {uunet,ucbvax}!janus.berkeley.edu!jbuck
guest@geech.ai.mit.edu (Guest Account) (05/09/91)
In article <14730@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes:
I confess -- I disagree with Stallman about the concept of software
patents. We've had our email discussions on the subject. But I think
we can all agree that abuses of the patent system are another matter
entirely.
OK one more time. This is your brain (o). This is your brain on
patents (*). Ssssssssss. Just say no.
---BARBARA BUSHbarmar@think.com (Barry Margolin) (05/10/91)
In article <14730@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes: >So to violate their patent, one would have to have a facility that let >you specify just a *portion* of a file to be included... Big change, >right? Not obvious to ``one skilled in the art''? > >Subsequent claims mention that the merged document must be in editable >form, that it must include the back pointers, that changes are >propagated back (the real thing they did, or think they did), and >another claim I'm having trouble translating from the legalese. This sounds much fancier than the standard #include file mechanism. Most #include facilities don't have any way to specify portions of files, only whole files. An #include mechanism in a programming language implementation doesn't have to provide a way to save or display the merged document, although it may be useful for debugging purposes. And I've never heard of one that automatically propogates changes in the merged document back into the include file. I suspect they're describing something from DCA (IBM's Document Content Architecture, I think) or DISOSS (their DCA-based OA system). Who claims that #include in any C compiler infringes on this patent? >Other sins in the patent include using ``cursor'' as a verb. Any noun can be verbed. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
dricejb@drilex.UUCP (Craig Jackson drilex1) (05/11/91)
In article <14730@ulysses.att.com> smb@ulysses.att.com (Steven Bellovin) writes: [In response to an article asking about the "include file patent". > >The patent number is 4,674,040, issued on June 16, 1987 to Barbara Barker, >Irene Hernandez, and Rex McCaskill, and is assigned to (blare of trumpets) >IBM. RMS kindly provided me with the number a few weeks ago; I just >got a copy of the patent. > >The essence of what they're saying is new is that they keep a >back-pointer to the include file. If you take the merged file, and run >it through some formatter, and then edit the result, the changes are >fed back to the included files. Interesting... The only product which I've used which has that capability is Microsoft Word for Windows. Of course, they have all sorts of cross-license agreements with IBM. However, my reaction to seeing it was, "Gee, somebody finally went to the work of doing that." I suspect that in software there is a fine line between a new idea, and an idea that everybody has thought of but which seemed too expensive in implementation time. If somebody really comes up with a way to do it in 10 lines of code, maybe they should get a 7-year patent on it or so. However, if a large company merely throws programmer time at something and implements something brute-force that should not be patentable. Claimer: I disagree with RMS on software patents, but feel that 17 years is a longer monopoly than necessary. This probably holds true for many other fields, too. -- Craig Jackson dricejb@drilex.dri.mgh.com {bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
bzs@world.std.com (Barry Shein) (05/11/91)
From: barmar@think.com (Barry Margolin) >This sounds much fancier than the standard #include file mechanism. Most >#include facilities don't have any way to specify portions of files, only >whole files. Sure they do: File A: #define USESTUFF #include <junk.h> junk.h: ...whatever... #ifdef USESTUFF ...more whatever... #endif /*USESTUFF*/ I know, sounds silly, but who knows once the lawyers start making claims. That it's not slick doesn't deny its existence. It's fully general. But I don't think this is the issue. >I suspect they're describing something from DCA (IBM's Document Content >Architecture, I think) or DISOSS (their DCA-based OA system). I agree. I doubt C compilers would be in trouble as that's definitely prior art. If anything I think that's the point here. In fact, the C '#include' is almost an exact clone of PL/1's '%include' facility (note the name similarity!) Which IBM might own. Hmm. (Anyone know if the PL/1 pre-processor was part of the original VDL specification? It should be fairly easy to look up. Do other PL/1 compilers generally implement this pre-processor? Is any of this relevant to the issue?) -- -Barry Shein Software Tool & Die | bzs@world.std.com | uunet!world!bzs Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD
sef@kithrup.COM (Sean Eric Fagan) (05/12/91)
In article <GUEST.91May9010033@geech.ai.mit.edu> guest@geech.ai.mit.edu (Guest Account) writes: >OK one more time. This is your brain (o). This is your brain on >patents (*). Ssssssssss. Just say no. >---BARBARA BUSH Oooh. Such a compelling argument. Carries about as much validity as the drug commercial so grossly parodied. And so brave of you, too, to use your real name. I can see how convinced you are of your position. -- Sean Eric Fagan | "I made the universe, but please don't blame me for it; sef@kithrup.COM | I had a bellyache at the time." -----------------+ -- The Turtle (Stephen King, _It_) Any opinions expressed are my own, and generally unpopular with others.
marc@dumbcat.sf.ca.us (Marco S Hyman) (05/12/91)
In article <BZS.91May10200405@world.std.com> bzs@world.std.com (Barry Shein) writes: > > From: barmar@think.com (Barry Margolin) > >This sounds much fancier than the standard #include file mechanism. Most > >#include facilities don't have any way to specify portions of files, only > >whole files. > > Sure they do: [[ description of #define method of partial file inclusion deleted ]] Some compilers provided support for partial file inclusion, too. The Burroughs algol (and derivative) compilers had a compiler command named: $ include <file option> <start option> <stop option> You could do things like $ include "filename" 100 500 % include lines 100 - 500 from "filename" and then later in the code say $ include % includes the remainder of the last file. I just refreshed my memory from a book published in '77. The idea could be much older than that. Certainly it's nothing new. > Is any of this relevant to the issue?) Don't know. // marc -- // home: marc@dumbcat.sf.ca.us pacbell!dumbcat!marc // work: marc@ascend.com uunet!aria!marc
drake@drake.almaden.ibm.com (05/12/91)
In article <27383@drilex.UUCP> dricejb@drilex.UUCP (Craig Jackson drilex1) writes: > If somebody really comes up with a way >to do it in 10 lines of code, maybe they should get a 7-year patent on it or so. >However, if a large company merely throws programmer time at something >and implements something brute-force that should not be patentable. Hmm, I disagree with this on 2 levels. First, what you said seems to boil down to: If I invest $20.00 in an idea, I should get fully exclusive use of it for 7 years. If I invest $1,000,000 in an idea, I should get nothing in return. Come again? If what you really meant was that short, elegant algorithms should get preferential treatment over expensive, ugly ones, well, they do. If I figure out an expensive way to do something, I can patent it. If you then come out with an elegant and cheap way to do it, you can patent THAT. My guess is that your patent will be more in demand than mine. Second, I don't see how programmer time relates to whether something's patentable. To get a patent I don't have to have a working (coded) system...just a new idea. Standard disclaimers go here. Sam Drake / IBM Almaden Research Center Internet: drake@ibm.com BITNET: DRAKE at ALMADEN Usenet: ...!uunet!ibmarc!drake Phone: (408) 927-1861
scs@iti.org (Steve Simmons) (05/13/91)
From: barmar@think.com (Barry Margolin) >This sounds much fancier than the standard #include file mechanism. Most >#include facilities don't have any way to specify portions of files, only >whole files. If memory server, the MTS file system has always provided the feature. It worked something like $CONTINUE WITH <filename>[line#][line#] Given the extreme variation mts files were allowed in line numbering, it could get quite pathological. -- "SPAM is a registered trademark of a pork product packed only by Geo. A Hormel & Co. Corp." -- Sun Technical Bulletin, March 1991, pg ii
dricejb@drilex.UUCP (Craig Jackson drilex1) (05/14/91)
In article <740@rufus.UUCP> drake@drake.almaden.ibm.com writes: >In article <27383@drilex.UUCP> dricejb@drilex.UUCP (Me) writes: >> If somebody really comes up with a way >>to do it in 10 lines of code, maybe they should get a 7-year patent on it or so. >>However, if a large company merely throws programmer time at something >>and implements something brute-force that should not be patentable. > >Hmm, I disagree with this on 2 levels. > >First, what you said seems to boil down to: > > If I invest $20.00 in an idea, I should get fully exclusive > use of it for 7 years. > If I invest $1,000,000 in an idea, I should get nothing in return. > >Come again? That is one possible interpretation. My meaning was: If I invest $20.00 in a really new idea, I should have the priviledge of spending some more money to patent it, so as to get fully exclusive use of it for 7 years. If I invest $1,000,000 to do finally implement an idea that was thought of years ago, that doesn't make it a new, patentable idea. Example: A number of {people, governments} would love to have a way of of factoring the product of large primes. I've got an idea of how to do it: you try each possible factor by division, until you reject all possible numbers. This isn't a very good idea; it would take a lot of computing power to use this idea on large primes. It is also an idea that is taught in every algebra textbook. I hereby dedicate this idea to the public domain. Now say that IBM develops (at presumably large expense) a general-purpose computer that is 1,000,000 times faster than it has today. Assume, for the moment, that this increase of speed makes my idea feasible for a given set of candidates. This fact, in and of itself, should not be grounds for patenting trial-and-error as a method for factoring large numbers. >If what you really meant was that short, elegant algorithms should get >preferential treatment over expensive, ugly ones, well, they do. If I >figure out an expensive way to do something, I can patent it. If you >then come out with an elegant and cheap way to do it, you can patent THAT. >My guess is that your patent will be more in demand than mine. > >Second, I don't see how programmer time relates to whether something's >patentable. To get a patent I don't have to have a working (coded) >system...just a new idea. The emphasis here is should be on *new*. The "obvious to one practiced in the art" should be a major exclusion. Certainly, this argument is overused in the software patent controversy: in software, like many other fields, new ideas seem obvious once they've been thought up. However, my point is that merely implementing something that hasn't been implemented before does me that you've thought of something that hasn't been thought of before. >Sam Drake / IBM Almaden Research Center -- Craig Jackson dricejb@drilex.dri.mgh.com {bbn,axiom,redsox,atexnet,ka3ovk}!drilex!{dricej,dricejb}
mdb@ESD.3Com.COM (Mark D. Baushke) (05/15/91)
On 13 May 91 13:17:32 GMT, scs@iti.org (Steve Simmons) said: Steve> From: barmar@think.com (Barry Margolin) >This sounds much fancier than the standard #include file mechanism. Most >#include facilities don't have any way to specify portions of files, only >whole files. Steve> If memory server, the MTS file system has always provided the Steve> feature. It worked something like Steve> $CONTINUE WITH <filename>[line#][line#] Close. The syntax was: $CONTINUE WITH [<login>:]filename[(start#[,end#[,inc#]])] where login was the four character login id, filename was the up to 14 character filename (case insensitive) start# end# were each allowed to be expressions which yeilded a line number. *F was short hand for the first line number in the file (which could be negative) *L was the short hand for the last line number in the file. inc# was the increment to be added to the current start# to get the subsequent lines. The default value for start# is 1. The default value for end# is *L. The way to append to the end of a file was FILE(*L+1). I have fogotten the default value of inc#, but I have some circa 1979 manuals at home if anyone really want to know. Internally line numbers were stored as a 32 bit integer. Externally, they were displayed as if they had been divided by 1000. Line number 1.000 therefore had an internal representation of 1000. The maximum length of one line in the file was 32768 bytes. It was also possible to give a list of files on the $CONTINUE WITH line: $CONTINUE WITH 1F23:DATA(1,*L)+*SOURCE*(1,1)+1F23:DATA(-1,0.099,0.001) which would let the program read all of the lines from the user account 1F23:DATA starting at line 1 through the end of file followed by reading from the moral equivalent of stdin for one line followed by reading the lines between -1 and 0.099 of DATA. Any of those lines could in turn contain $CONTINUE WITH lines. Steve> Given the extreme variation mts files were allowed in line numbering, Steve> it could get quite pathological. Yup. The Michigan Terminal System was actually very nice to use. The only problem was that it did not have a hierarchical filesystem beyond having a separate directory for each user. I knew folks that put the source of their programs into the negative line numbers and had the executable starting at line 1. Steve> -- Steve> "SPAM is a registered trademark of a pork product Steve> packed only by Geo. A Hormel & Co. Corp." Steve> -- Sun Technical Bulletin, March 1991, pg ii Enjoy! -- Mark D. Baushke mdb@ESD.3Com.COM