5

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?

| improve this question | |
  • How is the license change relevant to controversial code patches??? – curiousdannii Sep 1 '17 at 6:40
  • Apache lets us unblock the project. We can temporarily bring a fork inside the firewall, apply the code patches, hit our deadlines, and work to resolve the political/legal issues in the background - eventually hoping to push the fork back outside. This really is a weird situation where 99% of the user base of the OSS are legally required to be inside the firewall. – kdopen Sep 1 '17 at 14:16
  • What do you mean by firewall? – curiousdannii Sep 1 '17 at 23:05
  • Legal/Contractual - 5 figure annual fees, named people only. – kdopen Sep 2 '17 at 16:36
  • 1
    I've simplified the question. The existing answer still applies – kdopen Sep 3 '17 at 19:26
6

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) .

| improve this answer | |
3

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.
| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.