Software Licensing

4 min read Updated Mon Jun 08 2026 01:02:45 GMT+0000 (Coordinated Universal Time)

A software license is a legal instrument governing use, modification, and distribution of software. The author retains copyright by default; a license grants specific rights to others.

Source being freely available does not imply unrestricted use.

Without a license, software is legally unusable by anyone other than its author, even if publicly hosted.

Why Licenses Matter

  • Define what users and developers may legally do with the software.
  • Protect authors from liability.
  • Determine compatibility when combining components.
  • Govern commercial use and redistribution.
  • Trigger compliance obligations when shipping products.

Proprietary Licenses

Software distributed without source code. Rights are reserved; users may run the software but not inspect, modify, or redistribute it.

Common grant types:

  • Per-seat
    One license per installation or user. Common in enterprise tools (e.g. Microsoft Office, JetBrains IDEs).
  • Subscription
    Time-limited access. Software stops functioning or updates cease when the subscription lapses (e.g. Adobe Creative Cloud).
  • OEM
    Bundled with hardware. License is non-transferable and tied to the device.
  • Trial / Freemium
    Core features free. Advanced features require payment (e.g. Slack, Zoom).
  • SaaS
    Software is never distributed. Access is provided as a hosted service. License governs usage of the service, not a local binary.

Proprietary Workflow

Typical obligations when using a proprietary component:

  • Purchase the appropriate license tier before deployment.
  • Track seat count and renewal dates.
  • Restrict access to licensed users only.
  • Comply with audit rights clauses. Vendors may inspect compliance.
  • Review redistribution terms before shipping the component inside a product.

Open Source Licenses

Source code is published and redistribution is permitted. Two broad categories: copyleft and permissive.

Copyleft Licenses

Require derivative works to carry the same license.

  • GPL (GNU General Public License)
    Any system that incorporates GPL code and is distributed must release its source under GPL. Applies to the entire combined work.
  • LGPL (GNU Lesser GPL)
    Weaker form of GPL. Allows proprietary software to dynamically link to an LGPL library without the proprietary code becoming open source. Static linking still triggers copyleft.
  • AGPL (Affero GPL)
    Extends GPL to network use. A service that runs AGPL code must publish its source even if no binary is distributed. Targets SaaS loopholes.

Examples:

  • Linux kernel (GPL v2)
  • MySQL (GPL; proprietary dual-license also available)
  • MongoDB (AGPL, then relicensed to SSPL)

Permissive Licenses

Allow use in proprietary products without requiring source disclosure.

  • MIT
    Attribution required. No other restrictions. Simplest and most widely used.
  • BSD (Berkeley Standard Distribution)
    Similar to MIT. The 3-clause variant adds a non-endorsement clause: the licensor’s name may not be used to promote derived products.
  • Apache 2.0
    Permissive. Grants an explicit patent license from contributors. Provides protection against patent claims.

Examples:

  • React, Vue (MIT)
  • FreeBSD OS (BSD)
  • Kubernetes, Android (Apache 2.0)

Dual Licensing

A project releases under both an open source license and a commercial license. Open source use is free; proprietary use requires purchasing the commercial license.

Examples: MySQL (GPL + proprietary), Qt (LGPL + commercial).

Open Source Workflow

Obligations when incorporating an open source component:

  • Identify the license before integration.
  • Distribute a copy of the license with the binary.
  • Attribute the author if the license requires it (MIT, BSD, Apache).
  • Publish modified source if using a copyleft license (GPL, AGPL).
  • Do not use the author’s name in promotion if using 3-clause BSD or Apache 2.0.
  • Verify license compatibility before mixing components with different licenses.

License Management

  • Maintain records of all open source components used.
  • Understand license type before use.
  • Track component evolution. License can change between versions.
  • Educate the team on compliance obligations.
  • Maintain auditing systems (FOSSA, Black Duck, Snyk).
  • Participate in the open source community.
Was this helpful?