> What's so bad with this?

It's lying. It's an open source project and a business model built on deceit. I guess I care about clear rules, clear intentions, and I care about integrity above all. The AGPL is ambiguity; unclear rules, veiled intentions. And these same people will relicense without a thought, too. I think we should care about these things, otherwise we repeat history over and over again.

▲

NoGravitas 6 days ago | parent | next [-]

> veiled intentions

The intentions behind the AGPL were never veiled. The intent was to close the loophole in the GPL3 that is opened by providing software as a network service. If you were to release software that provides a network service under the GPL3, someone else could use and modify it without sharing their changes, but while also providing it as a service. AGPL3 closes this loophole by ensuring that everyone who can use the software must have access to the source including any changes. I don't see any deceit, and I don't even see any anti-competitiveness.

	▲	ezekg 6 days ago \| parent [-]
		If you read the conversation higher up, instead of taking what I said out of context, you'd see that I was talking about the author veiling their intentions, i.e. using the AGPL as an effective non-compete while masquerading as "open source." They (the author aka the startup) wouldn't have chosen the AGPL if not for enterprises/bigtech/competition being scared of it. They didn't choose AGPL to increase freedom 0 (AGPL's purpose), they chose it to decrease it. Thus, veiled intentions.

▲

jraph 7 days ago | parent | prev [-]

> It's lying.

I don't see how it can do this. The AGPL is a license text. It states what people can do with the licensed code. What is lying in this text?

> I guess I care about clear rules, clear intentions, and I care about integrity

Me too

> The AGPL is ambiguity; unclear rules, veiled intentions

That's where I don't agree: The rules are written in the license text and I see no ambiguity there. Where is the ambiguity in the AGPL text? What is not clear about it? What granted rights are we not sure about?

> veiled intentions

The original intent of the AGPL authors (the FSF) was clear and simple to me: ensure the end user's freedom. It was GPL, but address the SaaS situation where someone can modify networked GPL software, make users use it from the network, without having to redistribute the modification since the program runs remotely and not on the user's machine. And that intent is perfectly align with what I want for my code.

Sure, people with bad intents will use the AGPL, and so what?

People kill with knives, but I'll definitely keep cooking with mine. The AGPL is a tool. It doesn't, by itself, has intents, especially veiled intents.

I'm not going to stop using the AGPL because someone wants to use it to trap users.

This is all abstract, I'd appreciate concrete examples where:

- people have done that, without a CLA (because yeah, I'm convinced AGPL+CLA can be bad).

- the AGPL doesn't work well for someone using it with the original intent in which the AGPL was written.

▲

ezekg 7 days ago | parent [-]

Here's a thread from a couple hours ago on X: https://x.com/_m27e/status/1962563736142565882. Read the images and follow the quoted posts.

The example comes straight from the mouth of a COSS founder.

▲

jraph 7 days ago | parent [-]

Sorry, but this yes-answered AI slop subtly makes no sense, it just reads comfortable to you. You should not delegate writing your opinion to the llm and even less use it to shape your opinion, this is my main takeaway from your screenshot. The AI answered your biased question in a way that pleases you, it's well known that they do this. This stuff is actually scary, and that clever people like you rely on this and don't notice the glaring issues is even more.

The agpl is ambiguous because users may choose not to fully use the freedom they were given? Sorry but this is bullshit. I'm glad I haven't started using this stuff yet (for other reasons). I'm sure I wouldn't notice such issues in topics I'm not at ease with and I can see how easy one can be seduced by this stuff.

Now, I'm convinced AGPL can be misused. What's more, I'm certainly quite happy that a side effect of the AGPL is that Google won't touch it, to mirror the comment you point to (whose author is wrong by the way, the intent behind the AGPL was not to exclude big tech, but to promote/protect user software freedom). All the fud around the AGPL actually comes from companies like Google, so respectfully fuck them all. Nobody could possibly have weaponised the AGPL against them had they not started spreading all the fud in the first place.

But even considering that picking the AGPL to scare big tech away is bad and weaponizes it (which I can hear, and let's assume), I believe you are wrong that nobody chooses the AGPL for the user freedom genuinely. There are a lot of examples of software under AGPL in good faith seemingly to me. Examples: Nextcloud, Joplin, CryptPad, Overleaf, Passbolt, Univention...

I doubt any of these commercial projects from friendly (?) companies choose the AGPL to fuck the world. I don't know the numbers, maybe it's a minority. You may not have numbers as well. Are you against the AGPL when used in good faith? If so, what to you suggest as an alternative?

I'm with you with the wish people were altruistic. But the system we live in doesn't exactly help being altruistic. Not being altruistic is certainly not a trait of people using AGPL, it's virtually everyone in a commercial setting (although some of us try to do their best to be good humans and virtuous). If anything, the AGPL was born from a ideal and that was certainly driven by something like altruism. All this blame towards the AGPL because people are out there to make money really feels weird to me.

Anyway, I don't think we'll reach an agreement here and that's OK. Thanks for the discussion, despite the strong disagreement it is/was stimulating.

▲

ezekg 6 days ago | parent [-]

Fair enough, but the LLM said nothing incorrect (if it did, please point it out). Regardless, the screenshots don't even matter. You didn't seem to actually read the thread I pointed to, where a VC-backed startup founder admitted to using the AGPL to limit bigtech from using the software, a clear violation of freedom 0. They didn't choose the AGPL for altruistic reasons, rather, it's simply a part of the COSS startup playbook now -- because it works! -- they can use the term "open source" while protecting themselves from competition. Which is my entire point.

Why do they get to use "open source" while effectively violating the freedoms but somebody using the Elastic License, or the Sustainable Use License, or the SSPL, or the BSL, or the FSL, etc. isn't allowed to? They're all doing the same thing, only the latter licenses are saying the quiet part out loud.

Anyways, I agree we do seem to be talking past each other at this point. gl

	▲	jraph 5 days ago \| parent [-]
		> You didn't seem to actually read the thread I pointed to I had mentioned it so you could see I actually read it. I had actually made the effort to load this twitter link despite the PITA it is. > if it did, please point it out Already pointed out my main qualm, but Brandolini's law is particularly bad with LLMs, I won't have time to debunk in details each time I run into generated text. I'd rather argue with a human being. Let's forget this part of the discussion, it was not your point, I should have ignored it, I'm just losing patience with the LLM madness. > effectively violating the freedoms They don't. There's a fundamental difference between "the license permits something but someone elects to avoid benefiting from it" (someone = big corps) and "the license actually forbids something". The difference is quite major for the rest of us who are not big corps stupidly afraid of the AGPL, and we are the vast majority. Which resolves your question: > Why do they get to use "open source" while effectively violating the freedoms but somebody using the Elastic License, or the Sustainable Use License, or the SSPL, or the BSL, or the FSL, etc. isn't allowed to? The reason is the Elastic License, or the Sustainable Use License, or the SSPL, or the BSL, or the FSL actually forbid running stuff for some endeavors. AGPL doesn't. We only have big corps deciding they should stay clear from the AGPL. That's not the AGPL forbidding anything to anyone. It's not a feature of AGPL. It's a feature of big corps. Now, that some people choose the AGPL because they know big corps stay clear from it, okay. I understand you find this veiled. Fine. But that doesn't make AGPL non open source. Our main disagreement IMHO is that you would like that we qualify licenses depending on the intent of people using it or on the FUD corps who don't like it (and you too!) spread instead of what they intrinsically allow or not. I can't agree with this. I'll go further. "Sustainable" and "Fair" are terrible and intentionally misleading qualifiers for these non-free licenses that are sustainable and fair only to the authors of the software under those licenses. You just need to own the fact that you write proprietary software, and shouldn't bitch on people actually doing open source stuff and find them gotchas. They are not doing some anti-competitive stuff that's unfair to you. If you find AGPL gives unfair advantage because it gets called open source, nothing prevents you from adopting it. I suspect you won't because you know it actually gives more rights than you want to give, which also answers your question. You guys using proprietary licenses are the ones not respecting software freedom, and you trying to call out people who actually do is quite rich. This really doesn't look great. I'd suggest you quit doing this and focus on the positive things instead. I've asked you what harm the AGPL actually does and all you have to share is some tweet written in jest answering a low quality LLM generated text tickling the gafam. Not very convincing. Not sure you'll find deep meaning in such low quality interactions on such a low quality platform. Stop spreading the FUD and own your choices.