Dual license or relicense when the new license is more permissive?

Question

An organization is considering changing the license of an OSS repo on GitHub. For the purposes of this question, assume that organization has the legal rights to change the license.

It is currently licensed under MPL 2.0, and we need the extra freedom of Apache 2.0.

One proposal is to dual license the code (assuming all contributors agree) as "MPL 2 || Apache 2.0".

I have suggested simply relicensing as Apache 2.0 and dropping MPL 2

I see no value in the proposed dual license, as I would expect most people to opt for the Apache license terms.

Can anyone see an advantage to dual licensing MPL/Apache vs simply relicensing?

Answer 1

Can anyone see an advantage to dual licensing MPL/Apache vs simply relicensing?

If anything, some actual users may feel strongly about the MPL.

Also the MPL 2.0 offers compatibility with v2 of the L/GPL family (thanks to the secondary licenses terms) ... while the FSF considers the Apache 2.0 not compatible with these v2 licenses (but compatible with the v3 licenses) .

Answer 2

In general, dual licensing to keep the old license is more friendly to forks and distributors, regardless of the specific licenses involved. A fork of your project may contain changes from many other developers, and the maintainers of that fork may not have the legal right to relicense. Similarly, downstream distributors and other users may prefer to continue using the previous license (which they already comply with) rather than switch to a new license (which may carry legal uncertainty, or at least require a reevaluation of their compliance). As a result, you will find that most open source projects do not drop old licenses unless they are actively causing problems.

Here are some specific examples of this behavior:

• Wikipedia relicensed from GFDL to CC-BY-SA, but retained a dual license for all old content and the vast majority of new content. Wikipedia is not, strictly speaking, an open source project, but the same concerns apply to its licensing.
• Mozilla relicensed its code under MPL/GPL/LGPL (from MPL-only), keeping the MPL in order to continue supporting proprietary downstream reusers. Subsequently, they rewrote the MPL to allow compatibility with the various GNU software licenses without needing a tri-license, but they keep the old license(s) for existing code.
• With the demise of OpenOffice.org, its immediate successors are Apache OpenOffice (which switched the license to Apache 2) and LibreOffice (which kept LGPL 3+ and (somehow) added MPL 2). LibreOffice is widely regarded as the "legitimate" successor, and the Apache version is reportedly having trouble getting code written. Licensing was far from the only problem here, but this arrangement does allow LibreOffice to take code from AOO without permitting the reverse. That may have exacerbated the issue and allowed it to metastasize to the point of nearly if not actually killing off the entire project.