[DRAFT] resolving DFSG violations

classic Classic list List threaded Threaded
69 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

[DRAFT] resolving DFSG violations

Robert Millan

[ This is a DRAFT, only intended to get feedback.  Do not second yet! ]

Hi,

Personal opinion, not part of the GR
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

In the past few days, it's become obvious (see discussion in -devel) that
our existing control structures are not effective at enforcing rule #1 of
the Social Contract.  SC #1 states that Debian is 100% free, but it doesn't
specify how this is supposed to be enforced.

Traditionally, we have assumed good will, and specially cooperation from
the release team; DFSG violations were considered "Release Critical" bugs
and therefore every one of them would have to be fixed before release.

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.
On one hand, one could consider that this falls short of compliing with the
goals of the project, but on the other, it's not fair that a problem that
belongs to Debian as a whole is put onto the release team to enforce, at
the expense that their hard work doesn't archieve the results they intended
(i.e. release in time).

My proposal will be, that since the problem belongs to the project as a whole,
we make it the responsibility of every developer to ensure DFSG compliance in
packages that are already part of the Debian archive.

There are four options, which reflect two orthogonal binary choices:

  - Whether to make this resolution become part of the SC or not.

  - Whether to provide exceptions that would allow Lenny to release sooner.


Option 1 (set an upper limit)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The developers resolve that:

When ever a package in Debian is found to have been violating the DFSG for
60 days or more, and none of the solutions that have been implemented (if
any) is considered suitable by the maintainers, the package must be moved
from Debian ("main" suite) to the Non-free repository ("non-free" suite).

The action of moving it may be performed by any of the developers.  When
this happens, any known DFSG violation in the package must be resolved
before the package can be moved back into Debian.

(Since this option does not contradict SC #1, I believe it would only require
simple majority;  please correct me if I'm wrong)

Option 2 (set an upper limit, make this part of the SC)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The developers resolve that the Social Contract shall be ammended as follows:

--- social_contract.wml 22 Nov 2007 03:15:39 -0000      1.23
+++ social_contract.wml 21 Oct 2008 14:37:17 -0000
@@ -31,6 +31,23 @@ the free software community as the basis
          free and non-free works on Debian. We will never make the
          system require the use of a non-free component.
        </p>
+       <p>
+         In order to ensure continued compliance with this promise, the
+         following rule is to be followed:
+       </p>
+       <p>
+         When ever a package in Debian is found to have been violating the
+         Debian Free Software Guidelines for 60 days or more, and
+         none of the solutions that have been implemented (if any) is considered
+         suitable by the maintainers, the package must be moved from Debian
+         ("main" suite) to the Non-free repository ("non-free" suite).
+       </p>
+       <p>
+         The action of moving it may be performed by any of the developers.
+         When this happens, any known violation of the Debian Free Software Guidelines
+         in the package must be resolved before the package can be moved back into
+         Debian.
+       </p>
       </li>
       <li><strong>We will give back to the free software community</strong>
        <p>

(Since this option ammends the SC, I believe it would require 3:1 majority)


Option 3 (set an upper limit, allow lenny to release with propietary firmware)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The developers resolve that the following rule shall take effect inmediately
after Lenny is released:

  When ever a package in Debian is found to have been violating the DFSG for
  60 days or more, and none of the solutions that have been implemented (if
  any) is considered suitable by the maintainers, the package must be moved
  from Debian ("main" suite) to the Non-free repository ("non-free" suite).

  The action of moving it may be performed by any of the developers.  When
  this happens, any known DFSG violation in the package must be resolved
  before the package can be moved back into Debian.

In addition:

   1. We affirm that our Priorities are our users and the free software
      community (Social Contract #4);

   2. We acknowledge that there is a lot of progress in the kernel firmware
      issue; however, it is not yet finally sorted out;

   3. We assure the community that there will be no regressions in the progress
      made for freedom in the kernel distributed by Debian relative to the Etch
      release in Lenny

   4. We give priority to the timely release of Lenny over sorting every bit
      out; for this reason, we will treat removal of sourceless firmware as a
      best-effort process, and deliver firmware in udebs as long as it is
      necessary for installation (like all udebs), and firmware included in
      the kernel itself as part of Debian Lenny, as long as we are legally
      allowed to do so, and the firmware is distributed upstream under a
      license that complies with the DFSG.

(Since this option overrides the SC, I believe it would require 3:1 majority)


Option 4 (set an upper limit, make this part of the SC, allow lenny to release with propietary firmware)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The developers resolve that, inmediately after Lenny is released, the Social
Contract shall be ammended as follows:

--- social_contract.wml 22 Nov 2007 03:15:39 -0000      1.23
+++ social_contract.wml 21 Oct 2008 14:37:17 -0000
@@ -31,6 +31,23 @@ the free software community as the basis
          free and non-free works on Debian. We will never make the
          system require the use of a non-free component.
        </p>
+       <p>
+         In order to ensure continued compliance with this promise, the
+         following rule is to be followed:
+       </p>
+       <p>
+         When ever a package in Debian is found to have been violating the
+         Debian Free Software Guidelines for 60 days or more, and
+         none of the solutions that have been implemented (if any) is considered
+         suitable by the maintainers, the package must be moved from Debian
+         ("main" suite) to the Non-free repository ("non-free" suite).
+       </p>
+       <p>
+         The action of moving it may be performed by any of the developers.
+         When this happens, any known violation of the Debian Free Software Guidelines
+         in the package must be resolved before the package can be moved back into
+         Debian.
+       </p>
       </li>
       <li><strong>We will give back to the free software community</strong>
        <p>

In addition:

   1. We affirm that our Priorities are our users and the free software
      community (Social Contract #4);

   2. We acknowledge that there is a lot of progress in the kernel firmware
      issue; however, it is not yet finally sorted out;

   3. We assure the community that there will be no regressions in the progress
      made for freedom in the kernel distributed by Debian relative to the Etch
      release in Lenny

   4. We give priority to the timely release of Lenny over sorting every bit
      out; for this reason, we will treat removal of sourceless firmware as a
      best-effort process, and deliver firmware in udebs as long as it is
      necessary for installation (like all udebs), and firmware included in
      the kernel itself as part of Debian Lenny, as long as we are legally
      allowed to do so, and the firmware is distributed upstream under a
      license that complies with the DFSG.

(Since this option ammends the SC, I believe it would require 3:1 majority)

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


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

madcoder (Bugzilla)
On Tue, Oct 21, 2008 at 02:52:42PM +0000, Robert Millan wrote:
> Traditionally, we have assumed good will, and specially cooperation from
> the release team; DFSG violations were considered "Release Critical" bugs
> and therefore every one of them would have to be fixed before release.

There are two kind of Release Critical bugs. The ones that affect the
usability of a software (independently of any religious issues wrt its
licenses and the blobs it contains), and the one due to incompatibility
with the Debian Policy or the DFSG or similar (the religious issues).

The bugs from the former kind are seldomly tagged lenny-ignore (if it's
appropriate, they are downgraded, or fixed, or the package is removed).
The latter kind, if it's practical, leads to a move to non-free or
contrib, or leads to removals.

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.


> 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. The
Release Team tries to ... wait for it... release. I explained what is my
(and I believe other RElease Team members) rationale wrt how "fixing" or
"ignoring" bugs above.


> There are four options, which reflect two orthogonal binary choices:
>
>   - Whether to make this resolution become part of the SC or not.
>
>   - Whether to provide exceptions that would allow Lenny to release sooner.

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


No I'd rather see something sensible about the firmware issues sorted
out. I'd like to re-state long known arguments:

  * firmwares are part of the hardware, even your CPU has microcode. You
    don't have the source code that generated the circuits of that
    hardware, having the source-code of the firmware will hardly help. I
    know that "firmwares are in Debian my hardware is not" but unlike
    flash or java, there is a bootstrap issues where we (I think) should
    think more of our users than you do. Not all platforms can deal with
    a secondary media with all the firmwares in it. This means that
    you'll go backwards in term of d-i features, and that implies a big
    regression.

  * Even when you have the firmware "source", without the toolchain used
    to generate them you won't go anywhere, and it's IMHO the most
    significant point to be made. Freeness of software is about being
    able to fix bugs and modify programs. Here you could modify source,
    big deal, you won't be able to *build* the damn firmware. ever. So
    what's the point ?


To me the firmware issues boils down to that:
 1. is the blob redistributable and compatible with the software license
    yes or no. If no, that's an issue that needs addressing. If yes,
    then there should be no problem.

 2. is the firmware *only* running in the hardware (IOW are we sure
    there is absolutely no code that would be mmaped and executed inside
    the host). yes or no. If yes, then it's good. else we want the
    source of it, because *this* we can fix and modify, and we have a
    toolchain for that.


Comparing documentation only distributed under PDF and binary firmwares
of 512 octets and pretend it's the same issue is a red herring, and a
total lack of nuance.


--
·O·  Pierre Habouzit
··O                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Aurelien Jarno
In reply to this post by Robert Millan
Robert Millan a écrit :
> [ This is a DRAFT, only intended to get feedback.  Do not second yet! ]
>

[snip]

> Option 1 (set an upper limit)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> The developers resolve that:
>
> When ever a package in Debian is found to have been violating the DFSG for
> 60 days or more, and none of the solutions that have been implemented (if
> any) is considered suitable by the maintainers, the package must be moved
> from Debian ("main" suite) to the Non-free repository ("non-free" suite).
>
> The action of moving it may be performed by any of the developers.  When
> this happens, any known DFSG violation in the package must be resolved
> before the package can be moved back into Debian.
>

An example of such a package is glibc (bug#382175). I don't think that
removing SUNRPC support (and with it NIS, NFS and more) is a suitable
choice (unless we want to lose all users who haven't switched yet to
Ubuntu).

The bug being more than 60 days old, does it mean that we have to move
glibc to non-free (and with it, half of the archive to contrib)? It
would be faster to move everything to non-free.

--
  .''`.  Aurelien Jarno            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   [hidden email]         | [hidden email]
   `-    people.debian.org/~aurel32 | www.aurel32.net


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Robert Millan
In reply to this post by madcoder (Bugzilla)
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."


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Robert Millan
In reply to this post by Aurelien Jarno
On Tue, Oct 21, 2008 at 05:50:40PM +0200, Aurelien Jarno wrote:
>
> An example of such a package is glibc (bug#382175). I don't think that
> removing SUNRPC support (and with it NIS, NFS and more) is a suitable
> choice (unless we want to lose all users who haven't switched yet to
> Ubuntu).

I have my doubts that the problem with glibc is so difficult as you present
it.  It's probably just a matter of contacting the right person at Sun, or
perhaps integrating another library from one of the *BSD.

In any case, if it really *is* as difficult as you present it, I trust that
you'll have no problem convincing the developers that an exception should be
granted for this particular package, at least for Lenny.

Two of the options I proposed contemplate an exception for firmware blobs in
Linux.  I didn't include other situations simply because I reused the same
text from the Etch GR.  Has something changed from Etch that would justify
making this different?

What does everyone else think about modifiing the exception texts to cover
this?

> The bug being more than 60 days old, does it mean that we have to move
> glibc to non-free (and with it, half of the archive to contrib)? It
> would be faster to move everything to non-free.

Neither the SC nor my proposed text enforce moving stuff to contrib, and I
don't think anyone would want to do it anyway, so this sounds like a moot
point.

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


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Marc 'HE' Brockschmidt-3
In reply to this post by Robert Millan
Robert Millan <[hidden email]> writes:
> Option 1 (set an upper limit)
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[move stuff to non-free after some time]

I believe this to be a bad idea.

Would we enforce this at the moment, Debian main would be empty, as
glibc (and consequently, all of it's r-build-deps) would need to go to
non-free. We would probably not do it, even if it is required by this
GR - creating the first of a probably long line of
exceptions. Re-affirming the Social Contract (or actually changing it)
in this way thus seems to be fundamentally dishonest, as we are not
actually willing to use this rule in all cases. [1]

Even if, magically, the DFSG violations in core packages would just be
fixed (after being known for a few years) I firmly believe that such a
strict rule would hurt the cause of free software. Yeah, flame on, but
read my rational before doing so.

Most DFSG violations have been fixed quite fast in the past. If such an
issue stays open for a longer time (for example, more than 60 days),
usually one of the following three option applies:
 (a) Noone cares because the package simply isn't in use.
 (b) People care, a clarification from upstream would be enough, but
     that takes a lot of time.
 (c) People care, code needs to be rewritten or data needs to be
     regenerated, but there is nobody available who's both interested
     and able to do so.

We solve (a) with a simple removal from the archive, so a move to
non-free wouldn't actually happen. If we are in case (b) or (c), we
would need to move the package to non-free. The biggest example would be
texlive, I think. So, what do you think what happens when we move
texlive to non-free? [2] I think people using tex either switch to
another distribution or add non-free to their sources.list. This will
not help to put free software on more machines, it will actually make it
harder to do so.

Anyway, I do not think that this discussion will lead to a useful
result. We are seeing two fundamentally different beliefs here - I
believe that Debian has to stay relevant and useful to make it possible
to distribute a completely free universal operating system in the
future.
From what I can gather from your mails, it seems to me that you would
prefer to distribute a completely free operating system now, even if this
means that quite a few users will switch to something different. Yes,
this description is biased and I know it, but I don't claim to be
objective.

Perhaps I'm wrong to believe that Debian is about bringing free software
to users. Perhaps it's just about free software and users actually don't
matter when there's a higher goal.

Marc

Footnotes:
 [1] At this point, I assume that moving all packages to non-free is not
     something people would actually consider. If you do feel that it's
     a viable option ... Well, then we have nothing to discuss and
     nothing to agree on, so let's just vote.
 [2] Let's just ignore all the (build-)r-deps...
--
BOFH #336:
the xy axis in the trackball is coordinated with the summer soltice

attachment0 (202 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

madcoder (Bugzilla)
In reply to this post by Robert Millan
On Tue, Oct 21, 2008 at 04:48:16PM +0000, Robert Millan wrote:
> On Tue, Oct 21, 2008 at 05:47:58PM +0200, Pierre Habouzit wrote:
> >     [...]. 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).

Such a position is blatantly impractical. To date, Debian has been
rather pragmatic in its choice, trying to find a proper compromise
between the DFSG and its usability.

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

I can't see any solution the the glibc and portmap issues either. Please
take into account in your future replies that skipping the bits you
don't want to read isn't going to make you prove your point.

My proposal is simple, and it was implied: the GR proposal is silly
because it fixes nothing that needs addressing. It add rules that are
too rigid and to date would move 95% of Debian to contrib and non-free.
And if we are to vote something, it'd be to say that unless a toolchain
to build a firmware exist, and unless firmwares licenses prohibit
distribution, firmwares are okay.


But you seem to miss a very important bit: and I see no reason to do a
GR for something that is going in the proper direction. No firmware
issue tagged etch-ignore is still present in lenny. IOW the kernel team
*is* doing good work in that area, and I see no reason to pressure them
more than useful.

--
·O·  Pierre Habouzit
··O                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Ean Schuessler
In reply to this post by Robert Millan
----- "Robert Millan" <[hidden email]> wrote:

> +       <p>
> +         In order to ensure continued compliance with this promise, the
> +         following rule is to be followed:
> +       </p>
> +       <p>
> +         When ever a package in Debian is found to have been violating the
> +         Debian Free Software Guidelines for 60 days or more, and
> +         none of the solutions that have been implemented (if any) is considered
> +         suitable by the maintainers, the package must be moved from Debian
> +         ("main" suite) to the Non-free repository ("non-free" suite).
> +       </p>
> +       <p>
> +         The action of moving it may be performed by any of the developers.
> +         When this happens, any known violation of the Debian Free Software Guidelines
> +         in the package must be resolved before the package can be moved back into
> +         Debian.
> +       </p>

I've kept a low profile for some time but AJ's enthusiasm tempts me into discussion.

These changes seem redundant to me. Rule 1 of the Social Contract is clear in its intent and Rule 5 spells out (in perhaps even more detail than necessary) how non-conforming software will be handled. I think adding links to the relevant parts of policy from the Social Contract page might be a more expedient way of drawing people's attention to the preferred "best practices".

A change to the SC mixes our policy (how things will be accomplished) with our philosophy (what our motivations are). Foundational documents are intended to communicate a more basic premise and having policy drift into them could set an ugly precedent. Making simple changes in policy would more often require an "act of congress" and it will be harder, rather than easier, to get work done.

I hear the daunting problems as illustrated in the SUNRPC/glibc issue. These are the same issues that the community has faced from the beginning. We're arguably in a far better position today than when Stallman was writing his earliest GNU work and had to go through mind-warping contortions and compromises to push towards a more open world. Viewing all this as a process, perhaps we can require that any non-free code given a "stay of execution" be part of a formal road-map that its developers commit to. If your package can't commit to a road-map to get to Free then maybe it becomes part of the road-map to arrange its removal.

I doubt a single massive move of everything that may be in violation will get us somewhere useful. An optimistic view is that we are slowly formalizing what has been done for a long time through an evasion of mind. If we can continue to formalize our progress towards the goal we've held all along then that seem productive. Rome wasn't built in a day and all that sort of thing.

--
Ean Schuessler, CTO Brainfood.com
[hidden email] - http://www.brainfood.com - 214-720-0700 x 315


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

madcoder (Bugzilla)
In reply to this post by Robert Millan
On Tue, Oct 21, 2008 at 04:54:13PM +0000, Robert Millan wrote:
> On Tue, Oct 21, 2008 at 05:50:40PM +0200, Aurelien Jarno wrote:
> > The bug being more than 60 days old, does it mean that we have to move
> > glibc to non-free (and with it, half of the archive to contrib)? It
> > would be faster to move everything to non-free.
>
> Neither the SC nor my proposed text enforce moving stuff to contrib,

It does, packages in main cannot (Build-)?Depend upon non-free, hence
must be moved to contrib.

If you move linux to non-free (ignoring the blatant silliness of such an
action), every package that needs linux-source would move to contrib.
Say kernel-package, m-a, all the kernel-patches, iptables, ...
everything. And ... even the glibc since it uses linux-libc-dev to
build, so in turn 90% of Debian shall go to contrib.

--
·O·  Pierre Habouzit
··O                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Aurelien Jarno
In reply to this post by Robert Millan
Robert Millan a écrit :

> On Tue, Oct 21, 2008 at 05:50:40PM +0200, Aurelien Jarno wrote:
>> An example of such a package is glibc (bug#382175). I don't think that
>> removing SUNRPC support (and with it NIS, NFS and more) is a suitable
>> choice (unless we want to lose all users who haven't switched yet to
>> Ubuntu).
>
> I have my doubts that the problem with glibc is so difficult as you present
> it.  It's probably just a matter of contacting the right person at Sun, or
> perhaps integrating another library from one of the *BSD.
>
> In any case, if it really *is* as difficult as you present it, I trust that
> you'll have no problem convincing the developers that an exception should be
> granted for this particular package, at least for Lenny.
>

I don't said it is difficult, though that surely not easy to contact the
*right person* at Sun. In most case you just get ignored.

Anyway I don't really care about this bug, and nothing oblige me to fix
it. I will accept patches though. Also note that given that the bug is
not yet fixed and was opened a long time ago (almost 6 years), I guess
that most people in Debian also don't care.

BTW, as you seems really concerned by this kind of bug and think it is
easy, I offer you to do the job of getting this code relicensed. If in
60 days (the same delay as you proposed) it is not done, I will consider
that this bug can be ignored for Lenny.

--
  .''`.  Aurelien Jarno            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   [hidden email]         | [hidden email]
   `-    people.debian.org/~aurel32 | www.aurel32.net


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Robert Millan
In reply to this post by madcoder (Bugzilla)
On Tue, Oct 21, 2008 at 07:02:36PM +0200, Pierre Habouzit wrote:
> No firmware
> issue tagged etch-ignore is still present in lenny. IOW the kernel team
> *is* doing good work in that area, and I see no reason to pressure them
> more than useful.

This ain't true.  Some of these bugs were known since 2006, and even 2004.
See my report in #497823 (second mail).

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


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Robert Millan
In reply to this post by madcoder (Bugzilla)
On Tue, Oct 21, 2008 at 07:07:08PM +0200, Pierre Habouzit wrote:

> On Tue, Oct 21, 2008 at 04:54:13PM +0000, Robert Millan wrote:
> > On Tue, Oct 21, 2008 at 05:50:40PM +0200, Aurelien Jarno wrote:
> > > The bug being more than 60 days old, does it mean that we have to move
> > > glibc to non-free (and with it, half of the archive to contrib)? It
> > > would be faster to move everything to non-free.
> >
> > Neither the SC nor my proposed text enforce moving stuff to contrib,
>
> It does, packages in main cannot (Build-)?Depend upon non-free, hence
> must be moved to contrib.
>
> If you move linux to non-free (ignoring the blatant silliness of such an
> action), every package that needs linux-source would move to contrib.
> Say kernel-package, m-a, all the kernel-patches, iptables, ...
> everything. And ... even the glibc since it uses linux-libc-dev to
> build, so in turn 90% of Debian shall go to contrib.

Don't you find it a bit contradictory that you're arguing that we should
"bend SC #1" and at the same time argue that if we don't, we have to interpret
SC #5 in such an overzealous way that compels us to do things that are not
even in the text?

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


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Robert Millan
In reply to this post by Aurelien Jarno
On Tue, Oct 21, 2008 at 07:27:14PM +0200, Aurelien Jarno wrote:
>
> BTW, as you seems really concerned by this kind of bug and think it is
> easy, I offer you to do the job of getting this code relicensed. If in
> 60 days (the same delay as you proposed) it is not done, I will consider
> that this bug can be ignored for Lenny.

I think you were going to do that anyway.

If I may make a suggestion, I think a simple solution would be to split the
library in a separate package, and move that to non-free.  I might even have
time to help after I finish with this discussion, the dsp56 free firmware,
etc.

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


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Robert Millan
In reply to this post by Marc 'HE' Brockschmidt-3
On Tue, Oct 21, 2008 at 06:54:32PM +0200, Marc 'HE' Brockschmidt wrote:
> From what I can gather from your mails, it seems to me that you would
> prefer to distribute a completely free operating system now, even if this
> means that quite a few users will switch to something different. Yes,
> this description is biased and I know it, but I don't claim to be
> objective.

Actually, I think you made an accurate judgement.  But I find it incomplete;
I'd like to add that I don't see anything wrong with taking Debian + non-free
bits and using the project's resources (backed by SC #5) to release an installer
that uses that.  The only caveat is that it should be made clear the result is
not "Debian" (because of SC #1).

I think that'd be a really good solution.  Debian users could continue using a
100% free system, and those who don't mind the blobs could use that alternative.

It's actually a very similar approach to what Ubuntu did with Gobuntu, but in
reverse.

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


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Manoj Srivastava
In reply to this post by madcoder (Bugzilla)
On Tue, Oct 21 2008, 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.

        This is the part I am not comfortable with. I do not think the
 delegates have the powers to decide when enough progress has been made
 to violate a foundation document in our release.  Just like an
 individual developer does not have a right to decide to violate the
 DFSG in their work, I think the release team, which prepares the
 release, can do so unilaterally either (I did not vote for Bush).

        This is why my contention has been that the developer body, as a
 whole, has to be brought into the decision loop, like they have
 for the last two releases, and  make sure we, as a project, stand
 behind the decision, not just a few hapless RMs.

        So, I would like to see an option on the ballot that sates that
 we will release Lenny with known DFSG violations, we believe in the SC,
 but we also have to respect the needs of users, and we think progress
 is being made towards ensuring that the needs of our users can be met
 with free software in the future. I just do not think this is within
 delegate or individual developer powers.

        manoj

--
VMS must die!
Manoj Srivastava <[hidden email]> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

Aurelien Jarno
In reply to this post by Robert Millan
On Tue, Oct 21, 2008 at 07:40:14PM +0200, Robert Millan wrote:
> On Tue, Oct 21, 2008 at 07:02:36PM +0200, Pierre Habouzit wrote:
> > No firmware
> > issue tagged etch-ignore is still present in lenny. IOW the kernel team
> > *is* doing good work in that area, and I see no reason to pressure them
> > more than useful.
>
> This ain't true.  Some of these bugs were known since 2006, and even 2004.
> See my report in #497823 (second mail).
>

And you weren't able to provide a patch in all this time?

--
  .''`.  Aurelien Jarno            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   [hidden email]         | [hidden email]
   `-    people.debian.org/~aurel32 | www.aurel32.net


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

madcoder (Bugzilla)
In reply to this post by Robert Millan
On Tue, Oct 21, 2008 at 05:42:25PM +0000, Robert Millan wrote:

> On Tue, Oct 21, 2008 at 07:07:08PM +0200, Pierre Habouzit wrote:
> > On Tue, Oct 21, 2008 at 04:54:13PM +0000, Robert Millan wrote:
> > > On Tue, Oct 21, 2008 at 05:50:40PM +0200, Aurelien Jarno wrote:
> > > > The bug being more than 60 days old, does it mean that we have to move
> > > > glibc to non-free (and with it, half of the archive to contrib)? It
> > > > would be faster to move everything to non-free.
> > >
> > > Neither the SC nor my proposed text enforce moving stuff to contrib,
> >
> > It does, packages in main cannot (Build-)?Depend upon non-free, hence
> > must be moved to contrib.
> >
> > If you move linux to non-free (ignoring the blatant silliness of such an
> > action), every package that needs linux-source would move to contrib.
> > Say kernel-package, m-a, all the kernel-patches, iptables, ...
> > everything. And ... even the glibc since it uses linux-libc-dev to
> > build, so in turn 90% of Debian shall go to contrib.
>
> Don't you find it a bit contradictory that you're arguing that we should
> "bend SC #1" and at the same time argue that if we don't, we have to interpret
> SC #5 in such an overzealous way that compels us to do things that are not
> even in the text?
Huh ? If you go _your_ route, we should not bend any rules, to the point
where we break. I'm saying what it really means to not adapt and find a
more pragmatic solution, and you're saying _I'm_ advocating strict
interpretation ? Please...
--
·O·  Pierre Habouzit
··O                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

madcoder (Bugzilla)
In reply to this post by Manoj Srivastava
On Tue, Oct 21, 2008 at 05:52:28PM +0000, Manoj Srivastava wrote:

> On Tue, Oct 21 2008, 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.
>
>         This is the part I am not comfortable with. I do not think the
>  delegates have the powers to decide when enough progress has been made
>  to violate a foundation document in our release.  Just like an
>  individual developer does not have a right to decide to violate the
>  DFSG in their work, I think the release team, which prepares the
>  release, can do so unilaterally either (I did not vote for Bush).
And you're comfortable with ftp-master ruling DFSG-iness through NEW
then ? I don't really see the difference.

FWIW you can query all the lenny-ignore bugs on the BTS, there arent a
lot, and check if you agree. Unlike Bush (and the reference is quite
offensive, really) we don't hide such matters, and we never said we're
not open to discussion.

BUt yeah, tagging bugs lenny-ignore is part of the RM tasks, and we're
delegated for that (among other things).
--
·O·  Pierre Habouzit
··O                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

madcoder (Bugzilla)
In reply to this post by Robert Millan
On Tue, Oct 21, 2008 at 05:40:14PM +0000, Robert Millan wrote:
> On Tue, Oct 21, 2008 at 07:02:36PM +0200, Pierre Habouzit wrote:
> > No firmware
> > issue tagged etch-ignore is still present in lenny. IOW the kernel team
> > *is* doing good work in that area, and I see no reason to pressure them
> > more than useful.
>
> This ain't true.  Some of these bugs were known since 2006, and even 2004.
> See my report in #497823 (second mail).

I read that as a leftover from #242866, where most of it has been
cleansed. FInger pointing on one or two bugs among dozens is laughable.
"Some of these bugs" were known, true, but that's the fucking point.
*SOME* were known. There are fewer than before, that's progress. Some
were forgotten, right, it's not nice. But instead of cheering up for the
good work done, you're blaming them for not having fixed every damn bug
of Linux. way to go

--
·O·  Pierre Habouzit
··O                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (204 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [DRAFT] resolving DFSG violations

madcoder (Bugzilla)
In reply to this post by Robert Millan
On Tue, Oct 21, 2008 at 05:51:52PM +0000, Robert Millan wrote:
> I think that'd be a really good solution.  Debian users could continue using a
> 100% free system, and those who don't mind the blobs could use that alternative.

It's not, and that's exactly Marc's point, the difference between
non-free and Debian will be blurry (if it's not already blurry enough),
and every single User will have non-free, whereas I believe quite a few
live without it right now.

That's regression, and it's IMHO far worse than a couple of binary blobs
in Linux.
--
·O·  Pierre Habouzit
··O                                                [hidden email]
OOO                                                http://www.madism.org

attachment0 (204 bytes) Download Attachment
1234