[EMAIL PROTECTED] wrote:
Yes, sure! If some stream of bits is considered software when stored in
RAM then I can't see why it should not be software anymore when stored
in some other media. I have not seen any convincing argument about why
software should lose its nature if stored in ROM.
If
[EMAIL PROTECTED] wrote:
On Fri, Oct 29, 2004 at 11:07:14AM +0200, Marco d'Itri wrote:
Hardware is not part of Debian, and the fact that Debian depends on
non-free pieces of hardware has never been considered to violate any of
the above. (And, as I've said a few times, stuff tucked away in an
Marco d'Itri [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
On Fri, Oct 29, 2004 at 11:07:14AM +0200, Marco d'Itri wrote:
Hardware is not part of Debian, and the fact that Debian depends on
non-free pieces of hardware has never been considered to violate any of
the above. (And, as I've
Raul Miller a écrit :
Those boot loaders are not in main.
Which bootloaders are you talking about?
So far, lilo/grub/yaboot are in main.
Benoit PAPILLAULT
[EMAIL PROTECTED] wrote:
On Thu, Oct 28, 2004 at 10:05:05PM -0400, Michael Poole wrote:
BIOSes are in the EPROM case that I've described--part of the hardware,
already present--and go in main.
How does this exception follow from either the SC, DFSG or Policy?
Hardware is not part of Debian,
Glenn Maynard writes:
On Thu, Oct 28, 2004 at 10:05:05PM -0400, Michael Poole wrote:
BIOSes are in the EPROM case that I've described--part of the hardware,
already present--and go in main.
How does this exception follow from either the SC, DFSG or Policy?
Hardware is not part of
Raul Miller a écrit :
Those boot loaders are not in main.
On Fri, Oct 29, 2004 at 08:21:53AM +0200, Benoit PAPILLAULT wrote:
Which bootloaders are you talking about?
So far, lilo/grub/yaboot are in main.
I was talking about the prior bootloader stage in rom (typically in the
bios), which
Raul Miller writes:
Raul Miller a écrit :
Those boot loaders are not in main.
On Fri, Oct 29, 2004 at 08:21:53AM +0200, Benoit PAPILLAULT wrote:
Which bootloaders are you talking about?
So far, lilo/grub/yaboot are in main.
I was talking about the prior bootloader stage in rom
Raul Miller writes:
My opinion is that if someone wants Debian to distribute the firmware,
treat it as software, and apply the DFSG to it; otherwise, treat it as
outside the Debian system in the respect that the driver should not be
considered to depend on the firmware. I think this is
* Michael Poole ([EMAIL PROTECTED]) [041028 07:25]:
[...]
I hope you don't really mean it.
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
Michael Poole [EMAIL PROTECTED]:
My opinion is that if someone wants Debian to distribute the firmware,
treat it as software, and apply the DFSG to it; otherwise, treat it as
outside the Debian system in the respect that the driver should not be
considered to depend on the firmware. I think
Andreas Barth writes:
* Michael Poole ([EMAIL PROTECTED]) [041028 07:25]:
[...]
I hope you don't really mean it.
I don't really mean it. I think when the dependency is across some
hard interface like the PCI bus, a serial port, or a network, it is
none of Debian's business.
As far as I
Glenn Maynard writes:
On Wed, Oct 27, 2004 at 09:45:29AM -0400, Michael Poole wrote:
Even granting that, it does not establish a very clear dependency
chain from the firmware to the driver. Is the driver case different
from the various network clients (AIM, Exchange, etc.) in Debian with
Note that we do treat dependencies on software we do not distribute as
real dependencies.
On Thu, Oct 28, 2004 at 01:20:12AM -0400, Michael Poole wrote:
In the goal of seeking consistency, I think this requires mass bug
filing against packages with unmet dependencies, including:
We have
* Raul Miller ([EMAIL PROTECTED]) [041028 16:25]:
On Thu, Oct 28, 2004 at 01:20:12AM -0400, Michael Poole wrote:
In the goal of seeking consistency, I think this requires mass bug
filing against packages with unmet dependencies, including:
We have traditionally ignored boot loaders because
Raul Miller writes:
Note that we do treat dependencies on software we do not distribute as
real dependencies.
On Thu, Oct 28, 2004 at 01:20:12AM -0400, Michael Poole wrote:
In the goal of seeking consistency, I think this requires mass bug
filing against packages with unmet
* Michael Poole [EMAIL PROTECTED] [041026 19:51]:
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
* Marco d'Itri [EMAIL PROTECTED] [041026 20:40]:
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.
No, this is again wrong: a program and the libraries it use are a
We have traditionally ignored boot loaders because they're outside
our scope. The reason they're outside our scope is not because we don't
treat them as software but that we can't take control of a system without
using a boot loader.
On Thu, Oct 28, 2004 at 04:33:39PM +0200, Andreas
On Thu, Oct 28, 2004 at 10:41:07AM -0400, Michael Poole wrote:
We do it that way because it's not practical to do it the other way?
Except for GR 2004-004, when has that been good enough to ignore the
SC?
If I were ignoring the social contract your question might have some
relevance.
What we
Bernhard R. Link writes:
* Michael Poole [EMAIL PROTECTED] [041026 19:51]:
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
Raul Miller writes:
It is not consistent to claim that programmable software on a BIOS
flash chip is not software, but programmable software in an FPGA is
software. It is not consistent to claim that a driver depends on
software on the other side of a hardware bus but that gaim does not
On Thu, Oct 28, 2004 at 08:52:36AM -0400, Michael Poole wrote:
In both the network protocol cases and the unwritable format cases, if
you do not have appropriate non-Debian software, neither the hardware
nor the client (software) do anything useful. I am not convinced that
the data being
Glenn Maynard writes:
On Thu, Oct 28, 2004 at 08:52:36AM -0400, Michael Poole wrote:
In both the network protocol cases and the unwritable format cases, if
you do not have appropriate non-Debian software, neither the hardware
nor the client (software) do anything useful. I am not
It does make me curious what the AIM situation is today: I'm assuming
the current clients work out-of-the-box, without making you download
AIM and stick it somewhere before it works. (My Windows client, Trillian,
does, too.) If they dropped this particular approach, it makes me
On Thu, Oct 28, 2004 at 06:50:43PM -0400, Michael Poole wrote:
It's true that different firmwares (or bytecodes, or pieces) might satisfy
this, but all that's important is whether there exist at least one of
them which is free and in main. If they're all free, the existance of
several
Glenn Maynard writes:
On Thu, Oct 28, 2004 at 06:50:43PM -0400, Michael Poole wrote:
It's true that different firmwares (or bytecodes, or pieces) might satisfy
this, but all that's important is whether there exist at least one of
them which is free and in main. If they're all free, the
On Thu, Oct 28, 2004 at 10:05:05PM -0400, Michael Poole wrote:
BIOSes are in the EPROM case that I've described--part of the hardware,
already present--and go in main.
How does this exception follow from either the SC, DFSG or Policy?
Hardware is not part of Debian, and the fact that
Michael Poole [EMAIL PROTECTED] writes:
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 Debian requires that its
Marco d'Itri [EMAIL PROTECTED] writes:
[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
On Tue, Oct 26, 2004 at 11:43:56PM -0400, Brian Thomas Sniffen wrote:
But the functionality of the driver is a function of the functionality
of the device.
Why do you keep replying without quoting? It's even more annoying than
top-posting.
--
Glenn Maynard
[EMAIL PROTECTED] wrote:
No, this is again wrong: a program and the libraries it use are a single
entity (why do you think it's called linking?) while drivers and devices
are different entities.
They interact the same way IM clients and servers interact.
From the point of view of userspace, a
Brian Thomas Sniffen writes:
Michael Poole [EMAIL PROTECTED] writes:
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
Michael Poole [EMAIL PROTECTED] writes:
And the CPU is hardware, so not covered by the DFSoftwareG.
Is the device you mentioned not hardware?
The device is hardware. The software uploaded to control it, from a
file on disk, is software.
These are not a useful observations.
On the
On Wed, Oct 27, 2004 at 08:05:34AM -0400, Michael Poole wrote:
They are useful only for people who agree with you about certain
premises.
This sentence is true of all communication.
The premises typically being the definitions of the words used.
Examples: the firmware is software rather than
Brian Thomas Sniffen writes:
Michael Poole [EMAIL PROTECTED] writes:
And the CPU is hardware, so not covered by the DFSoftwareG.
Is the device you mentioned not hardware?
The device is hardware. The software uploaded to control it, from a
file on disk, is software.
Even granting
Glenn Maynard [EMAIL PROTECTED] writes:
On Tue, Oct 26, 2004 at 11:43:56PM -0400, Brian Thomas Sniffen wrote:
But the functionality of the driver is a function of the functionality
of the device.
Why do you keep replying without quoting? It's even more annoying than
top-posting.
Parsing
Raul Miller writes:
Another premise which would work better is that firmware is somewhere
between hardware and software and that there are circumstances where it
makes sense to treat firmware as hardware and other circumstances where
it makes sense to treat firmware as software. I feel that
Another premise which would work better is that firmware is somewhere
between hardware and software and that there are circumstances where it
makes sense to treat firmware as hardware and other circumstances where
it makes sense to treat firmware as software. I feel that this premise
is
On Wed, Oct 27, 2004 at 09:45:29AM -0400, Michael Poole wrote:
Even granting that, it does not establish a very clear dependency
chain from the firmware to the driver. Is the driver case different
from the various network clients (AIM, Exchange, etc.) in Debian with
no server implementations
Raul Miller [EMAIL PROTECTED] wrote:
It seems clear to me that the distinction here is whether we
treat the firmware in question as software or hardware.
The firmware that we are talking about is, in every case I've actually
investigated, a set of instructions that are carried out by something
Raul Miller [EMAIL PROTECTED] wrote:
It seems clear to me that the distinction here is whether we
treat the firmware in question as software or hardware.
On Thu, Oct 28, 2004 at 12:32:22AM +0100, Matthew Garrett wrote:
The firmware that we are talking about is, in every case I've actually
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
[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
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 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
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
But the functionality of the driver is a function of the functionality
of the device.
--
Brian Sniffen [EMAIL PROTECTED]
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
Marco d'Itri wrote:
[EMAIL PROTECTED] wrote:
Given that the entire purpose of the driver is to actually *drive a
device*, and that it can't do that at all without the firmware, then the
No, apparently you do not understand how the driver, hardware and
firmware interact. The driver is fully
Mike Hommey wrote:
On Tue, Oct 19, 2004 at 05:46:07PM -0700, Josh Triplett wrote:
This is clearly not appropriate; it is not perfectly reasonable to
install a driver package without the firmware, any more than it is
reasonable to install a dynamically-linked binary without its shared
library
[EMAIL PROTECTED] wrote:
Given that the entire purpose of the driver is to actually *drive a
device*, and that it can't do that at all without the firmware, then the
No, apparently you do not understand how the driver, hardware and
firmware interact. The driver is fully functional as is: the
On Wed, 20 Oct 2004, Marco d'Itri wrote:
[EMAIL PROTECTED] wrote:
Given that the entire purpose of the driver is to actually *drive a
device*, and that it can't do that at all without the firmware, then the
No, apparently you do not understand how the driver, hardware and
firmware interact.
Loïc Minier wrote:
Don Armstrong [EMAIL PROTECTED] - Mon, Oct 18, 2004:
No sourcecode bits:
http://people.debian.org/~terpstra/thread/20021106.222149.24f92b22.en.html
Quite interesting, although related to code running on the host, most
of the thread is interesting.
Note that where the
In article [EMAIL PROTECTED] you wrote:
Loïc, I suggest you read the whole debian-legal thread named non-free
firmware: driver in main or contrib?, because it answers many of the
points you raised.
I will summarize the points relevant to the eagle-usb-* packages:
- distribution of firmwares with
In article [EMAIL PROTECTED] you wrote:
Loïc, I suggest you read the whole debian-legal thread named non-free
firmware: driver in main or contrib?, because it answers many of the
points you raised.
I will summarize the points relevant to the eagle-usb-* packages:
thanks Marco, as I did not
Marco d'Itri wrote:
- notwithstanding the disagreement of a few people here, even if
post-sarge eagle-usb-data will have to be moved to non-free, there is
nothing in our policy which prevents to downgrade the hard dependency
to a suggestion, to be able to keep shipping the free driver in
On Tue, Oct 19, 2004 at 05:46:07PM -0700, Josh Triplett wrote:
This is clearly not appropriate; it is not perfectly reasonable to
install a driver package without the firmware, any more than it is
reasonable to install a dynamically-linked binary without its shared
library dependencies. In
Martin Braure de Calignon [EMAIL PROTECTED] - Sat, Oct 09, 2004:
I wanted to know if the binary files in the
eagle-usb-{utils,data,source} package are free.
When I get the source of the package (apt-get source), there is a
LICENSE file in the root directory which says that the package is GPL.
Loïc Minier wrote:
Martin Braure de Calignon [EMAIL PROTECTED] - Sat, Oct 09, 2004:
I wanted to know if the binary files in the
eagle-usb-{utils,data,source} package are free.
When I get the source of the package (apt-get source), there is a
LICENSE file in the root directory which says that the
Josh Triplett [EMAIL PROTECTED] - Mon, Oct 18, 2004:
I don't believe you can. In order to distribute software under the GPL,
we must provide the preferred form for modification of that software,
which is the source. From your description, it sounds like such source
exists but is not being
Loïc Minier wrote:
Josh Triplett [EMAIL PROTECTED] - Mon, Oct 18, 2004:
I don't believe you can. In order to distribute software under the GPL,
we must provide the preferred form for modification of that software,
which is the source. From your description, it sounds like such source
exists but
[ Stop Cc:ing me please, I read this mailing list. ]
Josh Triplett [EMAIL PROTECTED] - Mon, Oct 18, 2004:
This argument has been made before, and the clear consensus is that
firmware is software; this is even clearer than the situation over
documents and other data, which were also decided
Loïc Minier [EMAIL PROTECTED] - Tue, Oct 19, 2004:
The binary blob is needed as well as you
need to talk
Sorry, copy-paste problem, forget that half-sentence.
--
Loïc Minier [EMAIL PROTECTED]
Hi,
I'm currently (with our team at eagle-usb.org) working with Sagem and
Analog Digital, Inc. in order to get a new version out with newer
functionalities...
Let's stop that current thread that has already happened and get to work
together. The point is to find an agreement that would satisfy as
On Tue, 19 Oct 2004, Loïc Minier wrote:
Josh Triplett [EMAIL PROTECTED] - Mon, Oct 18, 2004:
This argument has been made before, and the clear consensus is
that firmware is software; this is even clearer than the situation
over documents and other data, which were also decided (on a
Don Armstrong [EMAIL PROTECTED] - Mon, Oct 18, 2004:
No sourcecode bits:
http://people.debian.org/~terpstra/thread/20021106.222149.24f92b22.en.html
Quite interesting, although related to code running on the host, most
of the thread is interesting.
In the context of DSP Binaries:
Marco d'Itri wrote:
[EMAIL PROTECTED] wrote:
This package should be removed from Debian before Debian gets sued for
copyright infringement.
Can you cut this bullshit please? You know well that Debian is not going
to get sued.
Well, the corporations issuing the firmware haven't been bought
[EMAIL PROTECTED] wrote:
This package should be removed from Debian before Debian gets sued for
copyright infringement.
Can you cut this bullshit please? You know well that Debian is not going
to get sued.
--
ciao,
Marco
posted mailed
Martin Braure de Calignon wrote:
I wanted to know if the binary files in the
eagle-usb-{utils,data,source} package are free.
No.
When I get the source of the package (apt-get source), there is a
LICENSE file in the root directory which says that the package is GPL.
But in
---BeginMessage---
Thanks for your answer, I have a mail from one of the developper of this
software :
QUOTE
There's a wiki url to see about that :
http://dev.eagle-usb.org/wakka.php?wiki=DeveloppementGPL
It seems to me (Benoit Audouard) that you incorrectly inferred that we
want to change
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
I wanted to know if the binary files in the
eagle-usb-{utils,data,source} package are free.
When I get the source of the package (apt-get source), there is a
LICENSE file in the root directory which says that the package is GPL.
But in the
74 matches
Mail list logo
