Sven wrote -
>I already did so, but let's try again :
>We consider for the purpose of this GR, firmware to be :
> [blah blah]
Hey, let's make it easy: let's approve shipping the same
firmware we shipped in sarge! I can list the 45 files
covered, so there's no ambiguity, no regression in hardware
On Thu, Aug 31, 2006 at 05:33:42PM -0700, Thomas Bushnell BSG wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
>
> > Well, it would be part of a driver aimed at driving the main cpu, yes, it is
> > not a peripheral processor, but the role played by the microcode is
> > peripheral
> > to the main
Sven Luther <[EMAIL PROTECTED]> writes:
> Well, it would be part of a driver aimed at driving the main cpu, yes, it is
> not a peripheral processor, but the role played by the microcode is peripheral
> to the main flow of the kernel code.
Do you really not see why this is hopelessly vague?
>>
On Thu, Aug 31, 2006 at 04:50:47PM -0700, Thomas Bushnell BSG wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
>
> >> Microcode for the main processor does not match (2) or (3). So no,
> >> there is no obvious likeness between microcode for the main processor
> >> and the "rest of the stuff".
> >
Sven Luther <[EMAIL PROTECTED]> writes:
>> Microcode for the main processor does not match (2) or (3). So no,
>> there is no obvious likeness between microcode for the main processor
>> and the "rest of the stuff".
>
> Microcode does run in a lower level of the cpu than the main code, as thus you
I second the GR proposal below.
Em Qua, 2006-08-30 às 23:06 +0200, Frederik Schueler escreveu:
> 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 corres
On Thu, Aug 31, 2006 at 03:03:13PM -0700, Thomas Bushnell BSG wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
>
> > Nope, i am not sure we have such microcode in the kernel tree. It certainly
> > fits the same category as the rest of the stuff, and i think the above
> > identifies perfectly which
Jacob Hallen <[EMAIL PROTECTED]> writes:
> My personal experience is that the larger the company, the smaller the
> interest in change will be and they will only change when outside pressure
> forces them to. This leads me to believe that the quickest way to a future
> where we can distribute f
Sven Luther <[EMAIL PROTECTED]> writes:
> Nope, i am not sure we have such microcode in the kernel tree. It certainly
> fits the same category as the rest of the stuff, and i think the above
> identifies perfectly which firmware blobs we are speakign about.
Huh? Microcode for the main processor
On Thu, Aug 31, 2006 at 05:55:43PM -0400, Joey Hess wrote:
> Joey Hess wrote:
> > 1. The archive did not support a non-free section for udebs until today.
>
> Done.
>
> > 2. libd-i and anna do not support multiple udeb sources, but can only
> >pull from one at a time; noone has yet fixed this
On Thu, Aug 31, 2006 at 09:02:25PM +0200, Jacob Hallen wrote:
Nice analysis, but there is one completely wrong way to do this.
> My personal experience is that the larger the company, the smaller the
> interest in change will be and they will only change when outside pressure
> forces them to.
Joey Hess wrote:
> 1. The archive did not support a non-free section for udebs until today.
Done.
> 2. libd-i and anna do not support multiple udeb sources, but can only
>pull from one at a time; noone has yet fixed this
mrvn pointed out that true multiple source support isn't needed for thi
On Thu, Aug 31, 2006 at 02:43:59PM -0700, Thomas Bushnell BSG wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
>
> > No. The "sourceless firmware blobs" mentioned in this GR, are identified as
> > those programs or register dumps or fpga config files, which are uploaded
> > to a
> > peripheral pr
Sven Luther <[EMAIL PROTECTED]> writes:
> No. The "sourceless firmware blobs" mentioned in this GR, are identified as
> those programs or register dumps or fpga config files, which are uploaded to a
> peripheral processor, and are part of a linux kernel driver in some way,
> usually an array of ch
I think the discussions around the various GR proposals miss some important
points.
Hardware manufacturers are in the habit of keeping their firmware
closed-source. Some firmware contains algorithmic code and should be
categorised as programs while others are plain data that control settings fo
On Thu, Aug 31, 2006 at 01:10:35PM -0700, Thomas Bushnell BSG wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
>
> >> So how do I know whether something is "firmware" instead of just
> >> ordinary sourceless code?
> >
> > Ah, well, i would say that the definition you search here are :
> >
> > he
Sven Luther <[EMAIL PROTECTED]> writes:
>> So how do I know whether something is "firmware" instead of just
>> ordinary sourceless code?
>
> Ah, well, i would say that the definition you search here are :
>
> hexdump sourceless blobs which are uploaded to a peripheral device.
So you would say t
On Thu, Aug 31, 2006 at 11:05:10AM -0700, Thomas Bushnell BSG wrote:
> Sven Luther <[EMAIL PROTECTED]> writes:
>
> >> 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.
Raphael Hertzog <[EMAIL PROTECTED]> writes:
> So I don't think it's a 3:1 issue. We're not changing our goals, only
> clarifying the timeline and acknowledging that the etch timeframe is too
> short for us to reach this goal.
I don't believe it. We already clarified the timeline, and created a
p
Sven Luther <[EMAIL PROTECTED]> writes:
>> 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.
>
> Well, in this case, firmware is clearly the firmware blobs actually into t
[EMAIL PROTECTED] wrote:
>> 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!
I did. And it's not part of
Enrico Zini writes:
>
>On Wed, Aug 30, 2006 at 11:06:54PM +0200, Frederik Schueler wrote:
>>
>> 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 Thu, Aug 31, 2006 at 10:30:07AM +0100, MJ Ray wrote:
> [-devel trimmed]
>
> Sven Luther <[EMAIL PROTECTED]> wrote:
> > 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 a
Steve Langasek <[EMAIL PROTECTED]> wrote: [...]
> On Wed, Aug 30, 2006 at 08:26:56PM -0400, Nathanael Nerode wrote:
> > Should the ftpmasters, who have even less legal expertise,
>
> Judging by some of the nonsense that debian-legal is typically riddled with,
It's generally quite easy to spot the
[-devel trimmed]
Sven Luther <[EMAIL PROTECTED]> wrote:
> 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
Le jeu 31 août 2006 09:50, Enrico Zini a écrit :
> ...and get Lars tatooed! :)
what an unfair way to get the vote biased for that proposal ! :)
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://ww
Qui, 2006-08-31 às 09:19 +0100, Daniel Ruoso escreveu:
> Qua, 2006-08-30 às 23:06 +0200, Frederik Schueler escreveu:
> > 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 lo
Qua, 2006-08-30 às 23:06 +0200, Frederik Schueler escreveu:
> 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 ye
On Wed, Aug 30, 2006 at 10:00:43PM -0400, David Nusinow wrote:
> 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 po
On Thu, Aug 31, 2006 at 09:21:12AM +0200, Raphael Hertzog wrote:
> Hi,
>
> On Wed, 30 Aug 2006, Thomas Bushnell BSG wrote:
> > Further, because this amounts to a decision to disregard the SC, it
> > should require a 3:1 majority.
>
> It's not disregarding the SC, it's clarifying the fact that we
On Wed, Aug 30, 2006 at 08:47:08PM -0400, Nathanael Nerode wrote:
> 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 provid
On Wed, Aug 30, 2006 at 10:00:43PM -0400, David Nusinow wrote:
> 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 po
On Wed, Aug 30, 2006 at 11:06:54PM +0200, Frederik Schueler wrote:
Seconded.
> 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
Hi,
On Wed, 30 Aug 2006, Thomas Bushnell BSG wrote:
> Further, because this amounts to a decision to disregard the SC, it
> should require a 3:1 majority.
It's not disregarding the SC, it's clarifying the fact that we need more
time to create the proper infrastructure that will allow us to suppor
On Wed, Aug 30, 2006 at 10:42:12PM -0700, Thomas Bushnell BSG wrote:
> 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 fi
On Thu, Aug 31, 2006 at 12:48:35AM -0400, Nathanael Nerode wrote:
> Sven Luther wrote:
> > 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 t
On Thu, Aug 31, 2006 at 01:01:45AM -0400, Nathanael Nerode wrote:
> Sven Luther wrote:
> > 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 b
On Wed, Aug 30, 2006 at 10:59:25PM -0700, Thomas Bushnell BSG wrote:
> 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
On Wed, Aug 30, 2006 at 09:36:53PM -0400, David Nusinow wrote:
> 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
> >
On Thu, Aug 31, 2006 at 12:15:20AM -0400, Nathanael Nerode wrote:
> 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.
FWIW, there's a few things I'd love to see legal opinions on too,
in
40 matches
Mail list logo
