8 Types of Open Source Licenses: Obligations Compared

A license choice is an architecture decision, not a legal label added after the code ships. The obligation may begin when you distribute a binary, link a library, modify a file, expose software through a network service, or trigger a patent clause. Two components can both be called “open source” while creating very different release and compliance work.

The practical split matters. Open Source Initiative's license overview distinguishes permissive, weak copyleft, and strong copyleft models, but the useful engineering question is more specific: what action triggers the obligation, and where does that action occur in your product?

This list compares the major types of open source licenses using that vocabulary. Each entry connects the license family to an engineering decision, so developers can describe the integration accurately and legal reviewers can assess the same facts. If a product team is preparing a distribution model, patent review, or licensing policy, specialist advice such as trademark licensing attorneys South Florida may also be appropriate.

1. Permissive Licenses

Permissive licenses make redistribution the main compliance trigger. MIT, BSD, and Apache 2.0 generally let companies use, modify, and redistribute code inside proprietary products without releasing derivative work under the same open-source license. The engineering question is where your team distributes the component, such as in source form, a binary, a container image, or a bundled application.

“Permissive” means limited conditions, not zero conditions. An MIT dependency still requires its copyright and permission notices. BSD variants may add attribution or endorsement conditions. Apache 2.0 adds an express patent license and patent retaliation provisions, so patent review can matter more than the short list of redistribution requirements.

GitHub's analysis of licensed repositories in 2015 found MIT in 44.69% of projects, followed by GPLv2 at 12.96%, Apache at 11.19%, GPLv3 at 8.88%, and BSD 3-Clause at 4.53%. About 15% used a non-standard license or a standard license outside the analysis's main list, according to GitHub's license usage analysis.

The engineering decision

Choose MIT or BSD when the priority is broad adoption and simple commercial integration. Choose Apache 2.0 when contributor patent rights and retaliation terms need explicit treatment, particularly in a patent-sensitive product.

React, Rails, Node.js, Django, NumPy, nginx, Kubernetes, Docker, and Apache Spark show how permissive licenses support reuse across products. The license does not establish your security controls or governance process. It sets the notices, grants, attribution terms, and redistribution controls your team must preserve.

Practical rule: Treat every permissive dependency as a notice-management task. “Permissive” does not mean “ignore it.”

For a security platform, Apache 2.0 can suit reusable policy engines or threat-modeling components. MIT may fit small utilities and integration code. Teams considering an MIT license for crypto projects should document attribution, patent exposure, and the exact components being released.

2. Permissive Licenses With Patent Clauses

Apache 2.0 adds patent protection to a permissive reuse model. It grants recipients a license to relevant patent claims contributed to the code and includes patent retaliation. The trigger is broader than redistribution. If a recipient brings a patent claim alleging that covered technology infringes, the patent grant can terminate for that recipient.

EPL and CDDL also address patents, but their patent terms sit alongside reciprocal obligations. The review therefore starts with the obligation trigger, then examines which files or components must carry reciprocal terms, how linking affects scope, and whether the license is compatible with the rest of the product. A shared reference to patents does not make these licenses interchangeable.

Apache 2.0 dates from January 2004. GPLv1 appeared in 1989, GPLv2 followed in June 1991, and GPLv3 was released in 2007. These version dates provide useful context when a team inherits an older dependency, because the applicable license version can change compatibility analysis and patent treatment.

Patent review is an integration decision

For a threat-modeling engine or policy-as-code component, record more than the SPDX identifier. Capture the contributor patent grant, retaliation language, required notices, and the integration form: source, binary, container image, or hosted functionality. The engineering decision is whether the dependency will be shipped, linked, modified, or kept behind a service boundary.

Apache 2.0 covers projects including Kubernetes, Docker, Kafka, and Spark. EPL 2.0 is associated with Eclipse software, while CDDL appears in projects such as OpenSolaris, OpenIndiana, and illumos. These examples show how patent-aware licenses support infrastructure and enterprise software, while leaving product-specific obligations for the review team to resolve.

• Map contributor rights: Confirm which patent grants cover the code received and whether later contributions use the same license.
• Separate code and data: A software patent grant does not settle rights in threat intelligence, documentation, or policy content.
• Record uncertainty: Static linking, generated code, or a combined work can create scope questions. Preserve those questions for counsel instead of creating a shortcut.

A contributor agreement can clarify ownership and contributor representations, but it does not replace license analysis. The engineering record should identify the dependency, explain how it is integrated, state whether it is redistributed, and document which patent event could terminate or narrow the grant.

3. Permissive Licenses With Community Standards

ISC, 0BSD, and the Unlicense reduce legal friction further, but they aren't interchangeable in every governance program. ISC is a short permissive license with conditions broadly familiar to teams that already manage MIT-style notices. 0BSD is designed to impose very few conditions. The Unlicense attempts to dedicate work to the public domain, subject to the limits of the relevant jurisdiction.

The trigger in this group is usually the act of copying or redistributing the material, but the compliance burden is intentionally light. That makes these licenses useful for examples, test fixtures, small utilities, educational code, and sample data. It doesn't make them automatically suitable for the core of a security product.

Use simplicity where the risk is bounded

A sample policy definition can benefit from a license that lets customers copy, adapt, and include it without a complex approval path. A threat-model template can be published under a public-domain-style dedication when the publisher wants community reuse to take priority over attribution tracking.

Core policy evaluation logic is different. Security-critical algorithms, enforcement code, and regulated compliance artifacts may require clearer ownership, contribution controls, warranty disclaimers, and provenance records. A near-zero-friction license can make those controls harder to explain during procurement or audit.

A practical split looks like this:

• Examples and tutorials: ISC or Unlicense can reduce barriers for readers who want to copy the material.
• Test data and fixtures: Use a simple license when the data has clear provenance and contains no restricted third-party material.
• Core security logic: Prefer a license with explicit terms that contributors, customers, and auditors can identify.
• Compliance mappings: Separate code rights from data rights, and document whether the mapping is an authoritative requirement or a reference artifact.

Don't describe public-domain-style material as “unlicensed.” A repository without a clear license can leave recipients without permission to use, modify, or redistribute the code. The label should match the legal instrument attached to the files.

4. Weak Copyleft and Library Licenses

Weak copyleft licenses try to preserve openness at a component boundary without automatically placing the entire consuming application under the same license. LGPL, MPL, and EUPL are common examples, but their triggers differ. LGPL analysis often turns on linking and the ability to replace or modify the covered library. MPL generally focuses on the file boundary, while EUPL has its own compatibility and reciprocal terms.

That boundary is an engineering fact, not a diagramming preference. A dynamically linked library, statically linked library, plugin, generated file, and copied code fragment may create different questions. A legal reviewer needs the build method, not only the dependency name.

MPL 2.0 is used by Firefox and Thunderbird. LGPL is associated with projects such as GNOME and GTK. EUPL appears in software developed for European public-sector contexts. These examples don't provide a shortcut for your product, but they show why teams should distinguish library-level, file-level, and broader derivative-work obligations.

Keep the boundary real

Suppose a proprietary application links to an LGPL library. The team should preserve the library's notices, identify any modifications to the library, and confirm that users can exercise the rights the license requires. If a team copies the library's code into proprietary files or statically links it in a way that changes the analysis, the original “it's just a library” assumption may no longer be sufficient.

MPL can be easier to audit when the repository marks covered files clearly. That advantage disappears when developers mix MPL code into larger files without tracking the resulting modifications.

For teams developing security libraries, weak copyleft can offer a useful compromise:

• Open the component: Community members can inspect and improve the library under reciprocal terms.
• Protect the application boundary: Proprietary policy definitions or user interfaces may remain separately licensed, subject to the license's exact conditions.
• Document the build: Record static versus dynamic linking, plugin loading, generated code, and distribution format.
• Review sector requirements: Teams working under the EU Cyber Resilience Act guide should connect license records to the broader product security evidence trail.

A weak-copyleft choice works only when the architecture preserves the boundary the license assumes.

5. Copyleft Licenses

Copyleft licenses make reciprocity the central design goal. GPL permits use, modification, and distribution, but distributing covered software or derivative works can trigger source and licensing obligations. GPLv2 and GPLv3 are historically influential, yet the version matters. GPLv3 contains provisions that differ from GPLv2, including its treatment of patents and other distribution conditions.

AGPL extends the analysis to network use. A service provider that modifies and offers AGPL-covered software over a network may face source-sharing obligations that a standard GPL distribution analysis doesn't capture in the same way. LGPL is often discussed alongside GPL, but it is a weaker copyleft model and should not be treated as equivalent.

A historical study of license usage found restrictive licenses represented at least 70% of usage through 2011, except in 2008, when the share was about 67%. The study also observed that GPLv2 remained widely adopted after GPLv3 became available, as documented in the empirical license study.

Decide whether reciprocity is part of the product

GPL is a reasonable fit when the project wants improvements to remain available to recipients of distributed versions. It can be a poor fit when a company plans to embed the component in a proprietary appliance, distribute a closed binary, or combine it with code whose owners won't accept reciprocal licensing.

AGPL can prevent a hosted fork from remaining entirely closed, but that strategic benefit can conflict with enterprise procurement rules. Many organizations require a specific review for AGPL dependencies because the network-service trigger reaches beyond traditional shipment workflows.

Use a decision record that answers:

• What is distributed: Identify source, binaries, installers, images, firmware, and appliance updates.
• What is combined: Describe linking, copied code, plugins, generated output, and inter-process communication.
• Who receives it: Separate internal use, customer distribution, partner delivery, and public release.
• What is hosted: State whether users interact with a modified covered work through a network.
• Which version applies: Record GPLv2, GPLv3, AGPLv3, LGPL, and any “or later” language.

For dependency review, software composition analysis can help teams connect component identity with license data before a pull request becomes a release problem. Automation doesn't decide derivative-work questions, but it can keep the inventory current.

6. Server-Side Public License and Anti-Cloud Licenses

SSPL and similar source-available licenses respond to a specific commercial concern: a provider can host software as a service without distributing the software in the traditional sense. Their trigger is network use or service operation, not merely delivery of a binary to a customer.

That change has major architectural consequences. Under SSPL-style terms, a team offering the software as a service may need to disclose a much broader set of service code, including surrounding management and infrastructure components, depending on the license language. BSL and Elastic License take different approaches, often restricting defined commercial uses or delaying broader permissions.

These licenses also create a classification problem. Not every source-available license is an open-source license under the Open Source Definition. A product team should state that distinction precisely in procurement documents, repository metadata, and marketing material.

Protecting cloud revenue can narrow adoption

MongoDB's SSPL change, Redis licensing changes, Elasticsearch and Kibana's licensing change, and HashiCorp's use of BSL are widely discussed examples of projects moving away from earlier permissive models. The business rationale may be understandable, but customers still have to assess whether the license fits their procurement, hosting, and redistribution plans.

For a threat-modeling-as-a-service product, ask direct questions:

• Is the service modified: If not, the network trigger may still matter under the chosen terms.
• Who operates it: Distinguish the licensor, customer, managed service provider, and cloud platform.
• What code surrounds it: Inventory orchestration, management, monitoring, and service-layer code.
• Can customers self-host: Confirm whether the license permits the deployment model customers expect.
• Is the license open source: Don't promise open-source rights when the text grants source availability under additional restrictions.

A BSL conversion clause can create a future licensing path, but teams must verify the exact change date, permitted use, and restrictions in the license text. Don't assume a general “converts later” statement gives customers present-day Apache 2.0 rights.

7. Business-Friendly Dual Licensing

Dual licensing offers the same software under an open-source license and a separate commercial license. The trigger depends on the path the recipient chooses. An open-source user inherits the obligations of that license. A commercial customer receives the rights, guarantees, support, or integration permissions defined in the commercial agreement.

This model is not a license family by itself. It's a product and governance strategy layered over license texts. The vendor must manage copyright ownership, contributor rights, version control, and the boundary between open and commercial features.

Qt demonstrates an open-source and commercial licensing model. GitLab has community and enterprise offerings, while other vendors have combined open components with proprietary editions or commercial services. The examples differ materially, so copying a competitor's structure without reviewing its terms is risky.

Put the commercial boundary in the architecture

A security company might release a threat-modeling library under Apache 2.0 or LGPL while reserving advanced integrations, hosted controls, and enterprise support for a commercial offering. That can work if the repository, build artifacts, and documentation make the boundary clear.

The model becomes difficult when proprietary features depend on copyleft code. A commercial agreement can't automatically erase obligations owed to third-party licensors. The dependency graph still governs what can be distributed and under which terms.

A workable dual-licensing program needs:

• Contributor control: Use a contributor agreement or another ownership process that supports future licensing decisions.
• Feature separation: Keep commercial integrations in identifiable modules with clean dependency boundaries.
• Customer clarity: Explain what rights apply to the community edition and what the commercial agreement adds.
• Release discipline: Tag source, binaries, notices, and commercial artifacts consistently.
• License compatibility: Review every dependency before it enters either distribution track.

Teams evaluating what is a licensing contract should distinguish a copyright license from a broader commercial agreement. Support, indemnity, warranties, service levels, and usage rights may sit outside the open-source license and need their own review.

Dual licensing creates flexibility only when ownership, dependencies, and product boundaries are controlled from the start.

8. Compliance and Governance-Specific Licenses

Code and security data don't always need the same licensing treatment. An execution engine is software. A threat library, policy definition, compliance mapping, or template is a separate artifact with different reuse and attribution concerns. AGPL can address network-service reciprocity for code, while CC0 or PDDL-style approaches may suit data that an organization wants to make broadly reusable.

The trigger for data artifacts is often copying, adapting, and redistributing the data, not linking. Teams should also verify that they have the rights to dedicate the material in the first place. A public repository can contain third-party content, jurisdiction-specific text, or data with restrictions that the repository owner can't waive.

Separate the artifact types

A practical governance model might release execution code under Apache 2.0, publish reusable threat-model templates under CC0 or a public-domain dedication, and keep customer-specific architecture records under contractual confidentiality terms. Those choices must be documented separately. “The project is open source” isn't precise enough for an auditor or customer.

For regulated environments, license records should sit beside provenance and review evidence. A team preparing ISO 27001 framework documentation may need to show who approved a policy definition, which source informed it, and whether the organization treats it as guidance or as a binding control.

Use explicit labels for:

• Execution code: Record the software license, version, notices, and modification obligations.
• Threat-model templates: State whether recipients may copy and adapt them without attribution or under specified conditions.
• Policy definitions: Identify whether the file is code, configuration, documentation, or a mixed work.
• Compliance mappings: Add a disclaimer that the mapping is a reference and must be adapted to the organization's architecture and obligations.
• Threat intelligence: Track provenance, third-party terms, and whether the data can be redistributed.

AGPL may suit a project that wants hosted modifications returned to the community, but it can conflict with a commercial SaaS strategy. CC0 or PDDL-style treatment may maximize reuse for reference data, but it doesn't provide the same control over accuracy, endorsement, or downstream interpretation.

8-Point Open Source License Comparison

Choosing a License Without Surprises

Start with the trigger, not the label. Ask whether your product distributes source or binaries, links or copies a dependency, exposes modified software through a network service, or enters a patent-sensitive field. Then identify the exact license version, exceptions, notices, and compatibility terms. A permissive license may still require attribution and patent handling. A copyleft license may create source and same-license obligations when you distribute a combined work. A network-focused license may apply a different analysis to hosted use.

Next, map the dependency graph before merging code. Record direct and transitive dependencies, SPDX identifiers, license exceptions, generated code, vendored files, containers, plugins, and build outputs. Package-ecosystem research found MIT and Apache-2.0 together exceeded 70% of usage across the examined package-management platforms and surpassed 85% in RubyGems and Cargo, as reported in the large-scale package licensing study. That prevalence makes permissive dependencies common, not automatically compliant.

The same study found that 90.52% of observed multi-license changes combined MIT and Apache-2.0. This is useful operationally because automated tooling should recognize common dual-license patterns without treating every multi-license declaration as an anomaly. Your policy still needs to define which combinations are acceptable for direct dependencies, transitive dependencies, and distributed artifacts.

Store the decision beside the design artifact. A useful record includes:

• Dependency and version: Identify the exact component and release.
• Integration method: Describe linking, copying, plugins, generated code, containers, or separate processes.
• Distribution channel: State whether the component reaches customers, partners, devices, or only internal systems.
• Network exposure: Record whether users access a modified work as a service.
• Required actions: List notices, source offers, file disclosures, patent records, and license propagation.
• Open questions: Send derivative-work, compatibility, or jurisdiction-specific uncertainty to counsel.

For DevArmor users, the same discipline can connect open-source license decisions with threat models, design reviews, pull-request policies, and implementation evidence. License choice shouldn't live in a spreadsheet that loses contact with the architecture. Keep it in the audit trail where engineering and legal teams can review the dependency, integration method, distribution path, and decision together.

A license is successful when the team can explain what it permits, what triggers an obligation, and who owns the next action. Choose the simplest model that supports the product strategy, but don't simplify away the facts that determine compliance.

DevArmor connects software composition analysis and license checks with continuous threat modeling, security design reviews, and Policy-as-Code enforcement across the delivery lifecycle. Visit DevArmor to keep license-sensitive dependencies, design decisions, and pull-request controls connected in one living security context.