The types of software license models in active use today fall into three long-standing camps — proprietary/commercial, permissive open source, and copyleft open source — plus a newer, more contested fourth category: source-available licenses that companies have written specifically to capture open source's community benefits while blocking commercial competitors from reselling the software as a service. Any license software your team depends on falls into one of these four buckets, and knowing which one determines what you're actually allowed to do with it.
What separates proprietary and open source license agreements?
A proprietary software license agreement grants specific, limited rights to use software without providing source code or the right to modify or redistribute it — you're licensing a right to run the software under terms the vendor controls entirely, typically tied to a subscription, per-seat, or perpetual fee. Open source licenses, by contrast, all satisfy the Open Source Definition: source code is available, and users have the right to run, study, modify, and redistribute it, though what obligations come attached to redistribution is exactly where the open source license models diverge sharply from each other. A team evaluating a new dependency needs to know which category a license is in before anything else, because a proprietary EULA and an OSI-approved open source license create completely different sets of practical obligations.
How do permissive and copyleft licenses actually differ?
Permissive licenses — MIT, Apache 2.0, BSD — let you use, modify, and redistribute the code, including in proprietary and commercial products, with minimal obligations beyond preserving the original copyright notice and, for Apache 2.0, a patent grant and NOTICE file requirement. This is why permissive licenses dominate infrastructure and library code that companies want widely adopted with no friction: React (MIT), most of the Apache Software Foundation's projects (Apache 2.0), and countless smaller utility libraries. Copyleft licenses — GPL, LGPL, AGPL — require that modified versions you distribute or, in AGPL's case, host as a network service, be released under the same license with source code available. GPLv3 is the strongest common copyleft license for direct distribution; LGPL relaxes the requirement so that dynamically linking a proprietary application against an LGPL library doesn't force the whole application to be GPL-licensed, which is why LGPL is common for libraries meant to be embedded in commercial software.
What's a source-available license, and why do companies keep writing new ones?
A source-available license lets you view and often modify the source code, but restricts specific commercial uses — most commonly, offering the software as a competing hosted service. The Business Source License (BSL), used by companies like MariaDB and HashiCorp for parts of their portfolios, typically converts to a fully open license (often Apache 2.0 or MPL) after a fixed number of years, giving companies a temporary competitive moat while still promising eventual full openness. The Server Side Public License (SSPL), which MongoDB adopted in 2018, took a harder line: it requires anyone offering the software as a service to open source the entire service stack around it, a condition strict enough that the Open Source Initiative has not approved SSPL as meeting the Open Source Definition. These licenses exist because large cloud providers had been taking permissively or weakly-copyleft-licensed open source projects and reselling them as managed services without contributing meaningfully back, and the original maintainers wanted a legal mechanism to capture more of that commercial value themselves.
How does this map onto subscription and perpetual commercial licensing?
Commercial software licensing has its own separate axis — how you pay, not what rights you get — running from perpetual licenses (one-time payment, ongoing right to use a specific version, often with a separate maintenance/support contract) to subscription or SaaS licensing (recurring payment tied to continued access, typical of nearly all modern enterprise software and cloud platforms). This axis is largely independent of the open-source-versus-proprietary question above: a proprietary software license agreement can be sold either way, and increasingly even open-core companies sell subscription access to hosted or enterprise-tier versions of otherwise open source cores. When you're evaluating vendor risk, both axes matter — the open-source-vs-proprietary axis tells you what rights you actually have to the software, and the perpetual-vs-subscription axis tells you what happens to your access if you stop paying.
How Safeguard Helps
Safeguard's license scanning classifies every dependency in your SBOM against its actual license terms — permissive, copyleft, or source-available — and flags policy violations like an AGPL or SSPL component appearing in a codebase your organization ships as a hosted product. That turns a manual license-agreement reading exercise into an automated gate that runs on every build. See the SCA product page for how license compliance scanning works alongside vulnerability detection.
FAQ
Is there a quick software license comparison to work from?
Yes: proprietary licenses give you a right to use, nothing more; permissive open source lets you do almost anything including relicensing as proprietary; copyleft open source requires derivative works to stay open; and source-available sits in between, open to read and modify but restricted for commercial hosting. Match your use case to that spectrum before reading any single license's full text.
What are the main types of software license agreements a business should know?
Proprietary EULAs, permissive open source (MIT, Apache, BSD), copyleft open source (GPL, LGPL, AGPL), and source-available licenses (BSL, SSPL) are the four categories that cover the overwhelming majority of software you'll encounter, whether you're licensing a vendor's product or pulling in a dependency.
Is source-available the same as open source?
No. Source-available licenses let you view and sometimes modify source code, but they restrict specific uses (most often commercial hosting) in ways that don't meet the Open Source Definition, and licenses like SSPL are explicitly not OSI-approved.
Which license model is safest for a commercial product to depend on?
Permissive licenses (MIT, Apache 2.0, BSD) carry the fewest downstream obligations for a commercial product. Copyleft and source-available licenses aren't necessarily unsafe, but they require a specific legal review of how your product uses and distributes the dependency.
Do software license models affect vendor lock-in risk?
Yes — subscription-based proprietary licensing generally carries higher lock-in risk since access ends when payment stops, while open source licenses (of any type) guarantee you retain a usable copy of the code regardless of what happens to the original vendor or maintainer.