Grafana, Loki, and Tempo will be relicensed to AGPLv3

Laws exist ideally to limit freedoms whose exercise comes with externalities that end up reducing the freedom for others. These range from freedoms to cause harm to others (steal, assault, enslave), to freedoms to sell food without disclosing ingredients, to freedoms to run a business without transparently reporting financial information. The idea of greater freedoms depending on lesser restrictions is not novel.

> Lack of competition is what lets developer's exert power over users, and while copyleft licenses help with that, they're neither required nor sufficient to prevent abuse of power.

Copyleft/FLOSS alone is a necessary but insufficient measure; I wrote about other measures in a blog post [0].

[0]: https://seirdy.one/2021/01/27/whatsapp-and-the-domestication...

TLDR: open platforms/standards-driven and implementation-neutral development, implementation diversity, and simplicity are also necessary. Once all that is accomplished, you have a platform that prevents abuse of power: anyone can use any implementation they want, and implementations are simple enough for community members to fork and maintain. All of this prevents vendors from exerting power over users.

> At the same time, copyleft doesn't come free (ha), as developers who need to earn a living will choose to work on problems where they can actually extract some profit to compensate for their effort. Not everyone is keen to work for free, or work as much / as hard for free as they would if they could make a living off it. So yes you might get free-er software, but less of it.

From the article I linked:

> The key to making money with FLOSS is to make software a commoditized complement of other, more profitable services. [1]

[1]: https://www.gwern.net/Complement

> Examples of such services include selling support, customization, consulting, training, managed hosting, hardware, and certifications. Plenty of companies use this approach instead of building proprietary software: Red Hat, Collabora, System76, Purism, Canonical, SUSE, Hashicorp, Databricks, and Gradle are some names that come to mind.

> Managed hosting isn't a basket worth all your eggs if giants like AWS can do the same at a lower price. Being the developer can give an edge in areas like customization, support, and training; it doesn't offer as obvious an advantage when it comes to hosting.

In other words, developers should be paid for service rather than copies of software. AGPL makes it hard to sell copies of software, but doesn't stop you from offering any number of services. This makes sense, since labor is a scarce resource while copies of software require artificially-imposed scarcity to directly bring revenue.

I appreciate yours as well!

I agree that, from a commercial point of view, databases have been shown to need management.

> As to harm to the open source ecosystem, cloud providers wrapping managed services around databases has been shown to stifle innovation on those open source products

I don't think we agree on this. I think PostgreSQL has improved dramatically in the past 5 years, coinciding with (but perhaps not caused by) its increased adoption by AWS customers. The more customers/users FOSS projects have, the more information they have to work with, and the more interested developers they have to draw contributions from.

But it's OK, we don't need to agree on this point. We can adopt the axiom "MongoDB is more innovative because they have a non-OSI-compliant license". Again, I don't think this is necessarily true, but I can concede it so it doesn't distract us.

> You mention - why?

The reason requires stretching our imagination just a bit, but I hope you won't see it as philosophical, since real people plan against scenarios like this. Let's say that, today, MongoDB the company is benevolent, and happy to permit anybody who asks to operate their software. Everybody's happy.

At some point in the future, there's some management change, and the company that owns this IP has decided that the best thing they can do is box-in the customers they have, and make other service providers' lives as legally difficult as possible, thanks to the license they switched to in 2018.

Now, in the future, if you want this database management service that we agree is important and necessary, and you don't want to use MongoDB's platform, you're out of luck.

If you stick to databases with an OSI-certified license, you never have to make contingency plans for this future. There will always be a vendor for code with this license, as long as there's sufficient customer demand, until time immemorial.

Because you can not control the tail risk of MongoDB becoming an Orcale-like company (or, for that matter, being acquired by Oracle), you can not rule out the possibility that all vendors will be excluded from offering MongoDB as a service. You need to plan for the worst case, and treat it as a time-bomb.

You might consider this a philosophical argument, but, practically, this is why OSI has rule #6, and it's why the SSPL (and Elastic License) are not OSI-certified.

> Your discussion implies MongoDB's license (and Elastic and now a host of others) prevents people from contributing to MongoDB. It doesn't.

Correct, it doesn't. It prevents them from contributing to software with a license that does not "Discriminate Against Fields of Endeavor" and does not "Restrict Other Software". Which again, doesn't seem like a bad thing today but opens up paths that are otherwise avoidable.

Even if we buy the innovation argument, and even if this change was made with the purest of intentions, it's noncompliance with OSI standards makes it not worth the tail risk for people who want to pick software today that will be serviceable in 15 years.

It is even mentioned in the introduction:

"The GNU Affero General Public License is designed specifically to ensure that, in such cases, the modified source code becomes available to the community. It 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."

Here is the clause about modification:

"13. Remote Network Interaction; Use with the GNU General Public License.

Notwithstanding any other provision of this License, if you modify the Program, 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 by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph.

Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License."

https://www.gnu.org/licenses/agpl-3.0.html

If developers only get paid for selling auxiliary services, no one actually gets paid to write and improve the software, only to sell services. That's a rotten incentive structure.

Most consumer software doesn't in fact need any auxiliary services. It just needs work put in to actually build it, and that work needs to be paid for.

Props to Red Hat for earning money from enterprise clients. That model only works if you have enterprise customers.

Props to System 76 for selling computers. That model only works if you're selling hardware.

My software doesn't need any services or hardware or other auxiliary bullshit, and I'm not going to invent the need for said bullshit just to satisfy some ideologues.

You're not entitled to tell me what kind of software to write or how to license it. Don't like it, write your own FLOSS version, and outcompete me. Don't want to, or can't sustain yourself that way? Then don't tell me that I should, or that I can. Words are cheap.

> The hypothetical LibreOffice fork, with their private modifications on their own private computer, is entirely within the bounds of reason to keep those modifications private and generate revenue with it, if people want to pay them for the services they provide with it.

I think you're getting caught up in the "on their own private computer" part. There is a clear distinction between using a piece of software and providing a service by which other users make use of the software by proxy. In the first case, you are not acting as a proxy for other users to run the software.

> It's no different than me using LibreOffice to produce private documents, which I then use to generate revenue for my business. My customers have no right to access my private documents that I use to provide that service:

It is incredibly different, so much so that I'm not sure you've understood my hypothetical.

> source code is no different.

If you were using it purely for yourself, yes. But in the hypothetical the business is providing the ability for other users to use the software by proxy. They aren't using the software themselves and then

As a final point, consider that these days a regular user might not know whether the software they run is actually locally running on their computer or is a SaaS application where the code happens to reside on a different machine. How they use the software is no different in either case -- so why should they have different concepts of what freedoms they have? For an ordinary user there is no practical distinction between software they use on their computer versus software which is provided over the internet -- hence why I said that the only real difference is that the "display protocol" for the application is HTTP not X.