Gentlemen,

There is only one honorable solution to this dilemma. Make your 
application so magically wonderful, and with the prospect of future 
magic to such an extent that each and every user feels guilty if they do 
not comply with license rules, which should be very simple and 
straightforward. The users should also be encouraged to provide feedback 
for use in adding the "future magic" so that they come to relate 
personally to the project.

Those who cannot afford to comply, will feel guilty and will probably 
promote your program with others. Getting your program circulated is far 
more difficult than getting users to comply with the license once they 
are hooked. A registration bonus system might also be used. Word of 
mouth is the cheapest and best form of advertising. Am I naive? I don't 
think so.

This is all in MHO,

Joe Lewis Wilkins

tedd wrote:

>> The netcheckserialnumber functions don't work in Carbon. I protect my 
>> application with a dongle and limit the number of users with that 
>> obsolete function. I have tried appleevents but the examples I have 
>> found require some non-carbon appletalk functions.
>>
>> To authorize new users, I am considering storing data in one of the 
>> data files used by my application that tells 1) how many users are 
>> allowed, how many are logged on, and the current date. The "server" 
>> app (that has the dongle) would reset this info and the apps without 
>> the dongle would read it. By using the date I can prevent someone 
>> from copying the authorizing data file for use without a dongle. A 
>> system without a dongle would not reset the authorized date and the 
>> apps without dongles will read the authorzed date and compare to 
>> actual date and quit when out of range.
>>
>> Is this protection too easy to defeat?
>>
>> Any comments or suggestions appreciated.
>>
>> Bruce Moore
>
>
>
> Bruce:
>
> You can get as elaborate as you want, but it still sounds like your 
> app is writing something to the disk in such a fashion that it will 
> cause future runs not to work. If so, then all one has to do is to 
> copy that original disk document and re-use it every time they want it 
> to run.
>
> I have a program which was released on a trial basis that expired 30 
> days after the initial run. The programmer used a file in the 
> preferences to accomplish this feat. The problem was that all someone 
> had to do was to remove that pref file and the 30 days trial period 
> was reset.
>
> I used a similar approach by storing the number of runs in the 
> resources, but that also had problems when a hacker could look at the 
> resources of a running program and compare it to that of a non-working 
> program and change the resources.
>
> I though of a scheme where my program could generate several different 
> files and even disguised them as OS files -- thus hiding the key 
> files. But, no matter what you do, you only slow down the real hacker.
>
> I think the "real" solution is to make it hard enough and cost more 
> time to break the system than it would be to pay for it.
>
> tedd