Engineering teams depend on software they did not write. That is ordinary and often valuable. The leadership question is whether the organisation can explain the conditions under which it uses those components, alongside the technical reason for choosing them. In 2024 we examined ninety-seven libraries in a defined platform estate. Eighty-six had an approved licence account for their intended use. Eleven had incomplete evidence. The review did not begin with a finding of infringement. It began with an inability to show a complete internal basis for a decision the platform already depended on.
Availability is only the beginning of the account
Two immediate responses competed. Some engineers considered the issue administrative because the components were available through familiar channels. Other colleagues wanted every uncertain library removed immediately. Both positions moved too quickly from the state of our records to a conclusion about the underlying permission. A downloadable package does not tell the whole story of an intended use. Equally, a missing internal document does not establish that the use is unlawful. We needed to recover facts, obtain qualified interpretation and decide what engineering work followed from that account.
I supported a review involving legal and procurement colleagues as well as the platform team. Engineers supplied the component versions, sources, intended uses and integration context. That work mattered because a legal reviewer cannot interpret an abstract label detached from what the organisation actually plans to do. The technical team had to describe its use accurately without assuming that technical familiarity made it competent to deliver the legal conclusion. Procurement helped recover records that individual developers could not reasonably be expected to reconstruct from memory or from a current package page alone.
Seven of the eleven libraries were subsequently approved for the specified use after review. Four were replaced. The response cost ₹42 lakh and occupied six weeks, including the engineering and acceptance work associated with replacements. The arithmetic is useful because it prevents the outcome from being compressed into an inaccurate statement that all eleven were simply cleared. Some uncertainty was resolved through evidence and review; some resulted in a change to the technical estate. Those are different paths with different implications for maintenance and future decisions.
Replacement was not just a procurement event. A component can participate in behaviours that other parts of the platform assume will remain stable. Engineers had to understand those dependencies and show that the alternative supported the required work. Insurance professionals retained authority over any consequences for pricing, underwriting, claims or other specialised decisions. The library review did not grant engineering permission to alter those meanings for convenience. A funded replacement path therefore needed acceptance of the relevant behaviour as well as a satisfactory account of the new component's intended use.
Separate missing evidence from a legal conclusion
The incomplete records also required restraint in language. We did not publish an accusation against an author or supplier because our own evidence was missing. Nor did we call the original eighty-six permanently safe from future questions. Their accounts were approved for the versions and uses examined. A different release, integration or distribution arrangement could require another review. The result was a defined improvement in a defined estate. It was not a certification of every component across the enterprise or a promise that all future dependency choices could proceed without scrutiny.
Keep the permission question alive as the use changes
This distinction changes the quality of the engineering inventory. An inventory that lists only names and versions may help locate a dependency, but it may not explain the decision to rely on it. The useful account connects the technical purpose with the conditions examined, the responsible reviewers and the circumstances that would prompt reconsideration. It should be practical enough for a receiving team to maintain. If the account becomes an elaborate document that nobody can update when the software changes, its apparent completeness may conceal a growing gap between the approved description and actual use.
There is a capacity question here as well. Keeping the account current takes work, and replacing a component can displace other engineering commitments. That cost should be visible when the dependency is selected, rather than appearing later as an unexpected obstacle imposed by another function. The initial attraction of a library may include speed and reduced development effort. A fuller decision also considers maintenance, interpretation and the possibility that the intended use will evolve. Recognising those obligations does not negate the library's value. It makes the decision more complete and easier to defend over time.
I do not want the lesson reduced to a rule that engineers should become lawyers. Their responsibility is different and substantial: identify what they are using, describe how they are using it, preserve relevant evidence and recognise when the facts have changed. Qualified advisers provide interpretation within the appropriate process. Leadership must make that collaboration workable. If review is treated as a mysterious approval that occurs after every technical choice is fixed, teams will experience it as delay rather than as part of designing a sustainable service. Earlier clarity gives the organisation more options.
The same collaboration requires useful uncertainty. When evidence is incomplete, the record should say what is missing and who can resolve it. An undifferentiated red label can be as unhelpful as an automatic green one. It may encourage unnecessary replacement, conceal the effort required to recover a straightforward record or imply wrongdoing that has not been established. Conversely, an optimistic note that someone will find the paperwork later can allow uncertainty to become permanent. A good management account supports a proportionate next decision without pretending the answer is already known.
At board level, I would connect this experience with the enterprise's dependence on external intellectual and technical work. The board need not approve individual packages. It can ask whether management understands the obligations attached to critical dependencies, has access to the appropriate expertise and funds the responses its review produces. It can also examine whether reporting distinguishes a lack of evidence from a confirmed adverse conclusion. Those distinctions help directors challenge constructively without turning a technical inventory into a courtroom or treating every uncertain record as an equal business risk.
My conclusion is that permission should travel with the dependency's engineering account. The library is not merely a useful file that arrived one day and can thereafter be treated as part of the furniture. Its version, purpose and conditions belong to a continuing decision. In our review, seven libraries found an approved path through better evidence and four required replacement. The important leadership action was to keep those paths distinct, obtain the judgement we were qualified to seek rather than invent, and give engineering the capacity to act on the result. That is a more durable foundation than either casual confidence or unsupported alarm.