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@xxxxxx> 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 -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
