A Deep Dive Into Dual-Licensed Software

Spencer
Spencer

What is Dual-Licensing?

Dual-licensing (or, sometimes multi-licensing) means that software is released under multiple licenses for different purposes.

One license might grant full usage of sotware to non-commercial use while usage in commercial projects is covered by a second license.

Commonly, GNU's General Public License v3 (GPLv3, for short) licensed software is open sourced. GPLv3 has a key limitation: distribution in another software product requires that code to have the source code available.

Wait, but if it's open source, why doesn't someone just copy it?

If something is dual-licensed and there's open source code out there publicly, what's stopping someone from taking the open source version and releasing it?

This is covered under what's known as "copyleft": if someone created a derivative work, it must also be licensed under the same license and open sourced.

Protip: Licenses like MIT and Apache 2.0 don't include copyleft clauses, and are therefore known as "permissive"

Do my servers count as distribution?

GPL restricts distribution.

If someone incorporates and distributes GPL-licensed software, then that software must also be licensed under GPL and it's source code made available.

But... if you ship it onto your company servers and your customers only access it via a web-based GUI, is that really distribution?

Welcome to the SaaS-loophole. There was a time when all software distribution was done on CDs or at least, mailing physical copies, and GPL covers those no problem.

SaaS changed all that.

Aferro Greater Public License, however, closes up this loophole and specifies that shipping to your servers in a SaaS qualifies as distribution.

(See Heather Meeker, a lawyer specializing in this topic, talk "What is Distribution?")

Common Licenses

The most common is GPLv3.

A few others are the Lesser General Public License (LGPL) and Aferro General Public License (AGPL).

The "Intentional" License Bug

GPL's restrictions only take place when it's incorporated and distributed, so it makes the most sense to cover software components—like packaged dependencies to be incorporated into other software. GPL restrictions don't make as much sense with software intended for usage as is.

(Bash is licensed under GPL, but it's a complete program that most use on it's own.)

JavaScript packages intented to run in the browser make great use cases for dual-licensing under GPL.

JavaScript packages are necessarily incorpoated into a product and distributed.

When does dual-licensing make sense as a monetization model?

Let's start with a negative example.

If your software is intended for use on its own, then it does not really make sense to try to monetize with a commercial license. For instance, bash is popular GPLv3 shell put out by GNU. But, it's not really distributed as part of closed source software.

Is your source-code intended for distribution?

Client-side JavaScript libraries make good use cases:

How to Dual-License Code Under GPLv3 (and profit!)

First, you've got to create software to license. You should create a software package intended to be incorporated and released in another software product.

Let's use the example of a UI Kit for React.

Include the license file in the source of the codebase, and publish publicly on a registry like npm.

You'll need the non-packaged, source code availalbe as well to satisfy GPL, so publish the code on Github or where you like to host your source code.

Anyone can use and distribute your open source UI Kit in their applications as long it's also open source.

But, if someone at a company wants to use it in a closed-source, distributed application, you'll need to provide a way for them to purchase your UI Kit under a separate, commercial license.

You could use a license like the commercial license from polyform to cover usage of your UI Kit.