[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 RO
"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 abo
[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 a
Michael Poole wrote:
> Glenn Maynard writes:
>>The firmware has the nature of data being sent to the remote server.
>>It's being acted on by the hardware, but it's also being manipulated
>>and transferred by the driver. If you don't have the firmware to send
>>to the server (hardware), neither the
Michael Poole a écrit :
Or maybe he didn't understand what you were talking about because you
were using jargon peculiarly. Most people use "boot loader" to refer
to the stub loaded from disk that starts in real mode and loads the
kernel. Most people use "BIOS" to refer to software that, in pa
On Fri, Oct 29, 2004 at 08:58:11AM -0400, Michael Poole wrote:
> Someone might implement a good free synthesis and place-and-route
> toolchain; assuming the major EDA and FPGA vendors do not sue the
> developers for patent infringement, it might only take 5 or 10 years
> to make it support a reason
On Fri, Oct 29, 2004 at 10:38:03AM -0400, Michael Poole wrote:
> While I'm ranting on definitions, I wish others (Glenn) would stop
> using "EPROM" when they mean something else. Few, if any, consumer
> electronics, and probably no motherboards, use an EPROM to hold
> program or firmware data. Go
Please try to space out your quoting like everyone else does, so your mails
are readable.
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
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
> 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), whic
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 n
[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
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
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
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
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
> > seve
> >
> > 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
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 co
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 t
On Thu, Oct 28, 2004 at 01:29:25PM -0400, Michael Poole wrote:
> Operations over an asynchronous medium -- like TCP or PCI -- are quite
> different. The GPL, for example, is very specific about its reach.
> We should only use broader definitions than the license(s) with good
> reason.
Please don'
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 do
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
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 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, Andre
* 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 u
* 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
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 unme
* 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 bec
> > 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 ha
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
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
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 t
* 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
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 th
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 actua
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 someth
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 implementatio
> > 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 premi
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 th
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.
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.
Eve
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 th
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.
>>
>>
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 comp
[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 user
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
"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
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
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 obse
But the functionality of the driver is a function of the functionality
of the device.
--
Brian Sniffen [EMAIL PROTECTED]
[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 comple
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
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 inc
[EMAIL PROTECTED] wrote:
>Perhaps then you can provide an example of what the driver can do in a
>world where all the Windows driver-CDs have vanished, and there is
>only a device plaintively calling out for a firmware download in my
>machine. Can the driver do anything?
Uploading or not uploadin
> [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 o
"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
>>(oth
[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:
>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 h
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 mes
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 f
[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. Also, for some drivers there can be no package at all
providing the firmwa
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 inter
[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 fir
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
>>li
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.
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 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
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 w
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 wher
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:
> http
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
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 m
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]>
[ 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 deci
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
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
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
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
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
[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
--- Begin Message ---
Thanks for your answer, I have a mail from one of the developper of this
software :
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 licen
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 the eagle-us
-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 eag
83 matches
Mail list logo