Open source licensing governs almost every piece of software shipped by Australian development teams today. Whether your team is pulling packages from npm, building on top of Linux, or embedding a third-party library into a commercial product, the terms under which that code was released are a legal reality your organisation has to manage. Get it wrong and you are exposed to intellectual property claims, forced source disclosure, or licence revocation. Get it right and open source becomes one of the most powerful levers in your delivery toolkit.
Why open source licensing matters more now
The average modern application draws on hundreds of open source dependencies. Tools like npm, pip, Maven, and Cargo have made pulling external libraries into a project almost frictionless. That ease of adoption, however, has not been matched by an equivalent rise in licence awareness at the team level. Legal and engineering tend to operate in separate worlds, and open source compliance often falls through the gap between them.
In an Australian context, the stakes are rising. Supply chain security has become a board-level concern, and licence audits are now a standard part of due diligence for M&A transactions, government procurement, and enterprise contract negotiations. If your software contains code under a licence your organisation has not honoured, the consequences range from reputational damage to injunctions. Understanding how supply chain risks propagate through software dependencies is directly relevant here: licence violations often travel the same path as vulnerabilities.
The main licence families
Not all open source licences work the same way. There are three broad families worth understanding:
- Permissive licences. These let you use, modify, and redistribute code with minimal restrictions. The MIT, BSD (2-clause and 3-clause), and Apache 2.0 licences sit in this category. Apache 2.0 is especially common in enterprise software because it includes an explicit patent grant, giving downstream users protection against patent claims from contributors. For commercial products, permissive licences are generally the most straightforward to work with.
- Copyleft licences. These require that any software incorporating the licensed code is distributed under the same (or a compatible) licence. The GNU General Public Licence (GPL) is the most prominent example. If you embed GPL-licensed code in a commercial application and distribute that application, you are typically required to release your own source code under the GPL. The GNU Lesser GPL (LGPL) is a softer variant that allows linking to the library without triggering the copyleft obligation in most cases. The GNU Affero GPL (AGPL) extends the obligation to software delivered over a network, which catches SaaS products that might otherwise sidestep GPL requirements.
- Source-available and proprietary-adjacent licences. In recent years, a number of high-profile projects have shifted away from traditional open source licences toward models like the Business Source Licence (BUSL) or the Server Side Public Licence (SSPL). These restrict certain commercial uses, typically cloud providers reselling access to the software as a service. They are not "open source" in the OSI-approved sense, but they are often bundled alongside open source components in real-world projects.
Copyleft and the SaaS question
The AGPL is worth dwelling on because it catches many Australian SaaS developers off guard. Traditional copyleft under the GPL was drafted in an era of software distribution: you gave someone a copy of a binary, which triggered the obligation to share source. SaaS sidesteps this because users interact with the software over a network rather than receiving a copy. The AGPL plugs this gap by treating network delivery as a form of distribution. If your product incorporates AGPL code and users interact with it over the web, you are generally required to make your corresponding source available to them.
This matters practically. MongoDB, Grafana, and a number of other widely used tools have, at various points, used AGPL or SSPL licences to prevent cloud providers from reselling their software without contributing back. Australian teams building on these tools, especially for SaaS delivery, need to audit their obligations carefully before shipping.
Practical compliance for Australian teams
Licence compliance does not require a legal team embedded in every sprint, but it does require a systematic approach. Here is what works in practice:
- Automate licence scanning. Tools like FOSSA, Black Duck, and the open source FOSSology project can scan your dependency trees and flag licences that conflict with your distribution model. Integrating a scanner into your CI/CD pipeline means violations surface before code ships, not during a procurement audit.
- Maintain a software bill of materials (SBOM). An SBOM is a machine-readable inventory of every component in your software and its associated licence. Australian government procurement is increasingly requiring SBOMs from vendors, and the practice is spreading to enterprise buyers. If you are not producing one now, start.
- Define a licence policy. Most engineering teams do not have a formal list of approved and prohibited licences. Drawing one up (with legal sign-off) gives developers a clear decision framework. A common approach is to categorise licences as green (permissive, use freely), yellow (review required, typically weak copyleft), and red (prohibited without explicit approval, typically strong copyleft or AGPL when building commercial products).
- Manage attribution obligations. Even permissive licences like MIT and BSD carry attribution requirements. If you are distributing software, you are typically required to include the original copyright notices and licence texts. Failing to do so is a licence violation even under the most permissive terms.
These compliance practices sit naturally alongside the kind of DevSecOps thinking that Australian teams are increasingly adopting. Embedding legal and security checks into the pipeline, rather than bolting them on at the end, is the operating model that scales. Teams that have already invested in DevSecOps practices are often better positioned to absorb licence compliance tooling without significant process overhead.
Licence compatibility: the hidden complication
Even when your team correctly identifies the licences on individual components, combining them in a single codebase introduces compatibility questions. Not every pair of open source licences is compatible with each other or with commercial licences.
The GPL, for instance, is generally not compatible with the Apache 2.0 licence in the same binary, because the GPL requires all combined work to be distributed under GPL terms, which conflicts with some Apache 2.0 patent termination clauses. The Free Software Foundation and Apache Software Foundation have both published guidance on this, but the practical upshot is that your dependency graph can produce licence conflicts even when every individual component looks fine in isolation.
Automated tools catch some of these conflicts, but not all. For products going to market with significant commercial exposure, a targeted legal review of your SBOM by a lawyer familiar with IP and technology law is worth the investment.
When licences change mid-project
One pattern that has tripped up Australian teams in recent years is the mid-project licence change. A project your team depends on is open source today. Then the maintainer relicences it under something more restrictive, often citing commercial sustainability pressures. HashiCorp's 2023 shift from the Mozilla Public Licence to BUSL for Terraform is the most prominent recent example, triggering a community fork (OpenTofu) and a genuine architectural question for teams relying on Terraform in commercial environments.
The lesson is not to avoid open source, but to treat your key dependencies as risks to monitor. For foundational infrastructure components, understand who controls the licence, what their commercial incentives are, and whether a fork or alternative exists if the terms change unfavourably. Version-pinning and maintaining a clear upgrade policy also give you time to respond when changes happen upstream.
Getting your team aligned
Licence compliance ultimately comes down to culture as much as tooling. Developers need to understand that pulling a dependency is not just a technical decision. It is also a legal one. Regular short briefings, a clear internal policy document, and a low-friction escalation path to legal or a designated licence owner are the organisational basics that most teams still lack.
For Australian businesses bidding on government work, the bar is rising further. Federal and state procurement frameworks are increasingly scrutinising software supply chains, and a credible answer to "what licences does your software use and how do you manage compliance?" is now a differentiator in competitive tenders. Getting ahead of this now, rather than scrambling during a procurement process, is the pragmatic case for investing in open source governance.
Open source is not going away, and nor are the obligations it carries. The teams that treat licence management as part of normal engineering discipline will find it is a modest ongoing effort. Those that ignore it until an audit or a deal surfaces the question will find it is a very expensive one to resolve in a hurry.