International Security Journal hears exclusively from Phil Odence, General Manager of Black Duck.
As AI reshapes how software is written, some have begun to question whether open source can maintain its central role.
That said, open source remains the backbone of modern software – and AI is accelerating its use, not replacing it.
What is changing is the volume of code and therefore the management challenge.
As the 2026 Open Source Security and Risk Analysis (OSSRA) report makes this clear, open source has entered a more mature phase that demands legal awareness, governance and active oversight.
The era of informal trust and passive consumption is giving way to accountability, transparency and discipline as AI dramatically increases the pace and scale of software creation.
Ubiquity brings responsibility
Open source has effectively become universal. Modern applications rely on it not just for infrastructure, but for core functionality across cloud platforms, data pipelines and AI frameworks.
This level of dependence is a testament to open source’s success, but it also raises the stakes.
As codebases grow larger and more interconnected, organisations are no longer managing a handful of libraries – they’re inheriting responsibility for hundreds or thousands of components, many of them transitive and never explicitly chosen.
Each one carries security exposure, licensing obligations and long-term maintenance implications.
That scale reflects how thoroughly open source has moved from a grassroots innovation model into critical economic infrastructure – and infrastructure requires governance.
Vulnerability growth reflects scale, not failure
One of the most visible OSSRA findings is the continued rise in vulnerability counts, which is a natural consequence of scale, visibility and improved disclosure practices rather than a sign that components are becoming less secure.
More components mean more findings.
Better research means more issues identified.
Structural changes, such as expanded vulnerability reporting authorities, have surfaced risks that previously went untracked.
In many cases, this reflects progress, not regression.
The real challenge is prioritisation, given the volume.
Security teams are drowning in data, and mature governance means understanding which risks are exploitable, which carry legal, regulatory weight and which can wait.
Licensing is the quiet signal of maturity
If security risk gets the attention, licensing risk is where maturity is most clearly on display.
The OSSRA shows license conflicts at historic highs, driven by exploding dependency counts and increasingly complex licensing models.
More projects are adopting source-available or restrictive licenses as maintainers seek sustainable funding, a shift that reflects the commercial pressures on open source rather than a rejection of its principles.
For organisations, however, it means long-held assumptions need revisiting.
License obligations are not always obvious, and unlike security vulnerabilities, license violations can’t be fixed by upgrading to the latest version; they persist through acquisitions, audits and product launches until they are actively resolved.
The trend is visible in concrete examples.
Redis moved from a permissive BSD license to more restrictive models before adding AGPL as an option, triggering community forks and prompting many organisations to migrate to alternatives such as Valkey.
Bitnami shifted its container images to a paid licensing model, changing assumptions about freely available infrastructure.
Alongside these moves, a new class of source-available licenses has gained traction: the Business Source License (BSL), the Functional Source License (FSL) and the Fair Core License all offer broad rights for non-competing or non-production use with conversion to a recognised open source license after a set period.
Most organisations shifting to these licenses to do with the intent of making money and therefore pursuing violators.
These hybrid models reflect a genuine commercial tension, but they also mean that a component that appears open today may carry restrictions that matter for production deployments or commercial distribution.
As open source becomes more commercially and legally significant, treating license compliance as a secondary concern is no longer viable.
Mature use requires proactive legal awareness, not reactive cleanup during audits or acquisitions.
AI has complicated the meaning of “open”
AI introduces another dimension to this maturity shift: ambiguity around authorship and provenance.
AI models seem to use code without regard for licenses.
They generate code based on patterns, not permissions.
As a result, organisations face new questions:
- Where did this code originate?
- What obligations might it carry?
- How do we distinguish human-written code from machine-generated output?
In this context, as organisations race to build AI-powered applications, AI models themselves have become part of the software supply chain – often governed by open source or hybrid licenses.
Treating AI as separate from open-source governance creates critical blind spots, obscuring licensing obligations, security risks and compliance exposure now embedded directly in production systems.
In an AI-accelerated world, governance gaps don’t just slow innovation – they amplify risk at scale.
The answer is to extend governance models to match reality, not to slow adoption.
Maintenance debt is no longer just technical
Perhaps the clearest sign that open source has matured is how maintenance debt is now viewed.
For years, outdated and abandoned components have been tolerated as technical debt.
That tolerance necessarily wanes with the volume of cool.
When a component is abandoned, organisations are entirely on their own.
When it’s merely outdated – often by several versions – support may exist, but only if teams first endure risky, complex upgrades that grow harder the longer they wait.
What was once an engineering inconvenience has become a business and compliance liability.
New regulations are codifying the evolution of software hygiene, vulnerability response and long-term support – leaving organisations with little room for neglected code in their software supply chains.
When organisations ship software built on components that are no longer maintained, they inherit full responsibility for keeping those components secure, compliant and operational.
Updates may still be possible, but the further a component falls behind, the more complex, costly and risky remediation becomes – often requiring custom fixes, re-engineering or acceptance of known vulnerabilities.
In a mature software ecosystem, “we didn’t know” is no longer an acceptable answer.
Outdated components don’t just introduce technical debt; they transfer long-term security and compliance obligations squarely onto the organisation, with little margin for error.
Maturity demands visibility
Across security, licensing, AI and maintenance, one theme dominates: visibility.
You cannot govern what you cannot see.
Basic approaches to software composition analysis that focus only on declared dependencies miss significant portions of modern codebases: copied snippets, bundled vendor code and AI-generated content included.
In today’s environment, that visibility gap is a strategic risk, not a tooling oversight.
The organisations navigating this transition successfully have invested in better insight, clearer policies and governance practices that scale with modern development.
Open source’s next chapter
Open source is stepping further into relevance, not retreating from it.
The pressures highlighted in the OSSRA, including legal scrutiny, AI-driven scale, licensing evolution and regulatory oversight are not signs of retreat.
They are the hallmarks of a technology that has become indispensable.
Open source has grown up and like any mature system, it now demands responsibility to match its importance.
For organisations, the message is clear: passive use is no longer enough.
The future belongs to those who pair innovation with governance and treat open source not as a shortcut, but as a strategic asset worthy of active oversight.
