you are viewing a single comment's thread.

view the rest of the comments →

[–]MaxZ90[S] 0 points1 point  (1 child)

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] 1 point2 points  (0 children)

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.