gangesmaster <[EMAIL PROTECTED]> wrote: ... > but anyway, it's stupid. why be a dick? those who *really* want to get > to the source will be able to, no matter what you use. after all, the > code is executing on their CPU, and if the CPU can execute it, so > can really enthused men. and those who don't want to use your product, > don't care anyway if you provide the source or not. so share.
Alternatively, if you have secrets that are REALLY worth protecting, keep a tiny part of your app, embedding all worthwhile secrets, on YOUR well-secured server -- expose it as a webservice, or whatever, so the "fat client" (most of the app) can get at it. This truly gives you complete control: you don't care any more if anybody decompiles the part you distribute (which may be 90% or 99% of the app), indeed you can publish the webservice's specs or some API to encourage more and more people to write to it, and make your money by whatever business model you prefer (subscription, one-off sale, pay-per-use, your choice!). If you keep your client thin rather than fat, the advantages increase (your app can be used much more widely, etc), but you may need substantial amounts of servers and other resources to support widespread use. When I started proposing this approach, years and years ago, the fact that your app can work only when connected to the net might be considered a real problem for many cases: but today, connectivity is SO pervasive, that all sort of apps require such connectivity anyway -- e.g, look at Google Earth for a "fat client", Google Maps for a "thin" one accessing a subset of roughly the same data but running (the client side) inside a browser (with more limited functionality, to be sure). Alex -- http://mail.python.org/mailman/listinfo/python-list
