Re: [DRAFT] resolving DFSG violations
On Tue, Oct 21, 2008 at 06:48:16PM +0200, Robert Millan wrote:
> On Tue, Oct 21, 2008 at 05:47:58PM +0200, Pierre Habouzit wrote:
> > Though, when this software is central to all Debian (as the kernel is,
> > or the glibc for the sunrpc issue, or mesa for the GLX code, or ...),
> > then as it's a long and slow work to either prune the firmware, or deal
> > with the copyright holders to relicense (and mesa has made it, proof
> > that it's possible, but it needed like 2 or 3 releases of Debian to do
> > so !), the Release team acknowledge that progress has been made, and
> > tags the bugs $suite-ignore.
> So, I take it you will vote "Further discussion".
> > > At this time (and I believe, in part due to historical reasons), the release
> > > team has made it clear that it is not their responsibility to enforce the SC.
> > Why on earth should it be the Release Team ? It's everyone's.
> Then I guess you'll like that my proposal has two options that move the problem
> away from the Release Team.
> > Your proposal misses the point. DFSG wrt firmwares is a hard issue, and
> > your black-and-white vision of it isn't adapted. The 60-days or move the
> > package to non-free would move the glibc and portmap as is to non-free.
> > Good luck with that. (Just to show how impractical it is).
> You haven't proven that it is, you only assert it. Discussing whether it is
> or not is off-topic here. If you think so strongly this way, there are two
> options in my proposal to exclude Lenny for firmware, and you could also
> propose another GR to remove SC #1 (good luck).
> > * firmwares are part of the hardware, even your CPU has microcode.
> The combination of firmware and driver can perfectly constitue a "derived
> work", but that's not the point. The question is that we're promising the
> contents of linux-2.6 package are 100% free.
> > You
> > don't have the source code that generated the circuits of that
> > hardware,
> The circuits of my hardware have nothing to do with the Social Contract.
> > [...]. Here you could modify source,
> > big deal, you won't be able to *build* the damn firmware. ever.
> And if there are no tools, we just drop the driver untill someone's willing to
> add a /lib/firmware/ blob loader. Which will no doubt be done really soon by
> anyone who's actually interested in supporting non-free stuff (unlike myself).
| 4. Our priorities are our users and free software
| We will be guided by *the needs of our users* and the free software
| community. We will place their interests *first in our priorities*. We
| will support the needs of our users for operation in many different
| kinds of computing environments. [...]
Dropping support for already supported hardware more likely violate
SC#4. Moving the firmware to /lib/firmware/ doesn't.
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' email@example.com | firstname.lastname@example.org
`- people.debian.org/~aurel32 | www.aurel32.net