If you sell a MATLAB toolbox, a Simulink library or a model-based product, the thing you are protecting is usually not code at all. It is the plant model, the controller gains, the calibration set or the coefficient tables — the part that took years of measurement to get right and that a competitor cannot reproduce from your documentation.
That makes MATLAB unusually well suited to doing licensing properly, because the valuable data is already separate from the code.
The binding
addpath('SDK/bindings/matlab');
d = keynub.Dongle();
if ~d.isGenuine, error('no genuine KeyNub found'); end
d.sessionOpen();
coefficients = d.appDecrypt(encryptedBlob);Code language: Matlab (matlab)Gate on the parameters, not on a flag
Encrypt the plant coefficients with appEncrypt when you build the product, ship them encrypted, and decrypt them at model initialisation. Remove the dongle and the model does not run in a degraded mode — it has no parameters to run with. The SDK includes a sample that does exactly this on real plant coefficients, and one that builds a dongle-gated Simulink model in code (so there is no binary .slx to version).
MATLAB Coder and Simulink Coder
This is where most licensing schemes fall over. Generated C does not run inside MATLAB, so a MEX-based binding cannot come along — and that generated C is often the thing you actually ship. The SDK includes a small shim that links the licence check into MATLAB Coder and Simulink Coder output, so the protection survives code generation instead of being left behind in the development environment.
Honest status
The MEX gateway is covered by the SDK’s automated test suite and the codegen shim is compiled on every build, but the MATLAB samples themselves have not been executed — there is no MATLAB installation on the machine the SDK is developed on. Treat your first run as bring-up, and tell us if anything is off; that is a bug report we will act on quickly.
