Anthony DeRobertis wrote:
> Glenn Maynard wrote:
>> It'd be useful to have a real-life example of a server that
>> needs to be sent proprietary data for a "legitimate" reason (in the
>> sense that a device needing to be sent firmware is "legitimate").
>
> Habeas SWE.
>
> I believe SpamAssassin im
Anthony DeRobertis wrote:
> Glenn Maynard wrote:
>> It'd be useful to have a real-life example of a server that
>> needs to be sent proprietary data for a "legitimate" reason (in the
>> sense that a device needing to be sent firmware is "legitimate").
>
> Habeas SWE.
>
> I believe SpamAssassin im
Glenn Maynard wrote:
It'd be useful to have a real-life example of a server that
needs to be sent proprietary data for a "legitimate" reason (in the
sense that a device needing to be sent firmware is "legitimate").
Habeas SWE.
I believe SpamAssassin implements the server side (through hashes
Glenn Maynard wrote:
It'd be useful to have a real-life example of a server that
needs to be sent proprietary data for a "legitimate" reason (in the
sense that a device needing to be sent firmware is "legitimate").
Habeas SWE.
I believe SpamAssassin implements the server side (through hashes to
av
On Sun, 09 Jan 2005, Marco d'Itri wrote:
> On Jan 08, Josh Triplett <[EMAIL PROTECTED]> wrote:
> > atmel-firmware . Would you argue that at76c503a-source should neither
> > Depends: nor Recommends: atmel-firmware ? If so, why? If you changed
> Yes. Read the debian-legal@ archive if you care abou
On Jan 08, Josh Triplett <[EMAIL PROTECTED]> wrote:
> atmel-firmware . Would you argue that at76c503a-source should neither
> Depends: nor Recommends: atmel-firmware ? If so, why? If you changed
Yes. Read the debian-legal@ archive if you care about the details.
--
ciao,
Marco
signature.asc
On Fri, 7 Jan 2005 17:33:52 -0500, Glenn Maynard <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 07, 2005 at 02:13:05PM -0500, Luke Schierer wrote:
> > The aim/icq servers do not currently, but could at the flip of a switch
> > (and have in the past), required you to send a hash of a specified
> > segment
Marco d'Itri wrote:
> On Jan 07, Josh Triplett <[EMAIL PROTECTED]> wrote:
>>I'll assume for the moment you are only disagreeing with the
>>driver->firmware dependencies, not the client->server dependencies,
>>since the latter is standard Debian policy.
>
> No. What I'm saying is that if you stretc
Michael Poole wrote:
> Josh Triplett <[EMAIL PROTECTED]> writes:
>>Michael Poole wrote:
>>>Josh Triplett writes:
>>>
If the ICQ server were packaged in the Debian non-free section, would
you make ICQ clients Depends: or Recommends: on the ICQ server? If not,
then if the ICQ server were
Glenn Maynard wrote:
> On Thu, Jan 06, 2005 at 09:36:10PM -0500, Michael Poole wrote:
>>I disagree that the driver would Depends: on the firmware.
>
> Well, maybe we're coming closer to the root of our disagreement. I
> thought it was self-evident that, if a driver is packaged (on its own[1]),
>
On Fri, Jan 07, 2005 at 02:13:05PM -0500, Luke Schierer wrote:
> The aim/icq servers do not currently, but could at the flip of a switch
> (and have in the past), required you to send a hash of a specified
> segment of a specified file from the official (copyrighted) winaim
> client. If I am und
On Jan 07, Josh Triplett <[EMAIL PROTECTED]> wrote:
> I'll assume for the moment you are only disagreeing with the
> driver->firmware dependencies, not the client->server dependencies,
> since the latter is standard Debian policy.
No. What I'm saying is that if you stretch the definition of
"requi
On Fri, Jan 07, 2005 at 01:22:27PM -0500, Glenn Maynard wrote:
> If there's a parallel between ICQ servers and hardware, it seems to me
> that the ICQ server is like a physical hardware device which requires
> no firmware.
>
> If (all) ICQ servers required that I send it a copy, as a bitstream,
On Thu, Jan 06, 2005 at 09:36:10PM -0500, Michael Poole wrote:
> "Depends" and "Build-Depends" are not necessarily the entirety of the
> Social Contract's idea of dependency.
We're not saying they are. (For example, that would imply that the tech
ctte would have a great deal of power over the DFS
On Thu, 6 Jan 2005, Raul Miller wrote:
> > And of course there's the absurd situation where a manufacturer decides to
> > move firmware from a device from a ROM to a CD and Debian suddenly cannot
> > provide a driver for it
> Most likely, Debian IS able to provide a driver for it. Well, unless
Josh Triplett <[EMAIL PROTECTED]> writes:
> Michael Poole wrote:
> > Josh Triplett writes:
> >>If the ICQ server were packaged in the Debian non-free section, would
> >>you make ICQ clients Depends: or Recommends: on the ICQ server? If not,
> >>then if the ICQ server were packaged, the ICQ client
> On Thu, 6 Jan 2005, Josh Triplett wrote:
> > If the firmware we have packaged in non-free comes standard on the
> > device, then the driver does not need a copy of the firmware, so it does
> > not have a dependency on it.
On Thu, Jan 06, 2005 at 06:21:52PM -0800, Ken Arromdee wrote:
> Hm? The d
On Thu, 6 Jan 2005, Josh Triplett wrote:
> If the firmware we have packaged in non-free comes standard on the
> device, then the driver does not need a copy of the firmware, so it does
> not have a dependency on it.
Hm? The driver does need a copy of the firmware. It needs a copy that is
present
Michael Poole wrote:
> Josh Triplett writes:
>>If the ICQ server were packaged in the Debian non-free section, would
>>you make ICQ clients Depends: or Recommends: on the ICQ server? If not,
>>then if the ICQ server were packaged, the ICQ client would still be in
>>main. Therefore, the ICQ client
Marco d'Itri wrote:
> On Jan 06, Josh Triplett <[EMAIL PROTECTED]> wrote:
>>An ICQ client wouldn't Depends: icq-server; it might Suggests:
>>icq-server, but that's OK. A driver might at most Suggests:
>>burned-in-firmware-for-reflashing, but it would Depends: or at a minimum
>>Recommends: firmware
Josh Triplett writes:
> If the ICQ server were packaged in the Debian non-free section, would
> you make ICQ clients Depends: or Recommends: on the ICQ server? If not,
> then if the ICQ server were packaged, the ICQ client would still be in
> main. Therefore, the ICQ client can be in main.
A, e
Michael Poole wrote:
> Glenn Maynard writes:
>>On Thu, Jan 06, 2005 at 02:42:50PM -0500, Michael Poole wrote:
>>>Brian Thomas Sniffen writes:
software which he could download... but not from Debian, since it's
not Free and not packaged.
>>>
>>>Why do you insist on the "downloadable" part of
On Jan 06, Josh Triplett <[EMAIL PROTECTED]> wrote:
> An ICQ client wouldn't Depends: icq-server; it might Suggests:
> icq-server, but that's OK. A driver might at most Suggests:
> burned-in-firmware-for-reflashing, but it would Depends: or at a minimum
> Recommends: firmware-loaded-by-driver.
I
[Please keep either debian-legal or myself in the CC list; I'm not
subscribed to debian-devel.]
Anthony DeRobertis wrote:
> Brian Thomas Sniffen wrote:
>>> So would a web-based firmware loader, that never saved the firmware to
>>> disk allow the drivers to be in main?
>>
>> Of course not. It's fe
Glenn Maynard writes:
> On Thu, Jan 06, 2005 at 02:42:50PM -0500, Michael Poole wrote:
> > Brian Thomas Sniffen writes:
> >
> > > No. Firmware resident in RAM but put there by, say, the BIOS is
> > > fine. We've elected not to ignore firmware which is to be handled and
> > > installed by Debian
On Thu, Jan 06, 2005 at 02:42:50PM -0500, Michael Poole wrote:
> Brian Thomas Sniffen writes:
>
> > No. Firmware resident in RAM but put there by, say, the BIOS is
> > fine. We've elected not to ignore firmware which is to be handled and
> > installed by Debian software. You're having trouble m
On Thu, Jan 06, 2005 at 01:54:19PM -0500, Brian Thomas Sniffen wrote:
> aren't equivalent. The issue at hand is whether somebody might ever
> download software from Debian and find it useless without additional
> software which he could download... but not from Debian, since it's
> not Free and no
Brian Thomas Sniffen writes:
> No. Firmware resident in RAM but put there by, say, the BIOS is
> fine. We've elected not to ignore firmware which is to be handled and
> installed by Debian software. You're having trouble making a coherent
> position out of this only because you keep recasting i
Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> If I download an ICQ client, there are lots of reasons I might find it
> useful: I might not have anything to say, or I might have no network
> connection, or I might have no friends to talk to. Debian is not
> responsible for providing me with cr
Anthony DeRobertis <[EMAIL PROTECTED]> writes:
>>>So would a web-based firmware loader, that never saved the firmware to
>>>disk allow the drivers to be in main?
>> Of course not. It's fetching software, then using that software.
>> ICQ software merely mentions messages, but doesn't use them.
>
>
Josh Triplett wrote:
I would like to suggest an additional option, which I think covers most
cases quite well:
If Debian were to package (a copy of) the non-free item in the non-free
section, would the Free package express a Depends, Recommends, or
Build-Depends on the non-free package? If so,
Raul Miller wrote:
On Fri, Dec 31, 2004 at 05:02:15PM -0500, Anthony DeRobertis wrote:
The social contract says "...but we will never make the system depend on
an item of non-free software." not "but we will never make the system
depend on an item of non-free software /which we must distribute
Brian Thomas Sniffen wrote:
So would a web-based firmware loader, that never saved the firmware to
disk allow the drivers to be in main?
Of course not. It's fetching software, then using that software. ICQ
software merely mentions messages, but doesn't use them.
ICQ uses the messages as i
* Matthew Garrett
| You have argued that drivers don't really depend on firmware, but
| instead depend on the hardware expressing the correct interface. As an
| example, we can compare maria-vis, which depends on the graphviz
| package. maria-vis is in contrib, because it depends on graphviz, whi
I demand that Glenn Maynard may or may not have written...
> On Tue, Jan 04, 2005 at 06:22:20PM +, Darren Salt wrote:
>>> On Tue, Jan 04, 2005 at 01:48:12AM +, Darren Salt wrote:
>> [fetching firmware on finding hardware which needs it: wget or packaged?]
Fetch every time and fetch on
On Tue, Jan 04, 2005 at 06:22:20PM +, Darren Salt wrote:
> > On Tue, Jan 04, 2005 at 01:48:12AM +, Darren Salt wrote:
> [fetching firmware on finding hardware which needs it: wget or packaged?]
> >> Fetch every time and fetch once. That looks like a difference to me...
>
> > How could "fet
I demand that Glenn Maynard may or may not have written...
> On Tue, Jan 04, 2005 at 01:48:12AM +, Darren Salt wrote:
[fetching firmware on finding hardware which needs it: wget or packaged?]
>> Fetch every time and fetch once. That looks like a difference to me...
> How could "fetch every ti
Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> Hamish Moffatt <[EMAIL PROTECTED]> writes:
>> So if EEPROMs contain software, why "don't [you] get to distribute any
>> drivers"? I don't understand.
>
> You can get software out of an firmware-EEPROM on a hardware device.
> I don't think it's appr
On Tue, Jan 04, 2005 at 01:48:12AM +, Darren Salt wrote:
> Fetch every time and fetch once. That looks like a difference to me...
How could "fetch every time" possibly be acceptable to the SC when
"fetch once" is not? Are you saying that the "rancid-installer" package
could go in main, if it
I demand that Glenn Maynard may or may not have written...
> On Mon, Jan 03, 2005 at 05:42:07PM +, Darren Salt wrote:
>>> Anthony DeRobertis <[EMAIL PROTECTED]> writes:
> Scripsit Anthony DeRobertis <[EMAIL PROTECTED]>
>> That would, however, cover firmware and wind up sending X to con
On Mon, Jan 03, 2005 at 05:42:07PM +, Darren Salt wrote:
> > Anthony DeRobertis <[EMAIL PROTECTED]> writes:
> >>> Scripsit Anthony DeRobertis <[EMAIL PROTECTED]>
> That would, however, cover firmware and wind up sending X to contrib. So
> maybe: ... iff it is stored on the local machi
Scripsit Thomas Bushnell BSG <[EMAIL PROTECTED]>
> Matthew Garrett <[EMAIL PROTECTED]> writes:
>> The obvious thing to do here is not to attempt to find a way that
>> we can interpret the SC that makes sense - the obvious thing to do
>> here is to decide what we want the SC to say and then change
Matthew Garrett <[EMAIL PROTECTED]> writes:
> The parsimonious explanation is that the issue wasn't thought about in
> that much detail when the social contract was written. The archives tend
> to support this. The obvious thing to do here is not to attempt to find
> a way that we can interpret th
Scripsit Raul Miller <[EMAIL PROTECTED]>
> On Sat, Jan 01, 2005 at 11:33:21AM -0800, Josh Triplett wrote:
>> Please suggest any case which you don't think this criteria adequately
>> covers.
> The bios.
> Unless, we decide that the bios we put in non-free isn't the bios we
> need to boot the mach
On Sat, Jan 01, 2005 at 11:33:21AM -0800, Josh Triplett wrote:
> Please suggest any case which you don't think this criteria adequately
> covers.
The bios.
Unless, we decide that the bios we put in non-free isn't the bios we
need to boot the machine.
--
Raul
Anthony DeRobertis wrote:
> The social contract says "...but we will never make the system depend on
> an item of non-free software." not "but we will never make the system
> depend on an item of non-free software /which we must distribute/."
>
> In order to allow the vast majority of hardware whi
On Thu, Dec 30, 2004 at 03:09:52PM -0600, Gunnar Wolf wrote:
> The blobs for the in-kernel drivers are not to be executed by the host
> CPU itself, neither is the non-free ICQ, MSN or Yahoo servers
> (although Gaim can be seen useful by itself as it works with IRC and
> Jabber... Well, brain, pleas
Scripsit Anthony DeRobertis <[EMAIL PROTECTED]>
> Henning Makholm wrote:
>> Scripsit Anthony DeRobertis <[EMAIL PROTECTED]>
>>>That would, however, cover firmware and wind up sending X to
>>>contrib. So maybe: ... iff it is stored on the local machine's file
>>>system.
>> That would be my *intuit
On Thu, Dec 30, 2004 at 03:09:52PM -0600, Gunnar Wolf wrote:
> Hamish Moffatt dijo [Tue, Dec 28, 2004 at 04:26:26PM +1100]:
> > Yet the ICQ client is not useful without a component which is not in
> > Debian and in fact is not freely available.
> >
> > If the emulators were extended to be able to
Anthony DeRobertis <[EMAIL PROTECTED]> writes:
> Henning Makholm wrote:
>> Scripsit Anthony DeRobertis <[EMAIL PROTECTED]>
>>
>>>That would, however, cover firmware and wind up sending X to
>>>contrib. So maybe: ... iff it is stored on the local machine's file
>>>system.
>> That would be my *intui
On Fri, Dec 31, 2004 at 05:02:15PM -0500, Anthony DeRobertis wrote:
> The social contract says "...but we will never make the system depend on
> an item of non-free software." not "but we will never make the system
> depend on an item of non-free software /which we must distribute/."
We don't ma
Henning Makholm wrote:
Scripsit Anthony DeRobertis <[EMAIL PROTECTED]>
That would, however, cover firmware and wind up sending X to
contrib. So maybe: ... iff it is stored on the local machine's file
system.
That would be my *intuitive* understanding of how the mail/contrib
difference works.
Scripsit Anthony DeRobertis <[EMAIL PROTECTED]>
> That would, however, cover firmware and wind up sending X to
> contrib. So maybe: ... iff it is stored on the local machine's file
> system.
That would be my *intuitive* understanding of how the mail/contrib
difference works.
--
Henning Makholm
Glenn Maynard wrote:
On Tue, Dec 28, 2004 at 04:26:26PM +1100, Hamish Moffatt wrote:
Yet the ICQ client is not useful without a component which is not in
Debian and in fact is not freely available.
Nor is a driver useful without a piece of hardware which isn't in
Debian.
Of course, license
Glenn Maynard wrote:
icq-client does require access to a server to be useful, but there's no
expectation that that server be installable by the machine running the
client; the lack of an icq-server package is not a "piece missing" from
the client.
So, then, a solution would be:
a) Set
Hamish Moffatt dijo [Tue, Dec 28, 2004 at 04:26:26PM +1100]:
> Yet the ICQ client is not useful without a component which is not in
> Debian and in fact is not freely available.
>
> If the emulators were extended to be able to fetch some basic ROM images
> off the internet by themselves (eg via H
Josh Triplett <[EMAIL PROTECTED]> writes:
> Hamish Moffatt wrote:
>> If the emulators were extended to be able to fetch some basic ROM images
>> off the internet by themselves (eg via HTTP), could they go in main?
>
> As an interesting additional point, this isn't just a hypothetical
> scenario:
Hamish Moffatt wrote:
> If the emulators were extended to be able to fetch some basic ROM images
> off the internet by themselves (eg via HTTP), could they go in main?
As an interesting additional point, this isn't just a hypothetical
scenario: the ZSNES emulator (in the Windows version, not yet
Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> Matthew Garrett <[EMAIL PROTECTED]> writes:
>
>> /why/ those freedoms are no longer necessary. What is it about that code
>> that makes the ability to modify and distribute modified varients less
>> interesting?
>
> It's not that it's a less inte
Matthew Garrett <[EMAIL PROTECTED]> writes:
> /why/ those freedoms are no longer necessary. What is it about that code
> that makes the ability to modify and distribute modified varients less
> interesting?
It's not that it's a less interesting problem to create free
firmware. It's just that it
Måns Rullgård <[EMAIL PROTECTED]> wrote:
> A firmware image is not software to the system on which Debian runs.
> What it is to another system (e.g. some PCI card) is irrelevant.
While I disagree, I don't see why we're getting hung up on this software
thing. Note that the only uses of the word "s
Raul Miller <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
> On Wed, Dec 29, 2004 at 03:38:34PM +0100, Marco d'Itri wrote:
>> >Drivers for firmware, where the driver would typically be non-functional
>> >if we didn't ship some non-free software image, we've been treating as
>> >depending on
Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> Matthew Garrett <[EMAIL PROTECTED]> writes:
>> will happily present you with a copy of your system firmware (assuming
>> you're on x86). If you run ndisasm over it, you'll find it's x86 machine
>> code. You can even extract bits of it and run them.
Michael Poole <[EMAIL PROTECTED]> writes:
> A BIOS is normally stored in binary form as executable or
> interpretable code plus associated data. Most people would call
> executable code in binary form "software;" Debian uses a broader
> definition than that. The real question is why you think th
Brian Thomas Sniffen writes:
> Matthew Garrett <[EMAIL PROTECTED]> writes:
>
> > Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> >> Michael Poole <[EMAIL PROTECTED]> writes:
> >>> Lots of people cannot write or modify C code, but we accept as free
> >>> many programs that include C code. The u
Matthew Garrett <[EMAIL PROTECTED]> writes:
> Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
>> Michael Poole <[EMAIL PROTECTED]> writes:
>>> Lots of people cannot write or modify C code, but we accept as free
>>> many programs that include C code. The user being inexpert in some
>>> technique d
> [EMAIL PROTECTED] wrote:
> >The relevant distinction is whether whether or not we consider there to
> >be an adequate abstraction barrier between the two pieces of code.
> >Other distinctions don't really matter.
> Then why you keep talking about where firmware is stored?
Huh?
On Wed, Dec 29,
[EMAIL PROTECTED] wrote:
>The relevant distinction is whether whether or not we consider there to
>be an adequate abstraction barrier between the two pieces of code.
>Other distinctions don't really matter.
Then why you keep talking about where firmware is stored?
>Drivers for firmware, where the
Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> Michael Poole <[EMAIL PROTECTED]> writes:
>> Lots of people cannot write or modify C code, but we accept as free
>> many programs that include C code. The user being inexpert in some
>> technique does not render a thing non-free.
>
> But something
Brian Thomas Sniffen writes:
> Michael Poole <[EMAIL PROTECTED]> writes:
>
> > Brian Thomas Sniffen writes:
> >
> >> Måns Rullgård <[EMAIL PROTECTED]> writes:
> >> >
> >> > You can pull the chip from the socket, copy the contents to disk,
> >> > and
> >>
> >> I probably can't. No good with that
Michael Poole <[EMAIL PROTECTED]> writes:
> Brian Thomas Sniffen writes:
>
>> Måns Rullgård <[EMAIL PROTECTED]> writes:
>> >
>> > You can pull the chip from the socket, copy the contents to disk,
>> > and
>>
>> I probably can't. No good with that sort of thing. Software on disk
>> is software.
On Tue, Dec 28, 2004 at 11:44:54AM -0500, Brian Thomas Sniffen wrote:
> [EMAIL PROTECTED] (Marco d'Itri) writes:
>
> > On Dec 28, Raul Miller <[EMAIL PROTECTED]> wrote:
> >
> >> On Tue, Dec 28, 2004 at 04:26:26PM +1100, Hamish Moffatt wrote:
> >> > Yet the ICQ client is not useful without a compon
[let's see if I can keep from screwing up the formatting on this one.]
On Tue, Dec 28, 2004 at 04:26:59PM -0800, Ken Arromdee wrote:
> I think the scenario "They moved the firmware from a chip to a CD, so we
> can't distribute a driver any more" is ridiculous. Any attempt to modify
> the rules to
On Tue, Dec 28, 2004 at 11:46:19PM +, Matthew Garrett wrote: > It
may be helpful to think of your hard drive as a computer. At that >
point, the firmware is clearly software for the hard drive - it's a
> string of bytes that is executed. The rest of the hard drive is >
hardware. If something is
On Tue, 28 Dec 2004, Brian Thomas Sniffen wrote:
> > But that's a strange reason to require that the firmware blob on CD be free.
> > It's essentially saying "if you can make it hard to modify the firmware,
> > you don't need to allow modifications at all".
> As always, intent matters.
But most pe
On Tue, 28 Dec 2004, Brian Thomas Sniffen wrote:
> I probably can't. No good with that sort of thing. Software on disk
> is software. Also, I could pull the Pentium off my motherboard, scan
> its contents to disk, and open that in any editor I like -- right?
So if a BIOS can be scanned by a pr
Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> Måns Rullgård <[EMAIL PROTECTED]> writes:
>> You can pull the chip from the socket, copy the contents to disk,
>> and
>
> I probably can't. No good with that sort of thing. Software on disk
> is software. Also, I could pull the Pentium off my m
Brian Thomas Sniffen writes:
> Måns Rullgård <[EMAIL PROTECTED]> writes:
> >
> > You can pull the chip from the socket, copy the contents to disk,
> > and
>
> I probably can't. No good with that sort of thing. Software on disk
> is software. Also, I could pull the Pentium off my motherboard, s
Måns Rullgård <[EMAIL PROTECTED]> writes:
> Brian Thomas Sniffen <[EMAIL PROTECTED]> writes:
>
>>> Can a company release an encrypted CD, so that it's as difficult to
>>> modify the firmware on CD as it is in a chip, and then have it
>>> count as part of the hardware?
>>
>> No, that's not hardware
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes:
>> Can a company release an encrypted CD, so that it's as difficult to
>> modify the firmware on CD as it is in a chip, and then have it
>> count as part of the hardware?
>
> No, that's not hardware. That's an encrypted CD. That, and the DRM
> app
Ken Arromdee <[EMAIL PROTECTED]> writes:
>> * The firmware blob on CD, if free, can be easily modified by end
>> users. It's just software. Even given the preferred form for
>> modification, it's much more difficult to re-flash a firmware chip
>> on hardware not designed for regular firmwa
Raul Miller <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 28, 2004 at 04:58:52PM +, Matthew Garrett wrote:
>> to support this. The obvious thing to do here is not to attempt to find
>> a way that we can interpret the SC that makes sense - the obvious thing
>> to do here is to decide what we want the
On Tue, 28 Dec 2004, Brian Thomas Sniffen wrote:
> That said, or not, I do think there's a significant practical
> difference between firmware which ships as software, say on a CD
> accompanying the device, and firmware which ships on the device:
>
> * The firmware on the CD is typically not redis
Matthew Garrett <[EMAIL PROTECTED]> writes:
> Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
>
>> I don't believe policy or the SC does expand on what "requires"
>> means. This is the only self-consistent explanation I've seen which
>> allows Debian to ship a usable OS. Have you another?
>
> Th
On Tue, Dec 28, 2004 at 04:58:52PM +, Matthew Garrett wrote:
> to support this. The obvious thing to do here is not to attempt to find
> a way that we can interpret the SC that makes sense - the obvious thing
> to do here is to decide what we want the SC to say and then change it so
Fundamenta
Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> I don't believe policy or the SC does expand on what "requires"
> means. This is the only self-consistent explanation I've seen which
> allows Debian to ship a usable OS. Have you another?
The parsimonious explanation is that the issue wasn't th
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Dec 25, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
>
>> > Yet, CF is actually chips --- often the same chips as used to hold
>> > firmware distributed with hardware. Thus, it's all hardware.
>> Sure. It's on a medium for software exchange, thus i
[EMAIL PROTECTED] (Marco d'Itri) writes:
> On Dec 28, Raul Miller <[EMAIL PROTECTED]> wrote:
>
>> On Tue, Dec 28, 2004 at 04:26:26PM +1100, Hamish Moffatt wrote:
>> > Yet the ICQ client is not useful without a component which is not in
>> > Debian and in fact is not freely available.
>> Same thing
On Dec 28, Raul Miller <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 28, 2004 at 04:26:26PM +1100, Hamish Moffatt wrote:
> > Yet the ICQ client is not useful without a component which is not in
> > Debian and in fact is not freely available.
> Same thing applies to hardware drivers. And, for that matt
On Dec 25, Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> > Yet, CF is actually chips --- often the same chips as used to hold
> > firmware distributed with hardware. Thus, it's all hardware.
> Sure. It's on a medium for software exchange, thus it's software. If
> it were an integral componen
On Tue, Dec 28, 2004 at 04:26:26PM +1100, Hamish Moffatt wrote:
> Yet the ICQ client is not useful without a component which is not in
> Debian and in fact is not freely available.
Nor is a driver useful without a piece of hardware which isn't in
Debian.
Of course, license permitting, Debian *cou
On Tue, Dec 28, 2004 at 04:26:26PM +1100, Hamish Moffatt wrote:
> Yet the ICQ client is not useful without a component which is not in
> Debian and in fact is not freely available.
Same thing applies to hardware drivers. And, for that matter, all of
the kernel.
--
Raul
On Mon, Dec 27, 2004 at 09:45:32PM -0500, Glenn Maynard wrote:
> Right: some emulators are fairly useless without some kind of image (eg. a
> BIOS image), just as some drivers are fairly useless without some kind of
> image (eg. a firmware blob). If all of the pieces were packaged, foo-driver
> wo
On Tue, Dec 28, 2004 at 12:48:14AM +, Benjamin A'Lee wrote:
> On Tue, Dec 28, 2004 at 11:06:53AM +1100 or thereabouts, Hamish Moffatt wrote:
> > Yes, of course. So, we could technically distribute ROMs for atari800 if
> > we found some that met the DFSG, and then we could move atari800 to
> >
On Tue, Dec 28, 2004 at 11:06:53AM +1100 or thereabouts, Hamish Moffatt wrote:
> Yes, of course. So, we could technically distribute ROMs for atari800 if
> we found some that met the DFSG, and then we could move atari800 to
> main. We could technically distribute an ICQ server if we had one that
>
On Sun, Dec 26, 2004 at 09:22:42PM -0500, Brian Thomas Sniffen wrote:
> Hamish Moffatt <[EMAIL PROTECTED]> writes:
> > I think there are parallels with other software in Debian where we have
> > not been so forgiving. We have a number of emulators for game consoles
> > that are packaged and current
Måns Rullgård <[EMAIL PROTECTED]> writes:
> Brian Thomas Sniffen <[EMAIL PROTECTED]> writes:
>
>> Anthony DeRobertis <[EMAIL PROTECTED]> writes:
>>
>>> Brian Thomas Sniffen wrote:
That's not software. That's firmware, at best -- you can look at it
as software, but then you don't get to
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> On Sat, Dec 25, 2004 at 04:08:38PM -0500, Brian Thomas Sniffen wrote:
>> Hamish Moffatt <[EMAIL PROTECTED]> writes:
>> > Eh? The contents of EEPROMs are software just as much as the contents of
>> > CD-ROMs and hard disks. They are just different media
Brian Thomas Sniffen <[EMAIL PROTECTED]> writes:
> Anthony DeRobertis <[EMAIL PROTECTED]> writes:
>
>> Brian Thomas Sniffen wrote:
>>> That's not software. That's firmware, at best -- you can look at it
>>> as software, but then you don't get to distribute any drivers. It is
>>> also internally
On Sat, Dec 25, 2004 at 04:08:38PM -0500, Brian Thomas Sniffen wrote:
> Hamish Moffatt <[EMAIL PROTECTED]> writes:
> > Eh? The contents of EEPROMs are software just as much as the contents of
> > CD-ROMs and hard disks. They are just different media for storing
> > digital information.
> >
> You ca
1 - 100 of 164 matches
Mail list logo
