RE: [Slightly OT] Shareware donation collection
RE: [Slightly OT] Shareware donation collection
- Subject: RE: [Slightly OT] Shareware donation collection
- From: "Josh Ferguson" <email@hidden>
- Date: Thu, 19 Feb 2004 16:32:01 -0600
- Thread-topic: [Slightly OT] Shareware donation collection
Charles,
I agree with you to a certain extent. eSellerate offers a feature like this called Product Activation, where a specific serial number is tied to a machine ID (a hash of several unique identifiers, like machine serial number, hard drive SN, MAC address and I don't know what else). When a publisher decides that they want to use Product Activation for their product, they can specify any number of activations for each serial number. For example, with FileStorm, we allow three activations. If someone emails in and says they want their activation limit reset, we will typically do so without any hassle (if you use eSellerate, then you as the publisher have complete control over this). Most customers never have an issue, and we've had literally thousands of failed activation attempts. Product Activation, if set up correctly, is a very effective deterrent for casual piracy. The people who are more than casual pirates probably wouldn't buy your software anyway, so trying to stop them isn't economical. I'm a firm believer that we have not lost any sales because of this feature, and I know for a fact that we have blocked thousands of illegitimate registration attempts.
Josh Ferguson
-----Original Message-----
From: email@hidden
[
mailto:email@hidden]On Behalf Of Charles Srstka
Sent: Thursday, February 19, 2004 11:46 AM
To: Mark Eissler
Cc: CocoaDev List; Mike Brinkman; Finlay Dobbie
Subject: Re: [Slightly OT] Shareware donation collection
On Feb 17, 2004, at 12:36 PM, Mark Eissler wrote:
>
On Feb 15, 2004, at 7:09 PM, Finlay Dobbie wrote:
>
>
>
>
> How would you go about "processing transactions offline"? Sounds like
>
> a high overhead in manpower to me... :-)
>
>
>
>
Absolutely! The amount of overhead in manpower varies with a direct
>
relationship to the number of sales. But it is another way. ;-)
>
>
From what I've learned about esellerate so far is that they do provide
>
a number of options for issuing serial numbers. But the style that I'm
>
particular fond of is a serial that is tied to a MAC address. And I
>
guess the only way to implement such a scheme with esellerate would be
>
to use their SDK and embed payment into the application.
>
>
But I think as others have hinted here in the past, this type of
>
serial number is overkill in the amount of effort it takes to maintain
>
it. Learning to live with lost sales due to warez distributions that
>
include serial numbers is just a cost of doing business. Or is it?
The problem with tying a serial to a MAC address is that it limits your
customers' use of the product. For example, what if your customer has
two machines, a desktop and a laptop, and wants to use your program on
both? What if your customer upgrades to a new Mac and sells his old
one? What if a university computer lab has bought your utility and
wants a site license
Yeah, I know some people restrict software licenses to one copy per
machine. But I personally don't see the point. If the same user owns
two machines, why shouldn't he be able to use the utility he paid for
to solve problems on both of them? It may stop people from just
uploading their serial to the warez sites, but no one ever does that
anyway. What they do is decompile your code and read the assembler, and
figure out your serial algorithm. If your code is specific to one MAC
address, they won't be able to just generate a serial and post it,
sure, but there's nothing stopping them from just writing a serial
generator for your app and posting that.
Basically, I don't bother with stuff like this. The customer comes
first; anything that would make piracy more difficult at the expense of
the customer, I'm not sure is worth it.
Charles
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.