search

mojaloop / design-authority-project

This is the Issue and Decision Log for tracking mojaloop and related Designs
1 stars 2 forks source link

Grafana changing license to AGPL 3 #77

Closed adrianhopebailie closed 2 years ago

adrianhopebailie commented 3 years ago

Request Summary:

Analyse impact of the license change that Grafana have made from Apache 2.0 to AGPL

Request Details:

Grafana Labs have changed the license for Grafana from Apache 2.0 to AGPL: https://grafana.com/blog/2021/04/20/grafana-loki-tempo-relicensing-to-agplv3/

This license is not compatible with the Mojaloop licensing requirements for dependencies.

Accountability:

Decision(s):

- **Approved By:** ### Details - [ ] Actual decision made as a result of discussion ## **Follow-up**: - [ ] Actions to implement the decisions
mdebarros commented 3 years ago

https://grafana.com/blog/2021/04/20/qa-with-our-ceo-on-relicensing/

I am of the opinion that the license change will not impact our usage of Grafana. I believe it will only be an issue if we modify Grafan’s code, which will trigger the “network” part of the AGPL license.

godfreykutumela commented 3 years ago

I agree with @mdebarros. There are 3 conditions on which this can impact us:

  1. If you provide a competing service to Grafana - Grafana as a service to our customers
  2. If we modify the source code of Grafana. And if we do it only affects the part we changed not the entire code but anyway our code is public. Also, you only publish the code if someone requests it.
  3. If we provide a Gradana based solution as a public service via a public cloud or private.

In our case, we are using Grafana as an internal system so it is fully allowed as per AGPL conditions.

henrka commented 3 years ago

I would recommend to have someone with more legal expertise in the area of software licenses to have a look at this. Modification can be interpreted in different ways, see for example https://opensource.stackexchange.com/a/6904, but this depends on how strict Grafana Labs wants to be.

Also, based on https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL, would not the license of Mojaloop have to be changed to a GPL license as it would use the GPLed library? See also excerpt from https://www.apache.org/licenses/GPL-compatibility.html:

However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.

henrka commented 3 years ago

Additionally regarding the license incompatibility, see excerpt from https://github.com/mojaloop/mojaloop/blob/master/contribute/License.md:

Mojaloop code is created with the intention that it could be released using an Apache 2.0. To make this possible, all dependent libraries and tools must have a license that conforms to Apache 2.0. Submissions that do not meet this will be rejected.

millerabel commented 3 years ago

Thanks Henrik for providing the excerpts. When we organized the open source project, we identified this incompatibility between Apache 2.0 and the GPL family of licenses and so the use of GPL’d libraries in Mojaloop contributions is not permitted. As these libraries are sometimes imported at a very deep dependency, within our module tree, it has been a constant challenge to find and remove the dependencies. And, when a major platform switches license to a GPL family license, we must switch to something else or we place the project in jeopardy. We established the no-GPL principle to protect the commercial uses of the platform and to remove uncertainty for adopters.

— Miller

Miller Abel @.***

On Apr 28, 2021, at 2:27 AM, Henrik Karlsson @.***> wrote:

Additionally regarding the license incompatibility, see excerpt from https://github.com/mojaloop/mojaloop/blob/master/contribute/License.md https://github.com/mojaloop/mojaloop/blob/master/contribute/License.md:

Mojaloop code is created with the intention that it could be released using an Apache 2.0. To make this possible, all dependent libraries and tools must have a license that conforms to Apache 2.0. Submissions that do not meet this will be rejected.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mojaloop/design-authority/issues/77#issuecomment-828303846, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6OJ6GZX5CQAJC3R3RAULTTK7II7ANCNFSM43VHJG6A.

henrka commented 3 years ago

Thanks Miller, that is consistent with my view from commercial usage.

A related potential issue with the current license in https://github.com/mojaloop/mojaloop/blob/master/contribute/License.md is for Elasticsearch and Kibana. These are, starting from version 7.11, dual licensed under the Elastic License and Server Side Public License instead of Apache 2.0. As far as I know, Mojaloop is in some way using both Elasticsearch and Kibana in some way. Maybe this has already been discussed elsewhere..

mdebarros commented 3 years ago

I would recommend to have someone with more legal expertise in the area of software licenses to have a look at this. Modification can be interpreted in different ways, see for example https://opensource.stackexchange.com/a/6904, but this depends on how strict Grafana Labs wants to be.

Also, based on https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL, would not the license of Mojaloop have to be changed to a GPL license as it would use the GPLed library? See also excerpt from https://www.apache.org/licenses/GPL-compatibility.html:

However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.

We are not using any libraries for Grafana as we do not directly integrate with Grafana.

Grafana integrates into Prometheus by providing visualization dashboards. Additionally, we use the following client library to expose metrics over standard HTTP which is then scraped by Prometheus --> https://github.com/siimon/prom-client. Note: Both Prometheus and the prom-client library is licensed under Apache 2.0 License.

I believe the above scenario is perfectly acceptable based on my interpretation of https://www.apache.org/licenses/GPL-compatibility.html.

@millerabel FYI.

However, I do agree with @HenkKodde that an expert opinion is needed here.

millerabel commented 3 years ago

Okay, this is excellent. Thanks Miguel for exploring the connections. Indeed, AGPL inherits the GPL's “viral on modification” and “viral on linking” philosophy, and it adds restrictions on service hosting of the stack. This is (according the AGPL authors) an attempt to prevent AWS and Azure from “free riding” by offering paid services powered by open source projects, without sharing revenue with the open source projects. It was created to protect the enterprise/community split that a lot of companies use to offer paid services into market that build beyond the community editions of their stacks.

So, under AGPL, we can’t host the “Grafana stack” for use by others. And if what we build requires the use of the Grafana stack, we must investigate how we link to it (that is, how it’s incorporated into Mojaloop images), and how it would be used by others, particularly in a hosted SaaS context. Ask the question, “if ACME Cloud Corporation hosted Mojaloop, and charged a fee to utilize it, would that be disallowed by the Grafana component license?” And what would the alternative be for a commercial company wanting to offer metrics and visualization?

Is our connection to Prometheus (and so its use of Grafana) permitted under the Apache 2.0 and the inbound licenses used by Prometheus and its dependencies?

If a hosting service provider chose to use something else, do we have clean interfaces (e.g. Open Trace, etc…) that would allow them to replace the Prometheus stack and components?

If we can explain the relationship between Grafana (and the other Elastic components that we depend on, as they are all changing license) and Mojaloop, we can ask the board to provide legal support to help us iterate to a solution.

— Miller

Miller Abel @.***

On May 12, 2021, at 3:47 AM, Miguel de Barros @.***> wrote:

I would recommend to have someone with more legal expertise in the area of software licenses to have a look at this. Modification can be interpreted in different ways, see for example https://opensource.stackexchange.com/a/6904 https://opensource.stackexchange.com/a/6904, but this depends on how strict Grafana Labs wants to be.

Also, based on https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL https://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL, would not the license of Mojaloop have to be changed to a GPL license as it would use the GPLed library? See also excerpt from https://www.apache.org/licenses/GPL-compatibility.html https://www.apache.org/licenses/GPL-compatibility.html:

However, GPLv3 software cannot be included in Apache projects. The licenses are incompatible in one direction only, and it is a result of ASF's licensing philosophy and the GPLv3 authors' interpretation of copyright law.

We are not using any library for Grafana as we do not directly integrate with Grafana.

Grafana integrates into Prometheus by providing visualization dashboards. However, we use the following client library to expose metrics (which are scrapped by Prometheus) --> https://github.com/siimon/prom-client https://github.com/siimon/prom-client. This client licensed under Apache 2.0. License.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/mojaloop/design-authority/issues/77#issuecomment-839672140, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB6OJ6AOVYQVAV6F6T7ISE3TNJMDRANCNFSM43VHJG6A.