greg said:
>   There is no hardware unique serial number 
>   for a Mac that you can rely on.

this, of course, is the song-and-dance we usually do.

i usually am with the 
"can't be done well, and certainly isn't worth the effort" crowd, 
and my registration obstacles are laughably simply.
(but they seem to work just fine anyway.)

however, i am coming to the opinion that it _could_ be done,
and fairly well, and that it _might_ well be worth the effort.

hear me out...


>   And even if there was, 
>   do you really want to inconvience a legitmate user 
>   who buys a new computer to replace his old one 
>   and finds he can no longer run your program? 

if you defined the original purchase as "for-one-machine-only",
then that "inconvience" is a part of the deal, so i think it'd be fair.

and i think a significantly lower price for "one-machine-only"
agreements would make them palettable, perhaps even _preferable_, 
to users.

i'm thinking here of a one-machine prices in the $1-$10 range
(for shareware or commercial products typically running $10-$80).

i think that _even_initially_, this level might deliver more _profit_ ,
but it definitely would deliver more _users_, and _paying_ ones,
which we could certainly leverage into more profits down the line.


>   Or he reformats his hard drive, 
>   reinstalls your program, and finds it won't run?

a pool of variables that could "bend" to such changes
without "breaking" could easily handle _these_ situations.

especially if we _tell_ the user to make changes gradually, 
in small chunks, so the program could "bend" several times,
rather than "breaking" once, i think that would be very fair.

even in the case of a "break", if the user is buying all that hardware, 
in essence creating a "new" machine within the guts of the old,
it's not unreasonable to ask them for a _few_ bucks for a new copy,
is it?  assuming the agreement was on a "one-machine" basis...

-bowerbird