Live data from Hacker News

Grafana, Loki, and Tempo will be relicensed to AGPLv3

grafana.com

421–430 of 578 posts

Re: Grafana, Loki, and Tempo will be relicensed to AGPLv3

#421

The funny thing to me, which I haven't seen anyone else mention yet, is that way, way back in the old days, Grafana started out as a fork of Kibana. Go take a look at the first commit in the Grafana source: https://github.com/grafana/grafana/commit/75d03fc49ab4f95ee4... Anyone want to guess what the third commit was? That's right, it was an Apache 2 license: https://github.com/grafana/grafana/commits/master?after=2bb…

i wonder how much of that original Kibana code remains today (my guess is not very much), and if it were originally AGPL, would a completely rewritten codebase still be subject to it?

Re: Grafana, Loki, and Tempo will be relicensed to AGPLv3

#422
post #158

What I don't like about changes like this is that it makes it impossible to reuse any Grafana/Loki/Tempo pieces or libraries in any more permissively-licensed code without forcing that whole project into the AGPL as well. That doesn't only hinder competitors (which seems to be the legitimate goal), but also hinders interoperability and an open ecosystem evolving where people freely exchange bits and pieces of code to…

IMO, the ideal end-state from a software freedom perspective is that all software becomes AGPL. This change is a step in that direction, not only with the directly affected products, but for the reasons you mentioned, an additional pressure for more things to switch to it. Do you not like that end goal, or do you just think the side effects of the change outweigh the benefits of getting closer to it?

Wasn't the end goal of copyleft that all software becomes GPL 3 a few years ago? When will this stop? Why does 'freedom' in the Gnu sense require coercing all developers to use the same license?

Re: Grafana, Loki, and Tempo will be relicensed to AGPLv3

#423
post #404

Earlier quoted context omitted.

How do you figure? 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, jus…

anyone can change the license of apache software, without any permission. the right to do so is built into the apache license.

[deleted]

Re: Grafana, Loki, and Tempo will be relicensed to AGPLv3

#424
post #419

Earlier quoted context omitted.

The whole issue arose from the claim that the Timescale license was designed to be less restrictive then the AGPL. That's why Open Source came up in the first place - pointing out that one of the basic reasons for the Timescale license to exist in the first place is to restrict one of the major reasons Open Source licenses exist.

That only makes sense if you agree with the open source foundation definition of restrictive. I don't. I think the ability to freely link to whatever other software is much more important to most people than the ability to run a *aaS. We never made any claims about open source only our opinion about what restrictive means to us.

That's fine. I wasn't taking a position. I was explaining why people were using Open Source as a comparison.

There were also no claims about whatever definition of restrictive you were using. It was just a short statement that the Timescale license was designed to be less restrictive than the AGPL. You can't really be that surprised when somebody comes along and starts judging it by Open Source standards after that, can you?

Re: Grafana, Loki, and Tempo will be relicensed to AGPLv3

#425
post #416

Earlier quoted context omitted.

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

I don't understand the distinction you're drawing. It sounds like you're saying that "cannot be combined with code under a different license" is meaningfully different from "can be combined with code under a different license, so long as you immediately relicense that code so it's not under a different license anymore". What am I missing?

Because you're misreading it. It doesn't say you have to relicense the code. It just says (A)GPL terms have to apply to both parts of the code. That's not relicensing. You don't need anyone's permission for weakly-licensed code to do that. Weakly-licensed code already allows it, that's why it's a weak license.

Weakly-licensed code also allows to be covered by a proprietary license. Nobody needs to relicense weakly-licensed code to lock it up in any way and apply further restrictions to it, whether they be "good" restrictions like the (A)GPL, where you forbid further restrictions, or "bad" restrictions like a EULA, where you forbid people to look at your modifications or to do further modifications.

Re: Grafana, Loki, and Tempo will be relicensed to AGPLv3

#426
post #393

Earlier quoted context omitted.

I have a question regarding AGPL, that I couldn't answer by Googling or reading the license. Let's say that Postgres server is licensed under AGPL, and I modify it to my needs. I have a closed source web application, that is publicly accessible, and uses Postgres for storing data. a) Do I need to publish source code of my version of Postgres? b) Does my application (which relies on Postgres, and my patches) need to a…

I'm going to split hairs the other answers don't: you specify you have modified Postgres. My answer is, it entirely depends if your application is considered a "derivative work" of Postgres. This hinges on a couple of things: - does your application directly include AGPL postgres code in any form (headers, binary, etc etc) to its own source or its own runtime process? - keep in mind, in answering the above, that your…

Doesn't it also depend to some degree on how much code sits between the user and AGPL code?

IIRC AGPL was created to bypass a thin wrapper frontend type situation. I make a website that takes PDFs, it lets users extract pages. In the backend I'm just running a modified Ghostscript command line and sending back what it makes. From my discussions with other people, this type of direct coupling automation is what is intended to trigger the AGPL. Is this incorrect? If that doesn't trigger it, the 'users interacting with it remotely' clause is all but useless because firewalls and service chains like this are really easy to construct. Not all AGPL software is able to natively run as a server itself.

And if it does trigger it, a simple ToDo CRUD app that relies on a database is pretty much the same thing in my eyes.

Re: Grafana, Loki, and Tempo will be relicensed to AGPLv3

#427
post #246

Earlier quoted context omitted.

The same reason some people dislike the GPL, but a bit more extreme. 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,…

> 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 m…

AGPL isn’t this, of course. Though for a project that enforces copyright re-assignment and thus retains copyright, you certainly could use AGPL as a similar sort of deterrent, because end users and even contributors are beholden to different rules than the copyright owners. But this is not really any different with GPL versus AGPL, and it’s been a well-accepted practice to do things like dual-license FOSS projects as commercial products. I believe even Richard Stallman believed this to be an acceptable practice. Nonetheless, if people want the same rights as the copyright holders, they need to pay rent, unlike a communally owned project. Again, this is not the fault of AGPL, it’s the status quo for a lot of open source; but the way AGPL’s copyleft extends things represents a change to what implications people are used to and widens the gap.

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

Re: Grafana, Loki, and Tempo will be relicensed to AGPLv3

#428

Earlier quoted context omitted.

"Companies are right to avoid the AGPL" This was never an issue until Google was pinched on it five or six years ago and started a massive campaign to get the OSS movement to disfavor the AGPL. Google uses tons of GPL software that they don't pay for (Linux, Java, etc.) but once it became exterior-facing and the license applied to their software, then rather than pay to license the software, the world's fifth most va…

I understand your concern. After Google started the negative press about AGPL, some companies I worked also followed suit. It felt like blind following, as almost none of my software faces the public -- it's mostly internal. In that case, AGPL is no concern. But internal training made a big point about "avoid AGPL... even Google avoids it!" Truly, it was F.U.D. nonsense. You also wrote: > While that statement may be…

I don't know, but I expect that Google uses the OpenJDK release, which is identical to the Oracle JDK except it does not receive paid support from Oracle. I strongly doubt Google which has been fighting Oracle for years about a Java license would be paying Oracle for support. But stranger things have been known to happen!

Re: Grafana, Loki, and Tempo will be relicensed to AGPLv3

#429

The funny thing to me, which I haven't seen anyone else mention yet, is that way, way back in the old days, Grafana started out as a fork of Kibana. Go take a look at the first commit in the Grafana source: https://github.com/grafana/grafana/commit/75d03fc49ab4f95ee4... Anyone want to guess what the third commit was? That's right, it was an Apache 2 license: https://github.com/grafana/grafana/commits/master?after=2bb…

[deleted]

Re: Grafana, Loki, and Tempo will be relicensed to AGPLv3

#430
post #183

Earlier quoted context omitted.

I think it's both a completely unrealistic end goal (we live in the real world), and I also think that the AGPL puts you into a hole where you can never get out of again if you decided that you now need different constraints. So I really much more prefer permissive licenses. Funnily just before you wrote this comment, I also tweeted just that :) : https://twitter.com/juliusvolz/status/1384599249082626052

It seems you can always just run the AGPL licensed software and as long as you interact with it through the network or the database you won't have to relicense anything. 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 f…

No, it is the network interaction that is specifically a software release trigger. "Interact" is a term encompassing a broad scope of behaviour -- any network message that causes an API to be called.

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.

Post reply on HN