[EMAIL PROTECTED] wrote:
On Mon, Nov 01, 2004 at 01:51:56AM +0100, Marco d'Itri wrote:
So you say that non-free software is OK with you as long as you can
pretend it's not there? Which part of the policy or SC justifies this
theory?
If I ignore something as a part of a system when that
On Mon, Nov 01, 2004 at 01:51:56AM +0100, Marco d'Itri wrote:
So you say that non-free software is OK with you as long as you can
pretend it's not there? Which part of the policy or SC justifies this
theory?
[EMAIL PROTECTED] wrote:
If I ignore something as a part of a system when
[EMAIL PROTECTED] wrote:
On Thu, Nov 04, 2004 at 04:42:00PM +0100, Marco d'Itri wrote:
So you say that non-free software is OK with you as long as you can
ignore it's running on your system? Which part of the policy or SC
justifies this theory?
No, I've been saying that non-free software can
On Thu, Nov 04, 2004 at 07:11:33PM +0100, Marco d'Itri wrote:
How do you define what is part of our system, and from what you derive
this definition?
Fundamentally, everything we put in Main is a part of our system. I get
that definition from looking at debian cds, installing debian on
[EMAIL PROTECTED] wrote:
You're asking why I think can be flashed, but works just fine without
being flashed is different from won't work without being loaded?
Fundamentally, the latter case forces us to not ignore it. The equipment
won't work if we ignore the issue.
On Mon, Nov 01, 2004
You're asking why I think can be flashed, but works just fine without
being flashed is different from won't work without being loaded?
Fundamentally, the latter case forces us to not ignore it. The equipment
won't work if we ignore the issue.
On Mon, Nov 01, 2004 at 01:51:56AM +0100,
You're asking why I think can be flashed, but works just fine without
being flashed is different from won't work without being loaded?
Fundamentally, the latter case forces us to not ignore it. The equipment
won't work if we ignore the issue.
On Mon, Nov 01, 2004 at 01:51:56AM +0100, Marco
[EMAIL PROTECTED] wrote:
On Fri, Oct 29, 2004 at 05:50:29PM +0200, Marco d'Itri wrote:
So, following from this why you think that the motherboard firmware
(the BIOS, which can be reflashed by users) or the CD reader firmware
(which can be reflashed as well, with the right tools) and e.g. a
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:10:47PM -0400, Michael Poole wrote:
Conflict in what way? It says contrib and non-free are for works
that do not conform to the DFSG. Packages in contrib conform to the
DFSG but depend on software that does not. If I interpret the SC's
Raul Miller writes:
You can't build those boot loaders on a system which hasn't been booted.
So not only is there a runtime dependency from the boot loader to the
BIOS, but there is a Build-Depends-like dependency as well. I still
see no conflict with the SC or Policy.
There are a number 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
On Fri, Oct 29, 2004 at 11:11:23AM +0200, Marco d'Itri wrote:
Then let's forget for a minute boot loaders. What about all drivers
which interact with non-free software stored in computers and their
peripherals?
I think you're forgetting about more than boot loaders, since this has
been
On Fri, Oct 29, 2004 at 08:38:21AM -0400, Michael Poole wrote:
So not only is there a runtime dependency from the boot loader to the
BIOS, but there is a Build-Depends-like dependency as well. I still
see no conflict with the SC or Policy.
I'm not sure if this is because you just plain can't
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:
On Fri, Oct 29, 2004 at 08:38:21AM -0400, Michael Poole wrote:
So not only is there a runtime dependency from the boot loader to the
BIOS, but there is a Build-Depends-like dependency as well. I still
see no conflict with the SC or Policy.
I'm not sure if this is
On Fri, Oct 29, 2004 at 10:55:57AM -0400, Michael Poole wrote:
We ignore that bios dependency because it's trivial to write the software
which serves that role, but in most cases practically impossible to
change the hardware to use the resulting software.
In other words, it's a hardware
[EMAIL PROTECTED] wrote:
Then let's forget for a minute boot loaders. What about all drivers
which interact with non-free software stored in computers and their
peripherals?
I think you're forgetting about more than boot loaders, since this has
been explained more than once. However, I'll
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
[EMAIL PROTECTED] wrote:
In the goal of seeking consistency, I think this requires mass bug
filing against packages with unmet dependencies, including:
If dependencies really have to be followed outside the borders of
software manages by the OS then I agree that this is the only logical
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
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
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
Michael Poole [EMAIL PROTECTED] writes:
We do it that way because that's the way we do it? The SC is
specifically not limited to software; that was what GR 2004-003 was
about, and that was an editorial change: it was supposed to clarify
the meaning, not change it.
This appears to be a grave
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, 28 Oct 2004 13:22:42 -0400 Brian Thomas Sniffen wrote:
We do it that way because that's the way we do it? The SC is
specifically not limited to software; that was what GR 2004-003 was
about, and that was an editorial change: it was supposed to clarify
the meaning, not change it.
Brian Thomas Sniffen writes:
Michael Poole [EMAIL PROTECTED] writes:
We do it that way because that's the way we do it? The SC is
specifically not limited to software; that was what GR 2004-003 was
about, and that was an editorial change: it was supposed to clarify
the meaning, not
Raul Miller writes:
On Thu, Oct 28, 2004 at 07:43:05PM -0400, Michael Poole wrote:
The details[1] of the proposal that passed are pretty clear: It
removes the word software from a number of places, replacing it with
works, although it replaces software with components in the
first
On Thu, Oct 28, 2004 at 08:27:47PM -0400, Michael Poole wrote:
Regardless of whether works and components mean the same as
software, a computer's BIOS is a work, component and software.
Commercial IM and Microsoft Exchange servers are works and software
(and a component, but not clearly a
Raul Miller writes:
On Thu, Oct 28, 2004 at 08:27:47PM -0400, Michael Poole wrote:
Regardless of whether works and components mean the same as
software, a computer's BIOS is a work, component and software.
Commercial IM and Microsoft Exchange servers are works and software
(and a
34 matches
Mail list logo
