Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?
Francesco Poli writes: > What makes you think that every and each copyright holder acted in good > faith when started to distribute firmware under the terms of the GNU GPL > v2, while keeping the source code secret? > Some copyright holder could be deliberately preparing a trap, in order > to be able to sue at whim, whenever he decides he wants to. If the prospective plaintiff is the person who submitted opaque or object code, the relevant affirmative defense here is called estoppel. Pick your favorite form of estoppel -- several apply. Other copyright holders could sue with at least a colorable position, but not the one who added the sourceless code in the first place. 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
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 ." > > 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 - Deferment of Changes from GR 2004-003
Guido Trotter writes: > This may be bad, since we've just changed the SC, and we actually don't > want to change it back. (It may be bad publicity too) > > Can't we have a GR that simply overrules aj's decision about his personal > interpretation of the SC (according to the constitution § 4.1.3) and simply > reaffirms that the changes done to the social contract are only editorial, > and are done to clarify its meaning? > > Actually none of us have any problems with the new SC, it's only aj's > decision to anticipate dealing with this issues before sarge, instead of > after it, that we don't like... Let me see if I understand correctly: Debian revises its SC to remove an ambiguity. The release manager applies the new terms to the next major release of Debian. People disagree with that, and instead want to override his decision so that sarge will intentionally breach the SC. And you say reverting the changes would be bad publicity? Michael
Re: Proposal - Deferment of Changes from GR 2004-003
Guido Trotter writes: > This may be bad, since we've just changed the SC, and we actually don't > want to change it back. (It may be bad publicity too) > > Can't we have a GR that simply overrules aj's decision about his personal > interpretation of the SC (according to the constitution § 4.1.3) and simply > reaffirms that the changes done to the social contract are only editorial, > and are done to clarify its meaning? > > Actually none of us have any problems with the new SC, it's only aj's > decision to anticipate dealing with this issues before sarge, instead of > after it, that we don't like... Let me see if I understand correctly: Debian revises its SC to remove an ambiguity. The release manager applies the new terms to the next major release of Debian. People disagree with that, and instead want to override his decision so that sarge will intentionally breach the SC. And you say reverting the changes would be bad publicity? Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Social Contract GR's Affect on sarge
Michael Banck writes: > So even if the glibc functions might be documented in manpages in a > satisfactory way, this is probably not true for the rest of the GNU > packages. I would disagree that even glibc functions are adequately documented in man pages. To pick just one example, the mcheck() and mallinfo() functions are part of the malloc debugging support in glibc. I cannot find mention of them in the man pages, but they are described at length in the info files; I have used them before to try to debug memory bugs in a program I maintain [1]. To adequately re-document everything that is in upstream documentation (but in a non-free format) will be an enormous amount of effort, especially as upstream adds new features. Michael Poole [1]- To forestall the suggestion to use valgrind instead, the program in question uses 500 MB of memory without any debugging overhead, and has not exhibited the errors on smaller test sets. 32-bit valgrind exhausts the user memory space before it loads the full data set.
Re: Social Contract GR's Affect on sarge
Michael Banck writes: > So even if the glibc functions might be documented in manpages in a > satisfactory way, this is probably not true for the rest of the GNU > packages. I would disagree that even glibc functions are adequately documented in man pages. To pick just one example, the mcheck() and mallinfo() functions are part of the malloc debugging support in glibc. I cannot find mention of them in the man pages, but they are described at length in the info files; I have used them before to try to debug memory bugs in a program I maintain [1]. To adequately re-document everything that is in upstream documentation (but in a non-free format) will be an enormous amount of effort, especially as upstream adds new features. Michael Poole [1]- To forestall the suggestion to use valgrind instead, the program in question uses 500 MB of memory without any debugging overhead, and has not exhibited the errors on smaller test sets. 32-bit valgrind exhausts the user memory space before it loads the full data set. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
