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 nee
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
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 me
* 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
I'd like to ask if this license is DFSG approved?
http://public.perforce.com:8080/%40md=d&cd=//public/revml/&cdf=//public/revml/LICENSE&ra=s&sr=628&c=bMZ%40//public/revml/LICENSE
Copyright (c) 2000, 2001, Perforce Software, Inc.
All rights reserved.
Redistribution and use in s
[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
[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
softwar
* 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 On
[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 har
[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 wit
[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
[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
>>(oth
"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 FP
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 anythin
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 kn
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 ar
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 operate
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'
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
> > copyr
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 tha
> 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:
> [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
> [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
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 r
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 th
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. T
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 cu
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
> >
> 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
[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:
>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,
[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 "d
[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 of
> 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 i
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
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, th
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
Raul Miller writes:
> > In my day job, I work on a device driver that can talk to a device
> > programmed using several different firmwares. Other drivers I have
> > worked on can downloaded firmware but the boards also have EEPROMs
> > that hold default firmwares. Importantly, the drivers do no
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, whil
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 comple
> > 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
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, 2
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 unsu
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 the
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.
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 satis
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 belie
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
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 every
> 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 tha
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 firm
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
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 do
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 wou
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
/usr/share/common-licen
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 discu
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
"Marco d'Itri" <[EMAIL PROTECTED]> writes:
> [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
Matthew Garrett <[EMAIL PROTECTED]> writes:
> 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 functio
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
"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
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
73 matches
Mail list logo
