WebSphere ND and the IBM HTTP Server trap.
WebSphere Application Server Network Deployment ships alongside components like the IBM HTTP Server and the web server plug-in, and an audit will test whether you understood the line between what is bundled and what is separately licensed. Treating a restricted use component as full WebSphere is one of the most common self-inflicted findings on the product.
WebSphere Network Deployment is licensed by PVU on the cores running the application server. The complication is that the installation media and the entitlement carry supporting components, and those components come with their own use restrictions. An auditor who finds the IBM HTTP Server running on a tier you did not license WebSphere on will ask why, and the answer determines whether that server is in scope or out.
What ND actually entitles
The Network Deployment entitlement covers the application server cells and nodes you run WebSphere on, counted by PVU under sub-capacity where the conditions hold. Bundled with it are supporting pieces, most visibly the IBM HTTP Server and the web server plug-in, which exist to front WebSphere applications. These are provided for use with the entitled WebSphere deployment. They are not a free standing license to run a web server estate wherever you like.
The restricted use boundary
The trap is treating a bundled, restricted use component as though it carried the same broad rights as the product that bundled it. The IBM HTTP Server shipped with WebSphere is intended to support the licensed WebSphere environment. Deploy it on hosts that are not part of an entitled WebSphere deployment, or use it to serve content unrelated to WebSphere, and you have stepped outside the restricted use grant. That step is exactly what an audit is built to surface.
The argument under audit is rarely about the WebSphere cores you clearly licensed. It is about the HTTP Server instances on the edge: which ones front entitled WebSphere applications, and which ones drifted into general purpose web serving. The first group is in scope under the bundle. The second is where IBM will try to assert a separate licensing requirement.
How we defend the boundary
- Inventory every IBM HTTP Server instance and map it to the WebSphere deployment it actually fronts.
- Separate instances genuinely supporting entitled WebSphere applications from any that drifted into unrelated use.
- Apply sub-capacity correctly to the WebSphere cores themselves, so the application server count is not inflated alongside the scope question.
- Document the topology so the relationship between web tier and application tier is evidenced rather than assumed.
- Where an instance is genuinely out of scope, size that specific exposure rather than letting it color the whole WebSphere position.
Handled early, the HTTP Server question is usually a documentation exercise that confirms most instances are squarely inside the bundle. Handled late, after IBM has framed every web server as a separate liability, it becomes a negotiation over a number that never needed to exist.
WebSphere ND bundles the IBM HTTP Server under a restricted use grant, not a general license. Map every web server instance to the WebSphere deployment it fronts, prove the relationship, and isolate any instance that drifted out of scope before IBM bundles them all into the finding. The boundary is defensible, but only with the topology documented.