kernel-libre (hopefully 100% Free) for Fedora 8 and rawhide

[Simo Sorce]

Alexander, in general I tend to agree with you on the ethical level, but
I think you are going one step too far in this discussion.

First of all you really ought to decide if "free hardware" is the only
ethically acceptable choice for you. If so, the next logical step is
that you should stop using computers, because there isn't a single, mass
manufactured computer on earth that is completely built on "free
hardware".

If you think that hardware and software are 2 domains and you want to
concentrate on free software now, then you *have to* recognize the
distinction and not require more than what free *software* would
require.

This is fundamental, but it is also fundamental for you to be clear on
this point, because it is evident you are mixing matters in this thread.

Comment inline.

On Sun, 2008-03-30 at 06:27 -0300, Alexandre Oliva wrote:
> On Mar 30, 2008, Hans de Goede <j.w.r.degoede at hhs.nl> wrote:
> 
> > Alexandre Oliva wrote:
> >> - Sorry, I don't understand them myself.  I just copied them from the
> >> Windows driver.
> 
> > I didn't write this driver, but this is the most likely correct
> > answer. Still given that I needed to explain color correction lookup
> > tables to you. I _seriously_ doubt your ability to decide if this
> > makes some code non free.
> 
> What does one thing have to do with the other?  You're talking of
> technical matters, I'm talking of ethical matters.  How would my
> technical lack of knowledge about one particular kind of device make
> me unable to figure out whether someone is trying to stop others from
> enjoying the four freedoms on a piece of code?  That's not a technical
> issue at all.

It is! You are claiming your lack of technical understanding "might"
influence if a piece of code is free or not, and your table makes it
evident. Your table to choose what is free or not is subject to what I
call "post mortem un-free-tization". Which means that if the last author
that knew what something did (or the last piece of documentation on the
hardware is lost) then a driver becomes non-free, after having been free
all the time.
This is not acceptable, and for sure you cannot force a kernel to
release the datasheets for all single chipset ever supported as part of
the source code.
Not only because this would be completely unpractical, but also because
datasheets are not source code for software. The software is clearly
understandable, you can perfectly understand that a registry is being
set.
The fact you don't know why a registry is set to a value or another is a
matter of hardware freedom at most, but not of software freedom.

And if you believe so then the DES* algorithm is never implementable in
free software because it is based on a couple of tables nobody knows how
and when where implemented. You should stop using anything that uses
that algorithm

*IIRC going by memory, might be a different crypto algorithm.

Free software is about software, not about perfect knowledge of the
physical world. Free software has boundaries too.

> > First of all this is data, not code, and you can study the data all
> > you want, just as you can study a picture all your want without
> > needing to have to know why each pixel is the color it is.
> 
> You can say it's data as much as it want, the point is that it
> performs a functional role, and that's what makes the 4 freedoms
> ethically essential.  Comparing it with a picture is an inappropriate
> comparison for this reason.

An image might be functional data no more or less than it is a PASSWORD.
Now will you start claiming that you will not use any software that
deals with passwords (or any crypto code) because it may deal with data
to which you cannot have understanding ?

> Now, once it performs a functional role, then studying and
> understanding it has a broader meaning: you have to understand what
> each number actually means.  Especially if you want to have the
> freedom to modify it, to adapt it such that it does what you want.

If, and ONLY if it makes sense to modify it.

If I have an activation sequence code for a piece of hardware, and I
know that's the only way that piece of hardware can ever be activated,
then knowing *why* it is that way, may be a very nice curiosity. But
from the point of view of a driver and therefore free software it has
ZERO relevance because you have all the knowledge you need from a driver
programmer perspective, that is: you use it that way or hardware will
not work, period! Even if you know why it is, it does not change the
fact that that is the activation sequence, and you will gain nothing in
trying to change it, except finding out the hardware will not work,
something you already know because you were told so. Therefore from the
pure software point of view the information released to you was all you
needed and therefore comply with any freedom #1 you can come up.

The above does *not* apply to registries that CAN be set to different
values, but technical knowledge is needed to determine the difference,
not ethical knowledge.

The above does *not* apply to "hardware freedom", but here we are
talking about software freedom, right?

Once you know the difference you can make an ethical choice.

> E.g., in the color correction table, if I wanted to make the software
> behave differently WRT colors, now I have some vague idea of what I'd
> have to do with those numbers.
> 
> Now, compare that with the register initialization code.  How can I
> adapt it such that the code does what I need, if I can't really know
> what it's doing?

Can you tell me what you need?
Because the only need you may have it to actually initialize the
hardware or not initialize it. It's a binary choice, and all the
information to make this choice is provided.

Example:
Do you claim you need to know how all the connections from the key of
your car to your car engine are wired and built to be able to start the
engine ?
No. All you need to know is the direction you need to turn the key form
the "software" point of view.

> > You are also free to modify, derive, and spread it so I see no
> > problem here.
> 
> We're miscommunicating.  I've addressed this point.  'free to modify'
> is not enough, 'freedom to adapt to your needs' is what the FSD says,
> and that requires actual comprehension of what's in there in the first
> place.  If someone denies you that, then the code is non-Free.

The code is software, and it is one thing, the hardware is a different
thing.
Your reasoning makes sense to me for firmware *code* that runs on an
embedded processor in the hardware, or at most for registries that can
assume different values.
But again for registries, to obtain *software* freedom, all you need to
know is which are the valid values, and when you can (or have to) enter
them. For software freedom knowing the (hardware) why, in most cases, is
*not* necessary.

> That's unfortunate.  For the microprocessor documentation I've seen, I
> had documentation for every single bit of every single hardware
> register that I've needed to work on the compiler, assembler, linker
> and run-time libraries.

CPUs are quite different from other hardware, especially hardware that
deals with physical phenomenons, and do measure or interact with
physical quantities.

> I can see that trial and error can be used to determine recommended
> values, but I don't see that this low standard for documentation is a
> good one.  But that's besides the point.

And it is beside the point because you are getting into the hardware
realm.

> > So although those numbers are taken from the windows driver (I think),
> 
> Is there permission to do so and release that under the GPL?

Innocent until demonstrated guilty, I'd say.

> > the windows driver may have derived them this way. IF you even call
> > this non free you seem to _really_ be out of touch with the
> _physical_
> > reality. Some systems are svery complex: too many variables, with to
> > much uncertainty as to what their values are as that cannot be
> > predicted as its dependend upon the production process and often
> even
> > the batch.
> 
> > This is a fact of _physical_ reality, and this is solved by adding
> > some knobs to compensate for the uncertainty of some variables, the
> > correct position of these knobs is then often determined by ...
> trial
> > and error.
> 
> Sure, this is all good.  That's not what I'm concerned about.
> 
> What I'm concerned about is the reason to deny all this information to
> customers and developers.

Ok, but then you are dealing with hardware freedom, please stop mixing
hardware and software freedom or make the distinction clear, or make it
clear you have a concept of software freedom that is different from the
free software definition.

> > No amount of philosophical discussion will change the fact that
> > sometimes some values in registers are just there because they need to
> > be there.
> 
> I don't buy that.  If there's a register there, it's because someone
> put it there for a reason, and changing it must have some effect,
> otherwise it wouldn't be there in the first place.  But there's a big
> difference between "we don't know, it was like this when we got here"
> to "we know it, but we're not going to tell you".

Only for hardware freedom, for software freedom you don't care, the only
thing you care to know for the software perspective is what works and
what doesn't, not why. In the same way as you don't need to know all the
details of how an instruction is processed at the lower level in the cpu
except for the aspects that may influence that processing (status of
other registers and so on).
You do not need to know how physically a CPU is built, and prove of that
is the fact that emulators work, and different implementations too.

You are trying to get beyond that boundary and claiming that software
for an x86 CPU is not free if you do not know how the circuitry is
built.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York