On Mon, Oct 25, 2004 at 11:40:22PM -0400, Michael Poole wrote:
That doesn't really change the fact that drivers that only work after
pointing it at a non-free data block have a non-free dependency, and
belong in contrib, though.
The driver operates as designed regardless of what is in the
Ken Arromdee wrote:
On Mon, 25 Oct 2004, Josh Triplett wrote:
However, suppose that your statement were true. Why stop there?
Consider the case of a piece of hardware which could not be initialized
correctly except by the Windows driver. In order for the device to
work, a user would need to
Marco d'Itri wrote:
[EMAIL PROTECTED] wrote:
Is there a dependency relationship between the package that provides
the driver and the firmware itself?
I already explained some days ago why it's good and useful to not have a
strong dependency.
Perhaps you could point to a particular message in
On Mon, 25 Oct 2004, Josh Triplett wrote:
I would disqualify that driver from main not because it depended on a
Windows driver, but because it depended on having Windows itself.
I see; so some dependencies on non-free software are to be considered
acceptable, while others are not?
I meant
* MJ Ray:
On 2004-10-22 18:24:02 +0100 martin f krafft [EMAIL PROTECTED]
wrote:
please refer to #277794. One single line needs to be erased from the
package because otherwise, the package is unconstitutional in
Germany (and Austria). [...]
For other -legal contributors, this involves a
I'd like to ask if this license is DFSG approved?
http://public.perforce.com:8080/%40md=dcd=//public/revml/cdf=//public/revml/LICENSEra=ssr=628c=bMZ%40//public/revml/LICENSE
cite
Copyright (c) 2000, 2001, Perforce Software, Inc.
All rights reserved.
Redistribution and use in
[EMAIL PROTECTED] wrote:
be provided while keeping the packages in contrib), but I didn't see
anything where you argued that a package in main that requires software
not in our archive was not a violation of Policy and the Social Contract
(other than many unsupported assertions that only the
[EMAIL PROTECTED] wrote:
So if you don't have the firmware installed (into
/usr/lib/hotplug/firmware/something_or_other), the driver will only
print an error message and return an error code. If that is your
definition of fully functional, then perhaps we should include all the
programs in
[EMAIL PROTECTED] wrote:
Heck, for all I know there's a device out there where the firmware on
disk is verilog code, and it's compiled by the driver and loaded to
an FPGA on the device.
Surely that's software.
I'm not so sure that an FPGA design is software (for sane definitions of
software).
* Piotr Roszatycki:
I think it is BSD-like license with advertising clause.
It looks more like a 3-clause BSD license, *without* the obnoxious
advertising clause.
Is it fit to the main archive?
I think so. However, IIRC, Bastian Blank is working on packaging VCP
and its dependencies.
On 2004-10-26 10:16:21 +0100 Piotr Roszatycki
[EMAIL PROTECTED] wrote:
I think it is BSD-like license with advertising clause. Is it fit to
the main
archive?
At first glance, the licence appears to be BSD-like without
advertising clause, so could go in main.
--
MJR/slefMy Opinion
[EMAIL PROTECTED] wrote:
While this is true, it is incomplete: the driver Depends, in the
policy sense, on the device, and the device Depends on the firmware.
I do not think policy can justify this.
Obviously any kind of device driver has limited practical use[1] if
you do not own the hardware
[EMAIL PROTECTED] wrote:
On Mon, Oct 25, 2004 at 04:43:50PM +0200, Marco d'Itri wrote:
Please repeat after me: drivers do not require firmwares, hardware
devices require firmwares.
Then, how do you explain the ipw2200 case where driver version 0.5 and
less will only work with a certain
[EMAIL PROTECTED] wrote:
On Mon, Oct 25, 2004 at 11:44:37AM +0200, Marco d'Itri wrote:
Huh? If a driver requires a firmware blob be copied from a driver CD,
Please repeat after me: drivers do not require firmwares, hardware
devices require firmwares.
The driver is opening a block of data on
[EMAIL PROTECTED] wrote:
In cases where firmware is basically indistinguishable from hardware,
we treat it as hardware, and not as software.
Really? Which part of policy states this?
--
ciao,
Marco
Marco d'Itri [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
be provided while keeping the packages in contrib), but I didn't see
anything where you argued that a package in main that requires software
not in our archive was not a violation of Policy and the Social Contract
(other than many
Marco d'Itri [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Heck, for all I know there's a device out there where the firmware on
disk is verilog code, and it's compiled by the driver and loaded to
an FPGA on the device.
Surely that's software.
I'm not so sure that an FPGA design is
Yes, Marco. We all understand the model you propose, based around the
idea all firmware is essentially hardware, even if it's clearly a
file that has to be there on disk for a driver to function. An
equally valid model has been proposed around the idea that all
software is software, and anything
On Tue, Oct 26, 2004 at 12:23:43PM +0200, Marco d'Itri wrote:
[EMAIL PROTECTED] wrote:
I'm telling you some drivers *do depend* on a certain firmware. You're
still repeating the opposite. Now explain me how in ipw2200 case the
driver doesn't *depend* on the firmware, since you seem to know the
Brian Thomas Sniffen [EMAIL PROTECTED] wrote:
Yes, Marco. We all understand the model you propose, based around the
idea all firmware is essentially hardware, even if it's clearly a
file that has to be there on disk for a driver to function. An
equally valid model has been proposed around
Glenn Maynard writes:
On Mon, Oct 25, 2004 at 11:40:22PM -0400, Michael Poole wrote:
That doesn't really change the fact that drivers that only work after
pointing it at a non-free data block have a non-free dependency, and
belong in contrib, though.
The driver operates as designed
Raul Miller [EMAIL PROTECTED] wrote:
It's different because, when the firmware is built into the device,
the person who has the device has the firmware.
Note that this difference is similar in character to the difference
between main and contrib.
How? Main is free software that doesn't
On Mon, Oct 25, 2004 at 07:11:56PM +0200, Sebastian Feltel wrote:
Hello Andrew,
On Sun, Oct 24, 2004 at 23:32:17, Andrew Suffield wrote:
It probably isn't legitimate to claim a license in this manner in most
jurisdictions anyway. You normally need an explicit grant from the
copyright
On Mon, Oct 25, 2004 at 11:20:07PM -0400, Tim Olsen wrote:
Hello. I researching why MPEG-1 video and audio layers 1 and 2 do not
require any royalty payments. I have been googling for the past hour
and haven't been able to come up with any concrete explanation
(although it may just be that
Raul Miller [EMAIL PROTECTED] wrote:
It's different because, when the firmware is built into the device,
the person who has the device has the firmware.
Note that this difference is similar in character to the difference
between main and contrib.
On Tue, Oct 26, 2004 at 01:39:03PM
[EMAIL PROTECTED] wrote:
In cases where firmware is basically indistinguishable from hardware,
we treat it as hardware, and not as software.
On Tue, Oct 26, 2004 at 12:27:09PM +0200, Marco d'Itri wrote:
Really? Which part of policy states this?
Historical practice.
--
Raul
Raul Miller [EMAIL PROTECTED] wrote:
Raul Miller [EMAIL PROTECTED] wrote:
Note that this difference is similar in character to the difference
between main and contrib.
On Tue, Oct 26, 2004 at 01:39:03PM +0100, Matthew Garrett wrote:
How? Main is free software that doesn't require non-free
Raul Miller [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
In cases where firmware is basically indistinguishable from hardware,
we treat it as hardware, and not as software.
On Tue, Oct 26, 2004 at 12:27:09PM +0200, Marco d'Itri wrote:
Really? Which part of policy states this?
Michael Poole [EMAIL PROTECTED] writes:
Not at all. If you fill the block with random data, the driver will
continue to do what you expect and what you can follow by reading its
source code. It is the device that will not perform and that will not
live up to its end of the interface. That
Matthew Garrett [EMAIL PROTECTED] writes:
main. We argued that this was not allowed under the social contract and
the DFSG, and in the end people were forced to agree. I am now arguing
that the social contract gives us no right to engage in this form of
historical practice - given the current
Brian Thomas Sniffen [EMAIL PROTECTED] wrote:
OK. What course of action do you advocate? So far I hear you telling
other people they're wrong -- useful if they are, not so useful if
they're the least wrong of all possible arguments -- but I haven't
heard what you'd like to do about the
Brian Thomas Sniffen writes:
Michael Poole [EMAIL PROTECTED] writes:
Not at all. If you fill the block with random data, the driver will
continue to do what you expect and what you can follow by reading its
source code. It is the device that will not perform and that will not
live up
Raul Miller [EMAIL PROTECTED] wrote:
I said similar, not identical.
The difference I was referring to was the difference of convenience --
using software from contrib requires a few extra steps. Similarly,
using an external copy of firmware requires a few extra steps.
On Tue, Oct 26,
[EMAIL PROTECTED] wrote:
Then there's no point continuing this conversation. An FPGA design,
living as a file on disk and possibly even shipped by Debian is
clearly software under Debian's definitions. Runtime-loaded firmware
I was not discussing Debian's definitions now.
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
In cases where firmware is basically indistinguishable from hardware,
we treat it as hardware, and not as software.
Really? Which part of policy states this?
Historical practice.
OK, thank you for confirming that this has no foundation in the policy.
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
I'm telling you some drivers *do depend* on a certain firmware. You're
still repeating the opposite. Now explain me how in ipw2200 case the
driver doesn't *depend* on the firmware, since you seem to know the
truth.
You are using a different meaning of depend than the
[EMAIL PROTECTED] wrote:
Yes, Marco. We all understand the model you propose, based around the
idea all firmware is essentially hardware, even if it's clearly a
file that has to be there on disk for a driver to function. An
Now it's quite clear that you did not understand at all what I have
On Tue, 26 Oct 2004 10:48:00 Don Armstrong wrote:
You really want some sort of tacit assent though. Like a checkbox or
simlar that people have to check to indicate that their post is
licensed under a specific license.[1] Implicit assent is pretty weak.
You also may consider having some sort
Brian Thomas Sniffen writes:
So if I have a program which loads a library, and replace the library
with random data, the program will continue to do what I expect and
what I can follow by reading its source. It is the library that will
not perform, not living up to its end of the
Brian Thomas Sniffen [EMAIL PROTECTED] wrote:
OK. What course of action do you advocate?
On Tue, Oct 26, 2004 at 04:12:20PM +0100, Matthew Garrett wrote:
Modify the social contract to create a new section that would be
distributed alongside main, and put the firmware in there.
This is the
On Tue, Oct 26, 2004 at 04:12:20PM +0100, Matthew Garrett wrote:
Brian Thomas Sniffen [EMAIL PROTECTED] wrote:
OK. What course of action do you advocate? So far I hear you telling
other people they're wrong -- useful if they are, not so useful if
they're the least wrong of all possible
On Tue, Oct 26, 2004 at 11:51:22AM +0100, Matthew Garrett wrote:
1) The social contract doesn't give us any leeway here. There's no
way to claim that hardware doesn't have to conform to the DFSG
The S in DFSG stands for Software, so I don't see how you would get that it
applies to hardware.
In cases where firmware is basically indistinguishable from hardware,
we treat it as hardware, and not as software.
Really? Which part of policy states this?
[EMAIL PROTECTED] wrote:
Historical practice.
On Tue, Oct 26, 2004 at 06:07:28PM +0200, Marco d'Itri wrote:
OK, thank you for
Marco d'Itri wrote:
[EMAIL PROTECTED] wrote:
So if you don't have the firmware installed (into
/usr/lib/hotplug/firmware/something_or_other), the driver will only
print an error message and return an error code. If that is your
definition of fully functional, then perhaps we should include all
Ken Arromdee wrote:
On Mon, 25 Oct 2004, Josh Triplett wrote:
I would disqualify that driver from main not because it depended on a
Windows driver, but because it depended on having Windows itself.
I see; so some dependencies on non-free software are to be considered
acceptable, while others are
Josh Triplett writes:
The driver contains code to interact with the firmware in operating the
hardware device, just as the program contains code to interact with the
library in performing its function. The driver does not contain all the
code needed to manage the device; it contains code
[EMAIL PROTECTED] wrote:
These two cases are well different: the first driver already contains
all code needed to manage the hardware device (even if it chooses to not
send some commends to the device until it will be ready to process them),
in the second case the program is not complete and
That said, it sounds like the drivers do behave differently depending on
the firmware -- you've asserted that the difference is not of interest
to the driver, but that's not at all the same as asserting that there
is no difference.
On Tue, Oct 26, 2004 at 01:47:06PM -0400, Michael Poole
Raul Miller writes:
That said, it sounds like the drivers do behave differently depending on
the firmware -- you've asserted that the difference is not of interest
to the driver, but that's not at all the same as asserting that there
is no difference.
On Tue, Oct 26, 2004 at
Raul Miller [EMAIL PROTECTED] wrote:
On Mon, Oct 25, 2004 at 11:46:03PM +0100, Matthew Garrett wrote:
I see nothing that suggests that non-free component is only meant to
apply to material shipped by Debian. Nor is there any suggestion that
it applies only to software (which is unsurprising,
On Tue, Oct 26, 2004 at 12:27:09PM +0200, Marco d'Itri wrote:
In cases where firmware is basically indistinguishable from hardware,
we treat it as hardware, and not as software.
Really? Which part of policy states this?
It's very interesting how quickly people who fail badly at backing their
Raul Miller [EMAIL PROTECTED] wrote:
On Tue, Oct 26, 2004 at 04:12:20PM +0100, Matthew Garrett wrote:
Modify the social contract to create a new section that would be
distributed alongside main, and put the firmware in there.
This is the wrong mailing list for that sort of proposal.
That's
Adam McKenna [EMAIL PROTECTED] wrote:
'Main' is what we ship. Splitting it into two parts and calling one part
something else does not make it any different. If you're going to try to
amend the social contract, you might as well amend itto allow non-free
firmware into main (after
Glenn Maynard [EMAIL PROTECTED] wrote:
The status quo, as I understand it, is that firmware which is uploaded
from disk by a driver is a dependency, but firmware embedded in the hardware
is treated as part of the hardware--that's certainly how it looks and acts
to me, as a user. I believe
Don Armstrong [EMAIL PROTECTED] wrote:
So your argument is, in effect, that because we can't ship DFSG Free
computers (I mean, the system requires them after all) then we
should just give up and go home?
Or are you trying to say that because we can't satisfy SC 1 for
hardware, we should
On Tue, Oct 26, 2004 at 08:41:02PM +0100, Matthew Garrett wrote:
I think it's the only rational way to interpret it that's consistent
with the discussion surrounding the GR. The entire point of changing the
social contract was to make it clear that the DFSG were supposed to be
used on
Raul Miller writes:
It's a matter of point of view.
On Tue, Oct 26, 2004 at 03:42:41PM -0400, Michael Poole wrote:
I am quite certain that you have never worked with the drivers I was
describing, and the chance you have worked with any of the boards is
nearly zero. Your assumption that the
Glenn Maynard [EMAIL PROTECTED] wrote:
There is no contortion of logic involved in the conclusion that the
Social Contract is only talking about the stuff that Debian ships (or
is logically capable of shipping), and not the physical hardware that
stuff runs on.
Argh. Yes, but the firmware in
On Tue, Oct 26, 2004 at 04:42:45PM -0400, Glenn Maynard wrote:
No, the entire point was to make it clear that, as far as the Social
Contract is concerned, everything in Debian is software. (This is
my understanding, based both on the changes made by 2004-003 and the
discussions surrounding
This is the wrong mailing list for that sort of proposal.
On Tue, Oct 26, 2004 at 08:32:47PM +0100, Matthew Garrett wrote:
That's why I'm not actively proposing it here. Brian asked me a
question, and I answered it.
In that case, perhaps you should take your discussion elsewhere?
Correct me
Raul Miller writes:
In that case, we should probably be treating this as analogous to
players for various forms of content. If there are any significant free
examples of that content we allow the player into main. If there are
no significant examples of that content, the loader really does
On Tue, Oct 26, 2004 at 06:46:34PM -0400, Michael Poole wrote:
How many significant free examples of DVD content are there?
I have Debian main (sarge) on DVD, so there's at least one example.
If you're talking about audio-visual materials, I imagine that the right
way to find such materials
On Tue, 26 Oct 2004 11:16:21 +0200 Piotr Roszatycki wrote:
I think it is BSD-like license with advertising clause. Is it fit to
the main archive?
What you quoted is *exactly* the 3-clause BSD license, with *no* OAC
(Obnoxious Advertising Clause).
You can compare with
But the functionality of the driver is a function of the functionality
of the device.
--
Brian Sniffen [EMAIL PROTECTED]
Marco d'Itri [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
Then there's no point continuing this conversation. An FPGA design,
living as a file on disk and possibly even shipped by Debian is
clearly software under Debian's definitions. Runtime-loaded firmware
I was not discussing
Brian Thomas Sniffen writes:
But the functionality of the driver is a function of the functionality
of the device.
The functionality of a program is a function of the functionality of
the compiler that compiles it (and, independently, of the CPU that
executes it). These are not a useful
66 matches
Mail list logo
