On Mon, Jan 10, 2005 at 10:14:02AM -0800, Ben Pfaff wrote:
> I bet that, with some of these firmware blobs, we could
> reverse-engineer and "clean room" clone them in a country with
> permissive reverse engineering laws. At that point, we'd have
> something that was definitely free.
>
> Anyone in
[EMAIL PROTECTED] wrote:
>I bet that, with some of these firmware blobs, we could
>reverse-engineer and "clean room" clone them in a country with
>permissive reverse engineering laws. At that point, we'd have
>something that was definitely free.
I bet you could not, for interesting devices (DVB r
I bet that, with some of these firmware blobs, we could
reverse-engineer and "clean room" clone them in a country with
permissive reverse engineering laws. At that point, we'd have
something that was definitely free.
Anyone interested in trying?
--
"While the Melissa license is a bit unclear, Me
Get a legal college degree Instantly:
Here's the ultimate solution for anybody who needs to get a degree instantly
with no
attendance requirements or hassle of any kind. Get recognition for your
experience. Give us
a call @ 1.206.666.6485
narrate initiate torture actinium pixel acadia eigenst
[EMAIL PROTECTED] wrote:
>True enough. I have a harder time justifying to myself keeping such drivers
>in main, but I also think that the infrastructure needed in order to support
>grabbing firmware out of non-free (for things like the installer) could
>easily work for the case of contrib driver
[EMAIL PROTECTED] wrote:
>Being in contrib doesn't mean that a work is evil, nor is contrib a
>second cousin to non-free.
It means that something is not part of debian and is not acceptable for
install media, which looks like a big enough problem to me.
It would be silly to be able to move a driv
[EMAIL PROTECTED] wrote:
>On Sun, Jan 09, 2005 at 03:22:45PM +0100, Martin Schulze wrote:
>> The larger problem is to identify non-free blobs in the main kernel,
>> extract them into non-free and modify the driver so that it is able
>> to load the blob from a user provided location; and include th
On Mon, Jan 10, 2005 at 05:35:59PM +, Steve McIntyre wrote:
> Andrew Suffield writes:
> >
> >On Sun, Jan 09, 2005 at 07:51:58PM +, Matthew Garrett wrote:
> >> > You also need to turn this question around and ask it the other way:
> >> > does having these drivers in contrib actually hurt any
Op ma, 10-01-2005 te 16:58 +, schreef Andrew Suffield:
> On Sun, Jan 09, 2005 at 07:51:58PM +, Matthew Garrett wrote:
> > > You also need to turn this question around and ask it the other way:
> > > does having these drivers in contrib actually hurt anything?
> >
> > Yes. It currently mean
Craig Sanders dijo [Sun, Jan 09, 2005 at 05:28:23PM +1100]:
> it's worse than just putting them in contrib. there's a whole bunch of
> drivers with firmware blobs that have just been deleted from the kernel
> sources. they're not in contrib, they're not in non-free, they're just gone.
>
> this a
Andrew Suffield writes:
>
>On Sun, Jan 09, 2005 at 07:51:58PM +, Matthew Garrett wrote:
>> > You also need to turn this question around and ask it the other way:
>> > does having these drivers in contrib actually hurt anything?
>>
>> Yes. It currently means that we can't ship an installer with
On Sun, Jan 09, 2005 at 07:51:58PM +, Matthew Garrett wrote:
> > You also need to turn this question around and ask it the other way:
> > does having these drivers in contrib actually hurt anything?
>
> Yes. It currently means that we can't ship an installer with support for
> this hardware, b
On Sun, Jan 09, 2005 at 03:21:40AM +, Matthew Garrett wrote:
> Steve Langasek <[EMAIL PROTECTED]> wrote:
> > I don't think I have a problem, conceptually, with a kernel package which
> > provides drivers for 10,000 different types of hardware, and needs to load
> > firmware from disk for 300 o
13 matches
Mail list logo
