Nov 7, 2021, 04:29 by nico.h@gmx.de:
On 07.11.21 00:15, Martin Roth wrote:
Nov 6, 2021, 05:49 by nico.h@gmx.de:
It also seems that you underestimate the individuals in the community.
I don't understand your statement that patrick is underestimating the individuals in the community. Are you saying that people would have worked around the blobs? If so, then why haven't we seen that code. We'd all love it.
Could you explain?
That's so easy to answer that I wonder if you are trolling me?
Nope. You say in a following email that if there's a question about what you mean, we should ask you, but then you wonder if I'm trolling you when I ask for an explanation? What's going on?
Long story short, if a project is cluttered with blobs, you can't expect people to go on as if that didn't happen.
Sure we can. It actually gives people something to start with and replace.
When people are employed to work on blob support instead of native implementations, they don't have the time to work on the latter. Your scenario was "we'd started refusing blobs when the required blobs started appearing". In such a reality, I assume less people would have been employed to work on blob support. IIRC, there was a time when you couldn't hire anyone for coreboot work because a certain blob supporter already hired all of them.
I'm not sure who you're referring to as a blob supporter, but Google's never wanted blobs. Sage didn't either, they just needed anything to stay alive. The blob support has all been the chip vendors. And I think until Felix and Marshall went to AMD, the only other person involved in the coreboot community who went to a chip vendor directly was MrNuke when he went to intel. Everyone else has generally had to train people to work on coreboot. (Even Sage, with the exception of Marc Jones.)
Also, the upstream project became unfriendly towards solutions that are not carried by the respective silicon vendor. I've witnessed that first hand. For instance, when the first ramstage blobs were added, the whole codebase for Intel silicon was kind of forked inside our own repository, digging a deep ditch between the existing native code and the support for newer platforms. In such an environment, it becomes more unlikely that individuals add coreboot-native code. Somebody has spent months to overcome that ditch btw. and IIRC that was to prepare for some coreboot-native implementation that is already working.
I don't recall anyone being unfriendly towards solutions not done by the chip vendor. I agree that we haven't seen much, because of a lack of documentation and the difficulty in doing those ports. But could you point me to an example of a time when someone wanted to do a CPU/SOC port that coreboot refused because it wasn't done by the vendor?
As far as I know everyone wants to move as much out of the blobs and back into coreboot as we can get.
There's also a general reluctance to expect to support a project with free software that has shown that it doesn't take the GPL seriously.
Again, I'm not entirely certain what you mean here.I'm guessing you're talking about the "no linking" clause? We've talked to the lawyers at the SFC, and they haven't said that there's any issue with what's being done. Or are you saying that the SFC doesn't take the GPL seriously? Maybe there are differences of opinions on what taking the GPL seriously means?
Are things that use BSD, MIT, or other non-copyleft licenses not to be taken seriously as free software? You ask to be taken literally, but I'm generally left being confused by your statements. I apologize.
Feel free to respond if you want, but I think this is yet another place where we just won't agree. I definitely don't like the blobs, but I really don't see any world in which simply refusing them would have had a good outcome for the coreboot project.
I'll leave this thread alone after this email.
Regards, Martin