Everything Is Fine Until It Isn’t: A Primer on Software Licensing

Thousands of software licenses came with your web application.

Whether it’s an internal tool, a customer-facing service, or a contribution to the open source project, code ownership and licensing affect every digital organization. Like many intellectual property-related issues — photography attribution, likenesses, data protection — it’s a task that’s taken for granted until a show-stopping problem appears.

Let’s take a look at the source of concern, the key types of software license categories, and choosing the right path well ahead of delivery.

Compounding Libraries and Licenses

As we’ve touched on previously, the industry standard for new applications pairs pre-built, open-sourced dependencies (think React or D3) with custom code. The benefits fill an article of their own, but taking advantage of these packages pulls a web of copyright considerations into context around ownership. There are two primary questions:

1. Should this new piece of software or bit of code be open or closed source?
2. Do the licenses of included dependencies permit the answer to #1?
3. Can this new code be added to and used within a commercial offering?

Everything packaged into the completed application has a license (even if it doesn’t — more on that later), and those licenses may dictate how the parent application is distributed. The open part of open source doesn’t mean freely usable in proprietary platforms.

Dependencies Beget Dependencies

So, it’s clearly important to keep track of outside code use, but how quickly do licenses pile up?

Really fast.

Take our COVID-19 dashboard. As a small, straightforward application, it uses 19 dependencies. Those dependencies have dependencies, though, causing the final tally ramp up to 43 licenses. And that’s about as tame as it gets; React alone weighs in north of 1,600 dependencies, ensuring that this article’s opening line wasn’t hyperbolic.

Finding the License

It’s (generally) easy to find the license alongside the library’s source code. GitHub’s made the search even easier in recent years, with dedicated features pointing out the permissions, limitations, and even providing further reading. Keeping with React, here’s its relevant licensing information.

React’s choice implies that the 1,600+ dependencies underneath it are also safe to use for proprietary commercial distribution, but there’s reasonable cause for scrutiny:

• The license has no warranty or associated liability if there is a problem
• More than 1,400 different people have committed code to the project

Licensing Missteps and Penalties

So, if things do go wrong and you’re violating a license included somewhere in the code, here’s the brief tour of potential ramifications:

• A cease and desist, where resolution is either removing the offending code or taking the whole application down
• Litigation and/or settlements to continue using the packages in question
• Choosing to relicense your proprietary code as open source and making it freely available

Software represents a significant investment of time and capital, and each of the potential problems from missteps here can sink a project. Pulling React in as an example one last time, concerted pressure was required to force a relicense after Facebook’s initial pass included clauses that made patent litigation a danger.

License Categories Worth Knowing

As far as intellectual property and software licensing go, here are the types you’ll run across (or choose to use) more often than not.

No License

Simply put: If the code in question doesn’t have a license, don’t use it. Many take the absence of defined permissions to mean free use, but that was cleared up back in 1988. No license reserves all rights with the author(s) and blocks all non-explicitly given use by others.

Copyright and Closed Source

Just like no license (but more forthright), copyrighted work is generally unable to be changed, copied, or distributed. If you’re building an application around some proprietary knowledge, there’s a good chance that you’ll land here for the final product.

Permissive

Many of the libraries, frameworks, and packages that make up the modern web — especially in the JavaScript realm — use permissive licenses. Generally speaking, these licenses:

• Allow for use, modification, and distribution in commercial and noncommercial contexts
• Leave the possibility open for the platform containing it to use a different license
• Mandate that the copyright and license notices be preserved
• Limit liability and do not provide a warranty on the contents

Examples of Permissive Licenses

• Apache License 2.0
• MIT License
• Berkeley Software Distribution

In the Wild

Virtually every JavaScript framework (React, Vue, Angular, Ember, Svelte, etc.), Swift, Kubernetes, Babel, and countless other packages use permissive licenses.

Copyleft

While carrying a lot of the same ideas and allowances as permissive, copyleft takes it a step further in dictating distribution and licensing for the new piece of parent software. These licenses are often referred to as being “infectious”:

• Code containing copyleft dependencies (generally) must use the same license
• The source code for the parent application should also be freely available

Examples of Copyleft Licenses

• GNU General Public License v3.0
• GNU Lesser General Public License v3.0
• Mozilla Public License 2.0

In the case of the latter two, the requirement to inherit the existing copyleft choice is a bit more complex. You can release the parent software under a different license and choose to leave it closed source, as long as you’re only interfacing with the copyleft library. Copying portions of the code or modifying it, though, would necessitate use of the existing license.

In the Wild

GNU/Linux and the WordPress ecosystem (themes and plugins, too) are torchbearers for these sorts of licenses.

Public Domain

It’s relatively uncommon compared to the other types we’ve covered, but code can also be released into the public domain. Here, the software becomes usable in any context, condition-free.

Examples of Public Domain Licenses

• The Unlicense

In the Wild

Household names in this category are harder to find, but a sizable list of projects exist in the public domain.

Picking a License

The code you’re producing — or working with a firm to produce — will need a license, too.

Choosing a Path

Picking the right one is a bit of a flowchart moment. If the resulting software product is a core business offering or contains a bunch of intellectual property, you’ll want to retain rights. As we’ve covered, that means ensuring that everything underneath it allows for that decision to be made without potential future ramifications.

If your organization doesn’t have a policy in place for licensing decisions, it’s worth a discussion. Google, for instance, has clearly laid out forbidden patches.

Consider Open Source

Should the end result be destined for an open-sourced project, the community may already dictate needs on the licensing side of things. Freely sharing code in a business setting isn’t always in the cards, but it can be immensely valuable. If you’re considering the option, GitHub has a great guide for taking the plunge.

Licensing Due Diligence

Licensing is one of those funny topics where everything’s fine until it isn’t, and the problems that arise are never small.

It’s more-or-less unheard of in modern development to generate every line of code in a project from scratch. As we’ve seen, dependencies snowball quickly as new features are fleshed out. Ultimately, we’re left with a menagerie of licenses before any code is put into a production environment.

To avoid the woes of litigation, takedowns, and settlements, teams need to take the potential issues seriously and move forward with vigilance. Just like accessibility, performance, and responsiveness, intellectual property rights are a vital todo throughout the build.