Q&A with Grafana Labs CEO Raj Dutt about our licensing changes
When Grafana Labs CEO and co-founder Raj Dutt announced to the team that the company would be relicensing our core open source projects from Apache 2.0 to AGPLv3, he opened the floor for discussion and encouraged anyone who had further questions to reach out. We believe in honesty and transparency, so we collected hard questions from Grafanistas, and Raj answered them for this public Q&A.
Why was this change made now? Was there a specific trigger we were reacting to?
The time felt right. As I’ve said publicly before, I’ve been thinking about this topic for years. Recent relicensing to SSPL by others increased the amount of queries we received, and we wanted to make a decision and move forward.
Why AGPL specifically? Why not SSPL? If you look at the trend of MongoDB and Elastic, I’m wondering why you didn’t select SSPL.
We believe in open source and are not in the business of trying to redefine what that means.
AGPLv3 is an OSI-approved license that meets all criteria for Free and Open Source Software. SSPL is not OSI-approved.
We considered SSPL and watched community response to the decisions that MongoDB and Elastic made. We really respect their decisions, but we’ve decided that we want to keep Grafana Labs software under OSI-approved licenses, because the support of the open source community is very important to us.
It’s hard to say you’re an open source company when you’re using a license that isn’t accepted by OSI. Being open source is at the core of who we are, and we believe that adopting AGPLv3 allows our community and users to have the same core freedoms of free and open source software that they have enjoyed since our inception.
Does Grafana Labs expect this to impact adoption? AGPL might create red tape around using our projects internally at many companies running services on the internet.
Since AGPL is an OSI-approved license, and there’s a history of pervasive AGPL software already in most companies, we do not expect this to be an issue. However, we will absolutely have conversations with any organization concerned about the implications of this change.
What’s moving to AGPL and what’s not?
Our core projects (Grafana, Grafana Loki, and Grafana Tempo) are moving to AGPL. Plugins, agents, and certain libraries will remain Apache-licensed. You can find information in GitHub about what is being relicensed for Grafana, Loki, and Tempo.
What happens if there are forks of our projects?
Forks are already out there; in fact, Grafana started as a fork of Kibana. It’s important to note that the reason for the fork was that Kibana did not do what Torkel Ödegaard (the creator of Grafana) wanted it to do (time series data), and the Kibana project team had no plans to decouple it from the Elasticsearch backend. Obviously we are biased in our opinion that this type of fork is an example of great open source evolution. Elasticsearch also came out of Lucene — not necessarily a fork, but an implementation on top of Lucene to provide horizontal scalability.
Something many don’t realize is that as open source projects increase adoption, the time and resources needed to support them also increase drastically — in areas like identifying, triaging and fixing bugs, taking in feature requests, fixing security issues, building new features, and ensuring backward compatibility. Most forks are not successful; the majority of the effort behind successful projects is hidden, and it’s the people doing the actual work who have, or need, the context to make long-term decisions.
Having the right to fork a project is part of what open source is about. But that’s not enough for a successful project — you need a community, adoption, brand awareness (e.g., trademarks), and commitment.
A few users and customers ship Grafana as part of a service or as a way to monitor their product, like Red Hat Openshift and Cloud Foundry. Would the AGPL license prevent them from doing that?
Unmodified distributions are not affected. AGPL does not prevent customers from shipping Grafana as long as they follow the terms of the license. In the case of Openshift and CloudFoundry, that source is already open, so there is no issue.
What about cloud providers like AWS? How does this change affect the Amazon Managed Service for Grafana (AMG)?
AWS is a strategic partner, and given the commercial relationship AWS has with us for AMG, AWS and their AMG customers are not impacted by this change. We hope that other XaaS providers follow AWS’s lead in working with open source software companies in similarly sustainable ways.
How does this affect our competitors?
We don’t focus on competitors. We focus on our users and customers. :)
The answer to this question depends on which competitor and which open source project we are talking about. It will be up to them to comply with the terms of the AGPLv3 license, and if we learn of non-compliance, we will pursue those matters accordingly.
Will Grafana Labs give users guidance on how to comply with AGPL? I’m guessing we will have a lot of inquiries.
While we won’t be in a position to provide legal advice, what we are committed to doing is monitoring this change and the various concerns that our users have, and over time, we will continue to provide guidance and clarifications on what can and can’t be done with our software specific to the AGPLv3 license. There are just too many different fact patterns to address those in advance, but we will provide follow-up guidance.
How strict does Grafana Labs intend to be regarding license enforcement?
The vast majority of users will be in compliance with the AGPL licensing from day one. AGPL is actually not hard to comply with. We expect that many of our users will have questions about it, but that they will find it easy to get comfortable with AGPL.
Our strategy is all about carrots, not sticks. While we will enforce our license terms, we fundamentally believe that our best route to building a good business is simple: Make great open source software, take feedback from users/community, help people be successful, earn enough trust that they’ll give us time to explain and educate them on the value of our commercial offerings (Grafana Cloud and Grafana Enterprise Stack). We tried to take a similar approach with Grafana Cloud, too, offering a very robust free tier, so as with the open source, users do not have to commercially engage with us to leverage the full Grafana Stack. Over time, a large percentage of users will still never become commercial customers, but many will.
How does this change relate to the Grafana Labs CLA (Contributor License Agreement)?
Along with relicensing, we are updating our CLA to avoid license incompatibilities. It will be up to each contributor to decide whether they want to continue to contribute under our new terms. However, our new CLA is based on the CLA set forth by The Apache Software Foundation, and as such, we don’t expect it to discourage our community.
Should we be concerned that AGPL is not battle-tested yet?
AGPLv3 has been around for 14 years. In fact, there are many, many popular open source technologies that are AGPL-licensed, and they are leveraged on a daily basis by organizations of all sizes. Here is the Wikipedia list. In any case, one of the reasons so few open source licenses have been tested in court is that there is little doubt that they can be enforced. That may sound counter-intuitive, but people don’t usually fight expensive legal battles when the outcome is predictable.
Will we change the license again?
This is the right decision for our company at this time. We are not planning another change. As the primary copyright holder of our software, Grafana Labs can change the license again within the constraints of the law. We will continue thinking about these topics and following the conversation in the open source community.
We believe our past actions have shown our good faith intentions with the community, and we place tremendous value on the trust that we have earned. We intend to continue to earn that trust.
What should people who can’t use AGPL do?
This depends on the use case they are trying to fulfill. In some cases, we suggest they re-examine the policies set by the organization that determined AGPL was not acceptable. We’ve heard of cases where adoption of AGPL projects grew significantly in organizations (MongoDB for example), and this triggered further evaluations and eventual acceptance of AGPL projects. Barring an internal change of policy, users have some choices.
They can stay with older Apache versions, consider adopting Grafana Cloud, or for those that don’t intend to modify the code, simply use our Enterprise download. This is a free-to-use, proprietary-licensed, compiled binary that matches the features of the AGPL version, and can be upgraded to take advantage of all the commercial features in Grafana Enterprise (Enterprise plugins, advanced security, reporting, support, and more) with the purchase of a license key.
As a final option, for customers who want to modify the AGPL version and distribute or offer it as a service over a network, and also don’t want to be subject to AGPL obligations to make their modifications available, they can relicense the AGPL version under the terms of our paid proprietary license, which meets these needs.
Would we be willing to use AGPL-licensed software we do not hold a CLA privilege for?
At this time, we do not use third-party AGPL software in our commercial offerings. (Ed. note, added for clarity: Our Grafana Enterprise and Grafana Cloud products are offered under a commercial license.) We hope that our move to AGPL drives greater adoption of the AGPL broadly and that it results in more AGPL software that we can derive value from. If we do use AGPL software in our commercial offerings, we will follow the terms of the license.
Will Grafana Labs still backport fixes to the Apache versions of Grafana? How will the backports be licensed?
Security fixes for Grafana are always released for at least the two most recent stable minor versions of the two most recent major versions. Other fixes need to be decided case by case. If fixes are backported to an Apache-licensed version, the fix will also be Apache-licensed.
If Kibana had been an AGPL project, would Grafana even exist? Are we being hypocritical?
I asked Torkel, and he said that If Kibana had been an AGPL project, Grafana would likely have been AGPL from day one.
This is of course a hypothetical question, so it’s difficult to determine how that would have affected subsequent business decisions the company might have made.
Making business decisions to increase the likelihood of commercial success of our company while also supporting the health of our thriving Grafana community on the basis of new information and an evolving situation is not hypocritical.
Do we have an idea of what’s the worst that could happen?
The worst-case scenario is several companies could band together to fork our projects. They could collaborate under an existing foundation or form a new foundation and put major engineering effort around forking Grafana and creating/maintaining an Apache license for it. They could out-innovate us and shift the mass of community to their fork. However, the likelihood of this is very low.
It’s very low partly because this would require either a rebuilding from scratch of an entire community of experts, or “poaching” of several major contributors to Grafana. Our major defense against this is our longstanding relationship with our community and the way we value and take care of our team. We care about our community and respond to their needs and requests.
Also, we plan to maintain our brand and trademarks, for the benefit of both our company and the community. Any fork would have to build its own reputation.
Is Grafana Labs going to offer proprietary Enterprise and Cloud code under a source-available license?
No. While we see the value of source-available proprietary software, we are not offering our proprietary software products under a source-available license at this time.
Wouldn’t it have been easier to do this under the cover of Elastic relicensing?
Sure, but we are not trying to hide our relicensing. We have no reason to. On the contrary, we are striving for the absolute maximum in transparency.
