Visual COBOL development seat counting traps

A development seat metric sounds simpler than a core metric, and that apparent simplicity is exactly what makes it dangerous. Visual COBOL development seat counting traps arise because a finding counts installs, access rights, and shared infrastructure as if each were a working developer, when the licensed unit is the developer who actually writes and compiles code.

Visual COBOL reached the OpenText estate through the Micro Focus acquisition that closed on January 31, 2023, and its development tooling is governed by the Additional License Authorizations rather than the OpenText EULA. The development edition licenses people who develop, but the easiest count for a vendor to assemble is a count of installations or of accounts with access, and those numbers are almost always larger than the population of genuine developers. The gap between the two is where a seat finding inflates, and closing that gap is most of the defense.

Why a seat count drifts upward

A seat metric is supposed to track the number of developers entitled to use the product. In practice a finding is built from whatever the vendor can measure most easily, and that is rarely a clean roster of active developers. It is usually a discovery scan that finds every machine with the software installed, every account in a directory group, or every login recorded against a license server, regardless of whether the person behind it ever opened the development environment. Each of those proxies counts more seats than the deployment supports. An install left on a decommissioned laptop, a service account that exists only to run a scheduled task, or a directory group that was never pruned all add seats that no developer occupies.

This is the same structural problem that appears across seat based products, and the discipline for separating the metric from the proxy is the same. The distinction between licensing developers and licensing access is taken up in runtime versus development license counting for COBOL and in Visual COBOL named developer versus runtime metrics, both of which bear directly on how a seat count should be assembled.

The specific traps to watch

The development seat counting traps cluster around a handful of recurring sources, each of which adds seats that do not belong in the count.

• Stale installs. Software left on retired or reimaged machines that no developer uses, yet a discovery scan still finds.
• IDE access without development. Accounts that can open the environment but never compile, sometimes counted as full seats. The editor and platform question is examined in Visual COBOL for Eclipse and Visual Studio seats.
• Build and continuous integration infrastructure. Automated build servers that compile code without a human developer, which belong under different terms, the subject of COBOL DevHub and build server license questions.
• Service and shared accounts. Non human accounts and shared logins counted as if each were a distinct developer.
• Non production environments. Development tooling deployed in sandboxes or training environments swept into a production seat count, as discussed in how to scope COBOL development versus production.

How we hold the count to real developers

Reducing a development seat finding to the genuine developer population runs through the four Rs. Respond inside the seven day notice window and hold a single controlled channel, so the seat count is built from one agreed roster rather than from a raw discovery export. Reconstruct the effective position by reading the authorization for what a development seat licenses, then mapping installs and accounts against evidence of actual development activity, compilation logs, commit history, and active project assignment. Rebut the finding seat by seat wherever it counts stale installs, build infrastructure, service accounts, or non production environments as developers. Resolve on terms that define the seat clearly and set a clean baseline, so the next audit does not re run the same inflated count. The throughline is to insist that a seat correspond to a person who develops, and to make the vendor demonstrate that correspondence for every seat it counts.

In a recent engagement

A defended engagement in the technology sector shows how far a seat count can drift from reality. In matter E-02, a Fortify application security finding asserted a developer seat overclaim of $4.5M, built largely from repository access rather than from the people who actually submitted scans. Mapping the real submitters against the asserted seats reduced the finding to $0.9M, an 80 percent reduction. The product differs, but the trap is identical to the Visual COBOL case: a seat count assembled from access or installs rather than from genuine use, corrected by mapping the count to the population that actually performs the licensed activity.

Count the developers, not the footprint

The recurring lesson of Visual COBOL development seat counting traps is that a finding measures the easiest thing to measure, which is the software footprint, and then prices it as if every install and account were a working developer. The licensed unit is narrower than the footprint in almost every estate. The defensive task is to read what the development seat actually licenses, assemble a roster of genuine developers from evidence of real activity, and require the vendor to justify each seat above that roster. Most of the available reduction on a development seat finding sits in the difference between the footprint and the developers, and that difference is reliably large.

Perpetual and term seats are not interchangeable

A further trap sits underneath the headcount question. Development seats may be licensed perpetually or on a term basis, and a finding sometimes prices term entitlements as though they were missing perpetual licenses, or counts a seat against the wrong model entirely. The remedy on a noncompliance finding is calculated at then current list price, so applying the wrong model to a seat compounds the overcount with a pricing error. Establishing which model governs each seat, and pricing any genuine shortfall against the correct one, is part of holding the development seat count to what the agreement actually says rather than to what the finding assumes.

Related field notes

These notes from the COBOL and Enterprise Server mainframe audit defense cluster cover seats, developers, and tooling. Each links back to the complete OpenText audit defense playbook for 2026.

• runtime versus development license counting for COBOL
• Visual COBOL named developer versus runtime metrics
• Visual COBOL for Eclipse and Visual Studio seats
• COBOL DevHub and build server license questions
• how to scope COBOL development versus production

If a notice of an OpenText or Micro Focus audit has arrived, the first seven days weigh more than any week that follows them. OpenText Audit Defense is an independent, buyer side practice founded in 2020 by former vendor compliance leadership. We have defended more than 200 audits, brought the average finding down by 68 percent, and mitigated more than $90M in claims against vendor positions. We do not resell OpenText software and we are not affiliated with OpenText Corporation. To open a case, use the contact form on this site.