Alright, I’ve been watching these threads for a while, and the amount of vague, hand-wavy nonsense in the answers to this fundamental question is truly impressive. Vendors love to obfuscate this, and forum cheerleaders often parrot the marketing copy without ever having read a real order form.
So, let’s cut through it. The short, brutal answer is: **It depends entirely on the vendor’s specific licensing model, and they often have several.** You cannot assume “license per machine” or “license per user” is universal. Anyone who tells you otherwise hasn’t done the procurement paperwork.
Here’s what you need to dissect, because this is where they get you on true-up audits and compliance:
* **Named User vs. Concurrent User:** This is the biggest trap. “Named User” means a specific human being needs a license, regardless of how many machines they use. If Jane uses her desktop, laptop, and a VM, she still only needs one license *if it’s Named User*. “Concurrent User” means a set number of people can be using the software at the same time, across any number of machines. These are wildly different cost structures.
* **Per-Node or Per-Instance Licensing:** Common for server/backend tools. If Cline has an agent or a service that runs on a physical or virtual server, that server is a “node.” Spin up a new VM? That might be another node. Containerized? Hope your vendor’s policy is clear on that, because most from the old guard aren’t.
* **The “Development/Testing” Mirage:** Some vendors offer free dev licenses, some require full licenses for any environment that isn’t production, and some have a murky “non-production” clause that’s a compliance nightmare waiting to happen. You need this in writing.
* **The Machine-User Mismatch:** The classic problem: You have 100 engineers but 300 machines (including VMs, containers, cloud instances). If you buy 100 Named User licenses, but your deployment model means the software is installed on 300 endpoints, you are likely in violation. The license metric (user) doesn’t match the deployment unit (machine).
My advice? Don’t ask the community for a definitive answer. The only answer that matters is in the **Master Service Agreement** and the **Product-Specific Terms**. Look for the section titled “License Metric” or “Unit of Measure.” Then, call your sales rep and make them explain it *in an email* with a specific, written scenario: “If my employee uses it on their laptop and their home desktop, is that one or two licenses? If we run it in a Docker container that scales up to 10 instances, what is the count?”
If they waffle or give you verbal assurances, walk away. This ambiguity is a feature of their pricing model, not a bug.
show me the tco
Oh, and let's not forget the glorious "Per-Node" vs. "Per-Instance" distinction you started to mention. It's a masterpiece of confusion, especially in containerized environments.
Is a spinning Kubernetes pod an "instance"? What about when it scales down to zero? The vendor's PDF will say one thing, their sales engineer will wink and say "it's fine," and the audit clause buried on page 17 will have a completely different, horrifying definition based on "deployed images" or "active cores." You haven't truly lived until you've had to explain to finance why your dev cluster needs a license for 50 potential nodes but only ever runs 3.
They all love the flexibility of cloud scaling until it's time to pay for the theoretical maximum footprint.
Demos are just theater. Show me the real workflow.
Preach. The "theoretical maximum footprint" clause is the one that keeps me up at night. Had a sales rep for a major analytics platform swear up and down their "per instance" model was container-friendly. The fine print defined an instance as "any virtual or physical environment capable of executing the software," which their legal team later argued included every single runner in our GitHub Actions fleet because a test could technically spin it up.
You win the audit lottery based on which department bought the license. Engineering? Might be okay. Sales ops? You're paying for every dormant VM in Azure.
been there, migrated that
Your example with GitHub Actions runners is precisely why we instrument our CI/CD licensing costs as a separate metric in our internal Grafana dashboard. We had to define a "software execution minute" based on Prometheus scrape data to prove our ephemeral runners never loaded the licensed library's core module, only its CLI shim. The vendor's audit team backed down when presented with the time-series data showing zero concurrent execution on over 98% of spawned runners.
It shifts the negotiation from legal definitions to observable runtime behavior. You still need the initial clause scrutiny, but your evidence becomes the operational telemetry, not the interpretation of "capable of executing."