I'll probably wait until I can get closer to the financials but at this point I imagine its mostly theoretical. I think its even mildly plausible that the crack

I'll probably wait until I can get closer to the financials but at this point I imagine its mostly theoretical. I think its even mildly plausible that the cracks are coming from sanctioned nations as this "luxury" product is quite key in certain industries. So I doubt we can defeat the l337est state backed h4xx0rs in a game of wits. As the package is delivered in completeness and runs entirely offline I believe there is no possibility in guaranteeing its protection. Ultimately you can load the app into memory, work out (slowly) what parts are performing checks and recompile the app while removing those parts. While I imagine initial users are paying, somehow the software is falling into the hands of those who wish to the crack it. So the process is just a factor of time. Without an architecture that puts the hard to reproduce part somewhere else that we can protect (e.g. a client-server architecture that is vital to the function of the app), there is no guarantee. From my perspective the only value beyond setting some arbitrary bar of difficulty (which we already have) is perhaps finding ways to fingerprint the software so we can narrow down the origin of the cracked edition (as its much harder for the attacker and beyond their interest to scrub non-functional breadcrumbs from the binary). We would then have an avenue to follow up with the official origin of the leak. You're right to bring up the trade-offs but given the money at play and the level of support we offer for the product it transitions quite well into a service as opposed to a product. There are obviously issues around such a switch but I believe it does fit into the business model. In terms of competition I am told that for the most part we are streets ahead and have little to worry about at the moment. > If the execs are desperate, the company is in trouble, and something needs to be done to save it, than maybe it is a good analogy, but the execs seem more scared of change than worried about cracks. Is that the right read? I don't think the execs are necessarily desperate, but I'd have to look at the financials to be certain of that. I believe that its just that they fear, and are looking to add value and have simply happened upon this as an obsession. The company is reasonably old with a consistent executive team for most of its life, so I just think they have that 80s/90s attitude to technology that hasn't been updated. I'm still trying to get a feel for the organization, but there appears to be a lack of structure which allows execs to effectively directly control the development department. I'm sure if I get a stronger handle on scheduling (which I expect to happen over time) then this issue is going to come up and we might clash over it, as I believe shipping the product (still with some level of copy-protection) is more important that over-fitting the copy-protection and slipping on the schedule. Their development practices themselves need some serious updating and it would be absurd to focus on adding more copy-protection when they don't even have proper continuous integration. There's lots to do. Their fear isn't entirely unwarranted, they do good work enforcing compliance with current customers and I agree that there's considerable value in chasing the clients with the money to rectify their non-compliance, and I imagine often such issues are accidental as opposed to intentional. There's a lot of money in this market and those benefitting from the software definitely have the ability to pay. However looking at those who are not paying and may never pay as lost revenue is a mistake imho that they're making, but its about how to frame that. I imagine someone has already made such an argument and was hoping to stumble across their resources. Thank you for the link and the idea of fear setting. Hopefully I will get the time to sit down and better understand their concerns, prior to framing a response.