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

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.
> 
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=502508
> 
> 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
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net


Reply to: