Re: call for seconds: on firmware

[Stefano Zacchiroli]

On Sat, Nov 15, 2008 at 04:24:18PM -0800, Russ Allbery wrote:
> Hm, no, the impression that I got from this discussion that at least
> several people here think the result of "Further discussion" is:

Let me observe that the fact that "several people here think" is not
authoritative.

That said, I disagree with point (ii) of your interpretation:

> i Do we require source for firmware in main: Yes
>ii Do we allow the Release Team to ignore SC violation bugs:  No
>   iii What do we do for Lenny:   Wait
>iV Do we modify foundation documents: No
> v Do we override foundation documentsNo

it should rather be "Yes":

>ii Do we allow the Release Team to ignore SC violation bugs:  Yes

Rationale: with "further discussion" nothing changes. Today RMs are
empowered, by delegation, to decide upon transitions and
"lenny-ignore" tags. It will be the same tomorrow if "further
discussion" wins.

If people disagree with that, they can overrule delegates' decision as
supported by our constitution.

BTW, this is yet another hint that separate ballots would have been
better, because we are implicitly calling for another GR in some
special case, but unfortunately Dato's proposal to split ballots
doesn't seem to have gained enough momentum.

Cheers.

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
[EMAIL PROTECTED],pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime


signature.asc
Description: Digital signature

Re: call for seconds: on firmware

[Manoj Srivastava]

On Sat, Nov 15 2008, Florian Weimer wrote:

> * Stephen Gran:
>
>> It's not possible to express the full set of relations in a single
>> winner vote, as far as I can tell.  It might be someone's vote to say
>> 'none of this non-free crap in the archive ever' and simultaneously
>> say 'but the release team does have the authority to downgrade these bug
>> reports if they need to'.  Unless I've missed something and we're
>> planning on having a multi winner vote, 
>
> We can always put the elements of the power set of all proposals on
> the ballot.

Yes, people may propose and second combinations of current
 proposals, as long as they are not mutually exclusive.

> I suppose the ballot should be structured in a way that guarantees
> halfway meaningful outcomes, while not actively discriminating against
> certain proposals.  To be honest, I'm glad I need not decide such
> things.

Being very hesitant about my wisdom, my first cutr at a ballot
 would be all the 6 proposals, plus a default, which is more or less
 proposal 1.

manoj
-- 
Flattery will get you everywhere.
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]

Re: call for seconds: on firmware

[Manoj Srivastava]

On Sat, Nov 15 2008, Russ Allbery wrote:

> Charles Plessy <[EMAIL PROTECTED]> writes:
>
>> we all agree that the result of "Further discussion" is the following,
>> don't we?
>>
>> i Do we require source for firmware in main: As usual
>>ii Do we allow the Release Team to ignore SC violation bugs:  As usual
>>   iii What do we do for Lenny:   Release
>>iV Do we modify foundation documents: No
>> v Do we override foundation documentsNo
>
> Hm, no, the impression that I got from this discussion that at least
> several people here think the result of "Further discussion" is:
>
> i Do we require source for firmware in main: Yes
>ii Do we allow the Release Team to ignore SC violation bugs:  No
>   iii What do we do for Lenny:   Wait
>iV Do we modify foundation documents: No
> v Do we override foundation documentsNo
>
> and that seems to be consistent with what Manoj is ruling about overrides
> of the SC.

This is my reading, yes. As far as I see, the SC is pretty
 clear, and leaves us no other option.

manoj
-- 
UNIX was half a billion (5) seconds old on Tue Nov 5 00:53:20
1985 GMT (measuring since the time(2) epoch).  -- Andy Tannenbaum
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]

Re: call for seconds: on firmware

[Russ Allbery]

Charles Plessy <[EMAIL PROTECTED]> writes:

> we all agree that the result of "Further discussion" is the following,
> don't we?
>
> i Do we require source for firmware in main: As usual
>ii Do we allow the Release Team to ignore SC violation bugs:  As usual
>   iii What do we do for Lenny:   Release
>iV Do we modify foundation documents: No
> v Do we override foundation documentsNo

Hm, no, the impression that I got from this discussion that at least
several people here think the result of "Further discussion" is:

i Do we require source for firmware in main: Yes
   ii Do we allow the Release Team to ignore SC violation bugs:  No
  iii What do we do for Lenny:   Wait
   iV Do we modify foundation documents: No
v Do we override foundation documentsNo

and that seems to be consistent with what Manoj is ruling about overrides
of the SC.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: call for seconds: on firmware

[Charles Plessy]

Le Sat, Nov 15, 2008 at 09:45:56AM -0600, Debian Project Secretary a écrit :
>i Do we require source for firmware in main: No
>   ii Do we allow the Release Team to ignore SC violation bugs:  No
>  iii What do we do for Lenny:   Release
>   iV Do we modify foundation documents: Yes
>v Do we override foundation documentsNo

Dear everybody,

we all agree that the result of "Further discussion" is the following, don't we?

i Do we require source for firmware in main: As usual
   ii Do we allow the Release Team to ignore SC violation bugs:  As usual
  iii What do we do for Lenny:   Release
   iV Do we modify foundation documents: No
v Do we override foundation documentsNo


-- 
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

[Manoj Srivastava]

On Sat, Nov 15 2008, Stephen Gran wrote:

> This one time, at band camp, Manoj Srivastava said:
>> On Sat, Nov 15 2008, Adeodato Simó wrote:
>> >
>> >> |  We as Developers at large continue to trust our release team to follow
>> >> |  all these goals, and therefor encourage them to continue making
>> >> |  case-by-case-decisions as they consider fit, and if necessary
>> >> |  authorize these decisions.
>> >
>> > Also, this one should not be voted together with the rest, since it's
>> > an orthogonal issue. This not /exclusively/ a solution for the problem
>> > for Lenny.
>> >
>> > We can ask the proposer of this option what he thinks, if you don't
>> > agree it should be split out.
>> 
>> While some of the proposals have longer lasting effects than
>>  just the current release, they are still related: for example, the
>>  proposal singled out above, if passed, would make proposal 5 moot, and
>>  invalidate proposal 1.
>
> It's not possible to express the full set of relations in a single
> winner vote, as far as I can tell.  It might be someone's vote to say
> 'none of this non-free crap in the archive ever' and simultaneously
> say 'but the release team does have the authority to downgrade these bug
> reports if they need to'.  Unless I've missed something and we're
> planning on having a multi winner vote, 

That does not seem to make sense. Either you have
  'none of this non-free crap in the archive ever'
  or you have
  'the release team downgrades these bugs and includes non-free crap'

Not both.

Which is why they are on the same ballot.

Frankly, at this point, we are trying to get the issue of Lenny
 release with or without firmware resolved. All the options do that, in
 one way or the other. Some options are temporary displensations, other
 are far wider ranging than that. Arguably, we might want the wider
 ranging changes _anyway_, but that might not happen if we can get lenny
 released by an other option.

In that case, we can re-raise the issue post lenny,
 independently, and not get the vote get all tangled up with trying to
 release lenny.

If we are trying to change foundation documents not in the
 context of releasing lenny, I think we need a good debate on the merits
 of each proposal, not an accelerated one trying to resolve the lenny
 issue. But all the related proposals will solve the lenny release, so I
 think it is justified to put them on the ballot about "what to do with
 lenny".

manoj
-- 
Success in management--at any level--depends on the ability to pick the
right people for the right jobs.
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]

Re: call for seconds: on firmware

[Florian Weimer]

* Stephen Gran:

> It's not possible to express the full set of relations in a single
> winner vote, as far as I can tell.  It might be someone's vote to say
> 'none of this non-free crap in the archive ever' and simultaneously
> say 'but the release team does have the authority to downgrade these bug
> reports if they need to'.  Unless I've missed something and we're
> planning on having a multi winner vote, 

We can always put the elements of the power set of all proposals on
the ballot.

I suppose the ballot should be structured in a way that guarantees
halfway meaningful outcomes, while not actively discriminating against
certain proposals.  To be honest, I'm glad I need not decide such
things.


-- 
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))

[Loïc Minier]

 I know there's already a good number of seconds, but I said I'd second
 this proposal, so here I do: I second the proposal below.

On Fri, Nov 14, 2008, Peter Palfrader wrote:
> 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



-- 
Loïc Minier


signature.asc
Description: Digital signature

Re: call for seconds: on firmware

[Stephen Gran]

This one time, at band camp, Manoj Srivastava said:
> On Sat, Nov 15 2008, Adeodato Simó wrote:
> >
> >> |  We as Developers at large continue to trust our release team to follow
> >> |  all these goals, and therefor encourage them to continue making
> >> |  case-by-case-decisions as they consider fit, and if necessary
> >> |  authorize these decisions.
> >
> > Also, this one should not be voted together with the rest, since it's
> > an orthogonal issue. This not /exclusively/ a solution for the problem
> > for Lenny.
> >
> > We can ask the proposer of this option what he thinks, if you don't
> > agree it should be split out.
> 
> While some of the proposals have longer lasting effects than
>  just the current release, they are still related: for example, the
>  proposal singled out above, if passed, would make proposal 5 moot, and
>  invalidate proposal 1.

It's not possible to express the full set of relations in a single
winner vote, as far as I can tell.  It might be someone's vote to say
'none of this non-free crap in the archive ever' and simultaneously
say 'but the release team does have the authority to downgrade these bug
reports if they need to'.  Unless I've missed something and we're
planning on having a multi winner vote, 
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: call for seconds: on firmware

[Manoj Srivastava]

On Sat, Nov 15 2008, Josselin Mouette wrote:

> Le samedi 15 novembre 2008 à 09:45 -0600, Debian Project Secretary a
> écrit :
>> | (Since this option overrides the SC, I believe it would require 3:1
>> | majority)
>
> So you get to decide which options need 3:1 majority?

I thought it was clear that the constitution spelled out that
 amending a foundation document requires the majority. If you want to
 supersede a (part of a)  foundation document, the majority comes into
 play. §4.1.5, etc.

> I don’t understand why you decide that we need a 3:1 majority to allow
> release managers to release lenny, while we do not require such a fuss
> to allow kernel or glibc developers to knowingly violate the social
> contract at each upload.
>
> Why should we consider the stable release process differently from our
> other processes?

We should not. Ideally, having agreed to the social contract and
 the DFSG,  Debian developers should be working hard to remove non-DFSG
 compliant stuff out of main.

However, we are human, and  there can be bugs in our packages
 during the work-in-progress stage. Most reasonable people can agree
 that it takes time to fix bugs, so Sid has bugs, and some of these are
 DFSG violation bugs. However, our release of the Debian system is what
 we produce, and we have promised that the Debian system shall be 100%
 free.

I do think upholding the SC should be a goal for all DD's at any
 time, but YMMV.

manoj
-- 
Oh Dad!  We're ALL Devo!
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]

Re: call for seconds: on firmware

[Russ Allbery]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> Le samedi 15 novembre 2008 à 09:45 -0600, Debian Project Secretary a
> écrit :
>> | (Since this option overrides the SC, I believe it would require 3:1
>> | majority)
>
> So you get to decide which options need 3:1 majority?

Well, yes.  Constitution section 7.1, point 3.

> I don’t understand why you decide that we need a 3:1 majority to allow
> release managers to release lenny, while we do not require such a fuss
> to allow kernel or glibc developers to knowingly violate the social
> contract at each upload.
>
> Why should we consider the stable release process differently from our
> other processes?

I don't think it's that unreasonable to consider our releases to be the
primary output of our development process.  If nothing else, it's rather
hard to keep from never violating the SC temporarily by simple mistake
during unstable development, and treating the release as the point at
which we have to clear all that up provides a firm boundary for what
"temporary" will be in temporary violations.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: call for seconds: on firmware

[Josselin Mouette]

Le samedi 15 novembre 2008 à 09:45 -0600, Debian Project Secretary a
écrit :
> | (Since this option overrides the SC, I believe it would require 3:1
> | majority)

So you get to decide which options need 3:1 majority?

I don’t understand why you decide that we need a 3:1 majority to allow
release managers to release lenny, while we do not require such a fuss
to allow kernel or glibc developers to knowingly violate the social
contract at each upload.

Why should we consider the stable release process differently from our
other processes?

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: call for seconds: on firmware

[Manoj Srivastava]

On Sat, Nov 15 2008, Adeodato Simó wrote:

>> ,[ Proposal 4: Allow release managers leeway to include non-dfsg bits as 
>> needed ]
>> |  Debian's priorities are our users and free software. We don't trade
>> |  them against each other. However during getting an release out of the
>> |  door, decisions need to be done how to get a rock stable release of the
>> |  high quality Debian is known for, release more or less on time, and to
>> |  minimize the usage of problematic software. We acknowledge that there
>> |  is more than just one minefield our core developers and the release
>> |  team are working at.
>
>> |  We as Developers at large continue to trust our release team to follow
>> |  all these goals, and therefor encourage them to continue making
>> |  case-by-case-decisions as they consider fit, and if necessary
>> |  authorize these decisions.
>
>> |  (Since this option overrides the SC, I believe it would require 3:1
>> |  majority)
>
> Also, this one should not be voted together with the rest, since it's
> an orthogonal issue. This not /exclusively/ a solution for the problem
> for Lenny.
>
> We can ask the proposer of this option what he thinks, if you don't
> agree it should be split out.

While some of the proposals have longer lasting effects than
 just the current release, they are still related: for example, the
 proposal singled out above, if passed, would make proposal 5 moot, and
 invalidate proposal 1.

Given that these proposals are strongly related, they should be
 on the ballot together. Post Lenny, if we do want to change our
 foundation documents, we can try and do so; but splitting out options
 on how to handle the release of lenny in view of firmware blobs, and
 the apparent conflict with the SC, would result in a botched
 decision. Serial votes with subsets of options really lend themselves
 to tactical voting our voting method is not designed to deal with.

manoj
-- 
Screw up your courage!  You've screwed up everything else.
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]

Re: call for seconds: on firmware

[Manoj Srivastava]

On Sat, Nov 15 2008, Adeodato Simó wrote:

> Peter Palfrader's proposal [1] explicitly said, and I quote:
>
>   | I'm hereby proposing the following general resolution.
>
> I don't think it's acceptable to bundle it up with the ongoing GR, since
> it was not proposed as an amendment to it.

I have explained why I think all these proposals are related
 (they all affect releasing lenny  while kernels contain firmware blobs,
 and some of the solutions have effects that are more far reaching than
 others).  Since they are related, they belong on the same ballot --
 even if they were not all formally declared to be "amendments" of the
 original proposal.

Our voting methods do not deal well with related options being
 on separate ballots.

manoj
-- 
"Imitation is the sincerest form of television." The New Mighty Mouse
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]

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

[Andreas Barth]

* Peter Palfrader ([EMAIL PROTECTED]) [081114 21:01]:
> 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.

seconded.

Cheers,
Andi


signature.asc
Description: Digital signature

Re: call for seconds: on firmware

[Adeodato Simó]

> ,[ Proposal 4: Allow release managers leeway to include non-dfsg bits as 
> needed ]
> |  Debian's priorities are our users and free software. We don't trade
> |  them against each other. However during getting an release out of the
> |  door, decisions need to be done how to get a rock stable release of the
> |  high quality Debian is known for, release more or less on time, and to
> |  minimize the usage of problematic software. We acknowledge that there
> |  is more than just one minefield our core developers and the release
> |  team are working at.

> |  We as Developers at large continue to trust our release team to follow
> |  all these goals, and therefor encourage them to continue making
> |  case-by-case-decisions as they consider fit, and if necessary
> |  authorize these decisions.

> |  (Since this option overrides the SC, I believe it would require 3:1
> |  majority)

Also, this one should not be voted together with the rest, since it's
an orthogonal issue. This not /exclusively/ a solution for the problem
for Lenny.

We can ask the proposer of this option what he thinks, if you don't
agree it should be split out.

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
  Listening to: Dar Williams - You Rise And Meet The Day


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

Re: Rechte auf der Seite

[Alexander Reichle-Schmehl]

Hi!

Jens Mänz schrieb:

> Wir haben ja 4 Benutzerrollen:
> 
> Anonymer Benutzer
> Registrierter Benutzer -> Benutzer, die keine Initiative sind, aber an
> den Foren usw. teilnehmen wollen
> Initiative (NEU)
> ggf. Förderer / Sponsoren?
> Administratoren

Sorry, habe gerade Netzprobleme; oder genauer:  Mit dem C135 Notebook
und dem VPN klappt es nicht so toll, wie Freitag getestet.

Können / Sollten wir vielleicht noch eine fünfte Gruppe einrichten?
"Editoren" oder so?  Für die AMG-Leute, die Inhalte einstellen und
Accounts bestätigen dürfen, aber nicht viel mehr (Einstellungen
verstellen, etc.)


Gruß,
  Alexander

PS:  Ich komme jetzt zwar per VPN zur Uni, aber nicht mehr auf den
AMG-Test-Rechner.  Hat jemand eine Ahnung, was da los ist?


-- 
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))

[Stephen Gran]

This one time, at band camp, Peter Palfrader said:
> | 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 assume we have enough seconds by now, but since I said I would, I
second this proposal.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

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

[Philipp Kern]

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.

Seconded.

Kind regards,
Philipp Kern
-- 
 .''`.  Philipp KernDebian Developer
: :' :  http://philkern.de Release Assistant
`. `'   xmpp:[EMAIL PROTECTED] Stable Release Manager
  `-finger pkern/[EMAIL PROTECTED]


signature.asc
Description: Digital signature

Re: on firmware (possible proposal)

[Stephen Gran]

This one time, at band camp, Robert Millan said:
> If we get closer to the free side, and provide a 100% free main like we used 
> to,

When precisely was that?
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: on firmware (possible proposal)

[Stephen Gran]

This one time, at band camp, Robert Millan said:
> 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.

Of course you can.  Adding paranoid fantasies to the debate doesn't
really help much.
-- 
 -
|   ,''`.Stephen Gran |
|  : :' :[EMAIL PROTECTED] |
|  `. `'Debian user, admin, and developer |
|`- http://www.debian.org |
 -


signature.asc
Description: Digital signature

Re: call for seconds: on firmware

[Adeodato Simó]

Peter Palfrader's proposal [1] explicitly said, and I quote:

  | I'm hereby proposing the following general resolution.

I don't think it's acceptable to bundle it up with the ongoing GR, since
it was not proposed as an amendment to it.

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

-- 
Adeodato Simó dato at net.com.org.es
Debian Developer  adeodato at debian.org
 
The problem I have with making an intelligent statement is that some
people then think that it's not an isolated occurrance.
-- Simon Travaglia


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

Re: call for seconds: on firmware

[Debian Project Secretary]

Hi,

This is how things stand:
The Situation: We are close to releasing Lenny
The Problem:  The kernels we are shipping have blobs that might not meet
  the DFSG, and some might be in violation of the kernel's
  GPL license. This would put them in conflict with the SC.

The proposed solutions below all try to address the basic issue
 of releasing while meeting the promises made in the SC.  A new proposal
 has been seconded, which extends the minimum discussion period by a
 week (I think the relevant second came in at 14 Nov 2008 22:53:07).

If the proposers do not submit the wml that should go up as the
 vote page, I'll make up the wording for the vote web page.

Here is the handy seconds registry. I hope I have recorded all
 seconds, and recorded their sponsorship correctly, please let me know
 if I have missed anything. (I have also simplified the summation
 formula below)
|+---+---+---+---++|
|| 1 | 2 | 3 | 4 |  5 |  6 |
|+---+---+---+---++|
| Robert Millan <[EMAIL PROTECTED]>| 1 | 1 | 1 |   |  1 |   
 |
| Bas Wijnen <[EMAIL PROTECTED]> | 1 |   |   |   |||
| Manoj Srivastava <[EMAIL PROTECTED]> | 1 | 1 |   |   |  1 ||
| Holger Levsen <[EMAIL PROTECTED]>  | 1 | 1 | 1 | 1 ||  1 |
| Peter Samuelson <[EMAIL PROTECTED]>   | 1 | 1 | 1 |   ||  
  |
| Hubert Chathi <[EMAIL PROTECTED]   | 1 | 1 | 1 |   |||
| Andreas Barth <[EMAIL PROTECTED]>|   |   |   | 1 |||
| Alexander Reichle-Schmehl <[EMAIL PROTECTED]> |   |   |   | 1 ||  1 |
| Reinhard Tartler <[EMAIL PROTECTED]> |   |   |   | 1 |||
| Bernd Zeimetz <[EMAIL PROTECTED]>  |   |   |   | 1 |  1 | 
 1 |
| Neil McGovern <[EMAIL PROTECTED]>   |   |   |   | 1 |  1 |
|
| Frans Pop <[EMAIL PROTECTED]>  |   | 1 | 1 |   ||  1 |
| [EMAIL PROTECTED] (Rémi Vanicat)  | 1 | 1 | 1 | 1 |||
| "John H. Robinson, IV" <[EMAIL PROTECTED]> |   |   |   |   |  1 ||
| Lars Wirzenius <[EMAIL PROTECTED]>|   |   |   |   |  
1 ||
| Damyan Ivanov <[EMAIL PROTECTED]> |   |   |   |   |  1 |  
  |
| Colin Tuckley <[EMAIL PROTECTED]>  |   |   |   |   |  1 |  1 |
| Pierre Habouzit <[EMAIL PROTECTED]>  |   |   |   |   |  1 ||
| Gunnar Wolf <[EMAIL PROTECTED]>  |   |   |   |   |  1 |   
 |
| Peter Palfrader <[EMAIL PROTECTED]>|   |   |   |   ||  1 |
| Russ Allbery <[EMAIL PROTECTED]>  |   |   |   |   ||  
1 |
| Martin Michlmayr <[EMAIL PROTECTED]>  |   |   |   |   ||  
1 |
| Steve McIntyre <[EMAIL PROTECTED]>  |   |   |   |   ||  1 
|
| Mark Hymers <[EMAIL PROTECTED]>   |   |   |   |   ||  
1 |
| Moritz Muehlenhoff <[EMAIL PROTECTED]>|   |   |   |   ||  
1 |
| Ben Pfaff <[EMAIL PROTECTED]>|   |   |   |   ||  1 |
| Cyril Brulebois <[EMAIL PROTECTED]>  |   |   |   |   ||  
1 |
|+---+---+---+---++|
|| 7 | 7 | 6 | 7 | 10 | 13 |
|+---+---+---+---++|
#+TBLFM: 
@29$2=vsum(@2..-I)::@29$3=vsum(@2..-I)::@29$4=vsum(@2..-I)::@29$5=vsum(@2..-I)::@29$6=vsum(@2..-I)::@29$7=vsum(@2..-I)


Since some people have had trouble reading the proposals, I am
 including a short impact of the proposal list below the proposal. 

,[ Proposal 1: reaffirm the Social Contract ]
|  1. We affirm that our Priorities are our users and the free software
| community (Social Contract #4);
| 
|  2. We acknowledge that we promised to deliver a 100% free operating system
| (Social Contract #1);
| 
|  3. Given that we have known for two previous releases that we have
| non-free bits in various parts of Debian, and a lot of progress has
| been made, and we are almost to the point where we can provide a
| free version of the Debian operating system, we will delay the
| release of Lenny until such point that the work to free the operating
| system is complete (to the best of our knowledge as of 1 November 2008).
`
   i Do we require source for firmware in main: Yes
  ii Do we allow the Release Team to ignore SC violation bugs:  No
 iii What do we do for Lenny:   Wait
  iv Do we modify foundation documents: No
   v Do we override foundation documentsNo

,[ Proposal 2: allow 

Re: call for seconds: on firmware

[Paul Wise]

On Sat, Nov 15, 2008 at 10:49 PM, Luk Claes <[EMAIL PROTECTED]> wrote:
> Paul Wise wrote:
>> On Sat, Nov 15, 2008 at 8:24 PM, Kurt Roeckx <[EMAIL PROTECTED]> wrote:
>>
>>> Does this mean that even if the blob is GPL'd, we don't need sources
>>> for it?
>>
>> That sounds like it would be a GPL violation.
>
> Only if the blob is not the actual source, no?

Presumably.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


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

Re: call for seconds: on firmware

[Luk Claes]

Paul Wise wrote:
> On Sat, Nov 15, 2008 at 8:24 PM, Kurt Roeckx <[EMAIL PROTECTED]> wrote:
> 
>> Does this mean that even if the blob is GPL'd, we don't need sources
>> for it?
> 
> That sounds like it would be a GPL violation.

Only if the blob is not the actual source, no?

Cheers

Luk


-- 
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))

[Paul Wise]

On Sat, Nov 15, 2008 at 8:24 PM, Kurt Roeckx <[EMAIL PROTECTED]> wrote:

> Does this mean that even if the blob is GPL'd, we don't need sources
> for it?

That sounds like it would be a GPL violation.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
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 06:54:52PM +0100, Frans Pop wrote:
> On Friday 14 November 2008, you wrote:
> > I believe Debian has
> > remained important over time because, despite our various social
> > failings, they *respect* our ideology.
> 
> And I believe that Debian is becoming increasingly marginal because users 
> are driven away to other distros.

Ironicaly, it is possible that both are right.  It is staying in this "middle
stage" that harms us the most, since we're heavily criticized from both sides.

Furthermore, we can't really satisfy everyone.  If we get closer to the
non-free side, we'll still be beaten by distributions which go further.  If
we include firmware, they will include Nvidious blobs.  If we include Nvidious
blobs, they will include Adobe Flash.  Etc.  This is a big part of how Ubuntu
earned this reputation of "being easy to setup" (they used our code to betray
our goals, and now somehow we're looking at them for inspiration..).

If we get closer to the free side, and provide a 100% free main like we used to,
we'll still be criticised for having a non-free repository, or for having
unofficial non-free installers.

This is why I think that worriing so much about what _others_ think is a
pointless exercise.  Heck, if people think our stance on freedom is wrong,
they most likely have already abandoned us in favour of other options (be
it e.g. Ubuntu or Gnewsense).  Those who have stayed with us to this date
is because they _like_ our current compromise, because they care about
freedom, even if they sacrifice their beliefs for practical reasons, and
install non-free software.  But when they do, they want to know they did.

-- 
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: call for seconds: on firmware (was: on firmware (possible proposal))

[Kurt Roeckx]

On Fri, Nov 14, 2008 at 09:12:25PM +0100, Peter Palfrader wrote:
> | 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

So do the licenses for all those blobs we have now comply with the DFSG
other than that we don't have the source for it?

Does this mean that even if the blob is GPL'd, we don't need sources
for it?


Kurt
 


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