[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: more evil firmwares found

#include <hallo.h>
* Nathanael Nerode [Thu, Apr 15 2004, 01:48:05PM]:

> >LOL. You just indicated that you don't know what you are talking about.
> >The "winmodems" are indeed bad hardware, they don't upload the firmware
> >into the device but do everything in the driver. Almost off-topic here.
> So they do their computation in a 486 rather than in a DSP.  From the 
> point of view of freedom, what's the *difference*?

Perhaps that the sorce code for the most winmodem drivers is not
available? They do the real work in the host CPU. In difference to the
case that we discuss all the time: free distributable and modifiable
data chunks uploaded to a device, while the device itself works autonom.

> >>>No. I think you are blinded after fighting the evil non-free software,
> >>>so much that you don't see the limits of feasibility.
> >>
> >>And I think you're seeing the limits of feasibility where they aren't.
> >
> >
> >The limits are there. You just dreamed that you can force hardware
> >vendors to share their IP, giving away things they need to earn the
> >money to survive. But now it's time to wake up.
> Um, people said the same thing about software vendors when saying that 
> free software was an impossibility.
> Anyway, I'm not trying to "force" anyone to to anything.  I'm saying 

A-Ha. "Not trying to force" like "Debian and Redhat had nothing to do
with the process of making Qt GPLed software, a while ago".

Did you write the excuse for the installation manual already? What are
you going to tell the users? You are not allowed to install via network
because your network driver is not free for for us (though for the rest
of the world).

> that it is feasible to have a Debian system which requires no firmware 
> downloads, and I provided proof.  You're saying that... something... is 

I do not talk about feasible things but about sensible.

> >>As what?
> >
> >
> >As above. You construct the examples or construct explanations to make
> >them look non-DSFG-free. By ignoring explanations that tell you
> >something different.
> OK, now you're just being rude.  I haven't ignored anything; I find 
> those "explanations" extremely unconvincing, and I've explained why.

Your explanations are not convincing (for me) either, so just accept it.
Nothing will become more convincing by repeating it again and again in a
public forum.

> >They are. As long as you cannot *proove* that they are not the preferred
> >for of modification (and this can be very hard since Linux driver
> >developers never modify it), don't claim that they are not DSFG-free.
> It's already been pointed out by others that you've put the burden of 
> proof on the wrong side from a legal point of view, and from the point 
> of view of the traditional methods of DFSG-interpretation; the logical 

I would care more when making such claims, it sounds somehow like the
smore spread by a three-letter company suing IBM.

> Anyway, what about blobs which are *not* even apparently GPL-licensed? 

I though they have been removed from the Debian kernel source months

> I've found those in the kernel sources too.  Would you at least agree 
> that those had better go?

If they license is explicitely GPL-incompatible, yes.

Ich wollte den Ball treffen, aber der Ball war nicht da.
		-- Anthony Yeboah (er hatte gegen Michael Schulz nachgetreten)

Reply to: