I think that's misunderstanding of AGPL. For internal use, AGPL does not require to share the proprietary part.
If a company develop an proprietary UI and use Loki as backend, this is not serving Loki directly to customer, so that does not require company to release their code.
It is similar to GPL. Dynamic linking to a GPL software does not require the developer releasing their code.
Only provider serving Loki instance directly to customer required to share the code.
Only Amazon is upset that they cannot just host a popular open source project directly on their cloud. Maybe they could pay a license fee for dual licensing arrangement, which is a better way to support open source startup.
I think this is a misunderstanding of how vague the AGPL actually is.
The key clause is "your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version."
Would putting AGPL software behind a reverse proxy change the fact that you're a user interacting with it remotely? What about a reverse proxy that changes/adds some headers? What about a really smart reverse proxy that reformats some of the output or repackages it or mixes it with things from other data sources? Is that materially different from the API that powers the "proprietary UI" you're describing?
And say you're pretty confident that you're on the right side of things. Can you point to any case law where courts have established precedent about what "interacting with it remotely" means in this context? No? Then to be on the safe side, you'll probably need to maintain a source code repository for your Corresponding Source, remember to update it every time you update a minor version of the service internally, and maintain an info screen in your product with "prominent" links to that source code repository, which likely means it needs sign off from a product team if not a legal team as well. All things that add expense and barriers to entry.
I think the AGPL is great for services like Grafana's UI itself, where there's likely to be a "human gap" between the software and anyone outside your organization. But things like Loki that are designed to power other proprietary systems that may well be touched by end users through a computer network, where Loki's output may have influence or side effects on the output the user sees? I don't think it's nearly as clear what liability that entails.
(Obligatory: Not a lawyer, the above is not legal advice.)
Most companies who use Grafana or Loki as part of some deployment would use an unmodified version, so the only AGPL specific clause, which you cite, would not apply and is irrelevant.
This kind of hand-wringing is what the naysayers were doing with GPL software in the 90s. That the GPL would never fly in business because lawyers would get hung up in "what if" interpretations that were never the intent or spirit of the GPL in the first place.
Not really. GPLv2 had more sensible legal language, even if that turned out to burn FSF intentions at times, but over time lawyers started digging in more into "derivative software" clause. Also a lot of the naysayers were fueled by RMS himself doing whack a mole by forcing projects to adopt GPL in not nice manner (and I'm not talking about them using something big or critical from GPL project).
TL;DR FSF is heavily responsible for the "GPL is viral" message sticking.
Sure! Saying that the parent’s “develop an proprietary UI and use Loki as backend” is a slippery slope to “user sees data that incorporates data served from Loki” which I am arguing could be interpreted as data that would require the developer to maintain a source repository for Loki under the AGPL.
I see now and yes the AGPL seems vague in that regard.
If it's anything like dynamic linking and GPL that could be considered okay even if it's not the intention of the licensee. Seems like the license should be more explicit about what "interacting with" entails.
Not everyone agrees on this point [1]. One relevant quote: "This is ultimately a question not of the GPL per se, but of how copyright law defines derivative works."
Whether or not dynamic linking constitutes a "derived" work is still an open question, legally speaking. Obviously the FSF has their own thoughts on this, but it's unclear how an actual court would rule.
That may be true, but a state of ambiguity is as good as saying its covered by GPL ... no organisation is going to look at that and say "that's fine, let's use it".
In fact, state of ambiguity is the worst for everyone because neither will users be able assume they can exercise their free software rights. So everyone loses.
The difference between the AGPL and traditional GPL is simple: The AGPL seeks to close a "loophole" that allows a company or organization to modify GPL'ed software and use it to provide a service — but without actually distributing changes. So a company can take a package like, say, WordPress and modify the software significantly to sell a service — but hold back changes because it's not technically "distributing" or "propagating" the software. The AGPL goes a bit further and says that if the program is "intended to interact with users through a computer network" and if the version that you received gives users "the opportunity to request transmission to that user of the Program's complete source code," you have to maintain that functionality and distribute the modified version.
1. the software is conveyed in a "User Product", and
2. that conveyance occurs as part of a transaction in which the right of possession and use of that product is transferred to the recipient.
A "User Product" is defined as 'either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling'.
In other words, it only covers software that is installed on actual physical hardware when that hardware is sold (or rented, etc) to the consumer.
For a sale of a service, it is completely out of scope.
This is probably the most misunderstood clause in GPLv3, with people thinking that it some sort of general anti-DRM clause. Almost everybody, for example, thinks that it is why you can't have GPLv3 code on the Apple app store, but because it only applies to conveyances that are part of the transaction by which you acquire your iPhone or iPad it in fact does not apply to software purchased later from the app store. Apple's app store DRM is perfectly compatible with GPLv3.
The incompatibility between the app store and GPL is that the license agreement for the app store says you won't redistribute the app or reverse engineer it. GPL does not allow adding additional license restrictions like that, and so you can't satisfy both the app store license and GPL.
This might be the case. However there is an additional risk and process component:
- you might not want to risk because you don't have lawyers etc in your company.
- even if you have lawyers etc in your company, if there are 2 alternatives one which is just an MIT license, you'll probably go for that one because you don't want to have a 1.5 month review of the use of this AGPL licensed alternative.
In general things like this https://github.com/xdspacelab/openvslam/wiki/Termination-of-... (repo with 3k stars), an effort terminated because of some traces of GPL code MIGHT be somewhere in there comes to light. Even though Grafana etc are mostly tools, for my startup I would probably not risk any of this (for my own sake and also for any kind of due diligence in case it ever gets acquired)
did not follow the events of openvslam, wouldn't they be required to still release the source code of the previously public version as GPL? also once the doubt is there, why not rerelease as GPL?
How does this actually work towards your employees or 3rd party personnel (for example consultants) getting access to the tools - would you have to make the source code available for them and allow them to distribute the code?
But think about it. Anyone that use AGPLv3 software can demand the AGPLv3 license, including employees and contractors. Once they got it, they can freely publish it to the public because it's AGPLv3. Forcing NDA to not leak it to the public doesn't work here because it violate AGPLv3 license thus copyright infringement.
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.