Open-Source Licensing for Software Startups

Almost every modern software startup is built on open-source code, often hundreds of components deep before anyone writes a line of original product. That is a gift: you get battle-tested infrastructure for free. But “free” is not the same as “no strings attached.” Every open-source license is a copyright license, and each one sets conditions. Ignore them and you can end up violating someone’s copyright, breaching an obligation to your own investors, or, in the worst case, being told you must publish the source code you thought was your competitive moat. This guide explains, in plain English, how open source licensing for startups actually works, where the real risks are, and how to stay compliant. For the broader picture of protecting what your company builds, start with our Startup IP pillar.

Permissive vs. copyleft: the two families

Open-source licenses approved by the Open Source Initiative all let you use, study, modify, and share the code. The difference is what they ask in return when you redistribute it.

Permissive licenses ask for very little. The big three are MIT, the BSD licenses, and Apache 2.0.

• MIT is the simplest. You can do almost anything, including putting the code into a closed-source commercial product, as long as you keep the original copyright notice and the license text.
• BSD (in its 2-clause and 3-clause forms) is similar to MIT. The 3-clause version adds that you cannot use the original authors’ names to endorse your product without permission.
• Apache 2.0 is permissive but more detailed. It requires you to preserve notices and pass along any NOTICE file, and it adds something MIT and BSD lack: an explicit patent grant (more on that below).

Copyleft licenses ask for more. The defining idea, championed by the Free Software Foundation, is that freedoms should flow downstream: if you benefit from open code, the people you give your software to should get the same right to the source. The main copyleft licenses are GPL, LGPL, and AGPL.

• GPL (GNU General Public License) is strong copyleft. If you distribute software that incorporates GPL code, you generally must make your entire corresponding source code available under the GPL.
• LGPL (Lesser GPL) is weak copyleft, designed for libraries. You can link an LGPL library into a closed-source program without opening your whole codebase, as long as users can swap in a modified version of the library (typically by dynamic linking). Your changes to the library itself still have to be shared.
• AGPL (Affero GPL) is strong copyleft plus a network clause. It closes the “SaaS loophole”: if users interact with your AGPL-based software over a network, you must offer them the source, even though you never handed them a copy to install.

The copyleft risk to a proprietary product

Here is the part that keeps startup founders up at night, and the reason this distinction matters so much.

With strong copyleft, the obligation to release your source code is triggered by distribution (and for AGPL, by network use). If you build your proprietary product on top of GPL code and then ship that product to customers, the license can require you to publish your own source under the GPL. People sometimes call this the “viral” effect: the copyleft terms spread to the code that combines with the licensed component. The practical result is that the codebase you considered your secret sauce may have to be opened to the world, including to competitors.

This is not theoretical. It is exactly how these licenses are intended to work. The good news is that the risk is manageable once you know it exists:

• It is usually triggered by distribution, not internal use. Using GPL tooling inside your own company, for development or operations, generally does not force you to publish anything, because you are not distributing the combined work to outside users. AGPL is the major exception, because it treats network access by users as the trigger.
• Weak copyleft is much safer for proprietary code. LGPL was built precisely so companies can use a library in a closed product.
• Permissive code carries essentially none of this risk. That is why MIT, BSD, and Apache components dominate commercial stacks.

For a startup, an AGPL or GPL component sitting in the core of a product you distribute or run as a service is a red flag worth a careful look, ideally before you have built a year of work on top of it. This is also one of the issues acquirers and investors scrutinize, which we cover in IP in fundraising and due diligence.

License compatibility and your dependencies

Modern software is a tree of dependencies, and dependencies have dependencies. A single license problem deep in that tree can affect everything above it, because copyleft obligations propagate upward toward the combined work.

A few compatibility realities worth knowing:

• You cannot relicense copyleft code as permissive. You can pull MIT code into a GPL project, but not the reverse. If a GPL component is combined into your product, the combination has to honor the GPL.
• Even permissive licenses are not interchangeable. Apache 2.0 is compatible with GPLv3, but the FSF considers it incompatible with GPLv2, because GPLv2 predates and does not accommodate Apache’s patent terms. Mixing the two in one combined work is a genuine conflict, not a technicality.
• “License compatibility” means: can these terms all be satisfied at once? If two components impose requirements that cannot both be met in the same distributed work, you have an incompatibility, no matter how convenient the code is.

The practical takeaway is that you need visibility into your whole dependency tree, not just the libraries you chose directly. Automated tooling that scans dependencies and flags licenses (often producing a software bill of materials, or SBOM) is the standard way startups keep this under control.

Complying: attribution and notices

Compliance with most permissive licenses is genuinely simple, and most violations are accidental rather than malicious. The recurring failure is stripping notices.

To stay on the right side of the common licenses:

• Preserve copyright notices and license text. MIT and BSD both require that the original copyright line and the license itself travel with the code when you redistribute it, including inside binaries and apps.
• Honor the Apache NOTICE file. Apache 2.0 requires you to include any attribution notices in the project’s NOTICE file when you redistribute. You can add your own notices, but you cannot drop theirs.
• Make required source available for copyleft. If you distribute GPL or LGPL code, you must provide (or offer) the corresponding source, and your modifications to that code, under the same license.
• Watch the AGPL network trigger. If you run AGPL software as part of a service users reach over a network, plan to offer them the source.

A clean approach is to generate a third-party notices file (a “credits” or “open-source attributions” page) as part of every build, so attribution ships automatically rather than depending on someone remembering.

Choosing a license for your own project

If your startup releases its own open-source project, picking a license is a strategy decision, not a formality. Use a recognized OSI-approved license with a standard identifier from the SPDX license list; writing your own license or editing one creates needless friction for everyone.

• Want the widest possible adoption, including by companies building closed products? Choose a permissive license. MIT is the minimalist default. Apache 2.0 is the better choice when patents are in play, because its express patent grant and patent-retaliation clause give users (and you) protection that MIT and BSD do not.
• Want to keep improvements open and prevent others from privatizing your work? Choose copyleft. GPL for applications, LGPL for libraries you want others to link freely, AGPL when you specifically want to require source-sharing from companies who run your code as a hosted service.
• Think about your business model. Many startups release a permissive or open-core project to drive adoption, then monetize hosting, support, or proprietary add-ons. Some deliberately choose AGPL to push commercial users toward a paid commercial license. There is no single right answer, but the license should match the strategy.

Because the choice interacts with your funding, your IP ownership, and your competitive position, it is worth confirming with an attorney licensed in your jurisdiction before you publish.

Open-source compliance checklist

• Inventory every dependency, direct and transitive, and record each component’s license (an SBOM is ideal).
• Flag copyleft early. Identify any GPL, LGPL, or AGPL code, and confirm whether your use triggers source-disclosure obligations.
• Check compatibility across the licenses in any combined work (remember Apache 2.0 vs. GPLv2).
• Preserve all notices. Keep copyright lines, license texts, and Apache NOTICE files in everything you ship.
• Automate attribution by generating a third-party notices file in your build.
• Set a policy for which licenses are pre-approved, which need review, and which are off-limits for product code.
• Re-scan on every release, since dependencies and their licenses change over time.
• Document your decisions so you can answer questions cleanly during fundraising or an acquisition.

For deeper background on how copyright applies to software specifically, see our software copyright analyses.

The bottom line

Open-source code is one of the best deals in software, but it is a contract, not a giveaway. The single most important distinction is permissive versus copyleft: permissive licenses (MIT, BSD, Apache 2.0) let your startup build proprietary products with minimal obligations beyond attribution, while copyleft licenses (GPL, LGPL, AGPL) can require you to open your own source code when you distribute or, with AGPL, serve software built on them. Know what is in your dependency tree, keep your notices intact, and choose your own project’s license to match your strategy, and open source becomes an asset rather than a liability.

This guide is general legal information for educational purposes only and is not legal advice. It does not create an attorney-client relationship. Open-source licenses are interpreted under the law of specific jurisdictions and the facts of your situation. For advice about your startup, consult an attorney licensed in your jurisdiction.