Hacker News new | past | comments | ask | show | jobs | submit login
Grafana, Loki, and Tempo will be relicensed to AGPLv3 (grafana.com)
710 points by WalterSobchak 28 days ago | hide | past | favorite | 559 comments

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...

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...

Relevant section copypasted below:

> 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?

Would Torkel have decided to fork Kibana in the first place if it were AGPL?

Would the same level of community have formed around Grafana?

Would it have received as many contributions and support for new backends?

Would Raj have wanted to acquire Torkel + Grafana for the original Raintank company if it were an AGPL project?

Would they have been able to as successfully build and monetize a Grafana Enterprise product with the requirements of AGPL in place?

It seems naive to argue that none of those would have been impacted by a more restrictive license.

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....

P.S. Hey Todd ;)

Oh, hey! Nice to have at least one person here that isn’t going to jump on the AGPL bandwagon. ;)

Are you sure you're not asking questions whose answer depends on one's ideological pre-disposition?

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.

You mean when you would have forked before the new licensing became effective?

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.

What do you mean? Any free software licence allows forks, including AGPL.

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.

Humour me, why must there be such a threshold?

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 applaud this decision.

I would like to see all major SaaSS projects be AGPLv3. End users still have freedom to user, modify, and distribute the software. Cloud providers must share contributions.

This is how I like it.

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.

> That seems like splitting hairs for ideological gain.

Such is the way of the FSF.

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].

[0]: https://seirdy.one/2021/01/27/whatsapp-and-the-domestication...

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]

[1]: https://www.gwern.net/Complement

> 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.

Well, GPL is about freedom for the users, not necessarily for the developers.

Every developer is also an user.

And "user" freedom is more important because we use tenths of millions of SLOC and do development work on a small fraction.

The copyright holder is never a user in a discussion about distribution rights, though.

...in a very narrow sense where one person or organization owns all the copyright on a codebase.

This can be true for a small program on a microcontroller, but 99.9% of FOSS is deployed as part of a big ecosystem.

For each line of code I deploy on production there's 1000 lines of kernel, libraries, daemons, firmware.

As developers, we are 0.1% developers and 99.9% users.

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.

The user could hire any developer, he doesn't have to live within the original author's roadmap.

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.

What do you think the word "free" means exactly, in the context of software freedom?

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 gives you more freedoms than the personal use rights you get from having bought/gotten a book, though.

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.

The only additional obligation that the AGPL requires is that you not restrict to others the freedoms that it grants to you.

> projects now cannot use

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.

On the contrary, AGPL (and GPL) cannot be combined with any other license. See section 5c: https://www.gnu.org/licenses/agpl-3.0.en.html

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.

That doesn't say you cannot combine it. It's saying what you have to do when you do combine it. It's not a restriction against combining it.

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.

> so long as you immediately relicense that code

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.

Ok, quoting section 5c:

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?

> 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

*Correction: My comment is a reply to Seirdy's answer

> Cloud providers must share contributions

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.

They have to be shared to the user under the same license. So any user could publish the changes publicly.

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.

There's a strong case to be made that grsecurity is violating the GPL by doing that: https://perens.com/2017/06/28/warning-grsecurity-potential-c...

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.

[1] https://www.gnu.org/licenses/old-licenses/gpl-2.0.html

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 ?

IIRC one of grsec's customers did already leak their patches, I can't find the Twitter thread or other discussions about it any more though.

> The freedom of users is more important than the freedom of developers.

This is misleading. All developers are users as well. Having to use closed source services and tools impacts us a lot.

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.

> I might be working on an accounting software for a big company and never use it.

Obviously. But you are using other FOSS directly or indirectly.

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.

The key part of the AGPL is phrased:

> 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".

The driver would be derived work of Postgres, thus AGPL, and already problematic in use because of that.

IANAL, but as I understand it:

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.

a) is wrong: users are not connecting directly to PG

Why the silent downvotes. If users do not directly use PG it's not an issue.

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).

[1] https://www.microsoft.com/en-us/licensing/learn-more/volume-...

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

I've tried really hard to understand this a few times and yesterday or early today or something I found an interesting thread here: https://news.ycombinator.com/item?id=11354475

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.

Would an extension like citus or timescaledb or opengis be considered a combined work for AGPL purposes?

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.

> Do you need to release as GPL the code of a program runnning on GNU/Linux? The answer is no.

Only because Linux (and perhaps more relevantly glibc) specifically exempts the relevant protocols from the GPL.

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

And you don't read what he wrote:

"... and I modify it to my needs ..."

So he has explicitly created derivative work of Postgres, that's not the question at all. The question is whether the conditions of the AGPL for distributing the source would trigger in his case. I would say yes but IANAL.

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.

A) Only if, as part of your service, your users can directly connect to Postgres, side-stepping your app.

B) Nope

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.

So the answer is clearly NO to both questions.

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.


a) postgres is not user facing, so no

b) there is no linking (as in compiler linking) between your application and postgres, so no

This article tries to answer that question. https://medium.com/swlh/understanding-the-agpl-the-most-misu...

1) Yes 2) Nope

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.

Am I missing some key point?

>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.

That was also my understanding of the GPL, but the AGPL is for me to understand.

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.

If Linux was AGPL you would have to

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.

What about freedom for developers?

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.

> individual people often benefit from denying access to the source code of software that is used to provide a service

To the detriment of the users of that service--which are the people that the FSF aims to protect.

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.

"Companies are right to avoid the AGPL"

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.

[1]: https://www.processmechanics.com/2018/10/18/the-server-side-...

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.

Anyone debating that it's not has a screw loose.

GP said SSPL is debatably not open source, not AGPL.

How is it debated whether AGPL is open source? Who says it isn't?

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 FTP masters’ message (from 14 years ago!) is pretty convincing:


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.

Sure, I think its mostly settled now. But it definitely was debated at the time.

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.

What's your definition of software freedom exactly?

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.

> Freedom includes freedom to have privacy.

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.

Consider "Service as a Software Substitute": https://www.gnu.org/philosophy/who-does-that-server-really-s...

Do you consider it a problem? If not, why not? If so, what other than the AGPL do you propose to fix it?

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!

There is absolutely no problem with that. If you want to host it then do it yourself, nothing is stopping you with commercially permissive licenses.

I never knew how much I can't stand "free" software types until today.

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".

I wrote:

> 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.

You forgot a point in your numbered list:

4) You're using it.


> access information in someone else's computer that you have nothing to do with.

1. "nothing to do with" is an absolute claim. Your line of argumentation has been heavily reliant on absolute statements, refusing to understand nuance.

2. If the user truly had "nothing to do with" some information on some computer, the AGPL places no requirement for them to be provided access to that information.

3. Interacting with a service provided by a software != having "nothing to do with" said software.


> ... claiming that you have the "freedom" to access information ...

For the last time, that is not how the AGPL works. I strongly urge you to go and actually read it, or even https://writing.kemitchell.com/2021/01/24/Reading-AGPL.html

Now, on to the specific rebuttal: The AGPL does not _force_ a user upon you, the service provider. It does not grant the user any "freedom" to access any information, let alone arbitrary information. It cannot even be used by a user to force themselves on you.


> That's actually a privacy violation.

By your line of reasoning, you have violated my privacy by way of your writing showing up on my computer. Do you see the absurdity in that?

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).

> There's a clear distinction between ...

The distinction is meaningless to the user in the example your parent cites.

(Timescale founder)

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.

Hi PeterisP, just to avoid any confusion:

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.

And we never call it Open Source!

(Timescale engineer here)

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.

Totally fair. My initial comment was a little rushed. :-)

Or scope it as "less restrictive for most users" or something along those lines.

That may indeed have been more accurate. But this is a HN comment thread after all, we can't capture all subtleties of a very complex debate. :)

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.

Oh cool! I see this is addressed in your FAQ:

> 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!

Thank you :-)

Re: Apache 2.0 only version, it is on our Github readme (but yes, probably could be made more prominent):

  Apache-2 licensed binaries can be built by passing -DAPACHE_ONLY=1 to bootstrap.

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.

Make it easy on customers like me.

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.

That is fair, and we do not claim that Timescale License is open source. (Our Apache 2 core codebase however is 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.

Thank you, I appreciate this thoughtful comment.

And to those who keep downvoting my comments simply because they don't agree with them - I always welcome thoughtful discussions. :-)

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.

Spot on answer

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..."


"...presents a huge risk to Google..."

and later in the document is the best part:

"This viral effect requires that the complete corresponding source code...".

All from a company which built itself on GPL software. This reminds me of Steve Ballmer ranting about Linux being a virus 20 years ago.


"Do not install AGPL-licensed programs on your workstation, Google-issued laptop, or Google-issued phone without explicit authorization from the Open Source Programs Office."

Assuming Google follows its own policy, this just creates a hassle for its employees. Worse, Google making this public sends a strong anti-AGPL message to other companies. I'd bet $10 RStudio server (AGPL) is installed somewhere at Google (perhaps the commercial version). But other organizations with less sophisticated legal departments might just ban RStudio completely following Google's lead. I would not call Google irresponsible here, but I think it could act more responsibly.

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!

The FSF and other similar organizations have lawyers too. What do you think their opinion is?

The FSF is not generally a party to the license, so it makes no difference what they think.

> AGPL virality is overbroad

Going against interest of Google (and similar companies) is one of main points of AGPL, so this indicated that it works as intended!

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.

It turned out alright.

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.

And 99.99% of users don't modify the code so it's irrelevant.

I don't understand the point you're trying to make with the reverse proxy as it doesn't seem related to anything the parent wrote.

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.

> that would require the developer to maintain a source repository for Loki under the AGPL.

Is that a problem? Fork it on github, and update the repository every once in a while or upon request.

> Dynamic linking to a GPL software does not require the developer releasing their code.

That's not true, you do have to release the code. There is no difference between statically or dynamically linking to a GPL library. Source: https://www.gnu.org/licenses/gpl-faq.html#GPLStaticVsDynamic

You may be thinking of the LGPL.

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.

(IANAL, this is not legal advice, etc. etc.)

[1]: https://en.wikipedia.org/wiki/GNU_General_Public_License#Lin...

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.

That does not seem to be the case. From [1]

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] https://www.networkworld.com/article/2229265/is-the-affero-g...

Wasnt this solved with GPLv3 anti tivoization rules?

The anti-tivoization rules only apply if:

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.

Related note: the GPLv2 also requires users to be able to reinstall the software:


How would the anti-tivoization rule that discusses physical products apply to a service?

> I think that's misunderstanding of AGPL.

That's GPs point.

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?

In my experience a lot of legal departments will block off entire classes of licenses just to be on the safe side.

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?

A company giving its own employees access to software for work use only doesn't count as distribution, but giving it to contractors can: http://www.gnu.org/licenses/gpl-faq.en.html#InternalDistribu...

AGPL uses the wording "all users interacting with it remotely through a computer network".

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.

Many devs at Google routinely use GPLv3 code, in GNU Emacs, to make an example.

Unless you’re repackaging Grafana into an app bundle for customers to use, there’s no violation occurring here, right?

GPL and AGPL are very different here.

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.

If Amazon was really scared of AGPL then MongoDB wouldn't need to relicense.

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.

Would you consider paying for a licence to use it?

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.

Honestly, I have no idea.

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

What about just paying for a commercial licence to use it to meet your needs?

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.

Or am I missing the point?

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 and contributors, sure.

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.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact