PACE iLok with HISE?

[optimistic]

I'm going to ask a potentially unpopular question here but has anyone ever tried / considered implementing iLok into a HISE project?

I know that HISE has it's own copy protection but from my perspective iLok helps overcome a few challenges currently with HISE ...

1. Demo Versions — Is there a good method for doing this currently in HISE? From my experience demos are extremely important for users and the conversion to sales is typically high.
2. Copy Protection — I realize HISE has its own copy protection system but this also requires speaking with an API which typically means web explaining this system to web specialists has proved to be challenging.

I would be interested to hear anyone else's thoughts around this topic.

I realize iLok has some downsides as well such as the licensing fee and technical implementation but my main concern is creating a good user experience with the end product.

[Christoph Hart]

@optimistic I think @Dan-Korneff is the only one that made plugins with HISE and iLok so far, so maybe he can explain the process.

As we've discussed, the most sensible approach to demo versions for me is that you offer a separate demo binary with limited functionality. If you ship the full version but just with a

if(isDemoVersion())
{
    hideFullVersionFeatures);
}

it will become the attack vector that will bring down your copy protection scheme since it's rather easy to read and modify the HiseScript code embedded in the binary.

Integrating the HISE copy protection on a server usually means adding an API point which connects to the user database and runs a script that generates the key file, which shouldn't be too hard for a web developer to implement, however I think this would be something where a template for the most popular web backend frameworks would jump start this task (I have no experience with any web frameworks whatsoever but maybe someone else here could chime in).

[optimistic]

@Christoph-Hart

I agree that you can't simply have a flag in the script to enable demo versions because doing so is indeed easy to crack.

I think the main question with that apporach is what do you and don't you leave in for users to demo the software? If things are too limited we often receive messages from users who (despite being clearly indicated) think these limitations are also a part of the full version.

Unfortunately I know very little about web technologies and many web developers know very little about software licensing integration.

So I think what is in HISE is doable but it also would require in our case some additional considerations and before implementing this I am curious to explore iLok a bit further.

But if that proves to not work out I will start going down the path you've outlined here to figure out a feature limited demo version and how to explain the API approach to a web development team.

@Dan-Korneff it would be great to hear your experience with integrating iLok. Did you have to write any C++ code for this or modify the HISE source in any way? Or was implementing it more like a code signing process?

[Dan Korneff]

I'm using iLok here with my HISE projects. The overall process has been frustrating at some points, but that went away once I got familiar with the process.
The nice part is the licenses are completely taken care of by iLok's license server. A single binary from HISE can be used for demo/subscription/perpetual, depending on the authorization code you give the customer. All of that stuff gets injected in HISE during compilation with their library called FUSION.
Pace is also now the owner of JUCE, so I wouldn't be surprised if there was a native integration with ilok in the future.
As with any protection system, it can be hacked. I've been having issues with that since last December. Once a hacker figures out how to bypass the iLok system, they have a blueprint for how it's implemented in many other iLok protected items. It's almost a copy/paste hack for them.... and then you have to find a new place to inject the protection for your next update. But they figure that out too. Not to mention the frequent iLok Cloud outages.
User experience is also a concern. A large majority of my support tickets are iLok based requests. It's confusing to most users, and there is a general animosity towards software that uses this protection in the consumer audio community.
With that being said, I'll be moving away from that system soon and implementing a licensing system that's integrated with Woocommerce. A few other users are already successfully using this system ( like @orange )

[optimistic]

@Dan-Korneff Thanks for the information!

I can totally understand why some users have a dislike to iLok. For our situation I do still feel like its ability to offer full featured time limited demos with (relatively) strong copy protection is a good trade off that would likely make more people happy than not.

We're quite a small development team and I'm also concerned about trying to build out copy protection on a web server and any eventual support from an external developer if there were issues.

I've reached out to PACE and have a meeting scheduled to get more information on how their system would be integrated.

If you could provide more information on the process I would specifically be interested in what you said here ...

All of that stuff gets injected in HISE during compilation with their library called FUSION.

Does this process happen to the binary that HISE creates after compilation or do you have to modify HISE in some way to support this during compilation? Really just trying to gauge how much work it will be to setup and if I would need to dig into any C++ to use this system.

I realize some of this may be under NDA and perhaps PACE can explain some of this too but if there is anything you can share the conversation may be of interest for others in the future researching the same topic too.

[optimistic]

I'm going to answer my own question for anyone looking this up in the future ...

• There are two options for iLok encryption. One requires wrapping a binary that HISE creates and the other requires injecting custom code in your project but is more secure.
• The first option should easily be compatible with HISE and the second one I'm not so sure about it.

Likely we will end up using the first option and it is positive to see it should be possible.