121–130 of 578 posts
However, the AGPL itself is quite clear that if you distribute a larger work based on an AGPL software, the whole larger work has to be distributed under the same license.
Would you still be confident shipping a proprietary product that includes a grafana dashboard ?
Okay, so they go out of their way to avoid answering how this actually affects people, so I'll ask here: If a company uses grafana internally, this should have no effect, right? And then the next step: If a company did offer grafana-based dashboards to customers but wasn't actually modifying grafana, what if anything does this do?
They do say it: > It’s important to note that this change does not prevent our users from using, modifying, or providing our open source software to others — provided, however, that under the AGPL license, users have to share source code if they are modifying it and making it available to others (either as a distribution or over a network). For distributors, AGPL has the same source code sharing requirements as GPL.…
Earlier quoted context omitted.
This seems to lump relicensing to better FOSS licenses like AGPL in with relicensing to bad non-FOSS licenses like the Commons Clause, SSPL, BSL, Redis Source Available License, and Anti-996 License. You're right about the former, but the latter is screwing over the community.
Serious question: How is the community impacted by SSPl, BSL, etc? The average end-user who makes no modifications and is not reselling as-a-service is fine, there is no additional burden with either AGPL or the non-OSI-compliant licenses. How does the AGPL screw over the community less than the other licenses? AGPL is problematic for a slew of reasons, lots of corporations (whether or not you agree that for-profit e…
The OSI or FSF-approved licenses form an ecosystem. I can have a project which mixes AGPL, GPL, and BSD code. I can make that part of the next version of Ubuntu. I can borrow bits of code. It all works together. If the goal is to have a computer running free software, AGPL builds towards that goal. If the goal is to use the code in new and unexpected ways, AGPL builds there.
The non-OSI licenses are walled gardens. Even the ones which nominally allow remixing require me to drop a few grand on a lawyer before remixing them (more grand if it's international).
AGPL is toxic to some corporations for mixing into their proprietary projects, but the commercial dual-license takes care of that. Most corporations don't mind spending money.
AGPL also gives a long-term sustainable pathway if the original vendor goes under or goes evil.
I remember when the AGPL was being talked about in around 2008 or so, and thinking it was ludicrous. Now I wonder if it's too lenient. AWS is just rebranding open source products and selling access for infinite markups while killing the open economy that created them. Maybe what we need is a 'no AWS' license, think Apache License but with a clause that says no corporation with more than $50B in revenue can resell it.
It'd be really hard to come up with a license less lenient than AGPL without it being non-FOSS, which would defeat the purpose.
> Maybe what we need is a 'no AWS' license, think Apache License but with a clause that says no corporation with more than $50B in revenue can resell it.
This would be a blatant violation of freedom 0.
Earlier quoted context omitted.
> Hopefully over time rather than having everyone choose their own licenses we end up with some form of standardisation. Yes; if you're going to do this, then using AGPL is so much better than flavor-of-the-week license. > If the core companies maintaining them did not do this they would eventually die and these projects would slowly rot. It sounds like you're suggesting that anything but hard-copyleft is doomed to d…
Problem: the letters "G, P, L" are toxic to a huge number of companies. This has nothing to do with the controversy around Stallman. It's because Microsoft spent over a billion dollars in the 1990s mis-educating the market that GPL software is "viral" and if present can "infect" non-GPL software with the GPL license. The problem would go away if you renamed the license to something else. It's that stupid. A lot of th…
I'm interested in what the 'weak corner cases' of AGPL are considering it was pretty much made to correct some weaknesses in the GPL.
Earlier quoted context omitted.
AGPL is a license qualifying the criteria of OSI's OpenSource definition and FSF's Free Software definition. A key point there is that a user can use the software quite freely without restrictions only with the caveat that modifications have to be made available to users. (AGPL is slighqtly more complex) Many of the "modern" licenses allow to look at code, but prevent distribution and/or modification and/or usage. Th…
I don't value OSI's stamp of approval since they were explicitly founded to coopt FSF's effort and make it more corporate friendly. Obviously corporate lawyers would disagree with me. A license that allows all typical freedoms except "use the software to start a SaaS using proprietary infrastructure" is fine by me.
Earlier quoted context omitted.
(Timescale founder) We actually designed the Timescale License to be _less_ restrictive than AGPL. It contains no virality. It just prevents public clouds from offering TimescaleDB-aaS.
The freedom to run the software for any purpose is #1 on the list of software freedoms that would be called open source. No ifs, no buts, no checking whether you qualify - software is free if and only if you can run it for any purpose, everything else comes only after that basic freedom. Various viral conditions only affect the licensing of developer changes (while still not restricting the developers right to make a…
The sentence you quote is actually meant to -technically- establish a basis for what it means for somebody to run/offer TimescaleDB as part of a value added service (very much allowed) versus a company like AWS offering TimescaleDB purely as a DBaaS offering (not allowed).
There are many, many thousands of companies that use or embed TimescaleDB as part of their service or product offerings, serving huge numbers of customers. We're extremely supportive of their ability to do so. We have no "enterprise features" that are excluded or held back only to paid users.
What we aren't supportive of is AWS running "TimescaleDB-as-a-Service" as part of AWS RDS. Because we know they do that!
The clause you are quoting helps define some of the legal nuances how we get there, ideally in ways that an engineer would understand. In particular, what it means to be a value added service/product versus just "TimescaleDB-as-a-Service".
The alternative legal formulations of this can be found in, e.g.
- Confluent Community License ("Licensee is not granted the right to, and Licensee shall not, exercise the License for an Excluded Purpose. For purposes of this Agreement, “Excluded Purpose” means making available any software-as-a-service, platform-as-a-service, infrastructure-as-a-service or other similar online service that competes with Confluent products or services that provide the Software.")
- Polyform "Shield" License ("Any purpose is a permitted purpose, except for providing any product that competes with the software or any product the licensor or any of its affiliates provides using the software.") https://polyformproject.org/licenses/shield/1.0.0/
These are all getting to similar places, but just putting more emphasis of the legal definition of "competition", which we thought would frustrate engineers with its vagueness.
I don't want to weigh in here with a huge value judgement on whether this is the right decision. However, I do want to say that what they're saying regarding SSPL vs AGPL is totally right. One of the biggest sticking points with SSPL is that it's not even really plausibly open source, and it tries to create restrictions that implicate software that is not even "linked" with the program that is licensed under it, whic…
(Timescale founder) We actually designed the Timescale License to be _less_ restrictive than AGPL. It contains no virality. It just prevents public clouds from offering TimescaleDB-aaS.
Why not toss in an AGPL license option? You wouldn't be discounted off-the-bat by folks like me. I build open source. Timescale is not open source. Timescale won't mix with GPL code. I use plenty of GPL code. GPL/AGPL are known quantities. Your license requires legal review.
As a footnote, I do pay for hosted versions of most of the databases I use.
All of the most important software of our lifetime is going through this relicensing effort as the creators attempt to capture the value of what it enables. This is not some nefarious plan to screw over the community. It's a very measured and thoughtful way to ensure the long term progress and continuity of these projects. If the core companies maintaining them did not do this they would eventually die and these proj…
Ahem: Grafana Labs Brings In $50M Series B For Open-Source Developer Platform: https://news.crunchbase.com/news/grafana-labs-brings-in-50m-...
I completely support the right to chose your own license and how you want to sell and use your own code, but let's be honest here. This is done because investors have discovered that it's possible to earn money on services around Open Source products, and Grafana Labs has gone all-in on this approach. Now they need the relicensing in order for the business model to remain viable. We're lucky that the code remains AGPL, but notice that they are still not committed to ensuring that all the code will remain AGPL (i.e. they still want CLA so they can relicense later).