351–360 of 578 posts
Earlier quoted context omitted.
Without knowing what they work on, one obvious case is code that interacts with grafana; extensions, plugins, whatever. For that matter, it's perfectly possible to maintain your own personal patchsets without being a "contributor" per se. Niche, but plausible.
Plugins don't seem to have been relicensed looking at https://github.com/grafana/grafana/blob/HEAD/LICENSING.md
Earlier quoted context omitted.
Consider "Service as a Software Substitute": https://www.gnu.org/philosophy/who-does-that-server-really-s... Do you consider it a problem? If not, why not? If so, what other than the AGPL do you propose to fix it?
No, I don't consider it a problem at all. Nothing is being used improperly or against the spirit of free software when software freedom is exercised (by a service provider) - that's the whole point. 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 pe…
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.
Earlier quoted context omitted.
Consider "Service as a Software Substitute": https://www.gnu.org/philosophy/who-does-that-server-really-s... Do you consider it a problem? If not, why not? If so, what other than the AGPL do you propose to fix it?
No, I don't consider it a problem at all. Nothing is being used improperly or against the spirit of free software when software freedom is exercised (by a service provider) - that's the whole point. 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 pe…
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".
I applaud this decision. 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.
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…
B) Nope
Earlier quoted context omitted.
> a company like AWS offering TimescaleDB purely as a DBaaS offering (not allowed). 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.
And we never call it Open Source! (Timescale engineer here)
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.
Grafana: The analytics platform for all your metrics. Allows you to query, visualize, alert on and understand your metrics no matter where they are stored. Create, explore, and share dashboards with your team and foster a data driven culture. 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…
Earlier quoted context omitted.
I agree. 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 ecosyst…
thanks for saying the AGPL is nice; we think it strikes the right balance. 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]
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.
Earlier quoted context omitted.
They have to be shared to the user under the same license. So any user could publish the changes publicly.
Sure, but there might be out-of-band reasons for users to not do that. 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.
Earlier quoted context omitted.
> Freedom includes freedom to have privacy. 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 wh…
Yeah, and running a business on my own computer by providing API services to someone is not distribution of software. Running an API business shouldn't force me to distribute anything to anyone.
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?
Earlier quoted context omitted.
How is it debated whether AGPL is open source? Who says it isn't?
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=495721 might be good background reading
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.