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

Re: [DRAFT] resolving DFSG violations



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).

Your reply doesn't add any useful feedback that could contribute to improving
the GR text.  Please note that the purpose of this thread is not discussing
whether you agree with the GR or not, but providing useful feedback so that it
can be found acceptable by more people.  I can't see any specific suggestion of
this kind in your mail.  Please take this into account in future replies.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."


Reply to: