Re: Debian sponsoring Chinese companies?

2005-01-08 Thread Santiago Vila
On Fri, 7 Jan 2005, Chris Waters wrote:

> The Debian project itself provides advertising opportunities through
> its mailing lists and bug tracking system, though, so one could argue
> that there is ample precedent. :)

Actually, the BTS and the lists are handled very differently.
The crap is usually removed from the BTS as soon as it's detected.
I wish we did the same for the lists archives.



Re: Debian sponsoring Chinese companies?

2005-01-08 Thread Michelle Konzack
Am 2005-01-08 12:13:43, schrieb Santiago Vila:

> Actually, the BTS and the lists are handled very differently.
> The crap is usually removed from the BTS as soon as it's detected.
> I wish we did the same for the lists archives.

I am subscribed to more then 70 Mailinglists since 2000 and
gotten more then 140.000 Spams via Debian in this time...

Per day around 1.1 SPAM and list

I think a real-clenup will be nice...

Greetings
Michelle

-- 
Linux-User #280138 with the Linux Counter, http://counter.li.org/ 
Michelle Konzack   Apt. 917  ICQ #328449886
   50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature


Dealing with drivers that need firmware on the filesystem

2005-01-08 Thread Matthew Garrett
It's becomingly increasingly common for hardware to require firmware to
be loaded by the device driver on boot, rather than containing it in
ROM. This is unfortunate, because in most cases the firmware is
non-free. As a result, a naive application of policy suggests that
drivers which require this firmware should appear in contrib.

This causes two problems. The first is practical - there's currently no
way that we can provide these drivers on the install media. The second
is philosophical - we effectively penalise drivers that require their
non-free firmware to appear on the filesystem rather than in a piece of
flash.

The free/non-free distinction was made because we felt that people
should use free software rather than non-free software when available.
In cases where there was no free alternative, failing to provide the
non-free version would encourage the development of a free one.
Irritating for the user, but good for free software. Fair enough.

In the firmware case, the choice is rather different. At present, the
choice is not between free firmware or non-free firmware. The choice is
between non-free firmware on disk or non-free firmware in ROM. Putting
drivers in contrib penalises the former, and as a result implicitly
encourages the latter.

So, a couple of questions:

a) Does having these drivers in contrib benefit either (i) our users, or
(ii) free software? (Bear in mind again that removing these drivers from
main doesn't encourage people to write free firmware, it encourages them
to buy hardware that has firmware in flash. Ironically, it therefore
becomes harder to produce free firmware...)

b) If not, what's the correct approach?

We /could/ put non-free firmware in main, on the grounds that while it
is in many cases executable code, it does not execute on any processor
that is under the direct control of the operating system. This would
possibly require a small alteration to the social contract. A result of
this would be that not everything in main would be DFSG free.

An alternative would be to leave non-free firmware in non-free, but not
to enforce the requirement that drivers depending on it end up in
contrib. This is possibly the most straight forward, and by squinting
funny we could possibly even argue that the social contract already
allows this.

A third possibility would be to create a new section for material that
is non-free but whose freeness we don't really care about. Drivers in
main would be allowed to depend on this, and we'd include it on the
install media. This would require changing the social contract.

The firmware situation now is similar to the free software situation in
the early 80s. Back then, free software depended on the existence of
proprietary code. It still does now, but the proprietary code has moved
further down the stack. I think it's entirely justifiable to try to
sever that dependence in the future, but we can't do it now. Trying
would be equivalent to trying to ship an entirely free distribution in
1985 - we have some free components, but there's no free versions of
their dependencies.

Until we've actually made a start on removing that dependency, I think
it's unreasonable to punish our users over it.
-- 
Matthew Garrett | [EMAIL PROTECTED]



Re: Dealing with drivers that need firmware on the filesystem

2005-01-08 Thread Steve Langasek
On Sun, Jan 09, 2005 at 02:36:03AM +, Matthew Garrett wrote:

> An alternative would be to leave non-free firmware in non-free, but not
> to enforce the requirement that drivers depending on it end up in
> contrib. This is possibly the most straight forward, and by squinting
> funny we could possibly even argue that the social contract already
> allows this.

I believe this is our best option.  AIUI, in many cases we don't have any
license to redistribute the firmware anyway, so the support mechanisms need
to be there regardless; at which point there doesn't even seem to be a
strong convenience argument for distributing such firmware in main, even if
people accepted that convenience was sufficient rationale.

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 of them, being in main (without a
Depends:/Recommends: relationship on the firmware-providing packages).

-- 
Steve Langasek
postmodern programmer


signature.asc
Description: Digital signature


Re: Dealing with drivers that need firmware on the filesystem

2005-01-08 Thread Matthew Garrett
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 of them, being in main (without a
> Depends:/Recommends: relationship on the firmware-providing packages).

That doesn't quite solve the problem of drivers outside the main kernel
tree. This is the case for a large amount of current wireless hardware,
irritatingly.
-- 
Matthew Garrett | [EMAIL PROTECTED]