Different Types of Software Licenses Compared

A feature is ready to ship, but its dependency review turns up a library the team copied into the repository months ago. The first-party code is MIT-licensed; the copied component is GPL-licensed, and the release process has no record of whether the product includes it or how it's linked. That's when a license stops being a label in a repository and becomes a release decision.

A software license controls whether you can run, modify, redistribute, and keep or disclose source code. Choosing MIT or Apache-2.0 for your own code doesn't clear the licenses attached to packages, copied snippets, or generated code elsewhere in the product. The practical question is whether your team can trace each component's terms to the way the software is built and delivered.

What a Software License Decides Before You Ship

Say a team vendors a library to avoid a build dependency, then ships it inside a closed product. The library's license still travels with the code. Its terms can affect what the team must preserve, disclose, or offer to recipients, even if the application's own LICENSE file says MIT.

Think of a license as a grant covering four permissions: run the code, change it, redistribute it, and keep or release its source. A permissive license such as MIT or BSD generally lets a company incorporate code into a closed product, provided it retains required notices. A copyleft license adds reciprocal conditions: the GNU General Public License (GPL), first published in February 1989, established a reusable framework in which distributed derivative works generally had to preserve the same freedoms and provide corresponding source code. The history of the GPL and open-source licensing helps explain why the label “open source” doesn't imply one set of obligations.

Commercial licenses grant narrower rights, often limited by contract terms such as seats, field of use, or redistribution. Source-available terms can expose code while restricting particular uses, such as offering it as a competing service. Those are not automatically open-source licenses: the Open Source Initiative (OSI) uses the Open Source Definition to assess approved licenses, not the mere availability of source code.

The table compares the license families a release review is likely to encounter. It's a starting point, not a clearance decision. The product's obligations can come from transitive dependencies and copied snippets as well as its first-party code.

Use the SPDX identifier, not an informal nickname, in dependency records. SPDX makes license metadata easier to normalize across package inventories, but a machine-readable identifier doesn't resolve whether a particular integration is permitted. If a component is dual-licensed, record the grant the team accepts rather than leaving two possible sets of obligations in the inventory.

For teams evaluating code that ships with an application, the practical guide to open font licensing is a useful example of why license notices and distribution context matter beyond conventional software packages. The next test is more specific: whether patent terms and the architecture's linking boundary change the release decision.

Permissive Copyleft and Proprietary Licenses Compared

The first-party code may use MIT or Apache-2.0 and still fail a release review if a dependency's license conflicts with how the product is distributed. Review the dependency graph and the integration boundaries, not just the license chosen for your own code.

MIT, BSD-2-Clause, BSD-3-Clause, and Apache-2.0 generally permit use, modification, redistribution, and inclusion in proprietary products, subject primarily to preserving copyright and license notices. Their terms are not interchangeable: Apache-2.0 includes an explicit patent license and a termination mechanism, while MIT and BSD licenses take a different approach.

LGPL-2.1, LGPL-3.0, and MPL-2.0 are weak-copyleft licenses. They typically apply obligations to covered components or files while allowing proprietary code to remain closed when the integration meets the license's conditions. For a release review, record how the component is linked, modified, and distributed. A package name alone does not answer whether the boundary holds.

GPL-2.0 and GPL-3.0 are strong-copyleft licenses. When a covered work is conveyed, corresponding-source requirements can apply. Static linking, dynamic linking, plugins, and aggregation each need review against the license terms; don't assume the architecture settles the question by itself. Use SPDX identifiers such as MIT, Apache-2.0, LGPL-3.0, MPL-2.0, GPL-3.0, and BSD-3-Clause in dependency records. The OSI license directory provides license texts and identifiers.

A proprietary EULA or paid SDK grants rights under its contract. Check whether the terms cover the intended users, deployment, and redistribution. Source-available licenses such as BSL, SSPL, and Elastic License 2.0 may allow inspection or use while restricting particular commercial or hosted-service uses. Visible source does not establish permission to ship or host the software.

For other distributed assets, the guide to open font licensing explained shows why notices and the way an asset enters a product belong in the release review too.

Review rule: Record the exact SPDX identifier, version, and selected grant. If the identifier is unknown or the license text is custom, block the merge until the terms receive review.

A dual-licensed package offers two possible grants. Choose and record the grant the team accepts; leaving both options in the inventory leaves the applicable obligations unresolved.

Patent Grants Linking and Commercial Limits

Apache-2.0 is permissive, but its patent terms can matter to a product team deciding whether to accept a dependency. Contributors grant a patent license covering their contributions, and the license includes a termination mechanism if the licensee brings a patent claim alleging that the work or a contribution infringes. A team considering Apache-2.0 should understand both sides of that grant: the patent permission and the condition that can end it.

MIT and BSD-3-Clause are typically silent on patents, while GPL-3.0 includes an explicit patent license. GPL-3.0 also includes anti-tivoization conditions relevant to devices that ship signed binaries, where users may otherwise be unable to install modified versions. Those differences don't make one license universally safer; they make the intended use and distribution method important to the review.

Weak copyleft follows the component boundary

Think of an LGPL library as a room in a building the product team still owns. The team can use the room while keeping the rest of the building closed, provided the boundary conditions hold and the user can replace the library where the license requires it. Dynamic linking and shipping object files for relinking are common ways teams address that replaceability; editing the library's covered files brings those modifications under the LGPL.

MPL-2.0 uses a file-level boundary. A modified MPL-covered file remains under MPL terms, while neighboring proprietary files can remain closed. That boundary is easier to describe than “the whole application is separate,” but the review still needs to identify which files were modified and how they're distributed.

Strong copyleft makes distribution architecture decisive

For GPL-2.0 and GPL-3.0, static linking and many plugin designs may form a combined work, which can trigger corresponding-source obligations when the work is conveyed. Merely placing separate programs together on the same medium doesn't, by itself, make them one combined work. Teams should document whether the parts are independently usable and how they interact rather than rely on folder layout or packaging alone.

Compatibility needs its own check. Apache-2.0 is widely considered incompatible with GPL-2.0, so a GPL-2.0 project that pulls in an Apache-2.0 module needs legal review before shipping the combined work. Likewise, a dual-licensed component should have one accepted grant recorded in the build or compliance record; otherwise, the release team may assume the open grant while the project relies on a commercial one.

A proprietary SDK may restrict redistribution even when the vendor lets a team inspect source under an NDA. Source-available licenses such as BSL, SSPL, and Elastic License 2.0 may allow internal use but prohibit offering a competing hosted service. Before calling a dependency safe, write down the distribution state, the integration boundary, and whether an applicable patent grant exists.

How to Verify a Dependency Graph for Compliance

A release can use MIT for its own code and still carry obligations through a transitive dependency. Review the full graph against how the product is distributed, then make the result part of the pull-request decision.

Use a five-step review:

1. Inventory the graph. Record direct and transitive dependencies with a stable SPDX identifier, version, and any exception or dual-license choice. A free-text name may not distinguish similarly named terms or show what the build includes.

2. Record the distribution state. Mark whether the software stays internal, ships as a binary or mobile app, or runs as a hosted service. The same component can raise different compliance questions in each state.

3. Review license obligations against the integration. For permissive code, check notice retention. For weak copyleft, inspect the file or library boundary and whether covered code was modified. For strong copyleft, check corresponding-source duties and how the component is linked or offered over a network.

4. Check notices in the release artifact. Keep copyright statements, attribution, and required NOTICE text with the artifact. Inspect packaged output, because build and packaging steps can omit files from the source repository.

5. Set the pull-request outcome. Pass when required notices are present and the intended use fits the grant. Send dual-licensed terms or unclear boundaries to legal review. Block the merge when a strong-copyleft or source-available term conflicts with the product's distribution model.

An MIT dependency does not settle the review if a transitive GPL, AGPL, or SSPL package, a missing notice, or an incompatible exception remains in the graph. Software composition analysis tools can connect package discovery to dependency review. The release policy still needs clear pass, legal-review, and merge-blocking outcomes. A guide to open source license audits can help structure the evidence and review trail.

Keep the audit chain concrete: component, SPDX identifier, version, integration boundary, and release artifact. Reviewers need those details to trace a decision to what shipped.

License Choices in Real Products and Dependencies

A product can ship first-party MIT-licensed code and still carry obligations through its dependency graph. License choice matters at the application boundary, but so do the licenses of packages the product incorporates and how the product is distributed.

OSI's 2025 website pageviews show attention to familiar licenses, not how often each appears in deployed products. The OSI history and license pageview figures report these approximate counts:

For a developer tool intended for broad adoption, MIT or BSD permits incorporation into closed products, with notices retained. Apache-2.0 includes a patent grant. A library author seeking reciprocal sharing might choose LGPL, MPL, or GPL; a network service provider may consider AGPL for its terms on hosted modifications. Each choice trades adoption flexibility against conditions that can shape integration and release.

Dependencies make the picture less tidy. OSI reported a marked rise in license count by 2004 and published a License Proliferation report in 2006. In 2023, GitHub added 17.5 million package licenses from ClearlyDefined, extending license coverage across dependency graphs, dependency insights, dependency review, and software bills of materials. License governance therefore needs to cover transitive packages, not just the application's chosen license.

A guide to reusable app code can help teams think about which code belongs in a product. License review still needs to follow the actual components and their terms. In the SBOM, sort non-permissive and unknown identifiers first. That gives reviewers a focused starting point for resolving dependencies that could affect a release.

AI Generated Code and Provenance Review

A developer submits an AI-generated block with no clear origin, and the pull request is ready to merge. Treat substantial generated code like a copied snippet: review its provenance before release. A survey of 574 developers about generative AI, licensing, and copyright found divided views on using open-source code to train models and whether authors should restrict that use through licensing. Organizations also report developers using AI tools outside company policy and scan open-source components and copied snippets for license obligations.

Review is warranted when a suggestion resembles a known copyleft file, includes an attribution comment, or comes from a model whose terms restrict commercial use or condition outputs. The response depends on provenance, similarity, model terms, human contribution, jurisdiction, and whether the team distributes the result.

Keep evidence that supports a review

For non-trivial code, retain the tool and model used, permitted prompt context, and human edits made before merge. Don't keep sensitive prompts against policy just to create an audit trail. Define what evidence developers may record and where it belongs.

Run recognizable output through the same checks used for copied code. If a scanner identifies third-party material, record its SPDX identifier or preserve the required notice. If a match to GPL, AGPL, or a source-available project is plausible, route the change to legal review rather than assuming the model granted permission.

Practical rule: If the developer can't establish provenance or explain a substantial match, require an attestation and hold the merge until the risk is resolved.

Set policy for which cases require review, who decides, and what evidence approval requires. AI coding security guidance can inform those rules, while the licensing decision must account for model terms and the product's distribution.

Put AI provenance in the pull-request gate alongside dependency-license checks. A one-time copyright note won't catch generated code added later or materially changed before release.

Choose a License Policy Your Release Can Defend

A release policy has to fit the way the product is distributed. MIT or BSD-2-Clause permits broad reuse, but offers no explicit patent grant. Apache-2.0 includes an express contributor patent grant and a termination mechanism. MPL-2.0 or LGPL may fit a reusable library intended to remain within a closed product, provided the required component boundaries are maintained.

Choose GPL-3.0 when distributed derivatives should carry corresponding-source obligations, or AGPL-3.0 when the policy extends reciprocal duties to network use. A proprietary EULA fits software sold with limited rights of use. BSL, SSPL, and Elastic License 2.0 are source-available licenses, not open-source licenses.

The first-party license is only one release decision. Obligations also depend on the dependency graph, how components are linked or modified, and whether the product is distributed or offered over a network. Record the accepted SPDX identifiers and the distribution model alongside the architecture. That gives reviewers a concrete basis to check grants, boundaries, and exceptions.

Use Policy-as-Code enforcement for pull requests to make approved license rules actionable at review time. Set each rule to block a merge or require legal review, and retain the decision and its reason. For audit evidence, keep the approved SPDX identifier list, legal-review decisions, and merge outcomes for blocked changes.

Choose the first-party license to match the release model, then make the dependency policy enforceable on the release branch. Choosing MIT or Apache-2.0 for first-party code alone does not establish compliance. The release must account for every relevant component and its obligations.

DevArmor supports continuous threat modeling, security design reviews, and Policy-as-Code enforcement in pull requests, with review outcomes traceable across the software lifecycle. For release controls covering dependency licenses or AI-generated code, see DevArmor.