Re: on firmware (possible proposal)

[Johannes Wiedersich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Manoj Srivastava wrote:
>> -- [Forward] -
>> From: Sven Luther <[EMAIL PROTECTED]>
>> Date: Thu, 13 Nov 2008 21:01:13 +0100
> 
>>   - code uploaded into another cpu (a device cpu, not a SMP cpu of some
>> kind) does not run in the same memory space, and can thus not impact
>> the main software running on the host CPU.
> 
> Impacting other software has very little to do with the
>  desirability of freedom of software.

>>   - code uploaded on a device cpu, is in no way less free than the case
>> where said code would be found in a flash rom or something, on the
>> contrary in some way it is more free than those cases.
> 
> But debian does not distribute the latter, so the fact that the
>  software being distributed is more free than some very non-free
>  software not distributed by debian has dubious value.

Manoj, Please read my post [1]. I suggest that the firmware is
distributed outside 'main', but within a new section: 'sourceless'.
'sourceless' is not free software, but instead is a rather restricted
sub-set of 'non-free'. See it like this: it gives users the option of
using sourceless firmware without opening the full Pandorra's box of
'non-free'. Nothing will be installed without explicitly informing the
user and asking for her/his consent to install the sourceless stuff. It
won't happen behind the user's back and they have the choice of yes or no.

I really don't like the idea that there are 'official' and 'unoffical'
installation media and that d-u will be consequently flooded by users
with installation issues.

A typical response might look like:
"Oh, yes it's well known that the official disks won't work with your
hardware. Just download the unofficial ones from www.foo.bar [*] and add
'non-free' to your 'sources.list'"

I'd rather see the debian project supporting their users and offering a
truly debian way of installing debian on both 'good' and problematic
hardware.

Just MHO.

> What shall we do with the cell, BTW? It has multiple processing 
> units, and the central processing usint, if one may call it that, si 
> the dispatcher, which does little work. Would the software that runs 
> on the other processing units be considered to have different needs
> of freedom? Why

In my first draft of [1], I actually had a formulation that said that
the sourceless stuff is not allowed to add new functionality to the OS.
What I mean with this is best explained with an example, actually two:

A wireless network interface provides network functionality to the OS
like some ordnary network interface. For the CPU or the hard disk or the
OS per se it is just the same, whether the data arrive via a cable
connection or a wireless connection; for the user of the computer, of
course both are not the same.

If a GPS module just sends qualified plain ascii data (or any other set
of standardized data) over a serial port or via an usb cable, it does
not provide extra fuctionality to the OS and its firmware need not be
open source in order to qualify for inclusion in 'sourceless'. If the
GPS module, however, talks binary gibberish and thus requires some other
closed source software or firmware in order to be interpreted by the OS,
than it DOES NOT qualify for the 'sourceless' section and has to remain
in 'non-free'.

You could also view this from the other way around: There must not be
any software in 'main' that would not work (at least on some hardware)
if the 'sourceless' stuff is not present. I don't notice any difference,
if my laptop is connected via the free ethernet card or the non-free
wireless (the transfer speed is limited by my dsl-provider). On the
other hand, compiz functionality is different with or without 3D.

I considered this to be to cumbersome to be added. If anyone has
better means of expressing this simple and unambiguously: Please go ahead!

The addition of a 'sourceless' section just supports our priorities for
free software. Some non-free firmware, unfortunately, is required on
some hardware just to install all the free software in 'main'.

Cheers,

Johannes

[1] http://lists.debian.org/debian-vote/2008/11/msg00132.html

[*] Replace www.foo.bar with the typical result of a google search on
'I'm feeling lucky'.

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkdRz0ACgkQC1NzPRl9qEUUQgCfQSiSQdMMIuCNPVlO7og+budC
71AAnjUtA9pXeoULl/vqMiwS8q8IpASa
=jtlX
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: For our own good: splitting the vote. Thoughts?

[Neil McGovern]

On Thu, Nov 13, 2008 at 01:23:42PM +0100, Robert Millan wrote:
> On the contrary.  It is excess of overlapping options that prompt for 
> strategic
> voting.  For example, if I don't care much between option A and option B, but
> prefer either of them to option C

So, your opinion would be 
ABC
112

> I might give equal weight to A and B in order
> to prevent circular ambiguities.
> 

As in:
ABC
112

?

Neil
-- 
 If stockhom sees my banana, he will want to eat it


signature.asc
Description: Digital signature

Re: on firmware (possible proposal)

[Stephen Gran]

This one time, at band camp, Peter Palfrader said:
> 
> | Firmware is data that is uploaded to hardware components, not designed to be
> | run on the host CPU.  Often this firmware is already required at install 
> time
> | in order to use network or storage devices.
> | 
> | Unfortunately such firmware often is distributed as BLOBs, with no source or
> | further documentation that lets us learn how it works or interacts with the
> | hardware in question.  By excluding such firmware from Debian we exclude
> | users that require such devices from installing our operating system, or
> | make it unnecessarily hard for them.
> | 
> | Therefore the Debian project resolves that
> |  a) firmware in Debian does not have to come with source.  While we do
> | prefer firmware that comes with source and documentation we will not
> | require it,
> |  b) we however do require all other freedoms that the DFSG mandate from
> | components of our operating system, and
> |  c) such firmware can and should be part of our official installation media.

This one time, at band camp, Peter Palfrader said:
> | Firmware is data that is loaded into hardware components in order to
> | make the component function properly.  It is not code that is run on
> | the host CPU.

I would second this with the amendement noted.

Cheers,
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: on firmware (possible proposal)

[Frans Pop]

Peter Palfrader wrote:
> I'm considering formally proposing this GR (option):

I'm certainly in favor of Debian going in this direction. Ideals are fine, 
but castrating the distribution for them is taking things to far. IMO we 
can still strife and work to have more source made available to the 
community without alienating users by making it needlessly hard to 
install Debian or find important pieces of software.

One comment on the proposed text.
 
> | Firmware is data that is uploaded to hardware components, not designed
> | to be run on the host CPU.  Often this firmware is already required at
> | install time in order to use network or storage devices.

"Firmware is data [...]"

This has been the source of much discussion in the past IIRC. In some 
cases it is true and firmware is merely some data tables with settings, 
but in many cases firmware is executed on some CPU in the device.

Would you consider s/data/software/ to avoid discussions on that point? 
For reading the DFSG the general viewpoint seems to be "anything that's 
not hardware is software".

Cheers,
FJP


signature.asc
Description: This is a digitally signed message part.

Re: on firmware (possible proposal)

[Robert Millan]

On Fri, Nov 14, 2008 at 12:29:20AM -0600, Manoj Srivastava wrote:
> >   - code uploaded into another cpu (a device cpu, not a SMP cpu of some
> > kind) does not run in the same memory space, and can thus not impact
> > the main software running on the host CPU.
> 
> Impacting other software has very little to do with the
>  desirability of freedom of software.

It often can, though.  You can't really tell if the firmware for your network
card is using DMA to send away your private data in unaccounted frames.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: For our own good: splitting the vote. Thoughts?

[Robert Millan]

On Fri, Nov 14, 2008 at 09:56:06AM +, Neil McGovern wrote:
> On Thu, Nov 13, 2008 at 01:23:42PM +0100, Robert Millan wrote:
> > On the contrary.  It is excess of overlapping options that prompt for 
> > strategic
> > voting.  For example, if I don't care much between option A and option B, 
> > but
> > prefer either of them to option C
> 
> So, your opinion would be 
> ABC
> 112

No, that would be my strategical vote.  My opinion could be e.g. 123.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: on firmware (possible proposal)

[Peter Palfrader]

On Fri, 14 Nov 2008, Frans Pop wrote:

> > | Firmware is data that is uploaded to hardware components, not designed
> > | to be run on the host CPU.  Often this firmware is already required at
> > | install time in order to use network or storage devices.
> 
> "Firmware is data [...]"

Firmware is like porn, I know it when I see it. :)

This isn't meant to be an exact definition, but more of a guideline.
That being said, if s/data/software/ makes you happy then we can do
that.

Also, I was asked to s/BLOB/blob/ which seems fine to me too.

Unless anything comes up I'll propose this later today.


Thanks,
-- 
   |  .''`.  ** Debian GNU/Linux **
  Peter Palfrader  | : :' :  The  universal
 http://www.palfrader.org/ | `. `'  Operating System
   |   `-http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: on firmware (possible proposal)

[Robert Millan]

On Fri, Nov 14, 2008 at 04:56:38PM +0100, Peter Palfrader wrote:
> > 
> > "Firmware is data [...]"
> 
> Firmware is like porn, I know it when I see it. :)
> 
> This isn't meant to be an exact definition, but more of a guideline.
> That being said, if s/data/software/ makes you happy then we can do
> that.

Why not refer to it as "microcode" instead?  This is far less ambigous, as
"microcontroller" is a more specific term than "processor".

> Also, I was asked to s/BLOB/blob/ which seems fine to me too.

May I suggest "so-called \"blobs\"" or some indication that "blob" is an
informal term?

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: For our own good: splitting the vote. Thoughts?

[Neil McGovern]

On Fri, Nov 14, 2008 at 04:50:14PM +0100, Robert Millan wrote:
> On Fri, Nov 14, 2008 at 09:56:06AM +, Neil McGovern wrote:
> > On Thu, Nov 13, 2008 at 01:23:42PM +0100, Robert Millan wrote:
> > > On the contrary.  It is excess of overlapping options that prompt for 
> > > strategic
> > > voting.  For example, if I don't care much between option A and option B, 
> > > but
> > > prefer either of them to option C
> > 
> > So, your opinion would be 
> > ABC
> > 112
> 
> No, that would be my strategical vote.  My opinion could be e.g. 123.
> 

So vote like that. What's the advantage to you in voting 112?

Oh, and please follow the list code of conduct and stop cc-ing me.

Neil
-- 
* stockholm bangs head against budget
 outsch
 h01ger: it is still very soft, i did not hurt myself
 stockholm: But you bled on the budget, and now it's red again!


signature.asc
Description: Digital signature

Re: on firmware (possible proposal)

[Johannes Wiedersich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Robert Millan wrote:
> May I suggest "so-called \"blobs\"" or some indication that "blob" is an
> informal term?

Informal like http://en.wikipedia.org/wiki/Binary_blob ?

- From there it appears it is better described as 'binary blob' in order
not to confuse it with the 'Binary Large OBject' [1] of databases.

Johannes

[1] http://en.wikipedia.org/wiki/BLOB
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkdpbkACgkQC1NzPRl9qEUhHwCeJvcS2neZ3O+rqHK+j1HQHqoi
+jEAniWnKsu9Ljds0SfOC+v0GOks/Gzs
=AGKW
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: on firmware (possible proposal)

[Ean Schuessler]

- "Frans Pop" <[EMAIL PROTECTED]> wrote:

> I'm certainly in favor of Debian going in this direction. Ideals are fine, 
> but castrating the distribution for them is taking things to far. IMO we 
> can still strife and work to have more source made available to the 
> community without alienating users by making it needlessly hard to 
> install Debian or find important pieces of software.

But you have to see that castrating the ideals of the project is just as 
damaging as these distribution problems are. I believe Debian has remained 
important over time because, despite our various social failings, they 
*respect* our ideology. We remain relevant because we assert a standard and 
have managed to mostly provide a useful product while complying with those 
standards. If we bend the rules too much it becomes an open question on why we 
are better or different than any of the many other distributions out there. We 
shouldn't be bullheaded, unrealistic or unyielding but we should be strong and 
true.

If distributing proprietary binaries is inescapable then, again, I'll say that 
we should leave that distribution to others and create some ground rules for 
identifying how those others should "play nice" with us. If we have an army of 
third party value-add distributors who fill in these proprietary gaps then we 
will be well armed to deal with the emerging spectrum of platforms that will be 
coming down the pipe in the coming years. Things that look like phones and 
other appliances will be the wave of the future and those devices will have 
many strange legal obligations. A partner program that enables the vendors of 
these devices to supply the necessary proprietary baggage and still guarantee a 
"Debian Compatible" environment will serve us, them and our users.

-- 
Ean Schuessler, CTO Brainfood.com
[EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: on firmware (possible proposal)

[Frans Pop]

On Friday 14 November 2008, you wrote:
> But you have to see that castrating the ideals of the project is just
> as damaging as these distribution problems are. I believe Debian has
> remained important over time because, despite our various social
> failings, they *respect* our ideology. We remain relevant because we
> assert a standard and have managed to mostly provide a useful product
> while complying with those standards.

And I believe that Debian is becoming increasingly marginal because users 
are driven away to other distros. Sure, it is nice that a lot of those 
users go to derived distros instead of "real" competitors, but IMO it is 
still unhealthy if Debian's own user base becomes too small. After all, 
we largely depend on having that user base for a healthy turnover in DDs 
and having motivated translators and such.

IMO nobody here is promoting indiscriminate "distribution of proprietary 
binaries" as you call it, nor to change our ideology. IMO we can still 
work towards a perfect world while being a bit more pragmatic and serving 
the needs of our users, especially the kind of professional or large 
scale users that really need to able to install a distro on hardware and 
have it working without having to jump to hoops.

Reality is that _more_ hardware, and especially more _common_ hardware is 
becoming hard to use because of our ideals. You can also wonder if the 
DFSG would be written exactly the way they are if the were written from 
scratch in the current time frame. I doubt it.

If we are selective in our concessions to pragmatism and careful in the 
way we implement things (which always has been one of the strengths of 
Debian), I personally don't see the problem.

I'm well aware that what I tend to think of as the "DFSG hardliners" in 
the project do not like this, but why not discuss things openly (and 
hopefully without too much flaming) and vote on it? Let's see what the 
project as a whole thinks.

Cheers,
FJP


signature.asc
Description: This is a digitally signed message part.

Re: on firmware (possible proposal)

[Ean Schuessler]

- "Frans Pop" <[EMAIL PROTECTED]> wrote:

> And I believe that Debian is becoming increasingly marginal because users 
> are driven away to other distros. Sure, it is nice that a lot of those 
> users go to derived distros instead of "real" competitors, but IMO it is 
> still unhealthy if Debian's own user base becomes too small. After all, 
> we largely depend on having that user base for a healthy turnover in DDs 
> and having motivated translators and such.

If we handle things properly, it is like the GSM standards body worrying that 
it doesn't actually build phones. Ubuntu has helped us suck the air out of Red 
Hat and Novell in a way that no one would have thought possible. Now, to your 
point, I would like to see them be a little more direct about co-marketing with 
us and it seems that they are coming around to that way of thinking as time 
goes on. I think they've eventually come around to the idea that "Debian done 
right" doesn't fly nearly as well as "Debian + Added Value". Being derogatory 
about the foundation of your product is backwards and nonsensical.

What we need to do is get these distributions to view co-marketing with Debian 
as a positive thing, like the "Real" Milk products or the Java (gah! dare I say 
it!) brand. To me, real Debian derived distros would provide users with the 
core Debian value of "choice" and then add value on top of that. What we need 
to do is make some formal rules about how "choice" is provided. For instance, a 
Debian based platform that locks the user out of root and has cryptographically 
secured firmware would not meet the criteria of an "official derived distro".

The kind of protections I'm outlining here will become far more important than 
the bits of firmware in the main distribution as time goes on. If, in the 
future, there are no computers to install Debian on (ie. everything becomes 
more embedded and network based) then it won't matter a bit what is on our CDs. 
Engaging the platform manufacturers and other value-added resellers is going to 
become ever more critical.

> If we are selective in our concessions to pragmatism and careful in the 
> way we implement things (which always has been one of the strengths of 
> Debian), I personally don't see the problem.
> 
> I'm well aware that what I tend to think of as the "DFSG hardliners" in 
> the project do not like this, but why not discuss things openly (and 
> hopefully without too much flaming) and vote on it? Let's see what the 
> project as a whole thinks.

I'm not disagreeing with you on the fact that bundles of proprietary bits are 
going to become harder to get away from as we move towards more embedded 
looking platforms. I'm just saying that distributing those bits through the 
core development process is a mistake and that value-added distributors are the 
way to go. That's what we're already doing and it works. What we should do is 
increase the effectiveness of our current process by making it more formal and 
explicit.

Martin Michlmayr actually proposed some similar ideas under the name "Debian 
Labs", which I immediately reserved as a means of making a point about 
trademark infringement. That URL could still be a good place to do this kind of 
work and I'm happy to hand it back to SPI if someone is serious about doing 
that kind of work on it.

-- 
Ean Schuessler, CTO Brainfood.com
[EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

call for seconds: on firmware (was: on firmware (possible proposal))

[Peter Palfrader]

On Wed, 12 Nov 2008, Peter Palfrader wrote:

> I so didn't want to get into this discussion, but here goes anyway.
> 
> I'm considering formally proposing this GR (option):

I'm hereby proposing the following general resolution:

| Firmware is data such as microcode or lookup tables that is loaded into
| hardware components in order to make the component function properly.
| It is not code that is run on the host CPU.
|
| Unfortunately such firmware often is distributed as so-called blobs,
| with no source or further documentation that lets us learn how it works
| or interacts with the hardware in question.  By excluding such firmware
| from Debian we exclude users that require such devices from installing
| our operating system, or make it unnecessarily hard for them.
|
| Therefore the Debian project resolves that
|  a) firmware in Debian does not have to come with source.  While we do
| prefer firmware that comes with source and documentation we will not
| require it,
|  b) we however do require all other freedoms that the DFSG mandate from
| components of our operating system, and
|  c) such firmware can and should be part of our official installation media.

Looking for seconds now.

Thanks,
weasel


signature.asc
Description: Digital signature

Re: call for seconds: on firmware (was: on firmware (possible proposal))

[Holger Levsen]

Hi,

On Friday 14 November 2008 21:12, Peter Palfrader wrote:
> I'm hereby proposing the following general resolution:
> | Firmware is data such as microcode or lookup tables that is loaded into
> | hardware components in order to make the component function properly.
> | It is not code that is run on the host CPU.
> |
> | Unfortunately such firmware often is distributed as so-called blobs,
> | with no source or further documentation that lets us learn how it works
> | or interacts with the hardware in question.  By excluding such firmware
> | from Debian we exclude users that require such devices from installing
> | our operating system, or make it unnecessarily hard for them.
> |
> | Therefore the Debian project resolves that
> |  a) firmware in Debian does not have to come with source.  While we do
> | prefer firmware that comes with source and documentation we will not
> | require it,
> |  b) we however do require all other freedoms that the DFSG mandate from
> | components of our operating system, and
> |  c) such firmware can and should be part of our official installation
> | media.

Seconded.


regards,
Holger


pgpoX4f7AdrRx.pgp
Description: PGP signature

Re: call for seconds: on firmware

[Colin Tuckley]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Peter Palfrader wrote:

> I'm hereby proposing the following general resolution:
> 
> | Firmware is data such as microcode or lookup tables that is loaded into
> | hardware components in order to make the component function properly.
> | It is not code that is run on the host CPU.
> |
> | Unfortunately such firmware often is distributed as so-called blobs,
> | with no source or further documentation that lets us learn how it works
> | or interacts with the hardware in question.  By excluding such firmware
> | from Debian we exclude users that require such devices from installing
> | our operating system, or make it unnecessarily hard for them.
> |
> | Therefore the Debian project resolves that
> |  a) firmware in Debian does not have to come with source.  While we do
> | prefer firmware that comes with source and documentation we will not
> | require it,
> |  b) we however do require all other freedoms that the DFSG mandate from
> | components of our operating system, and
> |  c) such firmware can and should be part of our official installation media.
> 

Seconded!

- --
Colin Tuckley  |  +44(0)1903 236872  |  PGP/GnuPG Key Id
Debian Developer   |  +44(0)7799 143369  | 0x1B3045CE

"My mind free-associates far too much; I'm going to have to start charging it."
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAkkd4QoACgkQj2OPlhswRc4KaACgzkJpwnSNXQu7SzfrW8MRGpeV
bukAoPdxaD0pVaNZ3l9ewLDOaexvQkrx
=oN0b
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: call for seconds: on firmware (was: on firmware (possible proposal))

[Frans Pop]

Peter Palfrader wrote:
> I'm hereby proposing the following general resolution:
> 
> | Firmware is data such as microcode or lookup tables that is loaded into
> | hardware components in order to make the component function properly.
> | It is not code that is run on the host CPU.
> |
> | Unfortunately such firmware often is distributed as so-called blobs,
> | with no source or further documentation that lets us learn how it works
> | or interacts with the hardware in question.  By excluding such firmware
> | from Debian we exclude users that require such devices from installing
> | our operating system, or make it unnecessarily hard for them.
> |
> | Therefore the Debian project resolves that
> |  a) firmware in Debian does not have to come with source.  While we do
> | prefer firmware that comes with source and documentation we will not
> | require it,
> |  b) we however do require all other freedoms that the DFSG mandate from
> | components of our operating system, and
> |  c) such firmware can and should be part of our official installation
> |  media.

Seconded.


signature.asc
Description: This is a digitally signed message part.

Re: call for seconds: on firmware (was: on firmware (possible proposal))

[Steve McIntyre]

On Fri, Nov 14, 2008 at 09:12:25PM +0100, Peter Palfrader wrote:
>
>I'm hereby proposing the following general resolution:
>
>| Firmware is data such as microcode or lookup tables that is loaded into
>| hardware components in order to make the component function properly.
>| It is not code that is run on the host CPU.
>|
>| Unfortunately such firmware often is distributed as so-called blobs,
>| with no source or further documentation that lets us learn how it works
>| or interacts with the hardware in question.  By excluding such firmware
>| from Debian we exclude users that require such devices from installing
>| our operating system, or make it unnecessarily hard for them.
>|
>| Therefore the Debian project resolves that
>|  a) firmware in Debian does not have to come with source.  While we do
>| prefer firmware that comes with source and documentation we will not
>| require it,
>|  b) we however do require all other freedoms that the DFSG mandate from
>| components of our operating system, and
>|  c) such firmware can and should be part of our official installation media.
>
>Looking for seconds now.

Seconded.

-- 
Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED]
There's no sensation to compare with this
Suspended animation, A state of bliss


signature.asc
Description: Digital signature

Re: call for seconds: on firmware (was: on firmware (possible proposal))

[Martin Michlmayr]

* Peter Palfrader <[EMAIL PROTECTED]> [2008-11-14 21:12]:
> I'm hereby proposing the following general resolution:
> 
> | Firmware is data such as microcode or lookup tables that is loaded into
> | hardware components in order to make the component function properly.
> | It is not code that is run on the host CPU.
> |
> | Unfortunately such firmware often is distributed as so-called blobs,
> | with no source or further documentation that lets us learn how it works
> | or interacts with the hardware in question.  By excluding such firmware
> | from Debian we exclude users that require such devices from installing
> | our operating system, or make it unnecessarily hard for them.
> |
> | Therefore the Debian project resolves that
> |  a) firmware in Debian does not have to come with source.  While we do
> | prefer firmware that comes with source and documentation we will not
> | require it,
> |  b) we however do require all other freedoms that the DFSG mandate from
> | components of our operating system, and
> |  c) such firmware can and should be part of our official installation media.
> 
> Looking for seconds now.

Seconded.
-- 
Martin Michlmayr
http://www.cyrius.com/


signature.asc
Description: Digital signature

Re: call for seconds: on firmware

[Russ Allbery]

Peter Palfrader <[EMAIL PROTECTED]> writes:

> I'm hereby proposing the following general resolution:
>
> | Firmware is data such as microcode or lookup tables that is loaded into
> | hardware components in order to make the component function properly.
> | It is not code that is run on the host CPU.
> |
> | Unfortunately such firmware often is distributed as so-called blobs,
> | with no source or further documentation that lets us learn how it works
> | or interacts with the hardware in question.  By excluding such firmware
> | from Debian we exclude users that require such devices from installing
> | our operating system, or make it unnecessarily hard for them.
> |
> | Therefore the Debian project resolves that
> |  a) firmware in Debian does not have to come with source.  While we do
> | prefer firmware that comes with source and documentation we will not
> | require it,
> |  b) we however do require all other freedoms that the DFSG mandate from
> | components of our operating system, and
> |  c) such firmware can and should be part of our official installation media.
>
> Looking for seconds now.

I second this GR.

-- 
Russ Allbery ([EMAIL PROTECTED])   


pgpwNQNgxBRNO.pgp
Description: PGP signature

Re: call for seconds: on firmware (was: on firmware (possible proposal))

[Mark Hymers]

On Fri, 14, Nov, 2008 at 09:12:25PM +0100, Peter Palfrader spoke thus..
> I'm hereby proposing the following general resolution:
> 
> | Firmware is data such as microcode or lookup tables that is loaded into
> | hardware components in order to make the component function properly.
> | It is not code that is run on the host CPU.
> |
> | Unfortunately such firmware often is distributed as so-called blobs,
> | with no source or further documentation that lets us learn how it works
> | or interacts with the hardware in question.  By excluding such firmware
> | from Debian we exclude users that require such devices from installing
> | our operating system, or make it unnecessarily hard for them.
> |
> | Therefore the Debian project resolves that
> |  a) firmware in Debian does not have to come with source.  While we do
> | prefer firmware that comes with source and documentation we will not
> | require it,
> |  b) we however do require all other freedoms that the DFSG mandate from
> | components of our operating system, and
> |  c) such firmware can and should be part of our official installation media.

Seconded.

Mark



signature.asc
Description: Digital signature

Re: call for seconds: on firmware

[Ben Finney]

Peter Palfrader <[EMAIL PROTECTED]> writes:

> I'm hereby proposing the following general resolution:
> 
> | Firmware is data such as microcode or lookup tables that is loaded
> | into hardware components in order to make the component function
> | properly. It is not code that is run on the host CPU.
> |
> | Unfortunately such firmware often is distributed as so-called
> | blobs, with no source or further documentation that lets us learn
> | how it works or interacts with the hardware in question. By
> | excluding such firmware from Debian we exclude users that require
> | such devices from installing our operating system, or make it
> | unnecessarily hard for them.
> |
> | Therefore […]

This gives no argument for why such bitstreams should be held to
different standards of freedom for its recipients. The properties
“not code that is run on the host CPU” is mentioned, but seems to be
irrelevant to the argument.

Can you re-write this so it's clear why this particular class of
bitstream should not be held to the same freedom standards as
everything else in Debian?

-- 
 \“To be yourself in a world that is constantly trying to make |
  `\you something else is the greatest accomplishment.” —Ralph |
_o__)Waldo Emerson |
Ben Finney


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: call for seconds: on firmware

[Ben Pfaff]

Peter Palfrader <[EMAIL PROTECTED]> writes:

> I'm hereby proposing the following general resolution:
>
> | Firmware is data such as microcode or lookup tables that is loaded into
> | hardware components in order to make the component function properly.
> | It is not code that is run on the host CPU.
> |
> | Unfortunately such firmware often is distributed as so-called blobs,
> | with no source or further documentation that lets us learn how it works
> | or interacts with the hardware in question.  By excluding such firmware
> | from Debian we exclude users that require such devices from installing
> | our operating system, or make it unnecessarily hard for them.
> |
> | Therefore the Debian project resolves that
> |  a) firmware in Debian does not have to come with source.  While we do
> | prefer firmware that comes with source and documentation we will not
> | require it,
> |  b) we however do require all other freedoms that the DFSG mandate from
> | components of our operating system, and
> |  c) such firmware can and should be part of our official installation media.

Seconded.
-- 
"GNU does not eliminate all the world's problems,
 only some of them."
--Richard Stallman


pgpQ1PYLLt45x.pgp
Description: PGP signature

Re: call for seconds: on firmware

[Alexander Reichle-Schmehl]

Peter Palfrader schrieb:
> I'm hereby proposing the following general resolution:
> 
> | Firmware is data such as microcode or lookup tables that is loaded into
> | hardware components in order to make the component function properly.
> | It is not code that is run on the host CPU.
> |
> | Unfortunately such firmware often is distributed as so-called blobs,
> | with no source or further documentation that lets us learn how it works
> | or interacts with the hardware in question.  By excluding such firmware
> | from Debian we exclude users that require such devices from installing
> | our operating system, or make it unnecessarily hard for them.
> |
> | Therefore the Debian project resolves that
> |  a) firmware in Debian does not have to come with source.  While we do
> | prefer firmware that comes with source and documentation we will not
> | require it,
> |  b) we however do require all other freedoms that the DFSG mandate from
> | components of our operating system, and
> |  c) such firmware can and should be part of our official installation media.

Seconded.




signature.asc
Description: OpenPGP digital signature

Re: call for seconds: on firmware (was: on firmware (possible proposal))

[Moritz Muehlenhoff]

In gmane.linux.debian.devel.vote, Peter Palfrader wrote:
>
> I'm hereby proposing the following general resolution:
>
>| Firmware is data such as microcode or lookup tables that is loaded into
>| hardware components in order to make the component function properly.
>| It is not code that is run on the host CPU.
>|
>| Unfortunately such firmware often is distributed as so-called blobs,
>| with no source or further documentation that lets us learn how it works
>| or interacts with the hardware in question.  By excluding such firmware
>| from Debian we exclude users that require such devices from installing
>| our operating system, or make it unnecessarily hard for them.
>|
>| Therefore the Debian project resolves that
>|  a) firmware in Debian does not have to come with source.  While we do
>| prefer firmware that comes with source and documentation we will not
>| require it,
>|  b) we however do require all other freedoms that the DFSG mandate from
>| components of our operating system, and
>|  c) such firmware can and should be part of our official installation media.

I second that.

Cheers,
Moritz


signature.asc
Description: Digital signature

Re: call for seconds: on firmware

[Bernd Zeimetz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


> I'm hereby proposing the following general resolution:
> 
> | Firmware is data such as microcode or lookup tables that is loaded into
> | hardware components in order to make the component function properly.
> | It is not code that is run on the host CPU.
> |
> | Unfortunately such firmware often is distributed as so-called blobs,
> | with no source or further documentation that lets us learn how it works
> | or interacts with the hardware in question.  By excluding such firmware
> | from Debian we exclude users that require such devices from installing
> | our operating system, or make it unnecessarily hard for them.
> |
> | Therefore the Debian project resolves that
> |  a) firmware in Debian does not have to come with source.  While we do
> | prefer firmware that comes with source and documentation we will not
> | require it,
> |  b) we however do require all other freedoms that the DFSG mandate from
> | components of our operating system, and
> |  c) such firmware can and should be part of our official installation media.

seconded.

- --
 Bernd Zeimetz   Debian GNU/Linux Developer
 GPG Fingerprint: 06C8 C9A2 EAAD E37E 5B2C BE93 067A AD04 C93B FF79
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkkeG+wACgkQBnqtBMk7/3mDsQCfTWQMHrHVxgf1Rvi07zQh9tha
arEAn00HIZm6T4KS+uVHqTTZFewcYt2l
=44sg
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: call for seconds: on firmware

[Cyril Brulebois]

Peter Palfrader <[EMAIL PROTECTED]> (14/11/2008):
> I'm hereby proposing the following general resolution:
> 
> | Firmware is data such as microcode or lookup tables that is loaded into
> | hardware components in order to make the component function properly.
> | It is not code that is run on the host CPU.
> |
> | Unfortunately such firmware often is distributed as so-called blobs,
> | with no source or further documentation that lets us learn how it works
> | or interacts with the hardware in question.  By excluding such firmware
> | from Debian we exclude users that require such devices from installing
> | our operating system, or make it unnecessarily hard for them.
> |
> | Therefore the Debian project resolves that
> |  a) firmware in Debian does not have to come with source.  While we do
> | prefer firmware that comes with source and documentation we will not
> | require it,
> |  b) we however do require all other freedoms that the DFSG mandate from
> | components of our operating system, and
> |  c) such firmware can and should be part of our official installation media.

Seconded.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: call for seconds: on firmware (was: on firmware (possible proposal))

[Charles Plessy]

Le Fri, Nov 14, 2008 at 09:12:25PM +0100, Peter Palfrader a écrit :
> 
> I'm hereby proposing the following general resolution:
> 
> | Firmware is data such as microcode or lookup tables that is loaded into
> | hardware components in order to make the component function properly.
> | It is not code that is run on the host CPU.
> |
> | Unfortunately such firmware often is distributed as so-called blobs,
> | with no source or further documentation that lets us learn how it works
> | or interacts with the hardware in question.  By excluding such firmware
> | from Debian we exclude users that require such devices from installing
> | our operating system, or make it unnecessarily hard for them.
> |
> | Therefore the Debian project resolves that
> |  a) firmware in Debian does not have to come with source.  While we do
> | prefer firmware that comes with source and documentation we will not
> | require it,
> |  b) we however do require all other freedoms that the DFSG mandate from
> | components of our operating system, and
> |  c) such firmware can and should be part of our official installation media.

Hi all,

can the secretaries state whether it is a supermajority option or not?

If yes, how will we deal with it after it is voted? The GR will not be a
foundation document but will rule over one. It will be hidden between many
other GRs, which is in my opinion messy, especially if it happens multiple
times: it will raise the entry barrier for people who want to understand
Debian's principles.

If the goal is to make a permanent decision, I would recommend a clear
permanent change of our foundation documents.

Another concern is that while I feel that there is a strong majority who is
keen on "releasing Lenny with the firmwares", I am not sure if we all agree on
the other consequences of this GR. My understanding of it is that it allows
source-less firmwares in main, but Peter mentioned an interpretation in which
the consequence of the GR is the creation of a new section (whith a transitory
period where the firmwares stay in main).
([EMAIL PROTECTED]). In terms of workload for some
developpers, it makes a big difference. I would really prefer hearing their
opinion before voting for a supermajority resolution that may not be applied if
nobody wants to deal with the work overhead of having a new section outside
main.

Have a nice day,

-- 
Charles Plessy
Tsurumi, Kanagawa, Japan


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: call for seconds: on firmware (was: on firmware (possible proposal))

[Ean Schuessler]

- "Charles Plessy" <[EMAIL PROTECTED]> wrote:

> can the secretaries state whether it is a supermajority option or
> not?
> 
> If yes, how will we deal with it after it is voted? The GR will not be a
> foundation document but will rule over one. It will be hidden between many
> other GRs, which is in my opinion messy, especially if it happens multiple
> times: it will raise the entry barrier for people who want to understand
> Debian's principles.

Seconded.

I think that this GR would change the interpretation of a foundation document 
to the point of effectively rewriting it. SC #1 effectively becomes "Debian 
will remain 100% Free except for binaries make us difficult to install on 
commodity hardware". I started using Debian at a time where you practically had 
to hand pick a Linux compatible hardware setup and the PC world was literally 
99% Windows (or OS/2) so these alterations and their motivations are a little 
hard to swallow.

I would rather see "Debian + non-free" ISO and install images for newbie users 
before a blanket acceptance of proprietary firmware. We could offer these disks 
as a service in addition to our "official" images that are completely Free. I 
realize that I haven't contributed to Debian enough lately to really complain 
about any of this but I still can't help being surprised. We should be running 
free ads for hardware vendors that offer pre-rolled Debian systems with no 
proprietary bits before we are doing any of this. 

-- 
Ean Schuessler, CTO Brainfood.com
[EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: call for seconds: on firmware

[Manoj Srivastava]

On Fri, Nov 14 2008, Charles Plessy wrote:

> Le Fri, Nov 14, 2008 at 09:12:25PM +0100, Peter Palfrader a écrit :
>> 
>> I'm hereby proposing the following general resolution:
>> 
>> | Firmware is data such as microcode or lookup tables that is loaded into
>> | hardware components in order to make the component function properly.
>> | It is not code that is run on the host CPU.
>> |
>> | Unfortunately such firmware often is distributed as so-called blobs,
>> | with no source or further documentation that lets us learn how it works
>> | or interacts with the hardware in question.  By excluding such firmware
>> | from Debian we exclude users that require such devices from installing
>> | our operating system, or make it unnecessarily hard for them.
>> |
>> | Therefore the Debian project resolves that
>> |  a) firmware in Debian does not have to come with source.  While we do
>> | prefer firmware that comes with source and documentation we will not
>> | require it,
>> |  b) we however do require all other freedoms that the DFSG mandate from
>> | components of our operating system, and
>> |  c) such firmware can and should be part of our official installation 
>> media.
>
> Hi all,
>
> can the secretaries state whether it is a supermajority option or not?

Yes, it is.

> If yes, how will we deal with it after it is voted? The GR will not be a
> foundation document but will rule over one. It will be hidden between many
> other GRs, which is in my opinion messy, especially if it happens multiple
> times: it will raise the entry barrier for people who want to understand
> Debian's principles.

If this GR passes, we will amend the social contract with the
 language in the GR. The exact wording can be discussed, either now, or
 when this passes.

> If the goal is to make a permanent decision, I would recommend a clear
> permanent change of our foundation documents.

Correct.

manoj

-- 
A man wrapped up in himself makes a very small package.
Manoj Srivastava <[EMAIL PROTECTED]>   
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]