Sorry for the rant, it's not aimed at any particular person, just to blobs which I don't think should get into coreboot.
On Mon, Apr 16, 2012 at 08:53:56AM +0100, Andrew Goodbody wrote:
To be honest I don't see the difference between having binary blobs in a separate repo and having them in the main coreboot repo. Apart that is from the slightly meaningless saying that the whole coreboot tree is GPL compatible. It seems more relevant to be able to say that about a particular port. So AMD chipsets will be fully GPL whereas Intel chipsets will not. This is regardless of where the blobs are actually stored. And aside of the question of where and how microcode is executed.
Of course it is relevant to say a whole project is GPL compatible, or free, or even any other property. Software isn't just a bunch of features and a bit string. It is a work that evolves through time, that's why people spend effort on maintanability and that's why the choice of licenses sets a shared plan on what committers agree. When you use a piece of software you invest some effort because you have some expectations not only on current features but on future possibilities. There's a capital to waste when changing directions.
I've not helped this effort much so it's not for me to decide, but if coreboot starts filling with blobs it will be just another BIOS, only somewhat delayed or playing catchup with some features.
In the past I've bought hardware believing it was likely to work with free firmware by looking at what coreboot supports. Recently I thought I might buy a chromebook if they finally run coreboot. But if coreboot becomes a blob loader I won't buy any hardware based on the fact that it runs coreboot. Coreboot would no longer be what it was to me. If someone forks a coreboot-libre then I may follow that, otherwise, it will be like what linux has become, you no longer know much by the statement that linux runs on something. If android is free software why should it be so hard to replace it with something else on some hardware? Does it have something to do with it accomodating too many propietary complements? It is pervasive, it has a big growth, it has many users. Yet it doesn't give them quite enough freedom. Coreboot may choose to go that route or may try to go the way of many other free software projects (GCC, Apache, debian...)
So the big question is really do we allow chipset support that requires the use of binary blobs in coreboot.
I don't. I try to find chipsets that don't require that.
If yes then those blobs may as well reside in the coreboot repo as anywhere else because you're going to need them to build a port.
I don't think such a limited port is worth people's efforts, but that's for each one to decide, of course. There are other propietary BIOSes around for that hardware, a free port to any hardware is worthwhile, a greenwashed half baked port of something that used to be free is not a big deal. I know it's still a lot of work in the free code for intel chipsets, but if the memory controller (which I hear is one of the most difficult parts) or such or such can't be understood or repaired, and the propietary BIOS you got preinstalled from factory does the job, I don't see much point in making or using a port.
In my view microcode and MRC are roughly equivalent. The method of executing the microcode is just different and that microcode is executed by the CPU in a different operating mode but it most certainly does go away and come back and the CPU state has changed by doing so.
Well, yes, I'm not very comfortable with microcode updates either. Yet, the fact I'm not comfortable with two things does not mean they are equal. I'm not very up to date, but if microcode is now loaded from the cbfs (it wasn't when I last looked, long ago, before git), then at least it has some legal advantages. Stuff you link at runtime is susceptible to form a derived work, at least under some interpretations (IANAL, and not sure at all calling some blob code needs any linking or anything that can be seen as creating derived works). Stuff you load from flash to hardware (from one EPROM to another, in fact) might not be construed as derived work.
Besides, microcode can be redistributed even if it is not free. Does someone else besides intel and google have permission to distribute the blobs? coreboot users have usually assumed they had permission to distribute the tree freely under GPL, not necessarily sending people to a single repository because the parties with distribution rights have designated it as distribution means. I mean people can publish their git trees anywhere, can't they? Must they now prune the blobs or ask intel for permission ?
People who is used to collaborate in a certain way even if it has historically meant incomplete hardware support may feel less inclined to collaborate when it is not sure their contributions will be used in the way they expect, or when they have difficulty to grasp what the criteria is for accepting restricted code to enable hardware support, or for distributing the resulting material.
Even if this (real or imagined) legal uncertainity does not scare corporate contributions, it might degrade their contribution. This includes even hardware vendors who might have published materials under terms that they believed were necessary to get acceptance and might change their policy if they find out the requirements for participation weren't so strict given later decisions or even feel under unfair competition. Others can claim coreboot compatibility with less disclosure. So going for more hardware support now might lead to less hardware support later, or to a spiraling propietarisation of the code base that voids the attractiveness of the project.
So it is a slippery slope and we have already started on it and I see no practical way back now.
Not sure why being in a slippery slope would be a reason to stop trying to keep some balance...
Andrew
PS I am really excited to see SandyBridge support coming in, I may actually be able to use coreboot in a project now.
Yeah, I was excited too until I heard of blobs.
I guess it's better to just stop buying hardware, if you can't even rely on a FSF priority project to get free software. Conformism with blobs seems to be so pervasive...