tecosystems

The State of Open Source Licensing in 2026

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

As far back as 2012, a RedMonk colleague was asserting that we were living in a “post-open source world,” meaning a world in which open source had been so successful that the very things that underpinned it – open source software licenses, for one – were taken for granted and thus, ignored. This hypothesis was supported by various datapoints ranging from GitHub’s acknowledgement that less than 20% of the repositories it hosted carried open source licenses to the repeated poor behavior of large companies that should know better brazenly and cavalierly misusing the term open source.

That unfortunate apathy notwithstanding, assertions that open source “doesn’t really matter” have never been any more defensible than saying climate change doesn’t matter because the average citizen pays it little mind. While the industry is undergoing tectonic shifts due to the incredible advances in AI, and there are multiple lines of potentially intractable questions about how open source licenses apply in this new era, the fact is that open source software is still being produced, and licensing decisions made around them are still being made strategically – see Swamp’s license choice, as but one example.

All of which means that it’s important to periodically take stock of the open source licensing landscape, to step back and evaluate its trends and tease apart what those might suggest about our industry and the choices its making moving forward. One of the last times we did this was in 2017, when the best available data was from Black Duck.

To bring that up to date, we’ve compared and contrasted historical data from sources no longer extant (Black Duck), sources that are still available but have undergone significant, disruptive transitions in the dataset (the GitHub Archive), and current, active sources (deps.dev – a superset of software package repositories). A few caveats before proceeding:

  • As noted above, in the largest single source of this data, the overwhelming majority of projects – likely 80% or more – do not carry licenses and are thus not represented in this analysis. Given that the cost of producing software is approaching zero thanks to step function changes in code assist abilities, this delta will likely only increase.

  • There is no single source of truth for the industry. Some datasets as mentioned are no longer available. Others like the GitHub Archive have undergone changes over the years making consistent measure hard to impossible. And none of them have insight into the full spectrum of software written and relied upon behind enterprise firewalls.

  • Much like with RedMonk’s Programming Language Rankings, then, this analysis should be considered an evaluation of the data that’s available rather than a full fidelity representation of the licensing reality.

Those limitations acknowledged, there are nevertheless some interesting takeaways from the data that is available. Here are the key themes worth noting for open source licensing in 2026.

The Rise of Permissive Licensing

Noted here well over a decade ago, the industry has been amidst a long term shift away from more restrictive, copyleft-style licenses to more permissive alternatives. The precise ratio of copyleft to permissive licenses has depended on the year and the particular sample surveyed, but they all have shown a marked shift away from copyleft licenses.

It’s difficult to pinpoint the exact point in time that we moved from a copyleft majority licensing environment to a permissive one, but a reasonable estimate is that the industry unknowingly crossed that chasm at some point between 2014 and 2017.

To some degree, this was inevitable, as copyleft’s absolute dominance from a licensing standpoint can be appropriately understood as being at least in part an artifact of the overwhelming popularity of copyleft projects such as Linux and MySQL. Greater license diversity was always likely, if not inevitable.

One interesting question is whether, as so often happens in industry, the pendulum will begin to swing back towards copyleft. With the caveat that there are odd small sample size issues with recent GitHub Archive data, there is some evidence to suggest this. Permissive licenses have ticked down from a high of 82% in 2022 to 73% in 2025. Again, this could simply be a sampling issue – the packaging data from deps.dev indicates no similar shift – but it’s worth watching if only because of the recent return from a few major projects to the AGPLv3 in particular which will be discussed more momentarily.

License Distribution by Package Ecosystem

Before looking at license traction as a whole, it’s worth examining community-level differences and drivers. This is based on data extracted from deps.dev, and looks at the license distribution across seven major package repositories.

As is evident, these repositories – like the data more broadly – tend to skew permissive. There are notable issues with certain repositories – in NuGET, the .NET package repository, more than half the packages have licenses that don’t map to SPDX identifiers and are thus unclassifiable. The npm package repository, meanwhile, skews heavily towards the ISC license as npm init historically defaulted to it. Maven’s Java focus, meanwhile, left it solidly in Apache’s orbit.

It’s worth noting, however, that these packages generally reflect deployed code, and as will be shown momentarily, the deployed code shows higher rates of permissive license usage than copyleft. That being said, also as we’ll come back to, npm’s weight in this sample – being roughly 3X more than the other repos combined – is overrepresented.

Apache vs MIT

The two primary beneficiaries of the rise of permissive licensing have been the Apache Software License and the MIT. In part because of its patent termination provisions that attempt to minimize the possibility of patent infringement litigation, Apache has tended to be the preference for commercial open source usage versus the MIT license which does not mention patents at all.

Both licenses dramatically improved their share of usage over the past two decades, but following the creation of the CNCF which favored Apache licenses in 2015 and the introduction of popular Apache licensed projects like TensorFlow in the same year and PyTorch the year after in 2016, Apache’s share of distribution began climbing in 2017 to a peak in this dataset of around 30% in 2022. This corresponded with a slight but noticeable decline in MIT’s share over that time, suggesting that the growth of the one came at least indirectly at the expense of the other.

In 2023, however, this trend reversed in dramatic fashion, and Apache usage dropped dramatically while MIT spiked. In all likelihood, this is an artifact of oddly smaller sample sizes post-2022, culminating in a dramatically smaller 2025 sample RedMonk is still seeking explanations for as we perform our regular biannual programming language ranking.

It’s also possible that it’s in part a reflection of the aforementioned outsized significance of JavaScript as a language and npm as a repository, as the latter favors MIT and hosts by far the most packages. Which brings us in turn to:

The Packaging Filter

One interesting exercise to consider is what deltas if any there might be between hosted source code and packaged code about to be deployed. In general, the differences tend to be minimal, but one obvious distinction is in the aforementioned outperformance of ISC. A historical default for npm, it is dramatically over-represented in the deps.dev dataset, being 31X more common there than on GitHub – a natural consequence of npm’s immense presence.

Both GPL licenses, for their part, are much more common on GitHub – 34X more common in the case of version 2 – than in deps.dev, which is predictable given the latter’s overwhelming preference for permissive rather than than copyleft licenses.

As a side note, while reading this chart: the “Unlicense” above is not a typo for “Unlicensed,” it’s an actual license that says, essentially, users can do whatever they want they want with the code. It’s more or less public domain for source code.

Source Available Licenses

One last question when surveying the state of licensing in 2026 is the degree to which non-open source, source available or hybrid licenses such as the BSL or SSPL are in circulation. The short answer to this is that these licenses are not measurable in a statistically significant way. They remain extremely uncommon and are not trending.

While they are not relevant statistically, however, they remain for the time being strategically relevant because of the projects that carry them (e.g. MongoDB, Terraform, etc). While there have been notable returns to open source licenses from source available alternatives – Elastic and Redis, for example, returned to an OSI approved license in the AGPL – the long term future of source available licensing will not be determined by a quantitative analysis such as this.