OI 10 marked the introduction of a new licensing method, replacing the old `oengine.dll` stamping. Historically, the licensing information was baked into `oengine.dll`. If you wanted to “change” the characteristics of your OI system you could just drop in a different `oengine.dll` and, effectively, you had a new system.

OI 10 introduces a separate licence metadata file called `revengine.lic`. It’s a simple XML file that looks like this (with some minor obfuscation):

<OI>
    <Signature>PEe80-Uf189-5mg27-m1t80-00m4Q-9hih7</Signature>
    <SerialNumber>W10280784</SerialNumber>
    <NumUsers>10</NumUsers>
    <ExpirationDate>2025-05-21</ExpirationDate>
    <ExpirationType>0</ExpirationType>
</OI>

The `Signature` element is the important part. It’s a cryptographic signature over the real licence attributes – serial number, user count, expiry date and type – generated with a secret key that only Revelation knows. OI trusts *that* value and treats the rest of the XML purely as metadata for human consumption. You can edit `SerialNumber`, `NumUsers`, `ExpirationDate` and `ExpirationType` to your heart’s content; it doesn’t change the way OI behaves because those fields are not trusted.

At this point you might think: “Fine, I’ll just copy the `.lic` file instead of the `.dll`.”

But there’s a catch.

OI 10 also moves to industry-standard security. Various user rows in the system are now encrypted using a key derived from (and salted with) the Signature. Change the Signature and you change the encryption seed. Anything that was encrypted under the old Signature will no longer decrypt under the new one and, if you’re using the default security policy, you will lock yourself out of the system.

So yes, `revengine.lic` is technically portable – but once you’ve started using the system in anger, all of your sensitive user data is cryptographically tied to that specific licence Signature. Swapping licences is no longer a harmless way to “refresh” a system; it has real consequences for your encrypted data.