The funny thing to me, which I haven't seen anyone else mention yet, is that way, way back in the old days, Grafana started out as a fork of Kibana. Go take a look at the first commit in the Grafana source:
<a href="https://github.com/grafana/grafana/commit/75d03fc49ab4f95ee414f730563f14cbdad9ee64" rel="nofollow">https://github.com/grafana/grafana/commit/75d03fc49ab4f95ee4...</a><p>Anyone want to guess what the third commit was? That's right, it was an Apache 2 license:
<a href="https://github.com/grafana/grafana/commits/master?after=2bb7eb18d1c06b20db63d9e0a9aeca3a8adbb97a+28900&branch=master" rel="nofollow">https://github.com/grafana/grafana/commits/master?after=2bb7...</a><p>Before there was any code, there was a permissive license. If the choice had been made 8 years ago to make Kibana less-permissively licensed, it's very likely Grafana wouldn't exist right now.<p>And for historical fun, here's the first commit from Torkel after the fork from Kibana v3:
<a href="https://github.com/grafana/grafana/commit/50e42c8bdd2099552dbc3e7a46f429d501f401ae" rel="nofollow">https://github.com/grafana/grafana/commit/50e42c8bdd2099552d...</a>
I applaud this decision.<p>I would like to see <i>all</i> major SaaSS projects be AGPLv3. End users still have freedom to user, modify, and distribute the software. Cloud providers must share contributions.<p>This is how I like it.
I don't want to weigh in here with a huge value judgement on whether this is the right decision. However, I do want to say that what they're saying regarding SSPL vs AGPL is totally right. One of the biggest sticking points with SSPL is that it's not even really <i>plausibly</i> open source, and it tries to create restrictions that implicate software that is not even "linked" with the program that is licensed under it, which calls into question whether it's even legally enforceable.[1]<p>AGPL is somewhat controversial, but the reasoning for AGPL to exist is chiefly to protect the end user's rights, however misguided that may be in your opinion. In this case Grafana presumably retains the copyright to these programs, so presumably they are not beholden to these restrictions in any way. On the other hand, though, it does mean that other providers will have to distribute their patches back to the community, which is pretty much the entire goal of copyleft open source in the first place.<p>In any case, this is, in my opinion, a lot better than SSPL or the Timescale license.<p>[1]: <a href="https://www.processmechanics.com/2018/10/18/the-server-side-public-license-is-flawed/" rel="nofollow">https://www.processmechanics.com/2018/10/18/the-server-side-...</a><p>edit: wording regarding AGPL was changed, because the claim that considering AGPL as not open source is “somewhat controversial” isn’t quite accurate; it’s more correct to say the license itself is simply controversial.
Why there's a prevailing hate against xGPL licenses? Almost all of the core infrastructure which runs this Apache/BSD/MIT licensed software is running on xGPL software.<p>I believe that we wouldn't be here without these aggressive copyleft licenses, and some developers embracing this license again is a good thing. I'll always prefer Nextcloud because it's AGPL. Similarly I'll use Grafana with less hesitation since it'll be AGPL from now on.<p>Being able to see everything inside a software and not binned as community/enterprise is better from my point of view. I'd happily pay for AGPL software, and I already pay a lot of money for licenses so, it's not <i>about money</i>.
Even though we use Grafana only internally and there would be no problem with AGPLv3 in theory I see big meetings with legal coming up which might result in us not being able to use it anymore.<p>I could image that its the same with other corporations. In the end that might hurt the popularity of Grafana quite a lot.
There's a lot of weird assumptions in this thread that this is some sort of strike against Amazon/AWS. It's not. AWS's managed grafana is built in partnership with grafana labs, and this license change won't affect it.<p>From Grafana:<p>"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."<p><a href="https://grafana.com/blog/2021/04/20/qa-with-our-ceo-on-relicensing/" rel="nofollow">https://grafana.com/blog/2021/04/20/qa-with-our-ceo-on-relic...</a>
What I don't like about changes like this is that it makes it impossible to reuse any Grafana/Loki/Tempo pieces or libraries in any more permissively-licensed code without forcing that whole project into the AGPL as well. That doesn't only hinder competitors (which seems to be the legitimate goal), but also hinders interoperability and an open ecosystem evolving where people freely exchange bits and pieces of code to make things work together. I know that some parts of the codebases have been exempted from these changes (see <a href="https://twitter.com/TwitchiH/status/1384566382180896769" rel="nofollow">https://twitter.com/TwitchiH/status/1384566382180896769</a>), but those are only some, and they may change over time...
Looks like there were two blog posts. This QA session with the CEO is also interesting.
<a href="https://grafana.com/blog/2021/04/20/qa-with-our-ceo-on-relicensing/" rel="nofollow">https://grafana.com/blog/2021/04/20/qa-with-our-ceo-on-relic...</a>
If I contribute a code under the new CLA, is Grafana Labs allowed to relicense that contribution under a non-copyleft license, like Apache Public License 2.0, without my further permission?<p>If yes, than it's a really bad bad thing and I hope they change it.<p>CLAs that permit relicensing for a project that already uses permissive license is fine and fair. But doing that on a project with a copyleft license is a bad taste. It would enable Grafana Labs to give Grafana to a party X which can then give it to party Y, where X isn't required to give all the necessary freedoms to Y.<p><a href="https://opensource.com/article/19/2/cla-problems" rel="nofollow">https://opensource.com/article/19/2/cla-problems</a><p><a href="https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/" rel="nofollow">https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/</a>
Grafana: The analytics platform for all your metrics. Allows you to query, visualize, alert on and understand your metrics no matter where they are stored. Create, explore, and share dashboards with your team and foster a data driven culture.<p>Loki: Web Analytics Dashboard for NGINX<p>Tempo: An open source, easy-to-use and high-scale distributed tracing backend. Tempo is cost-efficient, requiring only object storage to operate, and is deeply integrated with Grafana, Prometheus, and Loki. Tempo can be used with any of the open source tracing protocols, including Jaeger, Zipkin, and OpenTelemetry.
I'm not surprised with this, seeing their aggressive push to cloud service. I'd say this is the route of popular OSS projects that became SaaS services:<p>1. Fork something Apache-licensed.<p>2. Build a community with "awesome" buzz.<p>3. Start a company, promising bells, and whistles.<p>4. Hire more and more people because bugs are piling up.<p>5. Now we need VC to fund all of that.<p>6. VCs are in charge now; they require "growth" and more paying customers.<p>7. Start using dark patterns. On the download page, hide the actual package download, redirect users to paying cloud or paying software version.<p>8. More frequent releases, more drastic redesigns, and changes. VCs need to see where the money goes.<p>9. VCs are still not happy. The company is spending more and more... relicense everything and force users to pay for the product.<p>Mongo, Elastic, now Grafana... TBH I don't have a problem with *GPL, but let's be honest: they are luring users and companies with permissive licenses, promising "forever" stupidities, then suddenly and silently change the rules. The funniest thing is that most of these projects started on something with apache license...
Hmm. Where does Grafana people stand on what constitutes a "derivative" work? Are my Grafana dashboards derivatives of Grafana, and must now be published? If I embed a Grafana dashboard in my application, is my application now a derivative of Grafana and must be released as AGPLv3?
All of the most important software of our lifetime is going through this relicensing effort as the creators attempt to capture the value of what it enables. This is not some nefarious plan to screw over the community. It's a very measured and thoughtful way to ensure the long term progress and continuity of these projects. If the core companies maintaining them did not do this they would eventually die and these projects would slowly rot. Hopefully over time rather than having everyone choose their own licenses we end up with some form of standardisation.
The announcement seems to say that products that include an unmodified version grafana can still be proprietary, and only modifications to grafana itself will have to be published.<p>However, the AGPL itself is quite clear that if you distribute a larger work based on an AGPL software, the whole larger work has to be distributed under the same license.<p>Would you still be confident shipping a proprietary product that includes a grafana dashboard ?
Okay, so they go out of their way to avoid answering how this actually affects people, so I'll ask here: If a company uses grafana internally, this should have no effect, right? And then the next step: If a company did offer grafana-based dashboards to customers but wasn't actually modifying grafana, what if anything does this do?
When we released our server product under GNU AGPL v3 license, we have received a rather negative reaction from other participants in our field.<p>The general sentiment was, "this license makes a useless curiosity".<p>I wonder where does this hostility come from. Jealosy? FUD? Frustration that they can't take the source and not share own improvements??
Is it still possible to integrate Grafana in your product or does the whole thing have to be AGPL. No complaints. Just curious. Like, can I distribute some SaaS that has a Dashboard section that is Grafana-powered while retaining my code?
What is the biggest fork of Granafa I can use that is non-share-alike?<p>Edited:<p>Oh, I can't say this... I leave it up for posterity and a note to myself then.<p><a href="http://www.paulgraham.com/say.html" rel="nofollow">http://www.paulgraham.com/say.html</a>
Is there some exception for plugins? I can see a weird situation where a plugin for technology 'X' doesn't allow AGPL, but Grafana requires it.
Note that the AGPLv3 has an exception allowing you to link to GPLv3. GPLv3 allows for private use, in other words keeping changes secret as long as they stay on your own computer.<p>In effect, it becomes a weak copyleft- akin to MPL-2.0 where as long as you keep it in separate files code can stay closed-source.
1) We distribute Grafana as docker container along with our product to customers. What is the impact for us and our customers?
2) We build Grafana on a platform which is not supported by out of the box. What is the impact for us and our customers?
I like the AGPL, but I would like an extra step that forces you to distribute code even you have not modified it. This would be in the case of the original being unavailable for some reason.<p>Does anyone know how difficult it would be to have the login page for a web app be a different license? The idea being that the only users of the AGPL code are ones that have a valid account. Off the top of my head a reverse proxy, with a completely separate auth app would do the trick, but would be a bit of a pain.
"Amazon Announces Grafana Fork , Promises Amazing Things for the Community" (2021/05/08) [1]<p>On a more serious note: there is a bit of a trend in the licensing world. Mongo or ElasticSearch changes, or cool new projects like redpanda [2] launching with BSL.<p>Open source is still a very young business model. One that has provided a tremendous amount of value over the past decades, but we still need to figure out how to build sustainable businesses with it. Be it open core, more restrictive licenses, copyleft, dual licensing, ...<p>I just really hope that we don't slide back into the world of proprietary closed source. The danger is certainly there, and it will hit smaller companies the most.<p>[1] <a href="https://aws.amazon.com/grafana/" rel="nofollow">https://aws.amazon.com/grafana/</a><p>[2] <a href="https://github.com/vectorizedio/redpanda" rel="nofollow">https://github.com/vectorizedio/redpanda</a>
I look forward to a future AGPL, perhaps Absolutist AGPL.<p>Licencing your code under AAGPL extinguishes your own copyright as the author -- you now only have the same rights as someone triggering the code or a derived work. Triggering is any action which causes the code to run without human intervention.<p>The AAGPL will finally remove the possibility of crippled 'Community Edition' software.
I can see why they would relicense Grafana this way, but why Loki? It's a fairly immature product that needs the boost of a less restrictive license IMO. I'm worried this will harm the adoption of it compared to the ES ecosystem (OpenSearch in particular) and we won't see it used for anything beyond Grafana.
Seems like a sensible choice - one of the things that as cause me to look askance at some of the anti-serverisation (urgh) licenses has been companies trying to bespoke something when the AGPL has always been right there to solve the problem they're trying to tackle.
I think this is a step in the wrong direction.<p>Open source is about an open community, open contributions, the multiplier you get from contributions from multiple companies. That way open source is a win-win. Companies benefit from each other's contributions.<p>Once you have free and non-free tiers or need restrictive licensing it is already broken. The incentives no longer align.<p>I'm being paid in part to work on the open source projects that we utilize for our service(s). Some of those we started, some of those we're contributing to, but we _own_ none of them. We handed them off to external entities (Apache and others) for governance and we actively encourage others to participate.
And, yes, some of those are used by Amazon, and we welcome their contributions to the code.<p>Single support companies that use the popularity and reach of permissive licenses for profit that then turn around and bemoan the fact that their licenses are too permissive are disingenuous.
I wonder how many companies will choose to kill off Grafana use as a result of this change. Two companies I've worked for have simply banned the use of anything having a GPL type license.
I am writing a datasource for my product, so that data can be rendered in Grafana. I distribute my product to customer. Do I need to open source my datasource code as well?
I remember when the AGPL was being talked about in around 2008 or so, and thinking it was ludicrous. Now I wonder if it's too lenient. AWS is just rebranding open source products and selling access for infinite markups while killing the open economy that created them.<p>Maybe what we need is a 'no AWS' license, think Apache License but with a clause that says no corporation with more than $50B in revenue can resell it.
RIP grafana<p>^^ this is not a good contribution to HN, not much substance. (edit)<p>Many people who use Grafana will see this news and will stop planning on using Grafana and start planning on doing something else. That has nothing to do with Grafana, that is a common reaction to AGPL.<p>In theory, AGPL is fine under circumstances blahblahblah. In common practice in commercial settings (in my experience), GPL is poison and AGPL is radioactive poison.
Good. If Amazon wants to continue its creep of using open source software to build their empire they need to support the companies that make open source software.<p>> If Amazon/AWS was not a large monopoly it wouldn't be a problem.<p>DOJ Needs to split up AWS/Amazon and fine them and use that fine to create competition.
One of the reasons why I find it hard to contribute to projects that use CLA. Now you don't have any say in this relicensing even when contributed reasonable amount of code.
Those who have reservations about the terms of AGPLv3 - would any of you prefer if it was licensed under BUSL1.1 (i.e., source-available or eventually-open-source) instead? I'm curious to see the perspectives of businesses as to whether AGPLv3 or BUSL-1.1 is a "bigger risk" when compared to the previous Apache 2.0 license.<p>My gut feeling is that those passionate about open source on the whole will tend to prefer AGPLv3, while businesses or those making decisions on the behalf of a business, may prefer BUSL-1.1. I think there are trade offs with either approach.