Re: kernel firmwares: GR proposal
On Thu, Aug 31, 2006 at 12:48:35AM -0400, Nathanael Nerode wrote: > Actually, this is what is wrong with the polls at the debian user forums > which AJ pointed people to. Etch can release on time either free (with > less hardware support) or non-free (with more hardware support). > Making "Release etch on time" top priority doesn't really answer the > question of what to do. No, it doesn't, which is why there's a second poll on what should actually be done: http://forums.debian.net/viewtopic.php?p=31128 The results are currently: ] Since it appears Debian has to make a choice, which would you prefer we ] do for etch? ] ] 108 / 64% - Allow sourceless firmware in main ]31 / 18% - Delay the release of etch ](so that we can support loading firmware from non-free) ]29 / 17% - Drop support for hardware which requires sourceless firmware I don't know that 170 or so votes is that impressive, given what I'd estimate as the total number of Debian users. It's also worth noting there are a few comments along the lines: ] I've voted to allow the firmware in main, but I also want to add ] the remark that I hope the modifications to the debian installer ] will be high on the priority list for the next debian release. Cheers, aj signature.asc Description: Digital signature
Re: calling firmware code data is not being honest with ourselves, includes counterproposal and RFC on a possible Amendment
On Wed, Aug 30, 2006 at 09:54:31PM -0400, David Nusinow wrote: > On Wed, Aug 30, 2006 at 10:41:00PM -0700, Thomas Bushnell BSG wrote: > > David Nusinow <[EMAIL PROTECTED]> writes: > > > > > Would you, or someone else, mind pointing out some examples of firmware > > > with source? Preferrably with some of the breadth you refer to above? I > > > understand firmware in concept, but beyond seeing it as a binary blob I've > > > not really come seriously in to contact with it. If I'm going to vote on > > > this issue, I'd really like to actually understand what I'm going to be > > > voting on. > > > > I think it's widely in agreement that hardware manufacturers have > > assemblers and other tools they use for building firmware. > > So we don't have any firmware with source? Sorry. I've since read further in to this thread and found answers. I'll grab the kernel code and have a look. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: calling firmware code data is not being honest with ourselves, includes counterproposal and RFC on a possible Amendment
David Nusinow <[EMAIL PROTECTED]> writes: > On Wed, Aug 30, 2006 at 10:41:00PM -0700, Thomas Bushnell BSG wrote: >> David Nusinow <[EMAIL PROTECTED]> writes: >> >> > Would you, or someone else, mind pointing out some examples of firmware >> > with source? Preferrably with some of the breadth you refer to above? I >> > understand firmware in concept, but beyond seeing it as a binary blob I've >> > not really come seriously in to contact with it. If I'm going to vote on >> > this issue, I'd really like to actually understand what I'm going to be >> > voting on. >> >> I think it's widely in agreement that hardware manufacturers have >> assemblers and other tools they use for building firmware. > > So we don't have any firmware with source? I have no idea. I have heard people in this discussion *define* firmware in terms of the absence of source. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: calling firmware code data is not being honest with ourselves, includes counterproposal and RFC on a possible Amendment
On Wed, Aug 30, 2006 at 10:41:00PM -0700, Thomas Bushnell BSG wrote: > David Nusinow <[EMAIL PROTECTED]> writes: > > > Would you, or someone else, mind pointing out some examples of firmware > > with source? Preferrably with some of the breadth you refer to above? I > > understand firmware in concept, but beyond seeing it as a binary blob I've > > not really come seriously in to contact with it. If I'm going to vote on > > this issue, I'd really like to actually understand what I'm going to be > > voting on. > > I think it's widely in agreement that hardware manufacturers have > assemblers and other tools they use for building firmware. So we don't have any firmware with source? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
Frederik Schueler <[EMAIL PROTECTED]> writes: > 1. We affirm that our Priorities are our users and the free software > community (Social Contract #4); > 2. We acknowledge that there is a lot of progress in the kernel firmware > issue; however, it is not yet finally sorted out; > 3. We give priority to the timely release of Etch over sorting every bit > out; for this reason, we will deliver firmware in udebs as long as it is > necessary for installation (like all udebs), and firmware included in > the kernel itself as part of Debian Etch, without further conditions. It seems to me that this GR is unacceptable in this form because it does not give an adequate definition of firmware, and people seem to mean many different things by it. Further, because this amounts to a decision to disregard the SC, it should require a 3:1 majority. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: calling firmware code data is not being honest with ourselves, includes counterproposal and RFC on a possible Amendment
David Nusinow <[EMAIL PROTECTED]> writes: > Would you, or someone else, mind pointing out some examples of firmware > with source? Preferrably with some of the breadth you refer to above? I > understand firmware in concept, but beyond seeing it as a binary blob I've > not really come seriously in to contact with it. If I'm going to vote on > this issue, I'd really like to actually understand what I'm going to be > voting on. I think it's widely in agreement that hardware manufacturers have assemblers and other tools they use for building firmware. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: calling firmware code data is not being honest with ourselves, includes counterproposal and RFC on a possible Amendment (Was: Proposal: The DFSG do not require source code for data, including firm
Hi Sven, On Wed, Aug 23, 2006 at 09:09:31AM +0200, Sven Luther wrote: > There is no way you can just decide that firmware is not code, especially as > there is overwhelming evidence in some case that it is indeed code (or > microcode as some call it), ranging from declaration on the LKML mailing list > by the drivers author, or when the peripheral processor holds a mips or arm or > whatever core. Sure, other firmware cases consist of only register dumps, but > my own involvement in hardware development shows me that the trend is more and > more for peripheral hardware with embedded processor cores, and the firmware > of those being actual processors, some of them could run some variant of linux > (or uclinux at least) in their own right. This is especially true for high-end > raid cards and wireless applications. Would you, or someone else, mind pointing out some examples of firmware with source? Preferrably with some of the breadth you refer to above? I understand firmware in concept, but beyond seeing it as a binary blob I've not really come seriously in to contact with it. If I'm going to vote on this issue, I'd really like to actually understand what I'm going to be voting on. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: special exception for firmware because of technical limitations
Sven Luther wrote: > I heard claims of buginess in the patch, The buggy one was my radeon patch. It's rather hard to get right because of the complex interaction between X and the kernel, and because the DRI trunk doesn't like Linux-specific things, and we never did track down the problem. I'm not going to tackle that one again for a while -- I think it needs someone who is both good at Linux kernel development *and* understands the exact structure of the DRI system. There was one bug in the tg3 patch which Herbert Xu spotted and fixed related to having multiple tg3 boards present at once. As an aside, the tg3 driver is an ugly piece of work, because nearly the whole thing is in a single spinlock. > due in big part for the missing > upstream support for proper firmware loading Actually, kernel support was pretty much there by the time I wrote the tg3 patch. The userland tools weren't quite mature, however, which they are now. Back then not everyone was using hotplug (which was required), but now everyone uses udev. That probably makes a difference. Also, initially the firmware could only be loaded from /usr, which obviously irritated a lot of people; now it can be loaded from the root partition. > and probably the absense of > initramfs support, as we have now. Yes, there was some complaint about the lack of easy support for installing the firmware in the initrd. Which is not technically a bug, but the lack of a feature (netmounted root for those boards which need firmware loading). Isn't this still an issue? :-/ Doesn't it require udev to run in the initramfs, and isn't that not-yet-ready? (Although desired upstream, from what I remember -- this is the "early userland" stuff) Frankly, people who netmount root and use network cards requiring firmware loading are a pretty small group. But it would be nice to make it work for them. > Friendly, > > Sven Luther We are getting way off topic for -vote. -- 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: kernel firmwares: GR proposal
Sven Luther wrote:
> On Wed, Aug 30, 2006 at 08:47:08PM -0400, Nathanael Nerode wrote:
> http://www.debian.org/devel/debian-installer will give you all the links
> you want, but for the lazy :
> svn://svn.debian.org/svn/d-i/trunk/packages/anna
Thank you very much.
Oddly, finding the d-i repo was impossible for me until you provided this
link. It's not linked from the above page (it is linked from the Wiki page
linked from the above page, but I hadn't wandered that particular path) and
I didn't guess its name, so I couldn't find it at http://svn.debian.org/ .
> Also, it is in the main/debian-installer section of the debian archive,
> even with source and all.
I found it shortly after posting this. ::embarassed::
I had done dozens of searches, but I didn't think to look for a package
which existed only in the debian-installer section of the archive.
Ended up finding it via google; I managed to put in just the right search
terms finally.
'Course, it looks like 'anna' doesn't need any changes :-/
>> > and we do not
>> > want to depend on that (and even then, we still would have non-free
>> > firmware, see above). But since there is lots of hardware which needs
>> > firmware for correct operation, the installer would not work for
>> > mainstream hardware otherwise.
>> >
>> > There are two ways how to deal with it:
>> > 1. Accept these issues as transitional issues for now; or
>> > 2. Delay etch for some serious time.
>>
>> Like a month or two, maybe. If people actually bother to work on it, or
>> to accept other people's work on it.
>
> Current estimates place this between 6 month and a year. The fact is the
> d-i team need at least a month or two of testing for this,
Yeah, testing is an issue.
On the other hand, releasing a fully free etch by simply removing hardware
support would be fast and trivial, and etch wouldn't be delayed *at all*.
(Obviously the priorities of 'our users' and 'free software' come into
conflict there.)
If etch will be released in a hurry ("Debian releases before it is
ready"), I'd rather see an etch weak on hardware support and strong on
freedom; I guess others would prefer the other way around.
Actually, this is what is wrong with the polls at the debian user forums
which AJ pointed people to. Etch can release on time either free (with
less hardware support) or non-free (with more hardware support).
Making "Release etch on time" top priority doesn't really answer the
question of what to do.
> even if the
> change was instantaneous, there are loads of packages which will trigger
> NEW, and so on.
Yeah, that could slow things down.
> Also, finding, approaching and convincing people to clarify the licence of
> the problematic ones, is something which will take some serious time.
Years. Decades. Centuries. OK, I'm a bit pessimistic on this.
>> > In our social contract, we promised that the users and the free
>> > software community are our priorities. We firmly believe that our users
>> > profit very much from releasing etch in time, and that this is
>> > important enough that we can accept the transitional status with having
>> > a few firmware
>> > images left in main that should belong somewhere else. Of course,
>> > everyone who wants to make the number of such firmware images as small
>> > as possible is welcome to help converting old firmware loaders to the
>> > new standard, and working on the Debian installer. We are happy if this
>> > issues become smaller or even vanishes, but we do not want this to be a
>> > release blocker.
>>
>> OK, this is good. :-) Does this mean that the patches converting the
>> tg3 driver to use firmware loading will be reaccepted?
>
> What is the position of the upstream author of the tg3 driver about this,
I recall little but emotional hostility, but I haven't asked in a while.
Maybe I'll try again when the patch is ready against the latest upstream.
> and even if he is still (i think it was him) strongly opposed, is your
> patch upstream-quality ?
It was used for months without complaints by many people; it's minimally
invasive; the one identified bug was fixed by Herbert Xu, although I
currently don't have a copy of his bugfix.
Currently other people are working on updating it to the current kernel,
which suits me fine. :-)
>> Note that I am not comfortable personally working on the drivers
>> containing improperly licensed firmware. (Except for working on getting
>> a
>> proper license, that is.) You may well find that the other volunteers
>> for
>
> Yeah, that is something which is needed. We need someone to go over
> larry's list, which i have copiedto the debian wiki, and find out who the
> copyright holder of those problematic firmwares are, and then we can
> contact them, taking the broadcom original letter i wrote as a sample.
How optimistic you are. :-) After four or five attempts to find a contact
address at Broadcom which would reply, I gave up; I'm glad someone else
found one ev
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Steve Langasek wrote: > On Wed, Aug 30, 2006 at 08:26:56PM -0400, Nathanael Nerode wrote: >> Actually, letting an overworked team of four with (to my knowledge) zero >> legal expertise settle questions of legal liability is pretty absurd too. > > They are the team responsible for vetting the legality of what's > distributed > on the mirrors. None of them have any legal expertise to my knowledge; > but they do know where the lawyers are if they have questions, Well, that's good! Do they really have the hotline to the lawyers? Excellent! I hope they actually use it occasionally; I've never heard of them doing so, so if they have gotten any legal opinions, they've kept them secret. (Dammit, when Debian developers attempted to get legal advice on trademark policy, it sunk into a black hole. The advice never really came back, after several years.) > and they > *are* the ones in the hot seat(s). Meaning that they are personally liable and the rest of the Debian developers aren't? :-) I'd love to see a legal opinion from the SPI lawyers regarding who would be liable if Debian did commit copyright infringment (or whatever) and someone sued. It seems to me that the developers have entrusted the ftpmasters with the responsibility of guarding Debian's funds and property against a copyright infringment lawsuit. Is that the general feeling of the developers? Are the ftpmasters comfortable with that responsibility? If so, my proverbial hat is off to them. >> Should the ftpmasters, who have even less legal expertise, > > Judging by some of the nonsense that debian-legal is typically riddled > with, if I were an ftpmaster I would find that claim insulting. There is at least one laywer who posts regularly. Which counts as some legal expertise, and which is exactly what I was referring to when I said "very little". > The only claim to expertise that debian-legal has is in the area of > analyzing license terms and how they stack up against the requirements of > the DFSG. That is an important function, but it is *not* legal expertise. See above. -- 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: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Wed, Aug 30, 2006 at 08:26:56PM -0400, Nathanael Nerode wrote: > > On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: > >> Debian needs to make a decision on how it will deal with this legal > >> minefield. That is higher priority than the entire discussion going on > >> right now, because it determines whether Debian will distribute these 53 > >> BLOBs *at all*, in 'main' or in 'non-free'. > >> Oddly enough nobody has proposed a GR addressing this, > > Because voting is an absurd means of settling questions of legal > > liability. It's the domain of the ftp team to determine whether we can > > legally distribute a package on our mirrors. > Actually, letting an overworked team of four with (to my knowledge) zero > legal expertise settle questions of legal liability is pretty absurd too. They are the team responsible for vetting the legality of what's distributed on the mirrors. None of them have any legal expertise to my knowledge; but they do know where the lawyers are if they have questions, and they *are* the ones in the hot seat(s). > Should the ftpmasters, who have even less legal expertise, Judging by some of the nonsense that debian-legal is typically riddled with, if I were an ftpmaster I would find that claim insulting. The only claim to expertise that debian-legal has is in the area of analyzing license terms and how they stack up against the requirements of the DFSG. That is an important function, but it is *not* legal expertise. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.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
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: Amendment: special exception for firmware because of technical limitations
On Wed, Aug 30, 2006 at 09:11:50PM -0400, Nathanael Nerode wrote: > > > Josselin Mouette wrote: > > > I propose the following amendment to Steve's proposal. > > > >> THE DEBIAN PROJECT therefore, > >> > >> 1. reaffirms its dedication to providing a 100% free system to > >> our > >> users according to our Social Contract and the DFSG; and > >> > >> 2. encourages authors of all works to make those works available > >> not > >> only under licenses that permit modification, but also in forms that make > >> such modifications practical; and > >> > >> 3. supports the decision of the Release Team to require works > >> such as > >> images, video, and fonts to be licensed in compliance with the DFSG > >> without requiring source code for these works under DFSG #2; and > > > > 4. determines that as a special exception to DFSG #2, the source code > > for device firmwares contained in the kernel packages will not be > > required as long as there are no other technical means to install and > > run the Debian system on these devices. > > Seems reasonable > > One practical result of this: > > * The tg3 driver would have two of the three embedded firmware images > removed from 'main'. They are not necessary for installation or runtime; > they do add some performance. The one image which is necessary for certain > rare, old tg3 boards would remain. (Most tg3 boards don't need any > firmware loaded.) > > Because of stuff like this, this amendment would in fact have a different > result from all previous proposals. > > > Rationale: most of us want to release etch ASAP, and most of us want to > > remove the firmwares from the kernel ASAP. This is a way that shouldn't > > stop the ongoing work on both of these issues. The wording makes it > > clear that as soon as the kernel and d-i are able to use split out > > firmwares, the migration will have to be done. This way we won't > > discourage the work from Nathanael Nerode and other people who worked > > hard so far to remove the non-free blobs, > > Actually, the only thing which seriously discouraged me was when Debian > reverted the patch to convert tg3 to firmware loading and resumed shipping > the BLOBs. I understand why it was done (the loadable firmware was not > being shipped, because the license hadn't been fixed yet), but it was very > discouraging. Adding BLOBs which weren't in the previous release is very > discouraging. (Frankly, I'm waiting until those BLOBs are out of 'main' > again before trying to work on anything else -- sort of waiting for a sign > of good faith, if you will.) Anything else is not really that > discouraging. I heard claims of buginess in the patch, due in big part for the missing upstream support for proper firmware loading and probably the absense of initramfs support, as we have now. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: special exception for firmware because of technical limitations
Josselin Mouette wrote: > I propose the following amendment to Steve's proposal. > >> THE DEBIAN PROJECT therefore, >> >> 1. reaffirms its dedication to providing a 100% free system to >> our >> users according to our Social Contract and the DFSG; and >> >> 2. encourages authors of all works to make those works available >> not >> only under licenses that permit modification, but also in forms that make >> such modifications practical; and >> >> 3. supports the decision of the Release Team to require works >> such as >> images, video, and fonts to be licensed in compliance with the DFSG >> without requiring source code for these works under DFSG #2; and > > 4. determines that as a special exception to DFSG #2, the source code > for device firmwares contained in the kernel packages will not be > required as long as there are no other technical means to install and > run the Debian system on these devices. Seems reasonable One practical result of this: * The tg3 driver would have two of the three embedded firmware images removed from 'main'. They are not necessary for installation or runtime; they do add some performance. The one image which is necessary for certain rare, old tg3 boards would remain. (Most tg3 boards don't need any firmware loaded.) Because of stuff like this, this amendment would in fact have a different result from all previous proposals. > Rationale: most of us want to release etch ASAP, and most of us want to > remove the firmwares from the kernel ASAP. This is a way that shouldn't > stop the ongoing work on both of these issues. The wording makes it > clear that as soon as the kernel and d-i are able to use split out > firmwares, the migration will have to be done. This way we won't > discourage the work from Nathanael Nerode and other people who worked > hard so far to remove the non-free blobs, Actually, the only thing which seriously discouraged me was when Debian reverted the patch to convert tg3 to firmware loading and resumed shipping the BLOBs. I understand why it was done (the loadable firmware was not being shipped, because the license hadn't been fixed yet), but it was very discouraging. Adding BLOBs which weren't in the previous release is very discouraging. (Frankly, I'm waiting until those BLOBs are out of 'main' again before trying to work on anything else -- sort of waiting for a sign of good faith, if you will.) Anything else is not really that discouraging. > and we won't hold etch > development because of that issue. -- 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: kernel firmwares: GR proposal
On Wed, Aug 30, 2006 at 08:47:08PM -0400, Nathanael Nerode wrote:
> > Also, though the firmware loader allows us to put the firmware where it
> > belongs to (main or non-free, depending on the case), the installer can
> > as of now only take udebs from main. Fixing this is not too hard, but
> > it is doubtful whether we can fix this in time for etch,
>
> "because we are not willing to try to fix it and we have not given anyone
> else sufficient information to"
Oh come one, this is all free software, and it is freely available both in
the debian archive, which holds source, and in our svn repository.
> Sorry to be so annoyed. I can't even find 'anna', which is supposedly the
> module which needs to be fixed. Where do I download it from? I have asked
> debian-boot on previous occasions.
http://www.debian.org/devel/debian-installer will give you all the links you
want, but for the lazy :
svn://svn.debian.org/svn/d-i/trunk/packages/anna
Also, it is in the main/debian-installer section of the debian archive, even
with source and all.
> > and we do not
> > want to depend on that (and even then, we still would have non-free
> > firmware, see above). But since there is lots of hardware which needs
> > firmware for correct operation, the installer would not work for
> > mainstream hardware otherwise.
> >
> > There are two ways how to deal with it:
> > 1. Accept these issues as transitional issues for now; or
> > 2. Delay etch for some serious time.
>
> Like a month or two, maybe. If people actually bother to work on it, or to
> accept other people's work on it.
Current estimates place this between 6 month and a year. The fact is the d-i
team need at least a month or two of testing for this, even if the change was
instantaneous, there are loads of packages which will trigger NEW, and so on.
Also, finding, approaching and convincing people to clarify the licence of the
problematic ones, is something which will take some serious time.
I know you proposed patches for this so long ago, but back then the kernel
infrastructure was not mature enough for it, this has changed.
Furthermore, during the delay while we work on it, we still will have sarge
out there, which will have a less free situation than we currently have in
etch/sid, so you don't gain much by delaying.
Let's take the time to do this right, instead of hurying, and doing it for
etch+1 will allow us to do that.
> > In our social contract, we promised that the users and the free software
> > community are our priorities. We firmly believe that our users profit
> > very much from releasing etch in time, and that this is important enough
> > that we can accept the transitional status with having a few firmware
> > images left in main that should belong somewhere else. Of course,
> > everyone who wants to make the number of such firmware images as small
> > as possible is welcome to help converting old firmware loaders to the
> > new standard, and working on the Debian installer. We are happy if this
> > issues become smaller or even vanishes, but we do not want this to be a
> > release blocker.
>
> OK, this is good. :-) Does this mean that the patches converting the tg3
> driver to use firmware loading will be reaccepted?
What is the position of the upstream author of the tg3 driver about this, and
even if he is still (i think it was him) strongly opposed, is your patch
upstream-quality ?
> > So, we propose this GR:
> >
> > 1. We affirm that our Priorities are our users and the free software
> > community (Social Contract #4);
>
> Technically this is wrong. The priorities are "our users and free
> software". Not "the free software community". Please fix this; it means
> something different.
>
> > 2. We acknowledge that there is a lot of progress in the kernel firmware
> > issue; however, it is not yet finally sorted out;
> > 3. We give priority to the timely release of Etch over sorting every bit
> > out; for this reason, we will deliver firmware in udebs as long as it is
> > necessary for installation (like all udebs), and firmware included in
> > the kernel itself as part of Debian Etch, without further conditions.
>
> This ("without further conditions") would seem to promise that firmware will
> be included even if it doesn't actually carry a license which permits
> redistribution (as is the case for over 50 BLOBs in the upstream Linux
> kernel). Is this correct? Are you specifically ordering the ftpmasters to
> carry material which is technically improperly licensed?
Well, as said, it is no worse than the current situation, but given that the
upstream authors of those badly licenced firmwares are the ones who distribute
them under these licences in the first place, so it is highly doubtful they
will sue us over it, even if it was not a plain misinformed mistake.
As for users suing us, which i am not sure the GPL permits, well, we just
orient them upstream.
> If so, that's OK by me (it doesn't give me any legal li
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: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Wed, Aug 30, 2006 at 08:18:28PM -0400, Nathanael Nerode wrote: > Sven Luther wrote: > > > Since the firmware blobs are not derivative works of the kernel, but > > constitute mere agregation in the same binary format, the authors of other > > pieces of GPLed code fo the linux kernel cannot even sue us for > > distributing the kernel code with those GPL-violating binary BLOBs. > > This is not clear in the cases where the blobs are embedded directly into Please reread the discussion on debian-legal about this, where consensus was mostly found to support this idea, and also remember that we contacted broadcom with this analysis, who contacted their legal team, and i also mailed the FSF lawyers with it, and got no counter-claim to it. > the kernel, particularly when they're embedded in the same source files. > There's a case to be made that this is *not* mere aggregation, but creation > of an enhanced combination work which is derivative of both the firmware > and the other parts of the kernel. Simply putting files side by side is > mere aggregation -- what's happening with the drivers and firmware might be > mere aggregation, but nobody can be sure until a court case happens. Well, in the debian-legal discussion i gave plenty of counter examples, ranging from a firmware flasher (little C program with embedded firmware, exact same case as the kernel situation), to compressed binaries with uncompressing software embedded, passing by filesystem binaries containing both GPLed content as well as non-free content. So, all in all, unless you bring new evidence, there is really very little doubt about this, unless you want to consider your hardware a derived work of the linux kernel, but i doubt a judge will follow you on this one. IANAL, but there is a part of common sense and simple logic in most legal cases. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
Frederik Schueler wrote:
So, this is an "I'm OK with the actual GR but object strongly to the
overview" post.
> Overview:
>
> The Linux kernel source contains device drivers that ship with firmware
> files provided by the hardware manufacturer. They are uploaded during
> the driver initialization to the corresponding hardware device.
>
> Some of these binary image files are provided as a hexdump of register
> bank settings, others consist in fact of compiled binary code which is
> executed on the hardware device.
>
> Any device driver in the Linux kernel is freely available in source
> format and licensed under the GPL2. For many device drivers with
"For a few device drivers"
> attached firmware, the firmware image is freely distributable along
> with the corresponding driver.
>
> The most common source format for
> firmwares is the hexdump char array. It is almost impossible to
"It is usually, but not always, very easy to..."
> distinguish between register dumps and binary code without asking the
> device manufacturer who provided the firmware.
>
> Removing every firmware which is distributed as hexdump only will
"(if they are not moved to non-free)"
> cripple the kernel to an extent where it becomes unusable for most of
"for some of"
> our users, because popular network and scsi devices are among the
> drivers in question. Without these drivers, the user's system might not
> be installable at all.
OK, this was full of inaccuracies noted above. I have to strongly oppose
this characterization of the issues.
> The current situation:
>
> We achieved a lot of progress compared with the situation in 2.6.8 (the
> kernel that shipped with sarge). We were able to convince upstream that
> a firmware loader is a good thing, and that firmware and kernel code
> should be separated. This firmware loader was added in 2.6.13, and
> meanwhile, more than 40 drivers have been converted to the new
> infrastructure. However, this is not yet finished, and some important
> drivers still use the old method. There will be a day where we can drop
> the remaining legacy, but we are not there yet.
>
> Also, though the firmware loader allows us to put the firmware where it
> belongs to (main or non-free, depending on the case), the installer can
> as of now only take udebs from main. Fixing this is not too hard, but
> it is doubtful whether we can fix this in time for etch,
"because we are not willing to try to fix it and we have not given anyone
else sufficient information to"
Sorry to be so annoyed. I can't even find 'anna', which is supposedly the
module which needs to be fixed. Where do I download it from? I have asked
debian-boot on previous occasions.
> and we do not
> want to depend on that (and even then, we still would have non-free
> firmware, see above). But since there is lots of hardware which needs
> firmware for correct operation, the installer would not work for
> mainstream hardware otherwise.
>
> There are two ways how to deal with it:
> 1. Accept these issues as transitional issues for now; or
> 2. Delay etch for some serious time.
Like a month or two, maybe. If people actually bother to work on it, or to
accept other people's work on it.
> In our social contract, we promised that the users and the free software
> community are our priorities. We firmly believe that our users profit
> very much from releasing etch in time, and that this is important enough
> that we can accept the transitional status with having a few firmware
> images left in main that should belong somewhere else. Of course,
> everyone who wants to make the number of such firmware images as small
> as possible is welcome to help converting old firmware loaders to the
> new standard, and working on the Debian installer. We are happy if this
> issues become smaller or even vanishes, but we do not want this to be a
> release blocker.
OK, this is good. :-) Does this mean that the patches converting the tg3
driver to use firmware loading will be reaccepted?
> So, we propose this GR:
>
> 1. We affirm that our Priorities are our users and the free software
> community (Social Contract #4);
Technically this is wrong. The priorities are "our users and free
software". Not "the free software community". Please fix this; it means
something different.
> 2. We acknowledge that there is a lot of progress in the kernel firmware
> issue; however, it is not yet finally sorted out;
> 3. We give priority to the timely release of Etch over sorting every bit
> out; for this reason, we will deliver firmware in udebs as long as it is
> necessary for installation (like all udebs), and firmware included in
> the kernel itself as part of Debian Etch, without further conditions.
This ("without further conditions") would seem to promise that firmware will
be included even if it doesn't actually carry a license which permits
redistribution (as is the case for over 50 BLOBs in the upstream Linux
kernel). Is this corre
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Sven Luther wrote: > Since the firmware blobs are not derivative works of the kernel, but > constitute mere agregation in the same binary format, the authors of other > pieces of GPLed code fo the linux kernel cannot even sue us for > distributing the kernel code with those GPL-violating binary BLOBs. This is not clear in the cases where the blobs are embedded directly into the kernel, particularly when they're embedded in the same source files. There's a case to be made that this is *not* mere aggregation, but creation of an enhanced combination work which is derivative of both the firmware and the other parts of the kernel. Simply putting files side by side is mere aggregation -- what's happening with the drivers and firmware might be mere aggregation, but nobody can be sure until a court case happens. -- 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: The bigger issue is badly licensed blobs (was Re: Firmware poll
Steve Langasek wrote: > On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: > >> Debian needs to make a decision on how it will deal with this legal >> minefield. That is higher priority than the entire discussion going on >> right now, because it determines whether Debian will distribute these 53 >> BLOBs *at all*, in 'main' or in 'non-free'. > >> Oddly enough nobody has proposed a GR addressing this, > > Because voting is an absurd means of settling questions of legal > liability. It's the domain of the ftp team to determine whether we can > legally distribute a package on our mirrors. Actually, letting an overworked team of four with (to my knowledge) zero legal expertise settle questions of legal liability is pretty absurd too. I know this is Debian tradition, but it's worth thinking about whether it really makes sense. Debian-legal has very little legal expertise, and as a result the consensus errs on the side of caution at essentially all times with regard to copyright. Probably too much caution, but without getting an actual legal opinion, that seems like the right thing to do. Should the ftpmasters, who have even less legal expertise, ever take the risk of erring on the side of recklessness? (This risk is currently being taken with the mislicensed 'firmware' BLOBs.) Does this expose anyone but the ftp team to legal liability? Now, if the rest of Debian has repeatedly disavowed all responsibility, it may be that the ftp team and only the ftp team are *personally* liable if Debian makes an illegal distribution, and in that case it would make sense for them to determine such things. I'm not sure the ftpmasters are actually comfortatble with assuming personal legal liability for every package in Debian though. I wouldn't be! -- 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: kernel firmwares: GR proposal
Hello, Seconded, Regard Sylvain Le Gall On Wed, Aug 30, 2006 at 11:06:54PM +0200, Frederik Schueler wrote: > Overview: > > The Linux kernel source contains device drivers that ship with firmware > files provided by the hardware manufacturer. They are uploaded during > the driver initialization to the corresponding hardware device. > > Some of these binary image files are provided as a hexdump of register > bank settings, others consist in fact of compiled binary code which is > executed on the hardware device. > > Any device driver in the Linux kernel is freely available in source > format and licensed under the GPL2. For many device drivers with > attached firmware, the firmware image is freely distributable along > with the corresponding driver. The most common source format for > firmwares is the hexdump char array. It is almost impossible to > distinguish between register dumps and binary code without asking the > device manufacturer who provided the firmware. > > Removing every firmware which is distributed as hexdump only will > cripple the kernel to an extent where it becomes unusable for most of > our users, because popular network and scsi devices are among the > drivers in question. Without these drivers, the user's system might not > be installable at all. > > > The current situation: > > We achieved a lot of progress compared with the situation in 2.6.8 (the > kernel that shipped with sarge). We were able to convince upstream that > a firmware loader is a good thing, and that firmware and kernel code > should be separated. This firmware loader was added in 2.6.13, and > meanwhile, more than 40 drivers have been converted to the new > infrastructure. However, this is not yet finished, and some important > drivers still use the old method. There will be a day where we can drop > the remaining legacy, but we are not there yet. > > Also, though the firmware loader allows us to put the firmware where it > belongs to (main or non-free, depending on the case), the installer can > as of now only take udebs from main. Fixing this is not too hard, but > it is doubtful whether we can fix this in time for etch, and we do not > want to depend on that (and even then, we still would have non-free > firmware, see above). But since there is lots of hardware which needs > firmware for correct operation, the installer would not work for > mainstream hardware otherwise. > > There are two ways how to deal with it: > 1. Accept these issues as transitional issues for now; or > 2. Delay etch for some serious time. > > > In our social contract, we promised that the users and the free software > community are our priorities. We firmly believe that our users profit > very much from releasing etch in time, and that this is important enough > that we can accept the transitional status with having a few firmware > images left in main that should belong somewhere else. Of course, > everyone who wants to make the number of such firmware images as small > as possible is welcome to help converting old firmware loaders to the > new standard, and working on the Debian installer. We are happy if this > issues become smaller or even vanishes, but we do not want this to be a > release blocker. > > > So, we propose this GR: > > 1. We affirm that our Priorities are our users and the free software > community (Social Contract #4); > 2. We acknowledge that there is a lot of progress in the kernel firmware > issue; however, it is not yet finally sorted out; > 3. We give priority to the timely release of Etch over sorting every bit > out; for this reason, we will deliver firmware in udebs as long as it is > necessary for installation (like all udebs), and firmware included in > the kernel itself as part of Debian Etch, without further conditions. > > > We want to emphasize that the success of this GR is considered as > necessary by the kernel and release team for successfully delivering etch > in time (and to allow us a successful planning of that). > > > on behalf of the kernel- and release team > Frederik Schueler > > -- > ENOSIG signature.asc Description: Digital signature
Re: kernel firmwares: GR proposal
Seconded. On Wed, Aug 30, 2006 at 11:06:54PM +0200, Frederik Schueler wrote: > Overview: > > The Linux kernel source contains device drivers that ship with firmware > files provided by the hardware manufacturer. They are uploaded during > the driver initialization to the corresponding hardware device. > > Some of these binary image files are provided as a hexdump of register > bank settings, others consist in fact of compiled binary code which is > executed on the hardware device. > > Any device driver in the Linux kernel is freely available in source > format and licensed under the GPL2. For many device drivers with > attached firmware, the firmware image is freely distributable along > with the corresponding driver. The most common source format for > firmwares is the hexdump char array. It is almost impossible to > distinguish between register dumps and binary code without asking the > device manufacturer who provided the firmware. > > Removing every firmware which is distributed as hexdump only will > cripple the kernel to an extent where it becomes unusable for most of > our users, because popular network and scsi devices are among the > drivers in question. Without these drivers, the user's system might not > be installable at all. > > > The current situation: > > We achieved a lot of progress compared with the situation in 2.6.8 (the > kernel that shipped with sarge). We were able to convince upstream that > a firmware loader is a good thing, and that firmware and kernel code > should be separated. This firmware loader was added in 2.6.13, and > meanwhile, more than 40 drivers have been converted to the new > infrastructure. However, this is not yet finished, and some important > drivers still use the old method. There will be a day where we can drop > the remaining legacy, but we are not there yet. > > Also, though the firmware loader allows us to put the firmware where it > belongs to (main or non-free, depending on the case), the installer can > as of now only take udebs from main. Fixing this is not too hard, but > it is doubtful whether we can fix this in time for etch, and we do not > want to depend on that (and even then, we still would have non-free > firmware, see above). But since there is lots of hardware which needs > firmware for correct operation, the installer would not work for > mainstream hardware otherwise. > > There are two ways how to deal with it: > 1. Accept these issues as transitional issues for now; or > 2. Delay etch for some serious time. > > > In our social contract, we promised that the users and the free software > community are our priorities. We firmly believe that our users profit > very much from releasing etch in time, and that this is important enough > that we can accept the transitional status with having a few firmware > images left in main that should belong somewhere else. Of course, > everyone who wants to make the number of such firmware images as small > as possible is welcome to help converting old firmware loaders to the > new standard, and working on the Debian installer. We are happy if this > issues become smaller or even vanishes, but we do not want this to be a > release blocker. > > > So, we propose this GR: > > 1. We affirm that our Priorities are our users and the free software > community (Social Contract #4); > 2. We acknowledge that there is a lot of progress in the kernel firmware > issue; however, it is not yet finally sorted out; > 3. We give priority to the timely release of Etch over sorting every bit > out; for this reason, we will deliver firmware in udebs as long as it is > necessary for installation (like all udebs), and firmware included in > the kernel itself as part of Debian Etch, without further conditions. > > > We want to emphasize that the success of this GR is considered as > necessary by the kernel and release team for successfully delivering etch > in time (and to allow us a successful planning of that). > > > on behalf of the kernel- and release team > Frederik Schueler -- Prepare for tomorrow -- get ready. -- Edith Keeler, "The City On the Edge of Forever", stardate unknown signature.asc Description: Digital signature
Re: kernel firmwares: GR proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I second the below GR proposal. Friendly, Sven Luther || Overview: || || The Linux kernel source contains device drivers that ship with firmware || files provided by the hardware manufacturer. They are uploaded during || the driver initialization to the corresponding hardware device. || || Some of these binary image files are provided as a hexdump of register || bank settings, others consist in fact of compiled binary code which is || executed on the hardware device. || || Any device driver in the Linux kernel is freely available in source || format and licensed under the GPL2. For many device drivers with || attached firmware, the firmware image is freely distributable along || with the corresponding driver. The most common source format for || firmwares is the hexdump char array. It is almost impossible to || distinguish between register dumps and binary code without asking the || device manufacturer who provided the firmware. || || Removing every firmware which is distributed as hexdump only will || cripple the kernel to an extent where it becomes unusable for most of || our users, because popular network and scsi devices are among the || drivers in question. Without these drivers, the user's system might not || be installable at all. || || || The current situation: || || We achieved a lot of progress compared with the situation in 2.6.8 (the || kernel that shipped with sarge). We were able to convince upstream that || a firmware loader is a good thing, and that firmware and kernel code || should be separated. This firmware loader was added in 2.6.13, and || meanwhile, more than 40 drivers have been converted to the new || infrastructure. However, this is not yet finished, and some important || drivers still use the old method. There will be a day where we can drop || the remaining legacy, but we are not there yet. || || Also, though the firmware loader allows us to put the firmware where it || belongs to (main or non-free, depending on the case), the installer can || as of now only take udebs from main. Fixing this is not too hard, but || it is doubtful whether we can fix this in time for etch, and we do not || want to depend on that (and even then, we still would have non-free || firmware, see above). But since there is lots of hardware which needs || firmware for correct operation, the installer would not work for || mainstream hardware otherwise. || || There are two ways how to deal with it: || 1. Accept these issues as transitional issues for now; or || 2. Delay etch for some serious time. || || || In our social contract, we promised that the users and the free software || community are our priorities. We firmly believe that our users profit || very much from releasing etch in time, and that this is important enough || that we can accept the transitional status with having a few firmware || images left in main that should belong somewhere else. Of course, || everyone who wants to make the number of such firmware images as small || as possible is welcome to help converting old firmware loaders to the || new standard, and working on the Debian installer. We are happy if this || issues become smaller or even vanishes, but we do not want this to be a || release blocker. || || || So, we propose this GR: || || 1. We affirm that our Priorities are our users and the free software || community (Social Contract #4); || 2. We acknowledge that there is a lot of progress in the kernel firmware || issue; however, it is not yet finally sorted out; || 3. We give priority to the timely release of Etch over sorting every bit || out; for this reason, we will deliver firmware in udebs as long as it is || necessary for installation (like all udebs), and firmware included in || the kernel itself as part of Debian Etch, without further conditions. || || || We want to emphasize that the success of this GR is considered as || necessary by the kernel and release team for successfully delivering etch || in time (and to allow us a successful planning of that). || || || on behalf of the kernel- and release team || Frederik Schueler || || -- || ENOSIG -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE9gVk2WTeT3CRQaQRAkBiAJwMWRklUc4bX6wQJ/o0FFO6ipRRCwCeMgjT AjCrkNmQtTGU/L4ih2SeWEI= =gAca -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: kernel firmwares: GR proposal
Hi Frederik! Seconded. Bas. You wrote: > Overview: > > The Linux kernel source contains device drivers that ship with firmware > files provided by the hardware manufacturer. They are uploaded during > the driver initialization to the corresponding hardware device. > > Some of these binary image files are provided as a hexdump of register > bank settings, others consist in fact of compiled binary code which is > executed on the hardware device. > > Any device driver in the Linux kernel is freely available in source > format and licensed under the GPL2. For many device drivers with > attached firmware, the firmware image is freely distributable along > with the corresponding driver. The most common source format for > firmwares is the hexdump char array. It is almost impossible to > distinguish between register dumps and binary code without asking the > device manufacturer who provided the firmware. > > Removing every firmware which is distributed as hexdump only will > cripple the kernel to an extent where it becomes unusable for most of > our users, because popular network and scsi devices are among the > drivers in question. Without these drivers, the user's system might not > be installable at all. > > > The current situation: > > We achieved a lot of progress compared with the situation in 2.6.8 (the > kernel that shipped with sarge). We were able to convince upstream that > a firmware loader is a good thing, and that firmware and kernel code > should be separated. This firmware loader was added in 2.6.13, and > meanwhile, more than 40 drivers have been converted to the new > infrastructure. However, this is not yet finished, and some important > drivers still use the old method. There will be a day where we can drop > the remaining legacy, but we are not there yet. > > Also, though the firmware loader allows us to put the firmware where it > belongs to (main or non-free, depending on the case), the installer can > as of now only take udebs from main. Fixing this is not too hard, but > it is doubtful whether we can fix this in time for etch, and we do not > want to depend on that (and even then, we still would have non-free > firmware, see above). But since there is lots of hardware which needs > firmware for correct operation, the installer would not work for > mainstream hardware otherwise. > > There are two ways how to deal with it: > 1. Accept these issues as transitional issues for now; or > 2. Delay etch for some serious time. > > > In our social contract, we promised that the users and the free software > community are our priorities. We firmly believe that our users profit > very much from releasing etch in time, and that this is important enough > that we can accept the transitional status with having a few firmware > images left in main that should belong somewhere else. Of course, > everyone who wants to make the number of such firmware images as small > as possible is welcome to help converting old firmware loaders to the > new standard, and working on the Debian installer. We are happy if this > issues become smaller or even vanishes, but we do not want this to be a > release blocker. > > > So, we propose this GR: > > 1. We affirm that our Priorities are our users and the free software > community (Social Contract #4); > 2. We acknowledge that there is a lot of progress in the kernel firmware > issue; however, it is not yet finally sorted out; > 3. We give priority to the timely release of Etch over sorting every bit > out; for this reason, we will deliver firmware in udebs as long as it is > necessary for installation (like all udebs), and firmware included in > the kernel itself as part of Debian Etch, without further conditions. > > > We want to emphasize that the success of this GR is considered as > necessary by the kernel and release team for successfully delivering etch > in time (and to allow us a successful planning of that). > > > on behalf of the kernel- and release team > Frederik Schueler > > -- > ENOSIG -- Kind regards, ++ | Bas Zoetekouw | GPG key: 0644fab7 | || Fingerprint: c1f5 f24c d514 3fec 8bf6 | | [EMAIL PROTECTED], [EMAIL PROTECTED] | a2b1 2bae e41f 0644 fab7 | ++ signature.asc Description: Digital signature
Re: kernel firmwares: GR proposal
I second the proposal cited below. also sprach Frederik Schueler <[EMAIL PROTECTED]> [2006.08.30.2306 +0200]: > Overview: > > The Linux kernel source contains device drivers that ship with firmware > files provided by the hardware manufacturer. They are uploaded during > the driver initialization to the corresponding hardware device. > > Some of these binary image files are provided as a hexdump of register > bank settings, others consist in fact of compiled binary code which is > executed on the hardware device. > > Any device driver in the Linux kernel is freely available in source > format and licensed under the GPL2. For many device drivers with > attached firmware, the firmware image is freely distributable along > with the corresponding driver. The most common source format for > firmwares is the hexdump char array. It is almost impossible to > distinguish between register dumps and binary code without asking the > device manufacturer who provided the firmware. > > Removing every firmware which is distributed as hexdump only will > cripple the kernel to an extent where it becomes unusable for most of > our users, because popular network and scsi devices are among the > drivers in question. Without these drivers, the user's system might not > be installable at all. > > > The current situation: > > We achieved a lot of progress compared with the situation in 2.6.8 (the > kernel that shipped with sarge). We were able to convince upstream that > a firmware loader is a good thing, and that firmware and kernel code > should be separated. This firmware loader was added in 2.6.13, and > meanwhile, more than 40 drivers have been converted to the new > infrastructure. However, this is not yet finished, and some important > drivers still use the old method. There will be a day where we can drop > the remaining legacy, but we are not there yet. > > Also, though the firmware loader allows us to put the firmware where it > belongs to (main or non-free, depending on the case), the installer can > as of now only take udebs from main. Fixing this is not too hard, but > it is doubtful whether we can fix this in time for etch, and we do not > want to depend on that (and even then, we still would have non-free > firmware, see above). But since there is lots of hardware which needs > firmware for correct operation, the installer would not work for > mainstream hardware otherwise. > > There are two ways how to deal with it: > 1. Accept these issues as transitional issues for now; or > 2. Delay etch for some serious time. > > > In our social contract, we promised that the users and the free software > community are our priorities. We firmly believe that our users profit > very much from releasing etch in time, and that this is important enough > that we can accept the transitional status with having a few firmware > images left in main that should belong somewhere else. Of course, > everyone who wants to make the number of such firmware images as small > as possible is welcome to help converting old firmware loaders to the > new standard, and working on the Debian installer. We are happy if this > issues become smaller or even vanishes, but we do not want this to be a > release blocker. > > > So, we propose this GR: > > 1. We affirm that our Priorities are our users and the free software > community (Social Contract #4); > 2. We acknowledge that there is a lot of progress in the kernel firmware > issue; however, it is not yet finally sorted out; > 3. We give priority to the timely release of Etch over sorting every bit > out; for this reason, we will deliver firmware in udebs as long as it is > necessary for installation (like all udebs), and firmware included in > the kernel itself as part of Debian Etch, without further conditions. > > > We want to emphasize that the success of this GR is considered as > necessary by the kernel and release team for successfully delivering etch > in time (and to allow us a successful planning of that). > > > on behalf of the kernel- and release team > Frederik Schueler > > -- > ENOSIG -- Please do not send copies of list mail to me; I read the list! .''`. martin f. krafft <[EMAIL PROTECTED]> : :' :proud Debian developer, author, administrator, and user `. `'` http://people.debian.org/~madduck http://debiansystem.info `- Debian - when you have better things to do than fixing systems now I lay me back to sleep. the speaker's dull; the subject's deep. if he should stop before I wake, give me a nudge for goodness' sake. signature.asc Description: Digital signature (GPG/PGP)
kernel firmwares: GR proposal
Overview: The Linux kernel source contains device drivers that ship with firmware files provided by the hardware manufacturer. They are uploaded during the driver initialization to the corresponding hardware device. Some of these binary image files are provided as a hexdump of register bank settings, others consist in fact of compiled binary code which is executed on the hardware device. Any device driver in the Linux kernel is freely available in source format and licensed under the GPL2. For many device drivers with attached firmware, the firmware image is freely distributable along with the corresponding driver. The most common source format for firmwares is the hexdump char array. It is almost impossible to distinguish between register dumps and binary code without asking the device manufacturer who provided the firmware. Removing every firmware which is distributed as hexdump only will cripple the kernel to an extent where it becomes unusable for most of our users, because popular network and scsi devices are among the drivers in question. Without these drivers, the user's system might not be installable at all. The current situation: We achieved a lot of progress compared with the situation in 2.6.8 (the kernel that shipped with sarge). We were able to convince upstream that a firmware loader is a good thing, and that firmware and kernel code should be separated. This firmware loader was added in 2.6.13, and meanwhile, more than 40 drivers have been converted to the new infrastructure. However, this is not yet finished, and some important drivers still use the old method. There will be a day where we can drop the remaining legacy, but we are not there yet. Also, though the firmware loader allows us to put the firmware where it belongs to (main or non-free, depending on the case), the installer can as of now only take udebs from main. Fixing this is not too hard, but it is doubtful whether we can fix this in time for etch, and we do not want to depend on that (and even then, we still would have non-free firmware, see above). But since there is lots of hardware which needs firmware for correct operation, the installer would not work for mainstream hardware otherwise. There are two ways how to deal with it: 1. Accept these issues as transitional issues for now; or 2. Delay etch for some serious time. In our social contract, we promised that the users and the free software community are our priorities. We firmly believe that our users profit very much from releasing etch in time, and that this is important enough that we can accept the transitional status with having a few firmware images left in main that should belong somewhere else. Of course, everyone who wants to make the number of such firmware images as small as possible is welcome to help converting old firmware loaders to the new standard, and working on the Debian installer. We are happy if this issues become smaller or even vanishes, but we do not want this to be a release blocker. So, we propose this GR: 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. We acknowledge that there is a lot of progress in the kernel firmware issue; however, it is not yet finally sorted out; 3. We give priority to the timely release of Etch over sorting every bit out; for this reason, we will deliver firmware in udebs as long as it is necessary for installation (like all udebs), and firmware included in the kernel itself as part of Debian Etch, without further conditions. We want to emphasize that the success of this GR is considered as necessary by the kernel and release team for successfully delivering etch in time (and to allow us a successful planning of that). on behalf of the kernel- and release team Frederik Schueler -- ENOSIG signature.asc Description: Digital signature
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Wed, Aug 30, 2006 at 05:16:29PM +0200, Toni Mueller wrote: > > > Hello, > > On Wed, 30.08.2006 at 09:27:21 +0200, Marco d'Itri <[EMAIL PROTECTED]> wrote: > > On Aug 30, Nathanael Nerode <[EMAIL PROTECTED]> wrote: > > > Debian must decide whether it wants to ship BLOBs with licensing which > > > technically does not permit redistribution. At least 53 blobs have this > > > problem. Many of them are licensed under the GPL, but without source code > > > provided. Since the GPL only grants permission to distribute if you > > > provide source code, the GPL grants no permission to distribute in these > > > cases. > > Many people disagree with this interpretation. > > I'm not a lawyer, but my take on this is that if someone ships you a > BLOB under the GPL, you have the legal right to demand sources from > him. So, in other words, I think Debian (or SPI? or FSF?) *could* make > a real hurricane in the press (and courts) by trying to wrestle source > code from said vendors. If that'd be good or bad for Debian, I don't > know, but it will be very expensive and time consuming. My own understanding, and we discussed this on -legal when we aproached broadcom about the tg3 licencing, is that this is not the case, not really anyway. What happens, is that we, debian have not the possibility to provide those sources, and as thus, simply lose all rights per the GPL to distribute the source code in question, and thus what could happen, would be for the copyright holder to sue us for not respecting the GPL clauses. Obviously, since he doesn't do so himself, he would lose anyway, so the point is mostly moot, but the GPL itself says it doesn't allow us to distribute the problematic code in those cases. Since the firmware blobs are not derivative works of the kernel, but constitute mere agregation in the same binary format, the authors of other pieces of GPLed code fo the linux kernel cannot even sue us for distributing the kernel code with those GPL-violating binary BLOBs. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Hello, On Wed, 30.08.2006 at 09:27:21 +0200, Marco d'Itri <[EMAIL PROTECTED]> wrote: > On Aug 30, Nathanael Nerode <[EMAIL PROTECTED]> wrote: > > Debian must decide whether it wants to ship BLOBs with licensing which > > technically does not permit redistribution. At least 53 blobs have this > > problem. Many of them are licensed under the GPL, but without source code > > provided. Since the GPL only grants permission to distribute if you > > provide source code, the GPL grants no permission to distribute in these > > cases. > Many people disagree with this interpretation. I'm not a lawyer, but my take on this is that if someone ships you a BLOB under the GPL, you have the legal right to demand sources from him. So, in other words, I think Debian (or SPI? or FSF?) *could* make a real hurricane in the press (and courts) by trying to wrestle source code from said vendors. If that'd be good or bad for Debian, I don't know, but it will be very expensive and time consuming. Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Wed, Aug 30, 2006 at 09:00:27AM +0200, Raphael Hertzog wrote: > On Wed, 30 Aug 2006, Mike Hommey wrote: > > On Tue, Aug 29, 2006 at 07:17:47PM -0700, Steve Langasek <[EMAIL > > PROTECTED]> wrote: > > > On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: > > > > > > > Debian needs to make a decision on how it will deal with this legal > > > > minefield. That is higher priority than the entire discussion going on > > > > right now, because it determines whether Debian will distribute these 53 > > > > BLOBs *at all*, in 'main' or in 'non-free'. > > > > > > > Oddly enough nobody has proposed a GR addressing this, > > > > > > Because voting is an absurd means of settling questions of legal > > > liability. > > > It's the domain of the ftp team to determine whether we can legally > > > distribute a package on our mirrors. > > > > So, all in all, all this fuss for seven blobs ? waw, what a waste of > > time. > > 53 + 7 = 60. Re-read Nathanael's mail. The blobs that are concerned by all the discussion that has happened so far, and wasted a lot of time, are 7. The 53 are those that have licenses that technically don't allow redistribution. > Please Mike, you have lately a tendency to inflame discussions for > nothing. You've used me to expect better from you. I'm just pissed about all this waste of time discussing in the void while a release is "supposed" to happen in 3 months. And here I'm not only talking about this particular thread. Mike PS: Don't worry, you won't hear a lot from me since I'll be on vacation from saturday for almost 3 weeks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Wed, Aug 30, 2006 at 09:27:21AM +0200, Marco d'Itri wrote: > On Aug 30, Nathanael Nerode <[EMAIL PROTECTED]> wrote: > > > Debian must decide whether it wants to ship BLOBs with licensing which > > technically does not permit redistribution. At least 53 blobs have this > > problem. Many of them are licensed under the GPL, but without source code > > provided. Since the GPL only grants permission to distribute if you > > provide source code, the GPL grants no permission to distribute in these > > cases. > Many people disagree with this interpretation. A few very vocal people do. I guess they can be counted on the fingers of both hands or so. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Aug 30, Nathanael Nerode <[EMAIL PROTECTED]> wrote: > Debian must decide whether it wants to ship BLOBs with licensing which > technically does not permit redistribution. At least 53 blobs have this > problem. Many of them are licensed under the GPL, but without source code > provided. Since the GPL only grants permission to distribute if you > provide source code, the GPL grants no permission to distribute in these > cases. Many people disagree with this interpretation. > Oddly enough nobody has proposed a GR addressing this, and Debian continues > to ship 47 improperly licensed files in linux-2.6. If I were SCO, I'd buy > up the copyrights to them from the original companies, and then I'd have a > real case for a lawsuit. Not really. What effects do you think a lawsuit about this would have? -- ciao, Marco signature.asc Description: Digital signature
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Wed, 30 Aug 2006, Mike Hommey wrote: > On Tue, Aug 29, 2006 at 07:17:47PM -0700, Steve Langasek <[EMAIL PROTECTED]> > wrote: > > On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: > > > > > Debian needs to make a decision on how it will deal with this legal > > > minefield. That is higher priority than the entire discussion going on > > > right now, because it determines whether Debian will distribute these 53 > > > BLOBs *at all*, in 'main' or in 'non-free'. > > > > > Oddly enough nobody has proposed a GR addressing this, > > > > Because voting is an absurd means of settling questions of legal liability. > > It's the domain of the ftp team to determine whether we can legally > > distribute a package on our mirrors. > > So, all in all, all this fuss for seven blobs ? waw, what a waste of > time. 53 + 7 = 60. Please Mike, you have lately a tendency to inflame discussions for nothing. You've used me to expect better from you. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
