Anyone want to guess what the third commit was? That's right, it was an Apache 2 license:
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.
And for historical fun, here's the first commit from Torkel after the fork from Kibana v3:
> 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.
IMHO, his answer doesn't address the GP’s point; that the original, permissive license inherited from Kibana arguably enabled the growth & survival of Grafana.
Listen, at the end of the day, it's their legal right to choose the licensing strategy that they think is right for their business, shareholders, employees, customers, peace of mind, etc. I feel like asking if it's hypocritical is a bit of a straw man, though. It's not hypocritical per se - I just feel that it's a bit disingenuous to say "hey, we have this large, successful business to protect" without also openly acknowledging that it may never have existed without the tailwinds of an era where the open source community embraced permissive licenses. Simply dismissing the question as "hypothetical" is what I take issue with.
Also, I see your shiny, new account and feel it's likely that you are really just here to defend Grafana. I get it. I don't think this change is a bad idea, necessarily. I just want some of these licensing shenanigans to be more brutally honest.
Why's that? If Kibana had been AGPL and Grafana had been AGPL from day 1, how would the growth and survival of Grafana have been any different?
Would the same level of community have formed around Grafana?
Would it have received as many contributions and support for new backends?
Would Raj have wanted to acquire Torkel + Grafana for the original Raintank company if it were an AGPL project?
Would they have been able to as successfully build and monetize a Grafana Enterprise product with the requirements of AGPL in place?
It seems naive to argue that none of those would have been impacted by a more restrictive license.
P.S. Hey Todd ;)
Their FAQ even says:
you state this as if it's a settled fact (it isn't).
If you take a Shakespeare novel and replace every word in it with another word, and then remove and add many chapters to it, then shuffle all the pages, is it still a Shakespeare work or even recognizable as being derived from one? I think most would say "no".
In the case of Ship of Theseus, if you replaced every part with a different looking part, removed 30% of the parts entirely and added another 300% parts such that the function was expanded by 1,000%, would anyone recognize it as the same thing?
There has to be _some_ threshold beyond which you cannot reasonably claim the work is derivative.
If version B is modified from version A as a derivative work (therefore licensed as A) and version C is modified from version B as a derivative work of B, then would C not still be licensed same as B, and therefore A?
It seems it depends on how you view the accumulation of differences. If your only comparison is always against version A, then yes, eventually there must be enough accumulation of differences that one could claim a work is no longer derivative. But if you consider all versions between A and yours, then suddenly its just a series of gradual changes, none of which individually cause the work to become non-derivative. The Ship of Theseus parable seems to also fit this latter interpretation more -- it is after all about replacing items one at a time.
I agree with you from a practical legal point though. My argument above seems to imply that there's only been derived work since the first cell split in two. In practice this would be a nightmare; There should be a threshold whereupon a work can qualify on its own merits.
I think that depends. If it was progressively changed to something completely different, then, no.
Let's say in 10 days you replaced 10% of the code, with the same amount of code from a different program by another author. During those 10 days there'd be compilation errors, and thereafter the original work and copyright would be all gone (except for in old revisions in the repo), and the copyright holder of the new program could license it however s/he wanted.
and that is normally _not_ what you wrote:
> the copyright holder [sic!] of the new program could license it however s/he wanted.
However if sole copyright holder - real, not imagined - she sure can license it - or not. Or different another day.
I would like to see all major SaaSS projects be AGPLv3. End users still have freedom to user, modify, and distribute the software. Cloud providers must share contributions.
This is how I like it.
If you want to use AGPL software in your project, you're free to relicense under AGPL.
You might as well describe freedom of movement as power to take someone else's job in another town, or freedom of speech as power to manipulate masses, or freedom to do an abortion as power over the unborn child. Which way the issues are framed says more about the author than the issue.
Software has leverage (one developer, many users at low marginal cost) built-in, but that doesn't make developing non-(A)GPL or even proprietory software a projection of developer's power. Lack of competition is what lets developer's exert power over users, and while copyleft licenses help with that, they're neither required nor sufficient to prevent abuse of power.
At the same time, copyleft doesn't come free (ha), as developers who need to earn a living will choose to work on problems where they can actually extract some profit to compensate for their effort. Not everyone is keen to work for free, or work as much / as hard for free as they would if they could make a living off it. So yes you might get free-er software, but less of it.
Such is the way of the FSF.
> Lack of competition is what lets developer's exert power over users, and while copyleft licenses help with that, they're neither required nor sufficient to prevent abuse of power.
Copyleft/FLOSS alone is a necessary but insufficient measure; I wrote about other measures in a blog post .
TLDR: open platforms/standards-driven and implementation-neutral development, implementation diversity, and simplicity are also necessary. Once all that is accomplished, you have a platform that prevents abuse of power: anyone can use any implementation they want, and implementations are simple enough for community members to fork and maintain. All of this prevents vendors from exerting power over users.
> At the same time, copyleft doesn't come free (ha), as developers who need to earn a living will choose to work on problems where they can actually extract some profit to compensate for their effort. Not everyone is keen to work for free, or work as much / as hard for free as they would if they could make a living off it. So yes you might get free-er software, but less of it.
From the article I linked:
> The key to making money with FLOSS is to make software a commoditized complement of other, more profitable services. 
> Examples of such services include selling support, customization, consulting, training, managed hosting, hardware, and certifications. Plenty of companies use this approach instead of building proprietary software: Red Hat, Collabora, System76, Purism, Canonical, SUSE, Hashicorp, Databricks, and Gradle are some names that come to mind.
> Managed hosting isn't a basket worth all your eggs if giants like AWS can do the same at a lower price. Being the developer can give an edge in areas like customization, support, and training; it doesn't offer as obvious an advantage when it comes to hosting.
In other words, developers should be paid for service rather than copies of software. AGPL makes it hard to sell copies of software, but doesn't stop you from offering any number of services. This makes sense, since labor is a scarce resource while copies of software require artificially-imposed scarcity to directly bring revenue.
Most consumer software doesn't in fact need any auxiliary services. It just needs work put in to actually build it, and that work needs to be paid for.
Props to Red Hat for earning money from enterprise clients. That model only works if you have enterprise customers.
Props to System 76 for selling computers. That model only works if you're selling hardware.
My software doesn't need any services or hardware or other auxiliary bullshit, and I'm not going to invent the need for said bullshit just to satisfy some ideologues.
You're not entitled to tell me what kind of software to write or how to license it. Don't like it, write your own FLOSS version, and outcompete me. Don't want to, or can't sustain yourself that way? Then don't tell me that I should, or that I can. Words are cheap.
That incentive structure is universal though. A builder also doesn't get paid directly to maintain his toolset, that cost is included in how he charges for his services. A hospital doesn't charge you for the laundry/cleaning services, it's included in their service bill. If a farmer's combine harvester breaks down, he can't just up the price of his wheat twenty-fold to pay for a new one.
There is a market for selling shrink-wrapped software, see e.g. Microsoft, Nintendo, Apple. Invariably these products are proprietary, because Free Software uses a different paradigm: under the free software/open source model, software is a tool, not a product.
Of course. That's not a problem, because the toolset isn't the builder's product. Their customers don't care about the toolset, they actually want the service. Conversely, most consumer software users don't want or need your services, they just need the software.
Moreover, that toolset you mentioned belongs to that builder only. It's not a resource shared by all the builders in the world, unlike open source software.
It's not surprising that people pontificating about the morality of copyleft vs proprietary don't even seem to understand the basic economic effects of shared ownership like the tragedy of the commons.
Freedom of movement is the power to exchange goods and services with anyone.
> freedom of speech as power to manipulate masses
Freedom of speech is only a freedom if it is accompanied by a potential hearer's freedom to block speech. Modern platforms do not let you choose what or who you want to hear. Freedom of speech without freedom to choose your censor is anarchy.
You are ignoring the freedom to modify/fork, plus the requirement of free documentation.
You're free not to use Facebook, Twitter, et al, you know. There are other, open, platforms. And other closed ones that are decent. Use any of them if you want more control over what you read.
Don't fucking shame people for earning money writing good software. Most of us aren't building evil monopolies.
And "user" freedom is more important because we use tenths of millions of SLOC and do development work on a small fraction.
This can be true for a small program on a microcontroller, but 99.9% of FOSS is deployed as part of a big ecosystem.
For each line of code I deploy on production there's 1000 lines of kernel, libraries, daemons, firmware.
As developers, we are 0.1% developers and 99.9% users.
The idealogy is that proprietary software is wrong, bad, unethical. Software freedom should be available to all.
The copyleft terms of the GPL are a tactic a means to defending software freedom. And to that extent, all the incompatibility with other free licenses are indeed a bug a downside, a hampering of freedom in practice. That downside is accepted because of (and only when it is) the judgment that it is a net gain for software freedom anyway because it frustrates the development of non-free software.
There does not exist any ideology that wants incompatibility between free software licenses. It is a price that some feel should be paid sometimes in order to be incompatible with non-free licenses which are the actual problem.
And this condition is the reason that the answer will be "no" every time to using copyleft. Why would anyone ever choose a piece of software which, however you want to twist words, is actually less free in the sense of what it permits and will have less adoption as a result?
I run some websites without ads used by thousands of people and I never intend to monetize them, but I would still avoid these projects solely due to their licensing.
Take slavery, or indentured servitude. Nobody seriously argues (any more) that laws against these practices decrease freedom, although they technically restrict the freedom of would-be slave owners. Likewise, if "proprietary software is evil" is table stakes, then copyleft licenses are more free, period. There is no argument.
So, actually what we disagree on is "how unethical is proprietary licensing?" Arguing that permissive licenses are more free is really arguing that proprietary software isn't that bad.
Without having that argument, the other one just goes round and round I circles, like it always does.
Against that are more rights for the users of the final code. GPL is predicated on advocating for users' rights over developers. But that comes at the right of developers to re-use as they want.
Which one is more free is very much a matter of perspective. Claims that GPL is a more free license because it is better for users are therefore subjective, or at least subject to a very specific semantic context.
Right, but if you buy/get a book, you can't even re-publish or re-use the content in the first place.
I'm not comparing the AGPL and the GPL. I'm only talking here about the insinuation that the AGPL is somewhat like a book author requiring readers to let them crash their couches. It's not.
They can, they just don't want to because they want to ensure other people can produce non-free work.
Remove the desire to produce non-free work and you can perfectly legally put copylefted code into weakly-licensed free code. Weak licenses don't forbid this. Copyleft licenses don't forbid this. There's no need for anyone to change the license or copyright to combine weak licenses with copyleft licenses.
Copyleft licenses forbid proprietary code. And proprietary licenses forbid a lot of other things.
Weakly-licensed code also allows to be covered by a proprietary license. Nobody needs to relicense weakly-licensed code to lock it up in any way and apply further restrictions to it, whether they be "good" restrictions like the (A)GPL, where you forbid further restrictions, or "bad" restrictions like a EULA, where you forbid people to look at your modifications or to do further modifications.
Without a copyright transfer agreement in place, only the original author may relicense the code. The permissively licensed parts of the code will stay permissively licensed, but nevertheless may be distributed in combination with copyleft or proprietary code.
c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
This only says that the product of such a combination must be licensed as AGPL. The MIT/BSD licenses (with or without the attribution clause) specifically allow being included in larger works under any license, even proprietary, so what are you arguing exactly?
I have an MIT-licensed project called A, currently at version A1. You have an AGPL-licensed project called B. I take some code from B and incorporate it into version A2 of project A. I want to distribute A2 to A's community.
I don't have to relicense A1 to do this, but I do have to distribute A2, and all subsequent versions of A, under the AGPL, effectively "changing the license" of my project.
I realize this usage is informal - licenses cover code, not projects - but jrv's point upthread was that projects do not want to change their working license, which led me to read jordigh's response as somehow asserting that the AGPL was not viral. It's a non sequitur otherwise.
Doesn't that depend on how they use it? They're only AGPLing their backends. The tools still follow open protocols, so the client libraries can be permissive. I.e. the rest of their project won't be "infected".
A more permissive license is simply incompatible with this project's ideals - they are willing to sacrifice developer convenience for user freedom and prevent corporate theft and bastardization of the codebase into competing products
To be really strict: AGPL only mandates that contributions be shared with the user. The freedom of users is more important than the freedom of developers.
Of course an upstream maintainer can be a user and get the contributions.
For instance, grsecurity will sell you a security-hardening-patched Linux kernel. You, as the user/customer, have the right to take those GPL patches, and share them publicly. But if you do so, grsecurity will blacklist you as a customer, and you won't be able to get any more patches from them.
"Technically you could share the code, and then we'll blacklist you" isn't letting people share the code, "technically" their customers can do anything.
This sounds like the reasoning of a petulant elementary school kid, not a professional security company.
You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice [..] and give any other recipients of the Program a copy of this License along with the Program.
This is section 1 of the GPLv2 . This plainly states that if The Company is distributing their code under GPLv2, their customers are plainly permitted to "copy and distribute verbatim copies of the Program's source code".
Their whole business model is based on a tortuous reading of this part of section 2:
If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Their claim is that they are shipping their patch set as a separate work from the Linux kernel, so that they're not bound by the requirement that "the distribution of the whole must be on the terms of this License", and they're free to choose whatever license they want for their patch set. However, since their patch set is in no way a separate work on its own, only a lawyer could make that case without blinking.
This is misleading. All developers are users as well. Having to use closed source services and tools impacts us a lot.
Obviously. But you are using other FOSS directly or indirectly.
> The freedom of users is more important than the freedom of developers.
What exactly is this "freedom" that users are benefiting from? Is this the part where we invoke some negative right? That's called "control".
Let's say that Postgres server is licensed under AGPL, and I modify it to my needs. I have a closed source web application, that is publicly accessible, and uses Postgres for storing data.
a) Do I need to publish source code of my version of Postgres?
b) Does my application (which relies on Postgres, and my patches) need to also be under AGPL, and be available in source code form to all my users/visitors?
- does your application directly include AGPL postgres code in any form (headers, binary, etc etc) to its own source or its own runtime process?
- keep in mind, in answering the above, that your application probably does have to include a postgresql driver of some kind. Is the driver licensed AGPL too? If yes, your answer to the above is probably yes. This was the problem for years with MySQL, because they licensed their driver code GPL along with the actual database code.
- a final consideration that only comes into play if there is genuine ambiguity on the other points: is your application able to perform its functions if Postgresql is missing or swapped out for another database? To the extent it depends on Postgresql functionality, this will sway a jury towards considering it is in fact a derivative work of Postresql. If you on the other hand support 6 different databases and Postgresql is just one of them - it will be much less likely your application is considered a derivative work of it. As I said, this only comes into play if the other factors can't be decided decisively.
IIRC AGPL was created to bypass a thin wrapper frontend type situation. I make a website that takes PDFs, it lets users extract pages. In the backend I'm just running a modified Ghostscript command line and sending back what it makes. From my discussions with other people, this type of direct coupling automation is what is intended to trigger the AGPL. Is this incorrect? If that doesn't trigger it, the 'users interacting with it remotely' clause is all but useless because firewalls and service chains like this are really easy to construct. Not all AGPL software is able to natively run as a server itself.
And if it does trigger it, a simple ToDo CRUD app that relies on a database is pretty much the same thing in my eyes.
> if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source
So note the "interacting with it remotely" language isn't specific to just a network connection. So a reasonable interpretation would absolutely be that your users are "interacting remotely" with the PDF tool in the scenario you describe, no matter how many thin layers you put in between.
So this then goes to the question of how a court would decide the boundary ... clearly the connectivity of the internet means nearly every computer and software on earth is theoretically linked by a network. So that is where they would look at how direct the interaction with the AGPL software was, and how critically and specifically dependent on that interaction your software is. If everything a user does gets transformed into a completely different form by the time it hits the AGPL software then they aren't interacting with it remotely - they are interacting with your software remotely and your software is interacting with the AGPL. Similarly, if you could trivially substitute the AGPL for something equivalent and the end user wouldn't notice, that would also argue they aren't really interacting with the AGPL software specifically.
Of course, nothing is really clear until it goes to court, but this my best understanding of current state.
a) Yes, if Postgres is exposed to users for some reason. Your changes to Postgres are a derivative work of the original, and thus covered under the AGPL.
b) No. Your application is not a derivative work of Postgres, any more than it's a derivative work of whatever OS you're using.
"interacting with it remotely through a computer network" may include several hops, the text is unclear at this point. And there is precedent for this interpretation, Microsoft uses the same concept (as "multiplexing") in their SQL Server license terms: https://download.microsoft.com/download/3/D/4/3D42BDC2-6725-... (pdf, from , should the document link change in the future).
reitanqild seems to misunderstand and the other posters fill in with more information.
If the information in that thread is correct and I read it correctly it is totally fine to use an AGPL server that touches connects to a lot of stuff, it won't affect any of that.
Only if you somehow touches the codebase of the AGPL licensed code by modifying it or creating a combined work then the AGPL will take effect in the same way as today - except that allowing access to a running instance over a network will trigger it too, not only distribution of the binaries or the code.
Dealing with such issues, the risk of being abused by some AGPL-enforcement troll who would try to sue a company because it uses some software that uses some other software that happened to use a driver that talks to API which is served by AGPL-ed application... Just wow.
The sad outcome of this is that decision makers would say: ehh, better use AWS or some commercial software as open source sucks.
Only because Linux (and perhaps more relevantly glibc) specifically exempts the relevant protocols from the GPL.
"... and I modify it to my needs ..."
So he has explicitly created derivative work of Postgres, that's not the question at all. The question is whether the conditions of the AGPL for distributing the source would trigger in his case. I would say yes but IANAL.
While a derivative work of Postgres is created, it is not "distributed" (in the sense of the AGPL). The web application is, which I do not consider a derivative work of Postgres in the general case.
If you implement a feature in Postgres and have a web application that is practically just a wrapper around this one, new feature, then that could be considered a derivative work. But I'd say that's a far stretch.
As long as you don't exposed this modified version of a hypothetical AGPL-ed Postgres to the end users, it is considered your own use, where you are free to do anything you want, including using it as the data store for a web application.
If you would however expose this modified AGPL-ed Postgres as a DBaaS, in this case you will need to offer as AGPL your changes to the users. But this was not your case.
So the answer is clearly NO to both questions.
The last part surprised me. For most projects, they don't need to modify the source code of the database engine. They only need to use the database to create a schema and store data.
Can you share more about what you meant by "modify it to my needs"? It would be helpful if you could provide one specific example.
It is not that uncommon to mod Postgres to do something it can’t do out of the box. I’ve been paid to do it many times for companies that use Postgres to make it do just a bit more. This is a pretty valuable and unique property of Postgres; it has many fundamental limitations but a lot of small limitations can be coded around if you are handy with C.
a) postgres is not user facing, so no
b) there is no linking (as in compiler linking) between your application and postgres, so no
What if I release my own SaaS as AGPLv3? Do others, who rely on it, also have to license their software under AGPLv3? I think this kills many business cases.
Am I missing some key point?
If you link to it directly from your code then yes, unless you're willing to pay Grafana for a commercial license (assuming they offer one or you can negotiate one with them). If you have Grafana running on your servers but you aren't using the code in your own applications then you're generally fine (the GPL is generally recognized as ending where a process ends). And that's the point of the GPL/AGPL, you get the code for free, with the only expectation being that you pass it on if you make any changes.
You wouldn't, as system interfaces are specifically excluded as an AGPL enforcement domain. But if the Linux kernel was AGPL, you would have to supply the source code to your NFS clients, since those clients would be served directly by the kernel.
More specifically, the only difference between GPL and AGPL is section 13 (and the preamble summary). The rest of the license is word-for-word identical (save for the name).
I'm sure if I'm wrong I will find out very quickly, this is HN after all.
Much in the same way as Amazon should provide their low-tech workers with livable conditions - but unless the law and applicable contracts specify otherwise, there's no must about it.
Cloud providers are doing an end run around the intention of the GPL - but not around its legal constraints.
(And before we consider possibilities otherwise, it might be more pertinent to at least attempt to punish companies in blatant violation - like the multitude of router manufactures routinely shipping GPL derived software without reasonable access to source.)
The Free Software Foundation exists to protect the former at the expense of the latter.
It seems to me that, to defend users against corporations, the FSF as a side effect is attempting to take a whole lot of freedom away from developers who share the ideals of the FSF.
(That is, any developers who publish under MIT / BSD like licenses)
Corporations are sometimes users, and individual people often benefit from denying access to the source code of software that is used to provide a service.
Providing a service is fundamentally different from providing software.
The AGPL doesn't require you to provide the source for software that you're using to provide a service - only the source for software where the software is the service. A bug in software I use is equally annoying when I'm using that software over a network connection as it is when I'm using it on my local machine.
To the detriment of the users of that service--which are the people that the FSF aims to protect.
My customers, for example, to whom I provide service, are not infringed upon in any way because I use private forks of GPL software in the provision of my services.
The issue is that I—and, more importantly, your customers—must simply take your word for it, since we're unable to confirm or deny it for ourselves if you don't make the source available.
When dealing with large corporations, taking such statements at face value is pretty foolish.
You might not want to admit to yourself that your business model is based on infringing on the freedoms of these users of GPL software, but that's exactly what it is.
This was never an issue until Google was pinched on it five or six years ago and started a massive campaign to get the OSS movement to disfavor the AGPL. Google uses tons of GPL software that they don't pay for (Linux, Java, etc.) but once it became exterior-facing and the license applied to their software, then rather than pay to license the software, the world's fifth most valuable company decided they'd rather stiff the developers by a campaign to convince other companies of what you just posted.
You also wrote: <<Google uses tons of GPL software that they don't pay for (Linux, Java, etc.)>> While that statement may be true on the surface, it belies the fact that Google is either a major, direct contributor to the Linux kernel (and many of its parts). Or: Google is a major sponsor of open source orgs to pay for developers to work on open source projects -- like the Linux kernel.
Also: Are you aware that the Oracle version of Java requires companies to pay license costs when used in a production settings? I cannot say if Google uses a non-Oracle release. But if they do (sometimes) use the Oracle release, I am sure they pay licensing costs. Before you make a claim like that, you should share a source -- one way or the other. One reason why some companies choose to pay the license for Java (instead of using a non-Oracle pure open source release): They want the support when there is a security issue. Example: If you find a bug in the JVM and you are a major customer, then it will be much easier to get support directly from Oracle to release a fix.
The free in free software is often cited as being "free as in freedom", but it's important to remember that it's also and simultaneously "free as in beer".
Google, along with everyone else, uses tons of GPL software that they don't pay for - because the point of free software is that you're free to use it. They're not "stiff[ing] the developers" as you claim, because the software is available for all to use for free.
You can't have it both ways: either you're free to use the software for any purpose, or by using the software you owe somebody something. Pick one. I choose the former.
The only reason Google opposes the AGPL is financial. Read their explanations. So, while you're right that Google is not 'stiffing' the developers whose software they're using, by their campaign against the one license that can be used by developers to make money, they are making the OSS world weaker--especially for programmers from developing countries who don't have the luxury of large blocks of time to write software on the side unless they can benefit from a license like the AGPL.
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.
In any case, this is, in my opinion, a lot better than SSPL or the Timescale license.
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.
Anyone debating that it's not has a screw loose.
The follow on questions on that thread seem to be fairly hypothetical handwringing, and something I’d expect the FSF to submit an amicus brief, giving their fairly reasonable FAQ answers, if it ever did show up in court. Given that the GPLv3 (and its derivative, the AGPLv3) allow for up to thirty days to remedy shortcomings, your source code being unavailable for a few hours while GitHub is down seems like a non issue.
I am a proponent of software freedom, and resultantly I view the AGPL as nonfree.
Freedom includes freedom to have privacy. Not distributing any software, my privacy should not be violated.
Running an ASP off a private fork is not "loophole", any more than, say, using free software to make missiles or killing machines.
I feel like the AGPL is just anticapitalist fist-shaking.
You have that. The AGPL provides rights to _users_ of your software; that's it, no one else. If _you don't provide_ the modified software to someone, they can't demand your private patches. No one can "bring down the machinery of state copyright enforcement" against you, unless you interact with them first and provide them your modified software and they use it.
And even when you do that — when you provide your software to someone — they still can't demand that you "publish" your private patches. Only that you give to _them_ the modified software under the same rights that you received the original software. Only to _them_, not the public. No publishing required. _They_ are free to publish the software they received, of course, as were you when you first received the original software; but you aren't obligated to publish it.
The only difference between AGPL and GPL is that the definition of what constitutes "distribution" of software is extended. The AGPL changes only "distribution" and nothing else in the GPL.
Depending on the software, according to the author of said software, it can be. I'm not saying this is the case for all software, but for some kinds of software it makes sense.
> Running an API business shouldn't force me to distribute anything to anyone.
"Running an API business" does not "force" you to "distribute anything to anyone". Using software that was clearly meant, by its author, for the provision of a service and licensed as such to you is what requires you to do anything. And the AGPL is very tame at that:
1. you don't have to distribute non-AGPL3 and non-GPL3 code;
2. you don't have to distribute to just about anyone, only your users; and
3. you don't have to distribute anything _you haven't modified_.
If you were given the freedom to modify a software, then not providing users of this modified software the same freedoms you received is loss of software freedom, don't you see?
Do you consider it a problem? If not, why not? If so, what other than the AGPL do you propose to fix it?
I really think the whole AGPL is simply sour grapes, because most GPL-using businesses have not figured out how to become profitable. ("open source is not a business model.") The anti-corporate, anti-business types see people exercising their software freedoms and using free software to make money, and think it's a problem that needs to be stopped.
It's interesting that TPTB have ruled such "ethical source" licenses as nonfree - you're not allowed to restrict Freedom 0 to say that users aren't allowed to, say, use the software to produce bombs. That's not a free software license.
Using it to generate revenue however, is seen as a "loophole" to be "closed".
I don't see a license that forbids the generation of revenue by selling access to a service API using a private fork as any less nonfree than one that forbids the production of bombs.
However, because you can only access their fork of a GPL project over the internet, there is no requirement for them to provide users the source code of software they're using (which is based on software developed by other people under the social contract of the GPL). Thus users are using software which is technically free software but they have no mechanism by which to excerise any of their freedoms nor even see the source code of a program they use purely because the protocol used to display the interface is HTTP rather than X (yes, it's also not running on the same computer, but from a user's perspective it doesn't matter if it runs on your computer or not -- they are using and depend on the program, even if it happens to be running on a different computer).
Do you agree that this scenario is a problem, and the GPL is not helping to solve it? If so, then you now understand the reason behind the AGPL and how it is clearly in line with the spirit of free software. If not, then I'm not sure you fully buy into the concept of user freedom. User freedom is a holistic thing, it isn't a technical definition that cares about specific implementation details.
I would argue this is a bigger issue than tivoisation, because at least with tivoisation you can at least get the source code (even though you cannot use your freedoms on the hardware you bought). In this SaaS scenario, you can't even see the source code of software you are using.
I never knew how much I can't stand "free" software types until today.
Something entirely different is happening when I'm running software on my computer, using it to provide i/o services to you, and when I provide software to you to run on your own computer.
One is a service, the other is a product. The hypothetical LibreOffice fork, with their private modifications on their own private computer, is entirely within the bounds of reason to keep those modifications private and generate revenue with it, if people want to pay them for the services they provide with it.
It's no different than me using LibreOffice to produce private documents, which I then use to generate revenue for my business. My customers have no right to access my private documents that I use to provide that service: source code is no different.
I think you're getting caught up in the "on their own private computer" part. There is a clear distinction between using a piece of software and providing a service by which other users make use of the software by proxy. In the first case, you are not acting as a proxy for other users to run the software.
> It's no different than me using LibreOffice to produce private documents, which I then use to generate revenue for my business. My customers have no right to access my private documents that I use to provide that service:
It is incredibly different, so much so that I'm not sure you've understood my hypothetical.
> source code is no different.
If you were using it purely for yourself, yes. But in the hypothetical the business is providing the ability for other users to use the software by proxy. They aren't using the software themselves and then
As a final point, consider that these days a regular user might not know whether the software they run is actually locally running on their computer or is a SaaS application where the code happens to reside on a different machine. How they use the software is no different in either case -- so why should they have different concepts of what freedoms they have? For an ordinary user there is no practical distinction between software they use on their computer versus software which is provided over the internet -- hence why I said that the only real difference is that the "display protocol" for the application is HTTP not X.
The AGPL does not "forbid the generation of revenue". There exist revenue-generating services powered by AGPL software.
> Nothing is being used improperly or against the spirit of free software when software freedom is exercised (by a service provider)
If that exercise of software freedom hampers an end-user from exercising their software freedom, then that's pretty clearly "against the spirit of free software".
> forbids the generation of revenue by selling access to a service API using a private fork
That's the thing - "software freedom" is being applied to software that you have no reasonable expectation of having access to:
1) you didn't write it
2) it hasn't been provided to you
3) it's running on someone else's computer
There is no reasonable basis for claiming that you have the "freedom" to access information in someone else's computer that you have nothing to do with. That's actually a privacy violation.
4) You're using it.
> access information in someone else's computer that you have nothing to do with.
1. "nothing to do with" is an absolute claim. Your line of argumentation has been heavily reliant on absolute statements, refusing to understand nuance.
2. If the user truly had "nothing to do with" some information on some computer, the AGPL places no requirement for them to be provided access to that information.
3. Interacting with a service provided by a software != having "nothing to do with" said software.
> ... claiming that you have the "freedom" to access information ...
For the last time, that is not how the AGPL works. I strongly urge you to go and actually read it, or even https://writing.kemitchell.com/2021/01/24/Reading-AGPL.html
Now, on to the specific rebuttal: The AGPL does not _force_ a user upon you, the service provider. It does not grant the user any "freedom" to access any information, let alone arbitrary information. It cannot even be used by a user to force themselves on you.
> That's actually a privacy violation.
By your line of reasoning, you have violated my privacy by way of your writing showing up on my computer. Do you see the absurdity in that?
There's a clear distinction between sending someone a file that represents computer software (source or object code) (a product) and sending someone the output of a calculation you have been requested to perform (a service).
The distinction is meaningless to the user in the example your parent cites.
We actually designed the Timescale License to be _less_ restrictive than AGPL. It contains no virality. It just prevents public clouds from offering TimescaleDB-aaS.
Timescale license does not provide that, so obviously it's more restrictive than even the most viral of open source licences.
To be specific, the sentence "the customer is prohibited, either contractually or technically, from defining, redefining, or modifying the database schema or other structural aspects of database objects," spits in the face of all the ideals of open source. I can respect your decision to choose such a license, there are understandable practical arguments for that, but I can't respect you calling that open source - if you consider that users should be restricted with what they can do with their data schemas, if you include an explicit anti-user-freedom clause, legally mandating software developers to be hostile to their own users - then at least have the guts to openly say that you are against open source (because of all the valid reasons you have, I'm not denying that, you don't have a duty to be pro-open-source), instead of misleadingly labeling your license as such.
The sentence you quote is actually meant to -technically- establish a basis for what it means for somebody to run/offer TimescaleDB as part of a value added service (very much allowed) versus a company like AWS offering TimescaleDB purely as a DBaaS offering (not allowed).
There are many, many thousands of companies that use or embed TimescaleDB as part of their service or product offerings, serving huge numbers of customers. We're extremely supportive of their ability to do so. We have no "enterprise features" that are excluded or held back only to paid users.
What we aren't supportive of is AWS running "TimescaleDB-as-a-Service" as part of AWS RDS. Because we know they do that!
The clause you are quoting helps define some of the legal nuances how we get there, ideally in ways that an engineer would understand. In particular, what it means to be a value added service/product versus just "TimescaleDB-as-a-Service".
The alternative legal formulations of this can be found in, e.g.
- Confluent Community License ("Licensee is not granted the right to, and Licensee shall not, exercise the License for an Excluded Purpose. For purposes of this Agreement, “Excluded Purpose” means making available any software-as-a-service, platform-as-a-service, infrastructure-as-a-service or other similar online service that competes with Confluent products or services that provide the Software.")
- Polyform "Shield" License ("Any purpose is a permitted purpose, except for providing any product that competes with the software or any product the licensor or any of its affiliates provides using the software.") https://polyformproject.org/licenses/shield/1.0.0/
These are all getting to similar places, but just putting more emphasis of the legal definition of "competition", which we thought would frustrate engineers with its vagueness.
That restriction makes the license not Open Source. Open Source licenses MUST allow anyone to run the software, for any reason, by definition. Even "as-a-Service". It's a perfectly fine restriction to have, but it shouldn't be called an Open Source license.
(Timescale engineer here)
While AGPL is a value-add for many, TSL isn't as ambiguous in some regards and provides a lot of nice "we won't sue you for this" clauses for users. Clear communication regarding its FOSS status will only help!
That's why Open Source came up in the first place - pointing out that one of the basic reasons for the Timescale license to exist in the first place is to restrict one of the major reasons Open Source licenses exist.
There were also no claims about whatever definition of restrictive you were using. It was just a short statement that the Timescale license was designed to be less restrictive than the AGPL. You can't really be that surprised when somebody comes along and starts judging it by Open Source standards after that, can you?
Comparisons to Open Source and discussions of the pros and cons of both approaches are, of course, fair.
I think Timescale employees should remember to preface "This is our belief on the definition of restrictive" when describing the license as more open than open source licenses, given much of the community might disagree (sometimes vehemently) about that take.
Incidentally, that clause exists as a clear line for value added products and services. Some companies have a restriction that says, "You can't compete with us." That approach struck us as arbitrarily blurry. We took a clear approach that says DML (inserting, querying data) is permitted, but not DDL (creating tables). Again, this is to clearly restrict TimescaleDB-aaS providers and not other companies building true value added products / services on top (e.g., IoT platforms, SaaS companies).
Why not toss in an AGPL license option? You wouldn't be discounted off-the-bat by folks like me. I build open source. Timescale is not open source. Timescale won't mix with GPL code. I use plenty of GPL code. GPL/AGPL are known quantities. Your license requires legal review.
As a footnote, I do pay for hosted versions of most of the databases I use.
> TimescaleDB is a relational database for time-series, with some features licensed under the Apache 2.0 License but many of the features you know and love are licensed via the Timescale License (including continuous aggregates, compression, data retention policies, actions, multi-node, and more). The "Apache 2.0" version of TimescaleDB offered by Microsoft, Digital Ocean, and others includes only the features in the Apache license. The Timescale License prohibits cloud providers from offering the "community version" of TimescaleDB-as-a-service.
But I don't find any links to download the Apache 2.0 version, there or elsewhere…
By the way, I really hope you guys are able to strike a deal with the cloud providers for them to re-sell Timescale Licenses, so people can get all the great features and pay you without having to add a new vendor relationship!
Re: Apache 2.0 only version, it is on our Github readme (but yes, probably could be made more prominent):
Apache-2 licensed binaries can be built by passing -DAPACHE_ONLY=1 to bootstrap.
It's ubiquitous ("it's me, not you"), but I hate it.
I'd much rather get a straight "no."
To answer the non-answer: I don't want a crippled version of the product with features held back for paying customers. I don't know which other features will be held back in the future, or what the evolution of the system will be. My expectation is that at some point, I'll need e.g. features to comply with a law like GDPR, and some critical feature may be withheld in an attempt to monetize me.
When that happens, I end up in limbo.
With a half-open-source project, what do you do? Do you fork the system and build the feature yourself? It will never move into mainstream since it undermines your revenue source. Do you maintain a fork? No one will use your fork over mainstream and you have competing communities. Etc.
Having built systems which have been used and maintained for decades, those sorts of considerations matter much more for picking a long-term viable solution than which technology happens to be ahead this year. I'm not saying you're going to burn me (and usually by the time this happens, you've been acquired by Oracle like Java, went bankrupt and got picked up by vultures, like SCO, hired a massive number of mediocre people, like Google), but if you make a dozen decisions like this, someone WILL burn you, and that WILL cost you more than the other 11 decisions combined.
Make it easy on customers like me.
Heads up: calling out the virality of copyleft licenses as a "restriction" is a common tactic used by the anti-FOSS brigade — this includes the likes of Microsoft under Steve Ballmer that famously called the GPL "a cancer". So it seems like you're re-using old FUD tactics, even if you don't intend to.
Putting that aside, what you claim also happens to be an established point of argument that has been already heavily debated upon in the FLOSS community, specifically by the permissive licenses' side; and they actually have some truth to the claim. Your claim, instead, is nowhere near as strong as theirs.
Permissive licenses take away virality, sure, but add little-to-no restrictions of their own. Your license, OTOH:
1. Doesn't take away nearly as much virality — Derivative Works of code under the TSL are still subject to the TSL; and
2. Adds its own set of restrictions — quite a few of them, actually.
If your argument was that you "designed the Timescale License to be less restrictive than AGPL _specifically on the question of virality_", you'd be right. Because the TSL also adds a bunch of restrictions, your original claim does not quite stand up.
And to those who keep downvoting my comments simply because they don't agree with them - I always welcome thoughtful discussions. :-)
edit: And FWIW, I have dropped this claim from the post with a note, especially since it was not my point anyways.
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.
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 about money.
Maybe my observation on other places was a reflection of SV mentality, who knows.
I could image that its the same with other corporations. In the end that might hurt the popularity of Grafana quite a lot.
Now, one can read into why exactly this may be, though I have a strong feeling it is simply due to the fact that enforcing correct use of the license is harder than usual. Even if you use it alongside only compatible licenses, like GPLv3, it presumably would make the entire distribution subject to AGPLv3 restrictions. GPLv3 virility is a little easier to deal with, and of interesting note the Bazel build system contains some awareness of licenses.
On the other hand, one might view this as a benefit. So, I guess it depends on who you ask, really. It's not clear that big corporations would necessarily have an easier time with SSPL or TSL either.
Note: IANAL, please do not take my understanding of how these software licenses work as fact :)
"...extremely difficult for Google to comply with..."
"...presents a huge risk to Google..."
and later in the document is the best part:
"This viral effect requires that the complete corresponding source code...".
All from a company which built itself on GPL software. This reminds me of Steve Ballmer ranting about Linux being a virus 20 years ago.
"Do not install AGPL-licensed programs on your workstation, Google-issued laptop, or Google-issued phone without explicit authorization from the Open Source Programs Office."
Assuming Google follows its own policy, this just creates a hassle for its employees. Worse, Google making this public sends a strong anti-AGPL message to other companies. I'd bet $10 RStudio server (AGPL) is installed somewhere at Google (perhaps the commercial version). But other organizations with less sophisticated legal departments might just ban RStudio completely following Google's lead. I would not call Google irresponsible here, but I think it could act more responsibly.
Going against interest of Google (and similar companies) is one of main points of AGPL, so this indicated that it works as intended!
If a company develop an proprietary UI and use Loki as backend, this is not serving Loki directly to customer, so that does not require company to release their code.
It is similar to GPL. Dynamic linking to a GPL software does not require the developer releasing their code.
Only provider serving Loki instance directly to customer required to share the code.
Only Amazon is upset that they cannot just host a popular open source project directly on their cloud. Maybe they could pay a license fee for dual licensing arrangement, which is a better way to support open source startup.
The key clause is "your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version."
Would putting AGPL software behind a reverse proxy change the fact that you're a user interacting with it remotely? What about a reverse proxy that changes/adds some headers? What about a really smart reverse proxy that reformats some of the output or repackages it or mixes it with things from other data sources? Is that materially different from the API that powers the "proprietary UI" you're describing?
And say you're pretty confident that you're on the right side of things. Can you point to any case law where courts have established precedent about what "interacting with it remotely" means in this context? No? Then to be on the safe side, you'll probably need to maintain a source code repository for your Corresponding Source, remember to update it every time you update a minor version of the service internally, and maintain an info screen in your product with "prominent" links to that source code repository, which likely means it needs sign off from a product team if not a legal team as well. All things that add expense and barriers to entry.
I think the AGPL is great for services like Grafana's UI itself, where there's likely to be a "human gap" between the software and anyone outside your organization. But things like Loki that are designed to power other proprietary systems that may well be touched by end users through a computer network, where Loki's output may have influence or side effects on the output the user sees? I don't think it's nearly as clear what liability that entails.
(Obligatory: Not a lawyer, the above is not legal advice.)
It turned out alright.
TL;DR FSF is heavily responsible for the "GPL is viral" message sticking.
If it's anything like dynamic linking and GPL that could be considered okay even if it's not the intention of the licensee. Seems like the license should be more explicit about what "interacting with" entails.
Is that a problem? Fork it on github, and update the repository every once in a while or upon request.
That's not true, you do have to release the code. There is no difference between statically or dynamically linking to a GPL library. Source:
You may be thinking of the LGPL.
Whether or not dynamic linking constitutes a "derived" work is still an open question, legally speaking. Obviously the FSF has their own thoughts on this, but it's unclear how an actual court would rule.
(IANAL, this is not legal advice, etc. etc.)
In fact, state of ambiguity is the worst for everyone because neither will users be able assume they can exercise their free software rights. So everyone loses.
The difference between the AGPL and traditional GPL is simple: The AGPL seeks to close a "loophole" that allows a company or organization to modify GPL'ed software and use it to provide a service — but without actually distributing changes. So a company can take a package like, say, WordPress and modify the software significantly to sell a service — but hold back changes because it's not technically "distributing" or "propagating" the software. The AGPL goes a bit further and says that if the program is "intended to interact with users through a computer network" and if the version that you received gives users "the opportunity to request transmission to that user of the Program's complete source code," you have to maintain that functionality and distribute the modified version.
1. the software is conveyed in a "User Product", and
2. that conveyance occurs as part of a transaction in which the right of possession and use of that product is transferred to the recipient.
A "User Product" is defined as 'either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling'.
In other words, it only covers software that is installed on actual physical hardware when that hardware is sold (or rented, etc) to the consumer.
For a sale of a service, it is completely out of scope.
This is probably the most misunderstood clause in GPLv3, with people thinking that it some sort of general anti-DRM clause. Almost everybody, for example, thinks that it is why you can't have GPLv3 code on the Apple app store, but because it only applies to conveyances that are part of the transaction by which you acquire your iPhone or iPad it in fact does not apply to software purchased later from the app store. Apple's app store DRM is perfectly compatible with GPLv3.
The incompatibility between the app store and GPL is that the license agreement for the app store says you won't redistribute the app or reverse engineer it. GPL does not allow adding additional license restrictions like that, and so you can't satisfy both the app store license and GPL.
That's GPs point.
- you might not want to risk because you don't have lawyers etc in your company.
- even if you have lawyers etc in your company, if there are 2 alternatives one which is just an MIT license, you'll probably go for that one because you don't want to have a 1.5 month review of the use of this AGPL licensed alternative.
In general things like this https://github.com/xdspacelab/openvslam/wiki/Termination-of-... (repo with 3k stars), an effort terminated because of some traces of GPL code MIGHT be somewhere in there comes to light. Even though Grafana etc are mostly tools, for my startup I would probably not risk any of this (for my own sake and also for any kind of due diligence in case it ever gets acquired)
If legal is familiar with AGPL, like they are with GPL, BSD or Apache, they should see no issue. This change does not really affect anyone except for the very small number of people/companies that make their own changes to software and make this software available online to others.
If you aren't such a company and legal would still say you guys can't use e.g. Grafana anymore... the truth will be that it's some incompetent (or severely underhanded, where they can't do any research and err on the side of caution) legal department, failing at their jobs.
Unless you’re repackaging Grafana into an app bundle for customers to use, there’s no violation occurring here, right?
If a developer uses GPL Emacs to write a server that uses GPL libraries and Google runs that sever in their datacenter it is very clear that Google doesn't have to release any source code.
However Google's argument is that if they make a web application that uses AGPL MongoDB as a backend it is unclear if 1. The user is interacting with MongoDB over a network and 2. do they need to release the code of their server.
It appears that the answers are 1. Yes and 2. No but apparently Google isn't confident to use that in court. (Or at least they don't see enough benefits for that risk)
MongoDB Inc. instead went after much smaller companies, like mLab, holding their future hostage and thus strong-arming them to sell themselves to MongoDB Inc. a short while before they announced the monopolistic license change that would have effectively shut those small companies down anyway.
Frankly, I'm tired of hearing this myth. MongoDB would like you to believe they were David in a fight against Goliath — PR and marketing have always been their strong suit — but they were quite happy playing Goliath themselves while pointing fingers at imaginary Goliaths.
That is not allowed.
"""The "Corresponding Source" for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work."""
(Emphasis on that last part mine.)
"""Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software."""
If Amazon modifies Grafana so it depends on a proprietary Amazon system, the source code for that system is included in the Corresponding Source, and if they allow users to interact with that modified version, they need to provide them with access to the proprietary system's source code.
I think if there would be a possibility to pay money to have what we are doing reviewed by Grafana and be "certified" to be withing what they consider acceptable under the AGPL that might actually be a good option
My first post is about the fact that even though the planned use case would be 100% compliant to the AGPLv3 license the fear that is associated with that license could prevent such use.
> That makes zero business sense
Purchasing a license in that case while not strictly necessary might be seen as an insurance. So that makes business sense.
In the end though I highly doubt that's whats going to happen. The most likely outcome is that we just get told to get rid of Grafana and use something else.
Whatever you replace it with will have the same licensing overhead. Again, this makes no sense.
If you said we can’t afford to pay for it, fine. But you explicitly said you don’t think cost is an issue.
Maybe I’m making the wrong inference, but it sounds like you’re afraid your higher ups just don’t want to have any restrictions placed on whatever business need it is that Grafana is filling for you. If I haven’t misunderstood that fear, then I regret to say that any software product other than one you build and maintain yourselves will come with some restrictions or the possibility of future restrictions.
When I say this makes no business sense, that’s what I’m trying to get at: other than (potentially) licensing cost, any Grafana substitute will come with the same issues, plus switching costs. So unless there is a FOSS product that provides a better solution to your problem, by definition switching will be more costly than maintaining status quo.
Or am I missing the point?
“What can I do with Grafana in my business under GPL?” is much more clearly defined than the same question changing only the last word to AGPL. Alternatives available under Apache v2 or other non-copyleft licenses are also clear. For GPL, all I need to be careful to avoid doing is distributing the software and I’m in a well-understood situation.
It’s this closing off of futures unknown but possible that is markedly worse under AGPL. Anything that you’re doing today that could apply externally as well seems to be an area where a decision to continue to follow Grafana tip could bite you. And not updating could also bite you. Grafana will lose contributors and users over this. All of that I’m sure Grafana considered and made the best choice for Grafana.
Losing users who would otherwise be willing to pay for a commercial license (as the OP said they are) that could be negotiated to explicitly cover whatever future use case they’re concerned about? That makes no sense.