Thanks to everyone for the thoughts on this. I agree that you can never 100% prevent piracy from those who are determined enough and can waste a lot of time and effort trying to do so. I guess that's a plus for Zygodact - I buy the product, spend perhaps a couple of hours doing whatever customisation I think I need, and I'm done.
The target audience for the product I'm working on ( a Livecode/SQL database application development tool) is almost exclusively Livecode developers, not the end users of the applications they develop. I think developers, in general, are a pretty honest bunch so I'm not overly concerned about licensing/piracy but seems like there needs to be something in place, if only as a reminder that their demo period is about to expire and it's time to pay if they like what they've seen (that's certainly prodded me into payment in the past). I'm also reminded of the recent discussion on the use of password protected stacks. I'm tempted to go that route, not for reasons of piracy protection, but mainly because I could see huge support problems for me if people change my code for some reason then find that they've broken it. On the other hand, they could improve it :-) Pete Molly's Revenge <http://www.mollysrevenge.com> On Mon, Jul 18, 2011 at 8:40 AM, J. Landman Gay <jac...@hyperactivesw.com>wrote: > On 7/18/11 2:43 AM, Tiemo Hollmann TB wrote: > > As I understand Zygodact, or Peters or Shaos approach the user can pass on >> his "name, etc." and the generated code to everyone else to unlock the >> software. >> How do you handle this issue? Is it just something "as is", is this >> scenario >> so negligible in your customer base that you just can ignore it, or do you >> count on the good in the people that they won't do it? >> Would be of interest on how you handle this. >> > > I agree with everyone who said there is a limit to how much effort you > should put into piracy protection. However, Zygodact includes a CGI script > that can generate serial keys from the server. The script can be altered to > check a database on the server. If there are too many registrations for a > particular name and serial key, the script could return a message to the app > that the user needs to contact you, or do something else to notify you. > > This technique isn't perfect either, because it requires that the end user > has internet access when registering (or at some point anyway) and some > users get very upset when an app "calls home". So again, the trade-off is > something to consider. If the app is one that works only with the internet, > then it's probably okay because access will be expected. But if the app is a > self-contained game, for example, users may lose trust, and sometimes they > broadcast that in comments or ratings. > > -- > Jacqueline Landman Gay | jac...@hyperactivesw.com > HyperActive Software | http://www.hyperactivesw.com > > ______________________________**_________________ > > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/**mailman/listinfo/use-livecode<http://lists.runrev.com/mailman/listinfo/use-livecode> > > _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
