Licensing Defines How Your Software Can Be Used

Software licensing determines who can use your code, how they can use it, and what obligations they have. Choosing the wrong license can limit your business model, expose your proprietary code, or create legal liability. At Nexis Limited, we use open source licenses strategically for public projects while protecting proprietary SaaS code.

Open Source Licenses

Permissive Licenses

Permissive licenses allow nearly unrestricted use, modification, and distribution — including use in proprietary, closed-source products:

  • MIT License: The simplest and most popular. Allows any use with attribution. No restrictions on proprietary use. Most npm packages use MIT.
  • Apache License 2.0: Similar to MIT but includes explicit patent protection. Used by major projects (Kubernetes, Android). Recommended over MIT when patent concerns exist.
  • BSD Licenses (2-clause, 3-clause): Similar to MIT with minor variations. Common in academic and Unix/BSD ecosystem projects.

Copyleft Licenses

Copyleft licenses require that derivative works also be open-sourced under the same or compatible license:

  • GPL (v2, v3): Any software that incorporates GPL code must also be released under GPL. This "viral" property prevents proprietary use. Linux kernel uses GPLv2.
  • LGPL: "Lesser" GPL — allows linking with proprietary software without requiring the proprietary code to be GPL. Used for libraries (glibc).
  • AGPL: Extends GPL to cover network use — if you modify AGPL software and serve it over a network (SaaS), you must release your modifications. Designed to close the "SaaS loophole" in GPL.

Weak Copyleft

MPL 2.0 (Mozilla Public License): Copyleft applies at the file level — modified MPL files must remain open source, but you can combine them with proprietary files in the same project. A practical middle ground between permissive and copyleft.

Proprietary Licensing

Proprietary licenses restrict use, modification, and distribution. The license defines exactly what the customer can do — number of users, servers, or instances. This is the standard model for commercial SaaS products.

  • Per-seat licensing: License cost based on number of users.
  • Per-server licensing: License cost based on number of server instances.
  • Subscription licensing: Time-limited license (monthly/annual) — the dominant SaaS model.

Dual Licensing

Offer the same software under two licenses: an open source license (often AGPL) for community use, and a commercial license for companies that cannot or choose not to comply with the open source terms. This model works for database engines (MySQL, MongoDB), developer tools, and infrastructure software.

License Compliance

Using open source software requires compliance with license terms:

  • Track all open source dependencies and their licenses using tools like FOSSA, Snyk, or license-checker.
  • Ensure license compatibility — some licenses cannot be combined (GPL and proprietary, for example).
  • Include required attribution notices and license texts in your distributed software.
  • Understand the distinction between "use" and "distribution" — using GPL software internally is fine; distributing it requires compliance.

Choosing a License

  • Building a library or tool you want widely adopted → MIT or Apache 2.0
  • Want to ensure derivative works remain open source → GPL
  • Building SaaS and want to prevent competitors from hosting your code → AGPL
  • Want open source community with commercial licensing revenue → Dual licensing (AGPL + commercial)
  • Building proprietary commercial software → Proprietary license

Conclusion

Software licensing is a strategic business decision, not just a legal formality. Choose a license that aligns with your business model, protects your competitive interests, and meets the expectations of your user community. When in doubt, consult a lawyer experienced in software licensing.

Launching a software product? Our team can advise on licensing strategy and open source compliance.