Re: Microcode license [#3]

[Giacomo Catenazzi <cate@math.ethz.ch>]

"Thomas Bushnell, BSG" wrote:
> 
> Giacomo Catenazzi <cate@math.ethz.ch> writes:
> 
> > 2) It is difficult to say that microcode is a program:
> >    there are surelly many entry points (one per instruction),
> >    many exit point. Instruction are executed partly in parallel,...
> >    It is too hardware dependent. You can see it also as a immage for
> >    a chip. Then the electric flow are influenced by this immage (like
> >    photocopy machines), but relly it is not a program (AFAIK, the
> >    intel microcode is a list of changes of order of u-instructions
> >    in instruction). But until we have not full (or also some) Intel
> >    microcode and CPU internal build documentation, we cannot know
> >    if it is software...
> 
> Oh, please!  We know it's software.  They call it *microcode*.

hmm. They don't call it officially 'microcode'. On official documents
you will found other names (but I don't remember the official names.
In the errata they wrote: corrected via BIOS).
The name 'microcode' is an historic one, when there was programmable
instructions, and the developer at Intel wrote either 'microcode'
and 'data file'.

> 
> Having many entry points, parallel processing, hardware dependencies:
> all these are characteristics of it, but it is still software.

OK

> 
> It isn't hardware, precisely because you can upload *different*
> microcodes and get different behavior.  And Intel (IIUC) is preventing
> people from having the liberty to change and alter how that
> *programmable* function gets programmed.

True! (I expected that some hacker will found the microcode structure/
language, but I think it is too difficult because: the microcode (
but the header) is encrypted, and it is too hardware specific)

 
> > 3) You should be more contructive. Intel already changed the license
> >    because of Debian need. If you point to me exactly what is wrong
> >    and what changes should be taken, I can tell Intel to improve the
> >    license for the second time.
> 
> They should conform to the DFSG.  How hard is that?  Relabeling a
> dog's tail to be a leg doesn't make it a leg.  They need to make it
> *free software*, not just try and redefine terms so that it isn't
> software.
> 
> Thomas

True! But until the microcode will become DFSG, adding microcode to
debian add some freedom to us: the hardware that we buy will conform
more to the standard. Thus it is simple to make working program without
adding the exception for the various CPU.

But there is annother difficult. To write BIOS we use assembler because
we have much control to hardware, to write microcode I think they don't
use any language, to be more direct. They write (maybe) directly the bit
or byte. Thus there exists only binary files, so for DFSG: no source.


But: I can convince Intel to change the microcode license in a more
liberal way, but I would never convince Intel to put documentation
on microcode and to put microcode DFSG.
Thus I think the first step is to have microcode so much free
that it can be included in debian non-free.
Then we must improve Linux (kernel) and Open Source enought to
convince hardware manufacters to release microcodes and documentations
in a DFSG compatible manner.

	giacomo