syming%B.CC%Berkeley@sri-unix.UUCP (06/25/84)
Four years ago, I worked as a programmer for Business School at Ohio State U. When we ordered SAS/ETS(Statistical Analysis System/Econometic and Time Series) from SAS company, they sent us a tape with a fixed time (two months or so?) payment notice and stated that the program would vanish after that time. Of course, we paid in time and they sent us a 20(?)-digit long key word and instruction to make our trial copy a one-year-life-time program, since the service contract was year by year. I had not realized this was a rare case. Isn't it a common practice for a company to protect their products? -- syming hwang
LIN%MIT-MC@sri-unix.UUCP (06/26/84)
From: Herb Lin <LIN @ MIT-MC>
From: syming%B.CC at Berkeley
They sent us a tape with a fixed time (two months or so?)
payment notice and stated that the program would vanish after that time. Of
course, we paid in time and they sent us a 20(?)-digit long key word and
instruction to make our trial copy a one-year-life-time program, since the
service contract was year by year.
I'm a bit confused. How could this particular program make itself
vanish without some external reference to a date? It seems that a
simple routine to change the date to the date of original purhcase
whenever the routine was invoked would do the trick. Do you know if
anyone ever actually has their program vanish? Maybe the whole thing
was a bluff?darrelj@sdcrdcf.UUCP (06/29/84)
SDC has on at least one occasion shipped a program with a time-bomb in it
(so it would expire at the end of a contract for its use). Since the
technique used was embedded in the software, it certainly could have been
disabled, but it took me an hour of looking at the source code (which IS NOT
shipped, ever, for this product) to understand what was going on (it was not
documented, it even claimed to be something else). Finding it from a
coredump would take days or weeks because it worked by indirectly
introducing a subtle bug which would slowly crash the program.
--
Darrel J. Van Buer, PhD
System Development Corp.
2500 Colorado Ave
Santa Monica, CA 90406
(213)820-4111 x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,sdccsu3,trw-unix}!sdcrdcf!darrelj
VANBUER@USC-ECL.ARPAhes@ecsvax.UUCP (06/29/84)
<>In the good old days, SAS only ran on IBM mainframes (360 & offspring) and so there was the operating system (OS!) to ask for the date. Most large corporations use the date for all sorts of operations, and so probably wouldn't want to set the wrong date at IPL (OS load) in order to avoid paying lease costs. (I believe the dissappearing act works.) Also SAS sells alot of (quite good) tutorial and technical manuals and does a fair amount of answering bug requests over the phone and sending out newsletters, updates, etc. -- none of which would be readily available if you weren't making lease payments (I assume they would be suspicious ...) --henry schaffer genetics ncsu
wmartin@brl-tgr.ARPA (Will Martin ) (07/02/84)
While it would be easy to control the system-date on micros or a small machine which you use by yourself, on a large mainframe in a production shop there are many programs moving in and out of the machine which rely on the system-date being accurate. If you tried to manipulate that date just to make use of software with embedded expiration traps, you would incur more costs from the ill effect on the other jobs than you were saving by not paying for the software package in question. So it is not a foolproof safeguard in an academic or small-machine environment, but pretty effective in a large-machine commercial production shop (the traditional IBM world). Will
dgary@ecsvax.UUCP (07/09/84)
>From: LIN%MIT-MC@sri-unix.UUCP Tue Jun 26 04:04:00 1984 > From: syming%B.CC at Berkeley > They sent us a tape with a fixed time (two months or so?) > payment notice and stated that the program would vanish after that time. Of > >I'm a bit confused. How could this particular program make itself >vanish without some external reference to a date? >... Maybe the whole thing >was a bluff? The package in question was SAS, a large data manipulation and stats package, running on a fair-sized machine (not a micro). The program repeatedly checks the system date during execution. The date-protection business doesn't make it impossible to run the program after the contract expiration date, just inconvenient. It is more an automatic billing system than anything else. And yes, the idea is widely used in the mainframe world, where changing the system date in a multitasking system would play hell with accounting systems, payroll..... D Gary Grady Duke University Computation Center, Durham, NC 27706 (919) 684-4146 USENET: {decvax,ihnp4,akgua,etc.}!mcnc!ecsvax!dgary
brianp@shark.UUCP (07/12/84)
How well protected are the parts that check the system date for
expiration? (i.e. can a clever hacker fiddle around with the
machine code to jump the part that checks the date, thus
disabling the expiration part?)
Brian Peterson {ucbvax, ihnp4, } !tektronix!shark!brianp