How is observatorium an Apache license?

[kant777]

How is observatorium an Apache license when loki is AGPL? I see there is a plan to use tempo for tracing which is yet another AGPL license so I wonder how obervatorium can release it as part of Apache 2.0? is observatorium using a fork of loki if so what about the crucial fixes that went in recently such as out of order writes?

[periklis]

@kant777 As usually history happens before anything else. We are using Loki since 2.0 and currently it is pinned on 2.2.1. Back then it used to be Apache2

[bwplotka]

IANAL, but:

“The GNU Affero General Public License [...] 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.”

The only Loki pieces are touched with the following touchpoints:

• Observatorium packages Loki. I don't think this is impacted by AGPL. If someone makes Loki or Grafana Helm package, it does not make Helm AGPL, does it?
• Loki traffic goes through Observatorium API, but API has no knowledge if it's Loki OR anything else as long as it uses common API. Similarly, if someone deploys Loki behind proprietary AWS Loadbalancer, AWS does not need to make this LB code AGPL now.

If we fork Loki it is on public repos with AGPL. (Sometimes Red Hat builds projects in more secure docker images). But you can use Observatorium with any latest Loki version.

So I think we are fine with Apache2, but let us know if we missed anything (:

Hope that helps!

[kant777]

using 2.2.1 is perfectly fine, but how about the important changes that went in after 2.2.1? Especially this one grafana/loki#1544 ? without this change it is hard to use Loki and I expect changes like this will come moving forward so not sure if observatorium has a plan to implement them on its own or use something else?

Below are the concerns to the above questions

Observatorium packages Loki. I don't think this is impacted by AGPL. If someone makes Loki or Grafana Helm package, it does not make Helm AGPL, does it?

Agreed, But don't think that makes any difference since the underneath packages are AGPL. for example, here is what I ran into when I have to deploy my app on GCP 2 years ago. GCP folks had asked me to proved a list of all the libraries(including all transitive dependencies) along with their licenses used by my app, so I had done that and they came back saying they want me to replace all AGPL packages with something else for me to be able deploy. In fact, here is their policy https://opensource.google/docs/using/agpl-policy/ deploy.

Finally, Even though I am not a licensing expert, these days, I see most folks trying to stay away from AGPL for whatever reason.

[periklis]

using 2.2.1 is perfectly fine, but how about the important changes that went in after 2.2.1? Especially this one grafana/loki#1544 ? without this change it is hard to use Loki and I expect changes like this will come moving forward so not sure if observatorium has a plan to implement them on its own or use something else?

We are certainly going to update the used Loki image from 2.2.1 to 2.4.1 soon. The license change is not affecting us. The AGPL network effect is an extra security measurement for open source software that is used only as a service and they include custom patches. In this case you need to opensource your custom Loki and its patches. The network effect of AGPL is the balancing act to preserve access to these patches even if you do not redistribute the software and its patches.

Below are the concerns to the above questions

Observatorium packages Loki. I don't think this is impacted by AGPL. If someone makes Loki or Grafana Helm package, it does not make Helm AGPL, does it?

Agreed, But don't think that makes any difference since the underneath packages are AGPL. for example, here is what I ran into when I have to deploy my app on GCP 2 years ago. GCP folks had asked me to proved a list of all the libraries(including all transitive dependencies) along with their licenses used by my app, so I had done that and they came back saying they want me to replace all AGPL packages with something else for me to be able deploy. In fact, here is their policy https://opensource.google/docs/using/agpl-policy/ deploy.

Finally, Even though I am not a licensing expert, these days, I see most folks trying to stay away from AGPL for whatever reason.

Of course it makes a big difference. Helm or Observatorium's JSONnet is not using any AGPL-licensed source code to execute the k8s manifest generation and apply. The APGL source code is compiled as a binary only part of the official Loki container image. Because you reference the container image from a registry does not apply the network effect on packaging projects like Helm or Observatorium.

In fact the observatorium loki package is self-made JSONNet code without even referencing the official Loki production JSONNet package (https://github.com/grafana/loki/tree/main/production). Btw the official Loki production JSONNet code continues to be licensed as Apache2, because for good reasons Grafana Labs wants and should keep their SAAS production manifests closed source.

Google's policy is widely known and IMHO totally misunderstood. IMHO it applies on Google products and for Googlers. Notwithstanding their is a lot of parrot-play that in general Google disallows AGPL.

[kant777]

"Because you reference the container image from a registry does not apply the network effect on packaging projects like Helm or Observatorium" I hope this is the case but somehow this message is not coming across well with AGPL and there is all sorts of interpretations even if I assume this is true.

[periklis]

@kant777 What counts at the end of the day are facts and not interpretations. We certainly understand that Grafana Labs's AGPL switch makes our PR work a bit harder, but at the end of the day protecting open source requires sometimes under special conditions hard measures.