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:
https://github.com/grafana/grafana/commit/75d03fc49ab4f95ee4...
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.
> 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.
But the point is that they acknowledge that they forked Kibana and why. It’s no different than if someone forks Apache code to form a proprietary software company. The permissive license contributed to the success of many companies. They further acknowledge that Apache based Grafana can be forked too, but they’re betting on themselves to continue to succeed long term by focusing on good software, branding and community. The GP’s point seemed to indicate that “no one” acknowledged the Kibana origins when in fact Grafana themselves have.
You're right - I hadn't seen that in the Q&A, so I appreciate you pointing it out.
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.
> 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.
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?
The Grafana Enterprise point is the most salient here. The answer is no, they wouldn't have been able to create closed source plugins for a commercial product. Only AGPL code. As I've stated before: copyleft licenses are an evolutionary dead end: https://www.influxdata.com/blog/copyleft-and-community-licen....
Many companies ban agpl code, this came from legal and is taken seriously by business. Ops guy says it won't touch anything else, business says don care no.
I think I'm right in saying that, providing you fork from any commit before the introduction of the AGPL license, you can continue with Apache-licensed Grafana. Sounds like the way forward.
They amount to the same thing. A git repo is an historical document. All commits (and forks) up to the one changing to the new license "going forward" are available under the original license.
Yeah, that's pretty speculative to assume what would have been, but forking and improving/shifting direction of kibana would have been definitively possible from a license POV.
Their FAQ even says:
> I asked Torkel, and he said that If Kibana had been an AGPL project, Grafana would likely have been AGPL from day one.
i wonder how much of that original Kibana code remains today (my guess is not very much), and if it were originally AGPL, would a completely rewritten codebase still be subject to it?
The license talk about derived work. And even if every line of code has been changed, it is still a derived work as it was progressively changed. So pattern and desings from the original are still in use. The Ship of Theseus is still the Ship of Theseus.
> The Ship of Theseus is still the Ship of Theseus.
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.
> it is still a derived work as it was progressively changed.
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.
It is still likely a derived work. Looks more to me in the example it was just practised the right to make changes to the original work which one could do under the given circumstances which is normally a reciprocal license - floss or else - which means even when if 100% of all letters in all files have been changed, one could still not do more than the original license granted.
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.
That sounds nice in theory, but the reality is also that a lot of more permissively licensed (BSD / Apache) projects now cannot use (most) parts of Grafana / Loki / Tempo anymore, since realistically they won't be able to or want to switch to the AGPL as well (because of all the pain that would incur on others, in turn). That means that basically the whole free code sharing idea goes out of the window, at least in one direction – Grafana can of course still integrate code from more permissively licensed projects into their codebase.
That's kind of the point. The purpose of MIT/BSD is to enable nonfree derivative works; the purpose of the AGPL is to only allow free derivatives. AGPL maximizes freedom by prohibiting further restriction of it; it's a local maxima of "user freedom" as a function of "developer freedom".
If you want to use AGPL software in your project, you're free to relicense under AGPL.
I agree with the substance of what you said, but I'm going to nitpick a bit of wording: what you call "developer freedom" isn't freedom at all, and is more rightly called power.
That seems like splitting hairs for ideological gain.
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.
Laws exist ideally to limit freedoms whose exercise comes with externalities that end up reducing the freedom for others. These range from freedoms to cause harm to others (steal, assault, enslave), to freedoms to sell food without disclosing ingredients, to freedoms to run a business without transparently reporting financial information. The idea of greater freedoms depending on lesser restrictions is not novel.
> 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 [0].
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. [1]
> 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.
If developers only get paid for selling auxiliary services, no one actually gets paid to write and improve the software, only to sell services. That's a rotten incentive structure.
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.
no one actually gets paid to write and improve the software, only to sell services. That's a rotten incentive structure.
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.
> A builder also doesn't get paid directly to maintain his toolset, that cost is included in how he charges for his services
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 as power to take someone else's job in another town
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.
> 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.
You are ignoring the freedom to modify/fork, plus the requirement of free documentation.
Quite a quantum leap there from proprietary licenses to "modern platforms".
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.
How does freedom for the user-who-is-not-a-developer to change the source work, then? The FSF fundamentally assumes the user is a developer. Hell, look at the vast majority of the GNU software. I wouldn't say it's at all targeted at not-developer users.
Arguing over which one is “freedom” is a petty exercise in trying to claim the moral high ground. Instead, it’s more objective and accurate to say that GPL and BSD represent two different ideologies, and that the AGPL is definitely designed to promulgate the “GPL” ideology, so that it’s inability to be incorporated into BSD-licensed software is a feature and not a bug from the perspective of the people who choose to license their code as AGPL.
I think you misunderstand the GPL ideology (to use your words).
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.
> If you want to use AGPL software in your project, you're free to relicense under AGPL.
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.
"Are copyleft licenses more or less free than permissive licenses?" is a pathological nothingburger of an argument because there is no substantial point of disagreement, except on priors, which are never discussed.
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.
Without cost or encumbrance, just like I would expect for a physical free book. The book would not be free if I paid nothing for it and now the author has the right to sleep on my couch legally.
An AGPL license comes with more obligations for the one publishing the code, and for others re-using that code.
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.
> An AGPL license comes with more obligations for the one publishing the code, and for others re-using that code.
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.
AGPL can be combined with GPL and vice versa. GPL does not require open-sourcing if it stays on your computer or the computer of your company and its employees. This makes AGPL a much weaker copyleft when on a server.
I don't understand the distinction you're drawing. It sounds like you're saying that "cannot be combined with code under a different license" is meaningfully different from "can be combined with code under a different license, so long as you immediately relicense that code so it's not under a different license anymore". What am I missing?
Because you're misreading it. It doesn't say you have to relicense the code. It just says (A)GPL terms have to apply to both parts of the code. That's not relicensing. You don't need anyone's permission for weakly-licensed code to do that. Weakly-licensed code already allows it, that's why it's a weak license.
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.
> but the reality is also that a lot of more permissively licensed (BSD / Apache) projects now cannot use (most) parts of Grafana / Loki / Tempo anymore
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".
I suggest you read more deeply into the legal interpretations; it is not so clear cut as you put it.
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.
Sure, but there might be out-of-band reasons for users to not do that.
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.
This just seems like a blatant violation of the license on grsecuritys part. The license requires them to allow people to share the code.
"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.
It sounds pretty reasonable to be honest, youre allowed to share the code and theres no legal reprocussions for doing so but the company should be able to just stop sending you stuff if you do?
The GPL states that the company isn't allowed to distribute their modifications with those legal repercussions in the first place:
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 [1]. 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.
Didn't that preaty much out grsecurity into (an even bigger) obscurity as no one sane will touch a logic bomb like this, not to mention build their business on it ?
No, developers are not always users. I might be working on an accounting software for a big company and never use it. In that case the (A)GPL guarantees that the company is in control of their data and processes.
The line between user and developer is blurry, especially in the context of software that exposes its configuration entirely as some part of its core function.
> 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".
You have it backwards. The "control" you're speaking of is actually the thing that the AGPL withholds, so if you care about users having freedom but not control, then it's exactly what you want.
I have a question regarding AGPL, that I couldn't answer by Googling or reading the license.
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?
I'm going to split hairs the other answers don't: you specify you have modified Postgres. My answer is, it entirely depends if your application is considered a "derivative work" of Postgres. This hinges on a couple of things:
- 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.
Doesn't it also depend to some degree on how much code sits between the user and AGPL code?
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.
It depends on whether a court considers it to legally be a derivative work or not. Some (but not all) circuits apply the "Abstraction, Filtration, Comparison Test", under which thin wrappers should make no difference. Other courts might have their own ways of deciding. The whole area is murky and untested, mainly because companies haven't really hammered out the cases in court.
How is the court venue decided? Is it based on where the copyright holder is based? That just adds a whole other layer of murky, now I can decide whether or not to infringe based on where the project is headquartered :)
Apparently not, it's "either (1) in the district “where the defendant resides” or (2) in the district “where the defendant has committed acts of infringement and has a regular and established place of business.”" That's US specific of course.
> 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.
The postgresql driver might be considered derivative work, and thus required to be AGPL as well, because Postgres does not talk some standard protocol that exists outside of it.
But one can modify Postgres without changing the wire protocol, so the driver may be the plain, original one without custom modifications. The AGPL doesn't mandate that the protocol must be ratified by some standards body, only that a "Standard Interface [exists] for which an implementation is available to the public in source code form".
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.
The license does not include the phrase "connect directly". It says if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network [..] an opportunity to receive the Corresponding Source of your version
"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 [1], should the document link change in the future).
Actually the GPL has special wording to exclude system libraries and headers from the "derivative work" - since the AGPL does not have something similar (why would it?) one would assume that the derivative work of Postgres includes your app, even if you only communicate with Postgres via http requests going through three levels of indirection
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.
You've started a really interesting discussion, after reading the thread I am no longer surprised why companies are simply banning AGPL-ed software en block.
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.
Do you need to release as GPL the code of a program runnning on GNU/Linux? The answer is no. The same applies to software interacting with AGPL Postgres using the postgre protocol. If you are AWS and gives access to customers to modified versions of AGPL Postgresql you AWS must release your patches over Postgresql. IANAL and all that jazz, also I'm not that sure about the typical cloud vendor secret sauce that controls automation etc. Most of it it's probably external enough and not covered by AGPL but there might be some exceptions.
Only partially, this is part of the legal mess that is GPL, because if your program is based around standard apis etc. (and not, let's say, deep linux-only stuff and won't work without that ever) then your program is not derivative work.
That's not a GPL-specific issue, that's a copyright law issue. It applies just as much when writing programs for commercial Unix, or indeed OSX or Windows.
Assuming a client has no direct access to the Postgres server, I'd say you neither need to publish your changes to Postgres, nor put the web application under AGPL. Just because your web application uses Postgres as a storage for data, in a way it could also just use SQLite or MariaDB instead, does not make it a "derivative work". #notalawyer
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.
Just because I create a derivative work of an (A)GPL project does not immediately require me to publish those changes. Only if I distribute the work, I also need to distribute the changes along with it.
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.
The AGPL is a free software license. This implies that guarantees the well-known freedoms. Among them, there is the freedom to modify software for your own use.
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.
These are good questions. Regarding the premise, you wrote: <<Let's say that Postgres server is licensed under AGPL, and I modify it to my needs.>>
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.
Postgres is designed to be modified and is highly extensible. Many companies add features or capabilities that are not native to Postgres. Some things you can do using extension interfaces (linking in shared libraries) and others require modifying the source. It can get a bit blurry, it really depends on what you are trying to do.
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.
But if my proprietary SaaS only uses Grafana for monitoring but its key purpose is doing something else entirely, I can no longer use Grafana unless I also publish my SaaS under AGPLv3, right?
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.
>I can no longer use Grafana unless I also publish my SaaS under AGPLv3, right?
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.
If your server runs Linux you don't have to distribute the source code of Linux to the users of the services running on it. If Linux was AGPL you would have to. And yet, you would not have to distribute the source of your closed source software running on the server.
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.
The only difference between GPL3 and AGPL3 is what constitutes distribution. With GPL3 you have to provide source to anyone you provide binaries. With AGPL3 you also have to provide source to anyone who uses the software remotely (eg a web app). Everything else, including the scope of what must be included in the source (modifications, linked software, but not software that talks over IPC, etc), is identical between GPL3 and AGPL3.
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).
https://www.gnu.org/licenses/agpl-3.0.en.html#section13
To expand on that, you have to offer to provide the source to "all users interacting with it remotely through a computer network". If you're using Grafana for monitoring your SaaSS app, then your users aren't interacting with Grafana, so you're fine.
If your SaaSS app surfaces a few small things from Grafana to the user, do you only have to open source the glue code, or the entire SaaSS application?
The entire application, to the extent that it's a single work under copyright law. If your app is a "mere aggregation" of e.g. grafana administration and other-service-administration components then maybe not.
If you're only using Grafana for monitoring but not distributing it to your users as part of your product then I don't think you need to make your own product AGPL.
I'm sure if I'm wrong I will find out very quickly, this is HN after all.
Certainly they should share - but must stretches things a little far.
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.)
I view the AGPL as a nonfree license; I think more permissive licenses are better, because I believe in software freedom. Companies are right to avoid the AGPL.
You believe in freedom for who, exactly? Freedom for the users of software? Or freedom for corporations who benefit from denying access to the source code of that software?
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)
You are dragging anti-corporate ideology into a very simple matter.
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.
There's nothing anti-corporate about it. The AGPL is motivated by the same thing that motivated the original GPL: making sure that users have access to fix bugs in the software they're using, like in the printer driver anecdote.
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.
That's a very simplistic and, I think inaccurate view of the matter.
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.
> My customers, for example, to whom I provide service, are not infringed upon in any way
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.
This is an interesting point. The original question was what if my database was AGPL, and it's source code was modified. If this database was used as part of a public (cloud-based) web-app, how could end users ever know there is a custom database? You are right: It seems likely that less ethical orgs would just lie and say they use the database unmodified. Thus avoiding the obligation to publish their database modifications as required by AGPL.
They will be when you go out of business and disappear, and they can't compile that same service to run on their own replacement server because you've withheld the source to your modification.
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.
I understand your concern. After Google started the negative press about AGPL, some companies I worked also followed suit. It felt like blind following, as almost none of my software faces the public -- it's mostly internal. In that case, AGPL is no concern. But internal training made a big point about "avoid AGPL... even Google avoids it!" Truly, it was F.U.D. nonsense.
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.
I don't know, but I expect that Google uses the OpenJDK release, which is identical to the Oracle JDK except it does not receive paid support from Oracle. I strongly doubt Google which has been fighting Oracle for years about a Java license would be paying Oracle for support. But stranger things have been known to happen!
I would wager that there’s a corner case in Google somewhere where Google is paying Oracle for Java. (After so many acquisitions, it’s essentially inevitable and not all will be eradicated in post-merger integration, especially if the product wasn’t the main driver of the acquisition.)
> 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.
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.
Why do I have to pick one? It's not a binary thing. Why can't developers say it's free to use under these circumstances, but not under others? Isn't that precisely the freedom you are otherwise championing?
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.
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 plausibly 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]
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.
How is it debatable whether AGPL is open source? Who is debating this? AGPL is so open source that it legally forces open source if you try to close it.
It seems like this one sentence of my message has become the focal point of it, which was not the intent. However, I corrected it to be more close to the truth, which is to say that it is merely controversial, not necessarily that its status as an open source license is debatable.
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 feel that the AGPL actually reduces the software freedom in a misguided attempt to close the ASP "loophole", as if offering an API from a private fork is something to be prevented.
I am a proponent of software freedom, and resultantly I view the AGPL as nonfree.
If I download some open source free software, and modify it so it does something differently on my computer, simply running "systemctl start httpd" should not potentially bring down the machinery of state copyright enforcement against me for not publishing my private patches.
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.
Yeah, and running a business on my own computer by providing API services to someone is not distribution of software. Running an API business shouldn't force me to distribute anything to anyone.
> Yeah, and running a business on my own computer by providing API services to someone is not distribution of software.
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?
What's the difference to the user? Any kind of selling software is "providing API services", if I'm invoking an API over the network then I'd like access to the source that's behind that API for the same reasons (fixing bugs, making improvements) that I'd like access to the source for an API I'm invoking on my local machine.
No, I don't consider it a problem at all. Nothing is being used improperly or against the spirit of free software when software freedom is exercised (by a service provider) - that's the whole point.
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.
Consider an extreme example -- someone takes LibreOffice and many other GPL-licensed programs and creates a business where you can only access them through the internet. They make massive (useful changes) to LibreOffice to the point that a vast majority of users switch to the online version because it is objectively better.
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.
Wow, this is a fascinating answer. I really like your thought experiment with LibreOffice. Imagine something even more nefarious: The whole LibreOffice team "quits" to start a company that does exactly the above. After building a large user base on their web-only version, they begin to charge for premium features. All while never distributing the GPL code ever again. To be clear to all readers: This is only a thought experiment!
Further: If we think about cloud-based AGPL apps: For the most part we are talking about web-apps, which, in most cases, will always include JavaScript running on the user's host. Does FSF or AGPL have anything to say about this source? I ask because I am thinking deeper about your idea: What if the not-so-LibreOffice was nothing more than compiled into WASM (WebAssembly) and run in your browser... so the "server" (SaaS) was doing nothing except serving a huge binary that you run locally in your JavaScript VM. Plus, the compile from C/C++ into WASM could reasonably obfuscate the original source. I do imagine a future where lots of commercial apps are nothing more than C/C++ compiled into WASM then run through a browser. This would provide some source code privacy (that vanilla JavaScript cannot provide today) and reduce the burden of installation issues.
The source for compiled JavaScript or WASM needs to be provided even with just the GPL rather than the AGPL. The loophole in the GPL only applies if the code is actually running on someone else's server and not the user's client.
Great point. To travel deeper down this rabbit hole: We might need something like "Citrix Remote Desktop" in a browser. Basically: Only sent graphical diffs over the wire. Then, browser is only painting pixels, not running the app. Everything else is computed remotely. Horrible scenario, but sadly might pass muster vis-a-vis A/GPL!
You cannot host it yourself because you don't have a copy of the source code -- all of their changes are private because the are not distributing the software to anyone.
Well, where the software is running changes the whole fact of the matter.
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.
> 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.
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.
> I don't see a license that forbids the generation of revenue ...
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.
> 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 ...
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?
I disagree that "it hasn't been provided to you". Imagine a regular desktop program that you can only use through RDP or VNC. Is that not provided to the user either?
No, only the outputs of the software are provided. The software remains wholly within the confines of the computer executing it.
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).
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.
The freedom to run the software for any purpose is #1 on the list of software freedoms that would be called open source. No ifs, no buts, no checking whether you qualify - software is free if and only if you can run it for any purpose, everything else comes only after that basic freedom. Various viral conditions only affect the licensing of developer changes (while still not restricting the developers right to make and use these changes), but violations of this condition impose restrictions also on non-developer users on non-modified code.
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.
> a company like AWS offering TimescaleDB purely as a DBaaS offering (not allowed).
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.
For what it's worth, TSL is a great source-available/restrictive-for-clouds license in my opinion, and I'm glad Timescale went the direction of moving from a more restrictive license to a more permissive license rather than the other way around.
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!
The whole issue arose from the claim that the Timescale license was designed to be less restrictive then the AGPL.
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.
That only makes sense if you agree with the open source foundation definition of restrictive. I don't. I think the ability to freely link to whatever other software is much more important to most people than the ability to run a *aaS. We never made any claims about open source only our opinion about what restrictive means to us.
That's fine. I wasn't taking a position. I was explaining why people were using Open Source as a comparison.
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?
That's fair but I was more replying to the OP that said "but it shouldn't be called an Open Source license". The point is we don't call our license Open Source.
Comparisons to Open Source and discussions of the pros and cons of both approaches are, of course, fair.
AGPL license clearly gives you the ability to freely link with whatever software you want. The only requirement is to share it with your customers.
Following your logic it could be said that MIT licensed software could not be freely used because it requires preservation of original copyright notice
>That only makes sense if you agree with the open source foundation definition of restrictive.
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.
I appreciate this debate, but where do we label the Timescale License as open source?
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).
I apologize, I was sloppy at skimming the licence, it actually does clearly and properly delineate the open source and source-available, describing them appropriately.
And ergo, I'd never use TimescaleDB. It's not less restrictive in any objective sense; it has different restrictions. It's apparently less restrictive to you, but it's much more restrictive to me.
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.
We do offer an Apache 2 only binary of TimescaleDB which includes our open source core (and excludes the Timescale Licensed features). In fact, many companies (Azure, Digital Ocean, Ali Baba, etc) offer this Apache 2 version to their customers.
> 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!
I'll mention I hate this style of conversation. You call up a vendor, and ask about X. They switch to talking point Y, without ever addressing the point.
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.
I prefer AGPL despite that, mainly because I don’t believe a license that discriminates on use cases in such a direct manner could be compatible with either GPL or DFSG. It’s hard to directly compare virality vs use-case discrimination as far as restrictiveness goes. However, I don’t believe there is a good argument that such licenses can be considered open source.
> _less_ restrictive than AGPL. It contains no virality.
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.
If the Timescale License is less restrictive than AGPL, then why not dual-license your product under the Timescale License and AGPL? Wouldn't that give everyone the best of both worlds?
Who I earth would argue that AGPL isn't open source? The kind of people who think open source = free lunch I suppose. It's probably the most open source licence there is.
Maybe it isn't so controversial that it is called 'open source' as it is simply controversial. Though GPLv3 + AGPLv3 improves one of the worse problems, which is compatibility with GPL-licensed code.
edit: And FWIW, I have dropped this claim from the post with a note, especially since it was not my point anyways.
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.
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.
I assume the answer to the "why" can be as simple as: being primarily a Silicon Valley software industry forum, HN knows what side its bread is buttered on (namely the side of cobbling together freely available software to make proprietary products).
Thanks for your answer. Yes, the answer is simple when you only consider the HN scope however, this is a trend I observe for much longer, well before I found here.
Maybe my observation on other places was a reflection of SV mentality, who knows.
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.
I could image that its the same with other corporations. In the end that might hurt the popularity of Grafana quite a lot.
While many are dismissing your concerns, I do think this is a valid point, at least to some degree. For example, Google institutes a blanket ban on all AGPL code:
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 :)
I suspect this is not a popular opinion, but Google's AGPL policy reads like FUD to me. From the first paragraph:
"...extremely difficult for Google to comply with..."
and
"...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.
More:
"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.
On the one hand you have a large department of battle-hardened IP lawyers who say that AGPL virality is overbroad and poorly defined, and on the other hand you have a FOSS advocate who says it's fine, so I guess we'll never know for sure!
Yep, but guess who will win corporate argument inside the company. You may advocate as much as you like, but no legal person will approve the general use of the software in the company. I guess some companies, like Amazon will find their way around the license and still be able to offer it as a service under commercial terms, but not the average Joe in the corporate world.
I think that's misunderstanding of AGPL. For internal use, AGPL does not require to share the proprietary part.
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.
I think this is a misunderstanding of how vague the AGPL actually is.
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.)
Most companies who use Grafana or Loki as part of some deployment would use an unmodified version, so the only AGPL specific clause, which you cite, would not apply and is irrelevant.
This kind of hand-wringing is what the naysayers were doing with GPL software in the 90s. That the GPL would never fly in business because lawyers would get hung up in "what if" interpretations that were never the intent or spirit of the GPL in the first place.
Not really. GPLv2 had more sensible legal language, even if that turned out to burn FSF intentions at times, but over time lawyers started digging in more into "derivative software" clause. Also a lot of the naysayers were fueled by RMS himself doing whack a mole by forcing projects to adopt GPL in not nice manner (and I'm not talking about them using something big or critical from GPL project).
TL;DR FSF is heavily responsible for the "GPL is viral" message sticking.
Sure! Saying that the parent’s “develop an proprietary UI and use Loki as backend” is a slippery slope to “user sees data that incorporates data served from Loki” which I am arguing could be interpreted as data that would require the developer to maintain a source repository for Loki under the AGPL.
I see now and yes the AGPL seems vague in that regard.
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.
Not everyone agrees on this point [1]. One relevant quote: "This is ultimately a question not of the GPL per se, but of how copyright law defines derivative works."
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.
That may be true, but a state of ambiguity is as good as saying its covered by GPL ... no organisation is going to look at that and say "that's fine, let's use it".
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.
This might be the case. However there is an additional risk and process component:
- 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)
did not follow the events of openvslam, wouldn't they be required to still release the source code of the previously public version as GPL? also once the doubt is there, why not rerelease as GPL?
How does this actually work towards your employees or 3rd party personnel (for example consultants) getting access to the tools - would you have to make the source code available for them and allow them to distribute the code?
But think about it. Anyone that use AGPLv3 software can demand the AGPLv3 license, including employees and contractors. Once they got it, they can freely publish it to the public because it's AGPLv3. Forcing NDA to not leak it to the public doesn't work here because it violate AGPLv3 license thus copyright infringement.
Cannot be helped - that's just fear of the unknown.
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.
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)
In a large number of cases, this is not an issue at all. Just like we all use GPL-ed kernel and a ton of other stuff. There is also no problem with making AGPL-based services available to customers. The caveat is that when you modify AGPL-based code, you need to make the source of these modifications available, too. For some reason, this scares Amazon a lot. Developers know that and use AGPL when they don't want to be screwed by AWS.
This is a myth that has been repeated far too often. Amazon had made no move on MongoDB _until MongoDB started using the SSPL_. No hosted-MongoDB, no MongoDB-derived products, nothing.
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.
I don't get why Amazon should be scared by AGPL. I mean all of their services run on GPLed Linux, why should they be scared by a GPLed Grafana?Even if they had to open-source their Grafana contributions, they could do this in a way that they are worthless for potential competitors (e.g. if the contribution depends on a proprietary Amazon system)
> they could do this in a way that they are worthless for potential competitors (e.g. if the contribution depends on a proprietary Amazon system)
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.
If I was in charge of the money, assuming it’s a reasonable price for on-prem Grafana, I would pay for a license to Grafana, just to not have the licensing stress.
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
I have no Idea. Realistically its probably not the license cost but the one time and the perpetual operational overhead associated with the license that's going to be the problem.
That makes zero business sense. Your first post is about the one time and perpetual operational overhead associated with operating under the prior FOSS license (yes, you’re saying it’s the new license that’s a problem, but since the situation arose while operating under the prior conditions then implicitly those conditions carried this very overhead). Operating under any license carried an overhead, unless you simply choose to not read (or to read and ignore) the fine print.
> Your first post is about the one time and perpetual operational overhead associated with operating under the prior FOSS license
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.
> 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.
I think you’re getting the essential facts but drawing a conclusion that is still wrong, at least for some people/companies.
“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.
There should be no problem with it even if you use it externally. It's about time companies stopped seeing open source as freely exploitable. Every company that uses open source software should be obliged to contribute, or pay for proprietary software.
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.
From Grafana:
"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."
It could still be with AWS in mind. After this change, they'll be in a better negotiation position vs. AWS, since AWS can't (as easily) threaten that they'll build their own competing offer.
> AWS can't (as easily) threaten that they'll build their own competing offer
Elasticsearch changed their licence for more or less this reason [1]. So it wouldn't surprise me if Grafana's motivation was to solidify their position against Amazon.
> Elasticsearch changed their licence for more or less this reason
And look how it's going for them. AWS very nicely forked elsasticsearch and now has the fork that seems to be gathering quite a bit of momentum. I doubt that AWS was even considering talking with them after they announced the license change.
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 https://twitter.com/TwitchiH/status/1384566382180896769), but those are only some, and they may change over time...
IMO, the ideal end-state from a software freedom perspective is that all software becomes AGPL. This change is a step in that direction, not only with the directly affected products, but for the reasons you mentioned, an additional pressure for more things to switch to it. Do you not like that end goal, or do you just think the side effects of the change outweigh the benefits of getting closer to it?
I think it's both a completely unrealistic end goal (we live in the real world), and I also think that the AGPL puts you into a hole where you can never get out of again if you decided that you now need different constraints. So I really much more prefer permissive licenses.
> if you decided that you now need different constraints
and if you own the copyright, you can always relicense it to suit. How _other_ people chooses to use this software is not under your control, even though you're the copyright holder. This is exactly what it means to have freedom.
If this incremental step led to a better world already, I would maybe agree... but I think it makes the whole ecosystem worse and worse, until some far-away tipping point is reached where almost everything is AGPL and can reuse each other again. And even then I'm not sure I'd be happy with the *GPL, as now you can't back out of it again in case you later discovered that it was the wrong decision, without getting the permission by all copyright holders.
Yeah, which is why typically those companies make external contributors sign a CLA that allows for copyright assignment and relicensing. Which is annoying if you contribute to a company-owned project under a permissive license to help make it big and successful, and then they change the license under you. But yeah, then they could switch it around in both directions if they get all the rights signed away to them.
you realize that if you contribute to a company apache project without a CLA, they can change the license out from under you to _any_ license that they want, right?
The way I've understood it is part of the point of CLA's is to allow license changes, and that without them no license changes are possible to community projects. Because all the contributors own the copyright to the code they contributed, which they licensed under the existing license. To change the license you'd need to contact all the contributors and get permission (so okay, not impossible, just infeasible). The CLA is getting that permission in advance, to let some controlling body change copyright later.
I thought the point of CLA's in general is to stop contributors from revoking their license, or claiming the entire program is a collaborative work and that they have joint copyright over all of it. I don't think either has ever happened in open source, but I believe is possible, at least in the US.
It seems you can always just run the AGPL licensed software and as long as you interact with it through the network or the database you won't have to relicense anything.
What you cannot do is:
1. change the AGPL software itself and provide it to end users in any form without providing updated sources
2. make a combined product and not provide sources for all of it under AGPL.
3. Also there is nothing to prevent you from releasing sources of your software dual licensed under both MIT and AGPL.
No, it is the network interaction that is specifically a software release trigger. "Interact" is a term encompassing a broad scope of behaviour -- any network message that causes an API to be called.
1+2 are plain old GPL. 3 is just a basic consequence of owning all the IP, but it isn't possible to release a patch to an AGPL under MIT.
AGPL has massively enhanced virality, which is the entire point.
> AGPL has massively enhanced virality, which is the entire point.
Yep, but AFAIK (not a lawyer I have just spent some time trying to figure this out) it doesn't affect other software over the Internet:
Some examples based on Friendica:
- Chrome won't become AGPL licensed by being used to access Friendica
- MariaDB won't become AGPL licensed by being accessed by Friendica
- any changes you make to Friendica must obviously be AGPL (if you let anybody use it)
- if you want to write an extension for Friendica it needs to be AGPL (but if you want you can also release it under another license)
- if you want to put your or someone elses open source or proprietary code into Friendica you must plan to release that code too under the AGPL (of course you can still release it under another license simultaneously but it must be available as AGPL in addition.)
The difference is that not in what it infects but how it spreads - kind of.
The practical effect is that all modifications to an AGPL code are likely to be encompassed as soon as you use it on the internet.
Obviously it can't change the license of other products, but other products trigger the virality. For example, Apache calls a module which triggers generating a graph from your custom grafana instance. Your custom code is now AGPL.
The ideal end-state is simply software freedom for everyone, no more proprietary software — and also no more malicious actions in the world, world peace, and universal love and compassion.
I do sincerely share these ideals, but which paths get us how far with which real-world trade-offs, that's more complex.
For ideal policy, I like this direction: abolishing copyright and patent law and replacing them with (A) mandatory source-release for all published works that need source in order to practically study and modify and (B) prohibition on DRM or other measures that technically limit freedoms.
Oh, I don't think either is realistic any time soon (long long run, who knows). I'll readily accept that there's a path that takes us slowly in the direction of everything-is-AGPL, namely making more software AGPL. No comparable path exists to slowly progress toward my ideal policy.
Wasn't the end goal of copyleft that all software becomes GPL 3 a few years ago? When will this stop? Why does 'freedom' in the Gnu sense require coercing all developers to use the same license?
> Wasn't the end goal of copyleft that all software becomes GPL 3 a few years ago?
Giving users access to software without distributing it to them is a recent technical innovation. The AGPL exists to give those users the same rights as more conventional software users. The underlying goal - ensuring that all users have the four freedoms - remains the same.
> Why does 'freedom' in the Gnu sense require coercing all developers to use the same license?
The copyleft trick only works that way. The goal is to ensure that all software users have the four freedoms; ideally they would be enshrined into law somehow, but failing that, a license is the best we can do.
Unless you are using your software as a resume and need more Github stars to land you interviews, this is a fine result if it gets you more money. Companies like money more than they like clout - and it won't help them to have a billion users and then be undermined by "AWS Grafana" and slowly go out of business. I much prefer companies choosing the AGPL over going proprietary, using a franken-license or going out of business because Amazon sucked out all the oxygen.
Edit: it just occurred to me that opting for popularity over money is "paying" yourself with exposure.
Why? If your software is already all available under permissive licenses, what does Grafana's new license require of you that you weren't already doing?
Oh nothing for now, and there's likely not going to be a viable alternative around for a while. But long-term, I don't see Grafana as part of the openly sharing ecosystem anymore, as with them being under the AGPL, but most other relevant OSS projects in the space being under permissive licenses, the whole idea of code sharing now goes out of the window (or rather, becomes one-way). I don't like the long-term implications of this for the ecosystem.
Maybe I want to keep my software under a permissive license? AGPL would also infect my code, no? And what if we're talking about proprietary code that doesn't have much to do with Grafana and only uses it for monitoring?
> 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
They're not making everything AGPL and seem to be aware of the kind of thing you're talking about. From TFA (emphasis mine):
> Going forward, we will be relicensing our core open source projects (Grafana, Grafana Loki, and Grafana Tempo) from the Apache License 2.0 to the Affero General Public License (AGPL) v3. Plugins, agents, and certain libraries will remain Apache-licensed. You can find information in GitHub about what is being relicensed for Grafana, Loki, and Tempo.
>™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.
While the whole project must be available under the AGPL, nothing prevent individual pieces to be under a more permissive but compatible license.
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?
If yes, than it's a really bad bad thing and I hope they change it.
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.
It's a very good point. IMHO copy right transfers are something to be wary off. Any company that practices that can do a bait and switch on the license. I see it has a hard requirement for long term success of an OSS community to have a large and active community of copyright holders.
IMHO who holds the copyright is more important than the actual license. Anything OSI endorsed should be fine. However, AGPL to me screams "talk to us about buying a special license if you want to use this commercially". That requires copy right transfers. AGPL without copyright transfers does not make sense for companies for this reason.
Usually part of the CLA is meant to allow dual licensing. The idea is that the company also makes the software available under a commercial non-viral license.
Hence if you contribute to a GPL project with a CLA, some companies could still publish your code closed source through a commercial license deal.
Don’t they have a license to your work and they can do however they please with it? E.g. sell it to X and Y for whatever they want and X and Y have no obligations to ever release anything back?
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.
Loki: Web Analytics Dashboard for NGINX
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:
1. Fork something Apache-licensed.
2. Build a community with "awesome" buzz.
3. Start a company, promising bells, and whistles.
4. Hire more and more people because bugs are piling up.
5. Now we need VC to fund all of that.
6. VCs are in charge now; they require "growth" and more paying customers.
7. Start using dark patterns. On the download page, hide the actual package download, redirect users to paying cloud or paying software version.
8. More frequent releases, more drastic redesigns, and changes. VCs need to see where the money goes.
9. VCs are still not happy. The company is spending more and more... relicense everything and force users to pay for the product.
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?
The Q&A suggests that "unmodified" distributions are not an issue. But if I distribute dashboards, custom configurations, etc - is that a "modification" ?
nope, that wouldn't be a modification to the AGPL-licensed grafana. you are free to do that.
plus, dashboards and configuration are inherently ("source available"), so even if one were to consider them to be modifications (which they're not), you are already distributing them in source form ;-)
> A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
Doesn't a product that offers grafana-powered dashboards "form a larger program" ?
If you're just exposing your grafana instance, no - and probably not if you're iframing them or similar. If you're actually embedding grafana into your program then yes, but that would be a strange way to structure a system.
Yes, I was thinking about an iframe, but I don't think the technological details matter, do they? As long as grafana is a core part of your product, then your whole product has to be AGPL, according to the license...
If your product is integrated closely enough with grafana to constitute a derivative work under copyright law, yes. That's a complicated and murky area of law, but it's unlikely that just iframing in an otherwise separate webapp as a metrics page would be enough to trigger it.
(Whereas if you integrate e.g. editing metrics and calling grafana's API to add them to a dashboard, at that point it seems far more likely your system would be considered a derivative of grafana - but at that point you really are implementing a grafana editor product (or at least a product that includes a grafana editor) rather than just using grafana to monitor a separate product).
Thank you for responding. What about the case where Grafana is embedded into an application, potentially even with a custom Grafana data source. That might be more of a problematic case?
That's probably a question for the courts (in terms of what constitutes a derivative work). If it's a generic proxy that just passes requests on then probably not. If it's deeply integrated with the grafana API then probably. Just like wrapper scripts around GPLed executables.
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.
> Hopefully over time rather than having everyone choose their own licenses we end up with some form of standardisation.
Yes; if you're going to do this, then using AGPL is so much better than flavor-of-the-week license.
> If the core companies maintaining them did not do this they would eventually die and these projects would slowly rot.
It sounds like you're suggesting that anything but hard-copyleft is doomed to die out, which is a somewhat hard argument to make in a world with lots of counterexamples (postgres, the assorted BSD OSs, kubernetes, Android).
Your choice of counterexamples highlights an important aspect. Three of the four are in fact outliers: Kubernetes and Android are both financially backed by Google. Android as a strategic advantage across a global market, Kubernetes as a plumbing layer enabling more businesses operate logically like Google. Sure, it's a CNCF product since 2016 or so, but it still enjoys Google's backing.
Postgres? They have a very specific governance model - a single company can not employ over 50% of the core contributors, to guarantee that the direction of the product is not taken over even by accident.
Three of the four are in fact outliers: Kubernetes and Android are both financially backed by Google.
Is that really "outlier" behavior? More and more important open source projects are prominently backed by a single large tech company. React, TensorFlow, TypeScript, Go, etc.
If you just look at the last decade, there has been more important work done as "single-sponsor open source" than under the GPL.
A few monopolistic corporations having dictatorial power over key technologies is a dystopian nightmare.
Those projects have ultimately the interests of the corporations in mind not of the users.
Ever wonder why overcomplicated technical solutions are hyped so much? Why does everyone and their dog need to run Kubernetes? Why is it all Maschine Learning instead of good old fashioned methods that would do much better? Well those corporation have just the fitting cloud computing offering!
Sure many of them happen to be useful and are simply for increasing the prestige of the company but let's not act like it is a good thing.
> "Ever wonder why overcomplicated technical solutions are hyped so much? Why does everyone and their dog need to run Kubernetes? Why is it all Maschine Learning instead of good old fashioned methods that would do much better? Well those corporation have just the fitting cloud computing offering!
"
Simpler explanation than some nefarious plan. Software engineers love to play with the coolest new thing over working with some proven solution that might have worked well enough. I think these corporation just exploit that with cloud offering. They don't really get to pick what people like (they try but suck at it) but have the money and resources to exploit whatever ends up being the popular new thing anyway.
Debugging Kubernetes does often feel like a dystopian nightmare, but you aren't forced to use it. I think it's a really good thing that this open software is available. As frustrating as Kubernetes is, for companies with medium-size or large-size deployments, it's really nice to have this level of orchestration software, and it's far better to have the option to use open source software than to be forced to roll your own because you have no alternative.
TensorFlow and Pytorch are similar. Yeah, people end up using machine learning a lot when they don't really have to. But researchers and developers can achieve a lot more when they don't have to reinvent the wheel, and machine learning has provided some really great things.
> A few monopolistic corporations having dictatorial power over key technologies is a dystopian nightmare.
These corporations are eating the world. They need not keep their source code closed, we're all employees, generating revenue for them.
One of the only reasons to keep source code closed is to retain your competitive advantage. They need not that when there's no competition, or a very slim chance of some appearing one day.
I'm joking, but it sounds a bit more true than I expected. Also, mind you, I'd rather have them publish code than not.
> A few monopolistic corporations having dictatorial power over key technologies is a dystopian nightmare.
I think "dystopian nightmare" overstates it. Monopoly control over particular technology is also a working definition of the the patent system. Hey, wait a minute ...
So TypeScript is Microsoft, and React is Facebook, but all the rest of those are Google. Shouldn't we be a bit concerned about that?
Like, it seems like it should be fine, given that TensorFlow is part of their core AI mission, and they're heavily invested in Go, and Android probably isn't going anywhere. But people once thought that Java and MySQL were safe in the hands of Sun, too.
I could add in Pytorch, VSCode, and Swift too. But yeah it's reasonable to worry a bit. It's great that competitors to Java and MySQL arose, and pretty much everything listed except Android (kind of a weird case) has a strong open source competitor.
Sometimes open source helps. SQLite3 is a good example. Being open source (and very good) helped it become one of the -if not the- single most-used pieces of software in the world, but having a closed-source 100% branch coverage test suite helped establish a monopoly on development of SQLite3 and prevented hard forks. End result: big tech had to sign up for the SQLite Consortium. It's... not a unicorn, and I've not idea how much D. R. Hipp and friends get paid -- certainly they get paid enough to continue doing their awesome work, and maybe they get paid like the rock stars that they are, but probably nothing like what they'd be worth if they could really monetize SQLite3 and IPO. The SQLite devs are probably very happy, is my guess.
But yes, on the whole it's true: most open source projects aren't SQLite, and most aren't going to many any money just because they are open source. Open source is a business tool.
While I want to disagree with you on the general principle (and gen220's sibling comment points out several really nice longer-term examples), I will certainly admit that you have a point. Cloud providers eating the margins, investing in streamlined operations and in general making the earlier on-prem consulting work less attractive has had an effect.
But I do note that your examples are from quite a narrow sector. TypeScript, Go and React are all languages. TypeScript is a nice facade over JavaScript, and React is ... well, a very powerful DSL.[ß] Go is very much a Google project, developed perhaps more out in the open than in a traditional open-source sense.
As I understand, TensorFlow was originally an internal Google project, which they at some point decided to open up. It may have had something to do with their TPU cloud offering or not. If we wanted to compare low-level language or domain material, we should probably take a look at something like Boost. People who do C++ tell me that Boost is a pretty good approximation of C++ standards' evolutionary playground. And if we're going for new languages, shouldn't we also include Rust? It was backed and promoted by Mozilla, but how much of its development was driven solely by Mozilla, and how much was done by the interested community at large?
ß: Our frontend team will probably want to roast me for that one, but there isn't much visible JS left in modern React code. Not for my eyes, at least.
> But I do note that your examples are from quite a narrow sector. TypeScript, Go and React are all languages. TypeScript is a nice facade over JavaScript, and React is ... well, a very powerful DSL.[ß]
> ß: Our frontend team will probably want to roast me for that one, but there isn't much visible JS left in modern React code. Not for my eyes, at least.
Can you clarify what you're talking about here with regards to React? I can see calling JSX a DSL, but React is a language now? And there's no JS / TypeScript in your React code base?
In a way, it is. Whenever you write some module in your project, you're effectively designing a language. Every function you add is a new verb, every type you define is a new noun[0] - and the relationships between them form the grammar. It may sound trivial, but I think it's an important and underappreciated point. Modularizing and abstracting is done by building languages on top of other languages.
We usually make a distinction between what is a "library" or "module" and what is a "language", by... it's hard to capture the distinction exactly, but my guess is that we reserve the term "programming language" for languages that a) define a large, highly composable set of building blocks, and b) have complex translation into a lower-level language, ultimately yielding executable code. Whatever the distinction could be, in reality, it's a spectrum.
--
[0] - Well, a piece of a noun phrase. Maybe. I'm not a linguist.
That's not what was asked. The query was, 'Is React a language now', i.e. specifically React, not just a general query like 'In general, is programming a process of designing little custom languages to solve problems'.
Replace React with angular, replace Go with .NET which is a platform, and it's not just the language entire stacks in .NET are available as OSS (fronted, backend, distributed computing).
that for sure is false... Google helped start CNCF but now plays a small part in its governance, they are just one board member like the 30+ others... they have no special voting rights...
fiscally the impact would be a membership fee which is a small percentage of revenue
The organization is fairly well diversified in terms of members and revenue sources but we appreciate Google's continued support in helping the organization grow, we think it's benefited them in projects like Kubernetes where the work is done by a larger community all working together: https://www.cncf.io/cncf-kubernetes-project-journey/
That's good, but Google is still the single biggest Kubernetes contributor. If they decided to take their ball and go home, it would leave the project in the lurch. It's a risk factor. Is it likely? No. But it's not outlandish.
Postgres looks like the only interesting entry here.
K8s and Android have a major corporation backing them, which extracts value from them in its internal operation anyway. They are such products that using them by competition commoditizes said competition. Android on like 95% of phones outside China has very important proprietary parts, making it hardly compatible with a bunch of top-tier apps.
BSD OSes don't do excessively well, with regard to market share and mind share. They are reasonably healthy though.
SQLite, Vim/Emacs, Linux, everything in GNU coreutils.
All of the Apache projects (some to more/less an extant than others).
Most programming language implementations (e.g. CPython). Memcached. WireGuard. SQLAlchemy. Web Frameworks like Flask, Django, Rails, on and on.
There are many open source technologies that do not seek to capture the value they create with licensing hijinks.
I don’t think it’s an accident, that the ones that persist across generations are generally not structured as VC-backed firms, who care a great deal more about “value capture” than the average programmer capable of building such foundational systems. Usually “value capture” is correlated with “consumer harm”, and so they’re replaced over time.
From your example, K8s will definitely outlive Google. Hard to say about Android.
It’s just my opinion and I’ll be happy to be wrong (because it means something better will have supplanted it).
But I don’t think there’s a significantly-simpler, mature abstraction for doing container orchestration, than K8s.
K8s’ main advantage/stickiness factor, is how abstract and modular it is. It’s an opinionated Kernel that gets most things right and has a huge ecosystem of tools built around this kernel.
It has a very similar set of stickiness factors to Linux, imo, although the origin story couldn’t be more different of course.
I think if anything replaces K8s, it’ll take a Linux-like shape. But K8s gets enough things correct (licensing, api, modularity) that it’ll be hard to replace it wholesale.
I did not mean to say that open-source software (broadly, MIT-licensed) and free software (broadly, GPL-licensed) don't do well! They do, and I'm happy about it. Some have commercial entities around them, but most don't.
What I was trying to say is that FOSS was never about capturing commercial value, and always about capturing the value of the freedom to inspect, share, and tweak.
In this regard, going AGPL is preferable to what Mongo or Elastic did. They basically turned to commercial "source-available" offerings, much like mainframe software from 1970s.
Ah yeah! We totally agree! I was finding it hard to respond to your comment initially because I didn’t know which point you were trying to make, mentioning Android and K8s.
I totally agree that the “we are now AGPL” route is preferable.
Why the toxicity? AGPL was deemed by many to not be clear about what it was trying to accomplish. As I read in the various exchanges and articles around the time SSPL came out, I think they were just trying to clarify AGPL, not getting any more restrictive than AGPLs intent. And how would moving from a license that said you couldn't run a service bureau for free to something that says more clearly that you can't run a service bureau for free make MongoDB more money?
Sorry you’re right, I was being petty. I’ll explain my perspective in hope that we can learn something from this, but being flippant like that wasn’t justifiable. That’s a lesson in itself! :)
From my perspective, MongoDB (the company) “wins” by getting more people to purchase their product, and making MongoDB (the software) better is only one of the many possible dimensions to optimize in pursuit of this goal. When I see a license change by such a company, my null hypothesis is that somebody realized the marginal cost of changing their license would capture enough value (even if a smaller pie) to offset any potential harm to the community, brand, etc. It’s perhaps too cynical a view, and I’m open to learning otherwise.
I do agree that the AGPL is a mess, and there seems to be a consensus around this fact. It isn’t the correct license for a VC-backed firm trying to SaaSify a FOSS project, which is what MongoDB learned. And since SaaS is ostensibly its target audience, AGPL doesn’t come away looking great.
More broadly, I’m concerned for the developer productivity that’s wasted (from a humanity/society POV) in the corporate-driven pursuit of defensible and sellable intellectual property. Nothing wrong with making money, but I think it’s a tragedy that capital assets aren’t broken down, recycled and repurposed in the software world like they were in the industrial world.
From this angle, I view the GPL as a positive influence towards making our work less repetitive and more reusable. It makes me sad to see MongoDB move away from any GPL-based license, even when it’s in their shareholders’ best interest, because it means all the dev hours invested into MongoDB post-2018 likely will have been invested in vain.
But maybe I’m wrong and their new license means their software is still salvageable for the future, when MongoDB (the company) no longer exists! I’d love for that to be the case.
I really appreciate the constructive response back.
From reading all the press, it feels like MongoDB did not do this to garner more revenue but to instead prevent open-source parasites from causing MongoDB to lose money or even go out of business. When I read Eliot's posts in 2018, it feels like he's trying to stay in business, not be greedy.
From a commercial point of view, databases have been shown to need management. Maybe someday somebody will write a database that has a magic simple-to-use endpoint, stays up 100% of the time, and doesn't require a cadre of people dancing around the database chanting spells to operate it. None to date... So the cloud providers capitalize on that need, and wrap control planes around databases - often hurting the people who are working hard to innovate on that software - and deserve to be paid for their work.
As to harm to the open source ecosystem, cloud providers wrapping managed services around databases has been shown to stifle innovation on those open source products. I.e. why would anybody want to improve PostgreSQL or MySQL when Amazon Aurora PostgreSQL and MySQL exist, CloudSQL and Azure SQL all exist - and may or may not take the changes - and even when they do, it takes many months or years.
Finally, I guess I'm puzzled by your last two paragraphs.
You mention that "all the dev hours invested into MongoDB post 2018 likely will have been invested in vain" - why? They go into the community edition, which anybody can use. They go into the EA and Atlas version, which customers who want enterprise-quality software with enterprise-quality support can use.
Your discussion implies MongoDB's license (and Elastic and now a host of others) prevents people from contributing to MongoDB. It doesn't. Or that it prevents them using MongoDB as much as they want. It doesn't, with one exception - and that exception probably affects <0.01% of the users of the software. The MongoDB license (and the Elastic and TimeScaleDB and many other licenses) don't even prevent anybody from wrapping up the software into a cloud service and offering it for money. In fact, many companies (SAP, IBM, Tencent, Alibaba, to name a few, apparently do). It just means you have to talk to the company before doing it.
I personally love MongoDB and I think the SSPL ended up preserving the company and preserving innovation, which is good for the open source community. At least it's not a complicated mess like MySQL and MariaDB.
That said, I'd love to hear more about how SSPL actually damages anybody in a meaningful way. I haven't yet seen anything except a philosophical argument. I'd love to hear it.
I agree that, from a commercial point of view, databases have been shown to need management.
> As to harm to the open source ecosystem, cloud providers wrapping managed services around databases has been shown to stifle innovation on those open source products
I don't think we agree on this. I think PostgreSQL has improved dramatically in the past 5 years, coinciding with (but perhaps not caused by) its increased adoption by AWS customers. The more customers/users FOSS projects have, the more information they have to work with, and the more interested developers they have to draw contributions from.
But it's OK, we don't need to agree on this point. We can adopt the axiom "MongoDB is more innovative because they have a non-OSI-compliant license". Again, I don't think this is necessarily true, but I can concede it so it doesn't distract us.
> You mention <quote> - why?
The reason requires stretching our imagination just a bit, but I hope you won't see it as philosophical, since real people plan against scenarios like this. Let's say that, today, MongoDB the company is benevolent, and happy to permit anybody who asks to operate their software. Everybody's happy.
At some point in the future, there's some management change, and the company that owns this IP has decided that the best thing they can do is box-in the customers they have, and make other service providers' lives as legally difficult as possible, thanks to the license they switched to in 2018.
Now, in the future, if you want this database management service that we agree is important and necessary, and you don't want to use MongoDB's platform, you're out of luck.
If you stick to databases with an OSI-certified license, you never have to make contingency plans for this future. There will always be a vendor for code with this license, as long as there's sufficient customer demand, until time immemorial.
Because you can not control the tail risk of MongoDB becoming an Orcale-like company (or, for that matter, being acquired by Oracle), you can not rule out the possibility that all vendors will be excluded from offering MongoDB as a service. You need to plan for the worst case, and treat it as a time-bomb.
You might consider this a philosophical argument, but, practically, this is why OSI has rule #6, and it's why the SSPL (and Elastic License) are not OSI-certified.
> Your discussion implies MongoDB's license (and Elastic and now a host of others) prevents people from contributing to MongoDB. It doesn't.
Correct, it doesn't. It prevents them from contributing to software with a license that does not "Discriminate Against Fields of Endeavor" and does not "Restrict Other Software". Which again, doesn't seem like a bad thing today but opens up paths that are otherwise avoidable.
Even if we buy the innovation argument, and even if this change was made with the purest of intentions, it's noncompliance with OSI standards makes it not worth the tail risk for people who want to pick software today that will be serviceable in 15 years.
I get your point, and thanks for the discussion. My thought is that even software with an OSI approved license can be moved to a non-OSI license at any time. So you can't actually insure against the dystopian future you are concerned about. The only way to insure against that is if the software IP is not owned by a company. It will be interesting to see how this plays out with TimescaleDB, Confluent, Starburst, Grafana, and a host of others - none of their code is owned by a foundation (like PostgreSQL is) but is instead owned by a company. And those companies have ( and will continue to ) do thing that protect their customers, employees, and stakeholders.
Thanks for the clarifications - I understand now better the concerns of the OSI-favorable community.
> I did not mean to say that open-source software (broadly, MIT-licensed) and free software (broadly, GPL-licensed)
Sorry, but free software IS open-source software. I take issue with how you're presenting these. Perhaps a better term would be liberally licensed software, as opposed to copyleft.
It's only hipster sentiment if it is on principle ("this is popular -> I don't want it"). It sounds to me like just an observation in this case ("it so happens that the most popular things are the ones I want least"). The "almost" clarifies this.
Market share/mindshare is almost an inverse measure of quality at this point!
If you only compare things above a certain quality threshold, That's true of any creative endeavor. Not too many people will say that Mcdonald's has the best burgers, or the pop singer of the week is their absolute favorite.
AGPL is a license qualifying the criteria of OSI's OpenSource definition and FSF's Free Software definition.
A key point there is that a user can use the software quite freely without restrictions only with the caveat that modifications have to be made available to users. (AGPL is slighqtly more complex)
Many of the "modern" licenses allow to look at code, but prevent distribution and/or modification and/or usage. They typically aim for any "proper" usage requiring a commercial license and not giving the guarantee that code can be fixed in case the original vendor stops working on it.
Another major issue is remixing and license compatibility. AGPL is part of an ecosystem. Anything MIT, BSD, current GPL, etc. will freely mix with AGPL.
Most of the other licenses, I can't use in any of my projects without running into license compatibility issues.
Notably AGPL is also DFSG free, meaning that AGPL licensed software can be included in Debian and its derivatives. I believe its also fine in other major distros (RHEL/SuSE etc).
I don't value OSI's stamp of approval since they were explicitly founded to coopt FSF's effort and make it more corporate friendly. Obviously corporate lawyers would disagree with me.
A license that allows all typical freedoms except "use the software to start a SaaS using proprietary infrastructure" is fine by me.
While there are significant ideological disagreements between the OSI and FSF, when it comes to FOSS licenses their definitions are mostly equivalent. There are very few licenses that are recognized by the OSI but not by the FSF, and vice-versa.
Proprietary infrastructure = All infrastructure essentially.
So you're fine with a license that can't be used for SaaS. So basically you're happy for the commercial internet to be powered by proprietary software - with all that would mean for free software.
That's pretty much the same as AGPL. A tell about OSI's biases is that AGPL and SSPL are basically the same but since Amazon's propaganda engine ramped up against SSPL it was labeled as somehow completely out of bounds.
How are they pretty much the same? AGPL only require the changes to the software itself to be shared under AGPL and it's apply the same requirement for everyone.
SSPL require to release source code for every piece of your infrastructure if your business model seems like Amazon. This is descrimination which both FSF and OSI are not allow.
I don't care so much about the AGPL specifically, but it's a single known license, rather than every time I find a new project having to find out what "interesting" license they cooked up this time.
yes but afaict SSPL was kiiinda becoming a de facto "f off AWS" license that was generally becoming standard. thats all any of these vendors want, they're not coming up with new licenses just for shits and giggles.
standards evolve over time, it was entirely possible that Grafana could have thrown its weight behind SSPL and helped legitimize it more.
This would've been nice. I think we are not far from the OSI having to recognize that SSPL is the future whether they like it or not, and possibly moving from obstructionist to a more constructive point, where they help evolve the SSPL to address their concerns, while recognizing that it is a copyleft open source license.
The only thing that differs between SSPL and the AGPL in terms of being open source or not is that one particular group of people has decided one is Open Source(TM) and one is not.
I assume you mean the OSI. But it's not just them with a problem with the SSPL. Debian and Fedora both reject it too, independently, for being non-free.
But it is free. It solely conveys an expectation that you also release related tooling for free as well. If it's not a free license, the AGPL isn't either.
It closes the server loophole in which companies will use and modify Free software they're using just on their servers, but never make those changes available to clients, which is not restricted by just the regular GPL.
>Yes; if you're going to do this, then using AGPL is so much better than flavor-of-the-week license.
I'm not sure I agree. Yes, standardization is a good thing and AGPL is the "known evil", but having read it I do think that it is a very very complex piece of text - personally I'd go so far as to say that it is close to incomprehensible and would prefer pretty much anything else.
But even aside from that the sheer number of companies that point blank ban AGPL licensed software from being used in their stack could be used as an indicator as well. Though this may be due to the common misunderstanding that it is a viral license, which just goes back to my prior point on it not being clearly worded.
I won't even mention alternatives, I'm sure they all have issues, it is a complex topic, but if it were up to me the AGPL would not be my first license choice.
The question is whether the alternatives are any better; IMO, this is unlikely (all the others I've seen make tradeoffs that I'd consider poor, personally).
I think the virality and companies not liking it is the license working as intended, honestly; it's supposed to be viral, that's the point of copyleft, and obviously companies take issue with that (although I agree that some of this might be misunderstanding scope / what it infects), but that's not a bug, it's the license doing its job and companies making decisions based on that.
My personal opinion (and it is really just that - I cannot prove anything I say here) is that for a lot of those companies it is actually the risk of not being able to tell exactly what the AGPL would affect that is the main factor.
As I said, I'm explicitly not mentioning any alternative here because they all have issues, but the AGPL's wording is much more complicated than most and that (perceived) insecurity around it is my main criticism.
Arguably selling support/services to a company using that product would help pay for developers that work on the product, which to me sounds like a benefit.
With the AGPL that would require dual licensing, and that draws flak as well.
I think the notion that OSS means there cannot be any money involved simply cannot hold true anymore these days. Software has become extremely complex and requires dedicated developers working on it - and they need to eat.
We are currently seeing a lot of companies changing their licensing model for a reason - because there is not currently a middle ground between OSS and a working business modell that the OSS crowd doesn't hate.
That being said, I'd love to be proven wrong here!
Open source is a business tool. There are many business models where open source can be useful. PG has such a vibrant user _and_ developer community that it pays to be a freelancer in that community and there's room for lots to play. SQLite3 is very much the opposite: it has _no_ developer community outside the core team, but the business model is the SQLite Consortium, which pays for the core team, and the closed-source test suite whose existence prevents hard forks.
It makes sense to use attractive-to-end-users licensing at first and later switch to a license that helps lock in support bucks. Call it bait-n-switch if you like, but even the SQLite folks did it, only they didn't do it with the _license_ but with the _test suite_ -- either way they made it really difficult to play in their space and/or fork.
Anything not hard-copyleft (GPL, AGPL) or source-available (BSL etc.) is going to be embraced, extended, and SaaSified / paywalled. Eventually the open version might get abandoned since its authors will get tired of providing free labor to billion dollar cloud companies.
I don't think you'll see a lot of major projects under super-liberal licenses in the future. You will see such licenses for libraries and other components.
> I don't think you'll see a lot of major projects under super-liberal licenses in the future. You will see such licenses for libraries and other components.
And that seems fine, at least if you subscribe to the Unix philosophy of composability. Honestly, I love Django, but for some projects I'd love even more to use just Django's ORM without all the other stuff (which I also like, but is irrelevant for some projects).
> Anything not hard-copyleft (GPL, AGPL) or source-available (BSL etc.) is going to be embraced, extended, and SaaSified / paywalled. Eventually the open version might get abandoned since its authors will get tired of providing free labor to billion dollar cloud companies.
FreeBSD is 27 years old. Postgres is 24 years old. SQLite, which is placed in the public domain, is 20 years old.
That's true -- well, you're obligated to release the work under GPL -- but quite a lot of libraries are LGPL licensed which allows a proprietary application to link to it.
Problem: the letters "G, P, L" are toxic to a huge number of companies. This has nothing to do with the controversy around Stallman. It's because Microsoft spent over a billion dollars in the 1990s mis-educating the market that GPL software is "viral" and if present can "infect" non-GPL software with the GPL license.
The problem would go away if you renamed the license to something else. It's that stupid.
A lot of the flavor of the week licenses exist for this reason, as well as to address some of the weak corner cases of the AGPL.
The GPL is neither long nor complex. If a company won’t use GPL software because of Microsoft’s efforts, but would use that software under an identical license called something else, I think that company will experience many other difficulties on their journey as well.
For shrink-wrap software, GPL can be an issue. For hosted software, it’s generally not (which is why all the desire to make other licenses, including AGPL).
> Problem: the letters "G, P, L" are toxic to a huge number of companies.
Too. Effing. Bad. These companies can either figure out how to work with FSF-authored licenses or they can go make their own alternatives. I have no sympathy for them.
Or for devs that make excuses for this attitude. They deserve to be force-pushed onto software like when Apple decided to ship zsh instead of bash because they didn't want GPLv3 in their OS. Or that whole Rails brouhaha last month.
Companies should not be trusted with permissively licensed software. You don't get to play shell games with public access.
It doesn't adequately handle the SaaSification case, which is when someone hosts the software behind a paywall. It only handles the "Tivoization" case when someone ships the software inside a closed source box.
Are you sure? AGPL was written expressly to deal with SaaSification. Wikipedia seems to agree with me, at least[0]:
"Both versions of the Affero GPL were designed to close a perceived application service provider (ASP) loophole in the ordinary GPL, where, by using but not distributing the software, the copyleft provisions are not triggered. Each version differs from the version of the GNU GPL on which it is based in having an added provision addressing use of software over a computer network. This provision requires that the full source code be made available to any network user of the AGPL-licensed work, typically a web application."
Isn't the purpose of GPLv3 to handle Tivoization and AGPL was made to handle server-side sort of use-cases?
If I use AGPL-licensed software in a SaaS type of environment, I still need to release the source-code even if I'm not distributing the software directly, correct?
Curious about how the GPL is not viral... Unless you go through the hoops of making sure GPL code is sectioned (through a shared library or whatever) in your codebase, then your software becomes GPL, no? I mean sometimes you can avoid it so that the GPL project stands at an arms length to your own code but it is not always trivial. You just don't get to include the code in your project and not get "infected". The fact that you can sometimes circumvent the infection does not mean it is not viral because I believe it violates the "spirit" of the license anyways.
Your software never "becomes" GPL, no matter what. That's the problem with the "viral" label, it's somewhat of a misnomer that implies that anything that comes into contact with it gets infected and suddenly all your private IP _has_ to be released and anyone can just take it an fork it.
In reality, your proprietary code can only be GPLed if you explicitly release it under that license.
What people are confusing is that it is a violation of the GPL to release binary code that links (statically or dynamically[1]) with GPL-ed code without also releasing that code under a compatible license. This is where the "viral" label comes into play, since the easiest way to link against GPL code is to just make your code GPL as well. But it _does not_ mean that if you mess up and release a binary blob with GPL code in it that you've given up all rights to the non-GPL parts.
Sorry I still don't get it. Please tell me which step I am getting wrong:
I have my own proprietary code. I decide to make use of GPL code. Then I distribute the binaries. Now I have to make the source available, correct?
This source that was just made available (that includes my "proprietary code" and the GPL library I used) needs a license. At this step, I already lost my proprietary code and made it public - which might be unacceptable for some, but that in itself does not make GPL viral. Now that I need to license the released code, what options do I have? Can it be less permissive than GPL? My understanding has always been "no".
> Now I have to make the source available, correct?
Nope! That's one way to fix the licensing issue—but you're not forced to do that.
Another option would be to immediately stop distributing your binary and not distribute it again until you can replace or otherwise excise the GPL code that caused the licensing issue.
Eh, that is a bit dishonest argument. "I want to keep distributing, and I want to keep using this code" are the immutable assumptions of my argument. My point is, with those assumptions in place, there is no way to NOT propagate GPL in the entirety of the work - was my point. That is OK since GPL is intentionally made that way. Take it or leave it deal. No one is entitled to anything, if people want to distribute their work as GPL, that is up to them to decide after all. I am only discussing the virality aspect of it here as a separate fact.
And how does immediately stoping distribution help, legally? If I have already distributed the binary, the recipients are already entitled to the entire sources, no? Or does GPL have a "I have learned my lesson" clause?
I think you are wrong here, if I have 2 files, first is GPL and the second is proprietary and you steal them from me and use them then what license is your code now ?
The correct answer is that your code stealing is not transforming the product into GPL or into my proprietary license. If I catch and ask for money from you you have more options with the GPL code then with my proprietary code. With the GPL code you can just GPL your code changes, maybe the entire product but you are not forced to pay me anything. With the proprietary license though you don't have the option and I can make you pay.
So if you like that much the "infectious" word, you should add an "optional" modifier , you can always not GPL your changes, remove the "stolen" code , pay damages? (not sure if this ever happened).
What I observer the issues with GPL like software is lazy developers and companies that would like to "npm install" solutions and skip doing the work.
> 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. […] It's a very measured and thoughtful way to ensure the long term progress and continuity of these projects.
I completely support the right to chose your own license and how you want to sell and use your own code, but let's be honest here. This is done because investors have discovered that it's possible to earn money on services around Open Source products, and Grafana Labs has gone all-in on this approach. Now they need the relicensing in order for the business model to remain viable. We're lucky that the code remains AGPL, but notice that they are still not committed to ensuring that all the code will remain AGPL (i.e. they still want CLA so they can relicense later).
AGPL is nice and all but for contributors this does not really matter at all because of the CLAs.
I will never contribute to projects which reserve the right to relicense, e.g. take ownership over my contributions, however small or big they are. I think companies will do the same.
If they would remove the CLAs, they would signal to companies and contributors that they are serious in providing an open ecosystem, to which other people contribute willingly "for free". But currently they are not, likely because they fear competition.
They are a much higher barrier to entry for a lot of contributors. No, they're not all the same, but they make it harder. Each CLA needs to be reviewed and approved by company lawyers. It's kinda like creating a brand new OSS license that way.
To use a concrete example, the Google open source CLA is awful. At my previous job our lawyers refused to sign off the Google CLA. One of my engineers wrote a patch that we wanted to get upstream. Since, it would be generally useful.
Basically, the patch could never be merged, because we had a legal stalemate between us and Google.
I would highly recommend using https://developercertificate.org/ instead. This is what we use for Prometheus. It's also used for GPL projects like Linux. It's simple, standard, and used widely.
Does clause (d) allow the project to relicense its code? Because as far as I understand, that is the reason that GNU tends to have CLAs on their projects.
I as an individual on my free time would never sign any CLAs, but would be happy to contribute to Apache Licensed Projects.
Why?
Because CLAs make the sharing agreement asymmetrical. I want to provide my changes under exactly the same terms as you are providing your code. Additionally to the fact that CLAs are typically layed out in favor of the corporation and not of the contributor, they cause me to read that CLA, interact with it and most likely misinterpret it, because I'm a dev, not a/my lawyer. With common licenses I know what I'm getting and independent lawyers have created them, weighing the benefits of both sides.
Of course, the last argument is not really applicable if you depend on widely-known CLAs like the Apache CLA (I use widely-known because I have heard of it, but I really have no clue what it entails and have never signed one).
The issue of apache projects vs grafana is easy. I have never contributed to Apache projects and would hesitate to do so if I have to sign a CLA, but the issue is not as big because the License (AL2) of most of these projects already somewhat permits relicensing and AL2 is already a pretty weak license, because it is not infectious like the GPL family.
But allowing relicensing on an AGPL project means that if I change anything on your code then I have to publish it. If you change anything you don't have to publish your changes (because you can relicense). This is not contributing on equal terms, so I'm out.
Of course, one can also argue that you're doing much more work so the asymmetry is justified, but my work has not less value than yours and your benefit in this relationship already is determining where to go with the project.
That said, I am not a lawyer and my understanding of licenses and CLAs is very limited and could also be wrong. I'm not even accounting for different legal environments/jurisdictions here.
I think they are saying that they don't want to give the project owner permission to relicense their contributions to an incompatible license. Relicensing to a compatible license should be no problem.
do you think that earning money or having a viable business model is a bad thing?
look at our actions since the inception of the company, as well as our "big tent" philosophy; i think they speak for ourselves.
we built a sustainable business over the course of 4 years, prior to raising a dollar of VC money. we raised VC money to go even faster.
most of our VC money goes to paying our employees.
most of our employees are engineers.
most of what our engineers do is open source.
if we don't build a sustainable business, who will develop the software?
the overwhelming majority of development on things like grafana, loki, tempo are done by grafana labs employees. plus, we are the main contributors behind other OSS projects that we didn't create and don't own (like prometheus and cortex).
> do you think that earning money or having a viable business model is a bad thing?
Nope, but I kinda thought the whole idea behind open source is that no one company or group of companies/licensees gets privileged access to or control over the software, including any company that happens to have the same name as the piece of software.
I realize that “open source” and “free software” and other related labels mean many things to many people, and some people have very strong opinions about what does and doesn’t qualify, so I’m not trying to be prescriptive about what these terms “really” mean, but to me this is a pretty important almost self-evident part of it. If you want to sell proprietary software just do that!
> I kinda thought the whole idea behind open source is that no one company or group of companies/licensees gets privileged access to or control over the software, including any company that happens to have the same name as the piece of software.
That is not, at all, the idea behind open source. The idea behind open source is, basically, 'you are free to do whatever you like with the source code, as long as you credit us for our work and don't hold us responsible for any effects of using the work'. That's it. There is nothing about companies, corporations, licensees, who has control, who has what name, etc. All of that is irrelevant to open source at its core.
It's true that many people add on an open governance model (e.g. Rust) and mistakenly think that that is part of open source. It's not though.
I don't believe this is a realistic take on open-source. There's not a single successful modern OSS project that's not basically controlled by a single organization (or was not at some point in its conception). Control can take multiple forms: most of the time, it's directional to the project, since the roadmap of the company managing the project dictates what gets done. Sometimes, it's in the form of how you can use the project. The great thing is that you can always fork the project and create a version for which the new rules/direction does not apply. The challenging part is making that a project where active development is actually happening.
Certainly, there's things like the Linux Foundation that serve as places where projects can live without formal control by a single organization, but in practice, orgs that commit most of the code control things (for better or for worse - I'm not saying this is a good thing)
> I don't believe this is a realistic take on open-source. ... The challenging part is making that a project where active development is actually happening.
Well, yeah, that’s just the most obvious gut reaction everyone has when they first hear about open source software: Why in the world would anyone put work into software that’s free for everyone to use? My impression is that open source advocates have put tons of work into explaining why this can and does actually work and can result in software that’s better than proprietary alternatives.
I'm glad you were able to find a FOSS license that's able to support your business. I think grafana lab's use of AGPL will help encourage its adoption by other businesses wanting to make money in free software as well.
As a commercial consumer of FOSS, AGPL has been troubling for me.
As a non-commercial hacker, AGPL has been fine for me: GPL is fine here, and distribution as defined by SaaS or tarball is equivalent; I share back.
My opinions are that non-commercial FOSS projects probably shouldn't choose AGPL but that small-ish commercial FOSS projects (like Grafana, et al) probably should so that big commercial entities don't eat their lunch.
AGPL seemed like a tool that was mostly ahead of its time but is nice to have now.
Neither earning money nor having a viable business model are bad things, but that's about as straw as a strawman argument comes. A business model existed before these changes. As far as I can tell, though, it's not _captured_ the value that the founders and investors seem to think ought to be their wealth.
Grafana Labs and all these other companies have recieved both value add and goodwill free marketing from open source contributions and communities, and I don't see these companies being at all interested in figuring out who/what they've gained value from, beyond the currently existing company, in order to make a profit and benefit the founders and shareholders.
I'm not against AGPL. I'm against the relicensing of software made in good faith against one model of OSS being discontinued and basically forked by the most prominent for-profit company that have hitherto received the significant benefits of both contributions and goodwill that being more freely open source brings.
By relicensing you've probably significantly reduced the number of companies willing to run future versions of your software, and the number of companies willing to build businesses off of extending it and offering that value add, while still potentially contributing changes upstream. You're going to slowly eat away at that good will and the number of people asking for your product internally, since fewer and fewer people will remember the benefit from their last gig.
I could be wrong here, only time will tell, but I honestly don't think this is a move that increases the long term sustainability of your business model. If anything, I think it's going to be detrimental in the long term. Perhaps even in the short term.
Switch to the impacts view and sort by "days active". I think it is safe to say, any developer with days active >= 25% is a grafana labs employee or somebody that really loves to contribute to grafana because they are being paid to.
> Now they need the relicensing in order for the business model to remain viable.
This is exactly what the parent is saying though. They're going through this process to ensure that their business remains viable and they can continue to build and support the project.
I still think this sentence here is not quite precise enough:
> 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.
To me this sounds like the relicensing is done so that a few programmers finally can get paid for their hard labor while maintaining critical software we're all using. What's actually happening here is that some creators have convinced a few investors that they'll be able to give a huge return on invest by building up a sales department around the product. And now the realize that they're not able to accomplishing that with their original license.
It's a perfectly acceptable business strategy, but it's not necessarily the only way of running an open source project.
I'm still hoping that we (the open source community) can find even better ways of ensuring high-quality software remain open source without being so dependent on current mindset of investors.
This seems to lump relicensing to better FOSS licenses like AGPL in with relicensing to bad non-FOSS licenses like the Commons Clause, SSPL, BSL, Redis Source Available License, and Anti-996 License. You're right about the former, but the latter is screwing over the community.
Serious question: How is the community impacted by SSPl, BSL, etc? The average end-user who makes no modifications and is not reselling as-a-service is fine, there is no additional burden with either AGPL or the non-OSI-compliant licenses.
How does the AGPL screw over the community less than the other licenses? AGPL is problematic for a slew of reasons, lots of corporations (whether or not you agree that for-profit enterprises make up the bulk of the "community" is a separate discussion) disallow it entirely (mostly thanks to Google's precedent).
The community is impacted because there isn't an intellectual commons to build from.
The OSI or FSF-approved licenses form an ecosystem. I can have a project which mixes AGPL, GPL, and BSD code. I can make that part of the next version of Ubuntu. I can borrow bits of code. It all works together. If the goal is to have a computer running free software, AGPL builds towards that goal. If the goal is to use the code in new and unexpected ways, AGPL builds there.
The non-OSI licenses are walled gardens. Even the ones which nominally allow remixing require me to drop a few grand on a lawyer before remixing them (more grand if it's international).
AGPL is toxic to some corporations for mixing into their proprietary projects, but the commercial dual-license takes care of that. Most corporations don't mind spending money.
AGPL also gives a long-term sustainable pathway if the original vendor goes under or goes evil.
I don't see how AGPL is really problematic in any way for something like Grafana.
Most people, and companies, that use this will just run an unmodified Grafana container, maybe with some plugins (not of their own). AGPL doesn't come into play here (the software is not modified).
This change would really only impact a company that takes Grafana, puts a bunch of patches on top of it and wants to offer that as a SaaS. Those guys could still even do that, they'd just have to publish their patches. Or, quite possibly, just pay for a commercial license - a lot of GPL/AGPL software is actually dual-licensed, with more ore less "dowhateveryawant"-style, paid licenses.
Blocking competition among providers of your app as a service is a burden for users. Users would benefit from being allowed to use the provider which best meets their needs, rather than being forced to use the provider who happens to be allied with the copyright owner.
AGPL tries to ensure that third-party providers are at least sharing their development efforts to the same extent that those efforts were shared with them. AGPL doesn't try to give anyone an unfair advantage at providing the software as a service, not even the copyright owner.
> If the core companies maintaining them did not do this they would eventually die
Good riddance. Incumbents owned by corporations have too much control and prevent replacement projects from arising. When a community builds a solution, how it works is dictated by its users and developers, not profits.
Linux being GPL 2 was great for computing when we had thick clients, but now everything is moving to the cloud. Companies can innovate on top of it and not really give back.
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.
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.
Would you still be confident shipping a proprietary product that includes a grafana dashboard ?
The GPL and AGPL are clear that bundling does not constitute a derivative work, and does not require you to license the bundled works under the GPL/APL.
If you write a custom plugin for Grafana, then that plugin will likely need to be distributed under the AGPL (depending on Grafana's plugin architecture), but not your entire app.
I would be completely confident in bundling in this manner. The AGPL3 and GPL3 have identical wording on this matter, and it has been a well understood aspect of the GPL for decades.
Yes, I understood that just distributing grafana and your app together is not a problem, that is bundling. But what if grafana is a part of your app ? If you have a grafana dashboard inside the UI of your own application, this cannot be considered bundling, can it ? The AGPL is clear that if the result of the aggregation "forms a larger product", then you are NOT covered by the bundling clause.
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?
> It’s important to note that this change does not prevent our users from using, modifying, or providing our open source software to others — provided, however, that under the AGPL license, users have to share source code if they are modifying it and making it available to others (either as a distribution or over a network). For distributors, AGPL has the same source code sharing requirements as GPL. Those conditions are designed to encourage third parties looking to modify the software to also contribute back to the project and the community.
I read AGPL as "if you need to clone the Grafana Git repository, change code (even just one line), then you need to open source your changes". If you write code without having to modify Grafana's code itself, then you don't need to open source that.
I don't think it's what the license says. It says that if you are building a larger product that includes an AGPL part, then the whole product has to be AGPL. Even if you didn't change a single line of the AGPL code and just built "around" it.
Presumably - offering dashboards to users, would count as distribution to those users (internal or otherwise). Unmodified Grafana like has/will get a link to source code/license - that would likely cover you - although if Grafana goes away (or becomes closed source) - you might have to offer a copy of the source code on request?
No lawyer wants to be the first one to adopt licenses with novel clauses because the legal system runs on precedent, so using something that is untested in court is higher risk.
It wasn't that long ago that no large company would touch the GPL with a 10 foot pole.
The same reason some people dislike the GPL, but a bit more extreme.
One of the cool things about open source is that you can go and use Open Source code for things that the original author may have never even thought of. So your implementation of some novel algorithm might end up being useful in some situation that you were not aware of or maybe did not even exist when you wrote the code. While it seems idealistic, it is not that uncommon.
Now for the GPL license, depending on version, it is not a huge deal if you borrow GPL code. It is a fairly standard license that a lot of projects use. And of course GPL is compatible with a lot of different licenses, making it possible to distribute your projects under the terms of the GPL including code with compatible licensing.
Something interesting to note is that AGPLv1 is not GPL compatible. AGPLv3 is not GPLv2 compatible. GPLv3 and AGPLv3 are compatible, since GPLv3 was written to intentionally allow this usage. (Note: IANAL or an expert; so this should be taken with a grain of salt.)
In the end, this is why permissive licenses have gained a lot of popularity. It is immensely aggravating to people when things that are technically possible and not spiritually immoral are prevented by legal barriers that feel unnecessary. When the ZFS on Linux project faces trouble because of software licensing, it feels like a farce and a waste of time and resources.
Now imagine that the reasoning for the license choices being incompatible was not to protect user rights, and not simply a matter of differing policies between different organizations and their open source releases, but rather transparently a ploy to protect a profit model. This is where people's aggravation turns to anger, because it then feels like the open source label is being used to pull people in, then the more restrictive licenses are being used to seek rent forever after.
The reality is obviously not quite that grim. In fact, perhaps because of licenses like the Timescale license and SSPL, people have come around to AGPL in quite a significant way. The Overton window of open source licenses from corporate open source releases may have tilted a bit more towards the 'restrictive' side.
I don't think there's anything actually immoral about protecting one's own profit model. It does, at least in some sense, dilute what it means for software to be open source; if AGPL becomes popular, it will be more likely to encumber more projects with its requirements. Of course, in many cases, the ownership of the copyright will be spread among multiple parties, and so everyone is on a level playing field, and so other than the burden of ensuring you adhere to the restriction there's no real reason to feel that it is 'unfair' anymore than copyleft licenses already are.
At the end of the day, GPL was a legal solution to a community problem, and it imperfectly encodes an idea. There is no perfect encoding of that idea, so it is bound to cause some frustration for where the expectations mismatch with reality.
> Now imagine that the reasoning for the license choices being incompatible was not to protect user rights, and not simply a matter of differing policies between different organizations and their open source releases, but rather transparently a ploy to protect a profit model. This is where people's aggravation turns to anger, because it then feels like the open source label is being used to pull people in, then the more restrictive licenses are being used to seek rent forever after.
Anyone interpreting AGPL that way is being ridiculous, though. If you treat the software as fully open source then AGPL doesn't harm you and there is no rent seeking. Any paid licenses are only for companies that don't want to embrace that piece of software being open source.
AGPL isn’t this, of course. Though for a project that enforces copyright re-assignment and thus retains copyright, you certainly could use AGPL as a similar sort of deterrent, because end users and even contributors are beholden to different rules than the copyright owners. But this is not really any different with GPL versus AGPL, and it’s been a well-accepted practice to do things like dual-license FOSS projects as commercial products. I believe even Richard Stallman believed this to be an acceptable practice. Nonetheless, if people want the same rights as the copyright holders, they need to pay rent, unlike a communally owned project. Again, this is not the fault of AGPL, it’s the status quo for a lot of open source; but the way AGPL’s copyleft extends things represents a change to what implications people are used to and widens the gap.
All that said, the emotions felt here are not always rational. Sometimes things feel unfair or undesirable just because they’re different. I am not trying to cast my personal beliefs when I speak about discontent with AGPL because the truth is, I don’t have any. (Certainly not with AGPL specifically.)
I think perspective matters. The way I view my place in the world impacts how I see it. I tend to believe in mostly permissive licensing, especially for personal work. I believe this maximizes the utility of the work and the likelihood that someone may benefit from it. I have accepted the fact that they may benefit in ways that I don’t like. I have also accepted that some may not follow even the most basic terms of the license or copyright law itself; it’s not a huge deal. That’s not to say I would literally never pursue someone for violating my “IP” rights, though it is certainly a statement that for the most part, I don’t really intend to. If someone got maddeningly rich off of something I did for free, I lost nothing. Is it really much more unfair than writing a piece of code that is directly responsible for millions of dollars of profit, but only ever receiving an unremarkable salary? Clearly not. I got a dependable wage and did what I was paid to do. I didn’t have to do it. The entity could opt to show some appreciation by trying to reward employees for such things to encourage it and boost morale, but most people would agree that they’re not under any obligation to.
Not everyone feels this way. To some, they are invested in and concerned about the ways their code may be used. For some reason a growing set of expectations surround open source software in particular, perhaps simply because nobody gets paid to write it. This sometimes results in outbursts against overly entitled users who demand work out of open source authors. But the reverse situation gets far less attention: developers demanding that users follow additional unwritten rules. But I don’t think it’s rational. When Amazon announces an OpenJDK distribution, they’re the heroes. Why? Because fuck Oracle, that’s why. But when they announce forking ElasticSearch, they are panned for breaking open source. I know the “ASP problem” is real, hence AGPLs existence. However, there’s a difference from the pragmatic viewpoint (“we need to close this loophole to protect end user rights”) and the fairness viewpoint (“Big corps shouldn't take advantage of GPL code.” — would the same feeling be applied to a fellow startup?)
All this to say, I think if you want to understand the viewpoint of people who hate specific license decisions, you have to try to understand where they are coming from. It may not be totally rational, but it’s probably rooted in some defensible, understandable position. I think much distaste for AGPL over GPL is likely a little bit FUD and a little bit misunderstanding. But I do think people are coming around to AGPL. If anything, people’s awakened awareness of the fears of the “ASP provider” has done it some good. The reality is though, that people probably viewed it as being similar to what SSPL came to be; and SSPL, depending on where you are standing, could be a threat to open source (in a way that AGPL is not.)
The problem I have with AGPL is that you need to think about it, even if you just run the software and are not distributing it. Or rather AGPL forces you to distribute the software you run. This is in stark contrast to all other mainstream licenses where in general you don't need to think about the license at all if you are not distributing the software, which makes very worry free experience.
Tell that to the lawyers who are paid lots of money to be risk adverse. As others point out, the law operates on precedent, no lawyer wants their decision to be the one that makes their employer a test piece.
"The GNU Affero General Public License is designed specifically to ensure that, in such cases, the modified source code becomes available to the community. It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version."
Here is the clause about modification:
"13. Remote Network Interaction; Use with the GNU General Public License.
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. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.
Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License."
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?
Is there a specific conflict like ZFS-on-Linux that you want to avoid, or are you just asking "how can I most benefit from other people's work without letting anyone else benefit from mine?"
Huh? Grafana isn't your code, it's someone else's code that you'd be using. Unless I misinterpreted, and you are a Grafana contributor. If you are, you could dual license your contributions under AGPL and MIT, if you wanted.
Without knowing what they work on, one obvious case is code that interacts with grafana; extensions, plugins, whatever. For that matter, it's perfectly possible to maintain your own personal patchsets without being a "contributor" per se. Niche, but plausible.
I think you misunderstand the ZFS-on-Linux situation. The problem with that is that ZFS is licensed under the CDDL, and Linux is licensed under the GPL, both of which are FOSS licenses, but there's no legal way to combine them. In your situation, it sounds like there is a legal way to combine them, and you just don't like the license that it would require you to release your code under.
The AGPL3 license means that all my MIT code I distribute in a package will be considered AGPL3. So I can't combine Grafana, and my original work and improve both.
This is a stated purpose of GPL3 / AGPL3. I am happy to be told I am wrong and it is possible.
If you are not offering a product built on top of Grafana as a network-available service, then there is no difference between the new license and the previous GPL3 license for you whatsoever.
If you are, then your obligation would change to specifically making only that work which builds on top of the Grafana code available to others for free, along with the AGPL3-licensed Grafana code. You are not required to license that code that you wrote in any way, with the caveat that others may freely use it.
IANAL, but pretty sure you can license all of your code MIT, while also making it part of an AGPLv3 system; someone else can already distrubute your MIT licensed code under AGPL3, since that would comply with the terms of the MIT license.
Yes you can. The purpose of (A)GPLv3 is that someone else cannot benefit from you work if you cant benefit from theirs. It is a matter of leveraging cooperation.
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.
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?
You'll need to give your customers the source code you used to build Grafana. If your customers are just using it internally, then they have no new obligations. If they're letting customers of their own use it, then they have the same new obligations that you do.
Thank you for clarification. I read about Confluents decision about the license change. It looks like Confluent has opposite view than Grafana labs about AGPL.
"
Why didn’t Confluent use AGPL?
AGPL doesn’t solve the problem we are trying to fix. AGPL allows cloud service providers to sell services using the exact software being licensed, and charge for it, without any limitation. This means the software developer has become the unpaid developer and maintainer for the cloud service provider—which is not a scenario we want to enable.
Also, AGPL is too aggressive for our customers who need to redistribute commercial products. If you put AGPL code in a distributed program, you have to open source the whole program. We want you to be able to embed our code in proprietary applications, change it and not worry about open sourcing any of your changes. We don’t think that proprietary applications are bad, and we think it’s great if you use Confluent Community software to create them.:"
It sounds like Confluent doesn't get what the real problem is. There's 2 ways developers who also sell hosting end up losing all their market share to players like Amazon:
1. The big players like Amazon make custom, proprietary modifications to the software they're hosting, and since they're not technically distributing it, they don't have to release the changes, giving them an unfair advantage. This is the exact loophole that the AGPL closes.
2. Sometimes, the big players are just better/more efficient at hosting the exact same software the exact same way. There's nothing unfair or unethical about this; it's how the free market is meant to work that customers flock to them.
Confluent is trying to "fix" the second "problem", which rather than making anything more fair, just makes it unfair in their favor.
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.
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.
I didn't see your reply until just now, but the AGPL does not require you to redistribute source code to network users if it is not modified. The following stack exchange question has quotes from the fsf
"Amazon Announces Grafana Fork , Promises Amazing Things for the Community" (2021/05/08) [1]
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.
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, ...
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.
Amazon forking ElasticSearch to keep its old license is a good thing, since ElasticSearch's new license is a proprietary visible-source license. Grafana's new license is still FOSS, so it's really not a fair comparison.
Elastic made a massive blunder by open-sourcing Kibana. SumoLogic just took it and builtnon that. You open-source the underlying technology - not the product built on top of it.
While it is true that Grafana's new license is still FOSS not every company, public cloud provider is willing to accept the AGPLv3 license[1]. Hence a fork with the old license is not unlikely.
To be fair, Free Software was never a business model. It was a licensing model that forced to cooperate even such users who have incentives to grab the code, amend it, and disseminate the closed-source altered version. Free Software is about freedom to know exactly what you are running, and to share it. This us the value it tries to capture.
Various business models can be built around it. A license that restricts closed-source cloud use, like AGPL, still preserves the openness at least. It can be combined with a dual commercial license.
Mongo and ElasticSearch are completely different though. Related to those licenses: Has there been any clarification of what exactly you need to release for free if you use them to offer a SaaS?
> If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License.
> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
I can think of a hundred questions based on that text. If I use S3 to store data for my Mongo SaaS, do I need to call Bezos and buy the complete source code of S3?
I have for a while now thought that the ethical source licenses are at least trying to do exactly what open source licenses are trying to do, just within a human rights framework.
The SSPL and other source available licenses on the other hand basically just take away the ability to make a meaningful fork, making the project proprietary. Sure it makes business sense, but someone might still feel the need to make an FOSS alternative.
"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." https://grafana.com/blog/2021/04/20/qa-with-our-ceo-on-relic...
Amazon is the biggest leecher in the industry. They haven't open-sourced any meaningful project back to the community and they even prevent its employees to work in any of them[1] on their free-time.
Just to be clear, had Elastic chosen to relicense Elasticsearch under AGPL, there would likely be no issue with Amazon's usage of it and I doubt Amazon would have forked it in that case.
The problem for Amazon was strictly due to SSPL, not copyleft licenses in general.
I look forward to a future AGPL, perhaps Absolutist AGPL.
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.
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.
I don't want to host Elasticsearch myself, which is why I pay Elastic to host several clusters. That said, I really don't want to be locked into a single-vendor situation, which is what Elastic is realistically aiming for. I am 100% glad that Amazon forked ES, because it preserves the benefits of using an open source stack. I still have a choice of hosted providers. In my opinion, the amazon fork is much more likely to lead to a healthy ecosystem of hosted ES providers than the Elasticsearch version.
I wish people would stop equating what Grafana did with what Elastic did. Grafana switched from one FOSS license to another. Elastic switched from a FOSS license to a proprietary license.
The GPL (without A) requires you to publish sources under compatible license (usually also GPL) if you use a software and distribute it (to clients for example).
Git is GPL. Github however can totally run modified versions of git on their servers to build their service, and doesn't necessarily have to contribute back, since they never distribute their programs to the customer, but only some html.
The AGPL goes one step further and requires any changes that github makes in that situation to also be licensed under AGPL. That way it is like GPL, but for software that is typically run on servers, not on client hardware.
"The GNU Affero General Public License is a modified version of the ordinary GNU GPL version 3. It has one added requirement: if you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there." https://www.gnu.org/licenses/why-affero-gpl.html
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.
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.
Once you have free and non-free tiers or need restrictive licensing it is already broken. The incentives no longer align.
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.
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.
Out of curiosity, what kind of markets are those two companies in and how much competition exist.
Using open source libraries is, among other things, a cost saving measure. It allows a company to focus their expertise on what they are good at, without having to spend time and resources on reinventing wheels. Banning tools that enable a company to produce products faster, cheaper and (sometimes) more stable and secure can have a major impact when the competition does not limit themselves in the same way. However if the market is dominated by a monopoly or is very slow, then increased costs and delays might not have much of an impact.
As an example of such company, Google's revenue would not be impacted by a single percent if they suddenly needed to hire 200 more programmers for android. Delay next version with 2 months and the impact for android market share would unlikely be statistically verifiable.
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.
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.
> 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.
It'd be really hard to come up with a license less lenient than AGPL without it being non-FOSS, which would defeat the purpose.
> 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.
I mean, good for them? If they're "just rebranding and selling access for infinite markup" then surely the only people who would pay them are either too lazy or too busy to host it themselves, or too rich to care?
Would you prefer that people/companies that fall into these categories be forced to go through some _other_ reseller (who is just adding their own markup on top of the cloud hosting costs) instead of getting the service directly from their cloud provider of choice?
No, that's not the issue. They have a marketplace where ElasticSearch can be sold as SaaS. However, when there is something open source being offered on that marketplace, they co-opt it, give it AWS branding, and sell it themselves. They also own the infrastructure that both their own offering and the 3rd party SaaS offering is hosted on. Lets say they charge $1.00 / unit for EC2. They can charge $1.00 / unit for the 3rd party SaaS to run their service, and $1.00 / unit for their own offering which is basically EC2 + SaaS, so there is literally no way for the 3rd party to be price competitive, and meanwhile their own SaaS offering is blasted into the AWS interface everywhere, while the 3rd party offering has to be searched for and found. So they take the development work of that 3rd party and use their lock in and ability to steer customers to shut out the 3rd party, while taking all their work and selling it themselves at a price that the 3rd party can't possibly match (and not because of efficiency, because they'll just refuse to make a deal with the 3rd party to give an EC2 discount that they give all their other large customers if it would mean the 3rd party can then be price competitive with a SaaS offering that would compete with one of their own).
^^ this is not a good contribution to HN, not much substance. (edit)
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.
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.
Unless they were making money based on their proprietary modifications to Grafana, Loki, or Tempo, they aren't affected much beyond being required to publish links to the source code.
If, however, they _were_ making money off of proprietary modifications, and they wanted to keep such modifications proprietary, they now have the choice to fork Grafana (and Loki and Tempo respectively) as of a pre-AGPL version.
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.
> If Amazon/AWS was not a large monopoly it wouldn't be a problem.
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.
This has nothing to do with CLAs. The old license was Apache 2, which is compatible with AGPLv3 (although the converse is not true). You'd only need a CLA to relicense if it weren't compatible.
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.
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.
The BUSL is worse - obscure licenses are problematic.
The problem with the AGPL is it's very unclear what counts as linking, and this has never been tested in court, and that it's not clear what "network access" needs to look like.
> 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.
Your gut is onto something. People who care about something bigger than themselves prefer AGPL, while those who only care about their own profits prefer BUSL.
Anyone want to guess what the third commit was? That's right, it was an Apache 2 license: https://github.com/grafana/grafana/commits/master?after=2bb7...
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: https://github.com/grafana/grafana/commit/50e42c8bdd2099552d...