Is AGPLv3 or MPLv2 better for an open-source API meant to be integrated into closed-source customer APIs?

Question

Description:

• This open-source code is an API (let's call it X-API), which is meant to be used by businesses running their own closed-source APIs

The goal:

• Let other companies/individuals interact with X-API internally without having to disclose their own code (interact via server requests like GET, POST, etc)

• But also prevent competitors from building on top of (or extending) X-API without open-sourcing their own code

• Be able to potentially license to Enterprise clients in the future to sustain product development

Questions:

1. Is there any reason to prefer MPLv2 over AGPLv3?
2. Is my understanding correct: if the users only use X-API internally via its server endpoints, then they don't have to open-source any of their proprietary code, right?
3. Is there a specific reason Hashicorp has stuck with MPLv2 throughout their repos?

Answer 1

AGPL is probably not a great idea. Whilst I agree that interaction with the covered code via the (fully-documented) X-API is likely to insulate the interacting code from the full requirements of AGPL (and other strong copyleft licences) many companies are (rightly or wrongly) particularly suspicious of AGPL code, and forbid its internal use.

MPL is a per-file copyleft licence without the remote-user-interaction language of the AGPL (eg, s13 of AGPLv3), so likely to be more successful for the purpose. That said, it is in my opinion one of the less-well-understood free licences, and you may experience some pushback on that basis.

If it were me, I'd go for GPL with an explicit API exception (along the lines of the linux kernel's syscall exception) that makes it clear that use of your code via X-API does not create a derived work. That's a well-understood mechanism that puts goal one front-and-centre (where potential business users can see it) whilst also achieving goal two. Goal three is also easy provided you remain the sole rightsholder, or require a CLA from contributors that explicitly permits commercial relicensing.

Is there a specific reason Hashicorp has stuck with MPLv2 throughout their repos?

I'm not aware of one, though as a developer of popular code, once you've picked a licence it can be quite difficult to change it. You'd really have to ask them.

Answer 2

MPL2 is a weak copyleft license that applies at file-level only i.e. only to your library files. It's a great license for the purpose that you have described. Your users can statically or dynamically link to your library with no issues.

If you use MPL2 without Appendix B, your competitors will be able to relicense it under LGPLv2.1 and circumvent the patent retaliation clause of MPL2. On the other hand, without Appendix B, software licensed under LGPLv2.1 and GPLv2 will be able to use your library without license incompatibilities.

AGPL, like GPL (without exception), is not suitable as it forces your users to release all of their source code, and not just extensions to your library. AGPL also has the remote-user-interaction clauses.

The other two suitable licenses are LGPLv2.1 and LGPLv3. Users would normally only dynamically link to LGPL-licensed libraries.

LGPLv3 is overall better than LGPLv2.1, including for unusual linking methods (e.g. C++ template header-only projects), patent grant, patent retaliation etc. but it has the tivoization clause which some companies avoid.

If you're concerned about LGPLv3's tivoization clause, you can add on the LGPLv3 linking exception, which waives the requirement of Installation Information (section 4e). With this exception, your users can also statically or dynamically link to your library with no issues.

---

If users interact with your software API only via sockets (inter-process communication), then you can simply use GPLv2 or GPLv3 too.

The viral effects of GPL only applies to static and dynamic linking. It doesn't apply to communication via sockets/ IPC.

GPLv3 also has the tivoization clause, same as LGPLv3.