Mike Wagman wrote:
On a somewhat related question. I believe it is possible to password
oock zips. Can that be implemented into the py2exe so that unzip
software will not unpack a py2exe final file.
While your plan is cunning, it has a very big problem in that the
resulting app has to get those bytecodes back again, which means it
has to store the password somewhere.
Zip passwords are also not very secure. Try Googling for "crack zip
password" and you get 2300 matches.
In reality, if your business model depends on keeping secrets and your
product is any good, then someone somewhere will crack it. Once they
have cracked it, they can distribute the crack to all and sundry.
A better plan is to put in mild obfuscation mechanisms so that it isn't
trivial, and concentrate on other things that are of real value to
your customers such as good support, new versions etc. They will
then be happy to give you money even if there are cracked versions
or other "secret" information out there.
Roger
In reality, if your business model depends on keeping secrets and your
product is any good, then someone somewhere will crack it. Once they
have cracked it, they can distribute the crack to all and sundry.
That's a roger, Roger. 
Consider how easy it is to find cracks of programs like Photoshop, compiled
programs with nothing but binaries in distribution; if these programs are
being cracked, there is exactly a 0.00% chance that a Python program won't
be cracked if it is considered by the cracker to be worthwhile to do so.
The casual user won't want to or be able to crack it, but someone with the
will and the wherewithal will. Just consider this and be willing to take a
few hits. It will happen anyway until DRM is required for all program
execution, and even then I suspect someone will find a workaround.
Make the program worth paying for and people will pay for it. Don't kill
yourself on cutesy protection schemes. Make it simple and straightforward
but don't spend 50% of your development time on something that is doomed to
fail anyway.
One very easy way of checking on use is to have them "register" on a webpage.
Pretty easy to put in and, although still not that hard to crack, a better
way than having to deal with license keys etc. You'd have to disclose that
the program is trying to reach a website (I think otherwise it's illegal in
the US).
As others suggested - if the program is any good customers will be happy to
pay a decent price for support and updates. If MS had decent software they
wouldn't have to go after all the illegal copies that much. The way it is
now, commercial customers just pay the license not because they're convinced
the product is good, but merely to avoid legal repressions.
My customers get all the software in source under a non-disclosure agreement -
not because I think that they will ever take a look at it, but more because
it's a real good selling point for smaller companies - whenever we go away
they still have the source and just need a programmer to get it going again.
This is Return of Investment - one of the best selling arguments ever.
ยทยทยท
On Sunday 21 September 2003 05:21 pm, Jeff Grimmett wrote:
> In reality, if your business model depends on keeping secrets and your
> product is any good, then someone somewhere will crack it. Once they
> have cracked it, they can distribute the crack to all and sundry.
That's a roger, Roger.
Consider how easy it is to find cracks of programs like Photoshop, compiled
programs with nothing but binaries in distribution; if these programs are
being cracked, there is exactly a 0.00% chance that a Python program won't
be cracked if it is considered by the cracker to be worthwhile to do so.
The casual user won't want to or be able to crack it, but someone with the
will and the wherewithal will. Just consider this and be willing to take a
few hits. It will happen anyway until DRM is required for all program
execution, and even then I suspect someone will find a workaround.
Make the program worth paying for and people will pay for it. Don't kill
yourself on cutesy protection schemes. Make it simple and straightforward
but don't spend 50% of your development time on something that is doomed to
fail anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwindows.org
For additional commands, e-mail: wxPython-users-help@lists.wxwindows.org
--
UC
--
Open Source Solutions 4U, LLC 2570 Fleetwood Drive
Phone: +1 650 872 2425 San Bruno, CA 94066
Cell: +1 650 302 2405 United States
Fax: +1 650 872 2417