t1f4387@helios.TAMU.EDU (Mike Farlow) (02/21/90)
A friend and I are beginning a HyperCard project that will be distrubuted to new students at Texas A&M to show them were the different computing facilities are located and what types of hardware/software is at those facilities. After we create this stack for A&M, we hope to be able to offer the shell and a 'Construction Stack' to other universities that would like to have it. Also a demo stack will be posted to the usual places. Since we want to be the central distribution site for this stack, we want deliver full working version only to sites who license with the Trustees of Texas A&M (we hope this license to be free, i.e. John Norstad's Disinfectant). The primary reason being for us to offer support, all copies of the stack must be consistent (less site-specific information). As a result, the DEMO would automatically cripple itself after a preset amount of time. Our question is this: Is it morally reprehensible to develop a piece of software that will destroy/cripple itself? We have considered the following options to accomplish this: o Hiding the destruct mechanism inside a _vital_ XCMD or XFCN. o Deletion of the scripts for all the cards/buttons/backgrounds. (This leaves the stack intact, but functionally useless) o OR physical deletion of the stack from the disk. We would appreciate your comments on our methods. WE ARE NOT soliciting views on the morality of cripple-ware itself. What we need is feedback on the least obnoxious method of crippling our stack. Please reply direct to me since I do not read c.s.m a whole lot. A summary will be posted once the replies have died down. Thank you. -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Michael Farlow, X098MF@TAMVM1.BITNET MicroComputer Specialist X098MF@TAMVM1.TAMU.EDU Computing Services Center Texas A&M University Thank you, John Norstad!!!
bchurch@oucsace.cs.OHIOU.EDU (Bob Church) (02/25/90)
In article <4286@helios.TAMU.EDU>, t1f4387@helios.TAMU.EDU (Mike Farlow) writes: > > Since we want to be the central distribution site for this stack, we > want deliver full working version only to sites who license with the > Trustees of Texas A&M (we hope this license to be free, i.e. John > Norstad's Disinfectant). The primary reason being for us to offer > support, all copies of the stack must be consistent (less site-specific > information). As a result, the DEMO would automatically cripple itself > after a preset amount of time. > > Michael Farlow, X098MF@TAMVM1.BITNET I know that this is not what you want to here but I would like to know why you would even bother to post a self destructing copy. Why not just announce the product and terms for distribution? You compare your idea with Disinfectant but Mr. Norstad doesn't clutter up the BBS's and netfeeds with a program that isn't going to work. ******************************************************************** * * * bob church bchurch@oucsace.cs.ohiou.edu * * * * If economics isn't an "exact" science why do computers crash * * so much more often than the stock market? * * bc * ********************************************************************
denbeste@bgsuvax.UUCP (William C. DenBesten) (02/28/90)
In <4286@helios.TAMU.EDU>, t1f4387@helios.TAMU.EDU (Mike Farlow) writes: > information). As a result, the DEMO would automatically cripple itself > after a preset amount of time. > > Michael Farlow, X098MF@TAMVM1.BITNET I have been writing a program for which fresh versions will be needed periodically. I was, like you are, contemplating crippling the program after a preset date. This really bothers me because someone could very easily get a program that was unusable and have to wait while they were getting a new version. I have come up with what I consider to be a much superior method. When you start the program, it checks to see if it is too old. If it is, it puts up a message that says "This is an old version. To get a current version, send me $5.00 (to cover the disk/copying/shipping) or find it on a local bbs." The user can then click OK and continue with their work. The danger is, of course, that I have to guess at the date of obsolesence. I figure that letting users know that it is time to upgrade and where to upgrade will be something that they find useful. I anticipate new versions every six months and a timeout about a year after release. -- William C. DenBesten is denbeste@bgsu.edu or denbesten@bgsuopie.bitnet