Grafana relicensing to AGPLv3 - question on versions

Have just been reading about Grafana’s relicensing from Apache to AGPL. While I’m not thrilled about the move, I suppose it was a matter of “when”, not “if”.

In Raj Dutt’s Q&A on the topic, to the question “What should people who can’t use AGPL do?” part of the answer states “They can stay with older Apache versions”. Can someone confirm what “older” means specifically?

My assumption is that that all existing versions (up to 7.5.4) will remain under the Apache license - substantiated by the fact that grafana/LICENSE at v7.5.4 · grafana/grafana · GitHub is still the Apache license. While AGPL will be used for future releases - given that grafana/LICENSE at master · grafana/grafana · GitHub is AGPL. And that AGPL will not be retroactively applied (if that’s even possible).

Any clarification - presumably from someone on the Grafana Labs team - would be appreciated.

Hey @svetb,

Pinged the teams about this so I can get you clarification. More soon!


So to confirm:

we will be updating our FAQ on license chages with better details about what versions the new license applies to. Standby

Thanks @mattabrams for confirming, that makes sense.

And yes, regarding fixes, the Q&A states

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.

It stands to reason that at some point there will be be AGPL-licensed 7.6.x and 7.7.x versions, at which point 7.5.x will - according to the above logic - stop receiving security fixes. But hopefully there’d be a way to still have these applied to 7.5.x.

[I see you just updated your comment, so the above may seem a somewhat nonsensical musing, but hopefully not totally irrelevant. Either way, thanks for helping clear this up, also in the docs/Q&A]

yes, sorry I had to edit my comment! I was asked to step carefully here and wait until I have a super concrete answer. It’s possible that the license change will only apply to 8+. I will have more clarity soon!

Totally understand. I appreciate this must have been a tricky decision in the first place, and it pays to be careful when setting expectations, especially given the diversity of the community / use cases.

1 Like

exactly. The more accuracy the better with this community! Thanks for your patience

By the way, now that I’ve had the chance to reflect on this a bit more, I thought I’d add some context on our situation and considerations, in case it’s helpful for others in the community.

I’m one of the co-founders of AMMP - a start-up that provides remote monitoring for renewable energy systems, mostly in emerging markets. In other words - I’m pretty sure - we’re not the kind of company that Grafana (Labs) is trying to keep at bay with this license change.

From the start, we’ve been using a slightly modified version of the Grafana codebase for our visualizations and dashboarding engine, as part of a wider SaaS offering. We’re incredibly grateful to the Grafana community - in particular the devs/contributors - for building such a great tool and making it possible to us to use it in this way, for free. And in this context, having Grafana under the Apache license has given us not just freedom, but also peace of mind from a legal perspective.

The change to AGPL in principle complicates things for us. The fact of the matter is that we could open-source under AGPL also, in order to be compliant, but that’s not without its pitfalls. Specifically:

  • We would probably need to “lawyer up”, at least in order to get a qualified opinion as to what the scope of impact of AGPL on our codebase is, i.e. what specifically we would need to re-license on our end.
  • We would need to go through the logistics of open-sourcing our code in a way that’s compliant with the license requirements - some of which will probably again require legal opinion. (meanwhile, the sad fact here is that our codebase is unlikely to be particularly useful to anyone)
  • The AGPL exposure is likely to bring up questions during any technical/legal due diligence processes (e.g. as part of VC fundraising). Not questions we can’t answer, but ones that will take time and effort nonetheless.

Again, none of these are problems that we can’t solve with a bit of elbow grease. But they’re ones that a small company like ours - with a seemingly unending to-do list - could well do without. So for the time being at least we’ll stick with the Apache-licensed codebase, while we figure out what works best for the future.

[I hope the above doesn’t come across as a rant. We, as AMMP, wouldn’t be where we are now if Grafana wasn’t available to us back when we started 3 years ago. I support any measures needed to safeguard the long-term prosperity of the project, and trust the core team to know best. I just wanted to be open about the collateral effects of this change on us - and others too, I assume]


Thanks for the thoughtful writeup Svet. May I ask what type of changes have you made in your Grafana fork?

@daniellee it’s mostly stuff that could be classified as “branding” - color schemes, icons, some minor layout changes, etc. Encompassing the level required to ensure we’re compliant with the trademark policy. But yeah, pretty much all front-end stuff.

If attaining AGPL compliance is as simple as open-sourcing our “modified Grafana”, then that would be fairly trivial. We actually had it as a public github fork originally, and at some point we moved it to a private repo mostly out of convenience.

Beyond that, we would probably need to get clarity on the meaning of the last paragraph of Section 5 of the AGPL, regarding “aggregates” involving AGPL-licensed components. We would need to ensure that the “separate and independent works” clause applies, so that the rest of our platform (API integrations, data pipeline, analytical models, etc) is not affected. That’s where I imagine qualified legal advice would come into play.

Well expressed @svetb. We are doing the same with our own fork, primarily branding. It’s easy enough to place this in a public repo which may be useful for others to learn how to brand their own Grafana but otherwise not that beneficial.

The motivating reason for us is the startup-prohibitive $3500/mo for Enterprise. I presume the purchase of Enterprise removes these licensing obligations.

Speaking about re-branding in particular: Is this already easy enough for you? If you make it easier to re-brand, that would be the perfect upstream contribution: It makes it easier for you to modify & offer the modifications, and everyone else benefits from the same.


Hi @mattabrams,

Was you able to get any additional clarity on the licensing and which versions of Grafana/Loki/Tempo are still under the Apache licensing and if they will eventually fall under the new AGPL license.


Hi @stevejr,

Yes, I can provide some clarity on licensing for Grafana, Loki, and Tempo:


  • Newest version (to date) = 7.5.5
  • Grafana 7.5.5 = Apache2
  • Grafana’s license will change to AGPLv3 with the release of Grafana v.8


  • Newest version (to date) = 2.2.1
  • Version 2.2.1 = Apache2
  • Loki’s license will change to AGPLv3 with the next release


  • Version 0.6.0 = Apache2
  • Version 0.7.0 = AGPLv3

Thank you @mattabrams for the clarification on the licensing.

Will the above be published on the Grafana website, GitHub repos etc as an official statement to users as some may not come to the community forum to check this.

Thanks again.

I think that could be very useful for the community. Right now, you can always read the LICENSE file associated with a specific release. Here is the LICENSE for Loki v.2.2.1.

What is confusing in this transitional moment is that there is a banner above the file about how Loki is shifting to AGPLv3. But if you read the actual contents of that license file, you’ll see that the Apache2 license is still in use.

1 Like