[coreboot] Binary blobs in the source tree (was: Re: New patch to review for coreboot: e4fc528 Add the memory reference code binary for sandybridge chipsets)
xdrudis at tinet.cat
Tue Apr 17 01:48:46 CEST 2012
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,
> 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
> 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...
> 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...
More information about the coreboot