Discussion:
[DRAFT] resolving DFSG violations
(too old to reply)
Manoj Srivastava
2008-10-21 17:52:28 UTC
Permalink
Though, when this software is central to all Debian (as the kernel is,
or the glibc for the sunrpc issue, or mesa for the GLX code, or ...),
then as it's a long and slow work to either prune the firmware, or deal
with the copyright holders to relicense (and mesa has made it, proof
that it's possible, but it needed like 2 or 3 releases of Debian to do
so !), the Release team acknowledge that progress has been made, and
tags the bugs $suite-ignore.
This is the part I am not comfortable with. I do not think the
delegates have the powers to decide when enough progress has been made
to violate a foundation document in our release. Just like an
individual developer does not have a right to decide to violate the
DFSG in their work, I think the release team, which prepares the
release, can do so unilaterally either (I did not vote for Bush).

This is why my contention has been that the developer body, as a
whole, has to be brought into the decision loop, like they have
for the last two releases, and make sure we, as a project, stand
behind the decision, not just a few hapless RMs.

So, I would like to see an option on the ballot that sates that
we will release Lenny with known DFSG violations, we believe in the SC,
but we also have to respect the needs of users, and we think progress
is being made towards ensuring that the needs of our users can be met
with free software in the future. I just do not think this is within
delegate or individual developer powers.

manoj
--
VMS must die!
Manoj Srivastava <***@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Pierre Habouzit
2008-10-21 18:24:59 UTC
Permalink
Post by Manoj Srivastava
Though, when this software is central to all Debian (as the kernel is,
or the glibc for the sunrpc issue, or mesa for the GLX code, or ...),
then as it's a long and slow work to either prune the firmware, or deal
with the copyright holders to relicense (and mesa has made it, proof
that it's possible, but it needed like 2 or 3 releases of Debian to do
so !), the Release team acknowledge that progress has been made, and
tags the bugs $suite-ignore.
This is the part I am not comfortable with. I do not think the
delegates have the powers to decide when enough progress has been made
to violate a foundation document in our release. Just like an
individual developer does not have a right to decide to violate the
DFSG in their work, I think the release team, which prepares the
release, can do so unilaterally either (I did not vote for Bush).
And you're comfortable with ftp-master ruling DFSG-iness through NEW
then ? I don't really see the difference.

FWIW you can query all the lenny-ignore bugs on the BTS, there arent a
lot, and check if you agree. Unlike Bush (and the reference is quite
offensive, really) we don't hide such matters, and we never said we're
not open to discussion.

BUt yeah, tagging bugs lenny-ignore is part of the RM tasks, and we're
delegated for that (among other things).
--
·O· Pierre Habouzit
··O ***@debian.org
OOO http://www.madism.org
Thomas Bushnell BSG
2008-10-21 20:26:24 UTC
Permalink
Post by Pierre Habouzit
Post by Manoj Srivastava
This is the part I am not comfortable with. I do not think the
delegates have the powers to decide when enough progress has been made
to violate a foundation document in our release. Just like an
individual developer does not have a right to decide to violate the
DFSG in their work, I think the release team, which prepares the
release, can do so unilaterally either (I did not vote for Bush).
And you're comfortable with ftp-master ruling DFSG-iness through NEW
then ? I don't really see the difference.
I can't speak for Manoj, but for my own part, I have not seen any
evidence that ftp-master is letting things through NEW which are in
clear violation of the DFSG, so it doesn't come up.
Post by Pierre Habouzit
FWIW you can query all the lenny-ignore bugs on the BTS, there arent a
lot, and check if you agree. Unlike Bush (and the reference is quite
offensive, really) we don't hide such matters, and we never said we're
not open to discussion.
BUt yeah, tagging bugs lenny-ignore is part of the RM tasks, and we're
delegated for that (among other things).
So far, the release team has shown no awareness in this thread that
ignoring a technical RC bug is entirely different from ignoring a
violation of the core documents of the project. Nobody is talking about
technical bugs, and it would be helpful if y'all stopped bringing them
up.

Thomas
Raphael Hertzog
2008-10-23 06:36:24 UTC
Permalink
Post by Thomas Bushnell BSG
Post by Pierre Habouzit
Post by Manoj Srivastava
This is the part I am not comfortable with. I do not think the
delegates have the powers to decide when enough progress has been made
to violate a foundation document in our release. Just like an
individual developer does not have a right to decide to violate the
DFSG in their work, I think the release team, which prepares the
release, can do so unilaterally either (I did not vote for Bush).
And you're comfortable with ftp-master ruling DFSG-iness through NEW
then ? I don't really see the difference.
I can't speak for Manoj, but for my own part, I have not seen any
evidence that ftp-master is letting things through NEW which are in
clear violation of the DFSG, so it doesn't come up.
Every kernel upload changing the ABI goes through NEW.

Your lack of knowledge of Debian processes sucks (that means: you
annoy us (at least me) with your stance and the fanatic way you defend it
in public, please stop this and come back to more constructive
discussions).

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Thomas Viehmann
2008-10-23 07:44:33 UTC
Permalink
Post by Raphael Hertzog
Every kernel upload changing the ABI goes through NEW.
The typical situation here is that code that has the same set of DFSG
bugs is already in place and so it is questionable of what a reject
really achieves (i.e. does the archive become more DFSG-compliant or
not) and quite typically fixes some RC bugs (not always trashing
people's hardware). Sure, the ftp team can make this into a stand-off,
but the situation is much less clear than e.g. when the ftp team had
openjdk-6 in NEW, which had its (known or discovered during the vetting)
DFSG problems fixed rather fast and before it entered the archive in
first place, thanks to the maintainer (Matthias) willing to get the bugs
fixed and thanks to a cooperative upstream.

So let's evaluate options other than rejecting:
As for the suggestions to move linux-2.6 to non-free (which, again,
would have required someone to upload that): The ftp team usually are
pretty ruthless about pulling stuff from main with problems if it
doesn't get fixed fast, but in the case of the kernel and glibc the
Social Contract's
We will never make the system require the use of a non-free component.
puts a limit on what can be done: Aside from the additional work it
would cause to everyone (installer, ...) and the undesirable effect of
effectively forcing people to add non-free, moving stuff required for
running Debian into non-free seems shady from a Social Contract point of
view.
Note how the situation would be vastly different if we had a known-good
kernel package was somewhere in the archive (be it testing or unstable).

And about the options of fixing it or just insulting other people to fix
it I should note that the objection that finding a widely welcomed fix
involves work (on blob loaders) that someone interested in a free kernel
has no intrinsic motivation to do: A lot of tasks do that. I want a
release and when I ask the release team, they tell me to fix RC bugs in
stuff I personally don't care about one single bit. I don't get to yell
at the release team for that (though I do at the maintainers of RC buggy
packages possibly more than I should), but have the choice of working on
stuff or not. Claiming that "I want a release now and we could just
release, all the RC bugs are in packages I have no interest in" would be
openly preposterous and in the case of "I would work on freeing the
kernel of but finding something to make everyone happy involves making
the firmware loadable in non-free" thinly disguises the same sentiment
of "I'm not going to help unless it's 100% my way" in the disguise of a
taking a higher moral stance than everyone else. "Moral, das ist, wenn
man moralisch ist, versteht Er."

Kind regards

T.
--
Thomas Viehmann, http://thomas.viehmann.net/
Steve Langasek
2008-10-24 06:18:09 UTC
Permalink
Post by Thomas Viehmann
Post by Raphael Hertzog
Every kernel upload changing the ABI goes through NEW.
The typical situation here is that code that has the same set of DFSG
bugs is already in place and so it is questionable of what a reject
really achieves (i.e. does the archive become more DFSG-compliant or
not) and quite typically fixes some RC bugs (not always trashing
people's hardware).
This does not seem to be a position universally held by the ftp team, given
that a library I uploaded to binary NEW ths summer for a
release-team-approved transition was rejected over a source-only issue of
not mentioning in debian/copyright a pre-existing user guide not shipped in
any of the binary packages. Or is it only kernel DFSG-compliance bugs that
get ignored in binary NEW, while all the other nitpicky checks are grounds
for a package reject?
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
Reinhard Tartler
2008-10-24 07:14:16 UTC
Permalink
Post by Steve Langasek
Post by Thomas Viehmann
The typical situation here is that code that has the same set of DFSG
bugs is already in place and so it is questionable of what a reject
really achieves (i.e. does the archive become more DFSG-compliant or
not) and quite typically fixes some RC bugs (not always trashing
people's hardware).
This does not seem to be a position universally held by the ftp team
What is the designated way for escalating a dispute like this with
ftp-master?

With "Like this" I mean packages that have been held back in NEW for a
very long time without response or REJECTED with an reason not
acceptable to the maintainer? Does mediating this kind of issues fall
under the authority of the TC, or should they be escalated rather to the
DPL?
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Kalle Kivimaa
2008-10-24 07:57:56 UTC
Permalink
Post by Reinhard Tartler
With "Like this" I mean packages that have been held back in NEW for a
very long time without response or REJECTED with an reason not
acceptable to the maintainer? Does mediating this kind of issues fall
under the authority of the TC, or should they be escalated rather to the
DPL?
Well, if a package is in NEW for a long time, that's something that
really cannot be mediated, as it probably means that none of the
ftpmasters (or assistants) have had the time to look into it (meaning
it is very likely a very complex package with licensing issues), and
no authority in Debian can force any project member to do work the
member doesn't want to do.

If a package is REJECTED with a reason the maintainer thinks is
invalid, I think the first step should be to tell the ftpmaster (as a
group) the reasons. It is always possible that a ftpmaster (as a
person) has made a mistake.
--
* Sufficiently advanced magic is indistinguishable from technology (T.P) *
* PGP public key available @ http://www.iki.fi/killer *
Martin Meredith
2008-10-24 09:55:02 UTC
Permalink
Post by Kalle Kivimaa
Post by Reinhard Tartler
With "Like this" I mean packages that have been held back in NEW for a
very long time without response or REJECTED with an reason not
acceptable to the maintainer? Does mediating this kind of issues fall
under the authority of the TC, or should they be escalated rather to the
DPL?
Well, if a package is in NEW for a long time, that's something that
really cannot be mediated, as it probably means that none of the
ftpmasters (or assistants) have had the time to look into it (meaning
it is very likely a very complex package with licensing issues), and
no authority in Debian can force any project member to do work the
member doesn't want to do.
If a package is REJECTED with a reason the maintainer thinks is
invalid, I think the first step should be to tell the ftpmaster (as a
group) the reasons. It is always possible that a ftpmaster (as a
person) has made a mistake.
Indeed, I recently actually had this happen to me. An upload that I made
was rejected by an FTP Master (for convenience copies of code) - when I
pointed out to the FTP master the reason(s) why this was there (was
actually modified from upstream, debian didn't have the latest package,
the latest packages had huge API changes, etc etc) - he was happy to let
it through.
Thomas Viehmann
2008-10-24 15:58:51 UTC
Permalink
Hi Steve,
Post by Steve Langasek
Post by Thomas Viehmann
Post by Raphael Hertzog
Every kernel upload changing the ABI goes through NEW.
The typical situation here is that code that has the same set of DFSG
bugs is already in place and so it is questionable of what a reject
really achieves (i.e. does the archive become more DFSG-compliant or
not) and quite typically fixes some RC bugs (not always trashing
people's hardware).
This does not seem to be a position universally held by the ftp team, given
that a library I uploaded to binary NEW ths summer for a
release-team-approved transition was rejected over a source-only issue of
not mentioning in debian/copyright a pre-existing user guide not shipped in
any of the binary packages. Or is it only kernel DFSG-compliance bugs that
get ignored in binary NEW, while all the other nitpicky checks are grounds
for a package reject?
Thank you for voicing your concern about inconsistencies you perceive in
the processing of NEW (note that "binary NEW" is not a separate location
to upload to). As with any manual process, particularly when handled by
several individuals, NEW processing will quite probably not be as
deterministic as one might wish, if only in the style of reject
messages, but probably also in cases that are not entirely clear. As you
may know, the ftp team is split into roles of ftp-master and
ftp-assistant, with myself being listed as assistant[1]. I have to
balance my (felt[2]) obligation to provide the project with information
about my work in that position with the fact that my this work
necessarily involves assessments that are neither necessarily uniform
nor binding for other members of the ftp team.
My comment you quote above gives some rationale of why I did choose to
add overrides for certain binaries added by linux-2.6, as Raphaël
pointed out I had. If you disagree with the descision of letting these
pass through NEW, I would be very happy to learn why I should not have
done so in your opinion.

Unfortunately, you do not give a reference, but if the upload of yours
that you have in mind is freetds[3], let me venture that perhaps the
considerations[4] I offered in the thread you started about it in July
might actually help to put both things into more context. I am sorry to
hear that these explanations were not satisfactory to you but must admit
that I may have overlooked previous indication of how they fall short.
Note that I do not agree with you on the issues you raise in[3], but you
surely have more information to add when you bring it up here.

If just did not want to pass the excellent chance of someone on the ftp
team actually posting something to add some flames about the pet grudge
you hold when I was trying to provide information to enable the project
at large to take into account the rationale of actions when deciding
whether to instruct the people to make better decisions than they do by
their own, that is very valuable to me, too. You could be even more
effective by CCing the DPL as surely he will be happy to correct
appointments his predecessor made precisely eight months ago on this
day[5] when they do not work out as expected.

Again, thank you for helping to improve Debian's processes by providing
your critique.

Kind regards

T.

1. http://www.debian.org/intro/organization
2. I had the impression that sometimes the ftp team is criticized as not
operating transparently enough and think that it is reasonable that
the project deserves explanations when they feel that a decision
needs scrutiny.
3. http://lists.debian.org/debian-project/2008/07/msg00017.html
4. http://lists.debian.org/debian-project/2008/07/msg00032.html
5. http://lists.debian.org/debian-devel-announce/2008/02/msg00009.html
--
Thomas Viehmann, http://thomas.viehmann.net/
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Robert Millan
2008-10-23 14:08:17 UTC
Permalink
Post by Raphael Hertzog
Every kernel upload changing the ABI goes through NEW.
Your lack of knowledge of Debian processes sucks (that means: you
annoy us (at least me) with your stance and the fanatic way you defend it
in public, please stop this and come back to more constructive
discussions).
And I take it that Thomas is supposed to take your attitude as an example
on how being constructive?
--
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."
Josselin Mouette
2008-10-24 10:29:16 UTC
Permalink
Post by Robert Millan
Post by Raphael Hertzog
Your lack of knowledge of Debian processes sucks (that means: you
annoy us (at least me) with your stance and the fanatic way you defend it
in public, please stop this and come back to more constructive
discussions).
And I take it that Thomas is supposed to take your attitude as an example
on how being constructive?
Maybe you should take it that even our favorite care bear is starting to
be pissed of by his behavior.
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
Manoj Srivastava
2008-10-22 13:15:55 UTC
Permalink
Post by Pierre Habouzit
And you're comfortable with ftp-master ruling DFSG-iness through NEW
then ? I don't really see the difference.
I would be uncomoftable with ftp-masters willfully allowing DFSG
violations in main without ratification from the project as a whole as
well.
Post by Pierre Habouzit
BUt yeah, tagging bugs lenny-ignore is part of the RM tasks, and we're
delegated for that (among other things).
Every developer has the right to manage their own bugs too. But
they do not have the right to just downgrade or close bugs saying that
their package has a DFSG violation. I think the same principle applies
here.

manoj
--
Silence is the element in which great things fashion themselves. Thomas
Carlyle
Manoj Srivastava <***@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Pierre Habouzit
2008-10-22 13:59:27 UTC
Permalink
Post by Manoj Srivastava
Post by Pierre Habouzit
And you're comfortable with ftp-master ruling DFSG-iness through NEW
then ? I don't really see the difference.
I would be uncomoftable with ftp-masters willfully allowing DFSG
violations in main without ratification from the project as a whole as
well.
I have no evidence they do, my point is they have the same power, and if
they do, it's silent. When a RM choses to ignore a bug it's completely
non-silent and easy to post-check[0].

Though technically, as every new kernel goes through NEW, they *did*.
They willfully allowed DFSG violations last time they accepted a kernel
(some of the bugs on firmwares predate the last passage through NEW I
think).
Post by Manoj Srivastava
Post by Pierre Habouzit
BUt yeah, tagging bugs lenny-ignore is part of the RM tasks, and we're
delegated for that (among other things).
Every developer has the right to manage their own bugs too. But
they do not have the right to just downgrade or close bugs saying that
their package has a DFSG violation. I think the same principle applies
here.
At some point, someone has to decide. Doing a vote for each is
impractical. As our choice is _not_ silent, if someones (like usually
the reporter who _sees_ such tags happen) disagree, he can raise a
discussion. AFAICT it's what is happening currently, and it shows that
the system is sane and works. At some point if we want to scale, we have
to delegate, and it's just that.


[0] http://bugs.debian.org/tag:lenny-ignore
--
·O· Pierre Habouzit
··O ***@debian.org
OOO http://www.madism.org
Manoj Srivastava
2008-10-23 17:06:19 UTC
Permalink
Post by Pierre Habouzit
At some point, someone has to decide. Doing a vote for each is
impractical. As our choice is _not_ silent, if someones (like usually
the reporter who _sees_ such tags happen) disagree, he can raise a
discussion. AFAICT it's what is happening currently, and it shows that
the system is sane and works. At some point if we want to scale, we have
to delegate, and it's just that.
Look, I am not proposing we have a GR for every upload. I am
saying that non-free bits in main are a bug. A serious bug. A RC
bug. It is a big fucking deal. It comes to the core of what Debian is.

Now, we know there are unknon bugs and known bugs in the
archive, especially in Sid. Shit happens. Bugs take time to fix. But
releasing with DFSG violations should still be a big deal. It is not
something that some delegate decides is OK to do. The project tands up,
acknowledges we failed out users by not providing them a free operating
system like we promised in the social contract, acknowledge that the
SC is still what we would like to do, but we failed this time around,
and, as a project, take responsibility for our failure.

This is what we have done in the past, through GR's for Sarge
and Etch. We should not become Blase about shipping non-free operating
systems. It should not become common place.

manoj
--
Ditat Deus. [God enriches]
Manoj Srivastava <***@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Thilo Six
2008-10-23 19:14:42 UTC
Permalink
Manoj Srivastava wrote the following on 23.10.2008 19:06


<- *snip* ->
Post by Manoj Srivastava
Look, I am not proposing we have a GR for every upload. I am
saying that non-free bits in main are a bug. A serious bug. A RC
bug. It is a big fucking deal. It comes to the core of what Debian is.
Now, we know there are unknon bugs and known bugs in the
archive, especially in Sid. Shit happens. Bugs take time to fix. But
releasing with DFSG violations should still be a big deal. It is not
something that some delegate decides is OK to do.
manoj
who has not yet switched to the free drivers for nvidia cards yet


<- *snip* ->
--
bye Thilo

key: 0x4A411E09
Manoj Srivastava
2008-10-23 17:23:22 UTC
Permalink
It's all a matter of defining what your priorities are, which brings
- 100% freeness
- cater best to the interests of our users
Frankly, this mindset infuriates me. It frames the discussion
incorrectly, it implies that freeness and user interest are at
odds. Logically, it aargues that Windows is the best for users, since
it caters to newbies, and is not free- and since the implication is
that freedom can be taken too far, allowing the users freedom to see
movies legally, to use MS office and photoshop legally might triump the
new fangled linux thingy.

No. Freedom is in the long term best interests of the users. We
allow people to use non-free stuff, yes -- but we do so not by
tainting main, but by putting these tools to help the unfortunate
folks who cannot take advantage of a free operating system.


The same goes for people who are complaining oabout advocates
of the social contract and libre software, calling them folks who do
not care for users. I contend that people who stuff main with non-free
stuff _are_ the ones acting against the interests of the suers in the
long term, since freedom is the gift that Debian started out trying to
give users.

Why is not putting non-free firmware in non-free not the right
thing to do? Why is trying to create a 100% free distribution, as our SC
states, supposed ot be the dark side? I hope the few loud voices acting
against the interests of the users by trying to prevent Debian from
providing them a free operating system are indeed few.

manoj
--
The beauty of a pun is in the "Oy!" of the beholder.
Manoj Srivastava <***@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Ean Schuessler
2008-10-23 18:02:30 UTC
Permalink
Post by Manoj Srivastava
It's all a matter of defining what your priorities are, which brings
- 100% freeness
- cater best to the interests of our users
Frankly, this mindset infuriates me. It frames the discussion
incorrectly, it implies that freeness and user interest are at
odds. Logically, it aargues that Windows is the best for users, since
it caters to newbies, and is not free- and since the implication is
that freedom can be taken too far, allowing the users freedom to see
movies legally, to use MS office and photoshop legally might triump the
new fangled linux thingy.
Its a lot like exercise. Its not convenient and its not easy but in the long run its a good idea.

I think the loud voices you are talking about are the same kind of loud, short-term gain voices that have caused so much trouble for the American economy. The point is that what is "best for the user" and what is "convenient or easy for the user" may not be the same thing. It is convenient and easy to eat fast food every day but it will make you fat and unhealthy.

So it is the same way with your computer. It is easy and convenient to give up freedom and control so you can watch a movie and play a cool 3D game, but you end up with your data trapped in an infrastructure controlled by the interests of others.

Now, breaking the law to keep control... I don't know how we advocate that. That's a harder question. Without law the whole notion of copyright is farcical and the DFSG becomes largely meaningless unless we are looking to some kind of "higher law". Not clear how that works.
--
Debian, choice of a GNU generation.
Chris Bannister
2008-10-25 04:38:20 UTC
Permalink
Post by Ean Schuessler
Its a lot like exercise. Its not convenient and its not easy but in the long run its a good idea.
Nice pun! :)
--
Chris.
======
I contend that we are both atheists. I just believe in one fewer god
than you do. When you understand why you dismiss all the other
possible gods, you will understand why I dismiss yours.
-- Stephen F Roberts
Steve Langasek
2008-10-25 04:39:32 UTC
Permalink
Post by Manoj Srivastava
It's all a matter of defining what your priorities are, which brings
- 100% freeness
- cater best to the interests of our users
Frankly, this mindset infuriates me. It frames the discussion
incorrectly, it implies that freeness and user interest are at
odds.
No, it acknowledges that freeness and user interest are *sometimes* at
odds, and leaves it up to humans with faculties of reason to sort out which
of these two competing factors takes precedence in any given situation.

Otherwise, it might as well have just said "Our priority is our users"; if
you believe that what's best for free software is *always* what's best for
our users, and that what's best for our users is to use only free software,
then there's no need to spell this out as two *separate* priorities, right?

For users whose world is not circumscribed by the boundaries of the Debian
project, it is often the case that their short-term needs cannot be
satisfied by strictly free-software solutions. To demand, then, that users
make do with Free Software when it doesn't meet their needs is
self-defeating: it denies us the support of users who are potentially
sympathetic to the principles of Free Software, and it denies them the use
of the best OS on the planet.

To forestall the inevitable strawmen, I'll say plainly that I am *not*
arguing that this justifies including non-free software in Debian proper.
What I *am* arguing is that we are called by the Social Contract to help
ensure Debian's continued utility to the general population, because if
nothing else, that's where we find the next generations of developers who
will keep our project alive. This doesn't mean we should all drop what
we're doing and work on the firmware issue; but at the very least,
developers shouldn't be sanguine about proposing the outright removal of
firmware blobs, with no support for loading them from non-free, as a
"solution".
Post by Manoj Srivastava
The same goes for people who are complaining oabout advocates
of the social contract and libre software, calling them folks who do
not care for users. I contend that people who stuff main with non-free
stuff _are_ the ones acting against the interests of the users in the
long term,
It's pretty insulting to suggest that there is a non-zero set of developers
who have been "stuffing" non-free stuff into main, particularly when the
very kernel team that's being maligned by this implication is the same group
that has already done the heavy lifting of as much of the sourceless
firmware removal as we've achieved so far.
Post by Manoj Srivastava
Why is not putting non-free firmware in non-free not the right
thing to do?
It is the right thing to do; and while I know there are people that
disagree, I haven't seen anyone in *this thread* disagree with that. But
there are lots of other things that are "right" to do, and not all of them
are possible to achieve at the same time with limited resources. Is it
still the Right Thing to remove non-free firmware if we don't also make it
possible to load it from non-free at the same time? Is it the Right Thing
to delay the next release indefinitely while the firmware problems are
sorted out?

Right now, I suspect the right thing to do might be for me to abandon this
thread and go fix some bugs instead.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
***@ubuntu.com ***@debian.org
Manoj Srivastava
2008-10-25 05:22:30 UTC
Permalink
Post by Steve Langasek
Post by Manoj Srivastava
It's all a matter of defining what your priorities are, which brings
- 100% freeness
- cater best to the interests of our users
Frankly, this mindset infuriates me. It frames the discussion
incorrectly, it implies that freeness and user interest are at
odds.
No, it acknowledges that freeness and user interest are *sometimes* at
odds, and leaves it up to humans with faculties of reason to sort out
which of these two competing factors takes precedence in any given
situation.
In the long term, I do not think that is the case.

In the short term, sure, and we have determined that the place
to put non-free things that users might need to address their needs is
called the non-free part of the archive.
Post by Steve Langasek
To forestall the inevitable strawmen, I'll say plainly that I am *not*
arguing that this justifies including non-free software in Debian
proper. What I *am* arguing is that we are called by the Social
Contract to help ensure Debian's continued utility to the general
population, because if nothing else, that's where we find the next
generations of developers who will keep our project alive.
Back when we were deciding about all this, Alex Yukhimets argued
against the free requirement, saying that including the non-free
netscape browser was absolutely critical to the survival of Debian,
since other wise we'd have no users.

Surprisingly, we survived then, and I suspect we'll survive
now. And despite not including non-free netscape in main, the fact we
had a social contract that we followed made Debian stronger.
Post by Steve Langasek
Otherwise, it might as well have just said "Our priority is our
users"; if you believe that what's best for free software is *always*
what's best for our users, and that what's best for our users is to
use only free software, then there's no need to spell this out as two
*separate* priorities, right?
And, if you continue to read just a wee bit longer, you'lll see
we also say that we will provide such stuff that users need that does
not meet our definition of free in -- surprise --- the non-free section.
Post by Steve Langasek
This doesn't mean we should all drop what we're doing and work on the
firmware issue; but at the very least, developers shouldn't be
sanguine about proposing the outright removal of firmware blobs, with
no support for loading them from non-free, as a "solution".
It is not an ideal solution, but is better than sloshing it all
under the carpet and pretending all is kosher with our supposed
to be 100% free OS.
Post by Steve Langasek
Post by Manoj Srivastava
The same goes for people who are complaining oabout advocates
of the social contract and libre software, calling them folks who do
not care for users. I contend that people who stuff main with
non-free stuff _are_ the ones acting against the interests of the
users in the long term,
It's pretty insulting to suggest that there is a non-zero set of developers
who have been "stuffing" non-free stuff into main, particularly when the
very kernel team that's being maligned by this implication is the same group
that has already done the heavy lifting of as much of the sourceless
firmware removal as we've achieved so far.
Is it any less insulting to say people who want to explicitly
acknowledge that we are failing to meet the standards we set ourselves
are "user haters", de-constructive whiners and zealots?

If insults are what get your goat, I can list a number uttered
by people on this thread against people who are raising concerns
about silently slipping in non-free stuff in main.

Indeed, we have been slimed by the Debian equivalent of being
Terrists.
Post by Steve Langasek
Post by Manoj Srivastava
Why is not putting non-free firmware in non-free not the right
thing to do?
It is the right thing to do; and while I know there are people that
disagree, I haven't seen anyone in *this thread* disagree with that.
But there are lots of other things that are "right" to do, and not all
of them are possible to achieve at the same time with limited
resources. Is it still the Right Thing to remove non-free firmware if
we don't also make it possible to load it from non-free at the same
time? Is it the Right Thing to delay the next release indefinitely
while the firmware problems are sorted out?
Yes, loaded question, and yes again.

I have a piece of hardware not supported by free software. I
install the OS, and go through a step where I access the driver from
non-free post-install and get the full functionality in a second
step. I think that is perfectly acceptable. With netwrok hardware, the
ubiquitous USB drive and sneaker net is fine too.

It should not take us an indefinite time to release with
firmware blobs gone. I'll stake my reutation that the period involved
is not indefinite, and there is a upper boundary to it.

Testing out the patches that have been produced by Ben ought not
to take "indefinite" time. It took me just a couple of hours to test
the kernels on the four machines I own; and they worked just fine. Of
course, my machines are not affected by the firmware issues, so I know
this means little for the regression testing.

Given the state of RC bugs, I am not sure how much delay we
would entail while we test out the stripped kernel. I'll be willing to
help test, if it comes to that.


manoj
--
It is necessary to have purpose. Alice #1, "I, Mudd", stardate 4513.3
Manoj Srivastava <***@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Jeff Carr
2008-10-25 13:46:14 UTC
Permalink
Post by Manoj Srivastava
It should not take us an indefinite time to release with
firmware blobs gone. I'll stake my reutation that the period involved
is not indefinite, and there is a upper boundary to it.
Testing out the patches that have been produced by Ben ought not
to take "indefinite" time. It took me just a couple of hours to test
the kernels on the four machines I own; and they worked just fine. Of
course, my machines are not affected by the firmware issues, so I know
this means little for the regression testing.
I'm willing to stake my reputation on betting you are _not_ a firmware
engineer. Your are totally wrong if you think all firmware blobs can
be replaced by human readable source.

There is hardware, for which to function, will always, for the
lifetime of the equipment, require a firmware blob to operate. This
will always be the case; there will never be a human readable version.
It will never be possible to compile it (with non-free compilers) from
source code. There seems to be the belief that there is some scary
bogeyman at the end of this tunnel; some deliberate evil firmware
engineer who refuses to release the "source" for the blob. This is
hardly the case.

In fact, the exact opposite is true; the most free pieces of hardware
in the world require a firmware blob! A good example: try out the pci
core from opencores.org. Even in that case, where you have the logic
for the actual chip, you still have no choice but to distribute a
firmware blob anyway.

Going and flapping around and irritating hardware engineers with
totally impossible requests (Give us your psoc firmware sourcecode or
you suck! Thanks, the debian project.) makes us look like a bunch of
clueless and irrational software engineers. You think there must be
some magic way, well there is not.

I doubt anyone reading this uses coreboot which means that the first
instruction anyone ran today was a binary only firmware blob. Where is
all your concern about that? Doubly annoying is that that firmware is
actually x86 code and it is possible to get source code that can be
compiled with gcc. That would actually be fruitful and practical.
Manoj Srivastava
2008-10-25 14:21:14 UTC
Permalink
Post by Jeff Carr
Post by Manoj Srivastava
It should not take us an indefinite time to release with
firmware blobs gone. I'll stake my reutation that the period involved
is not indefinite, and there is a upper boundary to it.
Testing out the patches that have been produced by Ben ought not
to take "indefinite" time. It took me just a couple of hours to test
the kernels on the four machines I own; and they worked just fine. Of
course, my machines are not affected by the firmware issues, so I know
this means little for the regression testing.
I'm willing to stake my reputation on betting you are _not_ a firmware
engineer. Your are totally wrong if you think all firmware blobs can
be replaced by human readable source.
I used to be, but that was a lifetime ago. However, this is
irrelevant, you are framing the discussion incorrectly.

Your argument boils down to: There is function that will never
be supported by free software. Annoying people by asking them to expose
their function by freeing the software just ittitates them, so we
should just suck it up and accept it.

Great. So there is function that can't be supported by free
software. Wer know that. Some user might need that functionality. We
know that too. We (gasp) even put it into the social contract over a
_decade_ ago.

Guess how we cater to people who need non-free software for
some functionality they must have? We put it into a place called the
non-free archive.

You do not have to be a "firmware engineer" to grok that.

manoj

ps: back in the day, before I became a quantum mechanic, I toyed around
with seeing if designing microprocessors was for me. I did design a 27
instructions, 4 bit microprocessor with microcode, so I get what
firmware is.
--
The graveyards are full of indispensable men. Charles de Gaulle
Manoj Srivastava <***@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Paul Wise
2008-10-25 14:51:06 UTC
Permalink
Post by Manoj Srivastava
Your argument boils down to: There is function that will never
be supported by free software.
This is an incorrect assumption too, there are several pieces of free
firmware already:

Motorola DSP56001 (assembler for it is ITPed in #502508)

prism54 wireless, the FreeMAC firmware (still in progress upstream)

CHDK, firmware for some kinds of digital cameras

rockbox, firmware for some kinds of digital music players
--
bye,
pabs

http://wiki.debian.org/PaulWise
Manoj Srivastava
2008-10-25 15:34:43 UTC
Permalink
Post by Paul Wise
Post by Manoj Srivastava
Your argument boils down to: There is function that will never
be supported by free software.
This is an incorrect assumption too, there are several pieces of free
Oh, for gawds sake. Free formeware are not in discussion since
they can remain in main. non-free blobs are in dicussion in this
context. Pedantic nit picking detracts from the discussion, and serves
as little more than a red herring (if that)

manoj
--
"Your attitude determines your attitude." Zig Ziglar, self-improvement
doofus
Manoj Srivastava <***@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Jeff Carr
2008-10-27 03:17:13 UTC
Permalink
Post by Manoj Srivastava
Your argument boils down to: There is function that will never
be supported by free software. Annoying people by asking them to expose
their function by freeing the software just irritates them, so we
should just suck it up and accept it.
I don't think I'm explaining this well, as it seems you are still not
getting it: there isn't any source code to get.
Post by Manoj Srivastava
Guess how we cater to people who need non-free software for
some functionality they must have? We put it into a place called the
non-free archive.
Great; totally useless raw data the chips on the machine need so we
can write free device drivers to talk to them. Excellent. So the plan
is: "Debian is only for hardware manufacturers that embed the firmware
in flash. If you hide your non-free stuff, that'd be great because
then we could pretend it doesn't really exist. Please don't disrupt
our perfect version of how the world works."
Post by Manoj Srivastava
You do not have to be a "firmware engineer" to grok that.
I guess I'll find out. I think this proposal is just trying to pretend
that there isn't firmware in the machines now. How does it help the
free software movement if we try to ignore the non-free firmware
booting our machines now? Why are we trying to shuffle that under the
rug?
Post by Manoj Srivastava
ps: back in the day, before I became a quantum mechanic, I toyed around
with seeing if designing microprocessors was for me. I did design a 27
instructions, 4 bit microprocessor with microcode, so I get what
firmware is.
It depends,

I'm talking about the synthesized image of the microprocessor (for the
xlinux, altera, etc). I'm not talking about if you emulated it on
solaris to check your processor (CS courses often do processor
projects of that sort). I'm also not talking uboot/coreboot like
firmware or psos-like things (also firmware but they _do_ have source
code).

If you did synthesize it, you might not have even "seen" it if you put
it on a cpld. Then you might have just thought you were "programming"
the chip. No; you were just writing it to flash. Thus bypassing the
dilemma. If you build a product and don't want to pay to have the
extra chip onboard (common on cheap low end parts) then you have to
load it via software. Thus the firmware blob. And yes, for the 50th
time: THERE IS NOT SOURCE CODE. There can not be source code, it
didn't start as source code. You can't "compile" it because there
isn't a compiler. It's not instructions for a microprocessor -- in
your case -- it is the microprocessor itself. That's right, lets say
that again, the firmware blob is your 4 bit microprocessor.

So this whole free 4 bit microprocessor you just made, you can publish
the source and everything (see also: openrisc & opensparc). But, to
run it, you have to give people a firmware blob so they can run it.
Perhaps you can't even make an installer for it because you can't
initialize the chip in the installer because you can't put the fimware
you need in the installer. So you can only support hardware where you
can flash the firmware on the motherboard. Also not ideal because you
might have a version out of sync with the kernel device driver you
wrote. Great, thanks a lot freedom.

So yes, I think most people aren't going to "get" the issue unless
they may have been firmware engineers.
Ben Finney
2008-10-27 07:31:25 UTC
Permalink
Post by Jeff Carr
Post by Manoj Srivastava
Your argument boils down to: There is function that will
never be supported by free software. Annoying people by asking
them to expose their function by freeing the software just
irritates them, so we should just suck it up and accept it.
I don't think I'm explaining this well, as it seems you are still
not getting it: there isn't any source code to get.
If so, I don't get it either.

If we use the “preferred form of the work for making modifications to
it” definition of source code, what is the form that best meets that
definition?

What form of the work do the copyright holders use to make changes to
it?
Post by Jeff Carr
Post by Manoj Srivastava
Guess how we cater to people who need non-free software for
some functionality they must have? We put it into a place called
the non-free archive.
Great; totally useless raw data the chips on the machine need so we
can write free device drivers to talk to them. Excellent.
I've been continually surprised over the decades at just how much
usefulness can be found by clever people, once outsiders have free
access to the form of the work that is used for making modifications.

So much so that I'm very skeptical of anyone telling me that such
access is “totally useless”.
Post by Jeff Carr
So the plan is: "Debian is only for hardware manufacturers that
embed the firmware in flash. If you hide your non-free stuff, that'd
be great because then we could pretend it doesn't really exist.
The brightest line I've seen used for describing the threshold is:

If the vendor is able to send out a bit stream and (with or without
the owner's intervention) load that bit stream onto the
already-purchased hardware to modify its behaviour, then we just
crossed into the realm where the recipients of those bytes (the owners
of the hardware) deserve all the free-software freedoms in order to
retain ownership of their hardware.

If the bit stream is contained in hardware such that it not feasible
for the user *or* the vendor to modify, then they are both on equal
footing and it's much less important to demand free-software rights,
since the vendor doesn't have them either.
Post by Jeff Carr
I guess I'll find out. I think this proposal is just trying to
pretend that there isn't firmware in the machines now. How does it
help the free software movement if we try to ignore the non-free
firmware booting our machines now? Why are we trying to shuffle that
under the rug?
That's a different threshold, much easier to discern: Currently,
TTBOMK, Debian does not distribute firmware for booting machines. If
it did, those bit streams would fall under the Social Contract and
would need to be free to be part of Debian.

Whether it would be a good thing to promote free-software BIOS for
computers is moot, since Debian isn't a vehicle for distributing BIOS
so such BIOS doesn't automatically fall under the Social Contract.
Post by Jeff Carr
So yes, I think most people aren't going to "get" the issue unless
they may have been firmware engineers.
Thank you for continuing to discuss it; I'm genuinely interested in
testing the principles of software freedom to ensure they continue to
apply as computer designs change.
--
\ “I hope that after I die, people will say of me: ‘That guy sure |
`\ owed me a lot of money’.” —Jack Handey |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Neil Williams
2008-10-27 10:10:19 UTC
Permalink
Post by Jeff Carr
Post by Jeff Carr
Post by Manoj Srivastava
Your argument boils down to: There is function that will
never be supported by free software. Annoying people by asking
them to expose their function by freeing the software just
irritates them, so we should just suck it up and accept it.
I don't think I'm explaining this well, as it seems you are still
not getting it: there isn't any source code to get.
I just want to find out: Under what circumstances does the blob need to
be modified and who gets to do that modification?
Post by Jeff Carr
Because that's how the hardware works. If you are making a widget and
you need a fpga or hybrid chip of any sort, then you generate a binary
blob using the chip manufacturers tools.
Are these "chip manufacturer tools" physical tools/machines or software
programs? (i.e. something I need to pick up in my hands or something I
need to execute?) Is there any way that someone else can use the same or
similar tools to modify the blob (even if it is only useful to do so on
a different board / with a different chipset)?
Post by Jeff Carr
If so, I don't get it either.
If we use the “preferred form of the work for making modifications to
it” definition of source code, what is the form that best meets that
definition?
If the chip is used on a different board with different configuration,
is the blob going to need to be changed and who gets to change it? Can
Debian include software that supports porting Debian to the new board or
can the blob be used to lock Debian out? If I build a customised board
myself, is the blob / lack of blob going to prevent me running free
software on the chip/board?
Post by Jeff Carr
If the vendor is able to send out a bit stream and (with or without
the owner's intervention) load that bit stream onto the
already-purchased hardware to modify its behaviour, then we just
crossed into the realm where the recipients of those bytes (the owners
of the hardware) deserve all the free-software freedoms in order to
retain ownership of their hardware.
Sounds like a DRM type intervention.
Post by Jeff Carr
If the bit stream is contained in hardware such that it not feasible
for the user *or* the vendor to modify, then they are both on equal
footing and it's much less important to demand free-software rights,
since the vendor doesn't have them either.
Post by Jeff Carr
So yes, I think most people aren't going to "get" the issue unless
they may have been firmware engineers.
Thank you for continuing to discuss it; I'm genuinely interested in
testing the principles of software freedom to ensure they continue to
apply as computer designs change.
From an embedded perspective - so am I. I admit, I know very little
about the minutiae of hardware but I know I'm going to come up against
these problems and I want to know more about fixing them - *without*
needing to get permission from the chip manufacturers or getting their
software tools or needing expensive hardware tools.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Ben Finney
2008-10-27 10:40:24 UTC
Permalink
Post by Neil Williams
Post by Ben Finney
If the vendor is able to send out a bit stream and (with or
without the owner's intervention) load that bit stream onto the
already-purchased hardware to modify its behaviour,
That qualifier in parentheses would perhaps be better worded as
“(it's irrelevant for this distinction whether the user's
intervention is required or not)”.

In other words, I'm intending for this test to apply irrespective of
whether we're talking about a firmware loading program that the user
runs manually, or an automated phone-home update mechanism, or
anything else. The test is only whether there is an intentional
pipeline from “vendor distributes new bit stream” to “existing
device now operating with newer vendor-supplied bit stream”.
Post by Neil Williams
Post by Ben Finney
then we just crossed into the realm where the recipients of those
bytes (the owners of the hardware) deserve all the free-software
freedoms in order to retain ownership of their hardware.
Further, if that bit stream is something we're proposing to be
distributed as part of Debian, I'm saying this means that the Social
Contract promises that the bit stream will be free.
Post by Neil Williams
Sounds like a DRM type intervention.
Yes, that's one possible case, but I'm drawing a different line that
may or may not encompass DRM. I hope that's clearer with the above
expansion.
Post by Neil Williams
Post by Ben Finney
If the bit stream is contained in hardware such that it not
feasible for the user *or* the vendor to modify, then they are
both on equal footing and it's much less important to demand
free-software rights, since the vendor doesn't have them either.
--
\ “Here is a test to see if your mission on earth is finished. If |
`\ you are alive, it isn't.” —Francis Bacon |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Mark Brown
2008-10-27 12:36:03 UTC
Permalink
Post by Neil Williams
Post by Jeff Carr
Because that's how the hardware works. If you are making a widget and
you need a fpga or hybrid chip of any sort, then you generate a binary
blob using the chip manufacturers tools.
Are these "chip manufacturer tools" physical tools/machines or software
programs? (i.e. something I need to pick up in my hands or something I
need to execute?) Is there any way that someone else can use the same or
Software.
Post by Neil Williams
similar tools to modify the blob (even if it is only useful to do so on
a different board / with a different chipset)?
Ish. Someone else should be able to use the same tools (barring
development environment issues) but modern FPGAs provide encryption
mechanisms which mean that only someone posessing a security key blown
into the hardware during the manufacturing process can generate an image
that will be accepted.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
Jeff Carr
2008-10-27 19:50:17 UTC
Permalink
Post by Mark Brown
Post by Neil Williams
similar tools to modify the blob (even if it is only useful to do so on
a different board / with a different chipset)?
Ish. Someone else should be able to use the same tools (barring
development environment issues) but modern FPGAs provide encryption
mechanisms which mean that only someone posessing a security key blown
into the hardware during the manufacturing process can generate an image
that will be accepted.
What you said here doesn't make any sense. Barring development
environment issues? That's just skimming the surface of the issues.
Jeff Carr
2008-10-27 20:01:10 UTC
Permalink
Post by Neil Williams
I just want to find out: Under what circumstances does the blob need to
be modified and who gets to do that modification?
Probably only the hardware engineers.
Post by Neil Williams
Are these "chip manufacturer tools" physical tools/machines or software
programs? (i.e. something I need to pick up in my hands or something I
need to execute?)
kind of. Modern machines are designed on older machines using software
of some sort or another.
Post by Neil Williams
Is there any way that someone else can use the same or
similar tools to modify the blob (even if it is only useful to do so on
a different board / with a different chipset)?
no, not usually unless you are the one that designed the board.
Post by Neil Williams
If the chip is used on a different board with different configuration,
then you would generate your own firmware blob
Post by Neil Williams
is the blob going to need to be changed and who gets to change it? Can
you as the board designer
Post by Neil Williams
Debian include software that supports porting Debian to the new board or
thats where you write a gpl kernel driver
Post by Neil Williams
can the blob be used to lock Debian out? If I build a customised board
myself, is the blob / lack of blob going to prevent me running free
software on the chip/board?
yes, if you don't load the blob into the chip, the chip stays
un-initialized. Thats what /lib/firmware is for.

You can put the blob on a flash chip in hardware to avoid software
needing to load it, but on cheap devices, the manufacturers are
usually trying to save on the cost of another chip.
Post by Neil Williams
Sounds like a DRM type intervention.
no, that's something totally different. This firmware blob just tells
the chip what it's wires do (electriclly/logically)
Post by Neil Williams
From an embedded perspective - so am I. I admit, I know very little
about the minutiae of hardware but I know I'm going to come up against
these problems and I want to know more about fixing them - *without*
needing to get permission from the chip manufacturers or getting their
software tools or needing expensive hardware tools.
If you what to change how the chip works outside of the device you
purchased you wouldn't be purchasing that device. For instance, you
aren't going to be able to take a usb/ethernet device and turn it into
a usb/sata device even if the chip was capable of it -- you'd have to
change the board layout so changing the firmware blob there doesn't
make any sense.

In any case, all of this is theoretical; it's just doesn't make any
sense to change the manufacturer firmware blob. If you want to do that
and are smart and experienced enough, you would start your own company
building hardware devices and compete with whatever device it is that
isn't doing what you need it to do. That would be much easier than
trying to change a chip/board you don't have schematics for.
Ben Hutchings
2008-10-29 00:28:41 UTC
Permalink
On Mon, 2008-10-27 at 13:01 -0700, Jeff Carr wrote:
[...]
Post by Jeff Carr
In any case, all of this is theoretical; it's just doesn't make any
sense to change the manufacturer firmware blob.
[...]

It can do. Firmware has bugs, and many hardware manufacturers have an
unfortunate habit of abandoning firmware after the product is no longer
shipping. Sure, the most serious bugs get fixed before release, but
other bugs may only appear in conjunction with other hardware or may
turn out to be serious in some case that wasn't tested.

Just as a demonstration:
$ git grep -i '\bfirmware\b.*\bbug\b' drivers | wc -l
27

Ben.
Michelle Konzack
2008-10-29 21:11:27 UTC
Permalink
Post by Neil Williams
Post by Jeff Carr
Because that's how the hardware works. If you are making a widget and
you need a fpga or hybrid chip of any sort, then you generate a binary
blob using the chip manufacturers tools.
Are these "chip manufacturer tools" physical tools/machines or software
programs? (i.e. something I need to pick up in my hands or something I
need to execute?) Is there any way that someone else can use the same or
similar tools to modify the blob (even if it is only useful to do so on
a different board / with a different chipset)?
Some of those tools are under NDA an as I have already mentioned in a
E-Mail for some seconds, they create mostly an IMAGE which then will be
loaded into the Microcontroles SRAM.

Such SRAM, which in my case of a 8051 compatibel controller, can be 16,
32, 64 or 128 kByte...

Now you can claim, you can use SDCC (Small Device C Compiler; is Debian
Package) to build the firmware, but manufactureres are saving money by
using the smalles memory model available and of course, the manufacturer
build tools are building highly optimizd binaries...

IF I wan to use SDCC for my projects, I have to increase the SRAM by the
factor 3, which mean, instead using 32 kByte I have to use 128 kByte.

Which increase the price for the microcontroller from 4 US$ to 9 US$.
Post by Neil Williams
If the chip is used on a different board with different configuration,
is the blob going to need to be changed and who gets to change it? Can
Imagine an ATMEL AT91SAM7S with bigger SRAM but without FLASH...

And even if I use this chip on 100 different products the firmware would
be different on each product.
Post by Neil Williams
Debian include software that supports porting Debian to the new board or
can the blob be used to lock Debian out? If I build a customised board
myself, is the blob / lack of blob going to prevent me running free
software on the chip/board?
Most Hardware would simlpy NOT run before uploading the Firmware...

It does not mather, WHICH Operating System: Linux, BSD, MacOS, Windows...
All do need a loader to run the hardware...
Post by Neil Williams
From an embedded perspective - so am I. I admit, I know very little
about the minutiae of hardware but I know I'm going to come up against
these problems and I want to know more about fixing them - *without*
needing to get permission from the chip manufacturers or getting their
software tools or needing expensive hardware tools.
Unfortunately, the optimized binaries produced by GCC and in my case
SDCC cost money in form of Hardware...

My Development suite (runing on Windows XP) cost arround 8500 US$ but
using SDCC would cost me at least 3 million Euro more in production
which my customers have to pay...

I am not realy sure, 50.000 customers would accept hardware which cost
45 US$ instead of 40 US$ because there are 2-3 OSS frickler which want
access to the source because they want to fix something.

Do you would give the FIXES back to the manufacturer?

IF the hardware is working under Linux, BSD, MacOS, Windows and others,
are you realy willing to give the changes back even the other users are
using Windows?

I know a hardware manufacturer which gaved the sourcecode away under GPL
and it is IN the Debian distribution, but its OSS frickler upstream has
never gaved the changes back to the manufacturer so others can benefit
from it...

I strongly do not agree with this practice...

Note: The OSS firmware IS NOT compatibel with Windows and does
not add any additional functionalyty except it is open!

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
Andrei Popescu
2008-10-30 07:25:01 UTC
Permalink
Post by Michelle Konzack
I am not realy sure, 50.000 customers would accept hardware which cost
45 US$ instead of 40 US$ because there are 2-3 OSS frickler which want
access to the source because they want to fix something.
Do you would give the FIXES back to the manufacturer?
I thought that was the nice thing about GPL. If you want to distribute
your changes the receiver has to get the source too ;)
Post by Michelle Konzack
IF the hardware is working under Linux, BSD, MacOS, Windows and others,
are you realy willing to give the changes back even the other users are
using Windows?
I know a hardware manufacturer which gaved the sourcecode away under GPL
and it is IN the Debian distribution, but its OSS frickler upstream has
never gaved the changes back to the manufacturer so others can benefit
from it...
The manufacturer can get it with a copy of Debian if he wants to ;)
Post by Michelle Konzack
Note: The OSS firmware IS NOT compatibel with Windows and does
not add any additional functionalyty except it is open!
And why is this NOT important?

Regards,
Andrei
--
If you can't explain it simply, you don't understand it well enough.
(Albert Einstein)
Jeff Carr
2008-10-27 20:10:47 UTC
Permalink
If we use the "preferred form of the work for making modifications to
it" definition of source code, what is the form that best meets that
definition?
What form of the work do the copyright holders use to make changes to
it?
Usually it's whatever the chip manufacturer provides.
Ben Finney
2008-10-28 01:41:31 UTC
Permalink
Post by Jeff Carr
If we use the "preferred form of the work for making modifications
to it" definition of source code, what is the form that best meets
that definition?
What form of the work do the copyright holders use to make changes
to it?
Usually it's whatever the chip manufacturer provides.
That doesn't seem to address my question. Here, “the copyright
holders” means the copyright holders in the work under question; i.e.
the work whose freedom is being discussed: the bundle of bits that get
redistributed with the driver for loading onto the hardware.

Whoever the copyright holder of that work is (I read your remark above
to mean that the hardware manufacturer is that copyright holder),
there must be a “preferred form of the work for making modifications
to it”. What form is that? *Someone* must have it, in order to make
modifications that become new releases of the work to run on the same
hardware.
--
\ “The future always arrives too fast, and in the wrong order.” |
`\ —Alvin Toffler |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Jeff Carr
2008-10-28 03:30:38 UTC
Permalink
Post by Ben Finney
Whoever the copyright holder of that work is (I read your remark above
to mean that the hardware manufacturer is that copyright holder),
there must be a "preferred form of the work for making modifications
to it". What form is that? *Someone* must have it, in order to make
modifications that become new releases of the work to run on the same
hardware.
I guess it's really hard to explain because there is a massive gap; I
can't teach you to be an electrical engineer or logician here :) I
think if you had the time to go through and synthesize "firmware
blobs" for some chips then you would see why this doesn't make sense.
It would also expose you to the tools that the hardware and logic
engineers use to do this process. It would also expose you to the
pre-requisite knowledge of the board design (layout, etc) that you
have to have. Then I think it would make sense to you why this
conversation doesn't make sense right now. It's that these "binary
only blobs" only make sense to the chip. It's like they are a map of
how the transistors are to function -- an oversimplification -- but
generally that's the nature of it. *

For example, lets say you have a pci device. If you don't load the
firmware blob, the pins will just remain in an uninitialized state.
That is; the chip default. Programming in the firmware blob will tell
the chip how to work as a pci bus. Now you are good to go. It's now
possible to write a pci device & there are registers, etc. As a
hardware engineer I can give you all the registers and an API and even
some sample GPL code so you can write a device driver. Now, some
people are smucks like nvidia and they don't give out diddly. Still,
the firmware blob that you load into the chip isn't x86 code for the
host -- it's raw junk for the chip. It's a totally different issue
than distributing a binary only nvidia driver. That's not what I'm
talking about here. I'm only trying to explain there are binary only
firmware blobs for most chips, you have them for most of the chips on
your motherboard and in many cases, there is no human readable form.
Even the chip manufacturers don't know what they are. It's totally
machine generated chip garbage as far as they are concerned. Once you
have the chip initialized then you can hook it up to an oscilloscope
to debug it (or maybe you're lucky and you can already talk to it from
your device driver).

* http://en.wikipedia.org/wiki/Floorplan_(microelectronics)
* http://en.wikipedia.org/wiki/Logic_synthesis
* http://en.wikipedia.org/wiki/Place_and_route
Thadeu Lima de Souza Cascardo
2008-10-28 04:45:31 UTC
Permalink
Post by Jeff Carr
I guess it's really hard to explain because there is a massive gap; I
can't teach you to be an electrical engineer or logician here :) I
You are assuming there is gap when there may be not.
Post by Jeff Carr
think if you had the time to go through and synthesize "firmware
blobs" for some chips then you would see why this doesn't make sense.
It would also expose you to the tools that the hardware and logic
engineers use to do this process. It would also expose you to the
Would those be tools like a Verilog or VHDL synthetizer distributed by a
FPGA manufacturer? Considering the hardware is FPGA, of course. In the
case it is not, I assume there would still be procedures like logic
design, routing, etc.
Post by Jeff Carr
pre-requisite knowledge of the board design (layout, etc) that you
have to have. Then I think it would make sense to you why this
conversation doesn't make sense right now. It's that these "binary
only blobs" only make sense to the chip. It's like they are a map of
So, why do they only make sense to the chip? Is it because there is no
current implementation of a software simulator? And why would a software
simulator not be feasible? The binary blobs would make sense to the
simulator.
Post by Jeff Carr
how the transistors are to function -- an oversimplification -- but
generally that's the nature of it. *
For example, lets say you have a pci device. If you don't load the
firmware blob, the pins will just remain in an uninitialized state.
That is; the chip default. Programming in the firmware blob will tell
the chip how to work as a pci bus. Now you are good to go. It's now
possible to write a pci device & there are registers, etc. As a
hardware engineer I can give you all the registers and an API and even
some sample GPL code so you can write a device driver. Now, some
people are smucks like nvidia and they don't give out diddly. Still,
the firmware blob that you load into the chip isn't x86 code for the
host -- it's raw junk for the chip. It's a totally different issue
If it's not clear by now, people are not arguing that hardware should
not be used if it is not free hardware (either it is feasible or not to
distribute or exist source code). The matter is whether source for code
that will not execute in the main CPU is needed for those codes in the
main section. So, your point that it is not x86 code is moot in the case
"firmware" is considered to be the same as other software in Debian. If
source code isn't available or "possible" for the chip carries the same
requirements for DFSG as the case would be for the x86 code, in the case
"firmware" should still follow DFSG.
Post by Jeff Carr
than distributing a binary only nvidia driver. That's not what I'm
talking about here. I'm only trying to explain there are binary only
firmware blobs for most chips, you have them for most of the chips on
your motherboard and in many cases, there is no human readable form.
Even machine readable form would still be considered source if its
interpretation by the machine could be presented to someone to make
modifications to it. If it is not modifiable for some reason and every
design should be done from scratch, perhaps there is a problem with the
tools and/or processes used.
Post by Jeff Carr
Even the chip manufacturers don't know what they are. It's totally
machine generated chip garbage as far as they are concerned. Once you
Which machines do generate this "garbage"? Do they do it all by
themselves? Are there machines designing new hardware now without human
intervention? Or are those chips magically enhanced so they could make
some sense of any random bitstream and there is no real mistery in
generating this "garbage"?

If the manufacturers are unaware of it, I doubt the designer is unaware
of it.
Post by Jeff Carr
have the chip initialized then you can hook it up to an oscilloscope
to debug it (or maybe you're lucky and you can already talk to it from
your device driver).
* http://en.wikipedia.org/wiki/Floorplan_(microelectronics)
* http://en.wikipedia.org/wiki/Logic_synthesis
* http://en.wikipedia.org/wiki/Place_and_route
--
Regards,
Cascardo.
Michelle Konzack
2008-10-29 21:33:27 UTC
Permalink
Post by Thadeu Lima de Souza Cascardo
If it's not clear by now, people are not arguing that hardware should
not be used if it is not free hardware (either it is feasible or not to
distribute or exist source code). The matter is whether source for code
that will not execute in the main CPU is needed for those codes in the
main section. So, your point that it is not x86 code is moot in the case
"firmware" is considered to be the same as other software in Debian. If
source code isn't available or "possible" for the chip carries the same
requirements for DFSG as the case would be for the x86 code, in the case
"firmware" should still follow DFSG.
Anw what do you do with sourcode, for which there is not even a compiler
availlable under Linux/BSD? And you HAV to buy a 8000 US$ development
suit from the chip manufacturer to build the firmware?

I have such software and EVEN me can not read the firmware.

I have ONLY a "project" in my IDE and it produce the firmware.

And now you!
Post by Thadeu Lima de Souza Cascardo
Even machine readable form would still be considered source if its
interpretation by the machine could be presented to someone to make
modifications to it. If it is not modifiable for some reason and every
design should be done from scratch, perhaps there is a problem with the
tools and/or processes used.
Do you have already tried to modify a binary blob or simply opened a (no
mather which) binary from /bin/ in a HEX editor and tried to modify it?
Post by Thadeu Lima de Souza Cascardo
Post by Jeff Carr
Even the chip manufacturers don't know what they are. It's totally
machine generated chip garbage as far as they are concerned. Once you
Which machines do generate this "garbage"? Do they do it all by
themselves? Are there machines designing new hardware now without human
intervention? Or are those chips magically enhanced so they could make
some sense of any random bitstream and there is no real mistery in
generating this "garbage"?
The software/IDE use "projects" which are not in human readable form...
...and if you have finisched, you klick the button "Output firmware"
and then you have the firmware blob.
Post by Thadeu Lima de Souza Cascardo
If the manufacturers are unaware of it, I doubt the designer is unaware
of it.
???

It seems you have never designed Hardware or realy coded software for it

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
Robert Collins
2008-10-30 01:55:08 UTC
Permalink
Post by Michelle Konzack
Anw what do you do with sourcode, for which there is not even a compiler
availlable under Linux/BSD? And you HAV to buy a 8000 US$
development
suit from the chip manufacturer to build the firmware?
Free software is an iterative process; we started with nothing, using
proprietary C compilers, kernel, libc - everything. And we iterated, and
iterated - now we have a free stack including BIOS, and are continuing
to push freedom deeper down the stack.

I feel for you that you are on the cutting edge, where you cannot do
what you need to do without spending 8K US to buy a proprietary tool.
Post by Michelle Konzack
I have such software and EVEN me can not read the firmware.
I have ONLY a "project" in my IDE and it produce the firmware.
Well, your IDE is software, it can read the input settings to generate
the firmware. So its part of the tool chain to build the firmware.
Whatever data the IDE edits as you change settings, thats the source for
the firmware. (You may be combining other binary blobs when you compile
the firmware, but thats the nature of this part of the industry, as I
understand it).

And yes, people can fry their *own hardware* if they mess up the
firmware. So what - I started with monitors you could completely fry if
you put the wrong X11 config settings into it, which is vastly easier to
do than rebuilding a firmware:).

None of this changes the fundamental aspects though:
- The output firmware is not the preferred form for modification (it is
the output, not the alterable portion of the input).
- The output firmware *may* need to be replaced if there is an issue
found after the hardware ships. (Its not a write-once event to create
firmware).

This clearly means that we cannot ship it in main or contrib under the
social contract.

(I found http://en.wikipedia.org/wiki/Open_source_hardware and
http://en.wikipedia.org/wiki/Semiconductor_intellectual_property_core
useful reading, as I'm not personally coding down at this level).

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
Thadeu Lima de Souza Cascardo
2008-10-30 11:27:39 UTC
Permalink
Post by Michelle Konzack
Post by Thadeu Lima de Souza Cascardo
If it's not clear by now, people are not arguing that hardware should
not be used if it is not free hardware (either it is feasible or not to
distribute or exist source code). The matter is whether source for code
that will not execute in the main CPU is needed for those codes in the
main section. So, your point that it is not x86 code is moot in the case
"firmware" is considered to be the same as other software in Debian. If
source code isn't available or "possible" for the chip carries the same
requirements for DFSG as the case would be for the x86 code, in the case
"firmware" should still follow DFSG.
Anw what do you do with sourcode, for which there is not even a compiler
availlable under Linux/BSD? And you HAV to buy a 8000 US$ development
suit from the chip manufacturer to build the firmware?
If the source code is not "human-readable", but it is free/libre, I
would study it in the case I consider the chance there is a bug.
Perhaps, if it was of my interest, I would even study the possibility of
reverse-engineering it, so it could be more "human-readable" and provide
tools to "build" it.
Post by Michelle Konzack
I have such software and EVEN me can not read the firmware.
I have ONLY a "project" in my IDE and it produce the firmware.
And now you!
I consider that a problem with the tool you use. It has a major defect
("by design"): it is not free/libre. So you cannot modify your IDE to
give you any more "human-readable" format or something else.
Post by Michelle Konzack
Post by Thadeu Lima de Souza Cascardo
Even machine readable form would still be considered source if its
interpretation by the machine could be presented to someone to make
modifications to it. If it is not modifiable for some reason and every
design should be done from scratch, perhaps there is a problem with the
tools and/or processes used.
Do you have already tried to modify a binary blob or simply opened a (no
mather which) binary from /bin/ in a HEX editor and tried to modify it?
In my /bin/ directory? If I had to really modify it, why would I use a
hex-editor if I have source code in C?

However, I have programmed a microcontroller using a text editor and
hexadecimal numbers, even had to recode some constants present in code
because I had to add a single instruction in the middle of it. Until I
stopped being too lazy to code a simple assembler.
Post by Michelle Konzack
Post by Thadeu Lima de Souza Cascardo
Post by Jeff Carr
Even the chip manufacturers don't know what they are. It's totally
machine generated chip garbage as far as they are concerned. Once you
Which machines do generate this "garbage"? Do they do it all by
themselves? Are there machines designing new hardware now without human
intervention? Or are those chips magically enhanced so they could make
some sense of any random bitstream and there is no real mistery in
generating this "garbage"?
The software/IDE use "projects" which are not in human readable form...
...and if you have finisched, you klick the button "Output firmware"
and then you have the firmware blob.
Again, this is a issue with your IDE. It could certainly be modified to
output some more "human-readable" format that represents its internal
representation of the "project"... if only it were free/libre.
Post by Michelle Konzack
Post by Thadeu Lima de Souza Cascardo
If the manufacturers are unaware of it, I doubt the designer is unaware
of it.
???
It seems you have never designed Hardware or realy coded software for it
Does writing a microprocessor in Verilog count as designing hardware?
Post by Michelle Konzack
Thanks, Greetings and nice Day/Evening
Michelle Konzack
Anyway, this is about the DFSG and the requirement of distributing
source code. I would really like that the requirement for distributing
the needed tools to build and modify this source code was in DFSG too.
Unfortunately, they are not. Fortunately, many packages that
Build-Depends on packages on non-free are in contrib. I hope that will
be the case too for any "firmware".

So, it doesn't matter if the preferred form of modification (by the way,
do you open on your IDE your output "firmware" or your "project"?) is
"human-readable" or not. It is, in anyway, required by DFSG. If it is
the same as the "binary" distributed, the other DSFG requirementes still
apply.

Regards,
Cascardo.
Ben Finney
2008-10-28 05:38:41 UTC
Permalink
Post by Jeff Carr
Post by Ben Finney
Whoever the copyright holder of that work is (I read your remark
above to mean that the hardware manufacturer is that copyright
holder), there must be a "preferred form of the work for making
modifications to it". What form is that? *Someone* must have it,
in order to make modifications that become new releases of the
work to run on the same hardware.
I guess it's really hard to explain because there is a massive gap;
I can't teach you to be an electrical engineer or logician here :) I
think if you had the time to go through and synthesize "firmware
blobs" for some chips then you would see why this doesn't make
sense.
Nevertheless I really appreciate the effort you're taking to explain
this. Not just for myself either:

If bunches of bits are to be redistributed in Debian, that needs to be
done in a manner compatible with the explicit promises of the Social
Contract, regardless of whether those who package those bits for
redistribution are themselves trained electrical engineers.

So, it's important for the freedom issues to be understood by we mere
mortals who don't deal with logic boards; and that involves bridging
gaps in understanding, without requiring all of us learning everything
about each others's field :-)
Post by Jeff Carr
It's that these "binary only blobs" only make sense to the chip.
I'm not disputing that. The reason these programmatic bit streams are
an issue is that if they're to be redistributed by Debian, the
recipient needs to have the guarantees of freedom as per the Social
Contract. So, it is irrelevant (for the purpose of satisfying the
contract of freedom) which particular hardware they are intended to be
loaded into, be it a CPU or a daughterboard processor.
Post by Jeff Carr
For example, lets say you have a pci device. If you don't load the
firmware blob, the pins will just remain in an uninitialized state.
That is; the chip default. Programming in the firmware blob will
tell the chip how to work as a pci bus. Now you are good to go. It's
now possible to write a pci device & there are registers, etc.
So, it sounds like we're talking about exactly the same freedom
issues, just with a different processor involved: the PCI board's
processor instead of the motherboard's CPU.
Post by Jeff Carr
Still, the firmware blob that you load into the chip isn't x86 code
for the host -- it's raw junk for the chip.
That “raw junk” is, if I understand you correctly, instructions and
data for controlling the behaviour of the processor on the PCI chip.

How is this different from saying that the machine-code form of a
program is “raw junk for the motherboard's CPU”?

I get the impression you're saying it's different in some way other
than which processor the bit stream is destined for, but I'm trying
without success to see what difference exists that eliminates the
right of the recipient to have freedom in that work.
Post by Jeff Carr
It's a totally different issue than distributing a binary only
nvidia driver. That's not what I'm talking about here.
Understood; I'm fairly sure the distinction between which processor
these bits are intended for is clear to readers of this thread.

What I don't see is a justification for denying the right of freedom
in that bit stream for the recipient of the Debian operating system
where these bits are redistributed.

Note that “only a tiny fraction of the recipients could ever make
practical use of the source form of the work” is no justification for
denying any recipient the freedom to get that source form; we don't
accept that argument for processor code destined for a motherboard
CPU, after all.
Post by Jeff Carr
I'm only trying to explain there are binary only firmware blobs for
most chips, you have them for most of the chips on your motherboard
and in many cases, there is no human readable form. Even the chip
manufacturers don't know what they are. It's totally machine
generated chip garbage as far as they are concerned.
What, then, does the chip manufacturer — who, if I understand you
correctly, is the copyright holder and vendor of the firmware — have
as the means of generating *new* processor firmware targeted to the
*same*, already-sold, hardware?

I would argue that that form of the work meets the definition of
“source code for the firmware”. Yes?
--
\ “The best mind-altering drug is truth.” —Jane Wagner, via Lily |
`\ Tomlin |
_o__) |
Ben Finney
Tristan Seligmann
2008-10-28 07:33:07 UTC
Permalink
Post by Jeff Carr
Still, the firmware blob that you load into the chip isn't x86 code
for the host -- it's raw junk for the chip.
That “raw junk” is, if I understand you correctly, instructions and
data for controlling the behaviour of the processor on the PCI chip.
How is this different from saying that the machine-code form of a
program is “raw junk for the motherboard's CPU”?
What Jeff seems to be saying is that the tools the hardware
manufacturers use to modify the firmware work with it in that binary
form, as opposed to most software which is compiled into "machine-code
form" from separate human-readable source code. This would appear to be
akin to editing a raster image in an image editor while keeping it in
JPEG form, as opposed to using either a more complex format supporting
layers etc., or a vector graphics format.
What, then, does the chip manufacturer — who, if I understand you
correctly, is the copyright holder and vendor of the firmware — have
as the means of generating *new* processor firmware targeted to the
*same*, already-sold, hardware?
I would argue that that form of the work meets the definition of
“source code for the firmware”. Yes?
Again, assuming I'm not misspeaking, that form of the work is already
what we have.
--
mithrandi, i Ainil en-Balandor, a faer Ambar
Michelle Konzack
2008-10-29 21:40:03 UTC
Permalink
Post by Tristan Seligmann
Again, assuming I'm not misspeaking, that form of the work is already
what we have.
ACK ;-)

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
Thadeu Lima de Souza Cascardo
2008-10-30 11:30:06 UTC
Permalink
Post by Michelle Konzack
Post by Tristan Seligmann
Again, assuming I'm not misspeaking, that form of the work is already
what we have.
ACK ;-)
Thanks, Greetings and nice Day/Evening
Michelle Konzack
In which cases? Which of the firmwares? How can you be sure?

Regards,
Cascardo.
Ben Hutchings
2008-10-29 00:39:40 UTC
Permalink
On Mon, 2008-10-27 at 20:30 -0700, Jeff Carr wrote:
[...]
Post by Jeff Carr
For example, lets say you have a pci device. If you don't load the
firmware blob, the pins will just remain in an uninitialized state.
That is; the chip default. Programming in the firmware blob will tell
the chip how to work as a pci bus.
[...]

How exactly do you propose to load the firmware, if not through a JTAG
port? Back in the world of production hardware which Debian runs on,
ASICs tend to have power-on-reset logic built-in...

Ben.
Michelle Konzack
2008-10-29 21:42:56 UTC
Permalink
Post by Ben Hutchings
How exactly do you propose to load the firmware, if not through a JTAG
port? Back in the world of production hardware which Debian runs on,
ASICs tend to have power-on-reset logic built-in...
Most PCI hardware has a very small bootloader which checks some signals
on the PCI bus... I have a book about it but no time to read in since
it is very complicated...

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
Ben Hutchings
2008-10-30 10:22:39 UTC
Permalink
Post by Michelle Konzack
Post by Ben Hutchings
How exactly do you propose to load the firmware, if not through a JTAG
port? Back in the world of production hardware which Debian runs on,
ASICs tend to have power-on-reset logic built-in...
Most PCI hardware has a very small bootloader which checks some signals
on the PCI bus... I have a book about it but no time to read in since
it is very complicated...
PCI (Express) hardware has to be able to initialise at least the bus
interface and PCI config space at power-on reset. That includes board-
specific information like subsystem IDs.

The network controllers I work with can initialise their config
registers either from built-in ROM or from external EEPROM or flash,
selected by strap pins. Production boards always initialise from flash;
thankfully no-one expects to be able to remove flash from NICs as they
need to provide PXE boot code to the host.

Ben.
--
Ben Hutchings
It is a miracle that curiosity survives formal education. - Albert Einstein
Michelle Konzack
2008-10-29 21:20:51 UTC
Permalink
Post by Jeff Carr
Usually it's whatever the chip manufacturer provides.
;-)
That doesn't seem to address my question. Here, ???the copyright
holders??? means the copyright holders in the work under question; i.e.
the work whose freedom is being discussed: the bundle of bits that get
redistributed with the driver for loading onto the hardware.
Whoever the copyright holder of that work is (I read your remark above
to mean that the hardware manufacturer is that copyright holder),
there must be a ???preferred form of the work for making modifications
to it???. What form is that? *Someone* must have it, in order to make
modifications that become new releases of the work to run on the same
hardware.
I use a 8000 US$ software under Windows XP to build highly optimized
(very small) firmware and there is nothing like a C source code.

The project IS a binary blob which then can directly uploaded into the
device.

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
Michelle Konzack
2008-10-29 20:47:00 UTC
Permalink
Hello Ben and *,
Post by Ben Finney
If so, I don't get it either.
If we use the ???preferred form of the work for making modifications to
it??? definition of source code, what is the form that best meets that
definition?
What form of the work do the copyright holders use to make changes to
it?
There are SDKs called "Builder" where you will have NEVER source code,
even as Developer, since the "Builder" create an IMAGE which will be
uploaded into the the SRAM of a Microcontroller (I have some 8051
compatibles) and then after uploading it is executed...

The Microcontroller cost arround 4 US$ but if I user the same WITH
integrated FLASH memory, it cost arround 9-12 US$.

So, the prefered form of distributing is a 16/32/64/128/256 kByte IMAGE.

Currently I am developing a Hardware where I need such thing and now
puzzeling arround whether to use a firmware loader (GNU GPL version 3.0,
already coded and packed for the Debian distribution) or use the same
Microcontroller WITH FLASH which then is arround 5 US$ more expensive
and if the final Hardware cost arround 40 US$ (without VAT) in Low-Cost.

I do not know, whether my customers accepet 5 US$ more.

However, my Firmware Loader must be there anyway for upgrades...

The question is, what do you want with the Sourcecode?

Reprogramming? A singel error in the parameters will cook your computer
hardware and HOW do you want to recode something or add functionality?

I have choosen the smallest Microcontroller required to save money...

Yes, I can reploaye a MC with 16 kByte SRAM with one which has 256 kByte
and then OSS frickler can add stuff, but this would make the controller
over 10 times more expensive...

Please think about it.
Post by Ben Finney
I've been continually surprised over the decades at just how much
usefulness can be found by clever people, once outsiders have free
access to the form of the work that is used for making modifications.
I have the hell striping down the firmware of my hardware to fit into
32 kByte and you are talking about modifications to it...

I am sure, my enterprise is not the only one wondering about such
requirement to let users modify firmware of sensibel hardware which CAN
destuct the whole computer since they have to leafe out some stuff to
get it into the small memories...
Post by Ben Finney
So much so that I'm very skeptical of anyone telling me that such
access is ???totally useless???.
It is useless because I am building a hardware which take me several
month to develop plus coding testing the software in a secured
environement where hardware can not be destucted...

The lifetime of such hardware would be maybe 3-5 years and now, you can
explain me, HOW you would develop/recode the firmware, if you have NOT
the requirement environement, risking damages to the hardware and more.

You do not know the internals of my hardware and have to guess things.
Without the hardware developer tools you can not even DEBUG the Hardware
while loading YOUR hacked firmware. Even if my hardware has a JTAG
connector...
Post by Ben Finney
Post by Jeff Carr
So the plan is: "Debian is only for hardware manufacturers that
embed the firmware in flash. If you hide your non-free stuff, that'd
^^^^^^^^^^^^^^^^^
Which would make hardware much more expensive

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
Thomas Bushnell BSG
2008-10-30 05:52:52 UTC
Permalink
Post by Michelle Konzack
There are SDKs called "Builder" where you will have NEVER source code,
even as Developer, since the "Builder" create an IMAGE which will be
uploaded into the the SRAM of a Microcontroller (I have some 8051
compatibles) and then after uploading it is executed...
So suppose you have this IMAGE and you discover it has a problem; how do
you modify it to fix the problem? I'm assuming you load it into
"Builder", and then "Builder" can display for you something sensible and
comprehensible, better than simply editing bits, right? More details
would be helpful here.thout VAT) in Low-Cost.
Post by Michelle Konzack
I do not know, whether my customers accepet 5 US$ more.
However, my Firmware Loader must be there anyway for upgrades...
The question is, what do you want with the Sourcecode?
Your English is a little confusing for me, so I'm not sure what this
question is asking.

If you mean, what is the source code which Debian promises to make
available to its users, it's generally understood to be the preferred
form of the program for making modifications to it.

If you mean, why does Debian want the source code, there can be many
reasons. One is to learn about the program; how it works, how other
programs doing similar tasks could be built, and so forth. Another is
to deal with the day when you are gone and people still have the
hardware and wish to make it do something you never thought of. But
regardless, Debian has promised that Debian is only free software.
Post by Michelle Konzack
Reprogramming? A singel error in the parameters will cook your computer
hardware and HOW do you want to recode something or add functionality?
I have choosen the smallest Microcontroller required to save money...
Yes, I can reploaye a MC with 16 kByte SRAM with one which has 256 kByte
and then OSS frickler can add stuff, but this would make the controller
over 10 times more expensive...
Please think about it.
About what? Debian has no objection to the use of loadable firmware.
But notice that part of the reason you would save money with the
loadable firmware is that you can ask Debian to undertake the cost of
distributing it for you (and thus saving you the cost of the SRAM, which
is the way you would distribute it yourself). Debian will distribute
it, but in order for it to be a part of Debian itself, it needs to be
free software. There is no reason your interest in making the hardware
affordable can't go along with that at the same time: just provide the
source.
Post by Michelle Konzack
I have the hell striping down the firmware of my hardware to fit into
32 kByte and you are talking about modifications to it...
I am sure, my enterprise is not the only one wondering about such
requirement to let users modify firmware of sensibel hardware which CAN
destuct the whole computer since they have to leafe out some stuff to
get it into the small memories...
How is this a reason not to provide source code?
Post by Michelle Konzack
It is useless because I am building a hardware which take me several
month to develop plus coding testing the software in a secured
environement where hardware can not be destucted...
The lifetime of such hardware would be maybe 3-5 years and now, you can
explain me, HOW you would develop/recode the firmware, if you have NOT
the requirement environement, risking damages to the hardware and more.
You do not know the internals of my hardware and have to guess things.
Without the hardware developer tools you can not even DEBUG the Hardware
while loading YOUR hacked firmware. Even if my hardware has a JTAG
connector...
I don't understand why this matters to you. Provide the source code;
Debian ships it, and nobody is hurt. If nobody ever makes use of it,
how has it harmed you?

Thomas
William Pitcock
2008-10-30 06:48:27 UTC
Permalink
But regardless, Debian has promised that Debian is only free software.
Then why does Debian have non-free? Is that not part of Debian?

Does this mean that non-free should move to a third-party repo like
certain other repos out there containing controversial things?

If non-free is meant to be an opt-in part of Debian, then put the
distributable firmware there and be done with it.

William
Thomas Weber
2008-10-30 07:17:06 UTC
Permalink
Post by William Pitcock
But regardless, Debian has promised that Debian is only free software.
Then why does Debian have non-free? Is that not part of Debian?
"Thus, although non-free works are not a part of Debian, ..."
Social contract, paragraph 5.
Post by William Pitcock
If non-free is meant to be an opt-in part of Debian, then put the
distributable firmware there and be done with it.
You know, quite a big part of the discussion is about whether this is
a) feasible at all
b) feasible so short before a release

Thomas
Simon Josefsson
2008-10-30 11:22:24 UTC
Permalink
Post by William Pitcock
But regardless, Debian has promised that Debian is only free software.
Then why does Debian have non-free? Is that not part of Debian?
One way to resolve this dilemma is to realize that 'Debian' can refer to
two things: the project and the distribution.

Debian the operating system is free software since non-free/contrib is
not part of Debian (== main).

Debian the project is not (strictly) a free software project since it
contains and supports the non-free part.

Thus, a reasonable position for a free software supporter may be to
support the Debian operating system but not support the Debian project.

/Simon
Thomas Bushnell BSG
2008-10-30 17:47:06 UTC
Permalink
Post by William Pitcock
But regardless, Debian has promised that Debian is only free software.
Then why does Debian have non-free? Is that not part of Debian?
No, it's not part of Debian. Non-free is distributed by Debian, but it
does not form a part of the Debian system.
Post by William Pitcock
If non-free is meant to be an opt-in part of Debian, then put the
distributable firmware there and be done with it.
Of course, what I would be happy to see is the firmware moved to the
non-free respository. That's exactly what we're talking about.

Thomas
Michelle Konzack
2008-10-30 16:34:44 UTC
Permalink
Post by Thomas Bushnell BSG
Post by Michelle Konzack
I am sure, my enterprise is not the only one wondering about such
requirement to let users modify firmware of sensibel hardware which CAN
destuct the whole computer since they have to leafe out some stuff to
get it into the small memories...
How is this a reason not to provide source code?
Manufacturerers can be sued...

You get the hell if you for example modify the firmware uf a GSM modem
and you disturb the GSM communication...

It is NOT the Software distributor, but the Hardware Manufacturer which
run into touble. I must certify my Hardware to be used in GSM networks.

The if you modify the Firmware of my "24V DC Modular ATX PSU" which is
connectedt to 24V Batteries and a SolarCharger and now you change the
Reference vomtage from 24V (Gel batteries) to 25,9V (Li-Poly batteries),

You can burn your computer and after this, there is NO preuv, it was my
Firmware or your modified one.

So now as a Manufacturer I have the choice between

1) Use a huge NV/FLASH/EEPROM Memory which make the Hardware maybe
10-20 Euro more expensive and I will lost customers.

2) Use huge external SRAM (makes the Hardware expensive too) to let
users load there own non tested and non-optimised blob and become
sued if something goes wrong.

So, the Open-Source System does not realy work on Hardware...
Post by Thomas Bushnell BSG
I don't understand why this matters to you. Provide the source code;
Debian ships it, and nobody is hurt. If nobody ever makes use of it,
how has it harmed you?
The sourcecode is the blob. I can reload it into my Develoment suit and
edit it, but thats all. This SDKs use highly optimized builders/compilr
and there is NO OpenSource solution for it. Increasing FLASH/SRAM only
because someone maybe want to burn its hardware or damage others is
braindamaged since they are NO waraties something will work correctly...

The problem is, IF someone (e.g. Hobby frickler) do something wrong, I
can be f...ed.

I do not know HOW OpenMoko do this, but the certification for GSM
software/firmware IS expensive and it IS required by law.

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
Giacomo A. Catenazzi
2008-10-30 16:49:40 UTC
Permalink
Post by Michelle Konzack
Post by Thomas Bushnell BSG
Post by Michelle Konzack
I am sure, my enterprise is not the only one wondering about such
requirement to let users modify firmware of sensibel hardware which CAN
destuct the whole computer since they have to leafe out some stuff to
get it into the small memories...
How is this a reason not to provide source code?
Manufacturerers can be sued...
You get the hell if you for example modify the firmware uf a GSM modem
and you disturb the GSM communication...
But most of the firmwares are outside wireless communication.

How many manufacturers was sued because users burn the monitors
(it was very easy) or other hardwares (e.g. try with hdparam) ?

How many non conforming GSM devices are sold? How many of such devices
are recalled by manufactures?

ciao
cate
Michelle Konzack
2008-10-30 17:11:31 UTC
Permalink
Post by Giacomo A. Catenazzi
But most of the firmwares are outside wireless communication.
Right, but they are some like the one from me.
Post by Giacomo A. Catenazzi
How many manufacturers was sued because users burn the monitors
(it was very easy) or other hardwares (e.g. try with hdparam) ?
Do you think, someone (manufacturers) is making it public?
Post by Giacomo A. Catenazzi
How many non conforming GSM devices are sold? How many of such devices
are recalled by manufactures?
You can not even sell GSM devices, if your software is not certified.
The recalls are very very low... because they are tested

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
Michael Casadevall
2008-10-30 17:23:14 UTC
Permalink
I'll add my two cents.

I have some experience with radios. The FCC requires all radios to be
certified before they can be sold, and there is a requirement that you
must not make a device that is easily modifiable to operate outside
the limits put forth by the FCC. In this case, it would be illegal to
release the firmware's source code since it would violate the FCC
rules, violate and void the radio's certification (and this also
applies to Wifi/Bluetooth devices).

I do agree firmwares fall under the DFSG and the social contract, and
they should be split out, but included on the CD/DVDs so I can at
least enable full hardware support out of the box.
Michael

On Thu, Oct 30, 2008 at 1:11 PM, Michelle Konzack
Post by Michelle Konzack
Post by Giacomo A. Catenazzi
But most of the firmwares are outside wireless communication.
Right, but they are some like the one from me.
Post by Giacomo A. Catenazzi
How many manufacturers was sued because users burn the monitors
(it was very easy) or other hardwares (e.g. try with hdparam) ?
Do you think, someone (manufacturers) is making it public?
Post by Giacomo A. Catenazzi
How many non conforming GSM devices are sold? How many of such devices
are recalled by manufactures?
You can not even sell GSM devices, if your software is not certified.
The recalls are very very low... because they are tested
Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
Thomas Bushnell BSG
2008-10-30 18:05:33 UTC
Permalink
Post by Michael Casadevall
I have some experience with radios. The FCC requires all radios to be
certified before they can be sold, and there is a requirement that you
must not make a device that is easily modifiable to operate outside
the limits put forth by the FCC. In this case, it would be illegal to
release the firmware's source code since it would violate the FCC
rules, violate and void the radio's certification (and this also
applies to Wifi/Bluetooth devices).
The mere fact that the firmware can be loadable--with or without source
code--means that it can be easily modified. The ease of modification is
not about the obfuscation of the blob, but about the mere fact that it
can be loaded.

Thomas

Thomas Bushnell BSG
2008-10-30 18:03:03 UTC
Permalink
Post by Michelle Konzack
So now as a Manufacturer I have the choice between
1) Use a huge NV/FLASH/EEPROM Memory which make the Hardware maybe
10-20 Euro more expensive and I will lost customers.
2) Use huge external SRAM (makes the Hardware expensive too) to let
users load there own non tested and non-optimised blob and become
sued if something goes wrong.
Um, no. See, what you don't seem to understand is that users can load
their own non-tested and non-optimized blob whether you release source
or not. In fact, by not releasing source, you *increase* the risk that
users' modifications will damage the hardware.

The point here is that loadable firmware exposes you to a risk. The
refusal to provide source has nothing to do with whether the risk is
exposed; but providing source would *reduce* it.
Post by Michelle Konzack
So, the Open-Source System does not realy work on Hardware...
Of course, we're not talking about Hardware, we're talking about
firmware, which is, of course, a kind of software.
Post by Michelle Konzack
I do not know HOW OpenMoko do this, but the certification for GSM
software/firmware IS expensive and it IS required by law.
If I understand correctly, then you (and perhaps many others), are not
being honest in attaining GSM certification. You seem to be saying that
the certification is contigent upon it being impossible for the user to
change the behavior of the device in a non-compliant way. But the mere
fact that you are using loadable firmware means that the user can make
such a change. It has nothing to do with the license for the firmware,
or whether there is source, or even whether your or Debian or anyone
else distribute the firmware. The device, in fact, *cannot* be
guaranteed to meet the certification, because it provides the capacity
for users to load non-compliant firmware.

Now whether that's a serious problem or not, I don't know, but it is
entirely distinct from the license terms on the firmware blob.

Thomas
Ben Hutchings
2008-10-29 00:18:04 UTC
Permalink
On Sun, 2008-10-26 at 20:17 -0700, Jeff Carr wrote:
[...]
Post by Jeff Carr
If you did synthesize it, you might not have even "seen" it if you put
it on a cpld. Then you might have just thought you were "programming"
the chip.
You have to synthesise *from* something, be that Verilog or VHDL or
Handel-C.
Post by Jeff Carr
No; you were just writing it to flash. Thus bypassing the
dilemma. If you build a product and don't want to pay to have the
extra chip onboard (common on cheap low end parts) then you have to
load it via software. Thus the firmware blob. And yes, for the 50th
time: THERE IS NOT SOURCE CODE. There can not be source code, it
didn't start as source code. You can't "compile" it because there
isn't a compiler. It's not instructions for a microprocessor -- in
your case -- it is the microprocessor itself. That's right, lets say
that again, the firmware blob is your 4 bit microprocessor.
Sure, it's not a program in the usual sense, but there is a source for
it.
Post by Jeff Carr
So this whole free 4 bit microprocessor you just made, you can publish
the source and everything (see also: openrisc & opensparc). But, to
run it, you have to give people a firmware blob so they can run it.
If people want microprocessors then they buy ASICs, which are much
cheaper, faster, and power-efficient. So far as I can see, the major
use for open hardware designs is as modules ("IP") in larger designs
which will later be synthesised into ASICs. The people using them will
need the source; they already have the synthesis tools.

There aren't a whole lot of mass-produced devices using CPLDs or FPGAs
either, as that doesn't usually make economic sense.
Post by Jeff Carr
Perhaps you can't even make an installer for it because you can't
initialize the chip in the installer because you can't put the fimware
you need in the installer.
I believe we can distribute firmware binaries in main if we can also
distribute their sources. We might need to make an exception to the
policy that we build all binaries using tools in main.
Post by Jeff Carr
So you can only support hardware where you
can flash the firmware on the motherboard. Also not ideal because you
might have a version out of sync with the kernel device driver you
wrote. Great, thanks a lot freedom.
So yes, I think most people aren't going to "get" the issue unless
they may have been firmware engineers.
IANAFE, though I probably will be soon.

Ben.
Frank Küster
2008-10-25 16:21:11 UTC
Permalink
Post by Jeff Carr
There is hardware, for which to function, will always, for the
lifetime of the equipment, require a firmware blob to operate. This
will always be the case; there will never be a human readable version.
It will never be possible to compile it (with non-free compilers) from
source code.
How can that be? (That is an ernest question)

The engineers will have some description of what the firmware should do
(in terms of what to read and write from which register etc., not only
in terms of "initialize communication"), and some rules how to translate
these procedures into a binary blob.

I doubt the translation needs to be done by hand, instead of by a
compiler, but even if it was, wouldn't the software be useful? And
couldn't the "description of what the firmware should do" be treated as
the source, then?

I mean, your argument seems to be "there is no such thing as source for
firmware, so we cannot possibly require it". But isn't that description
of the function just the source?

Regards, Frank
--
Frank Küster
Debian Developer (TeXLive)
ADFC Miltenberg
B90/Grüne KV Miltenberg
Jeff Carr
2008-10-27 01:38:53 UTC
Permalink
Post by Frank Küster
How can that be? (That is an ernest question)
Because that's how the hardware works. If you are making a widget and
you need a fpga or hybrid chip of any sort, then you generate a binary
blob using the chip manufacturers tools.

So, no matter how good you intend on being, how much you love free
software, you don't have any choice. Again, this is ironic since
things like the opencores project are the most free hardware of all
and are n
Lennart Sorensen
2008-10-27 18:35:58 UTC
Permalink
Post by Jeff Carr
Because that's how the hardware works. If you are making a widget and
you need a fpga or hybrid chip of any sort, then you generate a binary
blob using the chip manufacturers tools.
But you provide input to the tool, usually VHDL code or similar. That
would be the source, and you can provide that. That is the prefered
format for editing. We use plenty of FPGAs at work, and I have seen how
they are programmed, and yes I have seen what the source looks like. It
is certainly human readable source code. If you think otherwise, then
you don't know how FPGAs and CPLDs work.

The tool doesn't have a magic buttong labeled 'make the chip do what I
am thinking of now".
Post by Jeff Carr
So, no matter how good you intend on being, how much you love free
software, you don't have any choice. Again, this is ironic since
things like the opencores project are the most free hardware of all
and are not given credit for it in this thread.
And opencores.org distributes source, not binary blobs. Gee whiz.
--
Len Sorensen
Jeff Carr
2008-10-27 19:26:31 UTC
Permalink
On Mon, Oct 27, 2008 at 11:35, Lennart Sorensen
Post by Lennart Sorensen
Post by Jeff Carr
Because that's how the hardware works. If you are making a widget and
you need a fpga or hybrid chip of any sort, then you generate a binary
blob using the chip manufacturers tools.
But you provide input to the tool, usually VHDL code or similar. That
would be the source, and you can provide that. That is the prefered
format for editing. We use plenty of FPGAs at work, and I have seen how
they are programmed, and yes I have seen what the source looks like. It
is certainly human readable source code. If you think otherwise, then
you don't know how FPGAs and CPLDs work.
True, I certainly feel like that at times with the opencores project
I've been trying to maintain.

On the other hand, I sure know that I know a pile more than you do or
we wouldn't be having this discussion :)
Post by Lennart Sorensen
The tool doesn't have a magic buttong labeled 'make the chip do what I
am thinking of now".
Post by Jeff Carr
So, no matter how good you intend on being, how much you love free
software, you don't have any choice. Again, this is ironic since
things like the opencores project are the most free hardware of all
and are not given credit for it in this thread.
And opencores.org distributes source, not binary blobs. Gee whiz.
Yes Gee whiz. You're not getting it. The firmware is a binary blob.
You can distribute the source but you can't synthesize it. So, in the
debian installer, you can't include it according to this insane
policy.

But the opencore case is the easy case, hybrid chips don't even have
source. The firmware blob is often generated when you fabricate the
chip & changes with the physical board layout. You guys just don't
understand the issues here. There isn't some nafarious intent; you
have little flash chips holding these bits all over in your machine
now. You just don't know it. And now, because someone is giving you
the luxury of actually loading them via software (with gpl software no
less) you seem to be all ticked off. You seem to want to stick your
head in the sand and pretend this doesn't exist.

And no, it's not about telling users "This is all free". That's a lie
at this level anyway. None of it is free. Whether you load it from
/lib/firmware/ or if it's already stored on your motherboard doesn't
change anything. It just makes us Debian look ridiculous. The message
should be: "There are some firmware blobs for some hardware that there
is no known way to generate code for, nor any way to compile such code
if we had it or any way to figure out how we would write a compiler
for it either. This firmware is also hidden in flash for most of the
chips on your machine. Some modern devices let the OS load this code
into the chip then we are able to write fully GPL drivers for the
device. Debian's focus is on free software; not free hardware designs
(although we love those too).
Felipe Sateler
2008-10-27 20:01:50 UTC
Permalink
Post by Jeff Carr
But the opencore case is the easy case, hybrid chips don't even have
source. The firmware blob is often generated when you fabricate the
chip & changes with the physical board layout. You guys just don't
understand the issues here.
Please explain what the issues are, then. The firmware blob has to be generated
*somehow*. There is a tool that generates the blob. Which data does the tool
need to generate it?
--
Felipe Sateler
Michelle Konzack
2008-10-29 21:58:12 UTC
Permalink
Post by Felipe Sateler
Post by Jeff Carr
But the opencore case is the easy case, hybrid chips don't even have
source. The firmware blob is often generated when you fabricate the
chip & changes with the physical board layout. You guys just don't
understand the issues here.
Please explain what the issues are, then. The firmware blob has to be generated
*somehow*. There is a tool that generates the blob. Which data does the tool
need to generate it?
The IDE/Software which produce the firmware blobs mostly generate it
directly and the projects the developers are using are binary stuff.

Parts of it maybe human readable but not suffisant to compile it or do
anything usefull with it.

And as I have already written, SDCC compiled code is 3 times bigger as
the firmeware blob generated by a 8000 US$ IDE.

And using a Microcontroller/ASIC with bigger memory is no solution since
sometimes it would be very costly...

In my case arround 3 million Euro more for the final production (18mio).

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
Thadeu Lima de Souza Cascardo
2008-10-30 11:35:32 UTC
Permalink
Post by Michelle Konzack
Post by Felipe Sateler
Post by Jeff Carr
But the opencore case is the easy case, hybrid chips don't even have
source. The firmware blob is often generated when you fabricate the
chip & changes with the physical board layout. You guys just don't
understand the issues here.
Please explain what the issues are, then. The firmware blob has to be generated
*somehow*. There is a tool that generates the blob. Which data does the tool
need to generate it?
The IDE/Software which produce the firmware blobs mostly generate it
directly and the projects the developers are using are binary stuff.
And what do you type in this software to produce this "project"? This
"project" would be source code, anyway. Even if we did not have the
tools to produce the same "firmware" from this.
Post by Michelle Konzack
Parts of it maybe human readable but not suffisant to compile it or do
anything usefull with it.
And as I have already written, SDCC compiled code is 3 times bigger as
the firmeware blob generated by a 8000 US$ IDE.
And do you write C code in your IDE? What else does this IDE provide you
to help you optimize your C code? If it's not C code, what is it? And it
would be very hard to compare C-code with hand-written assembly.
Post by Michelle Konzack
And using a Microcontroller/ASIC with bigger memory is no solution since
sometimes it would be very costly...
In my case arround 3 million Euro more for the final production (18mio).
A good solution would be to improve the free/libre software available in
Debian, since you seem to claim that SDCC is an option as a development
tool to this said micro-controller. Is it a 8051?
Post by Michelle Konzack
Thanks, Greetings and nice Day/Evening
Michelle Konzack
Loïc Minier
2008-10-28 08:46:21 UTC
Permalink
Post by Jeff Carr
have little flash chips holding these bits all over in your machine
now. You just don't know it. And now, because someone is giving you
the luxury of actually loading them via software (with gpl software no
less) you seem to be all ticked off.
Right; I share your concerns with the new burden Debian is attaching to
itself when requiring the loadable firmwares to be free.

I fear it's not an easy task to delimit which (sub-)system we require
to be free though. I'd love it if someone could come up with some sane
wording for it.

At the same time, I'd love our DFSG to reject software which is written
with unavailable documentation and unmaintainable without it.


I see it much in the same way as when I'm interfacing thanks to a
protocol with some remote servers: Google might be running proprietary
software on its servers, but because we're exchanging HTTP/HTML we can
interface with each other.
Concerning hardware (with firmware builtin or firmware to preload), I
care that I can ask the hardware to do stuff I care about.
In the same way I can't fix bugs on the Google server, I can't fix
bugs in firmware running on the hardware of my machines.

Naturally, I'd love firmware to be freed up, or to only interface with
servers running free code which I could inspect or replace if needs be.
But this is a huge project, different from building an OS. OpenMoko
does a good job at building a free hardware + software stack, but it
still has the GSM stack closed; I find this perfectly acceptable
because they interface over a serial port interface with it. There are
other projects to free graphics, or for x86 based hardware.


How do others feel about this? Is there any contamination of the
firmwares when shipped in a free OS which is not possible to prevent?
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Ben Finney
2008-10-28 11:51:55 UTC
Permalink
Post by Loïc Minier
Post by Jeff Carr
have little flash chips holding these bits all over in your
machine now. You just don't know it. And now, because someone is
giving you the luxury of actually loading them via software (with
gpl software no less) you seem to be all ticked off.
Right; I share your concerns with the new burden Debian is
attaching to itself when requiring the loadable firmwares to be
free.
The requirement for the contents of Debian to be free is not a new
burden. It's spelled out in the Social Contract; the founders and
drafters of that document are clear that the intention was always for
all of Debian to be free, not just some parts of Debian.

What's relatively new is the realisation that some of those parts
(such as firmware) have a programmatic function but can, in some
cases, have *no* better form for making modifications than the binary
blob itself.

At least, that's my understanding of some of the use cases presented
here: that even the vendors of those blobs routinely modify the binary
blob directly to generate a new version of it, much like
bit-manipulating a machine-code executable and running it.

As strange as it may seem to my mind used to the roomy expanses and
flexibility to be found in a motherboard CPU, it may be an optimal way
to work when the processor in question barely has room in its program
memory or instruction set for the functional blob, and no extra room
for even embedded diagnostic tools, let alone debuggers or symbol
tables. I don't know that to be the case, but I'm not going to reject
the possibility only because it's difficult for me personally to
imagine.
Post by Loïc Minier
I fear it's not an easy task to delimit which (sub-)system we
require to be free though. I'd love it if someone could come up
with some sane wording for it.
I think the Social Contract makes it fairly clear that all of the
Debian operating system is promised to be free. I don't see a
compelling reason to allow breaches of that promise to be rationalised
away by differences in functional classification of the works.
Post by Loïc Minier
How do others feel about this? Is there any contamination of the
firmwares when shipped in a free OS which is not possible to
prevent?
My opinion is that recipients of Debian should have unfettered access
to exercise the freedoms of running/performance, inspection,
modification, and redistribution of the entirety of Debian, using
nothing but operating system tools that are similarly unfettered and
hardware that's commonly used for such activities.

That means: free access to exactly the same form of the work that the
vendor might use to make modification to any part of the operating
system, be it the language instructions and APIs that gets rendered to
a machine code program, or the full-layered vector document that gets
rendered to a PNG file, or the reStructuredText document and style
sheets that get rendered to a PDF file, or the firmware blob that gets
manipulated as-is. Whatever the vendor can do to the work in order to
inspect, modify, and redistribute it, a Debian recipient equipped with
suitable generic hardware can expect to have free reign to do the
same.

It's clear that not every recipient of Debian will have access to the
hardware nor expertise necessary to develop useful modifications to a
GPU-targetted instruction blob, just as not everyone has a digital
camera for capturing high-resolution photographic data. But every
Debian recipient can certainly expect to be free to redistribute
Debian to someone arbitrary party (who is not necessarily the vendor)
who *does* have such hardware and expertise, and for that party to be
free to apply requested modifications and redistribute the work back
to them, *without* anyone in that chain needing extra permissions and
*without* access to any specific extra data, vendor-specific programs,
or other non-free software.

If the above isn't the case for any part of Debian, I consider that a
breach of the Social Contract, to be considered a serious bug and
fixed appropriately by ceasing redistribution of that work in Debian
until it's fixed, and (ideally) fixing it so the work can again be
included in Debian.
--
\ “An expert is a man who has made all the mistakes which can be |
`\ made in a very narrow field.” —Niels Bohr |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Thadeu Lima de Souza Cascardo
2008-10-28 12:09:34 UTC
Permalink
On Tue, Oct 28, 2008 at 10:51:55PM +1100, Ben Finney wrote:
[...]
Post by Ben Finney
*without* access to any specific extra data, vendor-specific programs,
or other non-free software.
I agree here, although, I wouldn't say the DFSG requires that source
code should be modifiable with software distributed in Debian. But it
would certainly be an improvement, mainly in the presence of bitstreams
which are the corresponding source code themselves and are only modified
using vendor-specific tools, which may not be available as free/libre
software.

[...]
Post by Ben Finney
Ben Finney
Cascardo.
Neil Williams
2008-10-28 12:33:31 UTC
Permalink
Post by Ben Finney
What's relatively new is the realisation that some of those parts
(such as firmware) have a programmatic function but can, in some
cases, have *no* better form for making modifications than the binary
blob itself.
OK, to my eyes, this means that if the relevant providers of such
firmware can give such an assurance and that this is added to
debian/copyright, the bugs reported against these items of firmware can
be closed as fixed. I see no problem with that.

Now, whether such packages should include some hints or links to docs
that explain the kind of tools that are required to do that manipulation
(software and physical tools), I think we can leave to minor or wishlist
bugs, manpages and README.Debian.gz. That isn't RC.
Post by Ben Finney
As strange as it may seem to my mind used to the roomy expanses and
flexibility to be found in a motherboard CPU, it may be an optimal way
to work when the processor in question barely has room in its program
memory or instruction set for the functional blob, and no extra room
for even embedded diagnostic tools, let alone debuggers or symbol
tables. I don't know that to be the case, but I'm not going to reject
the possibility only because it's difficult for me personally to
imagine.
At last, some sanity in this thread.

I have only the most limited exposure to hardware design / modification
but I can see that sometimes you do simply need to avoid uninitialised
data by using a binary blob that sets a sane value, amongst other tasks.
The mere fact that this is done by directly prodding the chip/pins with
a lump of binary code rather than by using gcc is inconsequential.

It leaves a question of just when such a method is still deemed
reasonable and whether the size of the blob (or the apparent complexity
of the blob) should be taken into account when assessing the validity of
a claim in debian/copyright. Nevertheless, the mere presence of a binary
blob is not a breach of the DFSG, IMHO.
Post by Ben Finney
My opinion is that recipients of Debian should have unfettered access
to exercise the freedoms of running/performance, inspection,
modification, and redistribution of the entirety of Debian, using
nothing but operating system tools that are similarly unfettered and
hardware that's commonly used for such activities.
(and that such hardware does not have to exist within the confines of
the hardware within or available to be plugged into a normal PC but may
include any hardware commonly used for the activity, including tools
that would be familiar to anyone commonly undertaking such activities.)
Post by Ben Finney
That means: free access to exactly the same form of the work that the
vendor might use to make modification to any part of the operating
system, be it the language instructions and APIs that gets rendered to
a machine code program, or the full-layered vector document that gets
rendered to a PNG file, or the reStructuredText document and style
sheets that get rendered to a PDF file, or the firmware blob that gets
manipulated as-is. Whatever the vendor can do to the work in order to
inspect, modify, and redistribute it, a Debian recipient equipped with
suitable generic hardware can expect to have free reign to do the
same.
It's clear that not every recipient of Debian will have access to the
hardware nor expertise necessary to develop useful modifications to a
GPU-targetted instruction blob, just as not everyone has a digital
camera for capturing high-resolution photographic data. But every
Debian recipient can certainly expect to be free to redistribute
Debian to someone arbitrary party (who is not necessarily the vendor)
who *does* have such hardware and expertise, and for that party to be
free to apply requested modifications and redistribute the work back
to them, *without* anyone in that chain needing extra permissions and
*without* access to any specific extra data, vendor-specific programs,
or other non-free software.
If the above isn't the case for any part of Debian, I consider that a
breach of the Social Contract, to be considered a serious bug and
fixed appropriately by ceasing redistribution of that work in Debian
until it's fixed, and (ideally) fixing it so the work can again be
included in Debian.
Equally, if the above *is* the case and debian/copyright can include a
declaration to that effect, then IMHO the DFSG is satisfied and the bug
needs to be closed as fixed.

In the end, it comes down to "the preferred form for modification" and
the reality that the preferred form *can* include binary code, machine
code or any other data of a type that may well be generated in many
other cases but is actually manipulated directly in this specific case.

Can we agree on this and get back to releasing Lenny?

(please?)
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Ben Finney
2008-10-28 13:42:54 UTC
Permalink
Post by Neil Williams
In the end, it comes down to "the preferred form for modification"
I am convinced that's the most useful place to draw the line, yes.
Post by Neil Williams
and the reality that the preferred form *can* include binary code,
machine code or any other data of a type that may well be generated
in many other cases but is actually manipulated directly in this
specific case.
I acknowledge it as a possibility (and my huge thanks to those who
have patiently explained this possibility). The existence of that
possibility doesn't significantly detract from the possibility that a
given firmware blob is *not*, in fact, the preferred form for making
modifications to it.

So I think that raises the important issue of what assurance is needed
to trust that we *are* redistributing the preferred form for making
modifications in any specific instance; and, while that issue is not
unique to programmatic blobs (c.f. raster graphic image data, for
another example of the same issue), it appears to me that the risk of
redistributing a non-source form (and thus unwittingly failing to meet
our Social Contract) is greater with programmatic binary blobs.

What assurance would those who are likely to have the inclination and
means to modify a processor's firmware, as distributed in Debian,
going to require to be satisfied that they have the preferred form of
the specific work for making modifications to it?
Post by Neil Williams
Can we agree on this and get back to releasing Lenny?
(please?)
I wasn't aware that work on releasing Lenny was halted while we
discuss this.

As for agreement, the existence of more possibilities in this matter
only appears to increase the burden of evidence. What application does
this have on the current firmware blobs in Debian? How do we determine
whether those specific blobs definitely are or definitely are not
being redistributed without the preferred form of the work for making
modifications?
--
\ “I like to fill my bathtub up with water, then turn the shower |
`\ on and pretend I'm in a submarine that's been hit.” —Steven |
_o__) Wright |
Ben Finney
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Simon Richter
2008-10-28 15:38:44 UTC
Permalink
Hi,
Post by Ben Finney
At least, that's my understanding of some of the use cases presented
here: that even the vendors of those blobs routinely modify the binary
blob directly to generate a new version of it, much like
bit-manipulating a machine-code executable and running it.
No, it's more a case of there not being any free compiler available that
could produce a working blob.

A lot of new USB hardware uses an off-the-shelf controller, one of the most
popular ones is the FX2, which has an 8 bit CPU with banked memory. gcc's
"state machine" approach to compiling is pretty much lost on this hardware.
Almost the same thing goes for FPGAs, which need to be optimized for the
specific chip (a lot of FPGAs have dedicated circuitry around the
programmable area for e.g. FIFOs or buffers, and compilers need to be able
to utilize those).

We do have compilers for these systems, but they will not generate code
that can fit into the actual hardware.

The commercial compilers that can handle this are not free software.
Post by Ben Finney
My opinion is that recipients of Debian should have unfettered access
to exercise the freedoms of running/performance, inspection,
modification, and redistribution of the entirety of Debian, using
nothing but operating system tools that are similarly unfettered and
hardware that's commonly used for such activities.
We cannot provide that even with the consent, however unlikely, of hardware
manufacturers, simply because their tools are not free software, so at the
current time lobbying for free firmware is a pretty pointless effort.

The only thing that will give us free firmware is actually writing it, and
writing the tools to compile it; the thing we need from hardware vendors
has not changed: documentation for the interfaces from the programmable to
the hardwired bits.

Simon
Paul Hardy
2008-10-29 22:20:33 UTC
Permalink
Post by Simon Richter
Hi,
Post by Ben Finney
At least, that's my understanding of some of the use cases presented
here: that even the vendors of those blobs routinely modify the binary
blob directly to generate a new version of it, much like
bit-manipulating a machine-code executable and running it.
No, it's more a case of there not being any free compiler available that
could produce a working blob.
(snip)
Almost the same thing goes for FPGAs, which need to be optimized for the
specific chip.
(snip)
We do have compilers for these systems, but they will not generate code
that can fit into the actual hardware.
The commercial compilers that can handle this are not free software.
Post by Ben Finney
My opinion is that recipients of Debian should have unfettered access
to exercise the freedoms of running/performance, inspection,
modification, and redistribution of the entirety of Debian, using
nothing but operating system tools that are similarly unfettered and
hardware that's commonly used for such activities.
We cannot provide that even with the consent, however unlikely, of hardware
manufacturers, simply because their tools are not free software, so at the
current time lobbying for free firmware is a pretty pointless effort.
The only thing that will give us free firmware is actually writing it, and
writing the tools to compile it; the thing we need from hardware vendors
has not changed: documentation for the interfaces from the programmable to
the hardwired bits.
Simon
I'm not a DD and didn't want to jump into the middle of what had been
a heated discussion, but I've done a bunch of hardware work and I've
realized reading related discussions over the past week that many DD's
might not be familiar with some of the lower-level complexities.
Simon mentioned that free compilers aren't available for many devices.
Of course the next logical question is: why not create a free
compiler? It isn't that easy (and in some cases impossible because at
least Xilinx and Altera are very unlikely to cooperate, as Simon
alludes).

In the FPGA/CPLD world, Xilinx and Altera are the top vendors. VHDL
source code to run on their chips would be better than a binary blob.
As Simon mentions, although there are free tools for synthesizing VHDL
("synthesizing" is the English term usually used for "compiling"
VHDL), those tools won't produce anything that will run on Xilinx or
Altera FPGAs. You must use the manufacturers' own non-free (except
sometimes for student editions), non-open tools to synthesize your
VHDL.

The format of the final blob is something those two manufacturers
treat as proprietary. Knowing the structure of a Xilinx or Altera
binary blob would give their "Hertz vs. Avis" competitor insight into
their devices' low-level chip architecture. Without the binary blob
structure being public knowledge, you'll never see open tools to
synthesize VHDL that will actually run on these devices.

But at least if you could get the VHDL source, it would be an
improvement over just a binary blob. You'd then have something you
could maintain, albeit with non-free tools. On the flip side, this
also means that nobody can just tweak some values in a binary file for
a Xilinx or Altera device -- the VHDL source must exist somewhere.


Many non-FPGA microprocessors load programs and otherwise update
EEPROM locations using the Intel Hex File format. In this case,
source code for a program probably exists written in assembler or some
higher-level language. However, it is reasonable for a vendor to use
a raw Intel Hex File to modify a few parameter values at specific
EEPROM locations on their device once the main program is loaded. The
only other case I can think of a vendor _maybe_ writing a raw Intel
Hex File instead of at least assembly language source might be to
create a highly optimized, very tiny bootloader. But even then, they
should be able to get the smallest machine code possible using a good
assembler.

So for a tiny bootloader or to just modify some parameters stored at
fixed EEPROM addresses, it is reasonable for a vendor to only use a
binary blob (Intel Hex File or some equivalent). From the point of
view of long-term maintenance though, any sane vendor should be
maintaining anything larger than that in some type of source code
form.

FWIW, PostScript can at times be considered a proper source language.
Along the lines of "when all you have is a hammer everything looks
like a nail," since I know PostScript I've often directly written
PostScript programs to generate graphics images, calendars, etc.

"The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man." -- George Bernard Shaw


Paul Hardy
GPG Key ID: E6E6E390
Loïc Minier
2008-10-28 22:38:49 UTC
Permalink
Post by Ben Finney
The requirement for the contents of Debian to be free is not a new
burden.
What's new here is the number of firmwares which one need to make a
computer useful and the consequence on the perimeter of the Debian
project.
Post by Ben Finney
It's spelled out in the Social Contract; the founders and
drafters of that document are clear that the intention was always for
all of Debian to be free, not just some parts of Debian.
Yes, perhaps we need to delimit what this covers exactly.
Post by Ben Finney
What's relatively new is the realisation that some of those parts
(such as firmware) have a programmatic function but can, in some
cases, have *no* better form for making modifications than the binary
blob itself.
I certainly wouldn't want to argue that the binary blob is the
preferred form of modification; I don't put in question that the
firmware files are programs which have been generated by some
development process out of some type of sources and some software.

Instead, I'd much rather limit what needs to be free in Debian to what
we care to interface with: I don't care that my BIOS is closed source
to run Debian on it. I wouldn't mind having a free BIOS updated which
would include BIOS update images made of non-free software if Debian
had the rights to redistribute them and to modify the binaries in
anyway.
Post by Ben Finney
At least, that's my understanding of some of the use cases presented
here: that even the vendors of those blobs routinely modify the binary
blob directly to generate a new version of it, much like
bit-manipulating a machine-code executable and running it.
I don't believe it's the most common case for the generation of the
lib/firmware files. I think those are the result of a complex
engineering and release process, and some parts are certainly source
code. Just documentation of the hardware is something I find essential
in order to maintain the firmwares, even in binary form.
Post by Ben Finney
Post by Loïc Minier
I fear it's not an easy task to delimit which (sub-)system we
require to be free though. I'd love it if someone could come up
with some sane wording for it.
I think the Social Contract makes it fairly clear that all of the
Debian operating system is promised to be free. I don't see a
compelling reason to allow breaches of that promise to be rationalised
away by differences in functional classification of the works.
I see one in that it's likely a much harder project than building a
free OS, and I wouldn't care much: I'm not a hardware engineer. I also
find it unrealistic that all these firmware bits will be freed up. I
don't buy the "preferred form of modification is the binary" argument
either.
Post by Ben Finney
That means: free access to exactly the same form of the work that the
vendor might use to make modification to any part of the operating
system
So you consider the bits of code which runs on the hardware part of the
OS? I consider it's part of what gets on the CDs to ship, and in the
archive, but I don't see it as a runtime part of the OS; I see it as a
runtime part for hardware with which the OS interfaces.
Post by Ben Finney
It's clear that not every recipient of Debian will have access to the
hardware nor expertise necessary to develop useful modifications to a
GPU-targetted instruction blob, just as not everyone has a digital
camera for capturing high-resolution photographic data.
But changing the code which runs on the GPU is building a different
system, for GPUs. I can imagine booting my GPU straight from VBIOS to
run actual code, without booting Debian at all from the main CPU.
Other projects can work on freeing up the GPU to do more useful stuff
than what the interface the hardware (with suitable driver loaded)
offers, but why would Debian need to consider this? Graphics can be
driven by the VESA API for example; it's not very powerful, but it
works. Why not allow shipping a file which enables using a different,
but agreed upon API if we have the right to ship the file and don't
need to care about its content but just about its conformance to the
API?
Post by Ben Finney
If the above isn't the case for any part of Debian, I consider that a
breach of the Social Contract, to be considered a serious bug and
fixed appropriately by ceasing redistribution of that work in Debian
until it's fixed, and (ideally) fixing it so the work can again be
included in Debian.
I ackowledge that the current requirements of the social contract as
it's worded and intended require us to ship the source code of the
lib/firmware blobs. What I'm not sure about is why we couldn't have an
equally useful social contract to build an OS, but is worded to allow
shipping of utility binary files which enable additional hardware to
work with agreed upon APIs.
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Ben Finney
2008-10-29 00:20:55 UTC
Permalink
Post by Loïc Minier
Post by Ben Finney
That means: free access to exactly the same form of the work that
the vendor might use to make modification to any part of the
operating system
So you consider the bits of code which runs on the hardware part of
the OS? I consider it's part of what gets on the CDs to ship, and
in the archive, but I don't see it as a runtime part of the OS; I
see it as a runtime part for hardware with which the OS interfaces.
I don't consider “runtime part of the OS” to be the limit of what
needs to be free. I consider “the OS”, that is, whatever we ship and
say is Debian, no matter what transient functional classifications it
may have in any particular instance, to be the limit of what needs to
be free.

For my own part, I want *all* digital information to be free; but
that's not the mandate of the Debian project. What *is* the mandate of
the Debian project is that it produce the best free operating system.

Anything that the project produces as part of that operating system,
whether it happens at any particular moment to be interpreted as
“executable”, “documentation”, “configuration”, “data”, or some
simultaneous blend of functional classifications, must be free.
Post by Loïc Minier
Post by Ben Finney
If the above isn't the case for any part of Debian, I consider
that a breach of the Social Contract, to be considered a serious
bug and fixed appropriately by ceasing redistribution of that work
in Debian until it's fixed, and (ideally) fixing it so the work
can again be included in Debian.
I ackowledge that the current requirements of the social contract
as it's worded and intended require us to ship the source code of
the lib/firmware blobs.
Simply because anything that we ship as part of Debian must be
DFSG-free.
Post by Loïc Minier
What I'm not sure about is why we couldn't have an equally useful
social contract to build an OS, but is worded to allow shipping of
utility binary files which enable additional hardware to work with
agreed upon APIs.
That would be far less useful as a social contract because it allows a
ghetto of non-free parts to be redistributed within Debian, and make
false the core idea that “I have received a free operating system, so
I know that for *everything* in here I have certain basic freedoms”.
--
\ “Room service? Send up a larger room.” —Groucho Marx |
`\ |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Loïc Minier
2008-10-29 08:29:22 UTC
Permalink
Post by Ben Finney
Post by Loïc Minier
I ackowledge that the current requirements of the social contract
as it's worded and intended require us to ship the source code of
the lib/firmware blobs.
Simply because anything that we ship as part of Debian must be
DFSG-free.
Yes; we agree on the current constraints.
Post by Ben Finney
Post by Loïc Minier
What I'm not sure about is why we couldn't have an equally useful
social contract to build an OS, but is worded to allow shipping of
utility binary files which enable additional hardware to work with
agreed upon APIs.
That would be far less useful as a social contract because it allows a
ghetto of non-free parts to be redistributed within Debian, and make
false the core idea that “I have received a free operating system, so
I know that for *everything* in here I have certain basic freedoms”.
Of course, producing a Debian including free firmwares would be
superior than producing a Debian which ships non-free firmwares, but
the actual option at hand is producing a Debian without the firmwares.

Naturally, I can imagine some people making use of the free firmwares
would they be available in Debian, but:
- this would probably be very little people
- it would be almost impossible to get the sources for all firmwares
generally useful to run a modern computer, as well as associated
compilers and hardware documentation; the FCC regulations make this
hard for instance
- this forces an effort for hardware which requires runtime loading of
a firmware, but does not force anything for hardware which has
preloaded firmware in flash or rom; so we effectively made the
freeness cover firmware for some random hardware
- this could be achieved by a separate project while still having an
useful and free Debian OS, except for firmware files

The size and risks of the task versus it's usefulness makes me think
the ghetto will rather be Debian if we can't support common PCs.
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Ben Finney
2008-10-29 10:58:59 UTC
Permalink
Post by Loïc Minier
Of course, producing a Debian including free firmwares would be
superior than producing a Debian which ships non-free firmwares,
but the actual option at hand is producing a Debian without the
firmwares.
Since the Social Contract promises Debian *won't* ship non-free
things, that's not an option compatible with the promises made by the
Debian project.
Post by Loïc Minier
Naturally, I can imagine some people making use of the free
- this would probably be very little people
The same argument can be made for free software targeted to the
motherboard CPU. It can also be refuteded with similar
counter-arguments: for example, those few who *can* make use of free
software can improve and redistribute it, thereby benefiting many
others beside themselves. This is only possible if the work is
distributed as free software.
Post by Loïc Minier
- it would be almost impossible to get the sources for all
firmwares generally useful to run a modern computer
I only expect the Debian project to hold to its promises for
distributing Debian as free software. Any firmware not being
distributed by Debian is outside the aegis of the project.
--
\ “Probably the toughest time in anyone's life is when you have |
`\ to murder a loved one because they're the devil.” —Emo Philips |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Ben Finney
2008-10-29 12:08:53 UTC
Permalink
Post by Ben Finney
Post by Loïc Minier
Of course, producing a Debian including free firmwares would be
superior than producing a Debian which ships non-free firmwares,
but the actual option at hand is producing a Debian without the
firmwares.
Since the Social Contract promises Debian *won't* ship non-free
things, that's not an option compatible with the promises made by
the Debian project.
Poorly worded on my part. Try this:

Since the Social Contract promises Debian *won't* contain non-free
things, [shipping non-free firmware in Debian] is not an option
compatible with the promises made by the Debian project.
--
\ “I call him Governor Bush because that's the only political |
`\ office he's ever held legally.” —George Carlin, 2008 |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Loïc Minier
2008-10-29 14:15:29 UTC
Permalink
Post by Ben Finney
Since the Social Contract promises Debian *won't* ship non-free
things, that's not an option compatible with the promises made by the
Debian project.
I might not have said it clearly enough:
- I agree the current DFSG and social contract imply we need to provide
sources for these firmware if they are shipped in Debian
- in turn, this implies that I'm suggesting we might need to reword
parts of them to reduce the perimeter of Debian to something
achievable which we still love and aim for

Ah I'm certainly going to get a pile of flame-ish mails for suggesting
we might need to change the social contract of the DFSG. It remains
that the current versions imply a too large work which I think
shouldn't be Debian's.
Post by Ben Finney
Post by Loïc Minier
- this would probably be very little people
The same argument can be made for free software targeted to the
motherboard CPU. It can also be refuteded with similar
counter-arguments: for example, those few who *can* make use of free
software can improve and redistribute it, thereby benefiting many
others beside themselves. This is only possible if the work is
distributed as free software.
Yes; it just helps putting things in perspective. Just like when we
decide to remove free software from the archive. This is not an
argument that the firmwares shouldn't come with source code, it's an
argument that if we allowed firmwares to come without source code, it
wouldn't affect a lot of people. Of course it would still affect some
people. If this itch is worth scratching, another project could be
started or these people could join one of the "free hardware" projects
which are becoming more common these days.
--
Loïc Minier
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Ben Finney
2008-10-30 01:05:56 UTC
Permalink
Post by Loïc Minier
Post by Ben Finney
Since the Social Contract promises Debian *won't* ship non-free
things, that's not an option compatible with the promises made by
the Debian project.
- I agree the current DFSG and social contract imply we need to
provide sources for these firmware if they are shipped in Debian
- in turn, this implies that I'm suggesting we might need to reword
parts of them to reduce the perimeter of Debian to something
achievable which we still love and aim for
Thanks for making it clear.

I disagree completely with that suggestion. I agree with the current
promise that all of Debian (that is, the operating system in whole and
all its parts) must be free.
--
\ “Whenever you read a good book, it's like the author is right |
`\ there, in the room talking to you, which is why I don't like to |
_o__) read good books.” —Jack Handey |
Ben Finney
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Robert Collins
2008-10-30 02:14:38 UTC
Permalink
Post by Loïc Minier
Post by Ben Finney
Since the Social Contract promises Debian *won't* ship non-free
things, that's not an option compatible with the promises made by the
Debian project.
- I agree the current DFSG and social contract imply we need to provide
sources for these firmware if they are shipped in Debian
Good :).
Post by Loïc Minier
- in turn, this implies that I'm suggesting we might need to reword
parts of them to reduce the perimeter of Debian to something
achievable which we still love and aim for
I think that that would not be Debian anymore.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
Lennart Sorensen
2008-10-28 14:00:31 UTC
Permalink
Post by Jeff Carr
True, I certainly feel like that at times with the opencores project
I've been trying to maintain.
On the other hand, I sure know that I know a pile more than you do or
we wouldn't be having this discussion :)
I have a different theory.
Post by Jeff Carr
Yes Gee whiz. You're not getting it. The firmware is a binary blob.
You can distribute the source but you can't synthesize it. So, in the
debian installer, you can't include it according to this insane
policy.
You could synthesize it if you had the tools for it.

Debian's policy is not insane. It is consistent. Any hardware maker
that wants their hardware to work with free software could use an
eeprom to store the firmware within the device, so that there is nothing
non-free that has to be distributed. That is what Debian is concerned
with. If the firmware is embedded in the device, then it has nothing to
do with Debian anymore, and it is entirely up to the user whether they
care about how the hardware they buy is made. Those that do care can
simply avoid that type of hardware (or at least try to).
Post by Jeff Carr
But the opencore case is the easy case, hybrid chips don't even have
source. The firmware blob is often generated when you fabricate the
chip & changes with the physical board layout. You guys just don't
understand the issues here. There isn't some nafarious intent; you
have little flash chips holding these bits all over in your machine
now. You just don't know it. And now, because someone is giving you
the luxury of actually loading them via software (with gpl software no
less) you seem to be all ticked off. You seem to want to stick your
head in the sand and pretend this doesn't exist.
If they use flash chips, then it doesn't affect Debian, because the
flash chip already contains what is needed for the device to work.
Debian doesn't have to have anything to do with updating them, and hence
there is no distribution of non-free to worry about.
Post by Jeff Carr
And no, it's not about telling users "This is all free". That's a lie
at this level anyway. None of it is free. Whether you load it from
/lib/firmware/ or if it's already stored on your motherboard doesn't
change anything. It just makes us Debian look ridiculous. The message
should be: "There are some firmware blobs for some hardware that there
is no known way to generate code for, nor any way to compile such code
if we had it or any way to figure out how we would write a compiler
for it either. This firmware is also hidden in flash for most of the
chips on your machine. Some modern devices let the OS load this code
into the chip then we are able to write fully GPL drivers for the
device. Debian's focus is on free software; not free hardware designs
(although we love those too).
It does make a difference. Debian makes no promise about the freeness
of the users hardware since Debian did no provide it. Debian promises
that everything they provide is free. That really isn't very hard to
understand. Debian policy is only concerned with the software Debian is
distributing. If Debian didn't provide it as part of the distribution,
then Debian's policy has nothing to do with it. Hence your motherboard
and its BIOS and other firmware in flash has nothing to do with Debian's
polcies at all. If your hardware requries closed source firmware to
operate, then at best Debian can distribute that in non-free, and using
it during the install will be slightly tricky (but not that hard. I
have done so and it wasn't that big a deal. It just meant I had to
personally accept that I was about to use one piece of non-free code to
make that particular system work and it was my choice, not Debian's that
made my system contain a piece of non-free code. That is how it should
be with Debian).
--
Len Sorensen
David Weinehall
2008-10-28 17:01:45 UTC
Permalink
Post by Lennart Sorensen
Post by Jeff Carr
True, I certainly feel like that at times with the opencores project
I've been trying to maintain.
On the other hand, I sure know that I know a pile more than you do or
we wouldn't be having this discussion :)
I have a different theory.
Post by Jeff Carr
Yes Gee whiz. You're not getting it. The firmware is a binary blob.
You can distribute the source but you can't synthesize it. So, in the
debian installer, you can't include it according to this insane
policy.
You could synthesize it if you had the tools for it.
Debian's policy is not insane. It is consistent. Any hardware maker
that wants their hardware to work with free software could use an
eeprom to store the firmware within the device, so that there is nothing
non-free that has to be distributed. That is what Debian is concerned
with. If the firmware is embedded in the device, then it has nothing to
do with Debian anymore, and it is entirely up to the user whether they
care about how the hardware they buy is made. Those that do care can
simply avoid that type of hardware (or at least try to).
Please try to explain to a hardware manufacturer that free their
hardware will only work with free software if they store their firmware
on an eeprom, and they'll laugh you in the face (or possibly send you
off to an asylum). Do you really think that it's better for our users
that the firmware is impossible to replace (and thus impossible, even
for the hardware vendors, to bugfix)?

Face it, all hardware has firmware, either loadable or in EEPROM. In
most cases that firmware is closed source. In most cases they are for
custom chips that have no compilers/developer kits/whatever available in
Debian anyway, so having the source wouldn't make any difference (and in
some cases, the binary blobs *is* the source code; I've spent more than
enough time programming 8-bit directly from a machine-code monitor).

As a bonus, an increasing amount of firmware these days is
cryptographically signed (cpu microcode, for instance), which means that
even if you had the source of the firmware, and the development kit, you
would still not be able to load the firmware onto your device.

Now, I always prefer to buy hardware I can get the drivers for,
so both my laptops and my server uses Intel chipsets to and through.
The only things I don't have the sources for are:

The CPU microcode
The iwl3945 firmware

I'm 100% certain I wouldn't have any use for the CPU microcode sources,
I know this because the microcode is cryptographically signed, and thus
any modified version I could possibly produce won't be able to load on
the CPU anyway (and apart from that, I seriously doubt that there is any
means of editing it in a sane way available in Debian anyway)

As for the iwl3945 firmware, I do not know for sure whether it's written
in C, assembler, or whatever else (I'm fairly certain it's NOT in some
obscure 8-bit CPU or similar). Personally I wouldn't mind having
the source code, but I do know, that if the choice is between either
having the firmware in EEPROM or having it as a binary blob, I'd take
the binary blob anytime.

I see firmware sources as a nice bonus in cases where it's written in
a language that we can actually modify and build using Debian tools.
I don't see it as a necessity. Throwing out the firmware doesn't help
our users, it makes things worse for our users. And our users are our
number one priority.

The same could of course be argued for non-free software as well, but
the difference is that we can write replacements for the non-free
software. We don't have the option of replacing our users hardware.
The closest we can get is to petition the hardware manufacturers for
specs or source code to the firmware, but if they don't answer, or if
they say no, we have to face he fact: our users are better off with
binary only firmware in Debian. Not in non-free.

For laptops running Intel chipsets, the most common wireless chipsets are
iwl3945, iwl4965, and iwl 5000 these days. All of them requiring binary
only firmware. With Intel's recent track record of releasing
sources, it's reasonable to assume that they would have released the
sources if they saw it as possible, so hoping for a source release seems
fairly futile.

Now, imagine Debian having this hypothetical yearly conference, called,
oh, let's say DebConf. During that conference we organise a special day
for our users, let's call it Debian Day. Lots of potential new Debian
users show up with their laptops and wants to install Debian. As the
kind souls we are, we hand out credit-card CD's with netinst images that
they can use with the WiFi available at the conference.

Oh, but wait. They cannot access the WiFi, because their wireless cards
are not supported. Or rather, the drivers are available, but they all
report the same error message "Firmware not found". Happy, happy, joy,
joy. I'm sure those potential Debian users will feel really happy about
Debian's consistent policy that dictates that software running on
non-cpu == software running on cpu. They might not feel equally please
with the fact that Debian isn't consistent in its dedication to
prioritising the users though...

[snip]


Regards: David
--
/) David Weinehall <***@debian.org> /) Rime on my window (\
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/
Thadeu Lima de Souza Cascardo
2008-10-28 18:07:02 UTC
Permalink
On Tue, Oct 28, 2008 at 06:01:45PM +0100, David Weinehall wrote:
[...]
Post by David Weinehall
some cases, the binary blobs *is* the source code; I've spent more than
enough time programming 8-bit directly from a machine-code monitor).
And many people write non-modular programs; use non-usual constructs; do
not comment their code; include pre-calculated constants. Is Debian
going to remove a table of primes that were calculated and then stamped
on code in an array, because the source code for the prime number
generator was not made available? I'd rather have said source code if
it, in fact, existed at all. People may have written a one-liner in some
high-level code or did it by their hands or used some other tool already
distributed by Debian. I guess it is just not feasible to verify all
that.
Post by David Weinehall
As a bonus, an increasing amount of firmware these days is
cryptographically signed (cpu microcode, for instance), which means that
even if you had the source of the firmware, and the development kit, you
would still not be able to load the firmware onto your device.
Which the GPLv3 tries to solve, stating that if the vendor can do it
(the software distributed by the vendor in this case being under the
GPLv3 license, of course), the user must be able to do it also. Even if
that means providing the private key.
Post by David Weinehall
Now, I always prefer to buy hardware I can get the drivers for,
so both my laptops and my server uses Intel chipsets to and through.
The CPU microcode
The iwl3945 firmware
I'm 100% certain I wouldn't have any use for the CPU microcode sources,
I know this because the microcode is cryptographically signed, and thus
any modified version I could possibly produce won't be able to load on
the CPU anyway (and apart from that, I seriously doubt that there is any
means of editing it in a sane way available in Debian anyway)
Again, this is not about what your computer use, but about what Debian
distributes in its main section.
Post by David Weinehall
As for the iwl3945 firmware, I do not know for sure whether it's written
in C, assembler, or whatever else (I'm fairly certain it's NOT in some
obscure 8-bit CPU or similar). Personally I wouldn't mind having
the source code, but I do know, that if the choice is between either
having the firmware in EEPROM or having it as a binary blob, I'd take
the binary blob anytime.
Some people have claimed this does not concern Debian, but I am for the
Free Software Foundation fights, and fighting for free/libre "firmware"
and hardware is worth, in my opinion.

Anyway, Debian is about a free/libre universal operating system, and
distributing non-free/libre pieces of "firmware" Debian knows there is
unavailable better forms of modification would not be the perfect way of
doing that.
Post by David Weinehall
I see firmware sources as a nice bonus in cases where it's written in
a language that we can actually modify and build using Debian tools.
I don't see it as a necessity. Throwing out the firmware doesn't help
our users, it makes things worse for our users. And our users are our
number one priority.
Is it not providing them the best free/libre operating system?
Post by David Weinehall
The same could of course be argued for non-free software as well, but
the difference is that we can write replacements for the non-free
software. We don't have the option of replacing our users hardware.
And why can't we write replacements for non-free/libre "firmware"? Is it
because you don't consider reverse-engineering network protocols and
file formats as hard as reverse-engineering hardware? And as someone
else has compared hardware to network services, Debian does provide
software that communicate with those just as Debian provides drivers
that communicate with the hardware. But if Debian cannot provide a
service software, does that mean Debian should exclude the access software?
That would be an argument for the maintenance of the drivers, which I am
for. But would Debian be required to distribute the service software?
Debian does not provide the service software that will run in another
machine, but if it did, it would comply with the DFSG to be in main. The
same should be required from "firmwares". Debian does not distribute
hardware to run "firmware", neither it does distribute the hardware to
run "service software".
Post by David Weinehall
The closest we can get is to petition the hardware manufacturers for
specs or source code to the firmware, but if they don't answer, or if
they say no, we have to face he fact: our users are better off with
binary only firmware in Debian. Not in non-free.
They are better off with free/libre firmware written by people who care
about them. If it requires reverse-engineering, so be it.
Post by David Weinehall
For laptops running Intel chipsets, the most common wireless chipsets are
iwl3945, iwl4965, and iwl 5000 these days. All of them requiring binary
only firmware. With Intel's recent track record of releasing
sources, it's reasonable to assume that they would have released the
sources if they saw it as possible, so hoping for a source release seems
fairly futile.
Write a replacement! Go for other hardware! Copy the firmware yourself
if you have the author permission! But do not distribute non-free/libre
software in Debian main!
Post by David Weinehall
Now, imagine Debian having this hypothetical yearly conference, called,
oh, let's say DebConf. During that conference we organise a special day
for our users, let's call it Debian Day. Lots of potential new Debian
users show up with their laptops and wants to install Debian. As the
kind souls we are, we hand out credit-card CD's with netinst images that
they can use with the WiFi available at the conference.
Oh, but wait. They cannot access the WiFi, because their wireless cards
are not supported. Or rather, the drivers are available, but they all
report the same error message "Firmware not found". Happy, happy, joy,
joy. I'm sure those potential Debian users will feel really happy about
Debian's consistent policy that dictates that software running on
non-cpu == software running on cpu. They might not feel equally please
The hardware manufacturer is at fault! Not Debian!
Post by David Weinehall
with the fact that Debian isn't consistent in its dedication to
prioritising the users though...
I will try to be short in telling something about the history of
education in my place. The government passed some resolution that
students must be approved always. Well, some teachers interpreted that
as that they should just give some grade to the student so they could
"achieve" that. What they should have done was everything so the student
would learn and not be able to fail.

If Debian interprets that its prioritising of users' software and
"firmware" availability is in favor of their freedom, why don't forget
the DFSG and include whichever distributable work in main? Debian could
tell them about the known issues with known hardware as well as tell
them about known issues with known network services and ask them for
help.
Post by David Weinehall
[snip]
Regards: David
--
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/
Regards,
Cascardo.
Teemu Likonen
2008-10-28 19:52:31 UTC
Permalink
Post by Thadeu Lima de Souza Cascardo
Throwing out the firmware doesn't help our users, it makes things
worse for our users. And our users are our number one priority.
Is it not providing them the best free/libre operating system?
Perhaps so, but it has also become quite clear that different people
have different goals and different definitions for software freedom. The
Social Contract means different things to different people. Therefore
it's a good paper to back up one's own views, whatever they are.

1. Debian will remain 100% free

[...] We will never make the system require the use of a
non-free component.

The "system" doesn't require non-free components; it's just some users
and their hardware that does. Debian cares about the "system".

4. Our priorities are our users and free software

We will be guided by the needs of our users and the free
software community. We will place their interests first in our
priorities. [...]

Probably everybody has an opinion about what "our users" and the "free
software community" needs. By definition, "our users" are people who use
Debian. If they stop using Debian (perhaps because they don't like it or
it doesn't work in their machine) they are not our users anymore so
those people don't count. In the end Debian developers can just think
that "what I need is also the need of our users." :-)

I'm not ranting. I'm actually very happy and "passionate moderate"[1]
Debian user. Thanks you, everyone.

----------
1. http://lkml.org/lkml/2006/9/27/414
Peter Samuelson
2008-10-29 18:03:10 UTC
Permalink
[Teemu Likonen]
Post by Teemu Likonen
1. Debian will remain 100% free
[...] We will never make the system require the use of a
non-free component.
The "system" doesn't require non-free components; it's just some users
and their hardware that does. Debian cares about the "system".
Did you miss the other sentence? "We promise that the Debian system
and all its components will be free according to these guidelines."

You can argue about whether the firmware files meet the DFSG source
requirement when they don't have separate source code. You can argue
whether this violates the GPL on the kernel drivers. But I don't see
how you can argue that the firmware files we distribute on our CDs are
not part of "the Debian system and all its components".
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Ben Hutchings
2008-10-29 01:12:57 UTC
Permalink
On Tue, 2008-10-28 at 18:01 +0100, David Weinehall wrote:
[...]
Post by David Weinehall
Please try to explain to a hardware manufacturer that free their
hardware will only work with free software if they store their firmware
on an eeprom, and they'll laugh you in the face (or possibly send you
off to an asylum). Do you really think that it's better for our users
that the firmware is impossible to replace (and thus impossible, even
for the hardware vendors, to bugfix)?
Does the "EEP" mean nothing to you?
Post by David Weinehall
Face it, all hardware has firmware, either loadable or in EEPROM. In
most cases that firmware is closed source. In most cases they are for
custom chips that have no compilers/developer kits/whatever available in
Debian anyway, so having the source wouldn't make any difference (and in
some cases, the binary blobs *is* the source code; I've spent more than
enough time programming 8-bit directly from a machine-code monitor).
Agreed.

[...]
Post by David Weinehall
Now, imagine Debian having this hypothetical yearly conference, called,
oh, let's say DebConf. During that conference we organise a special day
for our users, let's call it Debian Day. Lots of potential new Debian
users show up with their laptops and wants to install Debian. As the
kind souls we are, we hand out credit-card CD's with netinst images that
they can use with the WiFi available at the conference.
Oh, but wait. They cannot access the WiFi, because their wireless cards
are not supported. Or rather, the drivers are available, but they all
report the same error message "Firmware not found". Happy, happy, joy,
joy.
[...]

This situation sucks. But we cannot claim to have a 100% free
distribution while including sourceless firmware. The obvious solution
is to have official free and not-quite-official non-free variants of the
installer. But since most users won't know in advance whether they need
sourceless firmware, the safe default would always be to choose the
non-free variant - thus this is no solution. I wish I could think of
something better.

Ben.
Ben Finney
2008-10-29 03:03:31 UTC
Permalink
This situation sucks. But we cannot claim to have a 100% free
distribution while including sourceless firmware.
That is my main concern, yes.
The obvious solution is to have official free and not-quite-official
non-free variants of the installer. But since most users won't know
in advance whether they need sourceless firmware, the safe default
would always be to choose the non-free variant - thus this is no
solution. I wish I could think of something better.
One possibility is that there's no better option but to draw a similar
line in the sand as was done for free software 25 years ago.

Hardware vendors now appear (from my understanding of this discussion)
to be at the same point where software vendors were 25 years ago:
unquestioningly pushing out software works that are increasingly
flexible and updatable, but without even considering that some
recipients might expect freedom in the work, and in formats that can't
be feasibly modified without additional works that are themselves
non-free.


Whether or not the future holds a similar flowering of baseline
freedom as has occurred so far in CPU-targeted software works, I don't
know. I also don't know from where the expertise, resources, and
funding will come to reform or replace the established non-free
hardware vendors.

What I do know is that it will never happen unless a significant
number of hardware owners and operating system distributors decide
that the current trend of increasing dependence on non-free software
for running our hardware is unacceptable.
--
\ “If you fell down yesterday, stand up today.” —_The Anatomy of |
`\ Frustration_, H. G. Wells, 1936 |
_o__) |
Ben Finney
--
To UNSUBSCRIBE, email to debian-devel-***@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact ***@lists.debian.org
Paul Wise
2008-10-29 03:10:48 UTC
Permalink
Post by David Weinehall
As for the iwl3945 firmware, I do not know for sure whether it's written
in C, assembler, or whatever else (I'm fairly certain it's NOT in some
obscure 8-bit CPU or similar). Personally I wouldn't mind having
the source code, but I do know, that if the choice is between either
having the firmware in EEPROM or having it as a binary blob, I'd take
the binary blob anytime.
It is fairly likely that it is written in C, since the firmware blob
contains the names of .c files that were probably used to compile it.
Post by David Weinehall
For laptops running Intel chipsets, the most common wireless chipsets are
iwl3945, iwl4965, and iwl 5000 these days. All of them requiring binary
only firmware. With Intel's recent track record of releasing
sources, it's reasonable to assume that they would have released the
sources if they saw it as possible, so hoping for a source release seems
fairly futile.
Intel have resolved my bug report about source code for the firmware
as wontfix, citing the FAQ about the FCC:

http://www.intellinuxwireless.org/bugzilla/show_bug.cgi?id=1594

Personally I intend to switch to a more free-software friendly
wireless hardware provider as soon as is realistic. I considered doing
something similar to the prism54 FreeMAC project, but I have nowhere
near enough experience to even start such a thing.
--
bye,
pabs

http://wiki.debian.org/PaulWise
Michelle Konzack
2008-10-29 23:10:48 UTC
Permalink
Post by Lennart Sorensen
Debian's policy is not insane. It is consistent. Any hardware maker
that wants their hardware to work with free software could use an
eeprom to store the firmware within the device, so that there is nothing
non-free that has to be distributed. That is what Debian is concerned
with. If the firmware is embedded in the device, then it has nothing to
do with Debian anymore, and it is entirely up to the user whether they
care about how the hardware they buy is made. Those that do care can
simply avoid that type of hardware (or at least try to).
Curently I am building a hardware where the parts cost arround 40US$ per
device (@10.000) and using the same microcontroller with a "big" FLASH
memory would mke this Hardware arround 5 US$ in final production more
expensive.

So for the end-users arreound 10 US$ or 8 Euro

Are you willing to pay arround 15-18% more for such hardware?

Also you shouls know, that code generated by SDCC is 3 times bigger then
the one build by my IDE provided by the Microcontroller manufacturer.

Which mean, I must switch from a 32 kByte model to a 128 kByte one.

Or by attaching an external NVRAM of 128 kByte like the Atmel AT29BV010A
and I think, you can check the price for yourself...
Post by Lennart Sorensen
If they use flash chips, then it doesn't affect Debian, because the
flash chip already contains what is needed for the device to work.
Debian doesn't have to have anything to do with updating them, and hence
there is no distribution of non-free to worry about.
Again: ARE you realy willing to pay at least
10US$ or 8€ more for the hardware?

I mean, the I am trying currently servera hardware models since I need
highly optimized one (for solar-Energie Systems) and there is nothing in
production yet. I am 100% free what to do and how I do it...

Since all of my software must run under GNU/Linux and is licensed under
GNU GPL version 3 I like to see, that my hardware/Software fit the DFSG
which mean, must run with "main".

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
Michelle Konzack
2008-10-29 21:53:20 UTC
Permalink
Hi Jeff,
Post by Jeff Carr
Some modern devices let the OS load this code
into the chip then we are able to write fully GPL drivers for the
device.
This sounds a little bit weird...

What does have the FIRMWARE to do with a DEVICE DRIVER?

The FIRMWARE is intend to be loaded INTO the DEVICE, and then the DEVICE
DRIVER is in the OS to access the hardware. The DEVICE DRIVER can be
anyway written under GPL even if the FIRMWARE is a binary blob.

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)
Thomas Bushnell BSG
2008-10-30 05:54:27 UTC
Permalink
Post by Michelle Konzack
What does have the FIRMWARE to do with a DEVICE DRIVER?
For the DEVICE DRIVER to work, a FIRMWARE must be loaded on some
hardware, as you well know.

Debian has promised that the Debian distribution will only be free
software. Some of that software is device drivers, but other parts of
it are compilers, window systems, music playing programs, email systems,
databases...and firmware.

Thomas
Frank Küster
2008-10-28 20:24:43 UTC
Permalink
Post by Jeff Carr
Post by Frank Küster
How can that be? (That is an ernest question)
Because that's how the hardware works. If you are making a widget and
you need a fpga or hybrid chip of any sort, then you generate a binary
blob using the chip manufacturers tools.
So it seems to me that there actually is source: The input files for
"the chip manufacturer's tools". Isn't that correct?

Then the problem wouldn't be to provide the source, but to have free
tools available (and maybe the keys mentioned in some other mail).

Regards, Frank
--
Frank Küster
Debian Developer (TeXLive)
ADFC Miltenberg
B90/Grüne KV Miltenberg
Lennart Sorensen
2008-10-27 18:26:28 UTC
Permalink
Post by Jeff Carr
I'm willing to stake my reputation on betting you are _not_ a firmware
engineer. Your are totally wrong if you think all firmware blobs can
be replaced by human readable source.
There is hardware, for which to function, will always, for the
lifetime of the equipment, require a firmware blob to operate. This
will always be the case; there will never be a human readable version.
It will never be possible to compile it (with non-free compilers) from
source code. There seems to be the belief that there is some scary
bogeyman at the end of this tunnel; some deliberate evil firmware
engineer who refuses to release the "source" for the blob. This is
hardly the case.
In fact, the exact opposite is true; the most free pieces of hardware
in the world require a firmware blob! A good example: try out the pci
core from opencores.org. Even in that case, where you have the logic
for the actual chip, you still have no choice but to distribute a
firmware blob anyway.
I would expect anything on opencores.org to be perfectly readable VHDL
code, which is the prefered format for manipulating it. So what was
your point again? Besides FPGA's can work with eeproms, so no binary
blob has to be distributed with the OS to work with the device.
Post by Jeff Carr
Going and flapping around and irritating hardware engineers with
totally impossible requests (Give us your psoc firmware sourcecode or
you suck! Thanks, the debian project.) makes us look like a bunch of
clueless and irrational software engineers. You think there must be
some magic way, well there is not.
For some firmware it does make sense, for others it does not.
Post by Jeff Carr
I doubt anyone reading this uses coreboot which means that the first
instruction anyone ran today was a binary only firmware blob. Where is
all your concern about that? Doubly annoying is that that firmware is
actually x86 code and it is possible to get source code that can be
compiled with gcc. That would actually be fruitful and practical.
Yes the BIOS doesn't include source code, but there also is no need for
Debian to distribute the BIOS code in main for Debian to be able to
install and run on my system.

This whole debate is about Debian having to ship said firmware, not
about whether hardware needs firmware or not. That is a different
debate, but not one that directly involves the Debian distribution.

So much as closed source binaries and firmware on flash chips in raid
controllers may be annoying, it does not in any way affect the freeness
of the code _distributed_ by Debian.
--
Len Sorensen
Jeff Carr
2008-10-27 19:29:58 UTC
Permalink
On Mon, Oct 27, 2008 at 11:26, Lennart Sorensen
Post by Lennart Sorensen
I would expect anything on opencores.org to be perfectly readable VHDL
Hardly perfectly readable - I put up code there too :)
Post by Lennart Sorensen
code, which is the prefered format for manipulating it. So what was
your point again? Besides FPGA's can work with eeproms, so no binary
blob has to be distributed with the OS to work with the device.
Which is often not the case on cheap devices (often usb) because of
cost, space, power, etc for another chip.
Lennart Sorensen
2008-10-28 14:02:52 UTC
Permalink
Post by Jeff Carr
Hardly perfectly readable - I put up code there too :)
Oh well. Some people write ugly perl code, some write ugly VHDL. Not
the language or tools fault, just bad programmers.
Post by Jeff Carr
Which is often not the case on cheap devices (often usb) because of
cost, space, power, etc for another chip.
I know. So I can either pay more (if I can find someone that still
makes a proper complete device), or I can not use that device, or I can
accept that to use it I must install some file from non-free. It should
not be support by Debian main.
--
Len Sorensen
Continue reading on narkive:
Loading...