On Fri, Dec 17, 2004 at 09:39:46AM +, Matthew Garrett wrote:
> Glenn Maynard <[EMAIL PROTECTED]> wrote:
> > On Fri, Dec 17, 2004 at 02:37:45AM +, Matthew Garrett wrote:
> >> Glenn Maynard <[EMAIL PROTECTED]> wrote:
> >>
> >> > No, there's a very concrete reason: given an installation of De
On Thu, Dec 16, 2004 at 06:29:46PM -0500, Glenn Maynard wrote:
> On Thu, Dec 16, 2004 at 12:02:30AM +, Jonathan McDowell wrote:
> > If we refuse to handle non-free firmware being loaded onto devices and
> > require they come with it already inside then we get to play the "I
> > can't see it, it
Glenn Maynard <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 17, 2004 at 02:37:45AM +, Matthew Garrett wrote:
>> Glenn Maynard <[EMAIL PROTECTED]> wrote:
>>
>> > No, there's a very concrete reason: given an installation of Debian
>> > main, the driver works. Drivers that require non-free firmware d
Glenn Maynard <[EMAIL PROTECTED]> wrote:
> On Thu, Dec 16, 2004 at 10:51:39AM +0100, Frank Küster wrote:
>> When the issue of binary blobs in the kernel was first discussed here,
>> if I'm not mistaken the proposed solution was to rewrite the respective
>> drivers to be able to load the blob at ru
Glenn Maynard wrote:
Hmm. A few places to draw the "dependency from driver to firmware"
line seem to be:
1: a dependency exists if the driver needs access to a copy of the firmware
(for devices that need the firmware uploaded on every boot);
2: a dependency exists if the hardware needs firmware at
On Fri, Dec 17, 2004 at 02:37:45AM +, Matthew Garrett wrote:
> Glenn Maynard <[EMAIL PROTECTED]> wrote:
>
> > No, there's a very concrete reason: given an installation of Debian
> > main, the driver works. Drivers that require non-free firmware don't
> > work out of the box;
>
> The vast, v
Glenn Maynard <[EMAIL PROTECTED]> wrote:
> No, there's a very concrete reason: given an installation of Debian
> main, the driver works. Drivers that require non-free firmware don't
> work out of the box;
The vast, vast majority of drivers require non-free firmware.
> Your sarcasm and condesce
On Thu, Dec 16, 2004 at 10:51:39AM +0100, Frank Küster wrote:
> When the issue of binary blobs in the kernel was first discussed here,
> if I'm not mistaken the proposed solution was to rewrite the respective
> drivers to be able to load the blob at runtime from "somewhere", and
> that somewhere wo
On Thu, Dec 16, 2004 at 12:02:30AM +, Jonathan McDowell wrote:
> If we refuse to handle non-free firmware being loaded onto devices and
> require they come with it already inside then we get to play the "I
> can't see it, it doesn't matter" game, which gives the purists a warm
> fuzzy feeling,
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> On Tue, 14 Dec 2004 14:21:54 +0100, Simon Richter <[EMAIL PROTECTED]> said:
>
>> Hi,
>>> It's fine for software in main to be able to do stuff with non-free
>>> data; that's not the issue. The question is whether there *exists*
>>> any free data that
On Wed, Dec 15, 2004 at 11:33:30PM +, Matthew Garrett wrote:
> Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> > Well, if you need the non-free component to be on the file
> > system, why is this different from contrib? Why can't say of
> > everything in contrib that well, if the non-free
Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Well, if you need the non-free component to be on the file
> system, why is this different from contrib? Why can't say of
> everything in contrib that well, if the non-free jvm were to
> magically appear on the file system this java code woul
On Tue, 14 Dec 2004 14:21:54 +0100, Simon Richter <[EMAIL PROTECTED]> said:
> Hi,
>> It's fine for software in main to be able to do stuff with non-free
>> data; that's not the issue. The question is whether there *exists*
>> any free data that it works with, and if not, whether that's a
>> prob
Hi,
It's fine for software in main to be able to do stuff with non-free
data; that's not the issue. The question is whether there *exists* any free
data that it works with, and if not, whether that's a problem.
I don't believe that is a problem. We don't ship the non-free data, we
just allow its
Frank Küster <[EMAIL PROTECTED]> wrote:
> P.S. Shouldn't this be moved to -legal?
No. -legal is useful for determining whether a given piece of code meets
the DFSG or not. It doesn't make policy decisions. -project is a better
place for non-technical discussion of this sort of thing.
--
Matthew
On Tue, Dec 14, 2004 at 10:58:52AM +0100, Tollef Fog Heen wrote:
> * Simon Richter
>
> | > (If the firmware used by this tool really is Free Software, my
> | > apologies. However, in that case, the firmware still does not appear to
> | > be available in Debian.)
> |
> | The tool is generic, hen
Simon Richter <[EMAIL PROTECTED]> wrote:
> Hi,
>
[quoting Josh Triplett]
>> Package: misdn-utils
>> Version: 0.0.0+cvs20041018-4
>> Severity: serious
>
>> misdn-utils contains a utility "loadfirm", for loading firmware onto
>> ISDN devices. Unless this firmware is Free Software with source, whic
* Simon Richter
| > (If the firmware used by this tool really is Free Software, my
| > apologies. However, in that case, the firmware still does not appear to
| > be available in Debian.)
|
| The tool is generic, hence I cannot make any assumptions on the
| freeness of any firmware that may be
Hi,
Package: misdn-utils
Version: 0.0.0+cvs20041018-4
Severity: serious
misdn-utils contains a utility "loadfirm", for loading firmware onto
ISDN devices. Unless this firmware is Free Software with source, which
did not appear to be the case after a large amount of searching, this
utility should
19 matches
Mail list logo
