On 08.11.21 19:38, Martin Roth wrote:
Nov 7, 2021, 04:29 by firstname.lastname@example.org:
On 07.11.21 00:15, Martin Roth wrote:
Nov 6, 2021, 05:49 by email@example.com:
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?
Because it's so simple to explain. At least when one knows what is going on. I may have missed that you don't.
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.)
Since about 2014 all the Intel-based Chromebooks use an *optional* blob for graphics init, even though the hardware is *publicly* documented virtually to the last bit. There is no pressure whatsoever from Intel. These blobs are used willingly. As Google seems responsible for the firmware, I have to assume they are supporting blobs. Welcome to reality, Martin. As this happens right under your nose, I can't trust you when you say everybody wants to get rid of the blobs. Well, trust may be the wrong word, I think you don't have a clue.
And that's just the area I'm an expert in. I don't know how many more cases there are where blobs are simply used because they exist. Closing our eyes doesn't help. We need to keep talking about these things.
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?
I wasn't referring to any full platform support. Around 2014 coreboot on Intel platforms was effectively dead for anyone but a few select companies that Intel chose to talk to. There were two competing blobs to bring up Broadwell, neither of them was redistributable so many folks were shut out from coreboot development. Somewhere around the FSP for Skylake / Kaby Lake things got better, blob-access wise, but the existing platform code was tailored to Chromebooks and any attempt to fix it was blocked by the fear of breaking something. I tried to, but nobody took the time to answer the simplest questions about the boards in the tree. When somebody else took the burden to review my patches, I got bullied by Intel and Google employees when something broke. I'm not mad at anyone for this. I simply assume that some people's social skills got crushed under the corporate pressure.
As far as I know everyone wants to move as much out of the blobs and back into coreboot as we can get.
Well, definitely not everyone, see above.
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?
Sorry let me try to explain.
There are permissive and copy-left licenses. The GPL is one of the latter kind. Permissive licenses are of the "I don't care what you do with the code" kind. For copy-left licenses it is assumed that when somebody takes free software, they also give free software back. It's kind of the payment for the free software, we don't want money, we want more free software. Intel, for instance, does not give free software back. They don't pay. Many other entities do. They don't. Our leader- ship accepts that. Hence I see it as that the project doesn't take the GPL seriously.
Are things that use BSD, MIT, or other non-copyleft licenses not to be taken seriously as free software?
I don't understand the question. Maybe it's answered above.
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.
No refusing them doesn't help. But writing free software where we can could. Please start with that.