Do the license come with a waiver of liability or warranty? If yes, user losses aren't liable by the authors. It is up to the user if one software is broken and they decide to modify it, there isn't any hostage.
I think there are two factors here: the mere software, and the network/blockchain.
The code of the software might come with such a waiver. But those who bootstrapped the blockchain are usually interested in people using _their_ blockchain on their network, so they might advertise their blockchain and create expectations. Those who believe the advertisements and decide to invest would still be dependent on using the provided software.
This creates a "hostage" situation because there is no equal power even though the users' right to modify the source code is protected. If they use their right to improve the software by fixing bugs, it's still likely that those who bootstrapped the blockchain and took the premine will have a much larger benefit from the improvements.
What makes you think it's a separate factor?
It's an immediate conclusion from looking at a lot of free software licenses being used for writing blockchain software. The license will often include guarantees and restrictions regarding the software, but will on the other hand often not say anything about the network or blockchain on which the software operates.
This is also not a blockchain-specific issue. For example, look at Docker. People might like the (open-source) software, but not like the service platform it links to by default, and even decide to self-host it.
With blockchains, self-hosting alone is not a solution, and it would be important to also have a community around it.
Looking into the other direction, one might say that a blockchain to be taken serious should not rely on one single compatible client suite. For Bitcoin, you can already choose from multiple implementations, which makes it more likely that the blockchain will survive.
So, I would say there are multiple arguments suggesting that software and network/blockchain are to be considered separately, at least when the software itself is not proprietary. I consider it merely as an effect of too many separate blockchains being built that most of them do not survive up to the point where the distinction becomes relevant.
IMO, The software itself is inherently tied with the network, so I rather think it interrelated factor. It is not completely separated due to the constraint of what the code does toward the blockchain.
I think it's a matter of code quality. The link to the particular blockchain might be as small as defining a genesis block hash and a few bootstrap nodes. Hence the comparison to hard coding docker.com in Docker.
Of course, in practise you might see more, like hard coding gazillions of block numbers where hard forks occur, or whatever other fixes that become necessary when facing real-life problems with the blockchain. Hence "code quality": Good practise would be to separate this data from the code.
Free software guarantees are, among other goals, often exactly targeted at users who want to improve such quality defects. They might just refactor and implement a clean separation between node logic and data that defines characteristics of the particular blockchain.
Do note that libre software gave freedom to the users, whether they on the first hand would join with the mob or not. So, I rather think the users should have known if they use any particular software that requires others' consensus, they must be obliged to follow the current rules that are inherently tied to the software.
I think this does actually mix up "free as in beer" and "free as in speech" software. "Free as in beer" is the term often used for software where you just have the freedom of choosing whether to "join with the mob" or not. "Free as in speech" software was invented to prevent exactly that.
In my opinion, to make it legally sound, if the authors of the software wanted the users to follow the current rules that are inherently tied to the software (for example, losing a lot of money because the main authors aren't interested in fixing bugs as long as their pre-mine doesn't lose too much value) instead of wielding their freedom and retargeting the software, they should write up an appropriate EULA. However, chances are that it would be incompatible with a lot of free software licenses.
This is what, in my opinion, does lead to the aforementioned dilemma: A discrepancy between what the legal possibilities likely are, and what the authors likely expect.
With that in mind, users still have the freedom to use their own rules/consensus with their own community, yet doesn't incorporate any dilemmas at all.
Yes, this is their freedom. And if an existing community uses a software whose license allows it, they can use that software to build up their own rules/consensus (cloned) with their own community (built from scratch).
