Software Licensing Models: Perpetual, Subscription, and Open Source

Licensing is a commercial and legal topic that lands on engineering teams at awkward moments — during due diligence, a procurement review, or a customer's security questionnaire. A basic grasp prevents expensive surprises.

Commercial models

• Perpetual licence — buy once, use indefinitely, with an optional annual maintenance fee for support and upgrades. Large upfront cost, predictable thereafter.
• Subscription — pay periodically for the right to use, including updates. Lower entry cost, and access ends when payment does.
• Usage-based — priced by transactions, storage, or compute. Aligns cost with value, and makes budgeting harder.
• Open-source with commercial support — free software, paid assurance. Common for infrastructure.

Read the metric carefully

• Named user, concurrent user, or device — these produce very different bills for the same organisation.
• Whether test, development, and disaster recovery environments require licences. Often they do, and it's found during an audit.
• Virtualisation and core-based counting rules, which can multiply costs unexpectedly on modern hardware.
• Audit clauses: most enterprise agreements permit them, and unlicensed use discovered during one is expensive.

Open-source obligations that matter

• Permissive licences (MIT, Apache, BSD) — use freely, including commercially, with attribution. Apache also grants patent rights explicitly, which is why enterprises prefer it.
• Weak copyleft (LGPL, MPL) — modifications to the library itself must be shared; your own application generally need not be.
• Strong copyleft (GPL) — distributing software that incorporates it can require releasing your source under the same terms.
• Network copyleft (AGPL) — extends that obligation to software provided over a network, which catches SaaS products that assumed they weren't distributing anything.
• Source-available licences are not open source, despite appearances, and frequently restrict commercial or hosted use.

Practical steps

• Generate a dependency licence report in your build, and fail on licences your policy prohibits.
• Decide your policy before it's urgent: which licences are acceptable for internal use, and which for distributed products.
• Keep the attribution file accurate and shipped; it's the most commonly missed obligation.
• Get legal advice for copyleft in a distributed product. The engineering answer and the commercial answer are different, and only one of them matters in an acquisition.