Source-available software licenses, which have become increasingly popular in recent years, share properties with both open-source and proprietary licenses. At a high level, source-available licenses have three main attributes:
- They make source code available
- They impose some license restrictions
- They’re implemented in a frictionless manner
Source-available licenses are deployed like open-source licenses — and people have a tendency to mistakenly refer to source available as open source — but they’re not the same. This is because source-available licenses put restrictions on the use of the software, while true open-source licenses do not.
In this blog, I’ll discuss in detail the key properties of source-available licenses (and how they compare to open source and proprietary source), highlight examples of popular source-available licenses, and cover strategies for managing IP risks.
Editor’s Note: Heather Meeker is one of the world’s foremost legal experts on open-source software licensing and compliance. She’s authored the go-to book on the topic, “Open Source for Business,” and is a General Partner at OSS Capital. Heather is also the author of the new book, “From Project to Profit: How to Build Your Business Around Your Open Source Project,” now available on Amazon.
Source-Available License Properties
Although there’s no universally held definition for a source-available software license, code availability, the existence of restrictions, and frictionless implementation are common properties. Here’s a brief explanation of each.
Makes Source Code Available
A source-available license means that the source code is available. That’s the most important overarching license property.
Places Restrictions/Limitations
In contrast to open-source licenses, source-available licenses are not unrestricted. They have what licensing lawyers call a field-of-use limitation. (Source-available licenses can also limit the number of users, or impose other limitations, but they usually impose field-of-use limitations.) A field-of-use limitation is an old term in IP licensing. It can refer to, say, a technology area, a market, a geography, or a kind of use.
Implemented in a Frictionless Manner
Similar to open-source licenses, source-available licenses are implemented in a frictionless manner. This is in contrast to traditional end-user licenses, which require you to click to accept.
Source-available licenses very rarely have acceptance mechanisms. You usually download the software and there’s a license included, which is the same experience you’d have with open source.
But while you usually don’t have to click to accept anything, the license grants broad enough rights so that if you don’t accept the terms, you won’t have the right to do what you want to do with the software. That’s the legal theory upon which the frictionless method rests — for both open-source and source-available.
Source Available vs. Open Source and Proprietary
Source-available licenses share some qualities with open-source and proprietary licenses, but there are important differences between them.
Open Source Licenses
The fundamental concept of open source — other than source-code availability, of course — is that it allows the software to be freely used for any purpose. Open source grants all the rights of copyright and it doesn’t impose any restrictions on the use of the software. This means no license restrictions, no field restrictions, no market restrictions, no territory restrictions, and so forth.
It can, however, impose conditions.
Lots of people get confused about the difference between conditions and restrictions, but a condition is: If you do this thing, you have to do this other thing. For instance, if you drive a car, you have to get a driver’s license.
Open-source licenses place a range of conditions on the use of the licensed code. Copyleft licenses like GPL impose significant conditions, like source code sharing, while permissive licenses impose hardly any at all.
Proprietary Licenses
In contrast, proprietary licenses do impose restrictions and limitations. For example, there can be limitations on the number of servers or the number of users. (In the old days, we used to do site licenses and CPU licenses, but those have mostly gone by the wayside.) If you’re licensed for 100 users but you have 200 people using the software, those extra users are not licensed; you’ve violated the license and have potentially engaged in copyright infringement by exceeding the license restrictions.
Other types of proprietary license restrictions may include that you can only use the software for testing purposes or with specific products. Or, there may be a bundling requirement, meaning you can’t use the software on a standalone basis.
Source-Available Licenses
To recap: Like open source, source available makes source code available. And, like open source, these licenses are deployed in a frictionless manner. But unlike open source (and like proprietary terms), they have license restrictions.
Source-Available License Benefits
Software producers often choose to adopt source-available licenses for two primary reasons that seem contradictory but actually aren’t: openness and lack of openness.
Let’s say I'm making a database, I have some code, and I want to sell commercial licenses to it. My customers will not use that software unless I give them the source code. The reality today is that you have to give customers source code because they expect it.
That’s been one of the huge effects of the open-source movement. Twenty years ago, enterprise licenses included binary-only licenses and technology escrows, but those have fallen by the wayside. Now, the commercial expectation is that you give your customers source code so they don’t have worries about business continuity. As such, you have to have a source-code license, and the source-available licenses do that.
Additionally, because source-available licenses are frictionless, they allow people to easily download the software, and you don’t have to sign evaluation licenses. This takes a lot of friction out of the sales process. It allows distribution on platforms like GitHub. At the same time, if properly drafted, source-available licenses have narrowly crafted restrictions that protect the software producer’s business.
A typical source-available restriction is that you can use the software for anything you want — but you can’t set up a competing cloud service using the software. That allows the licensor to protect its cloud business, which is how it’s making money and how it’s funding product development.
Ultimately, making the software available for free (except for restricted use cases) helps with community, and the restrictions help the licensor fund the free aspects. It allows a company to fund development with its commercial business while keeping the source code available.
Source-Available License Examples
A handful of source-available licenses have gained particularly strong adoption. Here’s an overview of several of these popular licenses and their key provisions.
Business Source License
The most popular source-available license is the Business Source License (BSL), which was created by MariaDB. The BSL is an unusual license since it includes a license change feature.
The license change feature says that after a certain amount of time — no more than four years — the license automatically changes to a GPL-compatible open-source license. This is sometimes referred to as embargoed or delayed open source.
The Business Source License also says that you can use the software for non-production uses, although it doesn’t define non-production uses. Because the production use restriction is really broad and not precise enough for most people, BSL licensors tend to write what’s called “additional use grants.” So, for the BSL you’re usually looking at the BSL itself and an additional use grant along with the change license and a change date.
The BSL has gotten a lot of traction, particularly in the crypto area. There’s no particular reason why it’s gained steam in crypto other than the fact that it was adopted by some crypto companies, which generated publicity and popularity in the space.
Recently, a license called the Functional Source License (FSL) was released that updates BSL and narrows down the choices. It also contains a narrower restriction aimed at protecting SaaS businesses.
Elastic License
The Elastic License, which was published by Elastic Search, prohibits the use of the software to provide a managed or hosted service. This type of restriction is very popular in source-available licenses because the companies that release software under these licenses are trying to protect their cloud businesses. The Elastic License allows redistribution freely, so it’s not protecting the distribution business, only the cloud business. That’s a strategic decision.
Another property of the Elastic License is that you can’t disable the license key functionality. This is because Elastic controls some of its paid features by putting them in the software but keeping them turned off unless you pay for them.
Commons Clause License
Commons Clause was an early source-available license that ended up being more of a thought experiment than something a lot of people use. It’s an addendum to an open-source license, and the fact that it’s an addendum has caused some consternation in the open-source world. At a high level, I would describe Commons Clause as a restriction on commercialization, which is similar to the Business Source License.
If Commons Clause is used, the vendor applies a base open-source license plus the Commons Clause addendum. So, if you see software with a base license like Apache 2.0 and Commons Clause on top of it, the end result is that you can’t sell the licensed software.
Polyform Licenses
Polyform is a project I worked on with other lawyers in the open-source space to create a Commons Clause-like menu of choices for source-available licenses. Polyform offers various options like non-commercial, evaluation-only, and even some that are similar to the Elastic License or the BSL.
Managing Source-Available Licensing Risks
There are four primary IP-related considerations when it comes to using source-available software. Here’s my assessment of each.
License Notices
A lot of legal and compliance considerations with source-available licenses are similar to those that come with open-source licenses. This includes license notice requirements.
Those who draft source-available licenses usually try to make them easier to comply with than open-source licenses, such as allowing you to include a URL rather than the whole license text. But it’s the same kind of process — if you distribute a product with one of these elements in it, you need to pass on a license notice.
Complying with Limitations and Restrictions
The main concern with source-available licenses is that you need to make sure you comply with the license restrictions. You would not have that issue with an open-source license.
For example, if a source-available license allows only non-production use, you need to figure out how to maintain that control within your organization. The challenge is that a lot of organizations tell me — I believe correctly — that once you approve software for use within an organization, it gets very hard to control how it’s used within the organization.
This same challenge played out with proprietary software over the past 30 years: vendors developed software management tools that would ensure you didn’t exceed the number of users or servers you were allowed under proprietary licenses. But no such thing really exists for a non-production use restriction.
So, you have to do some human intervention to make sure you have policies and processes in place to ensure continuous compliance with most source-available licenses.
Navigating a Lack of Standardization
Source available licenses aren’t standardized yet, though the industry is converging around a few of them. A great benefit of open source — in addition to the fact that it has no restrictions — is the significant amount of standardization within open-source licenses. There are hundreds of them, but only a handful of open-source licenses have been broadly adopted. So, it’s very easy to make assumptions about the license terms because there are actually so few licenses that people use with any regularity
In contrast, at this point, you’ll have to review the source-available license on an ad-hoc basis just like you would with a proprietary license.
Budgeting for Commercial Use
Source-available licenses are almost always imposed by private companies, usually in a dual-licensing model or some other model where the company wants to make money from the software.
If a company releases software under a source-available license that prohibits commercial use, and you want to use it for commercial purposes, you have to come back to the licensor and negotiate a separate custom license.
That’s a double-edged sword.
On the one hand, if you want to use the software in a way that’s not allowed by the license, then you can probably negotiate an alternate license with the licensor. That isn’t the case with some open-source projects, which often cannot or will not negotiate alternate terms.
On the other hand, the companies that release source-available code are usually conducting enforcement activity because they’re shoring up their rights. So, it’s a little more common to have actual enforcement actions from private companies. Those are not usually lawsuits but rather letters saying, “We understand you’re using this in violation of the license, you need to get the license, and here’s the fee for it.”
As an overarching matter, if you can’t live with the terms of the source-available license, you can solve that problem with money. It might be painful to pay, but at least there is a solution.
Is Source-Available a Threat to Open Source?
Not really. The source-available model is a substitute for proprietary licenses, not open-source licenses. Without this category, vendors would still be using click-to-accept EULAs that don’t provide source code.
Learn More About Source-Available Licensing
This blog is related to a webinar I recently hosted with FOSSA: When “Open Source" Isn’t Open Source. If you’d like more information on source-available software licenses (and dual-licensing models), I’d suggest you consider viewing the on-demand recording. You can do so by clicking this link.
