Almost every startup runs on open-source software. Your web framework, your database, your deployment tooling, your monitoring stack — somewhere in your codebase, there’s open-source code doing critical work. That’s a good thing. Open source lets early-stage companies build fast without reinventing every wheel.
But open-source software isn’t a free-for-all. Every open-source component you use comes with a licence, and that licence is a legally binding set of conditions. Get it wrong, and you could find yourself forced to release your proprietary source code, facing an infringement claim, or watching a deal fall apart during due diligence.
Here’s what Australian startup founders need to understand about the legal risks of using — and contributing to — open-source projects.
Open-Source Licences Are Real Licences
The starting point is that open-source software is protected by copyright under the Copyright Act 1968 (Cth), just like any other software. The author holds copyright in the code, and the open-source licence grants you permission to use, modify, and distribute it — subject to conditions. If you breach those conditions, the licence terminates and your use becomes copyright infringement.
This isn’t theoretical. Courts around the world have consistently enforced open-source licence terms. In the 2024 German case Hancom v. Free Software Foundation Europe, the court held that a company’s failure to comply with GPL obligations rendered its distribution of the software unlawful. In the United States, the Federal Circuit confirmed in Oracle v. Google (albeit in a fair use context) that software copyright is real and enforceable. Australian courts have not yet heard a major open-source licence enforcement case, but the underlying copyright principles are well established, and there’s no reason to think the result would differ.
Understanding the Licence Spectrum
Open-source licences fall on a spectrum from permissive to copyleft, and where a licence sits on that spectrum determines how much risk it creates for your startup.
Permissive Licences
Licences like the MIT, BSD, and Apache 2.0 licences are broadly permissive. They let you use, modify, and redistribute the code — including in proprietary products — with minimal obligations. Typically, you just need to include the original copyright notice and licence text. The Apache 2.0 licence also includes a patent grant, which gives you some protection against patent claims from contributors.
For most startups, permissive-licensed components are low risk. But “low risk” doesn’t mean “no obligations.” You still need to include the required attribution notices. Failing to do so is technically a licence breach.
Copyleft Licences
This is where the risk escalates. Copyleft licences — most notably the GNU General Public Licence (GPL) family — require that if you distribute a modified version of the software, or in some cases a work that incorporates the software, you must make the source code of the entire combined work available under the same licence.
The practical implication: if your startup ships a product that includes GPL-licensed code, you may be required to release your proprietary source code under the GPL. For a company whose value is built on proprietary technology, this is an existential risk.
The AGPL: The SaaS Trap
The GNU Affero General Public Licence (AGPL) takes copyleft a step further. Under the standard GPL, the source code disclosure obligation is triggered by distribution — shipping copies of the software to users. Many SaaS companies thought they were safe because they never distribute software; users interact with it over a network.
The AGPL closes this loophole. Section 13 requires that if users interact with AGPL-licensed software over a network, you must make the complete source code of the modified program available to those users. For a SaaS startup, incorporating an AGPL-licensed component could mean publishing your entire application’s source code.
Companies like Google have internal policies that prohibit the use of AGPL-licensed code entirely. That’s not paranoia — it’s rational risk management.
The Risks That Actually Bite
1. Contamination of Proprietary Code
The most significant risk is “copyleft contamination” — the scenario where incorporating a copyleft-licensed component into your product triggers an obligation to release your own code under the same licence. The boundaries of what constitutes a “derivative work” or “combined work” under the GPL are not always clear, and the answer can depend on how tightly the open-source component is integrated with your proprietary code.
Static linking is generally accepted as creating a combined work. Dynamic linking is more contested. Using an API to communicate with a separate GPL-licensed process may not trigger the obligation, but there’s no universal rule. The uncertainty itself is a risk.
2. Due Diligence Failures
This is where open-source compliance most commonly becomes a practical problem for startups. When you raise a priced round, pursue an acquisition, or prepare for an IPO, investors and acquirers will conduct technical due diligence — and open-source licence compliance is a standard part of that review.
Tools like Black Duck (Synopsys), FOSSA, and Snyk can scan your codebase and produce a Software Bill of Materials (SBOM), identifying every open-source component and its licence. If that scan reveals undisclosed copyleft obligations, unattributed permissive licences, or components with incompatible licences, it creates problems. At best, you’ll need to remediate the issues under time pressure. At worst, the deal terms change, or the deal falls apart.
The 2023 Synopsys Open Source Security and Risk Analysis report found that 76% of codebases audited contained open-source components with licence conflicts. This isn’t a niche problem.
3. Security Vulnerabilities
Open-source components can introduce security vulnerabilities into your product. The Log4Shell vulnerability in late 2021 demonstrated how a single flaw in a widely-used open-source library could cascade through thousands of organisations. In Australia, obligations under the Privacy Act 1988 (Cth) and the Notifiable Data Breaches scheme mean that a security incident caused by an unpatched open-source dependency isn’t just a technical problem — it’s a legal one.
4. Licence Incompatibility
Not all open-source licences are compatible with each other. If your product incorporates components under two licences with conflicting terms — for example, the Apache 2.0 licence and the GPLv2 (which are incompatible in certain combinations) — you may not be able to lawfully distribute the combined work at all. Tracking licence compatibility across dozens or hundreds of dependencies requires deliberate effort.
Contributing to Open-Source Projects
Many startups contribute code back to open-source projects, whether to build community goodwill, attract developer talent, or improve the tools they rely on. This creates its own legal considerations.
IP assignment and licensing. Before your employees contribute code to an external project, make sure your startup owns the IP in that code (through employment agreements and IP assignment clauses) and that you’ve authorised the contribution. Many open-source projects require contributors to sign a Contributor Licence Agreement (CLA) that grants the project broad rights over contributed code. Review any CLA before signing — you’re granting rights over IP your startup may have created.
Accidental disclosure. Developers contributing to open-source projects can inadvertently include proprietary code, API keys, or internal business logic in their contributions. Once code is published to a public repository, it’s effectively impossible to fully retract. Establish clear internal policies about what can and cannot be contributed.
What Your Startup Should Do
1. Maintain a Software Bill of Materials
Track every open-source component in your codebase, including transitive dependencies (the dependencies of your dependencies). Automated tools like FOSSA, Snyk, or even npm audit and pip-licenses can help. The goal is to know what you’re using and under what terms.
2. Establish an Open-Source Policy
Create an internal policy that defines which licence categories are acceptable (permissive licences are usually fine), which require legal review (weak copyleft like LGPL or MPL), and which are prohibited (AGPL and GPL in proprietary products, unless you understand the implications). Make this part of your engineering onboarding.
3. Automate Compliance Checks
Integrate licence scanning into your CI/CD pipeline. Tools can flag new dependencies with copyleft or problematic licences before they’re merged into your codebase. Catching issues early is orders of magnitude cheaper than remediating them during a funding round.
4. Review Contributor Agreements
If your team contributes to external open-source projects, review the CLAs and contribution terms. If you’re releasing your own open-source project, choose your licence deliberately — it determines what others can do with your code and what obligations flow back to you.
5. Get Advice Before a Transaction
If you’re heading into a funding round, acquisition, or any transaction that involves technical due diligence, get your open-source house in order early. A clean SBOM, a documented open-source policy, and evidence of ongoing compliance monitoring will smooth the process. Discovering copyleft contamination during due diligence is expensive — in time, in deal terms, and sometimes in the deal itself.
The Bottom Line
Open-source software is an enormous advantage for startups. But it comes with legal obligations that can’t be ignored. The licences are enforceable. The risks — to your IP, your fundraising, and your exit — are real. And the fix is straightforward: know what you’re using, understand the terms, and build compliance into your development process from day one.
If you need help reviewing your open-source obligations, drafting an internal open-source policy, or preparing for due diligence, get in touch. We work with Australian startups to manage IP and licensing risk so it doesn’t become a problem when it matters most.
