Grafana, Loki, and Tempo will be relicensed to AGPLv3
grafana.com
grafana.com
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...
I think that depends. If it was progressively changed to something completely different, then, no.
Let's say in 10 days you replaced 10% of the code, with the same amount of code from a different program by another author. During those 10 days there'd be compilation errors, and thereafter the original work and copyright would be all gone (except for in old revisions in the repo), and the copyright holder of the new program could license it however s/he wanted.
and that is normally _not_ what you wrote:
> the copyright holder [sic!] of the new program could license it however s/he wanted.
However if sole copyright holder - real, not imagined - she sure can license it - or not. Or different another day.
you state this as if it's a settled fact (it isn't).
If you take a Shakespeare novel and replace every word in it with another word, and then remove and add many chapters to it, then shuffle all the pages, is it still a Shakespeare work or even recognizable as being derived from one? I think most would say "no".
In the case of Ship of Theseus, if you replaced every part with a different looking part, removed 30% of the parts entirely and added another 300% parts such that the function was expanded by 1,000%, would anyone recognize it as the same thing?
There has to be _some_ threshold beyond which you cannot reasonably claim the work is derivative.
If version B is modified from version A as a derivative work (therefore licensed as A) and version C is modified from version B as a derivative work of B, then would C not still be licensed same as B, and therefore A?
It seems it depends on how you view the accumulation of differences. If your only comparison is always against version A, then yes, eventually there must be enough accumulation of differences that one could claim a work is no longer derivative. But if you consider all versions between A and yours, then suddenly its just a series of gradual changes, none of which individually cause the work to become non-derivative. The Ship of Theseus parable seems to also fit this latter interpretation more -- it is after all about replacing items one at a time.
I agree with you from a practical legal point though. My argument above seems to imply that there's only been derived work since the first cell split in two. In practice this would be a nightmare; There should be a threshold whereupon a work can qualify on its own merits.
https://grafana.com/blog/2021/04/20/qa-with-our-ceo-on-relic...
> If Kibana had been an AGPL project, would Grafana even exist? Are we being hypocritical?
> I asked Torkel, and he said that If Kibana had been an AGPL project, Grafana would likely have been AGPL from day one.
> This is of course a hypothetical question, so it’s difficult to determine how that would have affected subsequent business decisions the company might have made.
> Making business decisions to increase the likelihood of commercial success of our company while also supporting the health of our thriving Grafana community on the basis of new information and an evolving situation is not hypocritical.
IMHO, his answer doesn't address the GP’s point; that the original, permissive license inherited from Kibana arguably enabled the growth & survival of Grafana.
Listen, at the end of the day, it's their legal right to choose the licensing strategy that they think is right for their business, shareholders, employees, customers, peace of mind, etc. I feel like asking if it's hypocritical is a bit of a straw man, though. It's not hypocritical per se - I just feel that it's a bit disingenuous to say "hey, we have this large, successful business to protect" without also openly acknowledging that it may never have existed without the tailwinds of an era where the open source community embraced permissive licenses. Simply dismissing the question as "hypothetical" is what I take issue with.
Also, I see your shiny, new account and feel it's likely that you are really just here to defend Grafana. I get it. I don't think this change is a bad idea, necessarily. I just want some of these licensing shenanigans to be more brutally honest.
Why's that? If Kibana had been AGPL and Grafana had been AGPL from day 1, how would the growth and survival of Grafana have been any different?
Would the same level of community have formed around Grafana?
Would it have received as many contributions and support for new backends?
Would Raj have wanted to acquire Torkel + Grafana for the original Raintank company if it were an AGPL project?
Would they have been able to as successfully build and monetize a Grafana Enterprise product with the requirements of AGPL in place?
It seems naive to argue that none of those would have been impacted by a more restrictive license.
P.S. Hey Todd ;)
Their FAQ even says:
> I asked Torkel, and he said that If Kibana had been an AGPL project, Grafana would likely have been AGPL from day one.
https://grafana.com/blog/2021/04/20/qa-with-our-ceo-on-relic...
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.
To be really strict: AGPL only mandates that contributions be shared with the user. The freedom of users is more important than the freedom of developers.
Of course an upstream maintainer can be a user and get the contributions.
For instance, grsecurity will sell you a security-hardening-patched Linux kernel. You, as the user/customer, have the right to take those GPL patches, and share them publicly. But if you do so, grsecurity will blacklist you as a customer, and you won't be able to get any more patches from them.
"Technically you could share the code, and then we'll blacklist you" isn't letting people share the code, "technically" their customers can do anything.
This sounds like the reasoning of a petulant elementary school kid, not a professional security company.
You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice [..] and give any other recipients of the Program a copy of this License along with the Program.
This is section 1 of the GPLv2 [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.
> 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".
This is misleading. All developers are users as well. Having to use closed source services and tools impacts us a lot.
Obviously. But you are using other FOSS directly or indirectly.
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?
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.
"... and I modify it to my needs ..."
So he has explicitly created derivative work of Postgres, that's not the question at all. The question is whether the conditions of the AGPL for distributing the source would trigger in his case. I would say yes but IANAL.
While a derivative work of Postgres is created, it is not "distributed" (in the sense of the AGPL). The web application is, which I do not consider a derivative work of Postgres in the general case.
If you implement a feature in Postgres and have a web application that is practically just a wrapper around this one, new feature, then that could be considered a derivative work. But I'd say that's a far stretch.
a) postgres is not user facing, so no
b) there is no linking (as in compiler linking) between your application and postgres, so no
a) Yes, if Postgres is exposed to users for some reason. Your changes to Postgres are a derivative work of the original, and thus covered under the AGPL.
b) No. Your application is not a derivative work of Postgres, any more than it's a derivative work of whatever OS you're using.
"interacting with it remotely through a computer network" may include several hops, the text is unclear at this point. And there is precedent for this interpretation, Microsoft uses the same concept (as "multiplexing") in their SQL Server license terms: https://download.microsoft.com/download/3/D/4/3D42BDC2-6725-... (pdf, from [1], should the document link change in the future).
[1] https://www.microsoft.com/en-us/licensing/learn-more/volume-...
Only because Linux (and perhaps more relevantly glibc) specifically exempts the relevant protocols from the GPL.
B) Nope
- does your application directly include AGPL postgres code in any form (headers, binary, etc etc) to its own source or its own runtime process?
- keep in mind, in answering the above, that your application probably does have to include a postgresql driver of some kind. Is the driver licensed AGPL too? If yes, your answer to the above is probably yes. This was the problem for years with MySQL, because they licensed their driver code GPL along with the actual database code.
- a final consideration that only comes into play if there is genuine ambiguity on the other points: is your application able to perform its functions if Postgresql is missing or swapped out for another database? To the extent it depends on Postgresql functionality, this will sway a jury towards considering it is in fact a derivative work of Postresql. If you on the other hand support 6 different databases and Postgresql is just one of them - it will be much less likely your application is considered a derivative work of it. As I said, this only comes into play if the other factors can't be decided decisively.
IIRC AGPL was created to bypass a thin wrapper frontend type situation. I make a website that takes PDFs, it lets users extract pages. In the backend I'm just running a modified Ghostscript command line and sending back what it makes. From my discussions with other people, this type of direct coupling automation is what is intended to trigger the AGPL. Is this incorrect? If that doesn't trigger it, the 'users interacting with it remotely' clause is all but useless because firewalls and service chains like this are really easy to construct. Not all AGPL software is able to natively run as a server itself.
And if it does trigger it, a simple ToDo CRUD app that relies on a database is pretty much the same thing in my eyes.
> if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source
So note the "interacting with it remotely" language isn't specific to just a network connection. So a reasonable interpretation would absolutely be that your users are "interacting remotely" with the PDF tool in the scenario you describe, no matter how many thin layers you put in between.
So this then goes to the question of how a court would decide the boundary ... clearly the connectivity of the internet means nearly every computer and software on earth is theoretically linked by a network. So that is where they would look at how direct the interaction with the AGPL software was, and how critically and specifically dependent on that interaction your software is. If everything a user does gets transformed into a completely different form by the time it hits the AGPL software then they aren't interacting with it remotely - they are interacting with your software remotely and your software is interacting with the AGPL. Similarly, if you could trivially substitute the AGPL for something equivalent and the end user wouldn't notice, that would also argue they aren't really interacting with the AGPL software specifically.
Of course, nothing is really clear until it goes to court, but this my best understanding of current state.
The last part surprised me. For most projects, they don't need to modify the source code of the database engine. They only need to use the database to create a schema and store data.
Can you share more about what you meant by "modify it to my needs"? It would be helpful if you could provide one specific example.
It is not that uncommon to mod Postgres to do something it can’t do out of the box. I’ve been paid to do it many times for companies that use Postgres to make it do just a bit more. This is a pretty valuable and unique property of Postgres; it has many fundamental limitations but a lot of small limitations can be coded around if you are handy with C.
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.
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.
If you want to use AGPL software in your project, you're free to relicense under AGPL.
And "user" freedom is more important because we use tenths of millions of SLOC and do development work on a small fraction.
This can be true for a small program on a microcontroller, but 99.9% of FOSS is deployed as part of a big ecosystem.
For each line of code I deploy on production there's 1000 lines of kernel, libraries, daemons, firmware.
As developers, we are 0.1% developers and 99.9% users.
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.
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.
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.
Such is the way of the FSF.
> Lack of competition is what lets developer's exert power over users, and while copyleft licenses help with that, they're neither required nor sufficient to prevent abuse of power.
Copyleft/FLOSS alone is a necessary but insufficient measure; I wrote about other measures in a blog post [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.
Most consumer software doesn't in fact need any auxiliary services. It just needs work put in to actually build it, and that work needs to be paid for.
Props to Red Hat for earning money from enterprise clients. That model only works if you have enterprise customers.
Props to System 76 for selling computers. That model only works if you're selling hardware.
My software doesn't need any services or hardware or other auxiliary bullshit, and I'm not going to invent the need for said bullshit just to satisfy some ideologues.
You're not entitled to tell me what kind of software to write or how to license it. Don't like it, write your own FLOSS version, and outcompete me. Don't want to, or can't sustain yourself that way? Then don't tell me that I should, or that I can. Words are cheap.
That incentive structure is universal though. A builder also doesn't get paid directly to maintain his toolset, that cost is included in how he charges for his services. A hospital doesn't charge you for the laundry/cleaning services, it's included in their service bill. If a farmer's combine harvester breaks down, he can't just up the price of his wheat twenty-fold to pay for a new one.
There is a market for selling shrink-wrapped software, see e.g. Microsoft, Nintendo, Apple. Invariably these products are proprietary, because Free Software uses a different paradigm: under the free software/open source model, software is a tool, not a product.
Of course. That's not a problem, because the toolset isn't the builder's product. Their customers don't care about the toolset, they actually want the service. Conversely, most consumer software users don't want or need your services, they just need the software.
Moreover, that toolset you mentioned belongs to that builder only. It's not a resource shared by all the builders in the world, unlike open source software.
It's not surprising that people pontificating about the morality of copyleft vs proprietary don't even seem to understand the basic economic effects of shared ownership like the tragedy of the commons.
The idealogy is that proprietary software is wrong, bad, unethical. Software freedom should be available to all.
The copyleft terms of the GPL are a tactic a means to defending software freedom. And to that extent, all the incompatibility with other free licenses are indeed a bug a downside, a hampering of freedom in practice. That downside is accepted because of (and only when it is) the judgment that it is a net gain for software freedom anyway because it frustrates the development of non-free software.
There does not exist any ideology that wants incompatibility between free software licenses. It is a price that some feel should be paid sometimes in order to be incompatible with non-free licenses which are the actual problem.
And this condition is the reason that the answer will be "no" every time to using copyleft. Why would anyone ever choose a piece of software which, however you want to twist words, is actually less free in the sense of what it permits and will have less adoption as a result?
I run some websites without ads used by thousands of people and I never intend to monetize them, but I would still avoid these projects solely due to their licensing.
Against that are more rights for the users of the final code. GPL is predicated on advocating for users' rights over developers. But that comes at the right of developers to re-use as they want.
Which one is more free is very much a matter of perspective. Claims that GPL is a more free license because it is better for users are therefore subjective, or at least subject to a very specific semantic context.
Right, but if you buy/get a book, you can't even re-publish or re-use the content in the first place.
I'm not comparing the AGPL and the GPL. I'm only talking here about the insinuation that the AGPL is somewhat like a book author requiring readers to let them crash their couches. It's not.
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.
They can, they just don't want to because they want to ensure other people can produce non-free work.
Remove the desire to produce non-free work and you can perfectly legally put copylefted code into weakly-licensed free code. Weak licenses don't forbid this. Copyleft licenses don't forbid this. There's no need for anyone to change the license or copyright to combine weak licenses with copyleft licenses.
Copyleft licenses forbid proprietary code. And proprietary licenses forbid a lot of other things.
Weakly-licensed code also allows to be covered by a proprietary license. Nobody needs to relicense weakly-licensed code to lock it up in any way and apply further restrictions to it, whether they be "good" restrictions like the (A)GPL, where you forbid further restrictions, or "bad" restrictions like a EULA, where you forbid people to look at your modifications or to do further modifications.
Without a copyright transfer agreement in place, only the original author may relicense the code. The permissively licensed parts of the code will stay permissively licensed, but nevertheless may be distributed in combination with copyleft or proprietary code.
c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
This only says that the product of such a combination must be licensed as AGPL. The MIT/BSD licenses (with or without the attribution clause) specifically allow being included in larger works under any license, even proprietary, so what are you arguing exactly?
I have an MIT-licensed project called A, currently at version A1. You have an AGPL-licensed project called B. I take some code from B and incorporate it into version A2 of project A. I want to distribute A2 to A's community.
I don't have to relicense A1 to do this, but I do have to distribute A2, and all subsequent versions of A, under the AGPL, effectively "changing the license" of my project.
I realize this usage is informal - licenses cover code, not projects - but jrv's point upthread was that projects do not want to change their working license, which led me to read jordigh's response as somehow asserting that the AGPL was not viral. It's a non sequitur otherwise.
Doesn't that depend on how they use it? They're only AGPLing their backends. The tools still follow open protocols, so the client libraries can be permissive. I.e. the rest of their project won't be "infected".
A more permissive license is simply incompatible with this project's ideals - they are willing to sacrifice developer convenience for user freedom and prevent corporate theft and bastardization of the codebase into competing products
What if I release my own SaaS as AGPLv3? Do others, who rely on it, also have to license their software under AGPLv3? I think this kills many business cases.
Am I missing some key point?
If you link to it directly from your code then yes, unless you're willing to pay Grafana for a commercial license (assuming they offer one or you can negotiate one with them). If you have Grafana running on your servers but you aren't using the code in your own applications then you're generally fine (the GPL is generally recognized as ending where a process ends). And that's the point of the GPL/AGPL, you get the code for free, with the only expectation being that you pass it on if you make any changes.
You wouldn't, as system interfaces are specifically excluded as an AGPL enforcement domain. But if the Linux kernel was AGPL, you would have to supply the source code to your NFS clients, since those clients would be served directly by the kernel.
More specifically, the only difference between GPL and AGPL is section 13 (and the preamble summary). The rest of the license is word-for-word identical (save for the name). https://www.gnu.org/licenses/agpl-3.0.en.html#section13
I'm sure if I'm wrong I will find out very quickly, this is HN after all.
The Free Software Foundation exists to protect the former at the expense of the latter.
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.
To the detriment of the users of that service--which are the people that the FSF aims to protect.
My customers, for example, to whom I provide service, are not infringed upon in any way because I use private forks of GPL software in the provision of my services.
The issue is that I—and, more importantly, your customers—must simply take your word for it, since we're unable to confirm or deny it for ourselves if you don't make the source available.
When dealing with large corporations, taking such statements at face value is pretty foolish.
You might not want to admit to yourself that your business model is based on infringing on the freedoms of these users of GPL software, but that's exactly what it is.
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.
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)
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.
The free in free software is often cited as being "free as in freedom", but it's important to remember that it's also and simultaneously "free as in beer".
Google, along with everyone else, uses tons of GPL software that they don't pay for - because the point of free software is that you're free to use it. They're not "stiff[ing] the developers" as you claim, because the software is available for all to use for free.
You can't have it both ways: either you're free to use the software for any purpose, or by using the software you owe somebody something. Pick one. I choose the former.
The only reason Google opposes the AGPL is financial. Read their explanations. So, while you're right that Google is not 'stiffing' the developers whose software they're using, by their campaign against the one license that can be used by developers to make money, they are making the OSS world weaker--especially for programmers from developing countries who don't have the luxury of large blocks of time to write software on the side unless they can benefit from a license like the AGPL.
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.
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.)
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.
edit: And FWIW, I have dropped this claim from the post with a note, especially since it was not my point anyways.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495721#17
The follow on questions on that thread seem to be fairly hypothetical handwringing, and something I’d expect the FSF to submit an amicus brief, giving their fairly reasonable FAQ answers, if it ever did show up in court. Given that the GPLv3 (and its derivative, the AGPLv3) allow for up to thirty days to remedy shortcomings, your source code being unavailable for a few hours while GitHub is down seems like a non issue.
I am a proponent of software freedom, and resultantly I view the AGPL as nonfree.
Freedom includes freedom to have privacy. Not distributing any software, my privacy should not be violated.
Running an ASP off a private fork is not "loophole", any more than, say, using free software to make missiles or killing machines.
I feel like the AGPL is just anticapitalist fist-shaking.
You have that. The AGPL provides rights to _users_ of your software; that's it, no one else. If _you don't provide_ the modified software to someone, they can't demand your private patches. No one can "bring down the machinery of state copyright enforcement" against you, unless you interact with them first and provide them your modified software and they use it.
And even when you do that — when you provide your software to someone — they still can't demand that you "publish" your private patches. Only that you give to _them_ the modified software under the same rights that you received the original software. Only to _them_, not the public. No publishing required. _They_ are free to publish the software they received, of course, as were you when you first received the original software; but you aren't obligated to publish it.
----
The only difference between AGPL and GPL is that the definition of what constitutes "distribution" of software is extended. The AGPL changes only "distribution" and nothing else in the GPL.
Do you consider it a problem? If not, why not? If so, what other than the AGPL do you propose to fix it?
I really think the whole AGPL is simply sour grapes, because most GPL-using businesses have not figured out how to become profitable. ("open source is not a business model.") The anti-corporate, anti-business types see people exercising their software freedoms and using free software to make money, and think it's a problem that needs to be stopped.
It's interesting that TPTB have ruled such "ethical source" licenses as nonfree - you're not allowed to restrict Freedom 0 to say that users aren't allowed to, say, use the software to produce bombs. That's not a free software license.
Using it to generate revenue however, is seen as a "loophole" to be "closed".
I don't see a license that forbids the generation of revenue by selling access to a service API using a private fork as any less nonfree than one that forbids the production of bombs.
However, because you can only access their fork of a GPL project over the internet, there is no requirement for them to provide users the source code of software they're using (which is based on software developed by other people under the social contract of the GPL). Thus users are using software which is technically free software but they have no mechanism by which to excerise any of their freedoms nor even see the source code of a program they use purely because the protocol used to display the interface is HTTP rather than X (yes, it's also not running on the same computer, but from a user's perspective it doesn't matter if it runs on your computer or not -- they are using and depend on the program, even if it happens to be running on a different computer).
Do you agree that this scenario is a problem, and the GPL is not helping to solve it? If so, then you now understand the reason behind the AGPL and how it is clearly in line with the spirit of free software. If not, then I'm not sure you fully buy into the concept of user freedom. User freedom is a holistic thing, it isn't a technical definition that cares about specific implementation details.
I would argue this is a bigger issue than tivoisation, because at least with tivoisation you can at least get the source code (even though you cannot use your freedoms on the hardware you bought). In this SaaS scenario, you can't even see the source code of software you are using.
Something entirely different is happening when I'm running software on my computer, using it to provide i/o services to you, and when I provide software to you to run on your own computer.
One is a service, the other is a product. The hypothetical LibreOffice fork, with their private modifications on their own private computer, is entirely within the bounds of reason to keep those modifications private and generate revenue with it, if people want to pay them for the services they provide with it.
It's no different than me using LibreOffice to produce private documents, which I then use to generate revenue for my business. My customers have no right to access my private documents that I use to provide that service: source code is no different.
I think you're getting caught up in the "on their own private computer" part. There is a clear distinction between using a piece of software and providing a service by which other users make use of the software by proxy. In the first case, you are not acting as a proxy for other users to run the software.
> It's no different than me using LibreOffice to produce private documents, which I then use to generate revenue for my business. My customers have no right to access my private documents that I use to provide that service:
It is incredibly different, so much so that I'm not sure you've understood my hypothetical.
> source code is no different.
If you were using it purely for yourself, yes. But in the hypothetical the business is providing the ability for other users to use the software by proxy. They aren't using the software themselves and then
As a final point, consider that these days a regular user might not know whether the software they run is actually locally running on their computer or is a SaaS application where the code happens to reside on a different machine. How they use the software is no different in either case -- so why should they have different concepts of what freedoms they have? For an ordinary user there is no practical distinction between software they use on their computer versus software which is provided over the internet -- hence why I said that the only real difference is that the "display protocol" for the application is HTTP not X.
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.
I never knew how much I can't stand "free" software types until today.
The AGPL does not "forbid the generation of revenue". There exist revenue-generating services powered by AGPL software.
> Nothing is being used improperly or against the spirit of free software when software freedom is exercised (by a service provider)
If that exercise of software freedom hampers an end-user from exercising their software freedom, then that's pretty clearly "against the spirit of free software".
> forbids the generation of revenue by selling access to a service API using a private fork
That's the thing - "software freedom" is being applied to software that you have no reasonable expectation of having access to:
1) you didn't write it
2) it hasn't been provided to you
3) it's running on someone else's computer
There is no reasonable basis for claiming that you have the "freedom" to access information in someone else's computer that you have nothing to do with. That's actually a privacy violation.
There's a clear distinction between sending someone a file that represents computer software (source or object code) (a product) and sending someone the output of a calculation you have been requested to perform (a service).
The distinction is meaningless to the user in the example your parent cites.
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?
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?
Anyone debating that it's not has a screw loose.
We actually designed the Timescale License to be _less_ restrictive than AGPL. It contains no virality. It just prevents public clouds from offering TimescaleDB-aaS.
Timescale license does not provide that, so obviously it's more restrictive than even the most viral of open source licences.
To be specific, the sentence "the customer is prohibited, either contractually or technically, from defining, redefining, or modifying the database schema or other structural aspects of database objects," spits in the face of all the ideals of open source. I can respect your decision to choose such a license, there are understandable practical arguments for that, but I can't respect you calling that open source - if you consider that users should be restricted with what they can do with their data schemas, if you include an explicit anti-user-freedom clause, legally mandating software developers to be hostile to their own users - then at least have the guts to openly say that you are against open source (because of all the valid reasons you have, I'm not denying that, you don't have a duty to be pro-open-source), instead of misleadingly labeling your license as such.
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).
The sentence you quote is actually meant to -technically- establish a basis for what it means for somebody to run/offer TimescaleDB as part of a value added service (very much allowed) versus a company like AWS offering TimescaleDB purely as a DBaaS offering (not allowed).
There are many, many thousands of companies that use or embed TimescaleDB as part of their service or product offerings, serving huge numbers of customers. We're extremely supportive of their ability to do so. We have no "enterprise features" that are excluded or held back only to paid users.
What we aren't supportive of is AWS running "TimescaleDB-as-a-Service" as part of AWS RDS. Because we know they do that!
The clause you are quoting helps define some of the legal nuances how we get there, ideally in ways that an engineer would understand. In particular, what it means to be a value added service/product versus just "TimescaleDB-as-a-Service".
The alternative legal formulations of this can be found in, e.g.
- Confluent Community License ("Licensee is not granted the right to, and Licensee shall not, exercise the License for an Excluded Purpose. For purposes of this Agreement, “Excluded Purpose” means making available any software-as-a-service, platform-as-a-service, infrastructure-as-a-service or other similar online service that competes with Confluent products or services that provide the Software.")
- Polyform "Shield" License ("Any purpose is a permitted purpose, except for providing any product that competes with the software or any product the licensor or any of its affiliates provides using the software.") https://polyformproject.org/licenses/shield/1.0.0/
These are all getting to similar places, but just putting more emphasis of the legal definition of "competition", which we thought would frustrate engineers with its vagueness.
That restriction makes the license not Open Source. Open Source licenses MUST allow anyone to run the software, for any reason, by definition. Even "as-a-Service". It's a perfectly fine restriction to have, but it shouldn't be called an Open Source license.
(Timescale engineer here)
While AGPL is a value-add for many, TSL isn't as ambiguous in some regards and provides a lot of nice "we won't sue you for this" clauses for users. Clear communication regarding its FOSS status will only help!
That's why Open Source came up in the first place - pointing out that one of the basic reasons for the Timescale license to exist in the first place is to restrict one of the major reasons Open Source licenses exist.
There were also no claims about whatever definition of restrictive you were using. It was just a short statement that the Timescale license was designed to be less restrictive than the AGPL. You can't really be that surprised when somebody comes along and starts judging it by Open Source standards after that, can you?
Comparisons to Open Source and discussions of the pros and cons of both approaches are, of course, fair.
I think Timescale employees should remember to preface "This is our belief on the definition of restrictive" when describing the license as more open than open source licenses, given much of the community might disagree (sometimes vehemently) about that take.
Why not toss in an AGPL license option? You wouldn't be discounted off-the-bat by folks like me. I build open source. Timescale is not open source. Timescale won't mix with GPL code. I use plenty of GPL code. GPL/AGPL are known quantities. Your license requires legal review.
As a footnote, I do pay for hosted versions of most of the databases I use.
> TimescaleDB is a relational database for time-series, with some features licensed under the Apache 2.0 License but many of the features you know and love are licensed via the Timescale License (including continuous aggregates, compression, data retention policies, actions, multi-node, and more). The "Apache 2.0" version of TimescaleDB offered by Microsoft, Digital Ocean, and others includes only the features in the Apache license. The Timescale License prohibits cloud providers from offering the "community version" of TimescaleDB-as-a-service.
But I don't find any links to download the Apache 2.0 version, there or elsewhere…
By the way, I really hope you guys are able to strike a deal with the cloud providers for them to re-sell Timescale Licenses, so people can get all the great features and pay you without having to add a new vendor relationship!
Re: Apache 2.0 only version, it is on our Github readme (but yes, probably could be made more prominent):
Apache-2 licensed binaries can be built by passing -DAPACHE_ONLY=1 to bootstrap.
It's ubiquitous ("it's me, not you"), but I hate it.
I'd much rather get a straight "no."
To answer the non-answer: I don't want a crippled version of the product with features held back for paying customers. I don't know which other features will be held back in the future, or what the evolution of the system will be. My expectation is that at some point, I'll need e.g. features to comply with a law like GDPR, and some critical feature may be withheld in an attempt to monetize me.
When that happens, I end up in limbo.
With a half-open-source project, what do you do? Do you fork the system and build the feature yourself? It will never move into mainstream since it undermines your revenue source. Do you maintain a fork? No one will use your fork over mainstream and you have competing communities. Etc.
Having built systems which have been used and maintained for decades, those sorts of considerations matter much more for picking a long-term viable solution than which technology happens to be ahead this year. I'm not saying you're going to burn me (and usually by the time this happens, you've been acquired by Oracle like Java, went bankrupt and got picked up by vultures, like SCO, hired a massive number of mediocre people, like Google), but if you make a dozen decisions like this, someone WILL burn you, and that WILL cost you more than the other 11 decisions combined.
Make it easy on customers like me.
Heads up: calling out the virality of copyleft licenses as a "restriction" is a common tactic used by the anti-FOSS brigade — this includes the likes of Microsoft under Steve Ballmer that famously called the GPL "a cancer". So it seems like you're re-using old FUD tactics, even if you don't intend to.
Putting that aside, what you claim also happens to be an established point of argument that has been already heavily debated upon in the FLOSS community, specifically by the permissive licenses' side; and they actually have some truth to the claim. Your claim, instead, is nowhere near as strong as theirs.
Permissive licenses take away virality, sure, but add little-to-no restrictions of their own. Your license, OTOH:
1. Doesn't take away nearly as much virality — Derivative Works of code under the TSL are still subject to the TSL; and
2. Adds its own set of restrictions — quite a few of them, actually.
----
If your argument was that you "designed the Timescale License to be less restrictive than AGPL _specifically on the question of virality_", you'd be right. Because the TSL also adds a bunch of restrictions, your original claim does not quite stand up.
And to those who keep downvoting my comments simply because they don't agree with them - I always welcome thoughtful discussions. :-)
I believe that we wouldn't be here without these aggressive copyleft licenses, and some developers embracing this license again is a good thing. I'll always prefer Nextcloud because it's AGPL. Similarly I'll use Grafana with less hesitation since it'll be AGPL from now on.
Being able to see everything inside a software and not binned as community/enterprise is better from my point of view. I'd happily pay for AGPL software, and I already pay a lot of money for licenses so, it's not about money.
Maybe my observation on other places was a reflection of SV mentality, who knows.
I could image that its the same with other corporations. In the end that might hurt the popularity of Grafana quite a lot.
I think if there would be a possibility to pay money to have what we are doing reviewed by Grafana and be "certified" to be withing what they consider acceptable under the AGPL that might actually be a good option
My first post is about the fact that even though the planned use case would be 100% compliant to the AGPLv3 license the fear that is associated with that license could prevent such use.
> That makes zero business sense
Purchasing a license in that case while not strictly necessary might be seen as an insurance. So that makes business sense.
In the end though I highly doubt that's whats going to happen. The most likely outcome is that we just get told to get rid of Grafana and use something else.
Whatever you replace it with will have the same licensing overhead. Again, this makes no sense.
If you said we can’t afford to pay for it, fine. But you explicitly said you don’t think cost is an issue.
Maybe I’m making the wrong inference, but it sounds like you’re afraid your higher ups just don’t want to have any restrictions placed on whatever business need it is that Grafana is filling for you. If I haven’t misunderstood that fear, then I regret to say that any software product other than one you build and maintain yourselves will come with some restrictions or the possibility of future restrictions.
When I say this makes no business sense, that’s what I’m trying to get at: other than (potentially) licensing cost, any Grafana substitute will come with the same issues, plus switching costs. So unless there is a FOSS product that provides a better solution to your problem, by definition switching will be more costly than maintaining status quo.
Or am I missing the point?
“What can I do with Grafana in my business under GPL?” is much more clearly defined than the same question changing only the last word to AGPL. Alternatives available under Apache v2 or other non-copyleft licenses are also clear. For GPL, all I need to be careful to avoid doing is distributing the software and I’m in a well-understood situation.
It’s this closing off of futures unknown but possible that is markedly worse under AGPL. Anything that you’re doing today that could apply externally as well seems to be an area where a decision to continue to follow Grafana tip could bite you. And not updating could also bite you. Grafana will lose contributors and users over this. All of that I’m sure Grafana considered and made the best choice for Grafana.
Losing users who would otherwise be willing to pay for a commercial license (as the OP said they are) that could be negotiated to explicitly cover whatever future use case they’re concerned about? That makes no sense.
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.
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.
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.
- 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)
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...
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.
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.)
If it's anything like dynamic linking and GPL that could be considered okay even if it's not the intention of the licensee. Seems like the license should be more explicit about what "interacting with" entails.
Is that a problem? Fork it on github, and update the repository every once in a while or upon request.
It turned out alright.
TL;DR FSF is heavily responsible for the "GPL is viral" message sticking.
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.
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...
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's GPs point.
If legal is familiar with AGPL, like they are with GPL, BSD or Apache, they should see no issue. This change does not really affect anyone except for the very small number of people/companies that make their own changes to software and make this software available online to others.
If you aren't such a company and legal would still say you guys can't use e.g. Grafana anymore... the truth will be that it's some incompetent (or severely underhanded, where they can't do any research and err on the side of caution) legal department, failing at their jobs.
Unless you’re repackaging Grafana into an app bundle for customers to use, there’s no violation occurring here, right?
If a developer uses GPL Emacs to write a server that uses GPL libraries and Google runs that sever in their datacenter it is very clear that Google doesn't have to release any source code.
However Google's argument is that if they make a web application that uses AGPL MongoDB as a backend it is unclear if 1. The user is interacting with MongoDB over a network and 2. do they need to release the code of their server.
It appears that the answers are 1. Yes and 2. No but apparently Google isn't confident to use that in court. (Or at least they don't see enough benefits for that risk)
https://opensource.google/docs/using/agpl-policy/
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.
https://docs.bazel.build/versions/0.24.0/be/functions.html#l...
On the other hand, one might view this as a benefit. So, I guess it depends on who you ask, really. It's not clear that big corporations would necessarily have an easier time with SSPL or TSL either.
Note: IANAL, please do not take my understanding of how these software licenses work as fact :)
"...extremely difficult for Google to comply with..."
and
"...presents a huge risk to Google..."
and later in the document is the best part:
"This viral effect requires that the complete corresponding source code...".
All from a company which built itself on GPL software. This reminds me of Steve Ballmer ranting about Linux being a virus 20 years ago.
More:
"Do not install AGPL-licensed programs on your workstation, Google-issued laptop, or Google-issued phone without explicit authorization from the Open Source Programs Office."
Assuming Google follows its own policy, this just creates a hassle for its employees. Worse, Google making this public sends a strong anti-AGPL message to other companies. I'd bet $10 RStudio server (AGPL) is installed somewhere at Google (perhaps the commercial version). But other organizations with less sophisticated legal departments might just ban RStudio completely following Google's lead. I would not call Google irresponsible here, but I think it could act more responsibly.
https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html
Going against interest of Google (and similar companies) is one of main points of AGPL, so this indicated that it works as intended!
From Grafana:
"AWS is a strategic partner, and given the commercial relationship AWS has with us for AMG, AWS and their AMG customers are not impacted by this change. We hope that other XaaS providers follow AWS’s lead in working with open source software companies in similarly sustainable ways."
https://grafana.com/blog/2021/04/20/qa-with-our-ceo-on-relic...
Elasticsearch changed their licence for more or less this reason [1]. So it wouldn't surprise me if Grafana's motivation was to solidify their position against Amazon.
And look how it's going for them. AWS very nicely forked elsasticsearch and now has the fork that seems to be gathering quite a bit of momentum. I doubt that AWS was even considering talking with them after they announced the license change.
Funnily just before you wrote this comment, I also tweeted just that :) : https://twitter.com/juliusvolz/status/1384599249082626052
I know :( I just meant it's the ideal we should strive towards, even if we never fully reach it.
[note: am co-founder/ceo of grafana labs]
The way I've understood it is part of the point of CLA's is to allow license changes, and that without them no license changes are possible to community projects. Because all the contributors own the copyright to the code they contributed, which they licensed under the existing license. To change the license you'd need to contact all the contributors and get permission (so okay, not impossible, just infeasible). The CLA is getting that permission in advance, to let some controlling body change copyright later.
and so is world peace. Yet, it's a worthy goal.
> if you decided that you now need different constraints
and if you own the copyright, you can always relicense it to suit. How _other_ people chooses to use this software is not under your control, even though you're the copyright holder. This is exactly what it means to have freedom.
AGPL can be linked against GPL.
What you cannot do is:
1. change the AGPL software itself and provide it to end users in any form without providing updated sources
2. make a combined product and not provide sources for all of it under AGPL.
3. Also there is nothing to prevent you from releasing sources of your software dual licensed under both MIT and AGPL.
1+2 are plain old GPL. 3 is just a basic consequence of owning all the IP, but it isn't possible to release a patch to an AGPL under MIT.
AGPL has massively enhanced virality, which is the entire point.
Yep, but AFAIK (not a lawyer I have just spent some time trying to figure this out) it doesn't affect other software over the Internet:
Some examples based on Friendica:
- Chrome won't become AGPL licensed by being used to access Friendica
- MariaDB won't become AGPL licensed by being accessed by Friendica
- any changes you make to Friendica must obviously be AGPL (if you let anybody use it)
- if you want to write an extension for Friendica it needs to be AGPL (but if you want you can also release it under another license)
- if you want to put your or someone elses open source or proprietary code into Friendica you must plan to release that code too under the AGPL (of course you can still release it under another license simultaneously but it must be available as AGPL in addition.)
The difference is that not in what it infects but how it spreads - kind of.
Obviously it can't change the license of other products, but other products trigger the virality. For example, Apache calls a module which triggers generating a graph from your custom grafana instance. Your custom code is now AGPL.
You only have to license your own software as AGPL if it is a derivative work of another AGPL licensed program.
Edit: it just occurred to me that opting for popularity over money is "paying" yourself with exposure.
Giving users access to software without distributing it to them is a recent technical innovation. The AGPL exists to give those users the same rights as more conventional software users. The underlying goal - ensuring that all users have the four freedoms - remains the same.
> Why does 'freedom' in the Gnu sense require coercing all developers to use the same license?
The copyleft trick only works that way. The goal is to ensure that all software users have the four freedoms; ideally they would be enshrined into law somehow, but failing that, a license is the best we can do.
I do sincerely share these ideals, but which paths get us how far with which real-world trade-offs, that's more complex.
For ideal policy, I like this direction: abolishing copyright and patent law and replacing them with (A) mandatory source-release for all published works that need source in order to practically study and modify and (B) prohibition on DRM or other measures that technically limit freedoms.
While the whole project must be available under the AGPL, nothing prevent individual pieces to be under a more permissive but compatible license.
They're not making everything AGPL and seem to be aware of the kind of thing you're talking about. From TFA (emphasis mine):
> Going forward, we will be relicensing our core open source projects (Grafana, Grafana Loki, and Grafana Tempo) from the Apache License 2.0 to the Affero General Public License (AGPL) v3. Plugins, agents, and certain libraries will remain Apache-licensed. You can find information in GitHub about what is being relicensed for Grafana, Loki, and Tempo.
If yes, than it's a really bad bad thing and I hope they change it.
CLAs that permit relicensing for a project that already uses permissive license is fine and fair. But doing that on a project with a copyleft license is a bad taste. It would enable Grafana Labs to give Grafana to a party X which can then give it to party Y, where X isn't required to give all the necessary freedoms to Y.
[1] https://web.archive.org/web/20200311075025/https://grafana.c...
Hence if you contribute to a GPL project with a CLA, some companies could still publish your code closed source through a commercial license deal.
IMHO who holds the copyright is more important than the actual license. Anything OSI endorsed should be fine. However, AGPL to me screams "talk to us about buying a special license if you want to use this commercially". That requires copy right transfers. AGPL without copyright transfers does not make sense for companies for this reason.
Loki: Web Analytics Dashboard for NGINX
Tempo: An open source, easy-to-use and high-scale distributed tracing backend. Tempo is cost-efficient, requiring only object storage to operate, and is deeply integrated with Grafana, Prometheus, and Loki. Tempo can be used with any of the open source tracing protocols, including Jaeger, Zipkin, and OpenTelemetry.
1. Fork something Apache-licensed.
2. Build a community with "awesome" buzz.
3. Start a company, promising bells, and whistles.
4. Hire more and more people because bugs are piling up.
5. Now we need VC to fund all of that.
6. VCs are in charge now; they require "growth" and more paying customers.
7. Start using dark patterns. On the download page, hide the actual package download, redirect users to paying cloud or paying software version.
8. More frequent releases, more drastic redesigns, and changes. VCs need to see where the money goes.
9. VCs are still not happy. The company is spending more and more... relicense everything and force users to pay for the product.
Mongo, Elastic, now Grafana... TBH I don't have a problem with *GPL, but let's be honest: they are luring users and companies with permissive licenses, promising "forever" stupidities, then suddenly and silently change the rules. The funniest thing is that most of these projects started on something with apache license...
plus, dashboards and configuration are inherently ("source available"), so even if one were to consider them to be modifications (which they're not), you are already distributing them in source form ;-)
[note: am co-founder/ceo of grafana labs]
> A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an "aggregate" if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
Doesn't a product that offers grafana-powered dashboards "form a larger program" ?
(Whereas if you integrate e.g. editing metrics and calling grafana's API to add them to a dashboard, at that point it seems far more likely your system would be considered a derivative of grafana - but at that point you really are implementing a grafana editor product (or at least a product that includes a grafana editor) rather than just using grafana to monitor a separate product).
Is that considered a modification?
In my eyes it shouldn't be as no changes are needed to any Grafana code, it's all just networking.
Interested to get your perspective.
Yes; if you're going to do this, then using AGPL is so much better than flavor-of-the-week license.
> If the core companies maintaining them did not do this they would eventually die and these projects would slowly rot.
It sounds like you're suggesting that anything but hard-copyleft is doomed to die out, which is a somewhat hard argument to make in a world with lots of counterexamples (postgres, the assorted BSD OSs, kubernetes, Android).
K8s and Android have a major corporation backing them, which extracts value from them in its internal operation anyway. They are such products that using them by competition commoditizes said competition. Android on like 95% of phones outside China has very important proprietary parts, making it hardly compatible with a bunch of top-tier apps.
BSD OSes don't do excessively well, with regard to market share and mind share. They are reasonably healthy though.
All of the Apache projects (some to more/less an extant than others).
Most programming language implementations (e.g. CPython). Memcached. WireGuard. SQLAlchemy. Web Frameworks like Flask, Django, Rails, on and on.
There are many open source technologies that do not seek to capture the value they create with licensing hijinks.
I don’t think it’s an accident, that the ones that persist across generations are generally not structured as VC-backed firms, who care a great deal more about “value capture” than the average programmer capable of building such foundational systems. Usually “value capture” is correlated with “consumer harm”, and so they’re replaced over time.
From your example, K8s will definitely outlive Google. Hard to say about Android.
What leads you to say that? I wouldn't be surprised if kubernetes is dead in 20 years. I would be very surprised if google is dead in 20 years.
But I don’t think there’s a significantly-simpler, mature abstraction for doing container orchestration, than K8s.
K8s’ main advantage/stickiness factor, is how abstract and modular it is. It’s an opinionated Kernel that gets most things right and has a huge ecosystem of tools built around this kernel.
It has a very similar set of stickiness factors to Linux, imo, although the origin story couldn’t be more different of course.
I think if anything replaces K8s, it’ll take a Linux-like shape. But K8s gets enough things correct (licensing, api, modularity) that it’ll be hard to replace it wholesale.
What I was trying to say is that FOSS was never about capturing commercial value, and always about capturing the value of the freedom to inspect, share, and tweak.
In this regard, going AGPL is preferable to what Mongo or Elastic did. They basically turned to commercial "source-available" offerings, much like mainframe software from 1970s.
I totally agree that the “we are now AGPL” route is preferable.
FWIW MongoDB was already AGPL, but that wasn’t enough for them I guess, they wanted more money. Old HN thread on the topic: https://news.ycombinator.com/item?id=18229452
From my perspective, MongoDB (the company) “wins” by getting more people to purchase their product, and making MongoDB (the software) better is only one of the many possible dimensions to optimize in pursuit of this goal. When I see a license change by such a company, my null hypothesis is that somebody realized the marginal cost of changing their license would capture enough value (even if a smaller pie) to offset any potential harm to the community, brand, etc. It’s perhaps too cynical a view, and I’m open to learning otherwise.
I do agree that the AGPL is a mess, and there seems to be a consensus around this fact. It isn’t the correct license for a VC-backed firm trying to SaaSify a FOSS project, which is what MongoDB learned. And since SaaS is ostensibly its target audience, AGPL doesn’t come away looking great.
More broadly, I’m concerned for the developer productivity that’s wasted (from a humanity/society POV) in the corporate-driven pursuit of defensible and sellable intellectual property. Nothing wrong with making money, but I think it’s a tragedy that capital assets aren’t broken down, recycled and repurposed in the software world like they were in the industrial world.
From this angle, I view the GPL as a positive influence towards making our work less repetitive and more reusable. It makes me sad to see MongoDB move away from any GPL-based license, even when it’s in their shareholders’ best interest, because it means all the dev hours invested into MongoDB post-2018 likely will have been invested in vain.
But maybe I’m wrong and their new license means their software is still salvageable for the future, when MongoDB (the company) no longer exists! I’d love for that to be the case.
From reading all the press, it feels like MongoDB did not do this to garner more revenue but to instead prevent open-source parasites from causing MongoDB to lose money or even go out of business. When I read Eliot's posts in 2018, it feels like he's trying to stay in business, not be greedy.
From a commercial point of view, databases have been shown to need management. Maybe someday somebody will write a database that has a magic simple-to-use endpoint, stays up 100% of the time, and doesn't require a cadre of people dancing around the database chanting spells to operate it. None to date... So the cloud providers capitalize on that need, and wrap control planes around databases - often hurting the people who are working hard to innovate on that software - and deserve to be paid for their work.
As to harm to the open source ecosystem, cloud providers wrapping managed services around databases has been shown to stifle innovation on those open source products. I.e. why would anybody want to improve PostgreSQL or MySQL when Amazon Aurora PostgreSQL and MySQL exist, CloudSQL and Azure SQL all exist - and may or may not take the changes - and even when they do, it takes many months or years.
Finally, I guess I'm puzzled by your last two paragraphs.
You mention that "all the dev hours invested into MongoDB post 2018 likely will have been invested in vain" - why? They go into the community edition, which anybody can use. They go into the EA and Atlas version, which customers who want enterprise-quality software with enterprise-quality support can use.
Your discussion implies MongoDB's license (and Elastic and now a host of others) prevents people from contributing to MongoDB. It doesn't. Or that it prevents them using MongoDB as much as they want. It doesn't, with one exception - and that exception probably affects <0.01% of the users of the software. The MongoDB license (and the Elastic and TimeScaleDB and many other licenses) don't even prevent anybody from wrapping up the software into a cloud service and offering it for money. In fact, many companies (SAP, IBM, Tencent, Alibaba, to name a few, apparently do). It just means you have to talk to the company before doing it.
I personally love MongoDB and I think the SSPL ended up preserving the company and preserving innovation, which is good for the open source community. At least it's not a complicated mess like MySQL and MariaDB.
That said, I'd love to hear more about how SSPL actually damages anybody in a meaningful way. I haven't yet seen anything except a philosophical argument. I'd love to hear it.
I agree that, from a commercial point of view, databases have been shown to need management.
> As to harm to the open source ecosystem, cloud providers wrapping managed services around databases has been shown to stifle innovation on those open source products
I don't think we agree on this. I think PostgreSQL has improved dramatically in the past 5 years, coinciding with (but perhaps not caused by) its increased adoption by AWS customers. The more customers/users FOSS projects have, the more information they have to work with, and the more interested developers they have to draw contributions from.
But it's OK, we don't need to agree on this point. We can adopt the axiom "MongoDB is more innovative because they have a non-OSI-compliant license". Again, I don't think this is necessarily true, but I can concede it so it doesn't distract us.
> You mention <quote> - why?
The reason requires stretching our imagination just a bit, but I hope you won't see it as philosophical, since real people plan against scenarios like this. Let's say that, today, MongoDB the company is benevolent, and happy to permit anybody who asks to operate their software. Everybody's happy.
At some point in the future, there's some management change, and the company that owns this IP has decided that the best thing they can do is box-in the customers they have, and make other service providers' lives as legally difficult as possible, thanks to the license they switched to in 2018.
Now, in the future, if you want this database management service that we agree is important and necessary, and you don't want to use MongoDB's platform, you're out of luck.
If you stick to databases with an OSI-certified license, you never have to make contingency plans for this future. There will always be a vendor for code with this license, as long as there's sufficient customer demand, until time immemorial.
Because you can not control the tail risk of MongoDB becoming an Orcale-like company (or, for that matter, being acquired by Oracle), you can not rule out the possibility that all vendors will be excluded from offering MongoDB as a service. You need to plan for the worst case, and treat it as a time-bomb.
You might consider this a philosophical argument, but, practically, this is why OSI has rule #6, and it's why the SSPL (and Elastic License) are not OSI-certified.
> Your discussion implies MongoDB's license (and Elastic and now a host of others) prevents people from contributing to MongoDB. It doesn't.
Correct, it doesn't. It prevents them from contributing to software with a license that does not "Discriminate Against Fields of Endeavor" and does not "Restrict Other Software". Which again, doesn't seem like a bad thing today but opens up paths that are otherwise avoidable.
Even if we buy the innovation argument, and even if this change was made with the purest of intentions, it's noncompliance with OSI standards makes it not worth the tail risk for people who want to pick software today that will be serviceable in 15 years.
Sorry, but free software IS open-source software. I take issue with how you're presenting these. Perhaps a better term would be liberally licensed software, as opposed to copyleft.
Market share/mindshare is almost an inverse measure of quality at this point!
Not necessarily knocking it, though!
If you only compare things above a certain quality threshold, That's true of any creative endeavor. Not too many people will say that Mcdonald's has the best burgers, or the pop singer of the week is their absolute favorite.
Postgres? They have a very specific governance model - a single company can not employ over 50% of the core contributors, to guarantee that the direction of the product is not taken over even by accident.
Is that really "outlier" behavior? More and more important open source projects are prominently backed by a single large tech company. React, TensorFlow, TypeScript, Go, etc.
If you just look at the last decade, there has been more important work done as "single-sponsor open source" than under the GPL.
Those projects have ultimately the interests of the corporations in mind not of the users.
Ever wonder why overcomplicated technical solutions are hyped so much? Why does everyone and their dog need to run Kubernetes? Why is it all Maschine Learning instead of good old fashioned methods that would do much better? Well those corporation have just the fitting cloud computing offering!
Sure many of them happen to be useful and are simply for increasing the prestige of the company but let's not act like it is a good thing.
Which leads to companies that do not (eg no CICD or data architecture standard) adopting tools that assume they do (k8s & tensorflow).
(And yes, I realize this is because most folks who work at the former aspire to jump ship to the latter)
Say what you want about Microsoft, but they do a much better job of meeting the customer where they are (dumpster fire) instead of where Microsoft is.
Simpler explanation than some nefarious plan. Software engineers love to play with the coolest new thing over working with some proven solution that might have worked well enough. I think these corporation just exploit that with cloud offering. They don't really get to pick what people like (they try but suck at it) but have the money and resources to exploit whatever ends up being the popular new thing anyway.
These corporations are eating the world. They need not keep their source code closed, we're all employees, generating revenue for them.
One of the only reasons to keep source code closed is to retain your competitive advantage. They need not that when there's no competition, or a very slim chance of some appearing one day.
I'm joking, but it sounds a bit more true than I expected. Also, mind you, I'd rather have them publish code than not.
I think "dystopian nightmare" overstates it. Monopoly control over particular technology is also a working definition of the the patent system. Hey, wait a minute ...
TensorFlow and Pytorch are similar. Yeah, people end up using machine learning a lot when they don't really have to. But researchers and developers can achieve a lot more when they don't have to reinvent the wheel, and machine learning has provided some really great things.
Like, it seems like it should be fine, given that TensorFlow is part of their core AI mission, and they're heavily invested in Go, and Android probably isn't going anywhere. But people once thought that Java and MySQL were safe in the hands of Sun, too.
But I do note that your examples are from quite a narrow sector. TypeScript, Go and React are all languages. TypeScript is a nice facade over JavaScript, and React is ... well, a very powerful DSL.[ß] Go is very much a Google project, developed perhaps more out in the open than in a traditional open-source sense.
As I understand, TensorFlow was originally an internal Google project, which they at some point decided to open up. It may have had something to do with their TPU cloud offering or not. If we wanted to compare low-level language or domain material, we should probably take a look at something like Boost. People who do C++ tell me that Boost is a pretty good approximation of C++ standards' evolutionary playground. And if we're going for new languages, shouldn't we also include Rust? It was backed and promoted by Mozilla, but how much of its development was driven solely by Mozilla, and how much was done by the interested community at large?
ß: Our frontend team will probably want to roast me for that one, but there isn't much visible JS left in modern React code. Not for my eyes, at least.
> ß: Our frontend team will probably want to roast me for that one, but there isn't much visible JS left in modern React code. Not for my eyes, at least.
Can you clarify what you're talking about here with regards to React? I can see calling JSX a DSL, but React is a language now? And there's no JS / TypeScript in your React code base?
In a way, it is. Whenever you write some module in your project, you're effectively designing a language. Every function you add is a new verb, every type you define is a new noun[0] - and the relationships between them form the grammar. It may sound trivial, but I think it's an important and underappreciated point. Modularizing and abstracting is done by building languages on top of other languages.
We usually make a distinction between what is a "library" or "module" and what is a "language", by... it's hard to capture the distinction exactly, but my guess is that we reserve the term "programming language" for languages that a) define a large, highly composable set of building blocks, and b) have complex translation into a lower-level language, ultimately yielding executable code. Whatever the distinction could be, in reality, it's a spectrum.
--
[0] - Well, a piece of a noun phrase. Maybe. I'm not a linguist.
I base my opinion on my own interpretation: for me modern React looks a lot like the offspring of QML and a flavour of Lisp.
The ultimate fate of the wave of companies switching to AGPL and similar licenses now will be the proof (or disproof!) of this.
But yes, on the whole it's true: most open source projects aren't SQLite, and most aren't going to many any money just because they are open source. Open source is a business tool.
https://www.cncf.io/people/governing-board/
they still do quite a lot of heavy lifting though in contributing to a variety of CNCF projects if you look at the numbers: https://all.devstats.cncf.io/d/5/companies-table?orgId=1
fiscally the impact would be a membership fee which is a small percentage of revenue
The organization is fairly well diversified in terms of members and revenue sources but we appreciate Google's continued support in helping the organization grow, we think it's benefited them in projects like Kubernetes where the work is done by a larger community all working together: https://www.cncf.io/cncf-kubernetes-project-journey/
license noob here - can you elaborate on why exactly it is so much better?
A key point there is that a user can use the software quite freely without restrictions only with the caveat that modifications have to be made available to users. (AGPL is slighqtly more complex)
Many of the "modern" licenses allow to look at code, but prevent distribution and/or modification and/or usage. They typically aim for any "proper" usage requiring a commercial license and not giving the guarantee that code can be fixed in case the original vendor stops working on it.
A license that allows all typical freedoms except "use the software to start a SaaS using proprietary infrastructure" is fine by me.
So you're fine with a license that can't be used for SaaS. So basically you're happy for the commercial internet to be powered by proprietary software - with all that would mean for free software.
Are you serious? Once you look past the most superficial level, they're not even close.
SSPL require to release source code for every piece of your infrastructure if your business model seems like Amazon. This is descrimination which both FSF and OSI are not allow.
Most of the other licenses, I can't use in any of my projects without running into license compatibility issues.
standards evolve over time, it was entirely possible that Grafana could have thrown its weight behind SSPL and helped legitimize it more.
I assume you mean the OSI. But it's not just them with a problem with the SSPL. Debian and Fedora both reject it too, independently, for being non-free.
Which would not have been a good thing in any way, so I'm glad they didn't do that.
The problem would go away if you renamed the license to something else. It's that stupid.
A lot of the flavor of the week licenses exist for this reason, as well as to address some of the weak corner cases of the AGPL.
For shrink-wrap software, GPL can be an issue. For hosted software, it’s generally not (which is why all the desire to make other licenses, including AGPL).
I'm interested in what the 'weak corner cases' of AGPL are considering it was pretty much made to correct some weaknesses in the GPL.
If I use AGPL-licensed software in a SaaS type of environment, I still need to release the source-code even if I'm not distributing the software directly, correct?
"Both versions of the Affero GPL were designed to close a perceived application service provider (ASP) loophole in the ordinary GPL, where, by using but not distributing the software, the copyleft provisions are not triggered. Each version differs from the version of the GNU GPL on which it is based in having an added provision addressing use of software over a computer network. This provision requires that the full source code be made available to any network user of the AGPL-licensed work, typically a web application."
The non-Affero GPLv3 handles Tivoization, FWIW.
[0]: https://en.wikipedia.org/wiki/Affero_General_Public_License
Even if true, why it is problem? Company so misinformed is not going to be helpful anyway.
There's not much else to it.
Too. Effing. Bad. These companies can either figure out how to work with FSF-authored licenses or they can go make their own alternatives. I have no sympathy for them.
Or for devs that make excuses for this attitude. They deserve to be force-pushed onto software like when Apple decided to ship zsh instead of bash because they didn't want GPLv3 in their OS. Or that whole Rails brouhaha last month.
Companies should not be trusted with permissively licensed software. You don't get to play shell games with public access.
The correct answer is that your code stealing is not transforming the product into GPL or into my proprietary license. If I catch and ask for money from you you have more options with the GPL code then with my proprietary code. With the GPL code you can just GPL your code changes, maybe the entire product but you are not forced to pay me anything. With the proprietary license though you don't have the option and I can make you pay.
So if you like that much the "infectious" word, you should add an "optional" modifier , you can always not GPL your changes, remove the "stolen" code , pay damages? (not sure if this ever happened).
What I observer the issues with GPL like software is lazy developers and companies that would like to "npm install" solutions and skip doing the work.
In reality, your proprietary code can only be GPLed if you explicitly release it under that license.
What people are confusing is that it is a violation of the GPL to release binary code that links (statically or dynamically[1]) with GPL-ed code without also releasing that code under a compatible license. This is where the "viral" label comes into play, since the easiest way to link against GPL code is to just make your code GPL as well. But it _does not_ mean that if you mess up and release a binary blob with GPL code in it that you've given up all rights to the non-GPL parts.
[1] LGPL allows dynamic linking, plain GPL doesn't distinguish.
I have my own proprietary code. I decide to make use of GPL code. Then I distribute the binaries. Now I have to make the source available, correct?
This source that was just made available (that includes my "proprietary code" and the GPL library I used) needs a license. At this step, I already lost my proprietary code and made it public - which might be unacceptable for some, but that in itself does not make GPL viral. Now that I need to license the released code, what options do I have? Can it be less permissive than GPL? My understanding has always been "no".
Nope! That's one way to fix the licensing issue—but you're not forced to do that.
Another option would be to immediately stop distributing your binary and not distribute it again until you can replace or otherwise excise the GPL code that caused the licensing issue.
And how does immediately stoping distribution help, legally? If I have already distributed the binary, the recipients are already entitled to the entire sources, no? Or does GPL have a "I have learned my lesson" clause?
I don't think you'll see a lot of major projects under super-liberal licenses in the future. You will see such licenses for libraries and other components.
And that seems fine, at least if you subscribe to the Unix philosophy of composability. Honestly, I love Django, but for some projects I'd love even more to use just Django's ORM without all the other stuff (which I also like, but is irrelevant for some projects).
FreeBSD is 27 years old. Postgres is 24 years old. SQLite, which is placed in the public domain, is 20 years old.
You will forgive me not holding my breath.
I'm not sure I agree. Yes, standardization is a good thing and AGPL is the "known evil", but having read it I do think that it is a very very complex piece of text - personally I'd go so far as to say that it is close to incomprehensible and would prefer pretty much anything else.
But even aside from that the sheer number of companies that point blank ban AGPL licensed software from being used in their stack could be used as an indicator as well. Though this may be due to the common misunderstanding that it is a viral license, which just goes back to my prior point on it not being clearly worded.
I won't even mention alternatives, I'm sure they all have issues, it is a complex topic, but if it were up to me the AGPL would not be my first license choice.
Alternatively, catering to those companies wouldn't bring relevant benefits to the project anyway
I don't think it's a big loss though.
With the AGPL that would require dual licensing, and that draws flak as well.
I think the notion that OSS means there cannot be any money involved simply cannot hold true anymore these days. Software has become extremely complex and requires dedicated developers working on it - and they need to eat.
We are currently seeing a lot of companies changing their licensing model for a reason - because there is not currently a middle ground between OSS and a working business modell that the OSS crowd doesn't hate.
That being said, I'd love to be proven wrong here!
I think the virality and companies not liking it is the license working as intended, honestly; it's supposed to be viral, that's the point of copyleft, and obviously companies take issue with that (although I agree that some of this might be misunderstanding scope / what it infects), but that's not a bug, it's the license doing its job and companies making decisions based on that.
As I said, I'm explicitly not mentioning any alternative here because they all have issues, but the AGPL's wording is much more complicated than most and that (perceived) insecurity around it is my main criticism.
It makes sense to use attractive-to-end-users licensing at first and later switch to a license that helps lock in support bucks. Call it bait-n-switch if you like, but even the SQLite folks did it, only they didn't do it with the _license_ but with the _test suite_ -- either way they made it really difficult to play in their space and/or fork.
This is a good thing.
Linux being GPL 2 was great for computing when we had thick clients, but now everything is moving to the cloud. Companies can innovate on top of it and not really give back.
How does the AGPL screw over the community less than the other licenses? AGPL is problematic for a slew of reasons, lots of corporations (whether or not you agree that for-profit enterprises make up the bulk of the "community" is a separate discussion) disallow it entirely (mostly thanks to Google's precedent).
The OSI or FSF-approved licenses form an ecosystem. I can have a project which mixes AGPL, GPL, and BSD code. I can make that part of the next version of Ubuntu. I can borrow bits of code. It all works together. If the goal is to have a computer running free software, AGPL builds towards that goal. If the goal is to use the code in new and unexpected ways, AGPL builds there.
The non-OSI licenses are walled gardens. Even the ones which nominally allow remixing require me to drop a few grand on a lawyer before remixing them (more grand if it's international).
AGPL is toxic to some corporations for mixing into their proprietary projects, but the commercial dual-license takes care of that. Most corporations don't mind spending money.
AGPL also gives a long-term sustainable pathway if the original vendor goes under or goes evil.
AGPL tries to ensure that third-party providers are at least sharing their development efforts to the same extent that those efforts were shared with them. AGPL doesn't try to give anyone an unfair advantage at providing the software as a service, not even the copyright owner.
Most people, and companies, that use this will just run an unmodified Grafana container, maybe with some plugins (not of their own). AGPL doesn't come into play here (the software is not modified).
This change would really only impact a company that takes Grafana, puts a bunch of patches on top of it and wants to offer that as a SaaS. Those guys could still even do that, they'd just have to publish their patches. Or, quite possibly, just pay for a commercial license - a lot of GPL/AGPL software is actually dual-licensed, with more ore less "dowhateveryawant"-style, paid licenses.
All of this sounds fair to me.
Ahem: Grafana Labs Brings In $50M Series B For Open-Source Developer Platform: https://news.crunchbase.com/news/grafana-labs-brings-in-50m-...
I completely support the right to chose your own license and how you want to sell and use your own code, but let's be honest here. This is done because investors have discovered that it's possible to earn money on services around Open Source products, and Grafana Labs has gone all-in on this approach. Now they need the relicensing in order for the business model to remain viable. We're lucky that the code remains AGPL, but notice that they are still not committed to ensuring that all the code will remain AGPL (i.e. they still want CLA so they can relicense later).
This is exactly what the parent is saying though. They're going through this process to ensure that their business remains viable and they can continue to build and support the project.
> All of the most important software of our lifetime is going through this relicensing effort as the creators attempt to capture the value of what it enables.
To me this sounds like the relicensing is done so that a few programmers finally can get paid for their hard labor while maintaining critical software we're all using. What's actually happening here is that some creators have convinced a few investors that they'll be able to give a huge return on invest by building up a sales department around the product. And now the realize that they're not able to accomplishing that with their original license.
It's a perfectly acceptable business strategy, but it's not necessarily the only way of running an open source project.
I'm still hoping that we (the open source community) can find even better ways of ensuring high-quality software remain open source without being so dependent on current mindset of investors.
AGPL is nice and all but for contributors this does not really matter at all because of the CLAs.
I will never contribute to projects which reserve the right to relicense, e.g. take ownership over my contributions, however small or big they are. I think companies will do the same.
If they would remove the CLAs, they would signal to companies and contributors that they are serious in providing an open ecosystem, to which other people contribute willingly "for free". But currently they are not, likely because they fear competition.
but, i'm curious to understand your perspective here.
do you mean to say that you'd never contribute to an apache licensed project?
anything that is apache licensed can be relicensed by the project, even if there isn't a CLA
[note: am co-founder/ceo at grafana labs]
They are a much higher barrier to entry for a lot of contributors. No, they're not all the same, but they make it harder. Each CLA needs to be reviewed and approved by company lawyers. It's kinda like creating a brand new OSS license that way.
To use a concrete example, the Google open source CLA is awful. At my previous job our lawyers refused to sign off the Google CLA. One of my engineers wrote a patch that we wanted to get upstream. Since, it would be generally useful.
Basically, the patch could never be merged, because we had a legal stalemate between us and Google.
I would highly recommend using https://developercertificate.org/ instead. This is what we use for Prometheus. It's also used for GPL projects like Linux. It's simple, standard, and used widely.
AFAIK, it's up to copyright assignment for re-licensing.
For example, contributing to Prometheus assigns all copyright to "The Prometheus Authors". The DCO just attests that it's OK to do this.
So, I don't think there's anything for or against re-licensing in DCO, it's just out of scope.
Why?
Because CLAs make the sharing agreement asymmetrical. I want to provide my changes under exactly the same terms as you are providing your code. Additionally to the fact that CLAs are typically layed out in favor of the corporation and not of the contributor, they cause me to read that CLA, interact with it and most likely misinterpret it, because I'm a dev, not a/my lawyer. With common licenses I know what I'm getting and independent lawyers have created them, weighing the benefits of both sides.
Of course, the last argument is not really applicable if you depend on widely-known CLAs like the Apache CLA (I use widely-known because I have heard of it, but I really have no clue what it entails and have never signed one).
The issue of apache projects vs grafana is easy. I have never contributed to Apache projects and would hesitate to do so if I have to sign a CLA, but the issue is not as big because the License (AL2) of most of these projects already somewhat permits relicensing and AL2 is already a pretty weak license, because it is not infectious like the GPL family.
But allowing relicensing on an AGPL project means that if I change anything on your code then I have to publish it. If you change anything you don't have to publish your changes (because you can relicense). This is not contributing on equal terms, so I'm out.
Of course, one can also argue that you're doing much more work so the asymmetry is justified, but my work has not less value than yours and your benefit in this relationship already is determining where to go with the project.
That said, I am not a lawyer and my understanding of licenses and CLAs is very limited and could also be wrong. I'm not even accounting for different legal environments/jurisdictions here.
look at our actions since the inception of the company, as well as our "big tent" philosophy; i think they speak for ourselves.
we built a sustainable business over the course of 4 years, prior to raising a dollar of VC money. we raised VC money to go even faster.
most of our VC money goes to paying our employees.
most of our employees are engineers.
most of what our engineers do is open source.
if we don't build a sustainable business, who will develop the software?
the overwhelming majority of development on things like grafana, loki, tempo are done by grafana labs employees. plus, we are the main contributors behind other OSS projects that we didn't create and don't own (like prometheus and cortex).
[note: am co-founder/ceo at grafana labs]
Grafana Labs and all these other companies have recieved both value add and goodwill free marketing from open source contributions and communities, and I don't see these companies being at all interested in figuring out who/what they've gained value from, beyond the currently existing company, in order to make a profit and benefit the founders and shareholders.
I'm not against AGPL. I'm against the relicensing of software made in good faith against one model of OSS being discontinued and basically forked by the most prominent for-profit company that have hitherto received the significant benefits of both contributions and goodwill that being more freely open source brings.
By relicensing you've probably significantly reduced the number of companies willing to run future versions of your software, and the number of companies willing to build businesses off of extending it and offering that value add, while still potentially contributing changes upstream. You're going to slowly eat away at that good will and the number of people asking for your product internally, since fewer and fewer people will remember the benefit from their last gig.
I could be wrong here, only time will tell, but I honestly don't think this is a move that increases the long term sustainability of your business model. If anything, I think it's going to be detrimental in the long term. Perhaps even in the short term.
Nope, but I kinda thought the whole idea behind open source is that no one company or group of companies/licensees gets privileged access to or control over the software, including any company that happens to have the same name as the piece of software.
I realize that “open source” and “free software” and other related labels mean many things to many people, and some people have very strong opinions about what does and doesn’t qualify, so I’m not trying to be prescriptive about what these terms “really” mean, but to me this is a pretty important almost self-evident part of it. If you want to sell proprietary software just do that!
Certainly, there's things like the Linux Foundation that serve as places where projects can live without formal control by a single organization, but in practice, orgs that commit most of the code control things (for better or for worse - I'm not saying this is a good thing)
Well, yeah, that’s just the most obvious gut reaction everyone has when they first hear about open source software: Why in the world would anyone put work into software that’s free for everyone to use? My impression is that open source advocates have put tons of work into explaining why this can and does actually work and can result in software that’s better than proprietary alternatives.
That is not, at all, the idea behind open source. The idea behind open source is, basically, 'you are free to do whatever you like with the source code, as long as you credit us for our work and don't hold us responsible for any effects of using the work'. That's it. There is nothing about companies, corporations, licensees, who has control, who has what name, etc. All of that is irrelevant to open source at its core.
It's true that many people add on an open governance model (e.g. Rust) and mistakenly think that that is part of open source. It's not though.
That’s exactly what I said.
For other's who are interested, here's a faq from grafana including a discussion about "Why AGPL and not SSPL?": https://grafana.com/blog/2021/04/20/qa-with-our-ceo-on-relic...
As a commercial consumer of FOSS, AGPL has been troubling for me. As a non-commercial hacker, AGPL has been fine for me: GPL is fine here, and distribution as defined by SaaS or tarball is equivalent; I share back.
My opinions are that non-commercial FOSS projects probably shouldn't choose AGPL but that small-ish commercial FOSS projects (like Grafana, et al) probably should so that big commercial entities don't eat their lunch.
AGPL seemed like a tool that was mostly ahead of its time but is nice to have now.
https://public-001.gitsense.com/insights/github/repos?r=gith...
Switch to the impacts view and sort by "days active". I think it is safe to say, any developer with days active >= 25% is a grafana labs employee or somebody that really loves to contribute to grafana because they are being paid to.
Good riddance. Incumbents owned by corporations have too much control and prevent replacement projects from arising. When a community builds a solution, how it works is dictated by its users and developers, not profits.
However, the AGPL itself is quite clear that if you distribute a larger work based on an AGPL software, the whole larger work has to be distributed under the same license.
Would you still be confident shipping a proprietary product that includes a grafana dashboard ?
> Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate. https://www.gnu.org/licenses/agpl-3.0.en.html#section5
https://www.gnu.org/licenses/gpl-faq.html#MereAggregation
If you write a custom plugin for Grafana, then that plugin will likely need to be distributed under the AGPL (depending on Grafana's plugin architecture), but not your entire app.
I would be completely confident in bundling in this manner. The AGPL3 and GPL3 have identical wording on this matter, and it has been a well understood aspect of the GPL for decades.
> It’s important to note that this change does not prevent our users from using, modifying, or providing our open source software to others — provided, however, that under the AGPL license, users have to share source code if they are modifying it and making it available to others (either as a distribution or over a network). For distributors, AGPL has the same source code sharing requirements as GPL. Those conditions are designed to encourage third parties looking to modify the software to also contribute back to the project and the community.
The general sentiment was, "this license makes a useless curiosity".
I wonder where does this hostility come from. Jealosy? FUD? Frustration that they can't take the source and not share own improvements??
It wasn't that long ago that no large company would touch the GPL with a 10 foot pole.
No it does not. Using AGPL software does not suddenly make your own software a derived work.
"The GNU Affero General Public License is designed specifically to ensure that, in such cases, the modified source code becomes available to the community. It requires the operator of a network server to provide the source code of the modified version running there to the users of that server. Therefore, public use of a modified version, on a publicly accessible server, gives the public access to the source code of the modified version."
Here is the clause about modification:
"13. Remote Network Interaction; Use with the GNU General Public License.
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.
Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License."
One of the cool things about open source is that you can go and use Open Source code for things that the original author may have never even thought of. So your implementation of some novel algorithm might end up being useful in some situation that you were not aware of or maybe did not even exist when you wrote the code. While it seems idealistic, it is not that uncommon.
Now for the GPL license, depending on version, it is not a huge deal if you borrow GPL code. It is a fairly standard license that a lot of projects use. And of course GPL is compatible with a lot of different licenses, making it possible to distribute your projects under the terms of the GPL including code with compatible licensing.
Something interesting to note is that AGPLv1 is not GPL compatible. AGPLv3 is not GPLv2 compatible. GPLv3 and AGPLv3 are compatible, since GPLv3 was written to intentionally allow this usage. (Note: IANAL or an expert; so this should be taken with a grain of salt.)
In the end, this is why permissive licenses have gained a lot of popularity. It is immensely aggravating to people when things that are technically possible and not spiritually immoral are prevented by legal barriers that feel unnecessary. When the ZFS on Linux project faces trouble because of software licensing, it feels like a farce and a waste of time and resources.
Now imagine that the reasoning for the license choices being incompatible was not to protect user rights, and not simply a matter of differing policies between different organizations and their open source releases, but rather transparently a ploy to protect a profit model. This is where people's aggravation turns to anger, because it then feels like the open source label is being used to pull people in, then the more restrictive licenses are being used to seek rent forever after.
The reality is obviously not quite that grim. In fact, perhaps because of licenses like the Timescale license and SSPL, people have come around to AGPL in quite a significant way. The Overton window of open source licenses from corporate open source releases may have tilted a bit more towards the 'restrictive' side.
I don't think there's anything actually immoral about protecting one's own profit model. It does, at least in some sense, dilute what it means for software to be open source; if AGPL becomes popular, it will be more likely to encumber more projects with its requirements. Of course, in many cases, the ownership of the copyright will be spread among multiple parties, and so everyone is on a level playing field, and so other than the burden of ensuring you adhere to the restriction there's no real reason to feel that it is 'unfair' anymore than copyleft licenses already are.
At the end of the day, GPL was a legal solution to a community problem, and it imperfectly encodes an idea. There is no perfect encoding of that idea, so it is bound to cause some frustration for where the expectations mismatch with reality.
Anyone interpreting AGPL that way is being ridiculous, though. If you treat the software as fully open source then AGPL doesn't harm you and there is no rent seeking. Any paid licenses are only for companies that don't want to embrace that piece of software being open source.
All that said, the emotions felt here are not always rational. Sometimes things feel unfair or undesirable just because they’re different. I am not trying to cast my personal beliefs when I speak about discontent with AGPL because the truth is, I don’t have any. (Certainly not with AGPL specifically.)
I think perspective matters. The way I view my place in the world impacts how I see it. I tend to believe in mostly permissive licensing, especially for personal work. I believe this maximizes the utility of the work and the likelihood that someone may benefit from it. I have accepted the fact that they may benefit in ways that I don’t like. I have also accepted that some may not follow even the most basic terms of the license or copyright law itself; it’s not a huge deal. That’s not to say I would literally never pursue someone for violating my “IP” rights, though it is certainly a statement that for the most part, I don’t really intend to. If someone got maddeningly rich off of something I did for free, I lost nothing. Is it really much more unfair than writing a piece of code that is directly responsible for millions of dollars of profit, but only ever receiving an unremarkable salary? Clearly not. I got a dependable wage and did what I was paid to do. I didn’t have to do it. The entity could opt to show some appreciation by trying to reward employees for such things to encourage it and boost morale, but most people would agree that they’re not under any obligation to.
Not everyone feels this way. To some, they are invested in and concerned about the ways their code may be used. For some reason a growing set of expectations surround open source software in particular, perhaps simply because nobody gets paid to write it. This sometimes results in outbursts against overly entitled users who demand work out of open source authors. But the reverse situation gets far less attention: developers demanding that users follow additional unwritten rules. But I don’t think it’s rational. When Amazon announces an OpenJDK distribution, they’re the heroes. Why? Because fuck Oracle, that’s why. But when they announce forking ElasticSearch, they are panned for breaking open source. I know the “ASP problem” is real, hence AGPLs existence. However, there’s a difference from the pragmatic viewpoint (“we need to close this loophole to protect end user rights”) and the fairness viewpoint (“Big corps shouldn't take advantage of GPL code.” — would the same feeling be applied to a fellow startup?)
All this to say, I think if you want to understand the viewpoint of people who hate specific license decisions, you have to try to understand where they are coming from. It may not be totally rational, but it’s probably rooted in some defensible, understandable position. I think much distaste for AGPL over GPL is likely a little bit FUD and a little bit misunderstanding. But I do think people are coming around to AGPL. If anything, people’s awakened awareness of the fears of the “ASP provider” has done it some good. The reality is though, that people probably viewed it as being similar to what SSPL came to be; and SSPL, depending on where you are standing, could be a threat to open source (in a way that AGPL is not.)
Edited:
Oh, I can't say this... I leave it up for posterity and a note to myself then.
I prefer to keep all my code as much as possible mit and I share them on Github. This is my mode of operation.
Grafana makes me unable to use MIT for that use.
Huh? Grafana isn't your code, it's someone else's code that you'd be using. Unless I misinterpreted, and you are a Grafana contributor. If you are, you could dual license your contributions under AGPL and MIT, if you wanted.
This is a stated purpose of GPL3 / AGPL3. I am happy to be told I am wrong and it is possible.
If your software is in effect an extension of Grafana, you will need to release source code under AGPLv3.
Edited: Or pick a fork and live on it forever.
Edited: Or write my own Grafana
If you are, then your obligation would change to specifically making only that work which builds on top of the Grafana code available to others for free, along with the AGPL3-licensed Grafana code. You are not required to license that code that you wrote in any way, with the caveat that others may freely use it.
In effect, it becomes a weak copyleft- akin to MPL-2.0 where as long as you keep it in separate files code can stay closed-source.
" Why didn’t Confluent use AGPL? AGPL doesn’t solve the problem we are trying to fix. AGPL allows cloud service providers to sell services using the exact software being licensed, and charge for it, without any limitation. This means the software developer has become the unpaid developer and maintainer for the cloud service provider—which is not a scenario we want to enable.
Also, AGPL is too aggressive for our customers who need to redistribute commercial products. If you put AGPL code in a distributed program, you have to open source the whole program. We want you to be able to embed our code in proprietary applications, change it and not worry about open sourcing any of your changes. We don’t think that proprietary applications are bad, and we think it’s great if you use Confluent Community software to create them.:"
1. The big players like Amazon make custom, proprietary modifications to the software they're hosting, and since they're not technically distributing it, they don't have to release the changes, giving them an unfair advantage. This is the exact loophole that the AGPL closes.
2. Sometimes, the big players are just better/more efficient at hosting the exact same software the exact same way. There's nothing unfair or unethical about this; it's how the free market is meant to work that customers flock to them.
Confluent is trying to "fix" the second "problem", which rather than making anything more fair, just makes it unfair in their favor.
Does anyone know how difficult it would be to have the login page for a web app be a different license? The idea being that the only users of the AGPL code are ones that have a valid account. Off the top of my head a reverse proxy, with a completely separate auth app would do the trick, but would be a bit of a pain.
This is...already the case. The distributor is the one who is bound to supply the source code--"upstream" isn't implicated in the license.
https://opensource.stackexchange.com/questions/650/do-i-have...
On a more serious note: there is a bit of a trend in the licensing world. Mongo or ElasticSearch changes, or cool new projects like redpanda [2] launching with BSL.
Open source is still a very young business model. One that has provided a tremendous amount of value over the past decades, but we still need to figure out how to build sustainable businesses with it. Be it open core, more restrictive licenses, copyleft, dual licensing, ...
I just really hope that we don't slide back into the world of proprietary closed source. The danger is certainly there, and it will hit smaller companies the most.
> If you make the functionality of the Program or a modified version available to third parties as a service, you must make the Service Source Code available via network download to everyone at no charge, under the terms of this License.
> “Service Source Code” means the Corresponding Source for the Program or the modified version, and the Corresponding Source for all programs that you use to make the Program or modified version available as a service, including, without limitation, management software, user interfaces, application program interfaces, automation software, monitoring software, backup software, storage software and hosting software, all such that a user could run an instance of the service using the Service Source Code you make available.
Source: https://www.mongodb.com/licensing/server-side-public-license
I can think of a hundred questions based on that text. If I use S3 to store data for my Mongo SaaS, do I need to call Bezos and buy the complete source code of S3?
Yes.
The SSPL and other source available licenses on the other hand basically just take away the ability to make a meaningful fork, making the project proprietary. Sure it makes business sense, but someone might still feel the need to make an FOSS alternative.
Various business models can be built around it. A license that restricts closed-source cloud use, like AGPL, still preserves the openness at least. It can be combined with a dual commercial license.
The problem for Amazon was strictly due to SSPL, not copyleft licenses in general.
[1]: https://www.reddit.com/r/cscareerquestions/comments/3axbeh/i...
I bet it wouldn't be open source otherwise.
Also, it's a more convenient and secure shell around kvm. It's valuable, but bit that meaningful.
Licencing your code under AAGPL extinguishes your own copyright as the author -- you now only have the same rights as someone triggering the code or a derived work. Triggering is any action which causes the code to run without human intervention.
The AAGPL will finally remove the possibility of crippled 'Community Edition' software.
I don't want to host Elasticsearch myself, which is why I pay Elastic to host several clusters. That said, I really don't want to be locked into a single-vendor situation, which is what Elastic is realistically aiming for. I am 100% glad that Amazon forked ES, because it preserves the benefits of using an open source stack. I still have a choice of hosted providers. In my opinion, the amazon fork is much more likely to lead to a healthy ecosystem of hosted ES providers than the Elasticsearch version.
The GPL (without A) requires you to publish sources under compatible license (usually also GPL) if you use a software and distribute it (to clients for example).
Git is GPL. Github however can totally run modified versions of git on their servers to build their service, and doesn't necessarily have to contribute back, since they never distribute their programs to the customer, but only some html.
The AGPL goes one step further and requires any changes that github makes in that situation to also be licensed under AGPL. That way it is like GPL, but for software that is typically run on servers, not on client hardware.
Open source is about an open community, open contributions, the multiplier you get from contributions from multiple companies. That way open source is a win-win. Companies benefit from each other's contributions.
Once you have free and non-free tiers or need restrictive licensing it is already broken. The incentives no longer align.
I'm being paid in part to work on the open source projects that we utilize for our service(s). Some of those we started, some of those we're contributing to, but we _own_ none of them. We handed them off to external entities (Apache and others) for governance and we actively encourage others to participate. And, yes, some of those are used by Amazon, and we welcome their contributions to the code.
Single support companies that use the popularity and reach of permissive licenses for profit that then turn around and bemoan the fact that their licenses are too permissive are disingenuous.
Using open source libraries is, among other things, a cost saving measure. It allows a company to focus their expertise on what they are good at, without having to spend time and resources on reinventing wheels. Banning tools that enable a company to produce products faster, cheaper and (sometimes) more stable and secure can have a major impact when the competition does not limit themselves in the same way. However if the market is dominated by a monopoly or is very slow, then increased costs and delays might not have much of an impact.
As an example of such company, Google's revenue would not be impacted by a single percent if they suddenly needed to hire 200 more programmers for android. Delay next version with 2 months and the impact for android market share would unlikely be statistically verifiable.
Maybe what we need is a 'no AWS' license, think Apache License but with a clause that says no corporation with more than $50B in revenue can resell it.
It'd be really hard to come up with a license less lenient than AGPL without it being non-FOSS, which would defeat the purpose.
> Maybe what we need is a 'no AWS' license, think Apache License but with a clause that says no corporation with more than $50B in revenue can resell it.
This would be a blatant violation of freedom 0.
Would you prefer that people/companies that fall into these categories be forced to go through some _other_ reseller (who is just adding their own markup on top of the cloud hosting costs) instead of getting the service directly from their cloud provider of choice?
^^ this is not a good contribution to HN, not much substance. (edit)
Many people who use Grafana will see this news and will stop planning on using Grafana and start planning on doing something else. That has nothing to do with Grafana, that is a common reaction to AGPL.
In theory, AGPL is fine under circumstances blahblahblah. In common practice in commercial settings (in my experience), GPL is poison and AGPL is radioactive poison.
If, however, they _were_ making money off of proprietary modifications, and they wanted to keep such modifications proprietary, they now have the choice to fork Grafana (and Loki and Tempo respectively) as of a pre-AGPL version.
Seems like it will be better solution then MPL.
> If Amazon/AWS was not a large monopoly it wouldn't be a problem.
DOJ Needs to split up AWS/Amazon and fine them and use that fine to create competition.
My gut feeling is that those passionate about open source on the whole will tend to prefer AGPLv3, while businesses or those making decisions on the behalf of a business, may prefer BUSL-1.1. I think there are trade offs with either approach.
The problem with the AGPL is it's very unclear what counts as linking, and this has never been tested in court, and that it's not clear what "network access" needs to look like.
Your gut is onto something. People who care about something bigger than themselves prefer AGPL, while those who only care about their own profits prefer BUSL.