protect demos: time out, insert noise, cripple the image with a generated image from jit.lcd (you don't say if its audio or video). more secure if your demo is different from your purchased product.
we tried pace for a while, but is so absurdly expensive for small timers, that it's not worth it. I rolled my own challenge/response thing, but it involves some custom externals and php.
Really, a serial number is mild protection, but so easily circumvented, it's somewhat pointless.
You may want to cripple the demo and just make the purchased download cp-free. Unless you expect to sell a lot, it's easier for you and your customers. We use cp on our video app (lividinstruments.com) becuase we don't have the personal connection to our buyers that I had with previous programs.
My approach for my MIDI-only app was to have my demo timeout (no input) for 30 seconds every 5 minutes or so, then timeout after an hour, requiring a quit/restart. This seems sufficiently annoying. The demo does not currently "die" after X days.
I use Kagi for sales, but I email the app directly. This does have its up/down side, might change that soon. I must ask Kagi about their java implementation to see if it's embeddable in Max.
The purchased app is a separate app (so no "unlocking" the demo), and I embed the registered user's name into it in a way that will be difficult to find & change, so if it appears on limewire etc, at least I'll know who let it loose, for all the good that will do.
If you wanted to lock it down further, you could look at tying it to a specific machine's MAC ethernet address, would probably be best done via java. Ultimately, I think this is more effort than it's worth, and a real pain for users.
As far as preventing users examining the .mxf or otherwise reverse-engineering the app, it's only possible to make it more difficult. Let's not discuss this aspect on the forum. I'd be all in favour of an encrypted standalone format, but that's certainly not on C74's roadmap I believe.
My limited demo will not be unlockable.
Regarding recording audio, I agree that anybody with a brain could keep using the demo without having the need of buying it..
I'll put a buzz here and there every 30 secs. so it will be very annoying and unpractical to use the demo for other purposes than exploring its functions.
The retail file will be different and downloadable only @ kagi store.
I guess nobody (or very few) will try to crack the mxf file becouse the retail price will be so low that it would be unlikely worth the time and talking of complicated patch, I can assure you that my app is an hell :P
My only concern is that I'll se the retail program on a p2p in a few weeks.
Have you considered going for a donation-ware or unprotected shareware
policy instead? Might build you a broader user base, and even if only
some of the users donate/pay, that might still end up providing you more
income. Just a thought.
Unfortunately donationware policy has been a total disaster.
On June 2005 my app: gleetchlab,
was online with a donation option of 9 euros.
In one year, gleetchlab has made more than 10.000 downloads from 40 countryes, thousands users that use it and just 44 donations (I was asking 9 euros, not 90 nor 900, just little more than 11 US$)
After that I have to pay site bandwidth (1000 visitors per week)
my Laptop is almost broken and I have payed also max msp upgrades.
Donationware from now on, for me is a no no no..
and believe me this is so sad for me, for I believed in donationware so much, but let's say the truth.. people just don't care they just take and unless you force them, you don't get nothing back..
I don't want to sound pessimimstic, but maybe you'll get as much
money as a non donationware ? It'll be even worse, since you'll have
only 44 people who use your software. Isn't nice to know that some
people liked your software, but just don't use it enough to consider
buying it, for exemple ? In other words, I don't think selling patch
is the right way to make money.
For a long time I've been struggling with a simple way to obtain
computers serial number, in order to get a way to create simple
challenge response copy protection scheme for max applications - not
that I ever really needed it, but it's been in my head for quite a
This question has been raised several times on the forums and I don't
remember it was answered before.
Using shell object, you can read machine serial using "System
Profiler" command. There is all other interesting system info
contained in there.
On 11-mai-06, at 10:10, Giorgio Sancristoforo wrote:
> can you explain me better the MAC address thing?
every (recent) computer includes an ethernet interface, and a unique
ethernet ID coupled to it. You could make your app check wether the
ethernet address of the host is the right one. But this implies that
you need to know the ethernet address of the machine you will
authorize, with some kind of question/response procedure!
I used this technique once for a software I sold to 2 people (the
software was very specialized, and rather expensive :-), so if you need
some C code example, I can send it to you and let you make your own Max
external, for OSX. But it may be as easy in Java.
> every (recent) computer includes an ethernet interface, and a
> unique ethernet ID coupled to it. You could make your app check
> wether the ethernet address of the host is the right one.
While it's true that every ethernet device has a unique MAC address,
it's not true that every computer has a unique ethernet device. (I
have a Linux box here with three ethernet ports.) Leaving aside the
fact that this technique will lock the software to the ethernet card
rather than the computer, it's not clear to me that "the" MAC address
will always be the same, even if the hardware doesn't change.
(I notice that Airport on my TiBook has a 48-bit ID - wifi carries
TCP/IP traffic, but I'm not sure whether this qualifies as
"ethernet", and whether this number qualifies as a MAC address. If
so, I have two MAC addresses here; more if I connect networking
hardware over Firewire or PCMCIA...)
nick rothwell -- composition, systems, performance -- http://
Please don't use MAC-based copy protection. If an app is Apple-only,
you can simply use the serial number of the computer. MAC addresses
can be cloned, forged, changed dynamically, etc. -- and (far worse),
it is apparently very difficult to make a MAC-based machine
identification that actually works on machines with multiple network
interfaces. (This is the case because network interfaces aren't
permanent, and you have no guarantee which one will be identified as
"the first" by the OS.)
I once bought some commercial Linux software that I could not
authorize because it was confused by the two ethernet cards in my
main Linux machine. Consider that any powerbook with AirPort has at
least two MAC addresses, and think of your user base.
By the way, please contact me (off- or on- list) with instructions on
how to donate towards the next version of gleetchlab development.