DFSG violations: non-free but no contrib
Robert Lemmen
the current situation concerning firmware blobs and dfsg-freeness is a
bit sad, among other things because there really isn't too much we can
do about it in the short run. so how about some practical proposal that
we can actually implement in a reasonable timeframe that gets us in a
better position to deal with this in the long run? my idea would be:
firmware blobs without source get put into non-free, firmware blobs with
source but without the necessary free tools to generate the image end up
in contrib, firmware which is cryptographically signed and can tehrefore
not be modified goes to non-free. we relax the "main" requirements
insofar that a package that depends on another package in non-free may
stay in main (and doesn't have to go to contrib), if the contents of
that other package are not executed or used on the main/host computer'c
cpu, but on some additional hardware. (this would of course need to be
phrased a bit better, but you get the idea).
this way everyone could still use their computer (if using contrib and
non-free), and not every other package will end up in contrib. main will
contain less non-free code than it does now, end non-free code is marked
as such...
cu robert
--
Robert Lemmen http://www.semistable.com
William Pitcock
> hi everyone,
>
> the current situation concerning firmware blobs and dfsg-freeness is a
> bit sad, among other things because there really isn't too much we can
> do about it in the short run. so how about some practical proposal that
> we can actually implement in a reasonable timeframe that gets us in a
> better position to deal with this in the long run? my idea would be:
>
> firmware blobs without source get put into non-free, firmware blobs with
> source but without the necessary free tools to generate the image end up
> in contrib, firmware which is cryptographically signed and can tehrefore
> not be modified goes to non-free. we relax the "main" requirements
> insofar that a package that depends on another package in non-free may
> stay in main (and doesn't have to go to contrib), if the contents of
> that other package are not executed or used on the main/host computer'c
> cpu, but on some additional hardware. (this would of course need to be
> phrased a bit better, but you get the idea).
Not possible, non-free is not enabled by default. Suggests/Recommends:
would be technically feasible though.
William
Robert Lemmen
> Not possible, non-free is not enabled by default. Suggests/Recommends:
> would be technically feasible though.
true, perhaps we even need a special dependency type. but these are
implementation issues. isn't the general route (put firmware in
non-free, and make sure you can still use your system) what is most in
line with how we deal with these things in debian?
Josselin Mouette
> the current situation concerning firmware blobs and dfsg-freeness is a
> bit sad, among other things because there really isn't too much we can
> do about it in the short run.
Wrong. You can help Ben Finney testing his packages. That would be much
more useful than useless babbling on mailing lists.
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
Josselin Mouette
> Wrong. You can help Ben Finney testing his packages. That would be much
> more useful than useless babbling on mailing lists.
Of course that’s Ben Hutchings. Sorry for mistaking you, Ben.
Robert Lemmen
> Wrong. You can help Ben Finney testing his packages. That would be much
> more useful than useless babbling on mailing lists.
if you are talking about these [0], i certainly do not own any of these
pieces of hardware...
cu robert
[0] http://womble.decadent.org.uk/blog/for-those-who-care-about-firmware
Ben Finney
> Le jeudi 30 octobre 2008 à 12:07 +0100, Josselin Mouette a écrit :
> > Wrong. You can help Ben Finney testing his packages. That would be
> > much more useful than useless babbling on mailing lists.
>
> Of course that’s Ben Hutchings. Sorry for mistaking you, Ben.
Anyone is welcome to *also* test my packages, of course; but those
don't currently have much impact for the free vs. non-free divide :-)
--
\ “The right to search for truth implies also a duty; one must |
`\ not conceal any part of what one has recognized to be true.” |
_o__) —Albert Einstein |
Ben Finney
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Pierre Habouzit
> we relax the "main" requirements insofar that a package that depends
> on another package in non-free may stay in main (and doesn't have to
For the sake of 10 binary firmwares, you want to make whole Debian
depend upon non-free ? Wow, what an achievement.
No, please, we don't accept regressions as a solution.
--
·O· Pierre Habouzit
··O madc...@debian.org
OOO http://www.madism.org
Charles Plessy
>
> non-free is not enabled by default. Suggests/Recommends:
> would be technically feasible though.
… but Recommends would not be welcome, as "No unmet recommends" was a release
goal of Lenny.
http://release.debian.org/lenny/goals.txt
This leaves "Suggests".
Have a nice day,
--
Charles Plessy
Debian Med packaging team,
Tsurumi, Kanagawa, Japan
Robert Lemmen
> For the sake of 10 binary firmwares, you want to make whole Debian
> depend upon non-free ? Wow, what an achievement.
ok, i think i came across in a wrong way, because that is certainly not
what i want!
but look at it this way: if we have a package that contains totally
non-free firmware which is required to make it work, we basically have a
few choices:
1. the whole package has to go to non-free
2. the package is split up into a non-free part and one that goes in
main, which then cannot depend on the non-free one
3. the same, but with a dependency and the parts go to contrib and
non-free respectively
if i understand things correctly than option 2 is what we are trying to
do with the kernel in the moment (correct me if i am wrong), and the
only thing i am saying is that having a package A which will not work
(in some cases) without package B should declare some kind of
relationship on it. simply because there *is* a relation between them...
doesn't that sound reasonable to you?
Bernd Eckenfels
> doesn't that sound reasonable to you?
Yes maybe, but on the other hand, arent ppl used to the fact that the kernel
does not know about some available modules? Thats the whole idea of modules
(and plugins in other situations like media encoders).
Gruss
Bernd
Pierre Habouzit
> On Thu, Oct 30, 2008 at 03:33:49PM +0100, Pierre Habouzit wrote:
> > For the sake of 10 binary firmwares, you want to make whole Debian
> > depend upon non-free ? Wow, what an achievement.
>
> ok, i think i came across in a wrong way, because that is certainly not
> what i want!
>
> but look at it this way: if we have a package that contains totally
> non-free firmware which is required to make it work, we basically have a
> few choices:
>
> 1. the whole package has to go to non-free
> 2. the package is split up into a non-free part and one that goes in
> main, which then cannot depend on the non-free one
> 3. the same, but with a dependency and the parts go to contrib and
> non-free respectively
no that's not how it will work. The split will be (and that's the sole
*reasonnable* way to do it) to put firmwares away, it *different* source
packages in non-free. The kernel will have patches to load those
firmwares on demand (and fail if they're not here). This is what Ben
did, and what needs testing. The kernel doesn't need to depend on the
firmwares at _all_.
All other options are silly and should not even be mentioned, unless the
expected reactions to it are nervous laughs.
Jan Hauke Rahm
> do with the kernel in the moment (correct me if i am wrong), and the
> only thing i am saying is that having a package A which will not work
> (in some cases) without package B should declare some kind of
> relationship on it. simply because there *is* a relation between them...
That "sort of relationship" between a package A that possibly (i.e. "in
some cases") might use a package B is AFAIK called "suggests" which
would be just fine: it declares a relationship and it is allowed to
declare it between packages in main and non-free.
Hauke
Lennart Sorensen
> depend upon non-free ? Wow, what an achievement.
>
> No, please, we don't accept regressions as a solution.
So if any of the hardware that requires non-free firmware to operate and
currently works in etch was to not work with Lenny, then that's
completely unacceptable?
If that's the case, then there is no way EVER to make Debian comply with
the DFSG since you aren't going to get free firmware for all those
devices.
Maintaining support for most of that hardware through the use of
non-free can be done. Maintaining support for all that hardware through
only main is imposible and unrealistic. So a demand of no regressions
is just insane. Debian shouldn't ever have worked with that hardware in
the first place in the case of main only installs.
--
Len SOrensen
Thomas Bushnell BSG
> So if any of the hardware that requires non-free firmware to operate and
> currently works in etch was to not work with Lenny, then that's
> completely unacceptable?
>
> If that's the case, then there is no way EVER to make Debian comply with
> the DFSG since you aren't going to get free firmware for all those
> devices.
Um, yes there is. We could do the same thing we do with codecs, file
formats, and all the rest--in the absence of support with free software,
we don't support it in Debian.
Thomas
Lennart Sorensen
> On Thu, 2008-10-30 at 16:33 -0400, Lennart Sorensen wrote:
> > So if any of the hardware that requires non-free firmware to operate and
> > currently works in etch was to not work with Lenny, then that's
> > completely unacceptable?
> >
> > If that's the case, then there is no way EVER to make Debian comply with
> > the DFSG since you aren't going to get free firmware for all those
> > devices.
>
> Um, yes there is. We could do the same thing we do with codecs, file
> formats, and all the rest--in the absence of support with free software,
> we don't support it in Debian.
That's what I said.
Those people who insist there can't be any regressions, are simply
kidding themselves. Debian never should have supported that hardware.
--
Len Sorensen
Aurelien Jarno
>
> the current situation concerning firmware blobs and dfsg-freeness is a
> bit sad, among other things because there really isn't too much we can
> do about it in the short run. so how about some practical proposal that
> we can actually implement in a reasonable timeframe that gets us in a
> better position to deal with this in the long run? my idea would be:
>
> firmware blobs without source get put into non-free, firmware blobs with
> source but without the necessary free tools to generate the image end up
> in contrib, firmware which is cryptographically signed and can tehrefore
> not be modified goes to non-free. we relax the "main" requirements
> insofar that a package that depends on another package in non-free may
> stay in main (and doesn't have to go to contrib), if the contents of
> that other package are not executed or used on the main/host computer'c
> cpu, but on some additional hardware. (this would of course need to be
> phrased a bit better, but you get the idea).
>
This look complicated. Everyone agrees that firmwares are a bit special
in the world of software due to the fact they don't run on the host CPU.
Some persons want to have them in main, others in non-free and others in
contrib, with some intermediate opinions.
What about creating a firmware section that have different rules than
the current main, contrib and non-free? This way ones who want a 100%
free "software" distribution have the possibility to use only main,
and ones who want to use firmwares do not need to add non-free to their
sources.list and installing non-free "software" by mistake.
This does not solve the problem of debian-installer though.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aur...@debian.org | aure...@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Robert Collins
> Everyone agrees that firmwares are a bit special
> in the world of software due to the fact they don't run on the host
> CPU.
I don't think they are at all special. What interprets the software - be
it a 'cpu', a 'vm' or a co-processor like many video cards, or something
like an arduino doesn't alter the basic attributes - there is machine
code for one or more machines, which is usually derived from some more
editable source (more can be quite a range though) though compilation.
If firmware is special, so is java, .net, ocaml, all 32-bit i386
binaries (because bochs can emulate them elsewhere) etc.
-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.
Aurelien Jarno
the host CPU.
Ben Finney
> This look complicated. Everyone agrees that firmwares are a bit
> special in the world of software due to the fact they don't run on
> the host CPU.
I disagree.
That makes them special, but it doesn't at all affect the rules that
should be applied to determine whether they are free.
Anything which we propose to distribute as part of Debian must follow
the DFSG rules; otherwise, we violate our promises in the Social
Contract. There's nothing special about the *vendor-intended use* of a
collection of bits that exempts it from the standard that we apply to
the rest of the operating system.
--
\ “A ‘No’ uttered from deepest conviction is better and greater |
`\ than a ‘Yes’ merely uttered to please, or what is worse, to |
_o__) avoid trouble.” —Mahatma Gandhi |
Ben Finney
Frank Lin PIAT
> On Thu, Oct 30, 2008 at 12:07:52PM +0100, Josselin Mouette wrote:
> > Wrong. You can help Ben Finney testing his packages. That would be much
> > more useful than useless babbling on mailing lists.
>
> if you are talking about these [0], i certainly do not own any of these
> pieces of hardware...
I would be very pleased to have a "Buyers guide" on the wiki (i.e list
devices that are current, supported and dfsg-free).
I would push to make such page in no more than "2 clicks" from the
frontpage.
Franklin
--
/me wonders how many laptops are 100% free.
Michael Banck
On Mon, Nov 03, 2008 at 09:17:56AM +1100, Ben Finney wrote:
> Anything which we propose to distribute as part of Debian must follow
> the DFSG rules; otherwise, we violate our promises in the Social
> Contract. There's nothing special about the *vendor-intended use* of a
> collection of bits that exempts it from the standard that we apply to
> the rest of the operating system.
I think you've made that point clear now, thanks.
Michael
Reinhard Tartler
> On Mon, Nov 03, 2008 at 08:03:15AM +1100, Robert Collins wrote:
>> On Sun, 2008-11-02 at 14:51 +0100, Aurelien Jarno wrote:
>> > Everyone agrees that firmwares are a bit special
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
Rémi Vanicat
> On Thu, 2008-10-30 at 11:29 +0000, Robert Lemmen wrote:
>> On Thu, Oct 30, 2008 at 12:07:52PM +0100, Josselin Mouette wrote:
>> > Wrong. You can help Ben Finney testing his packages. That would be much
>> > more useful than useless babbling on mailing lists.
>>
>> if you are talking about these [0], i certainly do not own any of these
>> pieces of hardware...
>
> I would be very pleased to have a "Buyers guide" on the wiki (i.e list
> devices that are current, supported and dfsg-free).
the problem with those list is that they often become outdated and
incomplete (who know if this no-name cheap card is supported or not ?),
but if it is updated regularly, it can be good idea.
--
Rémi Vanicat
Ben Finney
> Hi Ben,
>
> On Mon, Nov 03, 2008 at 09:17:56AM +1100, Ben Finney wrote:
> > Anything which we propose to distribute as part of Debian must
> > follow the DFSG rules; otherwise, we violate our promises in the
> > Social Contract. There's nothing special about the
> > *vendor-intended use* of a collection of bits that exempts it from
> > the standard that we apply to the rest of the operating system.
>
> I think you've made that point clear now, thanks.
I'd love it if that were true; then there wouldn't be fallacious
statements about “everyone agrees some bitstreams are special, so
deserve special standards of freedom”.
--
\ “It is far better to grasp the universe as it really is than to |
`\ persist in delusion, however satisfying and reassuring.” —Carl |
_o__) Sagan |
Ben Finney
Manoj Srivastava
> This look complicated. Everyone agrees that firmwares are a bit
> special in the world of software due to the fact they don't run on the
> host CPU.
Can you explain to me why it matters which processing unit the
software runs on? Why does it matter whether the software being
executed on the central unit matters, and that on the peripheral
processing unit gets off scott free?
Why should it matter that the software is executed on a
processing unit that lives on a daughter board instead of the mother
board?
Some people have said that most folks do not have the means of
compiling the sources, even if they were available. But most people
(like my mom) can't edit and compile code we run on the mother board
either, but we do not say that people would not be able to use source
code for the mother board, so we should not ship it.
I can also imagine a different hardware manufacturer, who does
have the proprietary hardware and compilers _could_ use the shipped
source code, if for nothing else than for learning by example -- so
that particular class of end users would be able to use and benefit
from the source code for even the daughter boards.
Just because a subset of users can benefit from the sources for
code executed in a processor does not mean freedom has become
meaningless.
manoj
--
Reunite Gondwondaland!
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Aurelien Jarno
> On Sun, Nov 02 2008, Aurelien Jarno wrote:
>
>
> > This look complicated. Everyone agrees that firmwares are a bit
> > special in the world of software due to the fact they don't run on the
> > host CPU.
>
> Can you explain to me why it matters which processing unit the
> software runs on? Why does it matter whether the software being
> executed on the central unit matters, and that on the peripheral
> processing unit gets off scott free?
>
> Why should it matter that the software is executed on a
> processing unit that lives on a daughter board instead of the mother
> board?
I haven't say that because they are not executed on by the CPU they are
more free. What I mean is that we have those discussions because they
are not executed on the main CPU, which makes them different than other
non-DFSG compliant software. Then some people consider that acceptable,
some other not.
At least having a separate section kills the argument that moving all
firmwares to non-free means that a lot of people will then use non-free
and install non-free stuff by mistake.
It also allows more easily to put all firmwares on a separate media for
use by debian installer (AFAIK there is no other reason to use non-free
in d-i).
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aur...@debian.org | aure...@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Brian May
> Can you explain to me why it matters which processing unit the
> software runs on? Why does it matter whether the software being
> executed on the central unit matters, and that on the peripheral
> processing unit gets off scott free?
>
I don't think it does matter.
On a related note though, compare to hardware vendors:
A) provides all firmware, in binary only form, without source code, on
board device ROM that cannot be changed.
B) provides all firmware on disk, in binary only form, without source
code, in form that must be downloaded to device after every boot.
A hardware is usable with Debian main. B is not.
Is this really a win? Have we gained anything for freedom? I suspect
not. In both cases the firmware cannot be modified. At least for B there
is some hope because the open source code to perform the downloading of
the firmware has been written, where as doing that for A that might be
harder.
The only benefit I see is a technical one - it is easy to draw the line
and say Debian must exclude all binary blobs that don't comply with the
DFSG. I can't see it helping in any practical manner achieve the goal of
the DFSG by increasing the freedoms we get with Debian. Users will still
have the same restrictions and not be able to make modifications. Not
until we can get open source hardware will this change.
I haven't heard a good answer to the problem that some types of firmware
can only be legally endorsed if the manufacturer ensures users can't
change it - e.g. firmware for wireless interfaces.
Brian May
Loïc Minier
> I don't think they are at all special. What interprets the software - be
> it a 'cpu', a 'vm' or a co-processor like many video cards, or something
> like an arduino doesn't alter the basic attributes - there is machine
> code for one or more machines, which is usually derived from some more
> editable source (more can be quite a range though) though compilation.
It's hard to define how they are special, but I think they are.
And I can think of other data bits in the grey area.
Consider SSL certificates for e.g. Verisign. It makes no sense to
change them and we don't have the ultimate source for them. These are
generated data files for which we have the tools to build them, but not
the ultimate source data (private key). And if we had the private key,
they would be worthless. These are effectively static data enabling
SSL communications with sites using these SSL certs providers.
I could make another argument about RFCs, it's even easier to change
them.
Firmwares can be considered somewhat the same: static data enabling the
use of your hardware. You can perhaps change them. Perhaps we have
the tools to change them. Perhaps we can change them usefully. But
they are useful as such and we don't need to fight for their freedom as
we fight for the freedom of the main OS.
With requiring the freedom of firmwares, we're putting our finger in a
completely new problem: the one of free hardware. To build an useful
firmware, we will need information about registers, the operation of
the hardware, it's hardware architecture, limits, caracteristics, test
results.
Perhaps someday we will port Debian to our graphics cards, just like
it's ported to wifi aps. This would be a new port, we don't need to
require Debian to be running on your ap to use it so why not enable the
distribution of useful data which doesn't taint the main OS if we have
the permissions to do so and it benefits our users?
I don't see Debian as a free harware and computers project. We need to
leave some hard problems to others to solve!
--
Loďc Minier
Josselin Mouette
> I haven't say that because they are not executed on by the CPU they are
> more free. What I mean is that we have those discussions because they
> are not executed on the main CPU, which makes them different than other
> non-DFSG compliant software. Then some people consider that acceptable,
> some other not.
This case is very similar to non-free documentation, which is not
executed on any CPU at all. It sounds bogus to split firmware in a
specific archive and to not do it for documentation, data, etc.
If you want to make a specific distinction for software for which we
don’t have a source and which is executed on the host CPU, I’d prefer to
see the non-free rules updated to ban such software from our archive,
and to add restrictions to it such as:
* availability of source code (for binaries meant for the host
CPU);
* legal possibility to autobuild the package (for arch-any ones);
* legal possibility to add patches for security updates.
This way we could add the non-free archive to sources.list without
wondering whether installing stuff from it will introduce an unfixable
root security hole. If more and more systems need non-free because of
firmware, this is a move that I’d like to see.
--
.''`.
: :' : We are debian.org. Lower your prices, surrender your code.
`. `' We will add your hardware and software distinctiveness to
`- our own. Resistance is futile.
Josselin Mouette
> And I can think of other data bits in the grey area.
>
> Consider SSL certificates for e.g. Verisign. It makes no sense to
> change them and we don't have the ultimate source for them. These are
> generated data files for which we have the tools to build them, but not
> the ultimate source data (private key). And if we had the private key,
> they would be worthless. These are effectively static data enabling
> SSL communications with sites using these SSL certs providers.
Since SSL certificates are randomly generated data, they are not subject
to copyright law, so I don’t think they are in any grey area. We can
change them without any licensing issue, it’s just that they won’t
fulfill their job if we do.
> Firmwares can be considered somewhat the same: static data enabling the
> use of your hardware. You can perhaps change them. Perhaps we have
> the tools to change them. Perhaps we can change them usefully. But
> they are useful as such and we don't need to fight for their freedom as
> we fight for the freedom of the main OS.
Firmware images are very different. They are binary code, only code not
meant for execution on the host CPU. They are similar to non-free data
for games: stuff that we cannot modify and with which we can live
without modifying, but it would be useful to be able to, and it is
impossible to distribute it in main.
Cheers,
Loïc Minier
> > Consider SSL certificates for e.g. Verisign. It makes no sense to
> > change them and we don't have the ultimate source for them. These are
> > generated data files for which we have the tools to build them, but not
> > the ultimate source data (private key). And if we had the private key,
> > they would be worthless. These are effectively static data enabling
> > SSL communications with sites using these SSL certs providers.
>
> Since SSL certificates are randomly generated data, they are not subject
> to copyright law, so I don’t think they are in any grey area. We can
> change them without any licensing issue, it’s just that they won’t
> fulfill their job if we do.
I'm not arguing about their copyright(-ability): just that we can't
usefully modify them; and still, the private key is the source to
create the certificate (even if it's random data), and we don't have it
in main. The same goes with firmware: we might have the right to
distribute modified binary firmwares, and they are sufficiently useful
as they are, even without accompanying ultimate source. Their form is
sufficient for a free OS, not for free hardware though; just like
certificates are sufficient for a free OS, not for an open
certification chain.
> > Firmwares can be considered somewhat the same: static data enabling the
> > use of your hardware. You can perhaps change them. Perhaps we have
> > the tools to change them. Perhaps we can change them usefully. But
> > they are useful as such and we don't need to fight for their freedom as
> > we fight for the freedom of the main OS.
>
> Firmware images are very different. They are binary code, only code not
> meant for execution on the host CPU. They are similar to non-free data
> for games: stuff that we cannot modify and with which we can live
> without modifying, but it would be useful to be able to, and it is
> impossible to distribute it in main.
The non-free games data I know of is non-free because we may not modify
it because the license doesn't explicitely allow it; what specific
example did you have in mind? This is IMO different from firmware
binaries which we may well be allowed to change, but don't have the
tools/doc to do so.
--
Loïc Minier
Loïc Minier
> > I haven't say that because they are not executed on by the CPU they are
> > more free. What I mean is that we have those discussions because they
> > are not executed on the main CPU, which makes them different than other
> > non-DFSG compliant software. Then some people consider that acceptable,
> > some other not.
> This case is very similar to non-free documentation, which is not
> executed on any CPU at all. It sounds bogus to split firmware in a
> specific archive and to not do it for documentation, data, etc.
Which non-free documentation specifically? The GFDL has this invariant
sections concept which prevents us from modifying the doc, so you can
not e.g. fork a software and rename/update doc in the invariant
sections. However I wouldn't mind having modifiable documentation in a
format which isn't the ultimate source but is maintainable, e.g. html
format if that's maintainable over time, even if originally it was
built from docbook and we don't have the docbook source.
IOW, I don't mind with picking up autogenerated contents to include in
Debian if we can maintain it in this form.
--
Loïc Minier
Josselin Mouette
> On Mon, Nov 03, 2008, Josselin Mouette wrote:
> > Since SSL certificates are randomly generated data, they are not subject
> > to copyright law, so I don’t think they are in any grey area. We can
> > change them without any licensing issue, it’s just that they won’t
> > fulfill their job if we do.
>
> I'm not arguing about their copyright(-ability): just that we can't
> usefully modify them; and still, the private key is the source to
> create the certificate (even if it's random data), and we don't have it
> in main. The same goes with firmware: we might have the right to
> distribute modified binary firmwares, and they are sufficiently useful
> as they are, even without accompanying ultimate source.
Ah, firmwares without source but with a free (e.g. MIT) license are
another story. This is definitely a grey area, since I guess many
upstreams are working on the binary directly, but there are also some
who compile it from C sources or assembly. For some of them the tools
are available, for some of them they are in-house, for some of them the
tool is a hex editor. And I don’t think we can easily distinguish
between them.
Firmwares without a free license should go to non-free, regardless of
their format.
> > Firmware images are very different. They are binary code, only code not
> > meant for execution on the host CPU. They are similar to non-free data
> > for games: stuff that we cannot modify and with which we can live
> > without modifying, but it would be useful to be able to, and it is
> > impossible to distribute it in main.
>
> The non-free games data I know of is non-free because we may not modify
> it because the license doesn't explicitely allow it; what specific
> example did you have in mind? This is IMO different from firmware
> binaries which we may well be allowed to change, but don't have the
> tools/doc to do so.
Yes, I didn’t understand you were talking about “free” firmware without
sources.
Frank Lin PIAT
> Frank Lin PIAT <fp...@klabs.be> writes:
>
> > On Thu, 2008-10-30 at 11:29 +0000, Robert Lemmen wrote:
> >> On Thu, Oct 30, 2008 at 12:07:52PM +0100, Josselin Mouette wrote:
> >> > Wrong. You can help Ben Finney testing his packages. That would be much
> >> > more useful than useless babbling on mailing lists.
> >>
> >> if you are talking about these [0], i certainly do not own any of these
> >> pieces of hardware...
> >
> > I would be very pleased to have a "Buyers guide" on the wiki (i.e list
> > devices that are current, supported and dfsg-free).
>
> the problem with those list is that they often become outdated and
> incomplete
Such buyer guide could list the supported-and-free chipsets (not laptop
model or device name).
Also, it should be limited to DebianLenny devices... Such page would
quiet "stable".
Depending on the device type, it could be either be a white-list or a
black list :
- All LAN adapter, except X,Y
- Only the X and Y Wifi adapter.
Franklin
Gunnar Wolf
> > I don't think they are at all special. What interprets the software - be
> > it a 'cpu', a 'vm' or a co-processor like many video cards, or something
> > like an arduino doesn't alter the basic attributes - there is machine
> > code for one or more machines, which is usually derived from some more
> > editable source (more can be quite a range though) though compilation.
>
> It's hard to define how they are special, but I think they are.
>
> And I can think of other data bits in the grey area.
>
> Consider SSL certificates for e.g. Verisign. It makes no sense to
> change them and we don't have the ultimate source for them. These are
> generated data files for which we have the tools to build them, but not
> the ultimate source data (private key). And if we had the private key,
> they would be worthless. These are effectively static data enabling
> SSL communications with sites using these SSL certs providers.
The thing is, some things are simply not OK for us to distribute as
part of our project, because they don't meet our requirements. That
does not mean "don't use that device" - It means only that "if you are
going to use that device, you should get the firmware". And probably
that statement will be followed by "You can get the firmware in a
nice, packaged way at http://nonfree-firmware.debian.net/yourfunnycard
or by adding non-free to your APT sources list, and installing
yourfunnycard-firmware".
What's the distinction regarding SSL certificates? Well, the
certificates are not the result of the creative process of a person
(unless you consider "creating just the right entropy for your
computer" as a creative process.
> I could make another argument about RFCs, it's even easier to change
> them.
RFCs are, indeed, a very interesting case. I understand the motivation
of the IETF on requesting them to be distributed verbatim and
disallowing distribution of modified formats - Well then, even if it
is nice to have everything in your system and packaged for Debian, I
agree that the ultimate reference point for RFCs is ietf.org - so if I
need to study a given protocol, I'll go to their website and grab the
needed bytes.
> Firmwares can be considered somewhat the same: static data enabling the
> use of your hardware. You can perhaps change them. Perhaps we have
> the tools to change them. Perhaps we can change them usefully. But
> they are useful as such and we don't need to fight for their freedom as
> we fight for the freedom of the main OS.
I agree with you. But we cannot see them as part of our system, which
is mostly defined by its freedom. We can adjust our system to allow
you to load the firmware (probably under the name "drivers", to which
many people are more used) in a painless and intuitive fashion. But I
have yet to see a real reason (besides the work that must go into
sweeping them out of the current and future kernel tree - Thanks to
everybody involved into that!) for Debian to make the needed
exceptions to distribute them as part of main.
Greetings,
--
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Loïc Minier
> I agree with you. But we cannot see them as part of our system, which
> is mostly defined by its freedom. We can adjust our system to allow
> you to load the firmware (probably under the name "drivers", to which
> many people are more used) in a painless and intuitive fashion. But I
> have yet to see a real reason (besides the work that must go into
> sweeping them out of the current and future kernel tree - Thanks to
> everybody involved into that!) for Debian to make the needed
> exceptions to distribute them as part of main.
Your post made me see the issue under a different light: I must agree
that this can't be considered on par with the rest of Debian so I wish
we would distribute it while making clear that these particular files
are not with accompanying source.
Why not come up with a new system which would be more convenient than
sections (or separate archives as you suggest)?
e.g. trivial but not very flexible: /lib/no-source-code/firmwares/blah
and a symlink /lib/firmware/foo -> /lib/no-source-code/firmwares/blah.
Or a list of "not fully-free" files, provided by the packages
themselves, e.g. /usr/share/doc/$pkg/btw-these-files-are-firmwares.
Or complex, but might be cleaner: a new type of dpkg meta-information,
just like we have conffiles, shlibs, we'd have "licensing" and would be
able to express that /lib/firmware/foo is free to distribute but
doesn't come with source code, and you probably don't care.
I'm not happy that people would enable non-free on most systems just
for the convenience of getting some files which most people will need
and for which providing a source is not critical. Fetching them
dynamically from $site isn't ok for live CDs, or when you actually try
to provide the firmware to get network to work. :-/
--
Loďc Minier
Frank Küster
> On Mon, Nov 03, 2008, Josselin Mouette wrote:
>> Le lundi 03 novembre 2008 à 10:12 +0100, Aurelien Jarno a écrit :
>> > I haven't say that because they are not executed on by the CPU they are
>> > more free. What I mean is that we have those discussions because they
>> > are not executed on the main CPU, which makes them different than other
>> > non-DFSG compliant software. Then some people consider that acceptable,
>> > some other not.
>> This case is very similar to non-free documentation, which is not
>> executed on any CPU at all. It sounds bogus to split firmware in a
>> specific archive and to not do it for documentation, data, etc.
>
> Which non-free documentation specifically?
e.g. PDF files with a DFSG-free license to them, the document source
available as a LaTeX file, but LaTeX will typeset the document using a
non-free font.
Here, you can even modify the content as you like, you just can't
reproduce the original PDF, and it would maybe be hard to make sure that
the typesetting still looks nice and readable with a free replacement
font with different metrics.
Regards, Frank
--
Frank Küster
Debian Developer (TeXLive)
ADFC Miltenberg
B90/Grüne KV Miltenberg
Robert Collins
...
> for which providing a source is not critical.
I wish I understood the reasoning here - putting aside the fact that
most of the software in Debian is under a copyleft licence and so we
*must* provide the source. Why is the source for the radio on my wifi
card any *less* critical than the source for the driver for my wifi
card?
And please, no handwaving about 'different' or 'its hardware
enablement'.
And if the answer reduces down to 'firmware is made by proprietary
vendors and does something many people need and we don't have a
replacement yet' - well thats fine, but at various points we didn't have
a free kernel, or a free libc, or a free graphic desktop environment.
Loïc Minier
> I wish I understood the reasoning here - putting aside the fact that
> most of the software in Debian is under a copyleft licence and so we
> *must* provide the source. Why is the source for the radio on my wifi
> card any *less* critical than the source for the driver for my wifi
> card?
Because I can consider the wifi firmware a subsystem which doesn't
contaminate my main OS; there's a clear interface between the two
systems -- it's like talking to another computer, talking to your hard
disk, talking to your keyboard: something proprietary or free might
well be inside, I don't care as long as I can run a free OS on the main
CPU. I'd *prefer* if it was free, but I can start another project to
fulfill this goal. I don't want the freedom requirements for the main
OS to require using free hardware, just like I want the freedom
requirements to require talking to computers running free software.
Now if Debian can distribute a blob which allows my hardware to run as
indicated by a clear interface with my free OS, that's good enough for
me. If something breaks, I can look at the interface and fix the OS or
blame the hardware (+ firmware). I don't personally feel like I need
the freedom to fix the firmware more than the hardware.
(However, I acknowledge that we must make it clear that particular
files are only distributed as enablement tools, and don't come with
ultimate source, tools, and doc.)
And if we don't require the hardware to be freely modifiable, why
require the firmware to be so?
> And if the answer reduces down to 'firmware is made by proprietary
> vendors and does something many people need and we don't have a
> replacement yet' - well thats fine, but at various points we didn't have
> a free kernel, or a free libc, or a free graphic desktop environment.
And we didn't have Debian or OpenMoko; and the glibc, linux, and
Xorg/GNOME/KDE/Xfce are huge separate projects and we could start new
projects to free more things up.
Google.com is run with software I don't have access to, but I use it
daily, as well as my microwave, or my wifi card.
--
Lo�c Minier
Gunnar Wolf
> (...)
> And if we don't require the hardware to be freely modifiable, why
> require the firmware to be so?
So we can ship it coherently with our policies?
Because users have expectations we have a way to give support to what
we ship? If it is a program, we can fix bugs. If it is documentation,
we can fix typos. If it is an image, we can deuglify it. If it is a
sound, we can make it sound... hmm... better? If it is
firmware... Well, we cannot do a thing to it.
It is better and more honest to our users to tell them, "that's not
ours and we cannot fix it. We cannot pledge to support it. Here it is,
it is a nice blob, but it is NOT ours, go bug your hardware
manufacturer for support".
It is not that I want Debian to ship a system with no hardware support
- But that I'd prefer it to be kept visibly separate. We might have a
nonfree-firmware file that can be just copied over at install time (as
Lenny's d-i already allows for) if your devices are needed for
installation. It is not -in my POV- antiethical to have non-free
hardware (i.e. hardware requiring non-free software), but shipping its
supporting firmware it does not allow us to keep our promises.
> > And if the answer reduces down to 'firmware is made by proprietary
> > vendors and does something many people need and we don't have a
> > replacement yet' - well thats fine, but at various points we didn't have
> > a free kernel, or a free libc, or a free graphic desktop environment.
>
> And we didn't have Debian or OpenMoko; and the glibc, linux, and
> Xorg/GNOME/KDE/Xfce are huge separate projects and we could start new
> projects to free more things up.
>
> Google.com is run with software I don't have access to, but I use it
> daily, as well as my microwave, or my wifi card.
Nothing to argue there. I use Google every day, and I provide the
infrastructure for my users to run their non-free programs on every
day. Still, I do not advocate distributing them as part of Debian.
And not because they are inherently evil or anything, but because
Debian is not the right place to distribute them from. See what I
wrote regarding the RFCs - I agree with the IETF, the RFCs server much
better their purpose being non-free than if they were DFSG-free. But
that's not a reason to bend Debian's principles and ship IETF RFCs in
main.
--
Gunnar Wolf - gw...@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
Manoj Srivastava
> Because I can consider the wifi firmware a subsystem which doesn't
> contaminate my main OS; there's a clear interface between the two
> systems -- it's like talking to another computer, talking to your
> hard disk, talking to your keyboard: something proprietary or free
> might well be inside, I don't care as long as I can run a free OS on
> the main CPU. I'd *prefer* if it was free, but I can start another
> project to fulfill this goal. I don't want the freedom requirements
> for the main OS to require using free hardware, just like I want the
> freedom requirements to require talking to computers running free
> software.
So you only care for one of the two freedoms. Which is
fair. Some of our users care about fewer freedoms -- they would be
happy if we distributed nvidia binary drivers in main. None of this,
however, is relevant to the central issue.
> Now if Debian can distribute a blob which allows my hardware to run as
> indicated by a clear interface with my free OS, that's good enough for
> me. If something breaks, I can look at the interface and fix the OS or
> blame the hardware (+ firmware). I don't personally feel like I need
> the freedom to fix the firmware more than the hardware.
> (However, I acknowledge that we must make it clear that particular
> files are only distributed as enablement tools, and don't come with
> ultimate source, tools, and doc.)
As I said, this is expressing your personal preference for the
kinds of freedom you care about.
> And if we don't require the hardware to be freely modifiable, why
> require the firmware to be so?
The issue is not really about whether the user can achieve
perfect freedom -- we do not restrict user actions. They may dual boot
Vista if they wish.
The issue is whether Debian distributes things that restrict
user freedoms. Last I looked, we did not distribute the hardware.
>> And if the answer reduces down to 'firmware is made by proprietary
>> vendors and does something many people need and we don't have a
>> replacement yet' - well thats fine, but at various points we didn't have
>> a free kernel, or a free libc, or a free graphic desktop environment.
> Google.com is run with software I don't have access to, but I use it
> daily, as well as my microwave, or my wifi card.
Sure. but Debian does not distribute them.
manoj
--
Is knowledge knowable? If not, how do we know that?
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Manoj Srivastava
> I don't think it does matter.
>
> On a related note though, compare to hardware vendors:
>
> A) provides all firmware, in binary only form, without source code, on
> board device ROM that cannot be changed.
>
> B) provides all firmware on disk, in binary only form, without source
> code, in form that must be downloaded to device after every boot.
>
C) Provides the source of the binary blob, which may, given the tool
chain (hardware/software) can be used by people who own such a tool
chain to modify and recreate the blob. Or to create a different
hardware by studying the original, Or just print it on a
shirt. What people do with the freedom is not something I would
like to label and narrow down.
> A hardware is usable with Debian main. B is not.
C is usable as well.
> Is this really a win? Have we gained anything for freedom? I suspect
We can't convince all non-free creators to come over rfom the
dark side to the source. Buty that is not an agument to embrace the
sith either.
> not. In both cases the firmware cannot be modified. At least for B
> there is some hope because the open source code to perform the
> downloading of the firmware has been written, where as doing that for
> A that might be harder.
But there is less pressure on the author, since they are getting
paid, since people who want to run debian hassle free will by their
hardware anyway.
I think that the same argument would have helpd for including
netscape in main as Alex Yukhimets was arguing back in '97. There might
be short term gain in popularity by letting the line shift on freedom
(heck, windows still is the dominant OS for a reason).
manoj
--
Blow it out your ear.
Manoj Srivastava <sriv...@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Ben Finney
> On Tue, Nov 04, 2008, Robert Collins wrote:
> > I wish I understood the reasoning here - putting aside the fact
> > that most of the software in Debian is under a copyleft licence
> > and so we *must* provide the source. Why is the source for the
> > radio on my wifi card any *less* critical than the source for the
> > driver for my wifi card?
>
> Because I can consider the wifi firmware a subsystem which doesn't
> contaminate my main OS
It seems to me that you can only honestly consider it so if it
*actually does not* contaminate the main OS. The situation we're faced
with is that non-free works *do* contaminate the main OS; that's the
reason we're having these discussions about DFSG violation at all.
> Now if Debian can distribute a blob which allows my hardware to run
> as indicated by a clear interface with my free OS, that's good
> enough for me.
The result can't be called free, though. So long as Debian is promised
to be free, I expect that promise to be met. It seems, from what you
say here, that you do not expect that promise to be met.
> And if we don't require the hardware to be freely modifiable, why
> require the firmware to be so?
Because it's distributed in an operating system — Debian — that its
distributor — the Debian project — promises is freely modifiable
(among other freedoms).
When someone distributes hardware to me and promises it is freely
modifiable, I require *that* promise to be upheld also.
--
\ “I don't like country music, but I don't mean to denigrate |
`\ those who do. And for the people who like country music, |
_o__) denigrate means ‘put down’.” —Bob Newhart |
Ben Finney
Robert Collins
> On Tue, Nov 04, 2008, Robert Collins wrote:
> > I wish I understood the reasoning here - putting aside the fact that
> > most of the software in Debian is under a copyleft licence and so we
> > *must* provide the source. Why is the source for the radio on my wifi
> > card any *less* critical than the source for the driver for my wifi
> > card?
>
> Because I can consider the wifi firmware a subsystem which doesn't
> contaminate my main OS;
If it wasn't fixed and never got altered I would subscribe to this
argument.
> there's a clear interface between the two
> systems -- it's like talking to another computer
Not at all, I don't own that other computer, and if it doesn't work
correctly I have to talk to it's owner to get it fixed.
> , talking to your hard
> disk
Not at all the same; probably because they are part of the standard boot
sequence I have yet to see a hard disk needing firmware (for SCSI/ATA
disks, I can't comment on more esoteric interfaces).
> , talking to your keyboard
Some keyboards we can't use properly because there is proprietary
features activated by USB command sequences that are not documented and
open. Those keyboards get less functionality on Linux until someone
reverse engineers them. Wouldn't it be great if that wasn't the case?
> : something proprietary or free might
> well be inside, I don't care as long as I can run a free OS on the main
> CPU.
I care that I can use the full capabilities of e.g. that extended
keyboard, that all the media keys, LCD displays and so on work.
> I'd *prefer* if it was free, but I can start another project to
> fulfill this goal. I don't want the freedom requirements for the main
> OS to require using free hardware, just like I want the freedom
> requirements to require talking to computers running free software.
It may be that for that hardware Debian does not fit your desires. Can I
remind you of this little statement:
"Social Contract" with the Free Software Community:
1. Debian will remain 100% free
We provide the guidelines that we use to determine if a work is free in
the document entitled The Debian Free Software Guidelines. We promise
that the Debian system and all its components will be free according to
these guidelines. We will support people who create or use both free and
non-free works on Debian. We will never make the system require the use
of a non-free component.
> Now if Debian can distribute a blob which allows my hardware to run as
> indicated by a clear interface with my free OS, that's good enough for
> me.
Why draw the line there? why not be happy if Debian can ship a blob that
uses the kernel's binary interfaces? There's no moral or technical
difference.
> And if we don't require the hardware to be freely modifiable, why
> require the firmware to be so?
Because the firmware isn't the hardware. It is software.
> > And if the answer reduces down to 'firmware is made by proprietary
> > vendors and does something many people need and we don't have a
> > replacement yet' - well thats fine, but at various points we didn't have
> > a free kernel, or a free libc, or a free graphic desktop environment.
>
> And we didn't have Debian or OpenMoko; and the glibc, linux, and
> Xorg/GNOME/KDE/Xfce are huge separate projects and we could start new
> projects to free more things up.
Debian started in 1993; Linux was first released in 1991, glibc had its
core functional in 1988
( http://en.wikipedia.org/wiki/GNU_C_Library#cite_note-1). KDE was
started in 1996, and GNOME in 1997. XFree86 forked around 1992, IIRC.
We *had* Debian long before we had a free graphical desktop environment
[that really meets the term - a window many isn't enough :)]
> Google.com is run with software I don't have access to
google doesn't affect the functionality of hardware you own.
> , but I use it
> daily, as well as my microwave
ECOMPLETELYUNRELATED
> , or my wifi card.
Which is the point under contention.
David Given
[...]
> I wish I understood the reasoning here - putting aside the fact that
> most of the software in Debian is under a copyleft licence and so we
> *must* provide the source. Why is the source for the radio on my wifi
> card any *less* critical than the source for the driver for my wifi
> card?
One potential reason is that in most jurisdictions you are legally *not
allowed* to use custom wifi firmware. Consider that most wifi systems
are software radios and that the software is entirely capable of
exceeding all regulators' transmissions strength limits or subverting
the carefully tuned frequency-hopping algorithms, etc. And of course,
it's the *hardware vendors* who'll be liable if someone does subvert
their wifi card to do this --- they'll be violating their FCC (or other)
license --- so there'll be pretty hefty signature validation to ensure
that only official firmware can be used.
So having the source doesn't actually gain you anything --- you would
neither be able nor allowed to do anything with it, apart from printing
it on T-shirts.
(Incidentally, this is one reason why mobile phone handset vendors are
so paranoid about reflashing phones. A phone with a maliciously
programmed GSM stack would turn into a rather efficient cellphone jammer.)
--
David Given
d...@cowlark.com
Faidon Liambotis
> One potential reason is that in most jurisdictions you are legally *not
> allowed* to use custom wifi firmware. Consider that most wifi systems
> are software radios and that the software is entirely capable of
> exceeding all regulators' transmissions strength limits or subverting
> the carefully tuned frequency-hopping algorithms, etc. And of course,
> it's the *hardware vendors* who'll be liable if someone does subvert
> their wifi card to do this --- they'll be violating their FCC (or other)
> license --- so there'll be pretty hefty signature validation to ensure
> that only official firmware can be used.
IMHO this is FUD well spread by companies that didn't want their IP
"exposed". Atheros cards don't have any firmware; you can transmit in
whatever frequency you want to with ath5k/ath9k -- ath9k is distributed
by Atheros themselves while ath5k is nowdays endorsed by them.
There are companies within the EU (possibly within the U.S. as well)
that gained access to those bits (namely, the Atheros HAL) via NDA and
distributed modified binaries that lifted any software limitations
whatsoever.
The most famous one that I know of is MikroTik; they sell a
"superchannel" upgrade that allows you to tune Atheros cards to
2.3-2.5GHz and 4.9-6.1GHz.
IOW, frequencies that are illegal to use without a license in most parts
of the world.
I highly doubt that MikroTik would do that (or Atheros would let them)
if they had a risk of getting sued for liability in case one of their
thousand customers violated the local or EU/federal laws.
> So having the source doesn't actually gain you anything --- you would
> neither be able nor allowed to do anything with it, apart from printing
> it on T-shirts.
That assumes that you want to operate only on unlicensed/ISM bands.
You can always *buy* a license from the local regulating authority to
transmit to other frequencies, in order to avoid interference by
unlicensed stations (and yes, I know people that have done this).
> (Incidentally, this is one reason why mobile phone handset vendors are
> so paranoid about reflashing phones. A phone with a maliciously
> programmed GSM stack would turn into a rather efficient cellphone jammer.)
That's also false. You can easily jam cellphones using equipment bought
from your local radio shop.
There are even (perfectly legal) commercial products that do exactly that.
Regards,
Faidon
Loïc Minier
> It may be that for that hardware Debian does not fit your desires. Can I
> remind you of this little statement
Please, don't quote the social contract on me.
And I already expressed that I understood my position implied changes
to foundation documents.
> > Now if Debian can distribute a blob which allows my hardware to run as
> > indicated by a clear interface with my free OS, that's good enough for
> > me.
> Why draw the line there? why not be happy if Debian can ship a blob that
> uses the kernel's binary interfaces? There's no moral or technical
> difference.
I acknowledge it's hard to draw the line. One idea in this thread was
"[ultimately] runs on the host's CPU". It's hard.
> > > And if the answer reduces down to 'firmware is made by proprietary
> > > vendors and does something many people need and we don't have a
> > > replacement yet' - well thats fine, but at various points we didn't have
> > > a free kernel, or a free libc, or a free graphic desktop environment.
> >
> > And we didn't have Debian or OpenMoko; and the glibc, linux, and
> > Xorg/GNOME/KDE/Xfce are huge separate projects and we could start new
> > projects to free more things up.
>
> Debian started in 1993; Linux was first released in 1991, glibc had its
> core functional in 1988
> ( http://en.wikipedia.org/wiki/GNU_C_Library#cite_note-1). KDE was
> started in 1996, and GNOME in 1997. XFree86 forked around 1992, IIRC.
>
> We *had* Debian long before we had a free graphical desktop environment
> [that really meets the term - a window many isn't enough :)]
I still don't see your point. I hope you see mine that all these
efforts are run as separate projects though. And the availability of
new free software after the apparition of Debian isn't really an
exciting argument. Would Debian have been possible without a free
glibc and a free kernel? Should we make it harder for Debian to be
useful because we don't have free firmware and hardware?
> > Google.com is run with software I don't have access to
> google doesn't affect the functionality of hardware you own.
No, but what is debated here is whether I need to be able to change it.
I can't change google's software, I might not be able to change the
firmware's software depending on the hardware implementation (whether
the firmware can be dynamically loaded) or on the availability of the
firmware's source. Yet I can use google and my wifi card.
What's possible is pretty clear at the time you buy the hardware and
wont change over time, wont require relicensing.
> > , but I use it
> > daily, as well as my microwave
> ECOMPLETELYUNRELATED
Or my phone; this was to illustrate my point WRT to interfaces: I don't
mind interfacing with something non-free when (there's no free
replacement and) there's a clear interface.
TBH I don't see enough new ideas or arguments in this thread anymore to
justify proposing fundamental changes to our core documents, so I'll
shut up.
--
Loďc Minier
Loïc Minier
> It is better and more honest to our users to tell them, "that's not
> ours and we cannot fix it. We cannot pledge to support it. Here it is,
> it is a nice blob, but it is NOT ours, go bug your hardware
> manufacturer for support".
Ack.
> It is not that I want Debian to ship a system with no hardware support
> - But that I'd prefer it to be kept visibly separate.
I fully agree.
> And not because they are inherently evil or anything, but because
> Debian is not the right place to distribute them from. See what I
> wrote regarding the RFCs - I agree with the IETF, the RFCs server much
> better their purpose being non-free than if they were DFSG-free. But
> that's not a reason to bend Debian's principles and ship IETF RFCs in
> main.
I see your point. Albeit all the things we're talking about are quite
different in nature.
A wifi card needs to be usable to access the network even during an
install, so if we want to support hardware which requires firmware to
be loaded after each boot with the Debian OS, the file needs to be
accessible to the Debian OS.
I see how easy it is to define that "everything which Debian
distributes is free software". I wish I'd have a rule as simple to
claim which would make it clear that "this is a free OS which comes
with some companion firmware files without source to make hardware just
work".
Anyway, there's too little traction to suggest changing our foundation
documents in an unclear way, so I'll shut up.
--
Loďc Minier
Thomas Bushnell BSG
> So having the source doesn't actually gain you anything --- you would
> neither be able nor allowed to do anything with it, apart from printing
> it on T-shirts.
You can learn about it. Remember the educational purpose of free
software?
Thomas
Brian May
> But there is less pressure on the author, since they are getting
> paid, since people who want to run debian hassle free will by their
> hardware anyway.
>
> I think that the same argument would have helpd for including
> netscape in main as Alex Yukhimets was arguing back in '97. There might
> be short term gain in popularity by letting the line shift on freedom
> (heck, windows still is the dominant OS for a reason).
>
not from B to A.
We might find vendors get the wrong message: "We want to able to to use
your product with Debian out of the box", which swings them towards the
"easier" option A (closed firmware distributed on ROM), not option C
(open firmware with source).
Brian May
David Given
[...]
> IMHO this is FUD well spread by companies that didn't want their IP
> "exposed". Atheros cards don't have any firmware; you can transmit in
> whatever frequency you want to with ath5k/ath9k -- ath9k is distributed
> by Atheros themselves while ath5k is nowdays endorsed by them.
In which case things have changed within the past couple of years ---
after all, the whole purpose of the Atheros HAL was to inforce those FCC
limits. Do you have any references? Like, to an FCC statement of policy
change? If so, it would be extremely useful to have.
[...]
>> (Incidentally, this is one reason why mobile phone handset vendors are
>> so paranoid about reflashing phones. A phone with a maliciously
>> programmed GSM stack would turn into a rather efficient cellphone jammer.)
> That's also false. You can easily jam cellphones using equipment bought
> from your local radio shop.
> There are even (perfectly legal) commercial products that do exactly that.
Well, yeah, but those devices are either (a) home built and therefore
unlicensed, which means they're either illegal or operating under some
sort of exemption as experimental hardware, or either (b) commercial and
licensed, which means they're operating within the regulators' limits.
(Or (c), in that they're commercial and illegal.)
That's a totally different matter from taking a piece of licensed
equipment where the vendor has promised the regulator that it operates
according to the rules, and then using that unmodified equipment to
violate those rules. Sure, you know and I know that changing the
software counts as a modification, but that's not how the regulators think.
Luckily it's very unlikely that Debian will ever having anything to do
with the labyrinthing maze of potential lawsuits that are involved in
GSM protocol stacks... what *is* the Debian project's policy on using
Debian with safety-critical systems, anyway? There are a number of
licenses that specifically prohibit the use of their software in such
environments; do these count as DSFG-free? Is there any such software in
Debian?
--
David Given
d...@cowlark.com
Paul Wise
> Luckily it's very unlikely that Debian will ever having anything to do
> with the labyrinthing maze of potential lawsuits that are involved in
> GSM protocol stacks... what *is* the Debian project's policy on using
> Debian with safety-critical systems, anyway? There are a number of
> licenses that specifically prohibit the use of their software in such
> environments; do these count as DSFG-free? Is there any such software in
> Debian?
Such licenses don't comply with DFSG #6, there should not be any such
software in Debian, there may be some in non-free though. If you find
any such software in main, please file RC bugs.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Michelle Konzack
> That's also false. You can easily jam cellphones using equipment bought
> from your local radio shop.
> There are even (perfectly legal) commercial products that do exactly that.
Maybe in the USNA, but not in Europe... (at least Germany and France)
Jaming the GSM Network cost you up to 500.000 Euro and 5 years prison.
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)