The GPL requires that it be the preferred version for editing. If you normally write in obfuscated code, and make changes directly in it, then that's the source for GPL. If you work on a readable version, and then run it through any sort of obfuscator, the readable version is what the GPL considers the source.
"Readability" is subjective and not defined. It is legal to release really bad, hard to understand, code under the GPL. It is not legal to take the version that you make changes in, remove the whitespace or otherwise make it less readable, and call that the source under the GPL.
Once your customer has a program they can run, they will be able to reverse engineer it given sufficient time & skill. That is just a fact of life.
If you really want to stop it, you should host and run the software yourself (SaaS)
Having said that, something like Python will be easier than C. Let's split this into the 3 parts you asked about (and then some more)
HTML
No matter what you do here, it will be decrypted in the browser (even in the SaaS model), so encrypting it on the server is pointless. Even minifying is pointless as modern browsers like Firefox and Chrome will neatly format it for them.
CSS
See above - don't waste your time
Javascript
Yahoo has a tool that can obfuscate it for you. Try YUI Compressor. Not, don't both encrypting this on the server-side as it must be served to the client unecrypted*, which would defeat the purpose.
Python
This is the only place you really want to spend your time - protecting your business logic. There are several methods you will find on google such as encrypting on disk and then decrypting at run-time. All these methods have problems, such as performance hits and having to supply the decrypter (hence enabling them to decrypt it anyone).
Your best beat to stop those not hellbent on stealing your code would be to use an obfuscate your Python code.
Summary
The only code you can stop someone from getting is the code you don't give them. HTML, CSS & Javascript will always end up on your users machine in a manner they can use, so assume they be able to steal it if they want, tough luck.
To protect your server code, the only sure-fire method is to NOT give it to them, running it in something like a SaaS model.
If that isn't possible, the best you can do is make it harder for them.
Testing
Always make sure you test on the production version you will be supplying your customers. This ensures any special build steps (such as obfuscation & minification) do not break your software.
Boring Business Stuff
So all of the above (and your question) has addressed this issue from the technical side. The other side of the coin is from the business/legal side.
If you have a small number of clients you can provide different "watermarked" versions of your software to each client. By doing this, you increase the possibility being able to track stolen software back to the source and take whatever legal action is appropriate.
Don't forgot, if you are in a serious business, you would be best to consult a lawyer on how you can prove and enforce the ownership of your software, should things go wrong.
* not strictly true, you could serve it encrypted and have other Javascript decrypt it on the fly, but this would be near pointless as it adds a performance hit and you will have to supply the attacker with the decrypter anyway...
Best Answer
This is called obfuscation.
What it does is that it performs a series of operations which don't affect the execution of the source code, but make it more difficult to read of a human.
For example, here are some commonly used obfuscation techniques:
Remove whitespace.
Remove comments.
Replace meaningful names of variables and members by names such as
a
,b
,c
.With only those three basic techniques, this code:
becomes:
Less frequently used obfuscation techniques include but not limited to:
Encryption of strings,
Inlining (i.e. moving the body of a method in the method which was calling the first one),
Control flow obfuscation,
Encryption of source code (the effectiveness of this technique is highly disputed, since if the machine running the application can decrypt the source code in order to run it, the user of this machine can do it as well).
Of course, you shouldn't do the obfuscation yourself, but rather search for a tool which makes this for the language of your choice.
Note that some tools don't have obfuscation as their primary goal, but still can be used for that. Google Closure Compiler, for example, is intended to (1) perform static checking of the code and to (2) reduce the size of JavaScript files, but has a side effect of making source code quite unreadable.