Plugins/Companies using serial, a keyfile, or watermark copy protection

[sprnva]

Think they changed that a long time ago, around 2017 IIRC, however at that time I only owned SquashIt so not sure if it was the same for all other products... (Rent to own on Splice is another story)

You're right. I just checked the previous release of Korvpressor and could activate it offline with the serial. Weird. I'm sure I tried this at some stage in the past and concluded that they needed an internet connection to activate.

[audiojunkie]

I have new concerns. I had this back and forth with AI about TAL-Software that hasn’t been adding up to me:

Here is a blurb from the TAL-Software FAQ on their web site, about their copy protection:

How does our registration process work?
The plug-in will ask for your license key when you open the user interface. Registration and use of the plug-ins are possible even if the TAL server is unavailable or you are offline.

From time to time the plug-ins connect to the server to verify the license and register the device, if necessary. If the server cannot be reached, nothing happens. This means you can continue using the plug-ins even in the future, whether or not the TAL server still exists.

The license can be registered on up to four different computers. You can remove registered computers at any time by logging into your account.

From that information, it sounds to me like the unique computer identifier is being used to tell TAL-Software what computers are using the license. Does this sound correct to you?

Yes—that’s a reasonable interpretation, and it lines up with how most software licensing systems work.

What they’re describing implies a few things:

* Each time you activate the plugin on a machine, it likely generates or reads a unique device identifier (often derived from hardware + OS info, sometimes hashed).
* That identifier gets associated with your license on their server, which is how they enforce the “up to four computers” limit.
* When the plugin “from time to time” contacts the server, it’s probably checking:
* whether the license key is valid
* whether this device is already registered
* whether the device count exceeds the allowed limit

The important nuance is in their offline statement: if the server isn’t reachable, the plugin keeps working. That suggests the local machine stores some kind of cached authorization token after initial activation, rather than requiring constant validation.

So in short:
Yes—the system almost certainly uses a per-computer identifier to track which machines are tied to a given license, but it’s not doing continuous enforcement in real time. It’s more of a periodic sync with a local fallback.


So, if TAL-Software were to go out of business, it appears likely that you may be able to authenticate just that particular licensed machine.

It does not, however, appear that the user could authenticate a new machine (which has its own unique identifier), without requiring the use of the server.

I wish developers could be more open about this stuff! Half truths do not help their reputations! They are more concerned with stopping pirates than with being open with the prospective purchasers (the honest).

I think it really all comes down to the “gold standard”—can a user purchase and archive the software and the license object (serial, keyfile, whatever), and at a later date, after the company and their servers no longer exist, install the software to a completely different computer, with a completely different unique ID, and register it to run.

In this case, I have my doubts that TAL-Software would meet the criteria—despite carefully worded attempts to persuade us otherwise.

[sprnva]

My read of it is that it is probably to stop businesses (studios, schools etc) from running a dozen or so instances of a single license. Most regular users are not going to have over four installed copies at any one time.

In the case of businesses, if the machines are online they'll snitch to the server. The key line for me is "Registration and use of the plug-ins are possible even if the TAL server is unavailable or you are offline."

The problem for you, as for me, is we don't run our machines offline so it's hard to really test this. Some people do, but we just want to know that the plugins won't fail to activate down the line if the server can't be reached.

Also, I wouldn't trust anything AI says. It can't reason. It just strings words together in a sometimes convincing way.

[audiojunkie]

My read of it is that it is probably to stop businesses (studios, schools etc) from running a dozen or so instances of a single license. Most regular users are not going to have over four installed copies at any one time.

In the case of businesses, if the machines are online they'll snitch to the server. The key line for me is "Registration and use of the plug-ins are possible even if the TAL server is unavailable or you are offline."

The problem for you, as for me, is we don't run our machines offline so it's hard to really test this. Some people do, but we just want to know that the plugins won't fail to activate down the line if the server can't be reached.

Also, I wouldn't trust anything AI says. It can't reason. It just strings words together in a sometimes convincing way.

You are absolutely right to not trust what AI says. But what the AI says makes for great jumping off points for personal research. In this case, I had already done a lot of research on this, because things Patrick had said weren’t adding up correctly to me, and the suggestions made by AI were confirming what I had already personally researched on my own.

For me, based upon my close reading of messages and information by Patrick, he is almost certainly making use of the unique ID that developers use to tie copy protection to the hardware. My queries back and forth to the AI seem to confirm that what I was suspecting is most likely correct.

So trusting AI in this case is not necessary.

Regardless, I no longer feel that I can recommend TAL-Software any more than I can recommend Imageline’s FLStudio’s copy protection, or any other developer that does this.

I had brought up the idea of creating a second tier rating for software that uses this form of copy protection, because it’s not as bad as other copy protection types, but no one seemed to like that idea.

[Kr3eM]

I had brought up the idea of creating a second tier rating for software that uses this form of copy protection, because it’s not as bad as other copy protection types, but no one seemed to like that idea.

Well, the question is can the owner move the plugin and license to another computer without having anything to do with TAL? If not then it's just as bad as a Plugin Alliance, Arturia, Native Instruments, iZotope that is nothing more than a C/R Machine ID DRM that doesn't need to call home to verify...but sure will eventually tell you to GFY cause sooner or later you will upgrade your computer or buy/build a new one.

I believe the reason no one like the idea of a second tier rating in this context is that it would be "hey at least it doesn't need to phone home". I mean that's is only a pro for people who have no issues with "C/R-machine-ID-locked-ransomware" in the first place... this is not really the thread for it....well it has not been so far, it's your thread, you do you.

[audiojunkie]

I had brought up the idea of creating a second tier rating for software that uses this form of copy protection, because it’s not as bad as other copy protection types, but no one seemed to like that idea.

Well, the question is can the owner move the plugin and license to another computer without having anything to do with TAL? If not then it's just as bad as a Plugin Alliance, Arturia, Native Instruments, iZotope that is nothing more than a C/R Machine ID DRM that doesn't need to call home to verify...but sure will eventually tell you to GFY cause sooner or later you will upgrade your computer or buy/build a new one.

I believe the reason no one like the idea of a second tier rating in this context is that it would be "hey at least it doesn't need to phone home". I mean that's is only a pro for people who have no issues with "C/R-machine-ID-locked-ransomware" in the first place... this is not really the thread for it....well it has not been so far, it's your thread, you do you.

It has been my intention to make this a "Community Project In a Thread" as much as possible.
So me being me means that I appreciate everyone's input.

I had originally considering a second tier, but I think now that it complicates things in a realm where it's already too complicated -- I'm referring specifically where you ask developers point blank, and they know darn well why you are asking, and yet they give careful, part answers. I'm not saying they are blatantly lying, but if they give you an answer that "looks" like it is what we are wanting, but in reality isn't what you are wanting, then it bugs me. It's evasive.

At this point, even though TAL-Software has been directly asked point blank about these things, and he has responded, his responses although appearing to be exactly what we are wanting, are leaving out important parts of the information that shows that the copy protection is not what we are wanting. When tying your software to a particular machine's unique ID, which it does indeed appear that his software does, I don't see how when the servers go off line (going out of business or deciding to stop support) how a person can truly reauthenticate a new machine with a new unique ID. When it comes down to it, it still appears to me that the software has to be authenticated through a server, and the number of machines is managed to (IIRC, 4 machines).

It's this kind of back and forth between a developer and the users that I seek to truly avoid.

Our criteria that is listed on the first post of this thread:

1. The copy protection must use either a serial number, a keyfile or a per user Watermark.

2. The copy protection must not tie itself to anything. For example, there are now developers claiming they only use serial number copy protection, but then the copy protection ties itself to a particular CPU or other hardware. Another example is having just a serial number, but the software has to download required files from the vendor site in order to run. This is just as bad as challenge/response authentication. The software should not restrict you to using only the one computer. If you buy a new computer, you should be able to use it without dealing with the company further.
3. The software should not require any form of calling home to authenticate or to obtain the plugin. In other words, if a company were to go out of business, you should be able to pull a copy of the software and serial number or keyfile off of your backup drive, and authenticate the software. Be wary of companies using a single installer for their entire lineup of products or of installers that have to download components from the vendor site to complete the install.

By authenticating with a server using the computer's unique ID, even if the software caches the authentication so that the software can be used if the server goes down permanently, it still won't let a user take a backup of the software and the authentication file and reauthenticate to a completely new machine (in the case of a drive failure or computer replacement/upgrade, for example). So, it essentially violates numbers #2 and #3 of our requirements.

In a way, I feel like I was duped, because I just bought TAL-Software's TAL-J-8X, and it specifically does not meet our criteria, even though we went out of our way to get the answers we needed. I'm really disappointed about this. Even more concerning was how carefully he worded his responses to not give away the fact that new computer will not authenticate if the server is no longer running (in the case of business failure or developer death <-- heaven forbid! ). If nothing else, it really, really drives home to me how we can't really trust anything other than just the three criteria:

1. The copy protection must use either a serial number, a keyfile or a per user Watermark.
2. The copy protection must not tie itself to anything. For example, there are now developers claiming they only use serial number copy protection, but then the copy protection ties itself to a particular CPU or other hardware. Another example is having just a serial number, but the software has to download required files from the vendor site in order to run. This is just as bad as challenge/response authentication. The software should not restrict you to using only the one computer. If you buy a new computer, you should be able to use it without dealing with the company further.
3. The software should not require any form of calling home to authenticate or to obtain the plugin. In other words, if a company were to go out of business, you should be able to pull a copy of the software and serial number or keyfile off of your backup drive, and authenticate the software. Be wary of companies using a single installer for their entire lineup of products or of installers that have to download components from the vendor site to complete the install.

[audiojunkie]

I am so conflicted about TAL-Software, because I don't know what to trust. As a reminder, this is how he responded when I wrote him regarding all of this:

Hello Sean

I don't think the latest update of our copy protection does punish anyone. It always works. Offline and online (special offline activation is not required anymore). The license stays valid when there is no server or no internet connection. You will always be able to use the software, also when TAL does not exist anymore.

It only validates the license from time to time, when you have an internet connection and our server is running.

Patrick Kunz
TAL Software GmbH

So, according to what he says, it looks like it is good. But according to what we know and understand about challenge/response software that ties itself to the hardware, logic seems to indicate that there are "limitations" at best when a situation comes up where the TAL server is gone and new hardware needs to be authenticated.

So how do we rate TAL-Software? I just keep going back and forth on this, with verbal reassurance being positive, and what we know about software that ties itself to hardware being negative....... HELP!

[BBFG#]

It only validates the license from time to time, when you have an internet connection and our server is running

Never trust vagueness.
Specify how and when "time to time" operates and exactly why that's even needed.
I lean to leaving it off this list for this.

[audiojunkie]

I know that there is distrust in AI. However, there are times when AI serves as a useful tool. For example, in this case, AI has been able to point out possible loop holes in our three rules requirements:

Are there any loop holes in these three rules that if the developer obeys these three rules can result in the user not being able to authenticate the software after the demise of the developer? Here are the three rules:

1. The copy protection must use either a serial number, a keyfile or a per user Watermark.
2. The copy protection must not tie itself to anything. For example, there are now developers claiming they only use serial number copy protection, but then the copy protection ties itself to a particular CPU or other hardware. Another example is having just a serial number, but the software has to download required files from the vendor site in order to run. This is just as bad as challenge/response authentication. The software should not restrict you to using only the one computer. If you buy a new computer, you should be able to use it without dealing with the company further.
3. The software should not require any form of calling home to authenticate or to obtain the plugin. In other words, if a company were to go out of business, you should be able to pull a copy of the software and serial number or keyfile off of your backup drive, and authenticate the software. Be wary of companies using a single installer for their entire lineup of products or of installers that have to download components from the vendor site to complete the install.

Yes—there are several “gotchas” where a developer can technically obey your three rules (serial/keyfile/watermark; no hardware tie; no call-home / no vendor downloads) and you can still lose the ability to authenticate, install, or run after the developer disappears.
Below is a structured threat-model style list of the most common loopholes, grouped by what fails after vendor demise, followed by concrete wording you can add to close each gap.

1) “Serial/keyfile” that still depends on a third party (not the vendor)
Your rules block vendor servers, but not other external dependencies.
Loopholes

iLok “machine activation” / other license managers
A plugin can use a serial/keyfile, but the verification is implemented by a third‑party licensing system. If that service breaks, changes, or sunsets, you’re stuck even if the developer is gone.
OS/App Store receipt verification (e.g., “serial” derived from store purchase)
No vendor call-home, but the store ecosystem is still a gate.
Certificate/CRL/OCSP dependency
The plugin might validate a signed license or signed binary and consult certificate revocation infrastructure indirectly through the OS. After years, cert chains can fail, roots can be deprecated, or policies change.

How to close it
Add:
“Authentication must be fully offline and self-contained, requiring no third-party services or license managers, now or in the future.”

2) Offline license that is cryptographically time-bombed
A serial/keyfile can be offline yet still contain a built-in expiration mechanism.
Loopholes

Time-limited signatures / “subscription disguised as perpetual”
License files can contain “valid until” fields (or require a timestamp counter-signature) even if no call-home occurs.
Reliance on system clock monotonicity / anti-rollback
Some copy protection invalidates if it detects clock rollback, leap, or time anomalies—this can happen legitimately after CMOS battery failure, VM restore, dual boot, etc.
Short-lived certificate chain
The license verifies fine today, but in 10 years the signature algorithm is considered insecure and the plugin refuses to validate.

How to close it
Add:
“Licenses must be perpetual with no embedded expiry, renewal, or time-based invalidation, and must not require accurate wall-clock time to remain valid.”

3) “Not tied to hardware”… except it’s tied to software identity or environment
Rule #2 bans CPU/hardware binding, but not other forms of binding.
Loopholes

Tied to OS install ID / machine GUID / user account SID
Not technically “hardware,” but still breaks on reinstall, migration, new user profile, or VM.
Tied to filesystem path / volume UUID / hostname
Restore from backup to a different disk or mount point and the license breaks.
Tied to DAW identity or plugin host fingerprint
Rare, but possible: license checks host or plugin folder signature.

How to close it
Add:
“The license must remain valid across OS reinstalls, user profile changes, disk replacement, virtualization/restore from image backup, and computer replacement—without requiring re-issuance.”

4) “No call-home” but still needs a disappearing runtime or dependency
Even if authentication works, the product can become unusable.
Loopholes

Installer requires a specific runtime (older VC++ redistributable, Java, PACE drivers, etc.) that becomes hard to obtain or incompatible.
Kernel driver / system extension copy protection that stops loading on new OS versions.
Cloud-adjacent “content delivery”
You already mention this (download required files), but it also includes:

downloading presets, IRs, models, wavetables
downloading “factory library”
downloading GPU kernels / model weights (increasingly common)



How to close it
Add:
“All required components (binaries, content, dependencies, runtimes, drivers) must be provided in a redistributable offline bundle, and the software must remain functional without downloading anything.”

5) “Single installer for entire lineup” can be offline… but still gatekept
You’ve already flagged this, but there are subtler variants.
Loopholes

Unified installer contains an embedded product catalog that can be disabled via an update requirement (“this installer is out of date”).
Installer enforces EULA acceptance via a web view
Not “authentication,” but still blocks installation without internet.
Installer uses online notarization checks (macOS Gatekeeper can be bypassed but many users won’t know how)

How to close it
Add:
“Offline installers must not require updates, online EULA flows, web views, or remote notarization checks to complete installation.”

6) Watermarking can create practical lockout (even if “auth” works)
Per-user watermarking sounds safe, but it can be implemented in ways that become brittle.
Loopholes

Watermark embedded via server-side build pipeline
If every download is custom-built per customer, you may not be able to recreate it later even if you have the serial.
Watermark requires vendor to reissue on demand (e.g., “download your personalized installer from your account”)

How to close it
Add:
“If watermarking is used, the watermarking process must be reproducible offline (e.g., via a keyfile) and not require a per-user bespoke binary that must be re-downloaded.”

7) “Offline license” that is legally or technically revoked later
This isn’t server-based, but still defeats survivability.
Loopholes

Kill-switch via blacklist shipped in updates
A plugin can remain offline yet periodically update (manually or via the DAW/plugin manager) and carry a blacklist of “compromised” serial ranges. After company demise, you might install a later build that blocks older licenses.
Mandatory updates for compatibility
Your old version works and authenticates, but a future OS/DAW breaks it; the only compatible build is newer and has a different licensing scheme or dependency.

How to close it
Add:
“No build may contain a license blacklist or revocation mechanism that can disable previously-valid licenses offline. If updates exist, prior versions must remain installable and usable.”

Hidden “soft” call-home: telemetry / analytics gating
A developer can claim “no authentication call-home,” but still block operation if analytics endpoints fail (yes, this happens).
Loopholes

Plugin stalls at startup waiting for telemetry DNS/timeouts
UI won’t open because embedded web component can’t load a remote resource
Crash-report or “news” feed is mandatory due to bad coding

How to close it
Add:
“Failure to reach any network endpoint must not prevent the software from launching or functioning; all network activity must be optional and disableable.”

A tightened “no loopholes” version of your rules (drop-in text)
If you want a compact policy that closes most of the above without becoming a novel, here’s a strong version:


1) License type must be serial, keyfile, or watermark AND verification must be fully offline and self-contained.
- No third-party license managers or external services required.

2) The license must not bind to hardware OR to machine/software identity (OS install ID, account SID, disk UUID, hostname, etc.).
- Must remain valid across OS reinstalls, backups/restores, virtualization, and computer replacement without vendor involvement.

3) Installation and operation must require no network access of any kind.
- No downloading components/content, no web-based EULA flows, no mandatory telemetry, no remote resources.
- Failure to reach any network endpoint must not affect launching or operation.

4) The license must be perpetual with no time-based expiry, renewal requirement, clock-dependency, or algorithm/certificate sunset that blocks use.

5) All required binaries, content, and dependencies must be provided in complete offline installers/archives that can be backed up.
- Watermarking must be reproducible via keyfile/serial, not via bespoke server-built binaries.

[audiojunkie]

So, when we contact a vendor, these are the hard questions we need to be asking:

Practical “audit questions” you can ask a vendor (fast litmus test)

1. “Can I install, authorize, and run this on a brand-new offline computer using only my backups?”
2. “Does the license survive OS reinstall and disk replacement without contacting anyone?”
3. “Do you use any third-party licensing system (PACE/iLok, Codemeter, online receipt checks, etc.)?”
4. “Does any license expire, require clock checks, or require periodic revalidation?”
5. “Is all factory content included in an offline archive? Are there any ‘download-on-demand’ parts?”
6. “Can I disable all networking (telemetry/news/crash reporting) and still run?”

If they can’t answer “yes” cleanly to #1 and #2, survivability is already compromised.

[BBFG#]

I think your AI is flawed in it's basis.
These lists suppose that vendor downloads are the initial way to acquire access and that both the program & serial/key card are available at that time (equally when downloading updates).
This list specifies and dictates that works however and whatever machine the user is using it own without the need for any other involvement from the vendor.

Not even "time to time".
Whatever that means.
TAL needs to clarify what that is.
But I doubt that would absolve it in some kind of AI justification of an acceptable loophole.

[audiojunkie]

I think your AI is flawed in it's basis.
These lists suppose that vendor downloads are the initial way to acquire access and that both the program & serial/key card are available at that time (equally when downloading updates).
This list specifies and dictates that works however and whatever machine the user is using it own without the need for any other involvement from the vendor.

Not even "time to time".
Whatever that means.
TAL needs to clarify what that is.
But I doubt that would absolve it in some kind of AI justification of an acceptable loophole.

You may be right. The key with AI is to not trust what it says blindly. I find it useful to get ideas, but it simply can't be trusted. So, the important thing is that we need to discuss and poke holes into any of the arguments made, and determine what is valid and useful that we can take away from all of it.

For example, I liked the expansion of the 3 rules we had to the 5 rules it suggests (although I'm not sure about the stuff it mentioned about watermarking). I think it covers more. But I'm not sure that I like the wording, and I'm not sure if it covers all that we are wanting. And to be really honest, I sometimes wonder if I'm focusing on it too much. I'm starting to feel burned out from trying to think of different copy protection potential problems. I probably need to step away from it all for a while.

[nusound mind]

You guys are doing God's work w/ this thread. OP is very good reference for devs, many of which I use already. I vote this thread get stickied. I appreciate the rigorous thoroughness too; though I use ilok for some stuff and UAD, subs and phone homing and log in requirements and so forth is something I aim to avoid entirely.

Really if I had to I could use only those plugin companies on the list and be more than good.

[BBFG#]

I've been using this thread to cross reference with the "3 OS ready" thread.
Sure whittles all the possibilities down fast.
Made my top ones as Audio Damage, Audio thing, u-He. Hoping other companies start taking the hint to fit these sensible customer needs.

[whassup]

Yeah, big thank you Sean for your massive efforts with this!
Years ago when people came up with stuff like this I didn't take it seriously.
But after I got burned seriously several times I am striving for a completely "non phoning home" system.
Gladly this isn't 2005 anymore.
We have basically all and everything and dozens of alternatives.