Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 29, 2006 at 03:07:11PM +0200, Sven Luther wrote: On Tue, Aug 29, 2006 at 11:00:44PM +1000, Hamish Moffatt wrote: To those who consider ROM-less hardware cheap and nasty I suggest the opposite is true. I design hardware (FPGAs) professionally for expensive communications equipment. We avoid ROMs as much as possible, because they are difficult to upgrade reliably and they are a waste of money. We deliberately load our FPGAs with different functionality at different times and that isn't possible from ROM. The emi62.c sound driver seems to do something similar - it loads different firmware for midi and spdif modes! Very interesting. Do you consider FPGA config files as programs, or would you say that the normal DFSG requirement for source applies to those also in order to be considered fit for debian/main ? Aren't these two alternatives the same? I am interested in your profesional opinion on this, since you clearly seem to either be, or in close contact to someone who is, an upstream author of such firmwares. In any case, they are not programs (there is no sequential operation, no program counters etc) but data that gets loaded into memory circuits (SRAM) inside the physical device. However they do have source code (Verilog and VHDL are the relevant languages). The hex dumps in the drivers are not only not the preferred form, they are in fact useless for modification. The vendors don't even publish the format of that information. There are no free tools for rebuilding those images, though that isn't an excuse in itself. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 30, 2006 at 12:13:32AM +0200, Sven Luther wrote: On Tue, Aug 29, 2006 at 10:07:55PM +0100, Mark Brown wrote: Speaking as someone with experience of the software rather than hardware side of this I'd call FPGA images hardware. From the point of view of working with it it looks very much like hardware. That's just my opinion, though. Well, but it is stuff with sources. You could argue that actual hardware also has sources (the design document, schematics and routing files) though. That's true, but software also has design documentation and we don't require that to be distributed to meet the DFSG. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Matthew Wilcox wrote: On Wed, Aug 23, 2006 at 02:44:48PM +0200, Sven Luther wrote: On Wed, Aug 23, 2006 at 06:08:08AM -0600, Matthew Wilcox wrote: I think the key distinction (as far as I'm concerned) is that Debian isn't producing a distribution for the microcontroller in my fibrechannel card, it's producing a distribution for my computer. In order to make my fibrechannel card work, it has to poke some bits in a documented way. Even if there happens to be an ARM onboard that card that's running a program, that ARM isn't running Debian. One of the purposes of having access to the prefered form of modification, is to be able to fix bugs. Certainly, it's one of the purposes. But I don't think we've *lost* anything by distributing binary firmware. Certainly not. That's what non-free is for, and I am in full support of distributing binary-only firmware in non-free. As long as it's properly licensed, which most of the stuff at issue isn't. :-/ Consider the cases: 1. Everything in hardware. You're not able to fix anything without a soldering iron ... and good luck to you with that. 2. Unmodifiable firmware in EEPROM. Need an EEPROM programmer, and a good deal of skill to fix anything. Again, best of luck. 3. Binary-only firmware in the driver. Slightly better chance of trying to figure out what's going on, but still low. 4. Firmware source in non-preferred form. Modifications probably possible, but when the next round of changes come out from the vendor, you probably have to ditch your mods. 5. Firmware source in preferred form. Can send changes back to vendor, everybody wins. (and I'm sure people can think of other finer distinctions). You seem to want to disallow cases 3 and 4 ... in main. Non-free exists for this. which makes sense from a here are the rules of data freedom, now i must follow them point of view, but really don't make sense to the vendor, nor to the user. It seems like an all-or-nothing approach. Well, if you don't realize that non-free exists to make exactly this compromise. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
MJ Ray wrote: I think the idea that refusing to ship non-free firmware in main will strengthen demand for free firmware is worthy of consideration. Debian helps users to take control of their operating system. Increasing the demand for free firmware might also help users to take control of their hardware, or at least highlight that there's this crap which their operating system uses to support their hardware but doesn't have its normal freedoms. However, I'm undecided whether it's a good idea to exclude them from the distribution CDs and so on. How big is the problem of vital hardware which won't work without firmware being copied to it? Complete list at http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html, with details. What that list does *not* show is that certain drivers only need firmware loaded for some of their supported cards. In the case of tg3, only a few rare (and old) cards actually need the firmware loaded. Should we split non-free into non-free-hardware and non-free, allowing non-free-hardware packages onto the CDs? Should we allow certain non-free material onto the installation CDs? Actually, that would be an compromise OK with me: the installation CDs only get used the once, and the material would be clearly separated out into the non-free section during and after installation. Doesn't address the legal issue of whether material without a proper distribution license should be included. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Matthew Garrett wrote: Bernhard R. Link [EMAIL PROTECTED] wrote: We are giving a promise here, that with the stuff in our distribution you have the freedom to use it, to give it to others and to fix it. This means the missing of legal obstacles and the possibility to do so. For this discussion preferred form of modification is perhaps not the best definition. It's good for licenses as it is not easily to work around. I think here the difference is between the source being in a form practical to edit or not. Without a practical form there is no possibility to change it. And this is a limitation we have to make clear to people and not lock them into by claiming all is good and well and it could be part of our free operating system. We never included non-free applications in main because we felt that there was no need to. And, indeed, even in 1993 it was possible to use a computer without any non-free applications. That doesn't hold with the firmware argument. With applications, we had the choice between Free but less functional and Non-free but more functional. With firmware we have the choice between Non-free but on disk and Non-free but in ROM. There isn't a Free option at all yet. Except for those cases where there is, such as adaptec, ser_a2232, ixp2000, wanxlfw, atmel, 53c700, 53c7xx, aic7xxx, sym53c8xx_2, and keyspan_pda. Yes, that includes a very common SCSI card and a very common NIC. So I think the real question is How does us refusing to ship non-free firmware help free software?. WE'RE NOT CONSIDERING DOING THAT. I hate to shout, but *have* you heard of non-free? It was mentioned in the post you're replying to! well, we are considering doing it in the cases where the firmware is *improperly licensed*. There, the benefit is (a) not getting sued and protecting downstream from liability, (b) clearly respecting copyright holders and respecting their stated desires. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 08:03:39PM +0100, Mark Brown wrote: Within a Debian context people normally seem to use the term firmware to mean any binary blob that gets programmed into hardware. This could include things like register settings or FPGA images as well as programs to execute on embedded processors. I'm not sure if there are any instances of these other types in the upstream kernel, though. FWIW (and a few days late) I did some searching for drivers in the kernel (2.6.17.11 from kernel.org) which refer to FPGAs and found the following: drivers/usb/atm/ueagle-atm.c drivers/media/video/bt8xx/bttv-cards.c sound/pci/vx222/* sound/pcmcia/vx/* sound/pci/pcxhr/* sound/pci/mixart/* sound/drivers/vc/* -- These load image via the standard kernel interface (hotplug) drivers/media/video/stradis.c drivers/net/wan/lmc/* -- Loads FPGA image supplied by an ioctl drivers/net/hamradio/yam.c -- Loads firmware from const arrays in yam*.h drivers/net/pcmcia/smc91c92_cs.c -- Loads firmware from const array in ositech.h drivers/usb/misc/emi26.c, emi62.c -- Loads firmware from const array in emi26_fw.h / emi62_fw*.h drivers/isdn/hardware/eicon/* -- Loads firmware from file directly (?) drivers/media/video/dabusb.c -- From file I think. Driver is confusing. arch/sh/boards/overdrive/fpga.c -- Loads from missing file To those who consider ROM-less hardware cheap and nasty I suggest the opposite is true. I design hardware (FPGAs) professionally for expensive communications equipment. We avoid ROMs as much as possible, because they are difficult to upgrade reliably and they are a waste of money. We deliberately load our FPGAs with different functionality at different times and that isn't possible from ROM. The emi62.c sound driver seems to do something similar - it loads different firmware for midi and spdif modes! Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 29, 2006 at 11:00:44PM +1000, Hamish Moffatt wrote: To those who consider ROM-less hardware cheap and nasty I suggest the opposite is true. I design hardware (FPGAs) professionally for expensive communications equipment. We avoid ROMs as much as possible, because they are difficult to upgrade reliably and they are a waste of money. We deliberately load our FPGAs with different functionality at different times and that isn't possible from ROM. The emi62.c sound driver seems to do something similar - it loads different firmware for midi and spdif modes! Very interesting. Do you consider FPGA config files as programs, or would you say that the normal DFSG requirement for source applies to those also in order to be considered fit for debian/main ? I am interested in your profesional opinion on this, since you clearly seem to either be, or in close contact to someone who is, an upstream author of such firmwares. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Steve Langasek [EMAIL PROTECTED] writes: If it's the latter, I maintain that this is precisely the subject matter of the proposed GR; we obviously *don't* have agreement in Debian over what should or should not be considered a program, so I think that's begging the question. However, your proposed amendment declares that firmware should not be considered a program. Can you please tell me what firmware is? I've seen a half dozen definitions tossed around recently, and I haven't a fig of a clue which one you mean: 1) A program which runs on a peripheral processor 2) A program which is distributed by the hardware manufacturer 3) A program which is controlled by the hardware manufacturer 4) A program which runs out of NVRAM or ROM instead of RAM 5) A program which, if you change it, voids the warranty for the hardware on which it runs, 6) A program which is necessary to support a piece of device hardware and for which we don't happen to have source I can't properly evaluate or think about this amendment while this rather crucial element remains unresolved. Also, it would seem very bizarre to say a program which ... is not really a program, so can you find a wording in which you don't define firmware as a particular sort of program, only to then declare that programs of that sort aren't really programs at all? Yes, these are reasonable definitions of both program and firmware. What is the definition of firmware which you are using? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 29, 2006 at 03:07:11PM +0200, Sven Luther wrote: On Tue, Aug 29, 2006 at 11:00:44PM +1000, Hamish Moffatt wrote: To those who consider ROM-less hardware cheap and nasty I suggest the opposite is true. I design hardware (FPGAs) professionally for expensive communications equipment. We avoid ROMs as much as possible, because they are difficult to upgrade reliably and they are a waste of money. Do you consider FPGA config files as programs, or would you say that the normal DFSG requirement for source applies to those also in order to be considered fit for debian/main ? I am interested in your profesional opinion on this, since you clearly seem to either be, or in close contact to someone who is, an upstream author of such firmwares. Speaking as someone with experience of the software rather than hardware side of this I'd call FPGA images hardware. From the point of view of working with it it looks very much like hardware. That's just my opinion, though. I'd also observe that newer FPGA chips often feature encryption support: the hardware has a secret key blown into it during manufacturing which must be used when building FPGA images to be loaded onto the hardware. -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 29, 2006 at 10:07:55PM +0100, Mark Brown wrote: On Tue, Aug 29, 2006 at 03:07:11PM +0200, Sven Luther wrote: On Tue, Aug 29, 2006 at 11:00:44PM +1000, Hamish Moffatt wrote: To those who consider ROM-less hardware cheap and nasty I suggest the opposite is true. I design hardware (FPGAs) professionally for expensive communications equipment. We avoid ROMs as much as possible, because they are difficult to upgrade reliably and they are a waste of money. Do you consider FPGA config files as programs, or would you say that the normal DFSG requirement for source applies to those also in order to be considered fit for debian/main ? I am interested in your profesional opinion on this, since you clearly seem to either be, or in close contact to someone who is, an upstream author of such firmwares. Speaking as someone with experience of the software rather than hardware side of this I'd call FPGA images hardware. From the point of view of working with it it looks very much like hardware. That's just my opinion, though. Well, but it is stuff with sources. You could argue that actual hardware also has sources (the design document, schematics and routing files) though. I'd also observe that newer FPGA chips often feature encryption support: the hardware has a secret key blown into it during manufacturing which must be used when building FPGA images to be loaded onto the hardware. Nice. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Manoj Srivastava wrote: On Tue, 22 Aug 2006 15:18:04 -0700, Steve Langasek [EMAIL PROTECTED] said: snip 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. This would require us to amend the foundation document of the DFSG, and define that what Debian defines as software program is different from the common definitions of the term In order for us to have a meaninglul foundation document, we can't debate and use our own special definitions of common terms, since the definition in turn uses words that can be defined in a special fashion. So, unless otherwise stated, the foundation document terms refer to commonly understood meanings of words; looking to dictionaries, encyclopedias, and common references. Calling firmware not programs is our own special definition of firmware, and or program, and hence must be defined explicitly in the DFSG. If we want to state that we only consider certain programs to be free, we ought to be upfront and clear about it in our foundation document. 110% in agreement with Manoj. Q: How many legs does a dog have, if you call the tail a leg? A: Four. Calling the tail a leg doesn't make it one. (Attributed to Abraham Lincoln.) I fail to see any way in which an executable MIPS binary is not a program, by any definition. If you want to amend the DFSG to state 3. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. However, this requirement does not apply to firmware, defined as insert your pet exemption here. I would strongly oppose such a change, but it would be a legitimate, reasonable GR (requiring 3:1 supermajority of course). In contrast, clause 4 of Steve Langasek's proposal is a backhanded and not very forthright way of trying to change the DFSG without changing them. Steve, you're better than this: please fix your proposal to do the straightforward thing. manoj -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Nathanael Nerode writes: If you want to amend the DFSG to state 3. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. However, this requirement does not apply to firmware, defined as insert your pet exemption here. I would strongly oppose such a change, but it would be a legitimate, reasonable GR (requiring 3:1 supermajority of course). Recent history -- in particular, GR 2006-001's winning option -- suggests that broad DFSG exemptions, when treated as clarifications or interpretations of the project, are not necessarily so clear-cut about requiring a 3:1 supermajority. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Mon, Aug 28, 2006 at 10:02:35PM -0400, Michael Poole wrote: Recent history -- in particular, GR 2006-001's winning option -- suggests that broad DFSG exemptions, when treated as clarifications or interpretations of the project, are not necessarily so clear-cut about requiring a 3:1 supermajority. Note that the winning option of that GR (GFDL-licensed works without unmodifiable sections are free) did in fact achieve a 3:1 supermajority, even though it was not required to. For comparison, the other options did not achieve a 3:1 supermajority. The first option, GFDL-licensed works are unsuitable for main in all cases, came close to, but didn't achieve a 2:1 supermajority, while the third option, GFDL-licensed works are compatible with the DFSG, didn't achieve a simple majority, let alone the 3:1 supermajority required of it. http://www.debian.org/vote/2006/vote_001 Cheers, aj signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
Joe Smith wrote: Anthony Towns aj@azure.humbug.org.au wrote in message news:[EMAIL PROTECTED] The middle one's the one of interest, it's expressed in the first point of the social contract as: We will never make the system require the use of a non-free component. (For reference, that replaced the following text from v1.0 of the social contract: [...] we will never make the system depend on an item of non-free software. ) [blink]! Clearly we cannot possibly be upholding that statement. There is simply no computer of fully free hardware and software. Even if there were, I'm betting Debian would require extensive modifications to run on it. I was hoping at one time to propose a GR to weaken it. However, I wanted to get the clarifications to the SC, which were not supposed to change its meaning, through, before we started proposing changes which actually *did* deliberately change its meaning That was clearly a poor change of wording, although it was likely not noticed because nobody was thinking gardware when they read that. True. Unfortunately, Debian was never exactly upholding the original version either; it was also bad wording. The accidental change there isn't really much of a change because of this. The place where they might mean different things is the case of chip designs, non-programmable ROM contents, and stuff like that. But as of today, every piece of hardware which runs the Debian system includes some non-free software (loadable 'firmware') anyway: usually the BIOS at a minimum. Although the ARM NSLU2 projects may be changing this situation. (As for chip designs, if Debian ever got ported to OpenSparc, that is free hardware; frankly it seems that the chip designs are opening up at least as fast as the BIOSes, so I don't see any real loss in this change.) Anyway, my plan was to weaken it to state something vaguely like: We will never make the system require the use of a non-free component, except for those components which are shipped as part of the hardware the system runs on (such as the BIOS). We will strive to make the system not require those components either, by supporting free alternatives as they develop. IANADD. IANAL. Neither am I. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Manoj Srivastava wrote: Indeed, all the references I have found tell me that firmware is computer programs. Interesting, as I note that *none* of those you quoted do so -- although some do say that it is software that is stored in less-volatile storage than RAM. Given the scale of the discussion that we had about the definition of software, I think it's probably unwise to equate it to programs in this situation! Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 05:38:07PM +1000, Anthony Towns wrote: On Wed, Aug 23, 2006 at 01:28:35AM -0500, Peter Samuelson wrote: [Steve Langasek] That's an interesting point. Can you elaborate on how you see this being a loophole, in a sense that having the firmware on a ROM wouldn't also be? The day Debian begins to distribute ROM chips, or devices containing ROM chips, I will expect those chips to come with source code. Until then, this is a red herring. Note that while Peter is currently in the n-m queue (on hold pending further response to TS checks apparently), he's not yet a developer, and his expectations shouldn't be inferred to be those of the developers as a whole. Well, I hereby fully agree with Peter's expectations. And I am a DD. Please don't dismiss people just on grounds that they're not, yet, DD's. Regards: David -- /) David Weinehall [EMAIL PROTECTED] /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
[Matthew Garrett] The biggest area which is likely to bite us is with network cards, though we'll probably lose some degree of SCSI support as well. Fortunately, at least with SCSI, users have a choice. They can buy Adaptec or LSI 53c* and they get _truly free_ firmware (in the case of Adaptec, the kernel includes firmware source and a matching assembler; for LSI, the firmware is augmented with byte-code scripts apparently assembled by the driver at runtime). Perhaps coincidentally, between aic7xxx, aic79xx and sym53c8xx_2, the most popular commodify SCSI chips are covered. (Well, there's the megaraid family, but those don't _appear_ to need to load firmware at runtime either.) Incidentally, the aic7xxx / aic79xx drivers in particular are a great thing to point out to people who are inclined to be lenient toward vendors on the theory that it is inherently not practical for them to ship open source firmware for their devices. Adaptec figured out how to do this a _long_ time ago: $Id: aic7xxx.reg,v 1.4 1997/06/27 19:38:39 gibbs Exp $ $Id: aic7xxx.seq,v 1.77 1998/06/28 02:58:57 gibbs Exp $ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 24, 2006 at 08:30:23AM +0200, Sven Luther wrote: he doesn't use the leader@ address even on issues related to his DPL role, as i well know, so this is no guarantee. AFAICT, he always signs those mails with DPL in the signature. Plus, at least in this thread, he did use [EMAIL PROTECTED] Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, 23 Aug 2006 16:23:20 -0700, Steve Langasek [EMAIL PROTECTED] said:
As you and I discussed previously on IRC, I don't agree with this
amendment. The premise of my proposal is that we are *not* granting
an exception nor redefining any terms, we are merely recognizing a
latent definition of programs that has guided Debian since its
inception in spite of standing in contrast to the dictionary
definition of the word. If I felt that we were actually redefining
terms at this juncture, I would wholeheartedly agree with Manoj that
it should be done by modifying the DFSG with a 3:1 supermajority.
And it seems to me that your proposed amendment falls on the other
side of this line, where you would have us define program to mean
one thing now and something else later.
It may be that this discussion will lead me to the conclusion that
the distinction between stating what our definition of 'program'
is and redefining 'program' is too subtle, in which case I expect
that I'll go for an amendment to the DFSG instead.
It is not just a dictionary definition. Let me see if I can
drive this point home. I have looked at text books, encyclopedias,
references in the IEEE and ACM digital libraries, and various
glossaries and dictionaries of computer and electronic terms. I
personally would consider Computer Organization Design: The
hardware /software interface by David A. Patterson and John
L. Hennessey authoritative in this area.
It is not as if the term is not well understood and fairly
rigorously defined in the texts, literature and media out there --
and redefining it by using a latent definition is indeed like
redefining what words mean in order to meet our convenience.
What would it take to convince the proponents of this position
that the term is ill-defined or vacuous enough to require further
(and wildly different) definition by the project?
Indeed, all the references I have found tell me that firmware
is computer programs. The only confusion I have ever seen is in
Debian fora linked to a discussion in which comeone is trying to
continue to inject such source-less computer programs in main --
which makes me wonder about the depth of such confusion.
If Debian chooses to use words in its foundation documents
which is privately re-defines to be at odds with the general and
commonly accepted meaning of the term, and does not explicitly insert
the private special definition into the foundation document, I
consider it deceptive, unethical, and putting a lie to the social
contract.
I mean, if Debian can today define program to mean not
firmware, despite what all references say, what is to prevent it
from redefining it privately tomorrow to say anything not written by
microsoft, since that isn't programs, but crap? and ship the freely
distributable but non-free crap in main, since they are not programs?
(Yes, this example is a little over the top, but not a whole
lot. If we are redefining common words, let us have the honesty to
put in our definition where we use it in the foundation documents).
manoj
Computer Organization Design: The hardware /software interface,
David A. Patterson and John L. Hennessey, pp 424-425, talking about
how firmware is programming instructions interpreted by the FSM
controller (ie computer code interpreted by a micrprocessor inside
the MIPS CPU itself -- so the CPU distinction is void).
Encyclopedias: Wikipedia says it unequivocally:
http://en.wikipedia.org/wiki/Firmware
In computing, firmware is software that is embedded in a hardware
device. It is often provided on flash ROMs or as a binary image file
that can be uploaded onto existing hardware by a user.
Gazillions of Glossaries:
Google for define: firmware
And yes, the dictionaries:
From The Free On-line Dictionary of Computing (19 Sep 2003) [foldoc]:
Firmware
Software stored in read-only memory (ROM) or programmable ROM
(PROM). Easier to change than hardware but harder than
software stored on disk. Firmware is often responsible for
the behaviour of a system when it is first switched on. A
typical example would be a monitor program in a
microcomputer which loads the full operating system from disk
or from a network and then passes control to it.
From WordNet (r) 2.0 (August 2003) [wn]:
firmware
n : (computer science) coded instructions that are stored
permanently in read-only memory [syn: {microcode}]
The Jargon file: Embedded software contained in EPROM or flash
memory.
--
Did you hear that two rabbits escaped from the zoo and so far they
have only recaptured 116 of them?
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, 23 Aug 2006 06:08:08 -0600, Matthew Wilcox [EMAIL PROTECTED] said: Manoj wrote: Actually, I disagree, and, even worse, so does the common definition of the phrase computer program: asking google about define: computer program gives: , | * A computer program is a set of statements or instructions to be | used directly or indirectly in a computer in order to bring | about a certain result. | www.tms.org/pubs/journals/JOM/matters/matters-9710.html But Debian has a tradition of ignoring the common definition of phrases. Have you tried asking google to define software, for example? Yes. There the answer is not so clear cut: I get # Programs, procedures, rules, and any associated documentation # pertaining to the operation of a system. Contrast with hardware # (page ***). publib16.boulder.ibm.com/doc_link/en_US/a_doc_lib/aixins/insgdrf/glossary.htm # Generally, programs loaded into a computer from external mass # storage but also extended to include operating systems and # documentation. www.flw.com/define_s.htm as well as: # Coded instructions (programs) that make a computer do useful work. www.krollontrack.com/legalresources/glossary.asp # The programs that tell the computer what to do. www.esls.lib.wi.us/glossary.html So, there is clearly a lack of uniform consensus there; and when it was brought to our notice, we used an editorial change to the foundation documents to disambiguate; why are we not doing the same now? manoj -- I don't wanna argue, and I don't wanna fight, But there will definitely be a party tonight... Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Joe Smith [EMAIL PROTECTED] writes: Anthony Towns aj@azure.humbug.org.au wrote in message news:[EMAIL PROTECTED] The middle one's the one of interest, it's expressed in the first point of the social contract as: We will never make the system require the use of a non-free component. (For reference, that replaced the following text from v1.0 of the social contract: [...] we will never make the system depend on an item of non-free software. ) [blink]! Clearly we cannot possibly be upholding that statement. There is simply no computer of fully free hardware and software. Even if there were, I'm betting Debian would require extensive modifications to run on it. In my view the unavalability of a free alternative does not create a dependency on a non-free component. Only if Debian would require a specific non-free BIOS for example I would regard that as a dependency. That your hardware (or mine) requires a BIOS (or firmware) for which there is no free alternative does not make Debian depend on it, IMHO. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
[Steve Langasek] That's an interesting point. Can you elaborate on how you see this being a loophole, in a sense that having the firmware on a ROM wouldn't also be? The day Debian begins to distribute ROM chips, or devices containing ROM chips, I will expect those chips to come with source code. Until then, this is a red herring. signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 01:28:35AM -0500, Peter Samuelson wrote: [Steve Langasek] That's an interesting point. Can you elaborate on how you see this being a loophole, in a sense that having the firmware on a ROM wouldn't also be? The day Debian begins to distribute ROM chips, or devices containing ROM chips, I will expect those chips to come with source code. Until then, this is a red herring. Note that while Peter is currently in the n-m queue (on hold pending further response to TS checks apparently), he's not yet a developer, and his expectations shouldn't be inferred to be those of the developers as a whole. Working out whether those expectations match those of the developers as a whole is what this GR -- and the discussion preceeding it -- is about. I'd strongly discourage people who participate in the discussion (whether you've run the n-m gauntlet or not) from dismissing developers' concerns about this as a red herring: if you're right, you shouldn't be afraid to discuss the reasons why you're right in detail when asked. Cheers, aj signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 05:38:07PM +1000, Anthony Towns wrote: On Wed, Aug 23, 2006 at 01:28:35AM -0500, Peter Samuelson wrote: [Steve Langasek] That's an interesting point. Can you elaborate on how you see this being a loophole, in a sense that having the firmware on a ROM wouldn't also be? The day Debian begins to distribute ROM chips, or devices containing ROM chips, I will expect those chips to come with source code. Until then, this is a red herring. Note that while Peter is currently in the n-m queue (on hold pending further response to TS checks apparently), he's not yet a developer, and his expectations shouldn't be inferred to be those of the developers as a whole. Working out whether those expectations match those of the developers as a whole is what this GR -- and the discussion preceeding it -- is about. I'd strongly discourage people who participate in the discussion (whether you've run the n-m gauntlet or not) from dismissing developers' concerns about this as a red herring: if you're right, you shouldn't be afraid to discuss the reasons why you're right in detail when asked. This is a commonly held believe, that many DDs have already used in the past, and seems quite common sense to me : - a firmware hold in a rom or flash is in no way different that a firmware hold in a driver binary, as far as DFSG and freeness goes, both are usually non-free. - debian doesn't ship hardware, so the DFSG can hardly apply to some random piece of hardware that the user may have, as it could not apply to let's say a copy of the microsoft-office program a user or DD may have on the same harddisk he installs debian on. To add to that, if i where Peter, i may feel slightly offended by the tone of your reply as well as the content of it. You are the DPL, and as thus speak with the authority given by the whole project, and i think you should as such be a more careful in your wording. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Le mercredi 23 août 2006 à 17:38 +1000, Anthony Towns a écrit : Note that while Peter is currently in the n-m queue (on hold pending further response to TS checks apparently), he's not yet a developer, and his expectations shouldn't be inferred to be those of the developers as a whole. And again, contempt before discussion. If you don't want the debate to be public, you should ask the rules to be changed so that they are held on a moderated mailing list. Otherwise, the rule is that anyone is free to contribute to the discussion. You are the project leader, and as such your are partly responsible for the image of the project. I don't want (and I hope I'm not the only one) the project to be associated with your deliberately obnoxious behaviour. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 05:38:07PM +1000, Anthony Towns wrote: Note that while Peter is currently in the n-m queue (on hold pending further response to TS checks apparently), he's not yet a developer, and his expectations shouldn't be inferred to be those of the developers as a whole. Working out whether those expectations match those of the developers as a whole is what this GR -- and the discussion preceeding it -- is about. I'd strongly discourage people who participate in the discussion (whether you've run the n-m gauntlet or not) from dismissing developers' concerns about this as a red herring: if you're right, you shouldn't be afraid to discuss the reasons why you're right in detail when asked. On Wed, Aug 23, 2006 at 09:56:25AM +0200, Sven Luther wrote: To add to that, if i where Peter, i may feel slightly offended by the tone of your reply as well as the content of it. You are the DPL, and as thus speak with the authority given by the whole project, and i think you should as such be a more careful in your wording. I was entirely careful in my wording. Peter is in the n-m queue, he isn't a developer, and while he has every right to his personal views, as do you and as do I, those views don't necessarily match those of the majority of other developers or the project as a whole, and we should be very careful not to accidently quash discussion of other points of view by being so vehement in our own views that other people don't think their view is welcome. On Wed, Aug 23, 2006 at 10:28:03AM +0200, Josselin Mouette wrote: And again, contempt before discussion. If you don't want the debate to be public, you should ask the rules to be changed so that they are held on a moderated mailing list. Otherwise, the rule is that anyone is free to contribute to the discussion. Indeed, and I specifically pointed that out in my mail. I hope you agree that I'm also free to participate and point out Peter's participation in the project isn't what people might assume from the authority with which he imbues his views, if I think that's valuable. People posting to Debian lists should be doing so on the strengths of their arguments -- and if they are doing so, pointing out that they're not a maintainer should have absolutely no effect on the success of their arguments. If it emboldens developers to post about their opinions even when they disagree with what appears to be consensus, then that will only help avoid misunderstanding their views in future: because at the end of the day it's the developers' views that determine Debian's view, not any one else's. You are the project leader, and as such your are partly responsible for the image of the project. I don't want (and I hope I'm not the only one) the project to be associated with your deliberately obnoxious behaviour. Then I would suggest you debate the issue on its merits, rather than making the topic of debate be your views on my character. If you believe a comment on a list has no merit, it's very easy to deal with it: just ignore it, and go on discussing the ideas that are worth discussing. Cheers, aj signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 05:38:07PM +1000, Anthony Towns wrote: On Wed, Aug 23, 2006 at 01:28:35AM -0500, Peter Samuelson wrote: [Steve Langasek] That's an interesting point. Can you elaborate on how you see this being a loophole, in a sense that having the firmware on a ROM wouldn't also be? The day Debian begins to distribute ROM chips, or devices containing ROM chips, I will expect those chips to come with source code. Until then, this is a red herring. Note that while Peter is currently in the n-m queue (on hold pending further response to TS checks apparently), he's not yet a developer, and his expectations shouldn't be inferred to be those of the developers as a whole. Interesting, is this why the discussion is on a public mailing list? Personally I am not a DD either nor am I in the NM queu, however I was always under the impression that my opinion as a users matters (and should matter IMHO) to Debian anyway. In contrast to Sven and Josselin I'm not going to blame you for doing this statement as DPL as your From: address did not say so. But otherwise I wholehartedly agree with them. As for the issue at hand here I must also agree with Peter and Sven: Debian doesn't distribute chips with non-free firmware currently. So if Debian wants to distribute non-free binary-only firmware I do hope it will do so in non-free and not in main. Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Le mercredi 23 août 2006 à 19:19 +1000, Anthony Towns a écrit : If you believe a comment on a list has no merit, it's very easy to deal with it: just ignore it, and go on discussing the ideas that are worth discussing. Why would I do that, when you are taking the opposite way? When you believe a commend on a list has no merit, you explicitly ask other people to ignore it, based on a stupid DD/non-DD segregation instead of the merits of the comment. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Proposal: The DFSG do not require source code for data, including firmware
Why would I do that, when you are taking the opposite way? When you believe a commend on a list has no merit, you explicitly ask other people to ignore it, based on a stupid DD/non-DD segregation instead of the merits of the comment. This is not my understanding of aj's comment, Josselin. He did not ask to *ignore* Peter's comment, but only to remind that, Peter not being a DD, the comment can't be told to reflect the DD community opinion. Yes, I'm not completely sure that aj's comment was appropriate but I don't put in it the interpretation you seem to put (awful English, sorry, folks). signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 07:19:24PM +1000, Anthony Towns wrote: On Wed, Aug 23, 2006 at 05:38:07PM +1000, Anthony Towns wrote: Note that while Peter is currently in the n-m queue (on hold pending further response to TS checks apparently), he's not yet a developer, and his expectations shouldn't be inferred to be those of the developers as a whole. Working out whether those expectations match those of the developers as a whole is what this GR -- and the discussion preceeding it -- is about. I'd strongly discourage people who participate in the discussion (whether you've run the n-m gauntlet or not) from dismissing developers' concerns about this as a red herring: if you're right, you shouldn't be afraid to discuss the reasons why you're right in detail when asked. On Wed, Aug 23, 2006 at 09:56:25AM +0200, Sven Luther wrote: To add to that, if i where Peter, i may feel slightly offended by the tone of your reply as well as the content of it. You are the DPL, and as thus speak with the authority given by the whole project, and i think you should as such be a more careful in your wording. I was entirely careful in my wording. Peter is in the n-m queue, he isn't a developer, and while he has every right to his personal views, as do you and as do I, those views don't necessarily match those of the majority of other developers or the project as a whole, and we should Well, the only one who could claim that his views have some representativity of the project as a whole is you, everyone else is just expressing his own opinion, be he a DD or a guy from NM or some random poster. be very careful not to accidently quash discussion of other points of view by being so vehement in our own views that other people don't think their view is welcome. Well. do we chip hardare, and as thus have the content of their ROMs covered by the DFSG ? I am not aware of such a situation, and altough Peter may have not said it in the best way, remember that for all those non-native english speakers there is a language barrier there, which may not be visible immediately, but which causes choice of non-perfectly-adequate wordings because of lack of vocabulary, or missing the subltetlies of various wording possibilities and misjudging the strength of them. You on the other side don't have this excuse :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 12:16:22PM +0200, Christian Perrier wrote: Why would I do that, when you are taking the opposite way? When you believe a commend on a list has no merit, you explicitly ask other people to ignore it, based on a stupid DD/non-DD segregation instead of the merits of the comment. This is not my understanding of aj's comment, Josselin. He did not ask to *ignore* Peter's comment, but only to remind that, Peter not being a DD, the comment can't be told to reflect the DD community opinion. No, but he blamed Peter for participating in the conversation because he was not yet a DD. I doubt that any DD's personal opinion here except aj's would be more representative of the DD community opinion. Yes, I'm not completely sure that aj's comment was appropriate but I don't put in it the interpretation you seem to put (awful English, sorry, folks). Maybe it is not best for us non-english speaker to comment on the content of aj's post, but i am happy that i am was not the only reacting to it. Maybe it is something french people are more sensible too, as both you, me and Josselin are all french-speakers. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
No, but he blamed Peter for participating in the conversation because he was That's not my understanding of aj's post. From my point of view, he did not blame Peter. He didn't even address him directly. Maybe it is not best for us non-english speaker to comment on the content of aj's post, but i am happy that i am was not the only reacting to it. Maybe it is something french people are more sensible too, as both you, me and Josselin are all french-speakers. Uh, such statement would likely reinforce the common perception that those French dudes really suck at speaking English..:-) signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
Le mer 23 août 2006 12:16, Christian Perrier a écrit : Why would I do that, when you are taking the opposite way? When you believe a commend on a list has no merit, you explicitly ask other people to ignore it, based on a stupid DD/non-DD segregation instead of the merits of the comment. This is not my understanding of aj's comment, Josselin. He did not ask to *ignore* Peter's comment, but only to remind that, Peter not being a DD, the comment can't be told to reflect the DD community opinion. This is still how many people (me included) do perceive it. Moreover, the fact that the opinion that Peter expressed is widespread or not among the DDs is also irrelevant to the discussion. The discussion is about what options we have, and the the GR will be responsible to see which opinion is the most shared among the DD comunity. Until the vote, anybody can express his views opinions, even if it is a minority position ... that is what a public debate really is about. With that in mind, beeing a DD or not is a completely irrelevant information, and reminding is, whichever the original intention of that reminder was, is rude and inappropriate. That's not the first tham that aj does such reminders[1], and especiall beeing the DPL[2], I find that disturbing. Regards, [1] remember the ugly java thread ... [2] that does not mean that it's ok to do such remarks not beeing the DPL, it means that having such words as the DPL makes it worse. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp4FQdINokut.pgp Description: PGP signature
Re: Proposal: The DFSG do not require source code for data, including firmware
reminder was, is rude and inappropriate. That's not the first tham that aj does such reminders[1], and especiall beeing the DPL[2], I find that disturbing. Well, even being the DPL, aj is perfectly allowed to have personal opinions, even some that you (or me) may find irrelevant or wrong. As far as I know, Anthony did not yell out hey, I'm the boss here and here's the Boss opinion. This year we have a DPL who is very active in the ML, whether we like his opinions or not. I actually tend to like it but that's not a reason for me to take all posts by Anthony as the Speech from the Throne...:) signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 12:40:11PM +0200, Christian Perrier wrote: No, but he blamed Peter for participating in the conversation because he was That's not my understanding of aj's post. From my point of view, he did not blame Peter. He didn't even address him directly. well, its the end effect that count, and aj's word could be interpreted as : you are no DD, so your opinion doesn't count, and you should not give counterarguments to a DD. This is how i read it. Maybe it is not best for us non-english speaker to comment on the content of aj's post, but i am happy that i am was not the only reacting to it. Maybe it is something french people are more sensible too, as both you, me and Josselin are all french-speakers. Uh, such statement would likely reinforce the common perception that those French dudes really suck at speaking English..:-) I believe is more that the culture and structure of a given language make the speakers of said language more sensible to certain ways of turning the sentences or using certain words. For example, it seems clear that aj regarder the 'red hearing' word as pretty insulting to whoever it was Peter was replying to, to the point to make the commenthe made, while i found this just plain normal way of saying it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 12:32:46PM +0200, Sven Luther wrote: Well, the only one who could claim that his views have some representativity of the project as a whole is you, everyone else is just expressing his own opinion, be he a DD or a guy from NM or some random poster. Anyone can claim their views are representative of the project, and everyone -- including myself -- would be wrong to do so. The project has procedures for establishing its views on subjects: be that by package maintainers having opinions about their packages, discussions on mailing lists, setting policies, decisions by delegates, the technical committee or the project secretary, or having a vote about it. There are a few people who are authorised to speak on behalf of the project, including myself, Steve McIntyre as 2IC [0], and Joey Schulze as press officer. But none of those people get to cast their own views as the project's -- they simply have been entrusted by the project through the appropriate means to put the project's views into words. But Peter wasn't claiming that his views were the project's by any means -- he simply stated them in a way that, in my opinion, is easily mistaken for a statement of a pre-existing consensus on behalf of the project. There is no such consensus, however -- if there were, there would have been no one to raise this GR in the first place -- and this process of discussion and voting is how the project forms its opinion on the subject, which may well end up being entirely different to Peter's opinion, or yours, or mine. Well. do we chip hardare, and as thus have the content of their ROMs covered by the DFSG ? We choose to apply the DFSG both to the components that the Debian system requires, and to what we use to provide debian.org services. It can be reasonably argued that non-free firmware encoded in ROMs is involved in both cases. I'm reluctant to argue for or against either of those, since I don't know what the project's view on these things is or will be, and I don't want anyone to be confused into thinking that my personal view on this is the project's. I'm entirely comfortable in saying that it's an issue worth discussing though, because that's both my personal view and, in my opinion, the project's view. I am not aware of such a situation, and altough Peter may have not said it in the best way, remember that for all those non-native english speakers there is a language barrier there, [...] TTBOMK, and according to whois, Peter is US based, and a native speaker... Cheers, aj [0] http://lists.debian.org/debian-devel-announce/2006/04/msg00015.html signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 12:03:17PM +0200, Floris Bruynooghe wrote: On Wed, Aug 23, 2006 at 05:38:07PM +1000, Anthony Towns wrote: Note that while Peter is currently in the n-m queue (on hold pending further response to TS checks apparently), he's not yet a developer, and his expectations shouldn't be inferred to be those of the developers as a whole. Interesting, is this why the discussion is on a public mailing list? Personally I am not a DD either nor am I in the NM queu, however I was always under the impression that my opinion as a users matters (and should matter IMHO) to Debian anyway. Just to be clear: you're completely correct, users' opinions do matter, and the opinions of people in the new-maintainer queue are pretty much on a par with individual developers' opinions, except that they don't actually get counted when it comes time to tally the votes. Sometimes, some opinions won't be addressed because others will take precedence -- such as it'd be great if perl weren't essential not being addressed due to the complexity of doing so and the tradeoffs that would involve; but that doesn't mean the opinion isn't valued, or that it won't be addressed later if it becomes possible. I didn't say Peter's take didn't matter, because personally I consider it self-evident and unarguable that it does matter. The followup was only intended to make sure it was clear that it *was* Peter's take, and not necessarily the project's, and that debate is still appropriate. And *this* one I will sign as DPL. Cheers, aj -- Anthony Towns Debian Project Leader signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, 23 Aug 2006 17:38:07 +1000, Anthony Towns aj@azure.humbug.org.au said: On Wed, Aug 23, 2006 at 01:28:35AM -0500, Peter Samuelson wrote: [Steve Langasek] That's an interesting point. Can you elaborate on how you see this being a loophole, in a sense that having the firmware on a ROM wouldn't also be? The day Debian begins to distribute ROM chips, or devices containing ROM chips, I will expect those chips to come with source code. Until then, this is a red herring. Note that while Peter is currently in the n-m queue (on hold pending further response to TS checks apparently), he's not yet a developer, and his expectations shouldn't be inferred to be those of the developers as a whole. In that case, let me reiterate what Peter said -- and I have been a developer longer than you have, and I actually was around when the DFSG was crafted, so my expectations are not as easily dismissed as someone who has but recently joined our community. manoj -- Alas, I am dying beyond my means. Oscar Wilde [as he sipped champagne on his deathbed] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, 22 Aug 2006 22:23:29 -0700, Steve Langasek [EMAIL PROTECTED] said: On Tue, Aug 22, 2006 at 06:19:08PM -0500, Manoj Srivastava wrote: On Tue, 22 Aug 2006 15:18:04 -0700, Steve Langasek [EMAIL PROTECTED] said: Hi folks, Ever since the sarge release, an ongoing question has been: what do the DFSG require for works that are not programs as previously understood in Debian? Several rounds of general resolutions have now given us answers for some subclasses of non-program works, but debate still rages regarding one particularly important class: firmware for peripheral devices. Actually, I disagree What point are you disagreeing with? That there is debate about firmware in Debian? That the previous common understanding of programs in Debian did not include firmware? I am disagreeing that there is a genuine ambiguity. If it's the latter, I maintain that this is precisely the subject matter of the proposed GR; we obviously *don't* have agreement in Debian over what should or should not be considered a program, so I think that's begging the question. and, even worse, so does the common definition of the phrase computer program: If 55% of the voting developers in Debian don't agree with this common definition as pertains to the DFSG (which I doubt most laymen would agree with either where firmware is concerned), why do they need the consent of another 20% of the voters in order to proceed accordingly? This is like legislating the value of Pi not to be irrational -- I mean, rationality is to be prized, no? What is firmware, then? Speaking as en electrical engineer, I would say that firmware is just compiled binary programs that are meant to be executed by a processor (that often lives on the mainboard) which happens not to be the contral processing unit. Yes, these are reasonable definitions of both program and firmware. They're also not the ones that Debian has been operating under for most of its history; the previous version of the Social Contract said that Debian would remain 100% free software, and I don't think anyone will argue that there are programs which aren't software. So if firmware was already supposed to be covered under the DFSG, how is this reconciled with the fact that no one ever worried about firmware in Debian until the past couple of years? These are not just reasonable definitions -- they are the overwhelming majority of definitions found for the terms. I searched the digital libraries of the ACM and of the IEEE, and I have yet to come across any mention of firmware that does not concede that it is software programs -- perhaps software programs that are read off non-volatile memory, instead of magnetic fields on a hard-drive platter, but in either case the storage media is some kind of (semi) persistent elecro-magnetic field, and the stored instructions are acted upon by a processing unit. No textbook, no reference, no definition in dictionaries of electrical engineering, no online dictionaries, seem to be ambiguous or confused -- seems hard to imagine that people can be genuinely confused for long. It is easy enough to correct ones understanding of the term firmware with a little research. Now, I also understand the convenience factor -- it is vastly more convenient to just let this slide under the carpet, and let what is technically non-free under the DFSG into main by cleverly redefining words to suit -- the users want it, the hardware vendors want it, and the benefit of sticking to principles of freedom seem silly and appear to have little immediate benefit. But pretending that firmware definition is somehow ambiguous is Clintonian (it depends n what the meaning of the word 'is' is) in nature. Oh, as to why we still have non-DFSG material in main, well, cleansing a distribution the size of Debian takes time, and we have been working towards this goal -- and it is not so long ago that an editorial change to the SC clarified the meaning of the SC for some people. manoj -- Even the most boundless love can end. Rhett Butler, to Scarlet O'Hara, _Gone With The Wind_ Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
* Matthew Wilcox [EMAIL PROTECTED] [060823 15:46]: Certainly, it's one of the purposes. But I don't think we've *lost* anything by distributing binary firmware. Consider the cases: 1. Everything in hardware. You're not able to fix anything without a soldering iron ... and good luck to you with that. 2. Unmodifiable firmware in EEPROM. Need an EEPROM programmer, and a good deal of skill to fix anything. Again, best of luck. 3. Binary-only firmware in the driver. Slightly better chance of trying to figure out what's going on, but still low. 4. Firmware source in non-preferred form. Modifications probably possible, but when the next round of changes come out from the vendor, you probably have to ditch your mods. 5. Firmware source in preferred form. Can send changes back to vendor, everybody wins. (and I'm sure people can think of other finer distinctions). You seem to want to disallow cases 3 and 4 which makes sense from a here are the rules of data freedom, now i must follow them point of view, but really don't make sense to the vendor, nor to the user. It seems like an all-or-nothing approach. That's not different at all to normal programs. Perhaps it even becomes a bit clearer if you substitute 1) and 2) for programs with no software. Having non-free software is - for the very single developer and any seen locally[1] - better than having no program to do the task all together. We (Debian project) acknowledge the need of users and distribute such stuff in the non-free section in addition to our distribution, so that people are not locked into totaly non-free systems but only have to bear that much unfreeness as it necessary. We are giving a promise here, that with the stuff in our distribution you have the freedom to use it, to give it to others and to fix it. This means the missing of legal obstacles and the possibility to do so. For this discussion preferred form of modification is perhaps not the best definition. It's good for licenses as it is not easily to work around. I think here the difference is between the source being in a form practical to edit or not. Without a practical form there is no possibility to change it. And this is a limitation we have to make clear to people and not lock them into by claiming all is good and well and it could be part of our free operating system. Hochachtungsvoll, Bernhard R. Link [1] having no software at all increases the pain and makes it more likely someone writes something free, but for the single person that cannot write it, this is too far reached. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Manoj wrote: Actually, I disagree, and, even worse, so does the common definition of the phrase computer program: asking google about define: computer program gives: , | * A computer program is a set of statements or instructions to be | used directly or indirectly in a computer in order to bring | about a certain result. | www.tms.org/pubs/journals/JOM/matters/matters-9710.html But Debian has a tradition of ignoring the common definition of phrases. Have you tried asking google to define software, for example? I think the key distinction (as far as I'm concerned) is that Debian isn't producing a distribution for the microcontroller in my fibrechannel card, it's producing a distribution for my computer. In order to make my fibrechannel card work, it has to poke some bits in a documented way. Even if there happens to be an ARM onboard that card that's running a program, that ARM isn't running Debian. I second Steve's proposal (although I can't be bothered to go to the hassle of signing this message right now. If it becomes important to do so, I shall.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 09:24:16PM +1000, Anthony Towns wrote: On Wed, Aug 23, 2006 at 12:32:46PM +0200, Sven Luther wrote: Well, the only one who could claim that his views have some representativity of the project as a whole is you, everyone else is just expressing his own opinion, be he a DD or a guy from NM or some random poster. Anyone can claim their views are representative of the project, and everyone -- including myself -- would be wrong to do so. So, why do you denigrate Peter in such a way ? What you said could apply as well to you, no ? The project has procedures for establishing its views on subjects: be that by package maintainers having opinions about their packages, discussions on mailing lists, setting policies, decisions by delegates, the technical committee or the project secretary, or having a vote about it. There are a few people who are authorised to speak on behalf of the project, including myself, Steve McIntyre as 2IC [0], and Joey Schulze as press officer. But none of those people get to cast their own views as the project's -- they simply have been entrusted by the project through the appropriate means to put the project's views into words. Ok. But Peter wasn't claiming that his views were the project's by any means -- he simply stated them in a way that, in my opinion, is easily mistaken for a statement of a pre-existing consensus on behalf of the project. I guess he never said so, he just worded his argumentation in such a way, that he thought his position was comon sense. Also, since in the previous cases i was involved in the non-free firmware issue, many people chose to use the same argument, both in the debian-legal threads and elsewhere. There is no such consensus, however -- if there were, there would have blink There is no such consensus that debian doesn't chip hardware ? I think we don't need consensus, these are plain facts, and we even advertize them on our web site, so i think there is some major misunderstanding about this going on. been no one to raise this GR in the first place -- and this process of discussion and voting is how the project forms its opinion on the subject, which may well end up being entirely different to Peter's opinion, or yours, or mine. Indeed, so, why did you need to resort to such bass tactics as an ad-hominem attack on Peter using his non-DD status ? Well. do we chip hardare, and as thus have the content of their ROMs covered by the DFSG ? We choose to apply the DFSG both to the components that the Debian system requires, and to what we use to provide debian.org services. It can be reasonably argued that non-free firmware encoded in ROMs is involved in both cases. blink huh ? That would be the first time i hear anyone say this with a straigth face or really meaning it. If you would get look at the logs, i have used that same argumentation in the debian-legal thread last year, but with a proof-as-asburdum, or however it is called, way. If we where really going to argue this, we could just as well stop shiping debian, since there is no way to actually make use of any of the content we ship without some piece of non-free firmware, the first of it being the non-free bios you use on your system. I'm reluctant to argue for or against either of those, since I don't know what the project's view on these things is or will be, and I don't want anyone to be confused into thinking that my personal view on this is the project's. Maybe, but then you don't make statements as you did, going away from arguing about the non-free matter, and into polemics about if non-DDs are allowed to post and comment, or if they should show due respect to the venerable DDs and be silent, and not contradict one's better. I'm entirely comfortable in saying that it's an issue worth discussing though, because that's both my personal view and, in my opinion, the project's view. So ? How does that excuse the comment you made. This is completely irrelevant to the critic raised against your comment. I am not aware of such a situation, and altough Peter may have not said it in the best way, remember that for all those non-native english speakers there is a language barrier there, [...] TTBOMK, and according to whois, Peter is US based, and a native speaker... So much for that then. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 02:11:39PM +0200, Marco d'Itri wrote: [EMAIL PROTECTED] wrote: Why is freedom of software only important for the central processing unit, but immaterial for other processing usints? Who said it's not important? I believe it is, just that it's not a battle which should be pursued by Debian by not distributing sourceless firmwares. It is clear that by banning firmwares from Debian we harm our users (easily verifiable) much more than we help the cause of free software (it's hard to prove that it would be of any help, and the burden of proof lies on who supports it). Indeed, but would it not make more sense, to aknowledge that the firmware is non-free, and then argue that we should include it nonetheless, instead of making obviously false claims like firmware are not programs ? Si, am I silly and alone in thinking that firmware is binary computer programs? Let us ask google to define: firmware: You are silly in pretending that the DFSG and the widely shared consensus among developers always intended considering them non-free and inappropriate for main. The last of the three pre-sarge non-free GRs confirmed the fact that firmware is indeed a code binary, and should have source. A majority of the DDs voted that, and unless there is another GR reverting this, that opinion is binding to the project. That said, Steve's GR is not the most smart way to solve this issue. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 06:08:08AM -0600, Matthew Wilcox wrote: Manoj wrote: Actually, I disagree, and, even worse, so does the common definition of the phrase computer program: asking google about define: computer program gives: , | * A computer program is a set of statements or instructions to be | used directly or indirectly in a computer in order to bring | about a certain result. | www.tms.org/pubs/journals/JOM/matters/matters-9710.html But Debian has a tradition of ignoring the common definition of phrases. Have you tried asking google to define software, for example? I think the key distinction (as far as I'm concerned) is that Debian isn't producing a distribution for the microcontroller in my fibrechannel card, it's producing a distribution for my computer. In order to make my fibrechannel card work, it has to poke some bits in a documented way. Even if there happens to be an ARM onboard that card that's running a program, that ARM isn't running Debian. One of the purposes of having access to the prefered form of modification, is to be able to fix bugs. If the firmware for your fibrechannel card has a bug, are you currently able to fix it ? And if so, do you think the binary-only firmware you have available is the prefered form of modification ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Aug 23, Sven Luther [EMAIL PROTECTED] wrote: Indeed, but would it not make more sense, to aknowledge that the firmware is non-free, and then argue that we should include it nonetheless, instead of making obviously false claims like firmware are not programs ? Firmwares are not programs *for the purpose of DFSG compliance* is a statement which may or may not be true, but will not obviously false (or not) until we will known the outcome of this GR. I do not mind either way anyway, my purpose it to make Debian an useful and free (as-in-freedom) Linux distribution, not arguing about the general definition of the word firmware. -- ciao, Marco signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
In linux.debian.vote Sven Luther [EMAIL PROTECTED] wrote: On Wed, Aug 23, 2006 at 09:24:16PM +1000, Anthony Towns wrote: On Wed, Aug 23, 2006 at 12:32:46PM +0200, Sven Luther wrote: Well, the only one who could claim that his views have some representativity of the project as a whole is you, everyone else is just expressing his own opinion, be he a DD or a guy from NM or some random poster. Anyone can claim their views are representative of the project, and everyone -- including myself -- would be wrong to do so. So, why do you denigrate Peter in such a way ? What you said could apply as well to you, no ? Why do you believe that remarking that somebody is not a debian developer is denigration? I think aj's post was very appropriate, considering how many non-developers like to explain to us what the DFSG really means. If we where really going to argue this, we could just as well stop shiping debian, since there is no way to actually make use of any of the content we ship without some piece of non-free firmware, the first of it being the non-free bios you use on your system. Unpleasant consequences are not a very good way of refuting a logically sound argument. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
El miércoles, 23 de agosto de 2006 a las 21:24:16 +1000, Anthony Towns escribía: We choose to apply the DFSG both to the components that the Debian system requires, and to what we use to provide debian.org services. It can be No, the DFSG are applied to what's provided by Debian, not to what it's required by it. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 07:14:03AM -0600, Matthew Wilcox wrote: On Wed, Aug 23, 2006 at 02:44:48PM +0200, Sven Luther wrote: On Wed, Aug 23, 2006 at 06:08:08AM -0600, Matthew Wilcox wrote: I think the key distinction (as far as I'm concerned) is that Debian isn't producing a distribution for the microcontroller in my fibrechannel card, it's producing a distribution for my computer. In order to make my fibrechannel card work, it has to poke some bits in a documented way. Even if there happens to be an ARM onboard that card that's running a program, that ARM isn't running Debian. One of the purposes of having access to the prefered form of modification, is to be able to fix bugs. Certainly, it's one of the purposes. But I don't think we've *lost* anything by distributing binary firmware. Consider the cases: 1. Everything in hardware. You're not able to fix anything without a soldering iron ... and good luck to you with that. 2. Unmodifiable firmware in EEPROM. Need an EEPROM programmer, and a good deal of skill to fix anything. Again, best of luck. 3. Binary-only firmware in the driver. Slightly better chance of trying to figure out what's going on, but still low. 4. Firmware source in non-preferred form. Modifications probably possible, but when the next round of changes come out from the vendor, you probably have to ditch your mods. 5. Firmware source in preferred form. Can send changes back to vendor, everybody wins. (and I'm sure people can think of other finer distinctions). Notice that i don't disagree with you, i even have argued, altough maybe in a more clumsy way, exactly the same thingas you. My point is that if we believe the above, then we should say so, namely : firmware is non-free. but we chose to keep it, because it is globally more free than the firmware-less alternatives or other reasons. This is what you claim, and what everyone thinks who support the keep firmware in main way, so why not be open about it and say it so ? You seem to want to disallow cases 3 and 4 which makes sense from a here are the rules of data freedom, now i must follow them point of view, but really don't make sense to the vendor, nor to the user. It seems like an all-or-nothing approach. I did say nothing of the sort. Actually, I can turn your argument on its head. The point you're making is about ease of fixing bugs. Given case 3, I can't fix the bug myself, but I have in the past been able to get the vendor to fix the bug. In case 2 (which your argument would seem happy with), I can't fix the bug at all. So cases 3 and 4 are *better* from a bug fixing point of view. Nope, my argument is unrelated to this, it is related to calling things as they are and not play word-games just because the reality inconveniences us. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 03:00:07PM +0200, Marco d'Itri wrote: In linux.debian.vote Sven Luther [EMAIL PROTECTED] wrote: On Wed, Aug 23, 2006 at 09:24:16PM +1000, Anthony Towns wrote: On Wed, Aug 23, 2006 at 12:32:46PM +0200, Sven Luther wrote: Well, the only one who could claim that his views have some representativity of the project as a whole is you, everyone else is just expressing his own opinion, be he a DD or a guy from NM or some random poster. Anyone can claim their views are representative of the project, and everyone -- including myself -- would be wrong to do so. So, why do you denigrate Peter in such a way ? What you said could apply as well to you, no ? Why do you believe that remarking that somebody is not a debian developer is denigration? I think aj's post was very appropriate, considering how many non-developers like to explain to us what the DFSG really means. Well, i and at least 2 other people felt it like that, so if nothing else, the wording of Anthony's comment sucked. If we where really going to argue this, we could just as well stop shiping debian, since there is no way to actually make use of any of the content we ship without some piece of non-free firmware, the first of it being the non-free bios you use on your system. Unpleasant consequences are not a very good way of refuting a logically sound argument. No, but they show the consequences of what you are arguing, and ask the question of if we really want to go this way, instead of just saying it for the case that is of interest, and ignore the full consequences of it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 02:44:48PM +0200, Sven Luther wrote: On Wed, Aug 23, 2006 at 06:08:08AM -0600, Matthew Wilcox wrote: I think the key distinction (as far as I'm concerned) is that Debian isn't producing a distribution for the microcontroller in my fibrechannel card, it's producing a distribution for my computer. In order to make my fibrechannel card work, it has to poke some bits in a documented way. Even if there happens to be an ARM onboard that card that's running a program, that ARM isn't running Debian. One of the purposes of having access to the prefered form of modification, is to be able to fix bugs. Certainly, it's one of the purposes. But I don't think we've *lost* anything by distributing binary firmware. Consider the cases: 1. Everything in hardware. You're not able to fix anything without a soldering iron ... and good luck to you with that. 2. Unmodifiable firmware in EEPROM. Need an EEPROM programmer, and a good deal of skill to fix anything. Again, best of luck. 3. Binary-only firmware in the driver. Slightly better chance of trying to figure out what's going on, but still low. 4. Firmware source in non-preferred form. Modifications probably possible, but when the next round of changes come out from the vendor, you probably have to ditch your mods. 5. Firmware source in preferred form. Can send changes back to vendor, everybody wins. (and I'm sure people can think of other finer distinctions). You seem to want to disallow cases 3 and 4 which makes sense from a here are the rules of data freedom, now i must follow them point of view, but really don't make sense to the vendor, nor to the user. It seems like an all-or-nothing approach. Actually, I can turn your argument on its head. The point you're making is about ease of fixing bugs. Given case 3, I can't fix the bug myself, but I have in the past been able to get the vendor to fix the bug. In case 2 (which your argument would seem happy with), I can't fix the bug at all. So cases 3 and 4 are *better* from a bug fixing point of view. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Jacobo Tarrio [EMAIL PROTECTED] wrote: El miércoles, 23 de agosto de 2006 a las 21:24:16 +1000, Anthony Towns escribía: We choose to apply the DFSG both to the components that the Debian system requires, and to what we use to provide debian.org services. It can be No, the DFSG are applied to what's provided by Debian, not to what it's required by it. The DFSG apply to The Debian system. The social contract doesn't define what The Debian system is. We could define it as What's shipped by Debian, but we could also define it as A system consisting of a computer and a Debian installation or Whatever is provided by Debian and run on the host processor. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
El miércoles, 23 de agosto de 2006 a las 14:59:37 +0100, Matthew Garrett escribía: No, the DFSG are applied to what's provided by Debian, not to what it's required by it. The DFSG apply to The Debian system. The social contract doesn't define what The Debian system is. We could define it as What's No, but it says that Debian are the producers of the Debian GNU/Linux system (should be fixed some day). So, the Debian system does not include anything not produced (or provided) by Debian. -- Jacobo Tarrío | http://jacobo.tarrio.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Followups set to -vote; why are we cc'ing this across multiple lists? On Wed, Aug 23, 2006 at 03:01:52PM +0200, Jacobo Tarrio wrote: El mi?rcoles, 23 de agosto de 2006 a las 21:24:16 +1000, Anthony Towns escrib?a: We choose to apply the DFSG both to the components that the Debian system requires, and to what we use to provide debian.org services. It can be No, the DFSG are applied to what's provided by Debian, not to what it's required by it. The DFSG is Debian's definition of free, so it's applied to everything we think should be free. That includes most of the contents of main and contrib (one notable exception is license texts), everything that main requires, and generally what we run on our servers. The middle one's the one of interest, it's expressed in the first point of the social contract as: We will never make the system require the use of a non-free component. (For reference, that replaced the following text from v1.0 of the social contract: [...] we will never make the system depend on an item of non-free software. ) Cheers, aj signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
Bernhard R. Link [EMAIL PROTECTED] wrote: We are giving a promise here, that with the stuff in our distribution you have the freedom to use it, to give it to others and to fix it. This means the missing of legal obstacles and the possibility to do so. For this discussion preferred form of modification is perhaps not the best definition. It's good for licenses as it is not easily to work around. I think here the difference is between the source being in a form practical to edit or not. Without a practical form there is no possibility to change it. And this is a limitation we have to make clear to people and not lock them into by claiming all is good and well and it could be part of our free operating system. We never included non-free applications in main because we felt that there was no need to. And, indeed, even in 1993 it was possible to use a computer without any non-free applications. That doesn't hold with the firmware argument. With applications, we had the choice between Free but less functional and Non-free but more functional. With firmware we have the choice between Non-free but on disk and Non-free but in ROM. There isn't a Free option at all yet. So I think the real question is How does us refusing to ship non-free firmware help free software?. If a user wants to use Debian, then the obvious thing for them to do will be to buy hardware that has the non-free firmware in ROM. Ironically, this will actually make it harder for them to ever use free firmware! I think it's reasonable to refuse to ship non-free code when there's actually a choice or when it's likely to provide an incentive to implement a free version. But right now, I don't see any evidence that refusing to ship non-free firmware will do anything other than cost us users without providing any extra freedom. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
* Matthew Garrett [EMAIL PROTECTED] [060823 16:40]: We are giving a promise here, that with the stuff in our distribution you have the freedom to use it, to give it to others and to fix it. This means the missing of legal obstacles and the possibility to do so. For this discussion preferred form of modification is perhaps not the best definition. It's good for licenses as it is not easily to work around. I think here the difference is between the source being in a form practical to edit or not. Without a practical form there is no possibility to change it. And this is a limitation we have to make clear to people and not lock them into by claiming all is good and well and it could be part of our free operating system. We never included non-free applications in main because we felt that there was no need to. And, indeed, even in 1993 it was possible to use a computer without any non-free applications. This depends whom you ask. Some people will even instist that today a computer without a working (i.e. non-free) flash-plugin is not operational. That doesn't hold with the firmware argument. With applications, we had the choice between Free but less functional and Non-free but more functional. With firmware we have the choice between Non-free but on disk and Non-free but in ROM. There isn't a Free option at all yet. This is not true in either direction. Not every non-free application has a free counterpart[1]. And not every hardware needs firmware. Many hardware for PCs needed ROM-stored instructions in the past. But as chips were expensive they were designed to run on the same processor, then operating systems no longer running in real mode arrived and Linux had to write drivers for almost everything themself. Where is the difference to firmware? Other that the vendor might be unwilling to give specs to write it on your own saying that there is that firmware. (Last time they has the excuse that all is secret...) So I think the real question is How does us refusing to ship non-free firmware help free software?. If a user wants to use Debian, then the obvious thing for them to do will be to buy hardware that has the non-free firmware in ROM. Or which somes with no firmware at all. (Or where it makes no difference, I do not know if any IDE controler has firmware and I did not hear about IDE harddiscs able to replace it). There also is still the non-free section (or split it into non-free-host-apps, non-free-periperical-apps, non-free-docs, ) so that people can still get it working easily without pretending anything if free or can be part of a free operating system. Ironically, this will actually make it harder for them to ever use free firmware! Where is the difference. If firmware is so free that even Debian declares it free, who will write a free one? I think it's reasonable to refuse to ship non-free code when there's actually a choice or when it's likely to provide an incentive to implement a free version. But right now, I don't see any evidence that refusing to ship non-free firmware will do anything other than cost us users without providing any extra freedom. I'm not saying we should refuse to ship non-free code. I've voted to keep non-free in the last GR about it. I'm against putting things in Debian which are not free. If it is in Debian, I want to be sure that I am allowed to modify it and get it working with some work. If I' bye stuff with ROMed firmware I know it is in there and what I have to expect. If I have to get in from the non-free section, I know I'll have no chance and try to buy something where the manufacturer gave specs and someone worked on them. If everything is in main I'm lured in a false feeling of security and have no easy way to distinguish and choose the vendor with a free firmware. I'm still waiting for a argument how this is in any way different from any other driver for hardware. The only advantage of firmware is that it does not hurt people with minority arches (But given Vancouver that can not be a difference, because we do not care about arches not used by everyone, do we) more than other people. And that it is not that dependent on some interfaces often changing on Linux. Would you also ask to include non-free drivers if they had stable interface and the kernel had a bochs included by default to run them? Hochachtungsvoll, Bernhard R. Link [1] Think of all that little programs speaking some secret protocol, applications for special tasks and so on. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 03:40:49PM +0100, Matthew Garrett wrote: Bernhard R. Link [EMAIL PROTECTED] wrote: We are giving a promise here, that with the stuff in our distribution you have the freedom to use it, to give it to others and to fix it. This means the missing of legal obstacles and the possibility to do so. For this discussion preferred form of modification is perhaps not the best definition. It's good for licenses as it is not easily to work around. I think here the difference is between the source being in a form practical to edit or not. Without a practical form there is no possibility to change it. And this is a limitation we have to make clear to people and not lock them into by claiming all is good and well and it could be part of our free operating system. We never included non-free applications in main because we felt that there was no need to. And, indeed, even in 1993 it was possible to use a computer without any non-free applications. That doesn't hold with the firmware argument. With applications, we had the choice between Free but less functional and Non-free but more functional. With firmware we have the choice between Non-free but on disk and Non-free but in ROM. There isn't a Free option at all yet. So I think the real question is How does us refusing to ship non-free firmware help free software?. If a user wants to use Debian, then the obvious thing for them to do will be to buy hardware that has the non-free firmware in ROM. Ironically, this will actually make it harder for them to ever use free firmware! I think it's reasonable to refuse to ship non-free code when there's actually a choice or when it's likely to provide an incentive to implement a free version. But right now, I don't see any evidence that refusing to ship non-free firmware will do anything other than cost us users without providing any extra freedom. I agree with you. But the point is on how you communicate about the fact. What Steve and others who seconded him propose is to ship non-free firmware in main, and declaring it as data, and thus disguising it as free software. By moving the non-free firmware to non-free, we clearly renew our believe in free software, and encourage effort to reverse engineer or convince vendors, as aurelien and piotr and a few others are reimplementing the apple mac os classic boot sector. It is still relatively easily possible to design the whole non-free firmware support in such a way that it is totally transparent to the user, apart of a message in the installer or something, which will inform him that he needs non-free firmware for its hardware, and asks if he wants to make use of it. So, shiping non-free code because there is no choice is just fine, but shiping it while insisting it is free is not. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 05:18:03PM +0100, Matthew Garrett wrote: OK, never saw that drives. But where is the problem with them. Works without needing any non-free stuff being put in the operating systems and people might be able to replace it. No good example. Wait. So by Non-free stuff being put in the operating systems, you mean Non-free stuff lives on my filesystem? What about non-free stuff shipped by debian ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Bernhard R. Link [EMAIL PROTECTED] wrote: This is not true in either direction. Not every non-free application has a free counterpart[1]. And not every hardware needs firmware. If you can find a single hard drive on the market that doesn't contain some sort of firmware, I'll be greatly impressed. Or, for that matter, a vaguely modern processor. Let alone bootstrapping a system (LinuxBIOS will suffice for a very small range of hardware), running a modern network card, using a graphics chip for any purpose other than unaccelerated 2D, or, well, pretty much any piece of hardware on the market today. For all practical purposes, it's impossible to obtain hardware that doesn't depend on firmware. Or which somes with no firmware at all. (Or where it makes no difference, I do not know if any IDE controler has firmware and I did not hear about IDE harddiscs able to replace it). Yeah, motherboard chipsets are probably about the only thing on a modern system that isn't obviously microcoded. Shame that the drives you plug into them are - vendors often provide firmware upgrades for IDE drives. There also is still the non-free section (or split it into non-free-host-apps, non-free-periperical-apps, non-free-docs, ) so that people can still get it working easily without pretending anything if free or can be part of a free operating system. I'm entirely happy with us making it clear that firmware isn't free-as-in-DFSG. I'm not happy about us leaving it out of the default install images. I'm not saying we should refuse to ship non-free code. I've voted to keep non-free in the last GR about it. I'm against putting things in Debian which are not free. If it is in Debian, I want to be sure that I am allowed to modify it and get it working with some work. If I' bye stuff with ROMed firmware I know it is in there and what I have to expect. If you believe that you can buy hardware without ROM firmware, then I think it's pretty clear that you don't know it is in there. If I have to get in from the non-free section, I know I'll have no chance and try to buy something where the manufacturer gave specs and someone worked on them. If everything is in main I'm lured in a false feeling of security and have no easy way to distinguish and choose the vendor with a free firmware. Or you'll go and buy some hardware with the firmware in eeprom where it's a pain to replace with free firmware. Would you also ask to include non-free drivers if they had stable interface and the kernel had a bochs included by default to run them? No. There's plenty of hardware with free drivers, and I think that us refusing to provide the non-free ones does make a difference. I run no non-free drivers on any of my hardware. At the point where it's possible for me to run a machine without any non-free firmware, I'll be happy to drop it. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
* Matthew Garrett [EMAIL PROTECTED] [060823 17:31]: If you can find a single hard drive on the market that doesn't contain some sort of firmware, I'll be greatly impressed. Or, for that matter, a vaguely modern processor. Let alone bootstrapping a system (LinuxBIOS will suffice for a very small range of hardware), running a modern network card, using a graphics chip for any purpose other than unaccelerated 2D, or, well, pretty much any piece of hardware on the market today. For all practical purposes, it's impossible to obtain hardware that doesn't depend on firmware. In case it was not clear I was discussing things where firmware is also loadable. I've never seen BIOSes being part of the Operating system, but you can get hardware that runs with LinuxBios. I've not yet met a hard drive (as opposed to all kind of Bus controlers) needing any firmware before operating. I don't know about new graphic cards (all I really need is 2D), but looking at how ugly the drivers are and what a secret even communicating with the hardware is for the vendors, I really doubt any firmware on the card is involved. Network cards I never looked to deeply, but most of them were so small I really doubt they are more than plain hardware. WLan cards might be something different, but I never used them. Yeah, motherboard chipsets are probably about the only thing on a modern system that isn't obviously microcoded. Shame that the drives you plug into them are - vendors often provide firmware upgrades for IDE drives. OK, never saw that drives. But where is the problem with them. Works without needing any non-free stuff being put in the operating systems and people might be able to replace it. No good example. I'm entirely happy with us making it clear that firmware isn't free-as-in-DFSG. I'm not happy about us leaving it out of the default install images. I'm not saying we should refuse to ship non-free code. I've voted to keep non-free in the last GR about it. I'm against putting things in Debian which are not free. If it is in Debian, I want to be sure that I am allowed to modify it and get it working with some work. If I' bye stuff with ROMed firmware I know it is in there and what I have to expect. If you believe that you can buy hardware without ROM firmware, then I think it's pretty clear that you don't know it is in there. If it is direct hardware or a ROM, it does not matter that much in there. If there is a ROM at all. In days where modems have no modulator/demodulator chips any more, there are not that much things where people would put processors in. Put again, what part instead if my BIOS (which mostly runs in CPU so some people might not call it firmware, and at least with PCs is never needed to be shipped by a driver) and IDE drivers (which also always come with some pre-installed firmware, so not relevant), is found in every cheap box? (assuming to wireless). If I have to get in from the non-free section, I know I'll have no chance and try to buy something where the manufacturer gave specs and someone worked on them. If everything is in main I'm lured in a false feeling of security and have no easy way to distinguish and choose the vendor with a free firmware. Or you'll go and buy some hardware with the firmware in eeprom where it's a pain to replace with free firmware. As I said. As long as noone cares for free firmwares, what difference does it make? I the vendor opens the specs, there should be a free one and not problems. If it does not open the specs the eeprom version has the advantage to work even when the firmware-binary gets lost and the manufacturer might have tested it before. (Or introduced something to replace the firmware, which again defeats your point). Hochachtungsvoll, Bernhard R. Link -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Matthew Garrett [EMAIL PROTECTED] I think it's reasonable to refuse to ship non-free code when there's actually a choice or when it's likely to provide an incentive to implement a free version. But right now, I don't see any evidence that refusing to ship non-free firmware will do anything other than cost us users without providing any extra freedom. The above argument seems to be If I don't see it, it doesn't matter. Of course, evidence is unlikely to appear before the action is taken. I doubt any corporation will declare if debian does this, we'll follow the DFSG instead. Instead, we each get to make our best guesses. I think the idea that refusing to ship non-free firmware in main will strengthen demand for free firmware is worthy of consideration. Debian helps users to take control of their operating system. Increasing the demand for free firmware might also help users to take control of their hardware, or at least highlight that there's this crap which their operating system uses to support their hardware but doesn't have its normal freedoms. However, I'm undecided whether it's a good idea to exclude them from the distribution CDs and so on. How big is the problem of vital hardware which won't work without firmware being copied to it? Should we split non-free into non-free-hardware and non-free, allowing non-free-hardware packages onto the CDs? Thanks for any answers, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 07:25:10PM +0100, MJ Ray wrote: Matthew Garrett [EMAIL PROTECTED] I think it's reasonable to refuse to ship non-free code when there's actually a choice or when it's likely to provide an incentive to implement a free version. But right now, I don't see any evidence that refusing to ship non-free firmware will do anything other than cost us users without providing any extra freedom. The above argument seems to be If I don't see it, it doesn't matter. Of course, evidence is unlikely to appear before the action is taken. I doubt any corporation will declare if debian does this, we'll follow the DFSG instead. Instead, we each get to make our best guesses. I think the idea that refusing to ship non-free firmware in main will strengthen demand for free firmware is worthy of consideration. Debian helps users to take control of their operating system. Increasing the demand for free firmware might also help users to take control of their hardware, or at least highlight that there's this crap which their operating system uses to support their hardware but doesn't have its normal freedoms. However, I'm undecided whether it's a good idea to exclude them from the distribution CDs and so on. How big is the problem of vital hardware which won't work without firmware being copied to it? Should we split non-free into non-free-hardware and non-free, allowing non-free-hardware packages onto the CDs? I would indeed vote for a solution including a non-free hardware, or even better an additional CD, which contained a non-free version of d-i (which need to include certain non-free firmwares and drivers in the images), and all the additional non-free firmware stuff. This way, we could add a list of pci ids needding non-fre hardware, and do a check pretty early in the installer, and if those non-free hardware is found, inform the user about it, and use the non-free installer CD instead, and all the rest would be taken care for him. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, 22 Aug 2006 15:18:04 -0700, Steve Langasek [EMAIL PROTECTED] said: Hi folks, Ever since the sarge release, an ongoing question has been: what do the DFSG require for works that are not programs as previously understood in Debian? Several rounds of general resolutions have now given us answers for some subclasses of non-program works, but debate still rages regarding one particularly important class: firmware for peripheral devices. Actually, I disagree, and, even worse, so does the common definition of the phrase computer program: asking google about define: computer program gives: , | * A computer program is a set of statements or instructions to be | used directly or indirectly in a computer in order to bring | about a certain result. | www.tms.org/pubs/journals/JOM/matters/matters-9710.html | | * A combination of computer instructions and data definitions that | enable computer hardware to perform computational or control | functions. | sparc.airtime.co.uk/users/wysywig/gloss.htm | | * A series of instructions or statements, in a form acceptable to | a computer, prepared in order to achieve a certain result. | www.hermit.cc/teach/ho/hogloss.htm | | * program: (computer science) a sequence of instructions that a | computer can interpret and execute; the program required | several hundred lines of code | wordnet.princeton.edu/perl/webwn | | * A computer program (often simply called a program) is an example | of computer software that prescribes the actions | (computations) that are to be carried out by a computer. Most | programs consist of a loadable set of instructions which | determines how the computer will react to user input when that | program is running, i.e. when the instructions are 'loaded'. | en.wikipedia.org/wiki/Computer_program ` What is firmware, then? Speaking as en electrical engineer, I would say that firmware is just compiled binary programs that are meant to be executed by a processor (that often lives on the mainboard) which happens not to be the contral processing unit. Why is freedom of software only important for the central processing unit, but immaterial for other processing usints? And, given the trend of multiple processing usints, and not all of them being symmetric (the cell, for example, the central processing unit serves as little more than a traffic cop), with processing increadsingly off loaded to the graphics processing unit, physics processing units, encryption processors, biometrics processors, peripheral processing units, we should be careful about how we define processing units for which software freedom in unimportant/ Si, am I silly and alone in thinking that firmware is binary computer programs? Let us ask google to define: firmware: , | # An Often-used microprogram or instruction set stored in ROM. Usually | # refers to the ROM-based software that controls an unit. Firmware is | # found in all computer based products from Cameras to Digital | # Peripherals | www.photoshopelementsuser.com/glossary.php | | # Software contained in a read-only memory (ROM) device. | www.ontrack.com/glossary/ | | # Proprietary code that is usually delivered as microcode as part of | # an operating system. Firmware is more efficient than software loaded | # from an alterable medium and more adaptable to change than pure | # hardware circuitry. | www.sabc.co.za/manual/ibm/9agloss.htm | | # instructions and data programmed into the circuits responsible for | # controlling the operation of peripheral devices | www.veritysystems.com/glossary.htm | | # These are permanent instructions and data programmed directly into | # the circuitry of read-only memory for the purpose of controlling the | # operation of the computer or disk drive. | www.harddiskrecovery.net/computer_glossary.html | | # Software (programs or data) that has been written onto read-only | # memory (ROM). Firmware is a combination of software and | # hardware. ROMs, PROMs and EPROMs that have data or programs recorded | # on them are firmware. | www.5starsupport.com/glossary/f.htm | | # Computer instructions which are permanently imbedded in the | # circuitry, usually in a ROM chip. | www.micro2000uk.co.uk/hardware_glossary.htm | | # Programming inserted into programmable read-only memory (PROM), thus | # becoming a permanent part of a computing device. Firmware is created | # and tested like software (using microcode simulation). When ready, | # it can be distributed like other software and, using a special user | # interface, installed in the programmable read-only memory by the | # user. Is sometimes distributed for printers, modems and other | # computer devices. | www.mcsx.co.uk/articles/glossary.htm | | # In a CD recorder, firmware is the programming instructions contained | # on a
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 22, 2006 at 06:19:08PM -0500, Manoj Srivastava wrote: On Tue, 22 Aug 2006 15:18:04 -0700, Steve Langasek [EMAIL PROTECTED] said: Hi folks, Ever since the sarge release, an ongoing question has been: what do the DFSG require for works that are not programs as previously understood in Debian? Several rounds of general resolutions have now given us answers for some subclasses of non-program works, but debate still rages regarding one particularly important class: firmware for peripheral devices. Actually, I disagree What point are you disagreeing with? That there is debate about firmware in Debian? That the previous common understanding of programs in Debian did not include firmware? If it's the latter, I maintain that this is precisely the subject matter of the proposed GR; we obviously *don't* have agreement in Debian over what should or should not be considered a program, so I think that's begging the question. and, even worse, so does the common definition of the phrase computer program: If 55% of the voting developers in Debian don't agree with this common definition as pertains to the DFSG (which I doubt most laymen would agree with either where firmware is concerned), why do they need the consent of another 20% of the voters in order to proceed accordingly? What is firmware, then? Speaking as en electrical engineer, I would say that firmware is just compiled binary programs that are meant to be executed by a processor (that often lives on the mainboard) which happens not to be the contral processing unit. Yes, these are reasonable definitions of both program and firmware. They're also not the ones that Debian has been operating under for most of its history; the previous version of the Social Contract said that Debian would remain 100% free software, and I don't think anyone will argue that there are programs which aren't software. So if firmware was already supposed to be covered under the DFSG, how is this reconciled with the fact that no one ever worried about firmware in Debian until the past couple of years? The two possible explanations I see are that 1) Debian simply was not reading (or following) the DFSG, 2) the definition of program that everyone was using was not the obvious dictionary definition. Why is freedom of software only important for the central processing unit, but immaterial for other processing usints? This isn't a question I can answer for you. I've never argued that software freedom isn't important for firmware, I've argued that different aspects of software freedom are of different relative importance for different classes of software, and in particular that source code is not important enough for firmware that it should be a condition for inclusion in main. And, given the trend of multiple processing usints, and not all of them being symmetric (the cell, for example, the central processing unit serves as little more than a traffic cop), with processing increadsingly off loaded to the graphics processing unit, physics processing units, encryption processors, biometrics processors, peripheral processing units, we should be careful about how we define processing units for which software freedom in unimportant/ That's an interesting point. Can you elaborate on how you see this being a loophole, in a sense that having the firmware on a ROM wouldn't also be? 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. This would require us to amend the foundation document of the DFSG, and define that what Debian defines as software program is different from the common definitions of the term In order for us to have a meaninglul foundation document, we can't debate and use our own special definitions of common terms, since the definition in turn uses words that can be defined in a special fashion. In fact, I don't think that any document of substance written in English could be so ironclad that it would eliminate all doubts about the meaning. There are enough questions about the application of the US Constitution to keep a large system of appellate and circuit courts quite busy; not because the Constitution was badly written, but because differences of interpretation are inevitable. Debian specifies that the Project Secretary adjudicates interpretation of the Debian constitution and decides matters of procedure when voting, but there is no defined procedure for resolving questions of interpretation of the DFSG and the Social Contract save the GR procedure itself. This effectively means that each developer is responsible for interpreting these documents as they apply to their own area of responsibility; which is why I maintain that a position statement on firmware's disposition under the DFSG could be cited as a sort of precedent, but could not compel anyone to act against their
