COBOL DevHub and build server license questions
Automated build infrastructure runs without a developer sitting at it, and counting it as though a person were assigned to it inflates a seat count for machines that hold no seat. COBOL DevHub and build server license questions concern how shared development hubs and continuous integration build servers are counted, and a finding that treats each build agent as a developer seat, or charges automated infrastructure as named users, overstates the position.
Visual COBOL and the development tooling around it reached the OpenText estate through the Micro Focus acquisition that closed on January 31, 2023, and the development side is governed by the Additional License Authorizations. Modern COBOL development runs through shared hubs and automated build pipelines, where compilation happens on infrastructure rather than at individual workstations, and the metric that governs a developer is not the same as the metric that governs a build server. When a discovery scan reads an estate it sees installations, not the role behind each one, and a finding built on that view tends to count every machine with the tooling as a developer seat. This article sets out how build infrastructure is counted, where the finding inflates, and how the seats are restored to actual developers line by line.
What a DevHub and a build server actually do
A development hub centralises shared development services, and a build server compiles and assembles code automatically as part of a pipeline, often many times a day, without a developer interacting with it directly. Neither is a person, and the developer seat metric is defined around people who develop, not around the infrastructure that supports them. The distinction between a named developer and the runtime or automated infrastructure is the one set out in Visual COBOL named developer versus runtime metrics, and it is the foundation for counting build infrastructure correctly rather than as a roomful of phantom developers.
Where a finding overcounts build infrastructure
The overstatement begins when the scan reads the tooling on a build server and the finding counts it as a seat. Several patterns recur around COBOL DevHub and build server license questions.
- Build agent counted as a developer. Each automated build agent charged as a named developer seat though no person is assigned to it.
- Pipeline fan out counted as users. A pool of ephemeral build workers counted as a population of developers.
- Hub counted twice. A shared development hub counted both as infrastructure and as a seat for every developer who connects to it.
- Service account counted as a person. An automation service account treated as a named user, the same error examined for runtime in runtime versus development license counting for COBOL.
The developer seat metric counts people who develop, not the infrastructure that builds. A finding that charges each build agent as a developer is reading a person into a machine that runs unattended, and it is corrected by mapping seats to actual developers and counting build infrastructure on the basis the authorizations define for it.
Restoring the seat count under the four Rs
The defense returns build infrastructure to its correct basis through the firm's four Rs. Respond inside the seven day notice window, set a single controlled channel, and prevent any vendor script from measuring before the development topology is mapped. Reconstruct the position by reading the Additional License Authorizations to establish how developer seats are defined and how shared hubs and build servers are treated, then label every installation as either a developer workstation, a shared hub, or automated build infrastructure. Rebut the finding line by line, removing any line that counts a build agent or service account as a named developer and any line that counts a hub twice. Resolve on terms that record how build infrastructure is counted, so a future audit cannot recount the pipeline as developers. The reconciliation that organises this work is the one in reconciling COBOL entitlements before an audit.
Why automation multiplies the error
Build pipelines are designed to scale, spinning up workers on demand and tearing them down when a build completes, which means a scan taken at the wrong moment can see far more build agents than ever run at once. Counting each transient agent as a permanent developer seat turns a handful of real developers into a finding sized for an army. The same scaling logic that makes pipelines efficient makes them dangerous in a flattened scan, which is why build infrastructure has to be identified as infrastructure and counted on its own basis rather than swept into the seat count. Mapping the actual developer population, and separating it cleanly from the automation that serves it, is what keeps the seat count honest.
In a recent engagement
In a recent COBOL engagement, a finding counted a continuous integration estate of build agents and a shared development hub as named developer seats, inflating the seat count well beyond the actual development team. The defense read the authorizations, mapped the real developers, and demonstrated that the build agents and service accounts were automated infrastructure rather than people. Once the seats were matched to actual developers and the build infrastructure was counted on its own basis, the finding fell to the defensible figure. The reduction was characteristic of the firm's record across more than 200 defended audits, contributing to the 68 percent average reduction and the more than $90M in claims mitigated against vendor positions.
Why the seat belongs to the developer, not the pipeline
The lesson is that a developer seat counts a developer, and build infrastructure is counted on the basis the authorizations define for infrastructure, not as a population of seats. Because the noncompliance remedy is priced at then current list with back maintenance and audit cost recovery stacked on top, counting build agents as developers multiplies a charge for people who do not exist. Reading the authorizations, mapping seats to developers, and resolving on terms that hold the treatment of build infrastructure is what keeps a COBOL development finding sized to the team rather than the pipeline. To have a COBOL development finding tested against the way build infrastructure is actually counted, open a case.
Is your finding counting build servers as developer seats?
We read the Additional License Authorizations, map seats to actual developers, and remove any line that charges automated build infrastructure or a shared hub as a named user. To get a defense team on the file, open a case or download the guide to reading the Micro Focus ALAs.
Get The Number Down →Related field notes
These notes from the COBOL and Enterprise Server mainframe audit defense cluster cover developer seats, build and runtime infrastructure, and the reconciliation that scopes them. Each links back to the complete OpenText audit defense playbook for 2026.
- Visual COBOL named developer versus runtime metrics
- runtime versus development license counting for COBOL
- Visual COBOL development seat counting traps
- Visual COBOL for Eclipse and Visual Studio seats
- reconciling COBOL entitlements before an audit
If an OpenText or Micro Focus audit notice has arrived, the first seven days matter 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, reduced the average finding 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.