Re: on firmware (possible proposal)

[Manoj Srivastava]

On Thu, Nov 13 2008, Peter Samuelson 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.

> => The argument is here that it is not as important that this is
> free software, since it cannot corrupt the software running on the
> main cpu.

Again, corruption or lack thereof is not why I want freedom in
 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.

>   - the third point, is that the fact that the code runs in a separate
> device CPU, create a clear interface barrier, and make it clear that
> the the uploaded firmware is not a derivative work of the kernel or
> driver or whatever that uses it.

Sure. It is non-free, but not a derivative of the kernel. Nvidia
 drivers also qualify here.

> This means that you are able to use these points (especially the last
> one) to respond to most of your question, and explain why the position
> of considering it ok to have non-free firmware in main is one that can
> be considered.

I do not buy it.

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?

manoj
-- 
e-credibility: the non-guaranteeable likelihood that the electronic data
you're seeing is genuine rather than somebody's made-up crap.- Karl
Lehenbauer
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: on firmware (possible proposal)

[Ben Finney]

Peter Palfrader <[EMAIL PROTECTED]> writes:

> I'm considering formally proposing this GR (option):
> 
> | 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 […]

This gives no argument for why such bitstreams should be held to
different standards of freedom for its recipients. The property “not
designed to be 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?

-- 
 \   “Pinky, are you pondering what I'm pondering?” “Well, I think |
  `\so, Brain, but I can't memorize a whole opera in Yiddish.” |
_o__)   —_Pinky and The Brain_ |
Ben Finney


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

Re: on firmware (possible proposal)

[Bernd Zeimetz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

I'd second the proposal as quoted below.

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

Cheers,

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

iEYEARECAAYFAkkct5kACgkQBnqtBMk7/3kl4QCcCxdv1R8GTrehUF5Q3R6rDNOC
jJcAn30u09aAqYBnyMMSMI0ZbS/qzXW5
=1coL
-END PGP SIGNATURE-


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

Re: on firmware (possible proposal)

[Peter Samuelson]

-- [Forward] -
From: Sven Luther <[EMAIL PROTECTED]>
Date: Thu, 13 Nov 2008 21:01:13 +0100

On Thu, Nov 13, 2008 at 01:43:32PM -0600, Peter Samuelson wrote:
> 
> 
> [Johannes Wiedersich]
> > I would propose to create a new section of the archive, called
> > 'sourceless' or such.  Stuff within this archive doesn't have full
> > sources. It is legally distributable and follows the DFSG with the
> > only exception of missing sources. On top of the DFSG it is required
> > that software in 'sourceless' _must not be executed_ on the host CPU.
> > 'sourcless' therfore applies to firmware as well as eg. documentation
> > pdfs or images without source.
> 
> You know what, I think this distinction about "running on the host CPU"
> is rather silly, and I'm starting to believe it is entirely artificial.
> By this I mean that the distinction itself would not matter, except
> that it sounds a little better than just saying firmware is necessary
> enough to compromise our principles on, but the Flash plugin is not.
> 
> But really, is there a principle of software freedom that distinguishes
> device firmware from, say, a [EMAIL PROTECTED] client using an NVidia GPU for
> compute cycles?  What about the ability to install a whole OS on a
> router - if you plug the router into the PC with a USB cable, could you
> consider the router to be "not the host CPU"?  The other day we were
> told d-i RC1 now supports certain NAS devices.  Would those be "hosts"
> or merely "devices" or "appliances"?  What about proprietary
> abandonware console game ROMs?  Those can run in an emulator but
> they're intended for real hardware that isn't "the host CPU".  Someone
> also mentioned Postscript, roughly the same situation.
> 
> Good thing Z80 daughterboards to run CP/M applications are no longer
> popular.

The important point here is the following (and these are not necessarily
my opinion, but the arguments used here) : 

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

=> The argument is here that it is not as important that this is
free software, since it cannot corrupt the software running on the
main cpu.

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

  - the third point, is that the fact that the code runs in a separate
device CPU, create a clear interface barrier, and make it clear that
the the uploaded firmware is not a derivative work of the kernel or
driver or whatever that uses it.

This means that you are able to use these points (especially the last
one) to respond to most of your question, and explain why the position
of considering it ok to have non-free firmware in main is one that can
be considered.

That said, the above argumentation sheed some light on the issue, but do
not constitute my opinion on what we should do, and anyway, my opinion
doesn't count since i can't vote since i was expulsed as so much garbage
from debian :/

Please forward this mail to the list, since i am being censored.

Sadly,

Sven Luther


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

Re: on firmware (possible proposal)

[Peter Samuelson]

[Johannes Wiedersich]
> I would propose to create a new section of the archive, called
> 'sourceless' or such.  Stuff within this archive doesn't have full
> sources. It is legally distributable and follows the DFSG with the
> only exception of missing sources. On top of the DFSG it is required
> that software in 'sourceless' _must not be executed_ on the host CPU.
> 'sourcless' therfore applies to firmware as well as eg. documentation
> pdfs or images without source.

You know what, I think this distinction about "running on the host CPU"
is rather silly, and I'm starting to believe it is entirely artificial.
By this I mean that the distinction itself would not matter, except
that it sounds a little better than just saying firmware is necessary
enough to compromise our principles on, but the Flash plugin is not.

But really, is there a principle of software freedom that distinguishes
device firmware from, say, a [EMAIL PROTECTED] client using an NVidia GPU for
compute cycles?  What about the ability to install a whole OS on a
router - if you plug the router into the PC with a USB cable, could you
consider the router to be "not the host CPU"?  The other day we were
told d-i RC1 now supports certain NAS devices.  Would those be "hosts"
or merely "devices" or "appliances"?  What about proprietary
abandonware console game ROMs?  Those can run in an emulator but
they're intended for real hardware that isn't "the host CPU".  Someone
also mentioned Postscript, roughly the same situation.

Good thing Z80 daughterboards to run CP/M applications are no longer
popular.
-- 
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/


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

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

[Manoj Srivastava]

On Thu, Nov 13 2008, Robert Millan wrote:

> On Wed, Nov 12, 2008 at 11:00:29AM -0600, Manoj Srivastava wrote:
>> Hi,
>> 
>> Well, splitting a vote into multiple ballots, with options
>>  referring to the same outcome, is a horrendously bad idea -- since the
>>  massive amounts of strategic voting possibilities will taint the final
>>  result.
>
> 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, I might give
> equal weight to A and B in order to prevent circular ambiguities.
>
> In fact it is only starting with the presence of a 3rd option that strategy
> gets into the game:
>
>   http://en.wikipedia.org/wiki/Gibbard-Satterthwaite_theorem

That theorem is silly. Firstly, all it is saying is that if you
 only have one or two options there can be no tactical voting (duh).

Secondly, it says in any voting system there will be conditions
 where voter with full knowledge of how the other voters are to vote and
 of the rule being used would have an incentive to vote in a manner that
 does not reflect his preferences.  Who has perfect knowledge?

Thirdly, there are ways in which we can mitigate the actual
 cases in which such conditions are present; and our voting method is
 one where such cases are rare; and we should not have to worry about
 ever having a third option on the ballot.

If anyone is interested, I can send them, offline, pointers to
 the properties in Schulze's method, which we use, and the potential
 benefit of using MAM, which I am considering coding for devotee.

manoj
-- 
Marriage is a romance in which the hero dies in the first chapter.
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: on firmware (possible proposal)

[Robert Millan]

On Wed, Nov 12, 2008 at 04:20:33PM +0100, Martin Michlmayr wrote:
> * Robert Millan <[EMAIL PROTECTED]> [2008-11-12 15:29]:
> > For example, if you want to install Debian on an NSLU, the only
> > difficulty is finding the unofficial D-I images that include
> > non-free firmware.  And even that can be improved.  They could be
> > linked from the main website, and integrated with our
> > infrastructure, much like we do for "non-free", as long as we make
> > it clear they're not officially "Debian".
> 
> The problem with this is that we'll end up shipping official Debian
> CDs that won't work on many systems and eventually we'll end up
> telling people "take the unofficial one, you know, the one that
> actually works".  I've been doing that for NSLU2 and there it's not
> such a big deal because everyone uses netboot images, but it's more of
> a problem with CDs/DVDs.

I know people who use Debian themselves, but when asked tell "take the Ubuntu
one, it supports more hardware".  Sure, we can try to compete with that if
that's more practical than either not recommending non-free or shipping two
build sets.  If we go this route, expect that we will either go half-way and
not actually make any difference, or push further and bundle our default
setup with Nvidious blobs, a "restricted devices" daemon, Adobe flash, etc,
etc.

In the end, you can't out-Ubuntu Ubuntu.

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

[Robert Millan]

On Wed, Nov 12, 2008 at 03:49:44PM +0100, Patrick Schoenfeld wrote:
> On Wed, Nov 12, 2008 at 03:29:30PM +0100, Robert Millan wrote:
> > For example, if you want to install Debian on an NSLU, the only difficulty 
> > is
> > finding the unofficial D-I images that include non-free firmware.  And even
> > that can be improved.  They could be linked from the main website, and
> > integrated with our infrastructure, much like we do for "non-free", as long
> > as we make it clear they're not officially "Debian".
> 
> well, as you say for yourself "non-free" is not Debian, which basically
> means that we provide infrastructure and such, but if in doubt the user
> is left alone with his problems.

We don't have any rules saying that non-free users have to be left alone with
their problems.  Some of us aren't going to help supporting non-free, but this
doesn't mean you can't do it if you like.

Isn't this what we had SC #4 and SC #5 for?

-- 
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 Wed, Nov 12, 2008 at 11:00:29AM -0600, Manoj Srivastava wrote:
> Hi,
> 
> Well, splitting a vote into multiple ballots, with options
>  referring to the same outcome, is a horrendously bad idea -- since the
>  massive amounts of strategic voting possibilities will taint the final
>  result.

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, I might give equal weight to A and B in order
to prevent circular ambiguities.

In fact it is only starting with the presence of a 3rd option that strategy
gets into the game:

  http://en.wikipedia.org/wiki/Gibbard-Satterthwaite_theorem

Also, note that my alternate option to Andreas' proposal [1] was carefully
worded to avoid making assumptions about the order in which votes would be
processed.

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

-- 
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 Wed, Nov 12, 2008 at 04:17:23PM +0100, Adeodato Simó wrote:
> I hate complex ballots. They tend to work against the goal of a vote,
> which is getting a crystal clear assessment on the opinions of the
> Developers.
> 
> This vote is at 5 options already, with 2 more underway. I want to
> propose, and get consensus on it, to logically split the vote in two or
> three simple ballots, one for each of the orthogonal issues at hand.
> 
> These issues are (in the order they should be voted on):
> 
>   1. Do we require source for firmware in main.
> 
>  I don't think we have ever had this vote, and it's about time that
>  we do, *without bundling it with somebody else*. This is Peter
>  Palfrader's proposal at [1].
> 
>  This vote has two options in it.
> 
>   2. Do we allow the Release Team to use without a GR -ignore
>  tags on bugs for violations of the SC.
> 
>  We haven't had this vote either, and it seems now it would be good
>  to have it.
> 
>  This vote also has two options on it, eg. something akin to Andreas
>  Barth's proposal [2] on one side, and Robert's reply [3] on the other.
> 
>   3. What do we do for Lenny.
> 
>  The necessity for this vote depends on the results of the two votes
>  above, and I think it should have at most 3 options: delay Lenny
>  until all firmware issues known by some date are solved: (a)
>  allowing source-less, (b) not allowing source-less; or don't delay it.
> 
> I'm a bit lost as to what I could get done in order to have this go
> forward, since there have been a lot of seconds for the various options.
> I do think it would be a Good Thing. I'm CC'ing secretary@ and leader@
> to see what they think.

I second this.  Notice, however, that my alternate option to Andreas' proposal
hasn't got enough sponsors yet:

>   [3]: http://lists.debian.org/debian-vote/2008/11/msg00086.html 

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


signature.asc
Description: Digital signature

Re: on firmware (possible proposal)

[Johannes Wiedersich]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ean Schuessler wrote:
> "Johannes Wiedersich" <[EMAIL PROTECTED]>
> wrote:
> 
>> I would propose to create a new section of the archive, called
>> 'sourceless' or such. Stuff within this archive doesn't have full
>> sources. It is legally distributable and follows the DFSG with the
>> only exception of missing sources. On top of the DFSG it is 
>> required that software in 'sourceless' _must not be executed_ on
>> the host CPU. 'sourcless' therfore applies to firmware as well as
>> eg. documentation pdfs or images without source.
> 
> For the sake of argument, what if we created a distribution of Debian
> that only runs on architectures with more than one CPU. We will
> designate one of the CPUs to be the "non-free CPU". This CPU will run
> all "sourceless" software. For this distribution we can move all of
> non-free into the "sourceless" designation since it does not run on
> the "host CPU".

Well, even if at some time in the future all architectures supported by
debian will require multiple CPUs and thus make it possible to move
'non-free' stuff to 'sourceless' without breaking the package for any
single CPU architecture...

 - 'sourceless' still won't be 'main'
 - the user has to acknowledge each installation of 'sourceless'
   packages

I guess by the time this happens, the very idea of what an OS is and
what it does will have changed so much, that many other parts of
debian's policy will be affected as well...

Cheers,

Johannes

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

iEYEARECAAYFAkkb4b4ACgkQC1NzPRl9qEWBvQCeNJtWMz0iX+msxFW5WUgMIqjI
Ic4An0y5jxnCe+PsNK0BeIeJAByGqZg/
=8tna
-END PGP SIGNATURE-


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