upvote
OpenBSD folks would consider the GPL to be less open due to the requirement to apply the GPL to any derivative works.
reply
And GNU folks would say the GPL is actually the more open choice because it forces the project to stay open.

Two different ways of thinking about it I guess... it's nice to have choices and I don't think one is more or less "correct", more a matter of opinion/taste I guess.

reply
I don't think the FSF would say that. They prefer the GPL, because it prevents someone from making a closed derivative, but I haven't seen them ever claim it is more open than "permissive" licenses.
reply
It kind of reminds me of the equality of opportunity people versus the equality of outcome people. One sets the starting conditions for developers, the other the ending conditions for users.
reply
Since developers are a subset of users, it's actually possible to calculate which is more open.
reply
> more open choice because it forces the project

A true morality must be based on consent, not coercion. Humanity may not be there yet, and therein lies the argument for force (and thus copyleft); but the ultimate goal should always be to reduce its necessity.

reply
It’s not coercion. You’re free to not use it, or alternatively do what these folks did, write your own. Coercion would be forcing people to use it through some mechanism, which clearly isn’t possible with GPL.
reply
I see this, and the spiritual example that immediately comes to mind is that which is labeled as "crime". Would it be more moral that a murderer must first consent to being judged and sentenced, or that there is a system which automatically comes into play to hopefully deter but also punish it when it happens?
reply
Allowing closed-source to exist is always the less moral choice for many reasons (one example being ecological sustainability)
reply
Is this not the paradox of tolerance restated in different terms?

BSD license is unrestricted, it tolerates taking open source and closing it, thus always being at risk of things closing down.

GPL license doesn’t tolerate taking from open source and closing it, thus ensuring things stay open.

reply
The paradox clears itself up if you look at what tolerance actually is. It's simply not interfering with people's agency over themselves. Given that your right to self-agency doesn't entitle you to restrict others' self-agency, behavior that does try restricting others' agency is automatically not included in "tolerance."
reply
The BSD license is why we have Valkey and not a purely closed-source Redis. It would have been much easier to perform the rugpull if Redis had initially been GPLed.
reply
On top of badreligion42’s point, that both licenses allow forking just as easily - don’t you have the rugpull part backwards?

Afaik BSD licensed stuff can be re-licensed under any more closed licenses at any time, where as to re-license GPL, you need consent from every single contributor.

But i’m not familiar with the redis-valkey story so, maybe there is some nuance i am missing?

reply
Redis started off as Free Software, but was switched to a source available license in version 7.4. The community promptly forked to Valkey, which is still under the BSD license. Since then, Redis shifted to AGPL 3, with contributor agreements, to try to ensure that they're the only ones who can attempt to commercialize Redis.
reply
AGPL makes commercializing harder only for people who fear the AGPL because they want to keep stuff for themselves. there is no problem commercializing it if you don't mind sharing all your connected code. the only benefit redis has is that they can integrate non-free code in their hosting service, while the rest of us could not. since it is their work, i think it is reasonable that they have an advantage. it does not reduce my freedom as a user. it only hinders AWS and other big players from crushing redis.
reply
And how exactly did the BSD license make creating Valkey easier? GPL and BSD licenses both have the source in the open. Anyone creating a fork, can easily do so for either BSD or GPL licensed projects. Since Redis is a database, which the user won't be using a binary of, even using a fork of a supposedly GPL-licensed Redis would not require you to share your modifications with your user, same as BSD.
reply
The BSD license made forking Valkey easier because it ensures that everyone has equal footing. The GPL, especially with contributor license agreements and the like, makes it much more easy for a single party to control the direction of the product. For another example of this happening, look at MongoDB. It started out under the AGPL, but was rugpulled to a non-free license.
reply
It feels like your actual beef here is with CLAs, which often are designed to allow the current maintainers to relicense.

CLAs are not an attribute of the GPL. They're an agreement that can be applied to contributions to any codebase with any license.

reply
Mongo was already a centralized project. Technically open source agpl but I don’t remember it having a large developer community or really many contributions from outside mongo. When the rug pull happened I think simply most people didn’t care or moved on to equal (or better) alternatives. It’s not beloved software like Redis is.
reply
The BSD license made forking Valkey easier because it ensures that everyone has equal footing

equal footing on the license is what allowed AWS to crush the original creators of the products they host.

it's a trade off.

the AGPL does not prevent a hosting service. it only prevents creating non-free addons. i see no problem with that. see also my other comment

reply
Many projects closely associated with OpenBSD start with "open"... openssh, openbgpd, openntpd, opensmtpd etc.
reply
Notable exception, OpenSSL already had the Open prefix so the OpenBSD project is called LibreSSL.
reply
Not many are reimplementations of existing, much more popular, already open source projects.
reply
OpenSSH was a 'reaction' to the original SSH(.com) code getting closed source:

> OpenSSH originated in 1999 as a fork of Björn Grönvall's OSSH, which derived from Tatu Ylönen's original SSH 1.2.12 release, the last version distributed under a license permitting open-source redistribution before Ylönen's subsequent software became proprietary under SSH Communications Security.[4]

* https://en.wikipedia.org/wiki/OpenSSH

It was probably the second thing with the Open— prefix by this group of developers, OpenBSD itself being the first. They simply ran with the naming convention. OpenBGP/OSPF were developed as alternatives to Quagga (GPL).

reply
Is rsync going closed source? If not, how is that the same thing?
reply
No. The name only means it’s made by the OpenBSD team, nothing more. If they made their own Python port, it’d be called OpenPython, even though the original is FOSS.
reply
So is OpenSUSE made by the BSD team? OpenOffice? OpenShift? OpenCV? OpenAI?

It is not reasonable to claim this prefix unambiguously refers to the OpenBSD team. I do not understand why so many in this thread are pretending this isn't a confusing choice.

reply
Nobody ever claimed that “Open” is a prefix used unambiguously by only one group of people ever.

In fact, your insistence that “Open” can only be used by projects that are replacing proprietary software is itself very odd.

OpenBSD itself has had its name for thirty years, and is not named for being an “open source” implementation of a proprietary OS.

reply
The person I replied to said the "open" prefix means it's made by the OpenBSD team and I am responding to that.

Do not invent arguments that I did not make. I have only said that naming it openrsync when rsync already exists and is "open" in the general sense is confusing.

I find the negative reactions to this observation very confusing, especially yours, but I see that you're an OpenBSD developer so that explains your bias.

reply
> The person I replied to said the "open" prefix means it's made by the OpenBSD team and I am responding to that.

What was said is that the OpenBSD operating system folks chose to use the Open— prefix for all their other projects ("They simply ran with the naming convention."). What was not said was that all Open— prefixed projects were from them.

reply
You’re inventing an argument I didn’t make. OpenBSD doesn’t own “open”. Literally no one is saying that. What I did say is that openrsync is named that because the OpenBSD team names their projects that way. The “open” in this project means that it came from OpenBSD, not that that it’s in contrast to rsync being proprietary (which it isn’t).
reply
> Is rsync going closed source? If not, how is that the same thing?

Not closed source, but with rsync 3.0 it changed its license to GPL3, which a lot of folks don't like: BSD/MIT licenses have zero limitations on use and distribution, GPL2 (rsync 1.x, 2.x) forces one to release code, GPL3 (rsync ≥3.x) adds further restrictions.

Some folks want to distribute code with as few restrictions as possible. Other folks have a great good/goal in mind (e.g., 'all software is open source') and so add 'local restrictions' to hopefully achieve greater non-restrictions.

reply
OpenBSD didn’t get its name from NetBSD going closed source.
reply
Historically speaking, it may have meant open to poorly socialized developers.
reply
Which aren't? It seems all (or most) are.
reply