Choose a template
Monday, December 29. 2008
Posted by Neil Williams in Debian
Defined tags for this entry: Debian
So the failings of the GR result in just what everyone didn't need - a restarted discussion about the firmware issue without first releasing Lenny. Come on people, leave it alone and get Lenny done. Anthony, Thomas and Theodore (also in his blog) all seem to be missing the point(s):
To me, it's more like data for the chips - it's saying "this is who you are, this is what you do and this is how to understand all subsequent instructions". Software is what follows - the instructions themselves.
We have a very good understanding of the separation between software and data in userspace - we all recognise that unless the output of a program consists to a large extent of modified versions of already licensed code (e.g. code generators), then the data created by your free software GPL-3+ text editor (or blogging client) cannot be deemed to be under the GPL-3+ or any other licence until such a statement is made by the copyright holder and that the copyright holder is the user of the software, not the author of the software. I could quite easily put this blog under a Microsoft-style EULA or even NDA if I wanted to be obtuse, despite it being created using a free software stack. The point remains - I am the copyright holder of the content created using the free software on my machines and I am free to publish that data as I see fit. The authors of the software itself have no rights to dictate what I do with the content I create using the software, just as I - as a user - cannot dictate whether the authors of my editor choose to migrate from GPL-2+ to GPL-3+ or even BSD.
Where firmware can have source code, let it have source code - we have such packages in Debian already. Even then, much of the code may be simply calculations or conditionals to select the right combination of binary flags for specific situations. This isn't about Nvidia kernel drivers that do real runtime calculations during the entire runtime of the machine, this is about tiny bits of initialisation data that are set once and not touched again. Can we not accept that some firmware is derived from a process that does not involve source code? How about experimentation and calculation? We know the voltage on pins 5 and 19, we know the state of register A and that for this specific case, it needs to be toggled to match the state of register E because otherwise another chip on the same board gets confused, so setup the chip to do that by setting a firmware datum point to initialise A? Where's the source code in that process? There is none - it is a piece of data, an item in the design notes (or more likely the errata). Yes, maybe the chip should know how to set this datum itself but for whatever reason (probably financial), it doesn't.
Source code could be used to calculate the datum point for a range of chips and chipsets according to a range of data inputs but the creative effort is then in the calculation not the data. The chip doesn't want the calculation, it cannot perform a calculation in this uninitialised state, it needs the datum point. Once it has the registers set, it can then understand subsequent instructions - the software itself. The datum point itself is just a raw piece of initialisation junk for the chip, it has no source code, it is determined by a physical process. It is a reference point - a fixed value that is determined during the design of the chip and/or chipset.
It's like saying you want the source code that determines whether there are one hundred cents in a Euro so that you could modify it to create a thousand or just ten or maybe turn the Euro into a hexadecimal currency. Weird. The fact that the Euro has one hundred sub-divisions is not up for negotiation, it isn't a modifiable value - changing the value unilaterally is not going to magically make everyone use the new value. It is a fixed reference point - a single datum point that initialises all subsequent behaviour of all software utilising such a currency. Even if there was source code (gee, what could that be, do you think? "%.2i" ?) it would be meaningless to insist on being able to modify it.
Few people can make the judgement about whether particular firmware can or cannot have source code - in most cases it comes down to the hardware design of either just the chip or how the chip is utilised for a particular board.
At some point, Debian has to accept that we cannot know if source code was used to create a particular blob. We simply have to ensure that maintainers ask upstream, elucidate as much information as possible about how the firmware was created and document that in debian/copyright. If that information is proved to be incorrect, then we have to deal with it as best we can - on a package-by-package basis. The assumption has to be that firmware does not necessarily have any source code.
In the end, I think the GR came up with the right result, despite all the failings - Option 5, assume that firmware is compliant with the GPL unless there is evidence to the contrary.
Sometimes, there simply is no source code - sometimes all you have is data.
Debian cannot insist on source code for data that is not generated from source code and it is the difficulty in deciding whether one set of figures is initialisation data or a set of compiled instructions that will defeat all debate on a general solution for the firmware debate. It is comparing apples and oranges - we can insist on source code where source code was used but we also have to accept that some firmware is identified, not programmed. In the end, Debian will have to trust the maintainer and the maintainer will have to trust upstream. Documenting that in debian/copyright seems to be the only sane option.
Now can we all just shut up and release Lenny? Please?
Display comments as (Linear | Threaded)
I'm not agree with you. Firmware is code, probably assambler, but code. The problem is always the same, in a pc (normally) there is no need to upgrade the bios, and the hardware with a piece of software needed to run the hardware is in there. Why the firmware is not in the wifi card? Easy, a cd costs a few cents a more complicated hardware implementation cost a few cents more.
That decision  is a mistake, like most of the others. The way is keeping out the firmware, but making easy it's installation. You can say that without internet we can't download the firmware for the wifi card, ok, we must have a cd with windows drivers and the firmware in it...
No, *SOME* firmware is code, not all. Sometimes there is no assembly code, no source code, nothing, nada. The problem is different in different situations and the term "firmware" covers more than just what you describe. This isn't about the BIOS, it's about one chip talking to another on the same board. The firmware is not on the card primarily for cost reasons, it's cheaper to use firmware to get around hardware bugs than to redesign the board. WiFi cards are misleading because there is firmware in those that generally does involve source code and which does require some computation at runtime but the term firmware itself encompasses more than just WiFi firmware and covers initialisation junk that is raw data and nothing else.
Sometimes, there simply is no source code - sometimes all you have is data.
Not all firmware is like that but just as importantly, not all firmware can *EVER* have source code. Some firmware is simply data.
Yes, the firmware is not in the board because of costs reason, I told you so, and the bios reference was an example of a firmware that it's inside the hardware, nothing else.
Ok, I'm gonna suppose that the firmware it's only data... But there's a long way from using that data, and including it without knowing if the company that owns that data will break our ass in a future. I'm still thinking that it's not the solution. Perhaps ubuntu had included a lot of them and no one have put a demand on canonical, but that's not the way. Debian is not fighting for a piece of the OS's cake, Debian tries to make an universal OS, and if exists a way to not include that piece of data, and leave possible problems behind, why don't we take it?
There is no creative effort in generating the data, it is an initialisation. This isn't an image or a novel or some other creative effort, it is a piece of raw data, without which the chip cannot initialise itself. It can't be patented or restricted.
The fact that a currency has a hundred sub-divisions is not something that can be copyrighted or patented or restricted and nobody can sue for revealing that piece of data, nobody can be prevented from using the bit of data. There is no reason to exclude it because it is merely a piece of data - it is not a modifiable variable, it is a datum point. Without that datum, use of the currency becomes completely impossible - same with initialisation firmware.
It cannot be left out, it cannot be taken away from anyone, it just is. It remains valid for every situation involving that particular currency (or in this case, one specific combination of chips).
It is not about removing firmware for the sake of paranoia about law suits etc. It is about defining firmware in such a way that allows for the real firmware that already exists. Not all firmware is software. The insistence on treating the firmware issue as black and white is a complete farce. It is just impossible to classify all firmware as software, it bends the truth to the point of breakage.
If there really is no source code, the firmware cannot be automatically excluded, an individual assessment has to be made about whether the firmware would have actually required source code in the first place. That is what Option5 allows - that firmware includes such things as non-modifiable datum points that are not copyrighted (or even copyrightable) and simply need to be considered as raw data.
It makes no sense to say that all currencies are non-free and that every finance program in FOSS must stop using currencies merely because the currency fractions are non-modifiable. The fractions are non-modifiable because modifying them makes no sense.
Free software is restricted to what can be covered by a copyright licence - non-modifiable datum points are not covered by such licences and as firmware includes such datum points, firmware cannot be universally declared as subject to free software licences. In some cases, firmware simply does not qualify as software and an allowance *must* be made for this reality.
I don't want you to waste more time in that discussion, I understand what you expose but let me doubt about the rightness of taking that data, and include it debian, and not from a moral way or nonsenses like that. I mean, you seem pretty sure that there's no problem, because this data cannot be patented or restricted, but this isn't my case, that's all.
In other words, I'm agree with you, but let me doubt if lawyers and other wild animals, think in the same way...