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. > 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. 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. 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? > 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. > I do seriously wonder if you've ever seen real hardware documentation > in your live, as in datasheets, or the one one gets under NDA? I've ported GCC to a number of embedded platforms, having got hardware documentation for all of those processors. Matsushita AM33/2.0, Renesas SH5, ARM platforms such as Maverick and Intel Xscale, in addition to having done some additional compiler, assembler and linker work for platforms such as Fujitsu FR-V, Renesas H8SX. So, yes, I've seen my share of datasheets. Not video cameras, though. I don't even own a webcam. Any further questions? > Often the official docs contains tables with initialization values > like this, 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. 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. > So although those numbers are taken from the windows driver (I think), Is there permission to do so and release that under the GPL? > 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. > 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". > If you look at the docs there is no reason to do things in this order, > but the actual hardware gets very upset (as in doesn't work) if you > change the order. There are most likely other orders as the one which > is currently used which may work too. But the current one works, as > has been determined by trial and error. This sounds fine to me. > Luckily Jeff seems to more down to earth then you on this, I don't think you can draw this conclusion from this conversation. I didn't even issue an opinion on that particular driver in the first place. -- Alexandre Oliva http://www.lsd.ic.unicamp.br/~oliva/ FSF Latin America Board Member http://www.fsfla.org/ Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org} Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org} -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
