How can I judge the "strength" of a licence?

Question

A quote from the FOSSA blog, How to Apply a License to Your Open Source Software Project:

In a nutshell, if your dependencies are distributed under open source licenses different than the one you are using for your own library, the resulting obligations on your users, from a legal perspective, are going to be determined by the strongest license across all of your dependencies, and their dependencies, and so on.

Given that I know the licences of all the dependencies (and their dependencies, ad nauseam) of my project, how do I determine which licence is the "strongest"?

For example, the summary of all the licences involved in project I'm working on is (generated with licence-checker):

├─ MIT: 284
├─ ISC: 33
├─ CC0-1.0: 29
├─ BSD-2-Clause: 17
├─ Apache-2.0: 7
├─ BSD-3-Clause: 5
├─ (MIT OR CC0-1.0): 4
├─ Python-2.0: 1
├─ CC-BY-4.0: 1
├─ CC-BY-3.0: 1
└─ 0BSD: 1

How can I determine which licences I'm able to use?

There are bonus brownie points for a tip on a toll which can sort licences according to their "strength".

Answer 1

Speaking about “strength” is a simplification. Recipients must comply with all the licenses of all the components that are part of the program, and you cannot choose a license that makes compliance with licenses of the other components impossible.

You might have seen license compatibility diagrams like the following:

The Free-Libre / Open Source Software (FLOSS) License Slide by David A. Wheeler is licensed under CC-BY-SA-3.0.

To the left are “weaker” licenses, to the right we have “stronger” licenses. The compliance obligations for the program as the whole are determined by the “strongest” components. It is worth noting that some licenses are not connected by arrows, meaning that combining these licenses is not possible. For example, it is not possible to have a GPL-2.0-only and an Apache-2.0 component in the same program.

The license list you have shown can be categorized as follows:

• public domain dedications (CC0): these impose absolutely no compliance obligations and are compatible with everything
• permissive licenses (MIT, ISC, BSD-2-clause, BSD-3-clause, Python-2.0, 0BSD): these just require attribution, and are therefore highly compatible with everything.
  • BSD-3-clause also prevents you from using the author's name for promotional purposes, but you probably wouldn't have that right anyway
  • Python-2.0 is an amalgamation of multiple licenses over Python's history, but can be treated as a typical permissive license
• Creative Commons Attribution licenses (CC-BY-3.0, CC-BY-4.0): these are essentially permissive licenses, similar to MIT or BSD
• Apache-2.0: also a permissive license, but with added clauses about patents that make it incompatible with some other licenses, notably with GPL-2.0-only.

All of these are essentially permissive licenses. For your own components, you can choose whatever license you want, including keeping your software proprietary, except that you cannot choose the GPL-2.0-only license for your components as this would be incompatible with the Apache-2.0 component.

Note that you can also choose “weaker” licenses for your own components, but this will not affect the effective license obligations for the program as a whole.

Regardless of what licensing you choose for your components and for the software as a whole, you will have to comply with all license conditions from all the licenses. This generally involves providing a copy of the license notices from all components to the recipients of the program. For the Apache-2.0 license, you would also be required to provide a copy of the NOTICE file, if present. How to provide these notices depends on the context of your program. Maybe the notices should be provided in documentation alongside the software, maybe the software should have some interactive feature that displays these notices. For example, many mobile apps have an entry for Open Source notices in their settings screen.

Answer 2

There's no simple answer to this I'm afraid; licenses are just too complicated for there to be a single linear metric you can use to "rank" them.

The only way to do this is to read each license, understand what the requirements to do under that license and follow those requirements. The licenses you've listed are generally what are considered permissive licenses which don't require much more than:

• Include a copy of the license
• Reproduce any copyright notices from the dependency

but you must read the licenses yourself.

As for which license you can use, permissive licenses generally don't restrict the license you can choose for your work so you are free to release your own code under any license you like - this is in contrast to copyleft licenses like the GNU GPL family which do force you to use a specific license (or one from a set of licenses).