I could image that its the same with other corporations. In the end that might hurt the popularity of Grafana quite a lot.
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!
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)
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.
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.