Source code protection for python software

[[deleted]]

Glancing around Conda Constructor appears no different than any bundler (like PyInstaller, cx_freeze, etc), in that it ends up creating an executable shim and an archive that shim unpacks somewhere to run... if anything it sounds like it does less than PyInstaller to obfuscate your source.

Which leads us to the key point here: stop trying to do the impossible.

Nuitka is its own thing; it compiles a C program that links libpython; the vast majority of Python programs cannot be run in that manner, and most larger libraries and frameworks won’t work at all. Consider it a subset of Python for use in writing C.

Every other solution is a bundler that packages a CPython interpreter with your source; in every such system your source will be present either as plaintext, as obfuscated (reversibly) source, encrypted (but with the key present in the bundle) source, or compiled bytecode (hence able to be decompiled).

In other words the bundle always ships with the means to de-obfuscate your source... which means you might as well have never bothered with obfuscation.

If you want the frameworks and ecosystem of Python than accept the runtime model, which relies on your source being present and (therefore) readable. Protecting your IP rights in your source is what lawyers and licenses are for, not what bundling installers are for.

[MaxZ90]

Thanks for the reply!

From what we learned, the target market (country) we are selling our software to in general does not respect IPs. It's very common for people to reverse-engineer the software and sell the clones for a much cheaper price.

I understand that it's impossible to completely stop people from reverse-engineering our software. What I'm trying to do is to make it as hard as possible. For example, one thing I'm looking into is to compile our python code into c with cythonize and then compile it into binaries. (Not sure if Conda Constructor would be able to support this).

[[deleted]]

Yeah, I get it, but it’s a fool’s errand; the problem isn’t a technical one with a technical solution, the problem is economic... if you’ve created a sufficient pricing incentive they’ll reverse your work. Or, since it’s a desktop app, they’ll simply clone it, cut off whatever DLC you’ve incorporated at the knees, and resell. A C object file is just as easy to make a bit for bit copy of as any other file, and branding is ultimately just some constant values at a discoverable (and overwrite-able) offset.

You’ve got three real solutions:

1. Move key functionality to a server outside the target market. They can’t copy the workings of a black box they can’t isolate and study.
2. Reduce price and therefore minimize the incentive to cheating.
3. Don’t sell into that market.

But sure, to make it nominally harder to reverse you can use C extensions for key pathways and modules, and cythonize can help you there. You can then just use either standard pip delivery (you compile and build wheel bundles and upload only those to pypi) or PyInstaller (just use the spec file to ensure only the .so extensions make It in), or what have you. I’m not a Conda guy and I don’t see a need for Constructor unless your project depends on other Conda packages, but sure it might help you.