The Client
A mid-sized, independent software vendor (ISV) specializing in a high-performance 3D modeling and rendering suite. Their application is written in C++, with builds for Windows, macOS, and Linux. Their primary customers range from individual freelance artists to small animation studios.
The Problem: A Leaky-Bucket Revenue Model
The ISV faced a multi-faceted piracy and licensing problem that was severely impacting their revenue and growth:
- Rampant Piracy: Days after each new release, patched versions of their Windows executable would appear on torrent sites. Their static license check was easily bypassed.
- License Key Sharing: Small studios would buy a single license and use it across dozens of machines, violating the EULA. Their existing system had no way to enforce a "per-seat" limit.
- Inability to Scale: Large enterprise clients wanted to purchase "floating" licenses (e.g., 20 seats for a 100-person team), but the ISV's simple key system couldn't manage this. This entire high-value market segment was inaccessible to them.
- Engineering Drain: Their internal developers were spending weeks on each release cycle trying to build and update their own licensing code, pulling them away from working on core product features.
The Search for a Solution
The ISV's engineering lead knew they needed an external solution. Their requirements were strict:
- It had to be **cross-platform**, with a native C/C++ library.
- It had to be **lightweight** and not impact the performance of their rendering engine.
- It had to be **fast to integrate**—they couldn't afford another multi-week engineering project.
- It had to solve **both piracy and enterprise licensing** (node-locked and floating).
After evaluating several competitors, they found that most solutions were either Windows-only, prohibitively expensive, or required complex SDK integrations. They discovered FLS Fortress and were intrigued by the "one-line-of-code" promise and the *active* protection model.
The FLS Fortress Implementation
The ISV signed up for a "Professional" plan on FLS Fortress. The total integration time was **under one hour**.
"The integration was exactly as advertised. We downloaded the header and static library for each platform, added the library to our build system, and put `FLS_Initialize()` in our `main()` function. That was it. We were protected." — Lead Developer, Anonymous ISV
From their new Mission Control dashboard, they created two primary license policies:
- "Freelancer Pro (Node-Locked)": A `software_node_locked` policy with `floating_limit = 1`.
- "Studio Pack (Floating)": A `software_floating` policy with `floating_limit = 10`.
For both, they enabled the `Lock Application` tamper policy.
The Results: A Complete Business Transformation
The impact was immediate and profound:
- Piracy Neutralized: The first patched executables that appeared online were useless. As soon as a user ran the cracked .exe, the FLS Fortress library detected the tampered code integrity, executed the "Lock Application" policy, and instantly terminated the program.
- New Enterprise Revenue: The ISV was able to immediately begin selling their new "Studio Pack" floating licenses, opening up the high-value enterprise market they couldn't serve before.
- End to License Sharing: The "Freelancer Pro" keys were now truly locked to a single machine's hardware hash, ending casual license sharing.
- Actionable Intelligence: For the first time, the ISV had a dashboard showing *where* their licenses were being activated and *which* keys were being used, giving them real-world data on their customer base.
Conclusion
By switching from a failed static-check model to FLS Fortress's active protection, the client not only solved their piracy problem but fundamentally transformed their business. They plugged their "leaky bucket," reduced engineering overhead to zero, and created an entirely new, high-margin revenue stream in a single afternoon.