I am developing a piece of software in Python that will be distributed to my employer's customers. My employer wants to limit the usage of the software with a time restricted license file.

If we distribute the .py files or even .pyc files it will be easy to (decompile and) remove the code that checks the license file.

Another aspect is that my employer does not want the code to be read by our customers, fearing that the code may be stolen or at least the "novel ideas".

Is there a good way to handle this problem? Preferably with an off-the-shelf solution.

The software will run on Linux systems (so I don't think py2exe will do the trick).

share|improve this question
py2exe just stores the .pyc byte code files in a .zip archive, so this is definitely not a solution. Still, that can be useful when combined with a suitable starup script to make it run unter Linux – Ber Nov 4 '08 at 12:35
like this: stackoverflow.com/questions/15955948/… – Dog Apr 25 '13 at 23:43

23 Answers 23

up vote 273 down vote accepted

Python, being a byte-code-compiled interpreted language, is very difficult to lock down. Even if you use a exe-packager like py2exe, the layout of the executable is well-known, and the Python byte-codes are well understood.

Usually in cases like this, you have to make a tradeoff. How important is it really to protect the code? Are there real secrets in there (such as a key for symmetric encryption of bank transfers), or are you just being paranoid? Choose the language that lets you develop the best product quickest, and be realistic about how valuable your novel ideas are.

If you decide you really need to enforce the license check securely, write it as a small C extension so that the license check code can be extra-hard (but not impossible!) to reverse engineer, and leave the bulk of your code in Python.

share|improve this answer
Even if the license-checking code were hard to reverse engineer because it's written in C, wouldn't it still be relatively easy to remove the calls to the license-checking code? – Blair Conrad Nov 4 '08 at 12:04
Yes it would, depending on where the license check is performed. If there are many calls to the extension, it could be difficult to eradicate. Or you can move some other crucial part of the application into the license check as well so that removing the call to the extension cripples the app. – Ned Batchelder Nov 4 '08 at 12:10
Really, all of this work is not about preventing modification, but about increasing its difficulty so that it's no longer worth it. Anything can be reverse-engineered and modified if there's enough benefit. – Ned Batchelder Nov 4 '08 at 12:11
@Blair Conrad: Not if the license-checking code hides functionality, too. E.g. mylicensedfunction(licenseblob liblob, int foo, int bar, std::string bash) – Brian Aug 9 '10 at 14:26
I think the clever way is implementing critical parts in C and implement all license checking stuff in there. (I use hardware dongle which can implement some calculation inside it. So it's almost impossible to reverse it back.) – Dasun Oct 17 '11 at 9:22

"Is there a good way to handle this problem?" No. Nothing can be protected against reverse engineering. Even the firmware on DVD machines has been reverse engineered and AACS Encryption key exposed. And that's in spite of the DMCA making that a criminal offense.

Since no technical method can stop your customers from reading your code, you have to apply ordinary commercial methods.

  1. Licenses. Contracts. Terms and Conditions. This still works even when people can read the code. Note that some of your Python-based components may require that you pay fees before you sell software using those components. Also, some open-source licenses prohibit you from concealing the source or origins of that component.

  2. Offer significant value. If your stuff is so good -- at a price that is hard to refuse -- there's no incentive to waste time and money reverse engineering anything. Reverse engineering is expensive. Make your product slightly less expensive.

  3. Offer upgrades and enhancements that make any reverse engineering a bad idea. When the next release breaks their reverse engineering, there's no point. This can be carried to absurd extremes, but you should offer new features that make the next release more valuable than reverse engineering.

  4. Offer customization at rates so attractive that they'd rather pay you do build and support the enhancements.

  5. Use a license key which expires. This is cruel, and will give you a bad reputation, but it certainly makes your software stop working.

  6. Offer it as a web service. SaaS involves no downloads to customers.

share|improve this answer
Point 2 is even more important. If it's cheaper buy than reverse engineering, plus yearly updates, no one will try and even if it does, no one will pay a hacker instead the provider of the software. – erm3nda Sep 1 '15 at 20:42

Python is not the tool you need

You must use the right tool to do the right thing, and Python was not designed to be obfuscated. It's the contrary; everything is open or easy to reveal or modify in Python because that's the language's philosophy.

If you want something you can't see through, look for another tool. This is not a bad thing, it is important that several different tools exist for different usages.

Obfuscation is really hard

Even compiled programs can be reverse-engineered so don't think that you can fully protect any code. You can analyze obfuscated PHP, break the flash encryption key, etc. Newer versions of Windows are cracked every time.

Having a legal requirement is a good way to go

You cannot prevent somebody from misusing your code, but you can easily discover if someone does. Therefore, it's just a casual legal issue.

Code protection is overrated

Nowadays, business models tend to go for selling services instead of products. You cannot copy a service, pirate nor steal it. Maybe it's time to consider to go with the flow...

share|improve this answer
Python is not the tool you need. Malbolge is. :) – johndodo Aug 4 '11 at 14:00
How does one "easily discover" if someone misuses my code? – Macke Sep 8 '11 at 10:49
Good answer, but "casual legal issue"? Really? Where do you live that you have any legal issues that are casual? – mehaase Sep 16 '13 at 13:40
So what programming language? – loops Jan 16 '14 at 17:10
That's another question. – e-satis Jan 17 '14 at 13:39

Compile python and distribute binaries!

Sensible idea:

Use Cython (or something similar) to compile python to C code, then distribute your app as python binary libraries (pyd) instead.

That way, no Python (byte) code is left and you've done any reasonable amount of obscurification anyone (i.e. your employer) could expect from regular Code, I think. (.NET or Java less safe than this case, as that bytecode is not obfuscated and can relatively easily be decompiled into reasonable source.)

Cython is getting more and more compatible with CPython, so I think it should work. (I'm actually considering this for our product.. We're already building some thirdparty libs as pyd/dlls, so shipping our own python code as binaries is not a overly big step for us.)

See This Blog Post (not by me) for a tutorial on how to do it. (thx @hithwen)

Crazy idea:

You could probably get Cython to store the C-files separately for each module, then just concatenate them all and build them with heavy inlining. That way, your Python module is pretty monolithic and difficult to chip at with common tools.

Beyond crazy:

You might be able to build a single executable if you can link to (and optimize with) the python runtime and all libraries (dlls) statically. That way, it'd sure be difficult to intercept calls to/from python and whatever framework libraries you use. This cannot be done if you're using LGPL code though.

share|improve this answer
There is a tutorial in how to do it here :) – hithwen May 13 '14 at 14:28
@Macke, consider citing nuitka – gg349 Dec 11 '14 at 17:24
Would compiling with cython work with a python 3.4 Django app, or could it be made to work without a huge amount of effort? – Daniel Sep 15 '15 at 4:35
@mlvljr FWIW, IMHO compiling to binaries is a nice tradeoff between selling all your secrets and trying to protect against NSA-class reverse engineering. Esp if you have a big python code base and reasons to be paranoid. ;) – Macke Jan 8 at 8:18

I understand that you want your customers to use the power of python but do not want expose the source code.

Here are my suggestions:

(a) Write the critical pieces of the code as C or C++ libraries and then use SIP or swig to expose the C/C++ APIs to Python namespace.

(b) Use cython instead of Python

(c) In both (a) and (b), it should be possible to distribute the libraries as licensed binary with a Python interface.

share|improve this answer
Other possibilities in the same vein: Shed Skin code.google.com/p/shedskin and Nuitka kayhayen24x7.homelinux.org/blog/nuitka-a-python-compiler – TryPyPy Jan 14 '11 at 4:03
I just gave a look on Shed Skin as suggested by TyPyPy and it appears to be really good stuff! – Filipe Jan 29 '13 at 11:47

Is your employer aware that he can "steal" back any ideas that other people get from your code? I mean, if they can read your work, so can you theirs. Maybe looking at how you can benefit from the situation would yield a better return of your investment than fearing how much you could lose.

[EDIT] Answer to Nick's comment:

Nothing gained and nothing lost. The customer has what he wants (and paid for it since he did the change himself). Since he doesn't release the change, it's as if it didn't happen for everyone else.

Now if the customer sells the software, they have to change the copyright notice (which is illegal, so you can sue and will win -> simple case).

If they don't change the copyright notice, the 2nd level customers will notice that the software comes from you original and wonder what is going on. Chances are that they will contact you and so you will learn about the reselling of your work.

Again we have two cases: The original customer sold only a few copies. That means they didn't make much money anyway, so why bother. Or they sold in volume. That means better chances for you to learn about what they do and do something about it.

But in the end, most companies try to comply to the law (once their reputation is ruined, it's much harder to do business). So they will not steal your work but work with you to improve it. So if you include the source (with a license that protects you from simple reselling), chances are that they will simply push back changes they made since that will make sure the change is in the next version and they don't have to maintain it. That's win-win: You get changes and they can make the change themselves if they really, desperately need it even if you're unwilling to include it in the official release.

share|improve this answer
What if they release software to customers, and the customer modifies it internally without re-releasing it? – Nick T Aug 9 '10 at 13:36
@Nick: Doesn't change the situation in any way. See my edits. – Aaron Digulla Aug 9 '10 at 14:14
+1 for stealing ideas back. Why limit your client-serving power to your in-house solutions, when you could see how others improve on your solution and accordingly improve your own product? "If you have an apple and I have an apple and we exchange these apples then you and I will still each have one apple. But if you have an idea and I have an idea and we exchange these ideas, then each of us will have two ideas." – Jordan Apr 30 '13 at 5:04

Do not rely on obfuscation. As You have correctly concluded, it offers very limited protection. UPDATE: Here is a link to paper which reverse engineered obfuscated python code in Dropbox. The approach - opcode remapping is a good barrier, but clearly it can be defeated.

Instead, as many posters have mentioned make it:

  • Not worth reverse engineering time (Your software is so good, it makes sense to pay)
  • Make them sign a contract and do a license audit if feasible.

Alternatively, as the kick-ass Python IDE WingIDE does: Give away the code. That's right, give the code away and have people come back for upgrades and support.

share|improve this answer
Like this extreme idea. Gets it out there in a huge way and massive market share, then you have a very big customer base for support and addons. I have also been grappling with this question and all the "licensing" answers are basically bull because it doesn't protect against widespread copying, yet doesn't give you any market share advantage. – Thomas Browne Apr 16 '13 at 14:43

In some circumstances, it may be possible to move (all, or at least a key part) of the software into a web service that your organization hosts.

That way, the license checks can be performed in the safety of your own server room.

share|improve this answer
+1 (back to 0): it seems the only true solution to the problem, assuming such an approach to be practical for the setting. – intuited Jul 21 '10 at 17:41
Beaware that if your licensing webserver goes down or the customers internet access is down your customer will not be happy that they can't run thier business because of loss of access to licensing checks. – DevPlayer Jul 3 '12 at 16:45
@DevPlayer There are solutions to this. You could implement a local key mechanism that allows temporary access when the software cannot reach the remote licensing server. – Jeffrey Mar 2 '14 at 17:49
@Jeffrey: That gets you right back to where you started - how to you protect that code. To be safer, you need to put some of the key functionality on your own server, so replacing it would involve substantially effort (at which point, why not just start an open-source competitor?) – Oddthinking Apr 10 '15 at 14:31

Though there's no perfect solution, the following can be done:

  1. Move some critical piece of startup code into a native library.
  2. Enforce the license check in the native library.

If the call to the native code were to be removed, the program wouldn't start anyway. If it's not removed then the license will be enforced.

Though this is not a cross-platform or a pure-Python solution, it will work.

share|improve this answer
The native library approach makes it much easier for someone to programmatically brute force your license key system as they can use your own code and API to validate their licenses. – Tom Leys Nov 24 '08 at 1:15
So? Use RSA to sign your licence and let them brute force your private key, say consisting of 1024 bits. It is possible, but takes a lot of time... and thus - money. – Abgan Dec 29 '08 at 2:18

Shipping .pyc files has its problems - they are not compatible with any other python version than the python version they were created with, which means you must know which python version is running on the systems the product will run on. That's a very limiting factor.

share|improve this answer

Depending in who the client is, a simple protection mechanism, combined with a sensible license agreement will be far more effective than any complex licensing/encryption/obfuscation system.

The best solution would be selling the code as a service, say by hosting the service, or offering support - although that isn't always practical.

Shipping the code as .pyc files will prevent your protection being foiled by a few #s, but it's hardly effective anti-piracy protection (as if there is such a technology), and at the end of the day, it shouldn't achieve anything that a decent license agreement with the company will.

Concentrate on making your code as nice to use as possible - having happy customers will make your company far more money than preventing some theoretical piracy..

share|improve this answer

Another attempt to make your code harder to steal is to use jython and then use java obfuscator.

This should work pretty well as jythonc translate python code to java and then java is compiled to bytecode. So ounce you obfuscate the classes it will be really hard to understand what is going on after decompilation, not to mention recovering the actual code.

The only problem with jython is that you can't use python modules written in c.

share|improve this answer

I think there is one more method to protect your Python code; part of the Obfuscation method. I beleive there was a game like Mount and Blade or something that changed and recompiled their own python interpreter (the original interpreter which i believe is open source) and just changed the OP codes in the OP code table to be different then the standard python OP codes.

So the python source is unmodified but the file extentions of the pyc files are different and the op codes don't match to the public python.exe interpreter. If you checked the games data files all the data was in Python source format.

All sorts of nasty tricks can be done to mess with amature hackers this way. Stopping a bunch of noob hackers is easy. It's the pro hackers that you will not likely beat. But most companies don't keep pro hackers on staff long I imagine (likely because things get hacked). But amature hackers are all over the place (read as curious IT staff).

You could for example, in a modified interpreter, allow it to check for certain comments or docstrings in your source. You could have special OP codes for such lines of code. For example:

OP 234 is for source line "# Copyright I wrote this" or compile that line into op codes that are equivelent to "if False:" if "# Copyright" is missing. Basically disabling a whole block of code for what appears to be some obsure reason.

One use case where recompiling a modified interpreter may be feasable is where you didn't write the app, the app is big, but you are paid to protect it, such as when you're a dedicated server admin for a financial app.

I find it a little contradictory to leave the source or opcodes open for eyeballs, but use SSL for network traffic. SSL is not 100% safe either. But it's used to stop MOST eyes from reading it. A wee bit precaution is sensible.

Also, if enough people deem that Python source and opcodes are too visible, it's likely someone will eventually develope at least a simple protection tool for it. So the more people asking "how to protect Python app" only promotes that development.

share|improve this answer

What about signing your code with standard encryption schemes by hashing and signing important files and checking it with public key methods?

In this way you can issue license file with a public key for each customer.

Additional you can use an python obfuscator like this one (just googled it).

share|improve this answer
+1 For the signing; -1 for the obfuscator You can at least prevent the code from being changed. – Ali Afshar Nov 4 '08 at 13:07
Signing does not work in this context. It's always possible to bypass the signature-checking loader. The first thing you need for useful software protection is an opaque bootstrap mechanism. Not something that Python makes easy. – ddaa Nov 4 '08 at 13:41
Yes, bootstrap in non-python. – Ali Afshar Nov 4 '08 at 16:27
Or validate the licence not only on startup but in several other places. Can be easily implemented, and can severely increase the time to bypass. – Abgan Dec 29 '08 at 2:21

The reliable only way to protect code is to run it on a server you control and provide your clients with a client which interfaces with that server.

share|improve this answer

Have you had a look at pyminifier? It does Minify, obfuscate, and compress Python code. The example code looks pretty nasty for casual reverse engineering.

$ pyminifier --nonlatin --replacement-length=50 /tmp/tumult.py
#!/usr/bin/env python3
 import demiurgic
except ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲמּ:
 ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ燱("Warning: You're not demiurgic. Actually, I think that's normal.")
 import mystificate
except ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲמּ:
 ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ燱("Warning: Dark voodoo may be unreliable.")
class ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ𐦚(ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ澨):
 def __init__(self,*args,**kwargs):
 def ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ클(self,dactyl):
  return ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ𠛲
 def ﺭ异𞸐𐤔ﭞﰣﺁں𝕌𨿩𞸇뻛𐬑𥰫嬭ﱌ𢽁𐡆𧪮Ꝫﴹ뙫𢤴퉊ﳦﲣפּܟﺶ𐐤ﶨࠔ𐰷𢡶𧐎𐭈𞸏𢢘𦘼ﶻ𩏃𦽨𞺎𠛘𐠲䉊ﰸﭳᣲ𐠯(self,whatever):
if __name__=="__main__":
# Created by pyminifier (https://github.com/liftoff/pyminifier)
share|improve this answer
当前网页内容, 由 大妈 ZoomQuiet 使用工具: ScrapBook :: Firefox Extension 人工从互联网中收集并分享;
若有不妥, 欢迎评注提醒:


订阅 substack 体验古早写作:

点击注册~> 获得 100$ 体验券: DigitalOcean Referral Badge

关注公众号, 持续获得相关各种嗯哼:


关于 ~ DebugUself with DAMA ;-)
公安备案号: 44049002000656 ...::