> Git clone, problem solved.

What a myopic assumption. Availability of source code doesn't solve the legal problems that can arise in the wake corporate restructuring, as new owners work to impede forking and continuing a project outside their control.

Continuing a project in the wake of total organizational failure or capture means setting up legal entities to replace the broken/subverted ones. That's a problem separate from "is the code out there on the Internet for me to download?"

In comparison to the GPL and AGPL, "fair" source licenses are at best hastily drawn. They certainly do not have decades of accrued favorable legal precedent. They are often short and ambiguous because their authors have not imagined half the use cases they might potentially forbid in the name of "fairness". All these qualities are miasmal to long term project stability.

In practice, what matters is that indeed the code is available in a form that makes it modifiable and that machines are available to run it on. Oracle and its hordes of malignant lawyers tried, and almost succeeded, to make this illegal with Java but thanksfully failed.

Why would I need to set up "legal entities" to enjoy my freedom as a user of open source software, unless I'm trying to start a competing business? It's unclear to me what you have in mind. Please explain like I'm a myopic person.

The people promoting "fair" source are specifically doing so to set up legal entities---companies---in order to run a business. That's fine, but it means users of their software should include the potential endgames of those legal entities in their assessment of the software's long term viability. That frame was implicit in my original point.

Any sufficiently large and complex piece of software (free, nonfree, or proprietary) will eventually need some kind of inter-human organization and governance. It won't matter for a small program with complexity that can be managed inside the head of one person but, again, "fair" source as advocated by its own proponents is about software of sufficient complexity to justify legal entities owning, stewarding, guiding, and managing it.

And, IIRC, Oracle and its lawyers, when trying to digest Sun Microsystems, choked on the GPL specifically at least twice: with both MySQL and OpenOffice. The GPL's well thought out protections enabled independent institutions to form around successor forks to those projects. Would the same have been possible with a relatively new, less well thought out "fair" source license? I don't think so.

I don't know what exemple you have in mind, but we were discussing n8n, redis, elastic search... Probably you have much more complex projects in mind?

If I go tu use, say, redis, in a way that the license permit, I don't give a single dime about the legal entity behind it. I just `apt-get install redis`. If I want to modify it for my need, I can `apt-get source redis`. When the next version of redis comes with a more restrictive license, or if features are removed, I just stick to a previous one. Maybe I fork it myself if it's really important for me. Probably, we will be many doing so, we will regroup, share our modifications and improvements. I've experienced this kind of colaborative maintenance of some dead project a couple of times in the past, and all te governance that was ever needed was a mailing list.

Now, sure, some project are more complicated. If, god forbid, postgresql or gcc were to disapear I would not trust myself, or any single individual, to maintain a private fork for long withough the quality deteriorating. But again, people would regroup, cooperate, and we will be able to figure it out.

Compare this with proprietary software, were you truly have no recourse. I've seen wonderful pieces of software in the past, that I loved an used daily, disaprear entirely because the company that produced it went belly up, leaving no alternative than to desperately run the old versions on an emulator still years after because nobody ever managed to redo something as good. And now they are gone, for good, with few people ever remembering them.

So, these are the exemples I have in mind, this is why I don't understand how one could equate fair-source with proprietary -- assuming that the restrictions tainting the "fair" software just prevent the user from competing with the software producer. The user has a ton of power with fair source compared to proprietary.

> When the next version of redis comes with a more restrictive license, or if features are removed, I just stick to a previous one. Maybe I fork it myself if it's really important for me. Probably, we will be many doing so, we will regroup, share our modifications and improvements. I've experienced this kind of colaborative maintenance of some dead project a couple of times in the past, and all te governance that was ever needed was a mailing list.

This situation is a one kind of sudden, unplanned migration. You seem to assess it as less stressful than I would. I'd also be concerned about security generally, duplication of effort to maintain the private fork, and potential retaliation if total secrecy isn't kept by the fork's maintainers.

Your reasoning makes sense for choosing software to use as an individual, but not when choosing software as an organization or when choosing software to integrate into software you distribute for others to use.

Your reasoning also makes sense for maintaining software that has a relaxed threat model (i.e. typically runs or can be made to run in isolation from any network). But the examples you pick (n8n, redis, elastic search) are most often used on perpetually networked computers where security a larger concern and I don't know that I'd trust a private, ad hoc group to keep a secret fork (in potential violation of a "fair" source license) up to snuff.

Oh I see. Sure I trust individual maintainers at least as much as large organisations. Part of my first gig included running debian potato's postgresql on a PC with an oracle sticker on it...