On 11.05.2018 01:32, Aaron Durbin wrote: > On Thu, May 10, 2018 at 5:10 PM, Nico Huber <[email protected]> wrote: >> Ok, I'll try to break this loop here. You are repeating the great bene- >> fits for a user (that I agree to) even if a blob is involved. And I keep >> asking why it should happen on our master branch (I don't see how we >> would take something away by not maintaining everything. Also, I never >> tried to exclude all blobs). It seems somehow we talk past each other. > > I've been meaning to respond to your original response, but I haven't > had a lot of time to articulate things. You've brought this up > numerous times; it sounds like you care what is in the master branch. > But maybe not any other branches? And what is the threshold for being > in master branch? And what audience is the master branch for? I'm > trying to envision what the development and eventual result will be.
As I tried to explain in my other (just sent) mail, I care most about other developers being able to pick up coreboot and use it for their boards. And this is something where we can improve a lot regarding the blob situation, IMO. I just hope, if we had rules that recommend redis- tributable blobs and push into this direction, one day, somebody new to the game (i.e. without prior contact to a silicon vendor) could again just use coreboot. > > You have been focusing on FSP talking about maintaining it, etc, but I > don't think that maintainership is falling on people > disproportionately any more than other parts of the tree. I do find it > a bit ironic that you were te one using FSP for some of your work. Well, it wasn't my choice. And after many months struggling to get a single board working, I wouldn't do it again for a new platform. Now that I know the Sky-/Kaby Lake code another board port would work out. But if things don't get better, I'd rather start reverse engineering right away for a new platform. I'm sure that would save us some time on average if somebody else would use the code, too. > > As for the github fsp proper, the license in the headers is weird, as > Youness pointed out. But in addition to that, it says IOTG Kabylake H > as a release. It doesn't say anything beyond that from a support > standpoint. Empirically it may work, but so does the FSP generated by > Chrome OS. As I'm sure you know assets can be extracted from recovery > images for those FSPs. What's the bar for picking one over the other? Can I use the CrOS FSP for a product? I'm convinced that I can use the one from GitHub. > I don't believe either can be submitted into coreboot.org blobs repo? > Or did I miss where that was concluded? If it was, I missed that too. AFAIR, I checked that once for the License on GitHub (and did not see a way). Nico > > Anyway, just lots of questions -- not many statements. I'm trying to > understand the distinction when I don't see many differences of a > situation I think most people would agree is unfortunate. > >> On 10.05.2018 23:26, Julius Werner wrote: >>>> You really seem to miss the point of free software. >>> >>> Okay, now this is starting to get personal again, let's please not go >>> there. You too have been among those who spoke out against that in that >>> derailment thread recently. It's insulting to insinuate that some of us >>> don't understand or don't care about free software just because we're >>> working for a big company. You also don't need to educate me about the >>> spirit of the GPL or the fundamental travesty of jumping back and forth >>> between blobs and GPL code a dozen times during a single boot and calling >>> it okay because it's "technically not linking". I am aware of these things >>> and I'm not happy about them either. But there have been blobs in most >>> boards that were added to this project since before I started working on it >>> and there will keep being blobs for the foreseeable future. You are not >>> going to convince Intel to open-source their FSP by yelling at fellow >>> coreboot developers about it. It's the reality we live in. This discussion >>> started (as I understood it) about how we can make the blob situation we >>> *are* living with a little better, so let's keep it focused on that. >>> >>>> As long as everybody >>>> adheres to the copyleft, you can do things on your own. If a blob ends >>>> up being only useful for a single board, ok. Should somebody be able to >>>> sell his product with it, sure. But why should the community maintain >>>> that shit (partially on the shoulders of volunteers) if it doesn't pro- >>>> vide what free software provides? >>> >>> "That shit" allows people to build custom firmware for the hardware that >>> they bought, which I think is a very important and worthwhile benefit on >>> its own. For Chromebooks, a whole little ecosystem of custom ROMs and build >>> instructions has developed around this. Do you want to take that away from >>> everyone just because some of the blobs may be mainboard specific? (And >>> again, as far as I am aware most blobs aren't really tied to a specific >>> mainboard, they're just SoC support which may or may not have been written >>> to include whatever peripheral support a particular mainboard needs. You >>> are really just complaining that peripheral support which the existing >>> mainboards didn't need is not implemented yet, which is a situation that >>> can happen just as well on a fully blob-free board.) >>> >>> It's not just free software when you can port it to a completely new >>> mainboard, in the same way that the coreboot core code is still free >>> software even though you can't automatically port it to any new chipset. >>> You can still add features or make changes to customize behavior for an >>> existing board. You can make it boot your own operating system with custom >>> calling convention, add some code signing or measuring framework, or make >>> it play the Jeopardy melody on the speaker while it's booting. That, too, >>> is a benefit of free software. >>> -- coreboot mailing list: [email protected] https://mail.coreboot.org/mailman/listinfo/coreboot
