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.

p

thanks. It's an audio app by the way.

I thought that I could do the foolowing:

downlaodable demo: A) disable recording audio B) delete DAC~ object after 10 minutes of run

final product use kagi for hosting selling and everything...

what you think?

> ? disable recording audio One can always record the audio output in full original digital quality if he has a sound card allowing internal routing from outputs to inputs.

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.

thanks for the suggestions.

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.

can you explain me better the MAC address thing?

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.

Best, Trond

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.

Julien.

I don't think so... I am sure that sales will be much much more succesfull than donation, I can bet. 10.000 downloads can't be wrong...

i emailed this few weeks ago:

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 while.

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.

boo.mi2.hr/~klif/private/report_machine_serial.pat

klif

p.s. i don't know if you can use shell object in a commercial app.

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.

p

On 11 May 2006, at 23:23, Patrick Delges wrote:

> 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...)

-- N.

nick rothwell -- composition, systems, performance -- http:// www.cassiel.com

By unique, I mean that no other device in the whole world should share the same ID. But indeed, there may be more different MAC addresses on one computer.

p

Giorgio (et al.),

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.

best, wb