On Tue, Aug 22, 2006 at 06:19:08PM -0500, Manoj Srivastava wrote: > On Tue, 22 Aug 2006 15:18:04 -0700, Steve Langasek <vorlon@debian.org> 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 own understanding of the DFSG as written (in either direction). OOI, in your view, how is a GR that says "'programs' should not be understood to include firmware" different from a GR that says "the GFDL passes the DFSG", where supermajority requirements are concerned? > 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. So for the sake of argument, where would you insert such definitions into the DFSG? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature