Firmware & Social Contract: GR proposal

[Anthony Towns]

Hi all,

It's been a week, and the results from the three polls concerning what to
do about firmware are currently:

What is the most important for the release of Etch? (202 votes) [0]
Release on time (early december) 57%
Support hardware that requires sourceless firmware   26%
Do not ship sourceless firmware in main  15%

Since it appears Debian has to make a choice, which would you 
prefer we do for etch? (197 votes) [1]
Allow sourceless firmware in main63%
Delay the release of etch (so that we can support18%
  loading firmware from non-free)
Drop support for hardware which requires sourceless  17%
  firmware

Developer only poll: (83 votes) [2]
Option 1 "Release etch on time"
defeats option 3 by 23 votes (51:28)
defeats option 2 by 52 votes (67:15)
defeats option 4 by 71 votes (76: 5)
Option 3 "Support hardware that requires sourceless firmware"
defeats option 2 by 39 votes (60:21)
defeats option 4 by 69 votes (74: 5)
Option 2 "Do not ship sourceless firmware in main"
defeats option 4 by 41 votes (59:18)
Option 4 "None of the above"
comes last

Obviously each of those polls only includes a self-selected minority of
the people they try to cover, but the results seem fairly consistent both
with each other, and what's been discussed so far on this list.

It therefore seems to me as though we're going to be failing to meet the
social contract again, and as a consequence I think we should seriously
reconsider whether the change we made in 2004 was the right one. So I'd
like to propose the following course of action for consideration:


The Debian Project resolves that:

(a) The Social Contract shall be reverted to its original form,
as at http://www.debian.org/social_contract.1.0

(b) The term "software" as used in the Social Contract shall be
presumed only to cover programs, scripts, libraries and similar
executable works to be executed directly as part of the Debian
System.

(c) In addition to the commitments made in the Social Contract,
the Debian System shall only include documentation, images,
sounds, video, fonts and similar works that meet the Debian
Free Software Guidelines, and are available in some reasonably
modifiable form.

(d) Notwithstanding the above, the Debian Free Software Guidelines
shall not be applied to logos, firmware or the text of copyright
licenses that may be included in the Debian System.

(e) Following the release of etch, the Debian Project Leader shall:
  i.   ensure that the Debian community has a good understanding
   of the technical and legal issues that prevent the Debian
   Free Software Guidelines from being applied to logos and
   firmware in a manner that meets the needs of our users;
  ii.  ensure that project resources are made available to
   people working on addressing those issues;
  iii. provide a report to the Debian community on progress achieved
   in these areas at DebConf 7 in Edinburgh.

(f) Following the release of etch, the Debian Project as a whole shall
reopen the question of which commitments should be codified in the
project's Social Contract. This shall including both an online
consultation with Debian users, Debian derivatives and the free
software community, and a public in-person discussion and debate
at DebConf 7 in Edinburgh in honour of the 10th anniversary of
the original publication of the Social Contract on the 4th
of July 1997.


Personally, I think it's a mistake to have a social contract that we
can't meet -- I would much rather say "we're not only meeting our social
contract, but we're going above and beyond it" than keep worrying about
how we've overpromised and keep having to underdeliver.

I think (e) is an important part of meeting our users' expectations,
as well as our own, that committing to releasing etch on time won't be
a permanent cost to our efforts towards free, sourceful firmware. I'm
happy to commit to it, and I presume whoever's elected DPL next year
will say during the campaign if they will or won't commit to it too,
so the project can take that into account. If people think that point is
worth adding to any of the other proposals that defer the free-firmware
issue to post-etch, that's fine by me.

It's fair to ask whether interpreting "software" to not cover all sorts
of other things we distribute is a sensible thing to do, whether on a
principled level ("but we *want* those other things to be free too"),
a logical level ("what about postscript, or self-extracting zip files of
documentation?") or a semantic level ("software

Re: Firmware & Social Contract: GR proposal

[Josselin Mouette]

Le mardi 05 septembre 2006 à 17:44 +1000, Anthony Towns a écrit :
> (a) The Social Contract shall be reverted to its original form,
> as at http://www.debian.org/social_contract.1.0
> 
> (b) The term "software" as used in the Social Contract shall be
> presumed only to cover programs, scripts, libraries and similar
> executable works to be executed directly as part of the Debian
> System.
[etc.]

I think this would be completely overreacting.

Following the social contract change, we have been able to remove most
of non-free stuff from the distribution, especially documentation. It
wasn't easy and we couldn't make it in time for sarge, but we can make
it in time for etch. For etch, we have the remaining firmware issue. And
just because we can't meet our expectations for firmwares, we should
abandon them all?

It's not a decent way to go. You want "momentum"? Then recall what has
been done. Etch will have a *lot* less non-free stuff than sarge. This
should encourage us to go in this direction, not to step back because of
a difficulty. GRs have already been proposed to deal with the firmware
stuff and go forward. Your proposal only means that the work that has
been done for etch would be abandoned.


I'd also like to add some comments on the polls.

First, it is a fact that we are going to release etch with non-free
firmwares. There is no decision to make here, it is too late. Those
polls are only a means to legitimate this fact in a political way, by
making it looking as a decision.

Second, these polls all specifically talk about the *etch* release. Not
about the future. Proposing them with the "etch" word in them and then
using the (expected) result to propose a drastic change for future
releases is nothing more than manipulation.

I ask you again to stop that kind of maneuvers. If your passion is
politics, you should consider joining a political party. Debian isn't
the right place for that.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
   `-  Debian GNU/Linux -- The power of freedom

Re: Firmware & Social Contract: GR proposal

[Sven Luther]

On Tue, Sep 05, 2006 at 05:44:04PM +1000, Anthony Towns wrote:
> Hi all,
> 
> It's been a week, and the results from the three polls concerning what to
> do about firmware are currently:
> 
> What is the most important for the release of Etch? (202 votes) [0]
> Release on time (early december) 57%
> Support hardware that requires sourceless firmware   26%
> Do not ship sourceless firmware in main  15%
> 
> Since it appears Debian has to make a choice, which would you 
> prefer we do for etch? (197 votes) [1]
> Allow sourceless firmware in main  63%
> Delay the release of etch (so that we can support18%
>   loading firmware from non-free)
> Drop support for hardware which requires sourceless  17%
>   firmware
> 
> Developer only poll: (83 votes) [2]
> Option 1 "Release etch on time"
> defeats option 3 by 23 votes (51:28)
> defeats option 2 by 52 votes (67:15)
> defeats option 4 by 71 votes (76: 5)
> Option 3 "Support hardware that requires sourceless firmware"
> defeats option 2 by 39 votes (60:21)
> defeats option 4 by 69 votes (74: 5)
> Option 2 "Do not ship sourceless firmware in main"
> defeats option 4 by 41 votes (59:18)
> Option 4 "None of the above"
> comes last
> 
> Obviously each of those polls only includes a self-selected minority of
> the people they try to cover, but the results seem fairly consistent both
> with each other, and what's been discussed so far on this list.

Ok, this seems indeed obvious, from the discussion that followed, and the
general consensus, but ...

> It therefore seems to me as though we're going to be failing to meet the
> social contract again, and as a consequence I think we should seriously
> reconsider whether the change we made in 2004 was the right one. So I'd
> like to propose the following course of action for consideration:

... you do a gigantic leap to this conclusion, which is not at all waranted by
the above poll.

The idea was that it is too short until the etch release (actually it is way
too late, since kernel freeze was in early august) to solve the non-free
firmware issue, and your little poll clearly stated that this was a poll aimed
at releasing etch on time, not to revert the decision already taken on this
subject.

> 
> The Debian Project resolves that:
> 
> (a) The Social Contract shall be reverted to its original form,
> as at http://www.debian.org/social_contract.1.0

So, we can include GFDL documentation, and other non-free stuff in main again ? 

> (b) The term "software" as used in the Social Contract shall be
> presumed only to cover programs, scripts, libraries and similar
> executable works to be executed directly as part of the Debian
> System.

Nice, especially as firmware falls more often than not in this category.

> (c) In addition to the commitments made in the Social Contract,
> the Debian System shall only include documentation, images,
> sounds, video, fonts and similar works that meet the Debian
> Free Software Guidelines, and are available in some reasonably
> modifiable form.

Oh, so you revert the social contract to the older wording, which fails to
consider most firmware cases, and then make a special exception for all those
non-firmware stuff we already removed ? 

> (d) Notwithstanding the above, the Debian Free Software Guidelines
> shall not be applied to logos, firmware or the text of copyright
> licenses that may be included in the Debian System.

And then grant a special excemption, not for the duration of the etch release,
but in general for firmware. I wonder what was the rationale for (a) then ?
Could you not have written the same without reverting the social contract to
its older form ? This only adds to the confusion instead of clarifying it.

> (e) Following the release of etch, the Debian Project Leader shall:
>   i.   ensure that the Debian community has a good understanding
>of the technical and legal issues that prevent the Debian
>Free Software Guidelines from being applied to logos and
>firmware in a manner that meets the needs of our users;
>   ii.  ensure that project resources are made available to
>people working on addressing those issues;

So, you plan to pay folk to explain to the world at large why debian should
not apply the DFSG to firmware programs :)

>   iii. provide a report to the Debian community on progress achieved
>in these areas at DebConf 7 in Edinburgh.
> 
> (f) Following the release of etch, the Debian Project as a whole shall
> reopen the question of which commitments should be codified in the
> project's Social Con

Re: Firmware & Social Contract: GR proposal

[Frank Küster]

Sven Luther <[EMAIL PROTECTED]> wrote:

> On Tue, Sep 05, 2006 at 05:44:04PM +1000, Anthony Towns wrote:
>> Obviously each of those polls only includes a self-selected minority of
>> the people they try to cover, but the results seem fairly consistent both
>> with each other, and what's been discussed so far on this list.
>
> Ok, this seems indeed obvious, from the discussion that followed, and the
> general consensus, but ...
>
>> It therefore seems to me as though we're going to be failing to meet the
>> social contract again, and as a consequence I think we should seriously
>> reconsider whether the change we made in 2004 was the right one. So I'd
>> like to propose the following course of action for consideration:
>
> ... you do a gigantic leap to this conclusion, which is not at all waranted by
> the above poll.
>
> The idea was that it is too short until the etch release (actually it is way
> too late, since kernel freeze was in early august) to solve the non-free
> firmware issue, and your little poll clearly stated that this was a poll aimed
> at releasing etch on time, not to revert the decision already taken on this
> subject.

I agree.  I have not taken part in the poll, mostly because I thought
that the result was clear from the beginning, and my vote wouldn't
change anything (it would have been exactly in the order that came out
of the developer poll and which I anticipated).  However, I always saw
these questions in the context of releasing etch, nothing else. 

I do not in any way see this poll as an indication that we should revert
the SC change, or that we have failed (in fact, we have succeeded to a
large extent, just not 100%) or that we are being hypocritical.

I also second the rest of Sven's statement ;-)

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Firmware & Social Contract: GR proposal

[Pierre Habouzit]

Le mar 5 septembre 2006 09:44, Anthony Towns a écrit :
> Obviously each of those polls only includes a self-selected minority
> of the people they try to cover, but the results seem fairly
> consistent both with each other, and what's been discussed so far on
> this list.

  Those polls should never ever drive our choices. I've raised my
concerns with respect to those polls on -devel, and even asked you as
the DPL directly[1], mail that you swept away with disdain[2].

 1. I'm utterly frustrated with your ways. The mail on d-d-a could not
have any other answer that "please release etch in time", that's
something a perfect moron could have predicted without a doubt. 

 2. Your proposal does not reflect what many of the DDs think, or have
discussed until now, whatever you claim. Only Don's proposal /may/
result into delaying etch (if the side GR that he would like to see,
— meaning voting an "override" for etch — does not pass).

 3. As it has been pointed out already, you are doing your proposal
supposing that people would have voted the same if the question
would have been "don't delay etch, nor any future release about
that" or any more clever formulation. That was not what has been
asked. The polls were strictly about etch, and drawing a general
conclusion looks like a grave abuse here to me.

 4. I know that many DD's had the same concerns about the potential
politisations of those polls, or the risks to see them impact the
GR, (or because they thought the issue was obvious) and didn't vote,
and would refuse to.

  Hiding behind those partial polls is hideous, because it *looks* 
legitimate.

  I strongly enjoin people not to second that proposal, and rather to
consider working from steve's proposal (either seconding it or
rephrasing the parts they don't like enough) that is in the spirit the
nearest proposal to that one.

 [1] http://lists.debian.org/debian-devel/2006/08/msg01313.html
 [2] http://lists.debian.org/debian-devel/2006/08/msg01322.html
-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpKtPoADNaZc.pgp
Description: PGP signature

Re: Amendment: special exception for firmware because of technical limitations

[Aurelien Jarno]

Joey Hess a écrit :

Aurelien Jarno wrote:
Not also that I found sad that the DPL try to kill this GR with his 
latest mail to debian-announce. The problem is known for a long time. 


How does posting straw polls of our users and developers to d-d-a manage
to look to you like an attempt to stop this GR?


Given the latest mail from Anthony Towns ("Firmware & Social Contract: 
GR proposal"), it looks like I was correct. He just try to stop this GR 
by proposing his own one.


If he wanted to help, it should have been done that before, not a 3 
months before the announced date of the release. And also not while 
proposals are beeing discussed. He just want to be awarded because he

found a solution to the problem.


I wish that I had your mind-reading capabilities. No, strike that, your
world seems worse with it then mine without it.



Looks like my mind-reading capabilities are working very well, I should 
use them more often.


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


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

Re: Firmware & Social Contract: GR proposal

[Anthony Towns]

On Tue, Sep 05, 2006 at 10:35:49AM +0200, Sven Luther wrote:
> > It therefore seems to me as though we're going to be failing to meet the
> > social contract again, and as a consequence I think we should seriously
> > reconsider whether the change we made in 2004 was the right one. So I'd
> > like to propose the following course of action for consideration:
> ... you do a gigantic leap to this conclusion, which is not at all waranted by
> the above poll.

There's two steps:

(1) we're not going to meet the social contract for etch
(2) having repeatedly failed to meet the new social contract over
an extended period, we should reconsider whether it was a
good idea to adopt it in the first place

Only (1) is justified by the poll. (2)'s my opinion; I think it makes
sense, but YMMV. Without (1), (2) is irrelevant, of course.

> The idea was that it is too short until the etch release (actually it is way
> too late, since kernel freeze was in early august) to solve the non-free
> firmware issue, and your little poll clearly stated that this was a poll aimed
> at releasing etch on time, not to revert the decision already taken on this
> subject.

That's correct. I don't think there's anything unreasonable about any of
the options on the table, on their own merits or in light of those polls.

> > 
> > The Debian Project resolves that:
> > (a) The Social Contract shall be reverted to its original form,
> > as at http://www.debian.org/social_contract.1.0
> > (b) The term "software" as used in the Social Contract shall be
> > presumed only to cover programs, scripts, libraries and similar
> > executable works to be executed directly as part of the Debian
> > System.
> > (c) In addition to the commitments made in the Social Contract,
> > the Debian System shall only include documentation, images,
> > sounds, video, fonts and similar works that meet the Debian
> > Free Software Guidelines, and are available in some reasonably
> > modifiable form.
> > (d) Notwithstanding the above, the Debian Free Software Guidelines
> > shall not be applied to logos, firmware or the text of copyright
> > licenses that may be included in the Debian System.

> So, we can include GFDL documentation, and other non-free stuff in main again 
> ? 
> Nice, especially as firmware falls more often than not in this category.
> Oh, so you revert the social contract to the older wording, which fails to
> consider most firmware cases, and then make a special exception for all those
> non-firmware stuff we already removed ? 
> And then grant a special excemption, not for the duration of the etch release,
> but in general for firmware. I wonder what was the rationale for (a) then ?

The rationale for (a) and (b) is having a social contract we can meet.

The rationale for (c) is that we can go beyond just meeting that social
contract, and we shouldn't be ashamed of saying that. The rationale for
(d) is that there are areas we haven't achieved what we'd like yet,
and we shouldn't be ashamed of saying that, either.

> Could you not have written the same without reverting the social contract to
> its older form ? This only adds to the confusion instead of clarifying it.

Without reverting the social contract, we're still breaking it for
etch. I'm uncomfortable with that. We could do a timed reversion like
we did for sarge, but personally, I think the current social contract
is flawed by design and we're better off with the old one until we come
up with something better than both of them.

> > (e) Following the release of etch, the Debian Project Leader shall:
> >   i.   ensure that the Debian community has a good understanding
> >of the technical and legal issues that prevent the Debian
> >Free Software Guidelines from being applied to logos and
> >firmware in a manner that meets the needs of our users;
> >   ii.  ensure that project resources are made available to
> >people working on addressing those issues;
> >   iii. provide a report to the Debian community on progress achieved
> >in these areas at DebConf 7 in Edinburgh.
> > 
> > (f) Following the release of etch, the Debian Project as a whole shall
> > reopen the question of which commitments should be codified in the
> > project's Social Contract. This shall including both an online
> > consultation with Debian users, Debian derivatives and the free
> > software community, and a public in-person discussion and debate
> > at DebConf 7 in Edinburgh in honour of the 10th anniversary of
> > the original publication of the Social Contract on the 4th
> > of July 1997.
> Mmm.
> I dislike this way of doing it, you want to, instead of making an exception
> for etch, generalize the situation, and then come back in a year

Re: Firmware & Social Contract: GR proposal

[Anthony Towns]

On Tue, Sep 05, 2006 at 11:09:17AM +0200, Frank K?ster wrote:
> I do not in any way see this poll as an indication that we should revert
> the SC change, or that we have failed (in fact, we have succeeded to a
> large extent, just not 100%) or that we are being hypocritical.

Consider comments like:

] But decontaminating Etch will finally mean Debian can keep its promise
] to its users. *Some people* actually care about Debian being 100% free,
] others don't. Last time the release team just said 'ignore it for sarge,
] we'll fix it for the next one' and now that Etch is coming around people
] are saying 'just let it through again and we'll fix it in etch+1.'

-- http://forums.debian.net/viewtopic.php?p=31198#31198

Or:

] Absolutely ... delay the release. I may want some of that firmware,
] but if I do, I want it labelled "non-free" As has been noted above,
] the release date for etch is unimportant since everyone who wants it is
] using it already.
] 
] As the old saying goes, "If you don't stand for something, you'll fall
] for anything." Debian stands for FOSS, and that's important.

-- http://forums.debian.net/viewtopic.php?p=31250#31250

Or, more to the point, articles like "Debian: too free?" (28/4/2004;
http://lwn.net/Articles/82536/) or "Resolved: firmware is not software"
(23/8/2006; http://lwn.net/Articles/196641/). 

Personally, I find it absurd that we're acting in ways that mislead
people into thinking that focussing on freedom is incompatible with
producing a good system or delivering it on time.

It's exactly right to say we haven't failed -- we've made some huge
successes since sarge, and we've got more to come. But by having a social
contract that sets the bar higher than we can achieve, we keep having
these successes viewed as failures, both by ourselves and our users.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Firmware & Social Contract: GR proposal

[Anthony Towns]

On Tue, Sep 05, 2006 at 11:26:59AM +0200, Pierre Habouzit wrote:
> Le mar 5 septembre 2006 09:44, Anthony Towns a ??crit :
>   Those polls should never ever drive our choices. I've raised my
> concerns with respect to those polls on -devel, and even asked you as
> the DPL directly[1], mail that you swept away with disdain[2].

I replied to it... If you wanted more information you could've followed
up to the reply...

>  1. I'm utterly frustrated with your ways. The mail on d-d-a could not
> have any other answer that "please release etch in time", that's
> something a perfect moron could have predicted without a doubt. 

26% of the people on the forums said supporting hardware requiring
non-free firmware was the highest priority; another 15% said not shipping
sourceless firmware in main was; that's 41% all up or 86 people.

In the other poll, 18% of people (36 people) said delaying etch was the
right solution.

>  2. Your proposal does not reflect what many of the DDs think, or have
> discussed until now, whatever you claim. Only Don's proposal /may/
> result into delaying etch

I have no idea what "many DDs think", that's why I wanted a poll to
see if we really were going to aim to release etch on time, and if so
whether we'd do that by dropping hardware support or not complying with
the social contract.

>  4. I know that many DD's had the same concerns about the potential
> politisations of those polls, or the risks to see them impact the
> GR, (or because they thought the issue was obvious) and didn't vote,
> and would refuse to.

*shrug* If you don't vote, you don't get your opinion taken into
account. That's not news.

>   I strongly enjoin people not to second that proposal,

Why? If the other proposals are better, they'll win when the final vote
is taken anyway.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Amendment: special exception for firmware because of technical limitations

[Kalle Kivimaa]

Aurelien Jarno <[EMAIL PROTECTED]> writes:
> Given the latest mail from Anthony Towns ("Firmware & Social Contract:
> GR proposal"), it looks like I was correct. He just try to stop this
> GR by proposing his own one.

The DPL has the same right as the other developers to propose GR's
that he feels are the correct ones. I fail to see why this would be
bad, but if you think that a DPL should not have that power (during
his/her term), feel free to suggest a GR to change the Constitution :)

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


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

Re: Firmware & Social Contract: GR proposal

[Sven Luther]

On Tue, Sep 05, 2006 at 08:04:59PM +1000, Anthony Towns wrote:
> If you consider our ideals to be the original social contract, applied
> to programs not images and firmware, we've been meeting and improving
> upon our ideals every year and every release.

The reason why your proposal is fundamentally broken, is that firmwares are
programs, even though some would hypocritically deny it. 

You cannot name a piece of software which runs on a mips or arm core on a
peripheral processor anything but a program.

> If you consider our ideals to be the current social contract, we've been
> violating them and compromising them and apologising for not meeting
> them every year and every release since we adopted it.

Indeed. But the ideals are something higher that is worth working to achieve.
If you place the bar lower, you will end up not reaching that either, and in
the end will have to go lower again and so on.

> > > I think (e) is an important part of meeting our users' expectations,
> > > as well as our own, that committing to releasing etch on time won't be
> > > a permanent cost to our efforts towards free, sourceful firmware. I'm
> > How can a commitment to release *ETCH* on time be a permanent cost, i mean,
> > once etch is out the door, it won't matter anymore to the solution of this
> > problem.
> 
> AFAICS, Steve's proposal is a permanent exception to DFSG#2 for images and

Steve's proposal is as flawed as yours, in the way it does things.

> firmware that's not tied to etch's release; Joss's is temporary, tied to
> the the development of "technical measures" that will allow firmware to be
> separated; Don's isn't an exception at all, and won't allow us to release
> etch on time without a further proposal; and Frederik's is an exception
> just for etch, in the same way the last reversion was an exception just
> for sarge: one that may well be repeated next time if nothing getsdone.

Frederik's proposal is a common position from the kernel team and the release
team, as it was originally drafted with input from various people of that
team, and predated all the other proposals by a couple of weeks.

It explicitly gives an exception for etch only, because we are confident that
the issue can be solved in the etch+1 timeframe. if we really wanted (and had
two man-month of full time paid work for example), we could probably even
achieve the whole thing for the etch timeframe, with proper cooperation from
the respective teams, altough it would delay d-i testing beyond what the d-i
team is confortable with.

> > So, why do you want to reopen the debate about it ? 
> 
> Because I don't think we ever had a debate on it, and I don't think it's

We did indeed have a debate on this during the last of the sarge non-free GRs.

> working out for us. The ballot that chose the current social contract
> didn't have any alternatives included, and was conducted immediately
> following the constitutional amendment to allow voting on non-free
> removal, the non-free removal debate itself and then the DPL elections,
> with only minimal discussion on -vote, most of which occurred prior to
> the non-free vote.

It was ratified by a large majority though, and i clearly remember 4-5 options
on that ballot.

> > I mean, the problem is not
> > really if firmware or fonts or whatever is software, but what we want to 
> > have
> > in main or not. These are fully orthogonal issues, and all those arguing 
> > that
> > we should accept firmware in main because it is not 'software' are misguided
> > at best, and misleading at worst. 
> 
> There are two social contract texts we have a reasonable understanding
> of -- the original one we had, and the new one we've got. Both have
> significant flaws, in my opinion, but I'd much rather have one that we
> can meet and exceed than one that we've repeatedly demonstrated we can't.

Well, i believe that both of them basically said the same thing. I seriously
doubt that if folk had thought about non-free firmware all those years ago,
they would have decided differently (altough i was not there, but from the
position of those who where, like Manoj, i think this was indeed the case).

Also, you seem to conveniently forget all the keep-non-free GR and discussion
preceding it, which largely discussed non-free kernel drivers and firmwares.

> > Let's be open and direct, all the stuff which goes on the debian cds and/or 
> > is
> > in debian archive is software, and then discuss the relative priority of
> > having it in main or not.
> 
> I think:
> 
> (b) The term "software" as used in the Social Contract shall be
> presumed only to cover programs, scripts, libraries and similar
> executable works to be executed directly as part of the Debian
> System.

And the rest is what ? Hardware ? 

> is pretty direct, even if it's not your preferred definition of the word.

Well, it leaves a elephantesk sized hole for any kind of abuse and
misinterpretation.

> But yes, discussing the re

Re: Firmware & Social Contract: GR proposal

[Sven Luther]

On Tue, Sep 05, 2006 at 08:14:42PM +1000, Anthony Towns wrote:
> On Tue, Sep 05, 2006 at 11:26:59AM +0200, Pierre Habouzit wrote:
> > Le mar 5 septembre 2006 09:44, Anthony Towns a ??crit :
> >   Those polls should never ever drive our choices. I've raised my
> > concerns with respect to those polls on -devel, and even asked you as
> > the DPL directly[1], mail that you swept away with disdain[2].
> 
> I replied to it... If you wanted more information you could've followed
> up to the reply...
> 
> >  1. I'm utterly frustrated with your ways. The mail on d-d-a could not
> > have any other answer that "please release etch in time", that's
> > something a perfect moron could have predicted without a doubt. 
> 
> 26% of the people on the forums said supporting hardware requiring
> non-free firmware was the highest priority; another 15% said not shipping
> sourceless firmware in main was; that's 41% all up or 86 people.

For etch though.

> In the other poll, 18% of people (36 people) said delaying etch was the
> right solution.

Again for etch, not forever after.

> >  2. Your proposal does not reflect what many of the DDs think, or have
> > discussed until now, whatever you claim. Only Don's proposal /may/
> > result into delaying etch
> 
> I have no idea what "many DDs think", that's why I wanted a poll to
> see if we really were going to aim to release etch on time, and if so
> whether we'd do that by dropping hardware support or not complying with
> the social contract.
> 
> >  4. I know that many DD's had the same concerns about the potential
> > politisations of those polls, or the risks to see them impact the
> > GR, (or because they thought the issue was obvious) and didn't vote,
> > and would refuse to.
> 
> *shrug* If you don't vote, you don't get your opinion taken into
> account. That's not news.

Well, the correct way of discussing this kind of stuff, is to do so on
debian-vote, this is how our voting procedure goes.

> >   I strongly enjoin people not to second that proposal,
> 
> Why? If the other proposals are better, they'll win when the final vote
> is taken anyway.

because we already have to many confunded proposals.

Friendly,

Sven Luther


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

Re: Firmware & Social Contract: GR proposal

[Anthony Towns]

On Tue, Sep 05, 2006 at 12:32:15PM +0200, Sven Luther wrote:
> > working out for us. The ballot that chose the current social contract
> > didn't have any alternatives included, and was conducted immediately
> > following the constitutional amendment to allow voting on non-free
> > removal, the non-free removal debate itself and then the DPL elections,
> > with only minimal discussion on -vote, most of which occurred prior to
> > the non-free vote.
> It was ratified by a large majority though, and i clearly remember 4-5 options
> on that ballot.

There was a second ballot, which had six options on it, namely "delay
the SC change until Sept 1st 2004", "delay the SC change until sarge
releases", "apologise", "revert to SC 1.0", "create a transition guide
for the SC and DFSG", "reaffirm the new SC".

The last option failed to achieve even a simple majority (188 ranked
it below further discussion, 155 ranked it above), each of the other
options achieved a 2:1 supermajority, but only the "delay the SC change"
options achieved the required 3:1 supermajority.

> Well, i believe that both of them basically said the same thing. 

Yes, we've had that discussion; the key point is you used the word
"software" to cover more of the contents of main, than others did.

> > I think:
> > (b) The term "software" as used in the Social Contract shall be
> > presumed only to cover programs, scripts, libraries and similar
> > executable works to be executed directly as part of the Debian
> > System.
> And the rest is what ? Hardware ? 

Firmware, documentation, images, sounds, videos, fonts, etc.

> Indeed, then [why] come back on the software vs program thingy, and retriger
> another 3+ month of discussion and voting ? 

Because we don't have an alternative social contract that we understand
well, and can adopt immediately without being in violation of it; and we
can't get a new social contract that we understand well without spending
some time to discuss it.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Amendment: special exception for firmware because of technical limitations

[Wouter Verhelst]

On Tue, Sep 05, 2006 at 01:12:56PM +0300, Kalle Kivimaa wrote:
> Aurelien Jarno <[EMAIL PROTECTED]> writes:
> > Given the latest mail from Anthony Towns ("Firmware & Social Contract:
> > GR proposal"), it looks like I was correct. He just try to stop this
> > GR by proposing his own one.
> 
> The DPL has the same right as the other developers to propose GR's
> that he feels are the correct ones.

Actually, he even has more rights (as a DPL, he does not need to find
seconds, according to points 5.1.5 and 4.2.1 of the constitution)

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


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

Re: Firmware & Social Contract: GR proposal

[Frank Küster]

Anthony Towns  wrote:

> On Tue, Sep 05, 2006 at 11:09:17AM +0200, Frank K?ster wrote:
>> I do not in any way see this poll as an indication that we should revert
>> the SC change, or that we have failed (in fact, we have succeeded to a
>> large extent, just not 100%) or that we are being hypocritical.
>
> Consider comments like:
[...]
> Or, more to the point, articles like "Debian: too free?" (28/4/2004;
> http://lwn.net/Articles/82536/) or "Resolved: firmware is not software"
> (23/8/2006; http://lwn.net/Articles/196641/). 
>
> Personally, I find it absurd that we're acting in ways that mislead
> people into thinking that focussing on freedom is incompatible with
> producing a good system or delivering it on time.

I do not understand how this is related to my statement.  I haven't read
the newer article word-by-word (and I don't know how a 2 years old
article is interesting here), but it doesn't seem to me that it argues
that freedom is incompatible with releasing a good system on time.
Instead it nicely tells about different opinions and viewpoints, and a
prediction like "So Debian may well punt the issue again; expect its
return in a year or two."  is probably true, anyway, regardless of one's
views on the relations between freedom, quality and timelines.

> It's exactly right to say we haven't failed -- we've made some huge
> successes since sarge, and we've got more to come. But by having a social
> contract that sets the bar higher than we can achieve, we keep having
> these successes viewed as failures, both by ourselves and our users.

So instead of trying ot change the way some developers and users think,
we'd rather change our foundation documents?  

In my opinion, a project like Debian is never ready, and never perfect.
Everybody knows that we are not meeting the freedom goals in the SC to
100% (as well as other goals)[1].  But I do not see this as a failure,
rather as a challenge.  So why not try to explain this to the people,
instead of lowering our standards?  We don't lower our standards with
respect to software quality or security support, either, even if we do
miss our goals.

Regards, Frank

[1] and that is not only because of firmware, but also because there are
still non-free bits hidden somewhere; they have been found in the past
months and years, and they're probably going to be found in the future.
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Amendment: special exception for firmware because of technical limitations

[Sven Luther]

On Tue, Sep 05, 2006 at 01:12:56PM +0300, Kalle Kivimaa wrote:
> Aurelien Jarno <[EMAIL PROTECTED]> writes:
> > Given the latest mail from Anthony Towns ("Firmware & Social Contract:
> > GR proposal"), it looks like I was correct. He just try to stop this
> > GR by proposing his own one.
> 
> The DPL has the same right as the other developers to propose GR's
> that he feels are the correct ones. I fail to see why this would be
> bad, but if you think that a DPL should not have that power (during
> his/her term), feel free to suggest a GR to change the Constitution :)

What is bad is not that Anthony proposed a GR, but that  he misinterpreted the
poll's result has Aurelien had predicted back then.

Friendly,

Sven Luther


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

Re: Firmware & Social Contract: GR proposal

[Anthony Towns]

On Tue, Sep 05, 2006 at 10:31:57AM +0200, Josselin Mouette wrote:
> Following the social contract change, we have been able to remove most
> of non-free stuff from the distribution, especially documentation. 

Removing non-free documentation had been a planned release goal
for etch since August 2003, prior to the SC GRs entirely. See
http://www.debian.org/News/weekly/2003/34/, eg.

> It wasn't easy and we couldn't make it in time for sarge, but we can make
> it in time for etch. For etch, we have the remaining firmware issue. And
> just because we can't meet our expectations for firmwares, we should
> abandon them all?

No. Ceasing to make commitments we can't keep doesn't mean we should
stop meeting the commitments we can. Which is why the bullet points you
didn't quote were in the proposal.

> It's not a decent way to go. You want "momentum"? Then recall what has
> been done. 

I have: http://lists.debian.org/debian-devel-announce/2006/08/msg00015.html

> Etch will have a *lot* less non-free stuff than sarge. This
> should encourage us to go in this direction, not to step back because of
> a difficulty. 

Indeed.

> First, it is a fact that we are going to release etch with non-free
> firmwares. There is no decision to make here, it is too late. 

That is not true. If the majority of developers (or users, IMO) wanted
us to delay etch instead of release with sourceless firmware that's what
would happen.

Cheers,
aj


signature.asc
Description: Digital signature

Re: Firmware & Social Contract: GR proposal

[Sven Luther]

On Tue, Sep 05, 2006 at 09:26:36PM +1000, Anthony Towns wrote:
> On Tue, Sep 05, 2006 at 10:31:57AM +0200, Josselin Mouette wrote:
> > Following the social contract change, we have been able to remove most
> > of non-free stuff from the distribution, especially documentation. 
> 
> Removing non-free documentation had been a planned release goal
> for etch since August 2003, prior to the SC GRs entirely. See
> http://www.debian.org/News/weekly/2003/34/, eg.

Notice though that we delayed that, not because of not caring or other such
issues, but because we were expecting that the discussions with the FSF solved
the GFDL problem and that this move would have proven unecessary. It was only
once it became clear that this would not be the case in a timely way for etch
that the move of the non-free documentation out of main started.

Friendly,

Sven Luther


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

Re: Firmware & Social Contract: GR proposal

[Frank Küster]

Anthony Towns  wrote:

> On Tue, Sep 05, 2006 at 10:35:49AM +0200, Sven Luther wrote:
>> > It therefore seems to me as though we're going to be failing to meet the
>> > social contract again, and as a consequence I think we should seriously
>> > reconsider whether the change we made in 2004 was the right one. So I'd
>> > like to propose the following course of action for consideration:
>> ... you do a gigantic leap to this conclusion, which is not at all waranted 
>> by
>> the above poll.
>
> There's two steps:
>
> (1) we're not going to meet the social contract for etch
> (2) having repeatedly failed to meet the new social contract over
> an extended period, we should reconsider whether it was a
> good idea to adopt it in the first place

Note that "repeatedly" means exactly "twice", but only if you replace
"having failed" by "going to have failed".  And "extended period" is
about 2 and a half years, where 10 months of that time the project was
in a state of paralysis because everybody was told "we're going to
freeze (something like) next week and release real soon afterwards".
For me, the paralysis was prolonged by the "no uploads with library
soname changes" soon afterwards, since working on non-free stuff in the
old upstream version didn't make any sense - maybe this was similar for
others.

Therefore I think it is hardly fair to say "repeatedly ... over an
extended period".  Maybe you talk like this because the fact hurts you
so much; but honestly I think if we look at it from an objective point
of view, we've achieved a lot, maybe more than could be expected.

> Only (1) is justified by the poll. (2)'s my opinion; I think it makes
> sense, but YMMV. Without (1), (2) is irrelevant, of course.

Why should it be irrelevant without (1)?  Would you feel less of a
failure if we release etch in summer 2008, without non-free firmware in
main?  I'm sure you wouldn't; just the argument would be phrased
differently (drop the "repeatedly", replace "meets" by "make a release
that meets" and "extended" by "incredibly long").

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Firmware & Social Contract: GR proposal

[Kalle Kivimaa]

Frank Küster <[EMAIL PROTECTED]> writes:
> In my opinion, a project like Debian is never ready, and never perfect.
> Everybody knows that we are not meeting the freedom goals in the SC to
> 100% (as well as other goals)[1].  But I do not see this as a failure,
> rather as a challenge.  So why not try to explain this to the people,
> instead of lowering our standards?  We don't lower our standards with
> respect to software quality or security support, either, even if we do
> miss our goals.

I think the question aj is asking is should the SC be a requirement or
an ideal. If it is a requirement, then we cannot release etch if we
fail to reach it. If it is an ideal, then we can release etch saying
that we are still behind our ideal in some respects.

I think the SC is a requirement and if we knowingly continue to break
it, it sends a bad message to our users.

-- 
* Sufficiently advanced magic is indistinguishable from technology (T.P)  *
*   PGP public key available @ http://www.iki.fi/killer   *


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

Re: Firmware & Social Contract: GR proposal

[Frank Küster]

Anthony Towns  wrote:

> There was a second ballot, which had six options on it, namely "delay
> the SC change until Sept 1st 2004", "delay the SC change until sarge
> releases", "apologise", "revert to SC 1.0", "create a transition guide
> for the SC and DFSG", "reaffirm the new SC".
>
> The last option failed to achieve even a simple majority (188 ranked
> it below further discussion, 155 ranked it above), each of the other
> options achieved a 2:1 supermajority, but only the "delay the SC change"
> options achieved the required 3:1 supermajority.

Which pretty much argues for the position that the project wants the new
SC, but is willing to compromise on the timeline of achieving it.

>> Well, i believe that both of them basically said the same thing. 
>
> Yes, we've had that discussion; the key point is you used the word
> "software" to cover more of the contents of main, than others did.

The key point seems to be that you want to renew a discussion that,
according to many's perception, has already taken place sufficiently,
while you said somewhere that it hadn't...

Regards, Frank

-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Firmware & Social Contract: GR proposal

[Sven Luther]

On Tue, Sep 05, 2006 at 08:53:29PM +1000, Anthony Towns wrote:
> On Tue, Sep 05, 2006 at 12:32:15PM +0200, Sven Luther wrote:
> > > working out for us. The ballot that chose the current social contract
> > > didn't have any alternatives included, and was conducted immediately
> > > following the constitutional amendment to allow voting on non-free
> > > removal, the non-free removal debate itself and then the DPL elections,
> > > with only minimal discussion on -vote, most of which occurred prior to
> > > the non-free vote.
> > It was ratified by a large majority though, and i clearly remember 4-5 
> > options
> > on that ballot.
> 
> There was a second ballot, which had six options on it, namely "delay
> the SC change until Sept 1st 2004", "delay the SC change until sarge
> releases", "apologise", "revert to SC 1.0", "create a transition guide
> for the SC and DFSG", "reaffirm the new SC".
> 
> The last option failed to achieve even a simple majority (188 ranked
> it below further discussion, 155 ranked it above), each of the other
> options achieved a 2:1 supermajority, but only the "delay the SC change"
> options achieved the required 3:1 supermajority.

Indeed, but the fact that "delay until sarge release" won by a large majority,
shows that our DDs did indeed reaffirm the new SC, even though they chose to
delay its application until after the sarge release, so, saying as you say
here, that because the "reaffirm the new SC" failed to get a simple majority,
that most DDs would prefer to revert to the older wording, failing to see that
this last one was indeed included (altough in a delayed way) in the option
that actually won by a 3:1 majority, is indeed very misleading, and why there
are people who profundly dislike the way you reason on things.

The fact that you made a huge statement back then about this, by resigning
from your RM position because of this further muddies the water about it.

> > Well, i believe that both of them basically said the same thing. 
> 
> Yes, we've had that discussion; the key point is you used the word
> "software" to cover more of the contents of main, than others did.

Well, but do you truly believe that this was not the original meaning of the
original social contract ? If anything else, it was strongly reafirmed in the
last of the pre-sarge non-free GRs. I mean, it did win and achieve the 3:1
supermajority, no ?

> > > I think:
> > > (b) The term "software" as used in the Social Contract shall be
> > > presumed only to cover programs, scripts, libraries and similar
> > > executable works to be executed directly as part of the Debian
> > > System.
> > And the rest is what ? Hardware ? 
> 
> Firmware, documentation, images, sounds, videos, fonts, etc.

Software has only a meaning in opposition to hardware, all the above clasify
as software in this most common of original definitions of the word, and
firmware foremost of them.

> > Indeed, then [why] come back on the software vs program thingy, and retriger
> > another 3+ month of discussion and voting ? 
> 
> Because we don't have an alternative social contract that we understand
> well, and can adopt immediately without being in violation of it; and we
> can't get a new social contract that we understand well without spending
> some time to discuss it.

Why would we need an alternative social contract. We already have one, which
shows the values and goals that we call our own. The fact that we failed to do
so by a tiny amount (and face it, it is a tiny amount compared to the huge
amount of software which respects those goals and values) is not enough to
change that, and in particular with regard of the huge improvement we were
able to achieve in the etch development timeframe, and the fact that we have
indeed plans to sort this out in the etch development timeframe.

Friendly,

Sven Luther


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

Re: Firmware & Social Contract: GR proposal

[MJ Ray]

Anthony Towns 
> Since it appears Debian has to make a choice, which would you=20
> prefer we do for etch? (197 votes) [1]
> Allow sourceless firmware in main  63%
> Delay the release of etch (so that we can support18%
>   loading firmware from non-free)
> Drop support for hardware which requires sourceless  17%
>   firmware

As far as I can see, those choices are not orthogonal.

> Developer only poll: (83 votes) [2]
> Option 1 Release etch on time
> Option 3 Support hardware that requires sourceless firmware
> Option 2 Do not ship sourceless firmware in main
> Option 4 None of the above

...and nor are these.

[...]
> (a) The Social Contract shall be reverted to its original form,
> as at http://www.debian.org/social_contract.1.0

However, that version imposes the same requirements.  It was merely
rephrased in an attempt to clarify the communication, with the hope of
stopping some attempts to put non-free in main.

> (b) The term "software" as used in the Social Contract shall be
> presumed only to cover programs, scripts, libraries and similar
> executable works to be executed directly as part of the Debian
> System.

This is nonsense, the equivalent of defining pi to be 3.  The rest of
the proposal is flawed as a consequence.

[...]
> Personally, I think it's a mistake to have a social contract that we
> can't meet [...]

There is no reason that we can't fulfil the social contract.  We may not
do so in the near future, but that does not make it impossible, or make
working towards it any less desirable.

> It's fair to ask whether interpreting "software" to not cover all sorts
> of other things we distribute is a sensible thing to do, [...]

The social contract does not cover other things that we distribute.
It covers software and should cover all software in the distribution.
The discussions about what aims should cover other things (like money)
are still on-going in other threads.

> TTBOMK the Debian, Firefox and Thunderbird [3] logos all currently have
> non-free copyright licenses acting as trademark protection, hence the
> specific exception for logos, given images are mentioned previously. To
> date, no one else has been particularly interested in helping work out
> what we want to do about protecting the Debian logo by trademark instead
> of (non-DFSG) copyright provisions. [...]

There are people interested.  I think us mere mortals have been hindered
by the slowness of the DPL and SPI on these topics.  We could GR it,
but there doesn't seem much objection - just inaction.  If this DPL
states clearly he will not work on this, I'll propose a GR in a bit,
but I've been flamed before for suggesting uncontroversial GRs.

IIRC, Mako has proposed trademark terms, and Greg Pomerantz(sp!) has
posted a draft licence to spi-trademark, probably in 2005.  Next on the
trademark, it needs SPI board to approve the terms, but I guess they
want to deal with the long-running Spain trademark problem first.
(How many months does it take SPI to talk to a lawyer?  Tune in next
year and find out.)

On the logo copyright, the DPL needs to instruct SPI to change the
licence.  The last discussion I can find is in 2004-10-05 minuted in
http://www.spi-inc.org/corporate/meeting-minutes/2004/board-meeting-october-5th-2004/
where it was deferred to 2004-11, but it doesn't appear on 
http://www.spi-inc.org/corporate/meeting-minutes/2004/board-meeting-november-9th-2004/
nor did I find it being referred to debian-legal in 2004-10.

Past DPL Branden Robinson wrote "I think we should leave the Open Use logo
basically unencumbered by copyright" in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=212895;msg=33
but didn't fix it during his DPL term AFAICT.

So, would this DPL like to be the one to take active leadership and
fix the dumb debian logo bug?

Here's hoping,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


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

Re: Firmware & Social Contract: GR proposal

[Mark Brown]

On Tue, Sep 05, 2006 at 01:48:06PM +0200, Frank K?ster wrote:

> The key point seems to be that you want to renew a discussion that,
> according to many's perception, has already taken place sufficiently,
> while you said somewhere that it hadn't...

The current situation appears to be that we end up repeatedly arguing
about which bits of the social contract we can fail to meet in order to
get a release done.  While I think it's fair to say that many people
have seen quite enough discussion about these issues this doesn't mean
that that sort of discussion is likely to stop happening.

-- 
"You grabbed my hand and we fell into it, like a daydream - or a fever."


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

Re: libd-i ABI bump

[Sven Luther]

On Tue, Sep 05, 2006 at 12:05:48PM +0200, Bastian Blank wrote:
> On Thu, Aug 31, 2006 at 10:36:46AM +0200, Bastian Blank wrote:
> > There is an ABI bump scheduled for after beta3.
> 
> I cancel this bump for pre-etch.
> 
> The main reason for this was the final implemention of support for more
> than one packages file. But implementing this in a correct way needs
> more modifications than I planned in this state.
> 
> The other planned changes are useless for etch anyway.

This clearly means that the non-free firmware/driver separation can't happen
for etch, right ? 

Friendly,

Sven Luther


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

Re: Firmware & Social Contract: GR proposal

[Anthony Towns]

On Tue, Sep 05, 2006 at 01:36:19PM +0200, Frank K?ster wrote:
> Anthony Towns  wrote:
> > There's two steps:
> > (1) we're not going to meet the social contract for etch
> > (2) having repeatedly failed to meet the new social contract over
> > an extended period, we should reconsider whether it was a
> > good idea to adopt it in the first place
> Note that "repeatedly" means exactly "twice", but only if you replace
> "having failed" by "going to have failed".  

We've failed to meet it for documentation, images, firmware, etc in sarge.

We'll fail to meet it for firmware and logos in etch, including our own
logo, and to the best of my knowledge, we're yet to consider addressing
the license of documents like the Debian Manifesto, or the Debian
Constitution.

We don't have any prospect of meeting it for copyright texts themselves,
either, a fact which is usually handwaved away entirely for "pragmatic"
reasons.

So yes, I count that as "repeatedly", and not particularly as "twice". For
the people who don't consider the SC to have changed meaning when the
word "software" was removed, we've knowingly failed to meet the SC every
release since introducing it.

> And "extended period" is about 2 and a half years, where [...]

And yes, I consider two and a half years an extended period, whatever
mitigating circumstances there might be.

> Therefore I think it is hardly fair to say "repeatedly ... over an
> extended period".  Maybe you talk like this because the fact hurts you
> so much; but honestly I think if we look at it from an objective point
> of view, we've achieved a lot, maybe more than could be expected.

I think we've achieved exactly as much as we should have expected -- we've
removed non-free documentation for etch, and made some good progress on
other things, with more to be expected for the next release.

Unfortunately that's not what we expected or what we told others to expect,
which was that the Debian System would be 100% free.

> > Only (1) is justified by the poll. (2)'s my opinion; I think it makes
> > sense, but YMMV. Without (1), (2) is irrelevant, of course.
> Why should it be irrelevant without (1)?  Would you feel less of a
> failure if we release etch in summer 2008, without non-free firmware in
> main? 

Huh? I don't feel like a failure at all.

If you're trying to ask "would I feel we'd abided by the SC better if we
released etch in mid-2008, without non-free firmware in main", then yes,
I would. Which is why I wanted to know whether that was what our users
actually wanted first.

> I'm sure you wouldn't;

If our users had wanted that, and we'd done it, I wouldn't think that was
a failure at all.

If our users didn't want it, but we'd delayed like that anyway, I'd think
that was a massive failure.

I realise everyone seems to be treating "let's release etch RSN and
ignore the SC" as a given, but I would ask you to remember that this was
introduced as "Etch timeline is unrealistic because non-free firmware
is NOT being dealt with".

Cheers,
aj



signature.asc
Description: Digital signature

Re: Firmware & Social Contract: GR proposal

[Anthony Towns]

On Tue, Sep 05, 2006 at 01:24:13PM +0200, Frank K?ster wrote:
> So instead of trying ot change the way some developers and users think,
> we'd rather change our foundation documents?  

Changing our foundation documents is a way of changing what developers
and users think. At the moment we claim on one hand that "Debian will
be 100% free", then on the other hand claim "oh, except for firmware
because we don't have time right now".

> In my opinion, a project like Debian is never ready, and never perfect.
> Everybody knows that we are not meeting the freedom goals in the SC to
> 100% (as well as other goals)[1].  

If "everybody knows that", why are we discussing this at all -- if the
social contract is just something we'd like to achieve one day, like
world peace or an end to hunger, why do we need a general resolution to
acknowledge that we're not meeting it now?

> But I do not see this as a failure,
> rather as a challenge.  So why not try to explain this to the people,
> instead of lowering our standards?  

Why not have the project have a process of continually raising and then
meeting its standards, rather than continually failing to meet them and
having to find some way to excuse it?

> We don't lower our standards with
> respect to software quality or security support, either, even if we do
> miss our goals.

We don't claim to have higher standards than we actually do for those
things either, though. Nor do we consider them "foundation documents".

Cheers,
aj



signature.asc
Description: Digital signature

Re: Firmware & Social Contract: GR proposal

[Frank Küster]

MJ Ray <[EMAIL PROTECTED]> wrote:

> Anthony Towns 
>> Since it appears Debian has to make a choice, which would you=20
>> prefer we do for etch? (197 votes) [1]
>> Allow sourceless firmware in main 63%
>> Delay the release of etch (so that we can support18%
>>   loading firmware from non-free)
>> Drop support for hardware which requires sourceless  17%
>>   firmware
>
> As far as I can see, those choices are not orthogonal.
>
>> Developer only poll: (83 votes) [2]
>> Option 1 Release etch on time
>> Option 3 Support hardware that requires sourceless firmware
>> Option 2 Do not ship sourceless firmware in main
>> Option 4 None of the above
>
> ...and nor are these.

Ah, right, I forgot: neither orthogonal nor contradicting, just mingled
up.  One more reason why I didn't vote.  Technically, we can still
manage to meet Options 1 to 3 of the DD-only poll, although it's highly
unlikely.  Options 1 and 3 in the first poll can be read with a "for
etch only" attached or without, making them either o

Regards, Frank
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Firmware & Social Contract: GR proposal

[MJ Ray]

Anthony Towns  wrote:
> While we ship the text of the GPL, we'll be shipping content that's not
> 100% free. [...]

Please not that old myth!

  Can I modify the GPL and make a modified license?
You can use the GPL terms (possibly modified) in another license
provided that you call your license by another name and do not include
the GPL preamble, and provided you modify the instructions-for-use
at the end enough to make it clearly different in wording and not
mention GNU (though the actual procedure you describe may be similar).
[...]
  -- http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL

If you want to fix that "not 100% free", then fix a bug against base-files
to remove the preamble and modify the tail.  The resulting licence will
have the same terms as the GPL (so GPL'd software could be distributed
under it) and name change clauses are fine for the DFSG, right?

I think there are more pressing bugs to deal with, but it's your choice.

> If you consider our ideals to be the original social contract, applied
> to programs not images and firmware, we've been meeting and improving
> upon our ideals every year and every release.

Can you support the claim that the original SC wasn't intended to cover
everything on the CD?  Am I misunderstanding your claim?

[...]
> My original mail was a bit strong, so I'm not really surprised. It's
> hard not to get worked up about this after so long, at least for me.

Please, everyone, instead of getting 'worked up', try to explain and
give references to support arguments when appropriate.

Thanks,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


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

Proposal - Amendment - allow hardware support from non-free into the debian system

[MJ Ray]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Here is my (slightly rushed) write-up of a non-free-hw compromise 
option.  Please second it if you think it should appear on the vote.

This amendment to <[EMAIL PROTECTED]> removes 
the rationale and "therefore", replaces "authors" in point 2 with 
"licensors", removes point 3, and replaces point 4 with "as a special 
exception to help users who have vital hardware without free software 
drivers yet, the Debian system and official CD images may include 
hardware support packages from the admin section of the non-free archive 
area which conform to all Debian Free Software Guidelines except 
guideline 2 (Source Code), or an archive section/area with equivalent 
requirements."

So, the full position statement proposed is:


THE DEBIAN PROJECT:
1. reaffirms its dedication to providing a 100% free system to 
our users according to our Social Contract and the DFSG; and
2. encourages licensors of all works to make those works 
available not only under licenses that permit modification, but also in 
forms that make such modifications practical; and
3. as a special exception to help users who have vital hardware 
without free software drivers yet, the Debian system and official CD 
images may include hardware-support packages from the admin section of 
the non-free archive area which conform to all Debian Free Software 
Guidelines except guideline 2 (Source Code), or an archive section/area 
with equivalent requirements.



Personal rationale:

- - I'm not giving a full rationale here because this has been discussed 
in extreme depth already and we're voting for a policy more than its 
rationale.  For what it's worth, I wrote this proposal after
http://lists.debian.org/debian-vote/2006/08/msg00123.html and
http://lists.debian.org/debian-vote/2006/09/msg00010.html and my notes
from -vote are http://mjr.towers.org.uk/blog/2006/debian#dfsgwaiving

- - this neither supports nor reverses the decision of the Release Team 
about works such as images, video, and fonts.  I don't think that the 
two issues should be combined: no videos seem as vital as firmware for 
installation.  This GR should neither promote that decision to policy, 
nor override it.

- - this tries to specify a compromise for hardware support in a way that 
/could/ be done today by moving linux-* to non-free (but I hope that 
isn't what happens) while trying to leave most of the implementation 
decisions to the relevant maintainers and delegates.  I hope that it's 
some sort of split between main and a new non-free-hw, but who knows?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFE/Ww1mUY5euFC5vQRAoDNAJ4llN14ZBov0MZeyF5pwDSdLEkejQCgh9ZB
Sr8ydUqesyN6CkAJQIhwYJ0=
=cLH/
-END PGP SIGNATURE-


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

Re: Proposal - Amendment - allow hardware support from non-free into the debian system

[Sven Luther]

On Tue, Sep 05, 2006 at 01:25:44PM +0100, MJ Ray wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1

Well, i think we are going to have too many options on that ballot, i think we
should do some rationalizing at some point, and keep only a few which will
represent most opinions, and work on polishing their wordings instead of
everyone proposing their pet proposal.

> Here is my (slightly rushed) write-up of a non-free-hw compromise 
> option.  Please second it if you think it should appear on the vote.
> 
> This amendment to <[EMAIL PROTECTED]> removes 
> the rationale and "therefore", replaces "authors" in point 2 with 
> "licensors", removes point 3, and replaces point 4 with "as a special 
> exception to help users who have vital hardware without free software 
> drivers yet, the Debian system and official CD images may include 
> hardware support packages from the admin section of the non-free archive 
> area which conform to all Debian Free Software Guidelines except 
> guideline 2 (Source Code), or an archive section/area with equivalent 
> requirements."
> 
> So, the full position statement proposed is:
> 
> 
> THE DEBIAN PROJECT:
> 1. reaffirms its dedication to providing a 100% free system to 
> our users according to our Social Contract and the DFSG; and
> 2. encourages licensors of all works to make those works 
> available not only under licenses that permit modification, but also in 
> forms that make such modifications practical; and
> 3. as a special exception to help users who have vital hardware 
> without free software drivers yet, the Debian system and official CD 
> images may include hardware-support packages from the admin section of 
> the non-free archive area which conform to all Debian Free Software 
> Guidelines except guideline 2 (Source Code), or an archive section/area 
> with equivalent requirements.
> 

Why do you mention the admin section of the non-free archive ? I mean,
sections are mostly obsolet with the new pool structure, and it is not clear
what is meant here.

If this is clarified, i would second your proposal.

> Personal rationale:
> 
> - - I'm not giving a full rationale here because this has been discussed 
> in extreme depth already and we're voting for a policy more than its 
> rationale.  For what it's worth, I wrote this proposal after
> http://lists.debian.org/debian-vote/2006/08/msg00123.html and
> http://lists.debian.org/debian-vote/2006/09/msg00010.html and my notes
> from -vote are http://mjr.towers.org.uk/blog/2006/debian#dfsgwaiving
> 
> - - this neither supports nor reverses the decision of the Release Team 
> about works such as images, video, and fonts.  I don't think that the 
> two issues should be combined: no videos seem as vital as firmware for 
> installation.  This GR should neither promote that decision to policy, 
> nor override it.
> 
> - - this tries to specify a compromise for hardware support in a way that 
> /could/ be done today by moving linux-* to non-free (but I hope that 
> isn't what happens) while trying to leave most of the implementation 
> decisions to the relevant maintainers and delegates.  I hope that it's 
> some sort of split between main and a new non-free-hw, but who knows?

Notice that the split to non-free will no more happen for etch, i think it is
doubtful that any other issue will come of those GRs.

Friendly,

Sven Luther


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

Re: Firmware & Social Contract: GR proposal

[MJ Ray]

Frank =?iso-8859-1?Q?K=FCster?= <[EMAIL PROTECTED]>
> MJ Ray <[EMAIL PROTECTED]> wrote:
> > Anthony Towns 
> >> Developer only poll: (83 votes) [2]
> >> Option 1 Release etch on time
> >> Option 3 Support hardware that requires sourceless firmware
> >> Option 2 Do not ship sourceless firmware in main
> >> Option 4 None of the above
> >
> > ...and nor are these.
> 
> Ah, right, I forgot: neither orthogonal nor contradicting, just mingled
> up.  One more reason why I didn't vote.  Technically, we can still
> manage to meet Options 1 to 3 of the DD-only poll, although it's highly
> unlikely.  [...]

The vote data may still be useful in picking priorities, but it makes
little sense to pick a "winner" in the usual way, or to do anything to
discourage work towards lower priority aims.

That's one reason why I can't agree with the initial proposal (apart from
the big stack of non-answers to my first reply to it): it pretty much
perpetually pooh-poohs several aims, rather than declaring some aims
to be more important than others.  I think that was a mistake with the
sarge-ignore GR and is part of the reason we're back here now.  Can we
get a release out in a timely way without chilling and insulting help?

Musing,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


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

Re: Firmware & Social Contract: GR proposal

[Anthony Towns]

On Tue, Sep 05, 2006 at 12:53:50PM +0100, MJ Ray wrote:
> There are people interested.  I think us mere mortals have been hindered
> by the slowness of the DPL and SPI on these topics.  

You might like to consider replying to:

Subject: Re: Presumably-unauthorized Open Logo use
Date: Sat, 1 Jul 2006 18:30:28 +1000
To: [EMAIL PROTECTED]

then.

> We could GR it, but there doesn't seem much objection - just inaction.  

When I asked in April about a week after my term began, Greg (the SPI
lawyer) replied:

"I don't think there has been a great deal of interest in registering
 the Debian logo.  On the one hand, the open use logo is not very
 strong as a trademark, and it seems to get independently re-created
 by various third parties around the world from time to time --
 therefore it would be terribly difficult to police.  The official
 logo does not seem to be very widely used or widely recognizable."

The last mail on the spi-trademark was in May on a not-particularly
related matter.

> On the logo copyright, the DPL needs to instruct SPI to change the
> licence.

Changing the copyright license without establishing a proper trademark
would seem irresponsible and inappropriate to me.

> So, would this DPL like to be the one to take active leadership and
> fix the dumb debian logo bug?

I haven't seen any interest whatsoever in dealing with this from other
developers, so I've deprioritised it. If that changes, I'll be happy to
put it back on my list of things to deal with.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Firmware & Social Contract: GR proposal

[Anthony Towns]

On Tue, Sep 05, 2006 at 01:52:51PM +0200, Sven Luther wrote:
> Indeed, but the fact that "delay until sarge release" won by a large majority,
> shows that our DDs did indeed reaffirm the new SC, 

In my opinion, it shows that at the time that was the best option on
the table. One option that wasn't on the table at that point was having
a proper discussion about what the social contract should contain. The
reason that wasn't on the table was that the sarge release was a higher
priority, and there wasn't much chance of a useful debate in the meantime.

> The fact that you made a huge statement back then about this, by resigning
> from your RM position because of this further muddies the water about it.

Actually, I made no statement about it whatsoever, either in the followup
vote (in which I deliberately abstained by voting all options equally),
nor in resigning (when I declined to comment publicly). I haven't
commented on it since then until this year, as part of trying to meet
the current social contract by getting the GFDL situation resolved
earlier this year, and now, since we seem to be having the exact same
problem again.

> > > Well, i believe that both of them basically said the same thing. 
> > Yes, we've had that discussion; the key point is you used the word
> > "software" to cover more of the contents of main, than others did.
> Well, but do you truly believe that this was not the original meaning of the
> original social contract ? 

Yes, I do believe that "software" only covered programs, not "everything". 

It's what I thought I was agreeing to when I read the SC as part of
signing up. The archives of -private on master during the SC/DFSG
discussions match that impression, to my mind:

] The reason for Debian to be free software is so that our users can do
] cool stuff with it without running into legal problems. I would prefer
] not to make the document sound more like a "Pledge of Allegiance to Free
] Software", lest we be seen to be marching after ideology regardless of the
] end product and the users. The document is a contract we offer to our
] community about how we will behave with that community. We offer it to
] the people, we do not lay it upon the altar of free software.
(June 1997)

] It is not a legal document, it's a social one. Thus, I eschew the extremely
] careful language of a legal document in favor of something short and simple
] that communicates our philosophy without boring or intimidating the reader.
(June 1997)

] > There is no mention in the "social contract" that source formats for
] > documentation must be provided and that we must be able to modify the
] > documentation.
] I suppose you could read it that way, but it's not meant that way.
] I know of one potential Debian package that places a different copyright
] on the documentation than the program, but I don't know of any where the
] documentation is not available in source form.
]
] I'm willing to wait for the problem to happen before we address it.
(July 1997)

> If anything else, it was strongly reafirmed in the
> last of the pre-sarge non-free GRs. I mean, it did win and achieve the 3:1
> supermajority, no ?

Compared to reverting to the ambiguous original social contract, with
no explicit clarification, nor any specific intention of doing better,
"delay to sarge" beat "rescind entirely" by 257:122 votes (about 2:1),
which was the weakest defeat of that option (compared to 301:45, 271:77,
273:86, 322:55 and 339:45). 

As I've said, I think it's worth reconsidering at this point.

> > > > I think:
> > > > (b) The term "software" as used in the Social Contract shall be
> > > > presumed only to cover programs, scripts, libraries and similar
> > > > executable works to be executed directly as part of the Debian
> > > > System.
> > > And the rest is what ? Hardware ? 
> > Firmware, documentation, images, sounds, videos, fonts, etc.
> Software has only a meaning in opposition to hardware, all the above clasify
> as software in this most common of original definitions of the word, and
> firmware foremost of them.

Again, I'm aware you prefer a different definition. dict/FOLDOC is aware of it
too:

 Some claim that {documentation} (both paper and electronic) is
 also software.  Others go further and define software to be
 programs plus documentation though this does not correspond
 with common usage.

> Why would we need an alternative social contract. 

Because we are unable to meet the terms of our current social contract,
and it doesn't actually reflect the priorities of our users or the free
software community -- and supporting those groups of people is the entire
point of our social contract.

Personally, I think there are other reasons to review it too -- I don't
think explicitly naming "contrib" and "non-free" is a good idea; I think
it's currently quite cumbersome and legalistic -- when I want to find
something that reminds me of why I think free soft

Re: Proposal - Amendment - allow hardware support from non-free into the debian system

[Julien BLACHE]

[EMAIL PROTECTED] (MJ Ray) wrote:

Hi,

> 3. as a special exception to help users who have vital hardware 
   ^
> without free software drivers yet, the Debian system and official CD 

We'll soon have a 200+ posts sub-thread trying to come up with a
definition for "vital hardware" ...

I'd second your proposal without the "vital" word.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


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

Re: Firmware & Social Contract: GR proposal

[Anthony Towns]

On Tue, Sep 05, 2006 at 01:18:06PM +0100, MJ Ray wrote:
> Anthony Towns  wrote:
> > While we ship the text of the GPL, we'll be shipping content that's not
> > 100% free. [...]
> Please not that old myth!
>   Can I modify the GPL and make a modified license?
> You can use the GPL terms (possibly modified) in another license
> provided that you call your license by another name and do not include
> the GPL preamble, and provided you modify the instructions-for-use
> at the end enough to make it clearly different in wording and not
> mention GNU (though the actual procedure you describe may be similar).
> [...]
>   -- http://www.gnu.org/licenses/gpl-faq.html#ModifyGPL

Heh, a FAQ on a website overriding the clear and explicit wording from the
license itself ("Everyone is permitted to copy and distribute verbatim
copies of this license document, but changing it is not allowed.")? Who
would've thought...

I don't think creating a "Debian General Public License" with the same
terms as the GPL, but without the preamble, and pretending all the
currently GPLed stuff is licensed under those terms would be in the
interests of either our users, or the free software community.

Yet, our social contract says that the Debian System will be 100% free...

Cheers,
aj



signature.asc
Description: Digital signature

Re: Firmware & Social Contract: GR proposal

[Sven Luther]

On Tue, Sep 05, 2006 at 10:49:49PM +1000, Anthony Towns wrote:
> On Tue, Sep 05, 2006 at 01:52:51PM +0200, Sven Luther wrote:
> > Indeed, but the fact that "delay until sarge release" won by a large 
> > majority,
> > shows that our DDs did indeed reaffirm the new SC, 
> 
> In my opinion, it shows that at the time that was the best option on

No, it simply shows that at that time there was a large majority which
approved of the new SC wording, while at the same time didn't consider it was
worth delaying sarge in order to make it happen.

It is plain clear enough. The three options could have been :

  - Reaffirm the new social contract and delay sarge until we fix the issues.
  - Reaffirm the new social contract and give us until september to release
sarge, or delay it until we fix the issues.
  - Reaffirm the new social contract but make an excpetion for sarge.

The third won, just like in this case there is a huge consensus on keeping
things like they are, and making an exception for etch on the issues still
remaining.

> the table. One option that wasn't on the table at that point was having
> a proper discussion about what the social contract should contain. The

Well, it is called "Further Discussion", and that discussion was held during
the campaing leading to that third vote, and during the non-free removal vote
(much less with the cosmetic change second vote, which trokaned in those
issues).

> reason that wasn't on the table was that the sarge release was a higher
> priority, and there wasn't much chance of a useful debate in the meantime.

Sure, but people could have chosen further discussion, or to revert the social
contract change, or even propose new options. They didn't do though.

> > The fact that you made a huge statement back then about this, by resigning
> > from your RM position because of this further muddies the water about it.
> 
> Actually, I made no statement about it whatsoever, either in the followup
> vote (in which I deliberately abstained by voting all options equally),
> nor in resigning (when I declined to comment publicly). I haven't

Acts speak louder than words :)

> commented on it since then until this year, as part of trying to meet
> the current social contract by getting the GFDL situation resolved
> earlier this year, and now, since we seem to be having the exact same
> problem again.

We do indeed have the exact same problem. We believe in our values, as
claimed in the social contract, but notice that we didn't have enough time to
fix all those issues during the etch release, which was noticably shorter than
the sarge release, and which saw lot of work and improvement in many areas, as
well as some ugly infighting which sapped energy and stuff.

No need for major reorientations of the project values and goals, just because
we did slip a bit in some areas.

> > > > Well, i believe that both of them basically said the same thing. 
> > > Yes, we've had that discussion; the key point is you used the word
> > > "software" to cover more of the contents of main, than others did.
> > Well, but do you truly believe that this was not the original meaning of the
> > original social contract ? 
> 
> Yes, I do believe that "software" only covered programs, not "everything". 

Ok. Where you a DD already back then ? It clearly contradicts others position,
but in any case, this is beside the point, because last year the debian
project clearly stated by a 3:1 majority that the new wording suits them fine.

> It's what I thought I was agreeing to when I read the SC as part of
> signing up. The archives of -private on master during the SC/DFSG
> discussions match that impression, to my mind:
> 
> ] The reason for Debian to be free software is so that our users can do
> ] cool stuff with it without running into legal problems. I would prefer
> ] not to make the document sound more like a "Pledge of Allegiance to Free
> ] Software", lest we be seen to be marching after ideology regardless of the
> ] end product and the users. The document is a contract we offer to our
> ] community about how we will behave with that community. We offer it to
> ] the people, we do not lay it upon the altar of free software.
> (June 1997)

Ok, well, which is why we have non-free, and voted to keep it, despite the
whish of RMS and the FSF and a few others.

> ] It is not a legal document, it's a social one. Thus, I eschew the extremely
> ] careful language of a legal document in favor of something short and simple
> ] that communicates our philosophy without boring or intimidating the reader.
> (June 1997)

This seems off-topic to the issue at hand.

> ] > There is no mention in the "social contract" that source formats for
> ] > documentation must be provided and that we must be able to modify the
> ] > documentation.
> ] I suppose you could read it that way, but it's not meant that way.
> ] I know of one potential Debian package that places a different copyright
> ] on the documentation than

Re: Firmware & Social Contract: GR proposal

[MJ Ray]

Anthony Towns  wrote
> On Tue, Sep 05, 2006 at 12:53:50PM +0100, MJ Ray wrote:
> > There are people interested.  I think us mere mortals have been hindered
> > by the slowness of the DPL and SPI on these topics.
> You might like to consider replying to:
> Subject: Re: Presumably-unauthorized Open Logo use
> Date: Sat, 1 Jul 2006 18:30:28 +1000
> To: [EMAIL PROTECTED]
> then.

OK.  Will it make any difference?  You already attack my previously-stated
position later in your mail as "irresponsible and inappropriate".

> > We could GR it, but there doesn't seem much objection - just inaction.
> When I asked in April about a week after my term began, Greg (the SPI
> lawyer) replied:
> "I don't think there has been a great deal of interest in registering
>  the Debian logo.  [...] "

These both have little to do with correcting the copyright licence, though.

As I'm sure you know, a copyright licence doesn't let us act against
people who use an independently created, confusingly similar mark, so it
is surely not effective trademark enforcement.  Its main effect is to stop
free software uses of the logo, which is bizarre.  How is the non-free
software licence helping to enforce a trademark in Spain, for example?
Isn't the problem there a lack of a clear trademark policy and process?

[...]
> I haven't seen any interest whatsoever in dealing with this from other
> developers, so I've deprioritised it. If that changes, I'll be happy to
> put it back on my list of things to deal with.

So, it's not that "no one else has been particularly interested", but
that there's no interest from any developers this DPL looks at.

Thanks for the clarification.
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


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

Re: Proposal - Amendment - allow hardware support from non-free into the debian system

[MJ Ray]

Sven Luther <[EMAIL PROTECTED]>
> Well, i think we are going to have too many options on that ballot, i think we
> should do some rationalizing at some point, and keep only a few which will
> represent most opinions, and work on polishing their wordings instead of
> everyone proposing their pet proposal.

I agree, but it's probably inevitable because Steve Langasek made
this a compound proposal, mixing issues, and there are many different
combinations which would resolve it.  Also, our voting is clone-proof,
so hopefully it won't damage the chances of finding the best possible
solution.  Even so, this option is quite different to the others so far.

[...]
> Why do you mention the admin section of the non-free archive ? I mean,
> sections are mostly obsolet with the new pool structure, and it is not clear
> what is meant here.

I mean packages with a Section: control field of non-free/admin.  Even if
it's mostly obsolete, ftpmasters and others are still regulating it, yes?

> If this is clarified, i would second your proposal.

Hope that's sufficient clarification.  Would you second it whether or not I
drop the word 'vital' from it?

[...]
> Notice that the split to non-free will no more happen for etch, i think it is
> doubtful that any other issue will come of those GRs.

Not 100% sure what you mean, but I think this has changed recently and I hope
it's not set in stone.

-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


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

Re: Proposal - Amendment - allow hardware support from non-free into the debian system

[MJ Ray]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Julien BLACHE <[EMAIL PROTECTED]>
> [EMAIL PROTECTED] (MJ Ray) wrote:
> > 3. as a special exception to help users who have vital hardware
>^
> > without free software drivers yet, the Debian system and official CD
>
> We'll soon have a 200+ posts sub-thread trying to come up with a
> definition for "vital hardware" ...
>
> I'd second your proposal without the "vital" word.

That's meant as an explanation, not a requirement.  Accordingly, I drop
the word 'vital' from there and the lead-in.

Thanks,
- --
MJR/slef
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFE/ZBPmUY5euFC5vQRAm5wAJ9GqoEgfdhD3lnZA0rDmasxtw3hVQCcCuy9
FsiqBm5VD2yKvzDnCDypPuA=
=YAqJ
-END PGP SIGNATURE-


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

Re: Firmware & Social Contract: GR proposal

[MJ Ray]

Anthony Towns  wrote:
> Heh, a FAQ on a website overriding the clear and explicit wording from the
> license itself ("Everyone is permitted to copy and distribute verbatim
> copies of this license document, but changing it is not allowed.")? Who
> would've thought...

What the FSF means by verbatim copying is not the usual English meaning,
but what the FSF means by Software isn't the usual either, so that's not a
particular surprise.  Unlike certain other FAQs, that one isn't clearly
rejected by the licence it covers, and there are examples which show how
the copyright holder approaches this.

> I don't think creating a "Debian General Public License" with the same
> terms as the GPL, but without the preamble, and pretending all the
> currently GPLed stuff is licensed under those terms would be in the
> interests of either our users, or the free software community.

How would it be pretending if it was?

> Yet, our social contract says that the Debian System will be 100% free...

The GPL is far closer to 100% free than a source-withheld hard-to-edit
blob of a program.  At least we can see an easy route to make it 100%
free without losing anything.


Really, this argument feels like a proposal that we shouldn't aim to be
good because we can never be perfect.  It sounds like the popular English
state education system approach in the 70s and 80s, that we shouldn't set
high standards for students because it will demoralise the little dears
when they don't score 100%.  It was nonsense then and it's nonsense now.

Yes, it looks like we're probably not going to deliver 100% on the social
contract with etch.  Life's hard and we need to accept that.  Maybe we'll
want to issue a statement about etch and the social contract, or declare
a lower target for this release in advance, but that's different from
declaring that debian's giving up on our social aims forever so its
developers can feel a little better about this failure.

See http://irascibleprofessor.com/comments-12-21-05.htm for a US-centric
comment about the self-esteem movement.  Revising your mission downwards
is just a different form of failure, more commonly used by share-market
corporations than volunteer projects.  Let's shoot for the stars and we
might get into space as a by-product...
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


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

Re: Proposal - Amendment - allow hardware support from non-free into the debian system

[Sven Luther]

On Tue, Sep 05, 2006 at 03:53:00PM +0100, MJ Ray wrote:
> Sven Luther <[EMAIL PROTECTED]>
> > Well, i think we are going to have too many options on that ballot, i think 
> > we
> > should do some rationalizing at some point, and keep only a few which will
> > represent most opinions, and work on polishing their wordings instead of
> > everyone proposing their pet proposal.
> 
> I agree, but it's probably inevitable because Steve Langasek made
> this a compound proposal, mixing issues, and there are many different
> combinations which would resolve it.  Also, our voting is clone-proof,
> so hopefully it won't damage the chances of finding the best possible
> solution.  Even so, this option is quite different to the others so far.

Please read my call for a vote following Frederik's proposal, which Steve said
he may retire his proposal in favour of it.

> [...]
> > Why do you mention the admin section of the non-free archive ? I mean,
> > sections are mostly obsolet with the new pool structure, and it is not clear
> > what is meant here.
> 
> I mean packages with a Section: control field of non-free/admin.  Even if
> it's mostly obsolete, ftpmasters and others are still regulating it, yes?

I mean, why non-free/admin and not others ? Why not clearly defining what is
covered and what not. why not non-free/base (the kernel being in base), and
what if we reorganise sections later on.

> > If this is clarified, i would second your proposal.
> 
> Hope that's sufficient clarification.  Would you second it whether or not I
> drop the word 'vital' from it?

Not really, see above. and yes, if you drop vital, i would do the same.

> [...]
> > Notice that the split to non-free will no more happen for etch, i think it 
> > is
> > doubtful that any other issue will come of those GRs.
> 
> Not 100% sure what you mean, but I think this has changed recently and I hope
> it's not set in stone.

It is too late for etch, whatever happens or not. 

Friendly,

Sven Luther


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

Let's vote ... (Was: kernel firmwares: GR proposal)

[Sven Luther]

Hi all.

We are quickly reaching the point where holding a vote on this issue and still
maintaining a timely etch release, so i believe that we should held a vote on
this issue sooner rather than later.

This GR, which was seen by Steve as orthogonal to his GR, is about the etch
release and not about more generic issues like if firmware are programs, and
or what was meant 10 years ago when the SC was coined, or how we should modify
it.

I thus propose that we held a vote ASAP, a real vote, not a poll, about what
we are going to do about etch :

  1) postpone the non-free firmware issue as proposed in this GR proposal.
  2) delay etch until we finish discussing this issue and then implement the
  resulting course of action.

(Well, 2 is probably the status quo and further discussion, so we don't really
need another option for that, and further discussion serves just as well).

I would like to ask then that :

1) Manoj, can you propose a ballot proposal for this one ? 

2) All those who proposed other GRs, i would like your comment about this, on
wheter this is orthogonal to your proposal. I would strongly recomend that you
either vote for or against delaying this issue post-etch, and continue with
your discussion without being distracted by the issue concerning the etch
release, maybe have a larger discussion following Anthony's proposal
culminating at the Edinburg debconf'07 next july.

So, let's vote on this proposal, and then we can either continue to discuss
this without having to deal with the etch release deadlines, or delay etch
appropriately while we first discuss a solution and then implement it.

Friendly,

Sven Luther
  


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

Re: Proposal - Amendment - allow hardware support from non-free into the debian system

[Julien BLACHE]

MJ Ray <[EMAIL PROTECTED]> wrote:

Hi,

>> > 3. as a special exception to help users who have vital hardware
>>^
>> > without free software drivers yet, the Debian system and official CD
>>
>> We'll soon have a 200+ posts sub-thread trying to come up with a
>> definition for "vital hardware" ...
>>
>> I'd second your proposal without the "vital" word.
>
> That's meant as an explanation, not a requirement.  Accordingly, I drop
> the word 'vital' from there and the lead-in.

Seconded, then.

JB.

-- 
 Julien BLACHE - Debian & GNU/Linux Developer - <[EMAIL PROTECTED]> 
 
 Public key available on  - KeyID: F5D6 5169 
 GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169 


pgpjV1dS6ojoK.pgp
Description: PGP signature

Re: Let's vote ...

[Frank Küster]

Sven Luther <[EMAIL PROTECTED]> wrote:

> I thus propose that we held a vote ASAP, a real vote, not a poll, about what
> we are going to do about etch :
>
>   1) postpone the non-free firmware issue as proposed in this GR proposal.
>   2) delay etch until we finish discussing this issue and then implement the
>   resulting course of action.
[...]
> So, let's vote on this proposal, and then we can either continue to discuss
> this without having to deal with the etch release deadlines, or delay etch
> appropriately while we first discuss a solution and then implement it.

Seconded ;-)
-- 
Frank Küster
Single Molecule Spectroscopy, Protein Folding @ Inst. f. Biochemie, Univ. Zürich
Debian Developer (teTeX/TeXLive)

Re: Proposal - Amendment - allow hardware support from non-free into the debian system

[Sven Luther]

On Tue, Sep 05, 2006 at 03:53:00PM +0100, MJ Ray wrote:
> Sven Luther <[EMAIL PROTECTED]>
> > Well, i think we are going to have too many options on that ballot, i think 
> > we
> > should do some rationalizing at some point, and keep only a few which will
> > represent most opinions, and work on polishing their wordings instead of
> > everyone proposing their pet proposal.
> 
> I agree, but it's probably inevitable because Steve Langasek made
> this a compound proposal, mixing issues, and there are many different
> combinations which would resolve it.  Also, our voting is clone-proof,
> so hopefully it won't damage the chances of finding the best possible
> solution.  Even so, this option is quite different to the others so far.
> 
> [...]
> > Why do you mention the admin section of the non-free archive ? I mean,
> > sections are mostly obsolet with the new pool structure, and it is not clear
> > what is meant here.
> 
> I mean packages with a Section: control field of non-free/admin.  Even if
> it's mostly obsolete, ftpmasters and others are still regulating it, yes?

notice that non-free firmware modules just uploaded where uploaded to
non-free/base.

Friendly,

Sven Luther


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

Re: Proposal - Amendment - allow hardware support from non-free into the debian system

[Marco d'Itri]

[EMAIL PROTECTED] wrote:

>3. as a special exception to help users who have vital hardware 
>without free software drivers yet, the Debian system and official CD 
>images may include hardware-support packages from the admin section of 
>the non-free archive area which conform to all Debian Free Software 
>Guidelines except guideline 2 (Source Code), or an archive section/area 
>with equivalent requirements.
This may include proprietary kernel drivers and will exclude important
firmwares which are not legally modifiable. Both too much and too little
at the same time. I would otherwise support a similar amendment, but I
in this form I consider it harmful to our cause.

-- 
ciao,
Marco


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

Re: Firmware & Social Contract: GR proposal

[Raul Miller]

Perhaps, before we spend too many more years on trying to solve this
problem, we should agree on what "this problem" is?

One issue here is that we are trying to make a statement about what
direction we are heading.  As M.J.Ray states:

  The GPL is far closer to 100% free than a source-withheld
  hard-to-edit blob of a program.

And, as http://lwn.net/Articles/196641/ states:

  Adopting a policy which favors devices having their proprietary
  software in ROM (where it can never, ever be changed) over those
  which accept their firmware from the host (where, maybe, someday
  it could be rebuilt and tinkered with) seems like a step in the
  wrong direction.

Though, the other side of the story is that the ground keeps
shifting underneath us.  (Which is hardly surprising.  Tomorrow's
hardware is new, every month.)

The way I see it, we're drawing lines in the sand, and the sand
is drifting.  We're trying to compensate for where the sand is
going to be next month, next year, and after that, but we're not
omniscient.  On top of that, each of us has different concepts
about what's coming up.

We can agree roughly about where we are going, but even there we
often have little control:  We did not design hardware which would
not function unless we distribute some essential (but non-free)
component, and we did not design the software which hard-wires
these components into itself.

If this is an accurate statement of the problem (is it? if not,
what's a more accurate statement?  is there an "accurate statement"
of the problem which we can all agree on?), then either:

(a) our "lines in the sand" are going to get broken, or
(b) we are going to have to keep on drawing new "lines in the sand", or
(c) we are going to have to come up with some more resilient approach.

As a further note, compromise might be inevitable (it usually is,
when people can not agree on the details of what they are trying
to do -- and our project has long since exceeded the size where
complete agreement, let alone complete understanding, is possible),
but compromises that result in new "lines in the sand" are going to
suffer the same flaw -- the ground is going to keep shifting out from
underneath us.

As a further, further note, I can see the logic in including "the
firmware in the proposed etch release" in etch, for practical
reasons and because that firmware is far enough away from what
some people consider "the operating system and its applications".
On the flip side, I can also see the logic in considering that
firmware "an essential part of the operating system", and can
easily imagine a day when applications include components which
are downloaded onto auxiliary processors (OpenGL is probably
the best "today" example of this sort of thing).

So... we are going to see this problem get bigger in the future,
I think, no matter what we decide today.  [But I'm cheating:
"this" is a variable.]

--
Raul


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

Re: Firmware & Social Contract: GR proposal

[Marco d'Itri]

With this message I formally second aj's proposed resolution from
<[EMAIL PROTECTED]>.

I deeply appreciate this, I believe it is the right step to bring back
Debian to its origins and hopefully will help reducing the tensions in
the project caused by the SC change.


Still, I want to ask you to reconsider point f, which proposes an
in-person debate to be held at the next debconf. This is unfair, because
it excludes from the debate two classes of developers: people who cannot
partecipate to the debconf[1] and people who are not proficient enough
in spoken english to be able to fully express themselves in an in-person
debate.


[1] not just because of money issues, but also because for many people
it is not easy to take a week off work.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Proposal - Amendment - allow hardware support from non-free into the debian system

[Joey Hess]

MJ Ray wrote:
> 3. as a special exception to help users who have vital hardware 
> without free software drivers yet, the Debian system and official CD 
> images may include hardware-support packages from the admin section of 
> the non-free archive area which conform to all Debian Free Software 
> Guidelines except guideline 2 (Source Code), or an archive section/area 
> with equivalent requirements.

This is seriously flawed:

- It ignores all other installation media supported by debian (floppies,
  netboot, hd-media, dvd, etc).
- It says that certian packages from non-free are part of the "Debian system",
  which is a self-contradicting statement.
- It has this strange thing about only stuff from the non-free admin section,
  which is just totally weird. If we drop the useless sections for
  debtags, or divide a section, or decide to put stuff in some other
  section, it magically becomes not a part of Debian?
- It talks about non-free _drivers_, which have not been a topic of any
  debate. No one has suggested including non-free kernel drivers on
  Debian installation media or supporting them in the installer, and I
  am confident it will never happen, for many reasons.

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Firmware

[Joseph Neal]

> It's been a week, and the results from the three polls concerning
> what to do about firmware are currently:
> 
> What is the most important for the release of Etch? (202 votes)
> [0] Release on time (early december) 57%
> Support hardware that requires sourceless firmware   26%
> Do not ship sourceless firmware in main  15%
> 
> Since it appears Debian has to make a choice, which would you 
> prefer we do for etch? (197 votes) [1]
> Allow sourceless firmware in main  63%
> Delay the release of etch (so that we can support18%
>   loading firmware from non-free)
> Drop support for hardware which requires sourceless  17%
>   firmware
> 
> Developer only poll: (83 votes) [2]
> Option 1 "Release etch on time"
> defeats option 3 by 23 votes (51:28)
> defeats option 2 by 52 votes (67:15)
> defeats option 4 by 71 votes (76: 5)
> Option 3 "Support hardware that requires sourceless firmware"
> defeats option 2 by 39 votes (60:21)
> defeats option 4 by 69 votes (74: 5)
> Option 2 "Do not ship sourceless firmware in main"
> defeats option 4 by 41 votes (59:18)
> Option 4 "None of the above"
> comes last
> 
> Obviously each of those polls only includes a self-selected minority
> of the people they try to cover, but the results seem fairly
> consistent both with each other, and what's been discussed so far on
> this list.

Erm.  I'm not sure self-selecting is what I'd call it.  Was this poll
announced on debian-user? usenet?  This is the first I've heard of
it. I'm a debian user and I'd sorta have like to have been counted on
this one since.

Think about it.  What kind of users are going to go to a web forum for
help?  What kind to irc?  Usenet and mailing lists?  This was not a
random sample.

The web forum is naturally going to have a higher proportion new
users and desktop users than usenet and the mailing lists.  This
crucial fact puts a definite skew on the results.  By not soliciting
users outside the web forum you have polled a demographic sample of
only a subset of debian users.  For example I'd think that network
admins and developers are much less likely to be counted, two of the
most important groups in terms of what they give back to debian.  

These results are meaningless. I'll leave it to others to decide if
this was an error of ineptitude or manipulation.  If it was deliberate,
it's the kind of tactic used to start over non-existent weapons of mass
destruction.


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

Re: Proposal - Amendment - allow hardware support from non-free into the debian system

[MJ Ray]

Joey Hess <[EMAIL PROTECTED]>
> MJ Ray wrote:
> > 3. as a special exception to help users who have vital hardware
> > without free software drivers yet, the Debian system and official CD
> > images may include hardware-support packages from the admin section of
> > the non-free archive area which conform to all Debian Free Software
> > Guidelines except guideline 2 (Source Code), or an archive section/area
> > with equivalent requirements.
> 
> This is seriously flawed:
> 
> - It ignores all other installation media supported by debian (floppies,
>   netboot, hd-media, dvd, etc).

No, they are covered as "the Debian system".  It mentions CD images
explicitly because other things I was reading mentioned the CD images
explicitly for whatever reason, so it seemed like a good idea.

> - It says that certian packages from non-free are part of the "Debian system",
>   which is a self-contradicting statement.

Why?  We can as easily define the Debian system to be main + some other
packages as we can define it to be just the main archive area.

> - It has this strange thing about only stuff from the non-free admin section,
>   which is just totally weird. If we drop the useless sections for
>   debtags, or divide a section, or decide to put stuff in some other
>   section, it magically becomes not a part of Debian?

No.  That could be an equivalent requirement, depending on how the
debtags or sections are defined.  Like it or not, the sections are
the current policy and I think it's wrong to combine this vote with
a debtags-replace-sections vote. (From other emails, admin may be the
wrong one... I looked for some particular firmware and I thought it was
in admin, which is why I named that section.  I'll check RSN, but it's
not a crucial point.)

> - It talks about non-free _drivers_, which have not been a topic of any
>   debate. No one has suggested including non-free kernel drivers on
>   Debian installation media or supporting them in the installer, and I
>   am confident it will never happen, for many reasons.

That's only in the explanatory subclause, but firmwares are driver programs
running on the hardware.  This proposal doesn't mention "kernel drivers"
at all, so I don't see how that's relevant.


Apart from maybe possibly getting the wrong section, I think all of those
so-called 'serious flaws' are based on misreading the proposal.

Hope that explains,
-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


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

Re: Proposal - Amendment - allow hardware support from non-free into the debian system

[MJ Ray]

Marco d'Itri <[EMAIL PROTECTED]>
> [EMAIL PROTECTED] wrote:
> >the non-free archive area which conform to all Debian Free Software 
> >Guidelines except guideline 2 (Source Code), or an archive section/area 
> >with equivalent requirements.
> This may include proprietary kernel drivers and will exclude important
> firmwares which are not legally modifiable. Both too much and too little
> at the same time.

How would you exclude proprietary kernel drivers while allowing important
firmwares which are not legally modifiable?

Do you think that Steve Langasek's original proposal would exclude/allow
those in that way?

> I would otherwise support a similar amendment, but I
> in this form I consider it harmful to our cause.

Prove it.

-- 
MJR/slef
My Opinion Only: see http://people.debian.org/~mjr/
Please follow http://www.uk.debian.org/MailingLists/#codeofconduct


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

Re: Proposal - Amendment - allow hardware support from non-free into the debian system

[Joey Hess]

MJ Ray wrote:
> Apart from maybe possibly getting the wrong section, I think all of those
> so-called 'serious flaws' are based on misreading the proposal.

It certianly seems to be based on us having different defintions of
terms including "the Debian system" and "drivers".

AIUI, I would word your proposal something like this:

3. as a special exception to help users who have vital hardware
   without free firmware, the Debian installation media images may
   include selected firmware from non-free archive, which conforms to
   all Debian Free Software Guidelines except guideline 2 (Source Code).

-- 
see shy jo


signature.asc
Description: Digital signature

Re: Proposal - Amendment - allow hardware support from non-free into the debian system

[Marco d'Itri]

[EMAIL PROTECTED] wrote:

>> This may include proprietary kernel drivers and will exclude important
>> firmwares which are not legally modifiable. Both too much and too little
>> at the same time.
>How would you exclude proprietary kernel drivers while allowing important
>firmwares which are not legally modifiable?
Firmwares do not run on the same CPU controlled by the OS, etc. The
difference has already been discussed on this mailing list.

>Do you think that Steve Langasek's original proposal would exclude/allow
>those in that way?
It obviously did not include proprietary drivers. It did not include
more restrictively licensed firmwares either, but it was not supposed to.

>> I would otherwise support a similar amendment, but I
>> in this form I consider it harmful to our cause.
>Prove it.
I should prove that Debian distributing illegal proprietary kernel
drivers would really be a bad idea?
I have better things to do with my time.

-- 
ciao,
Marco


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

Re: Proposal - Amendment - allow hardware support from non-free into the debian system

[Josselin Mouette]

Le mardi 05 septembre 2006 à 17:28 -0400, Joey Hess a écrit :
> AIUI, I would word your proposal something like this:
> 
> 3. as a special exception to help users who have vital hardware
>without free firmware, the Debian installation media images may
>include selected firmware from non-free archive, which conforms to
>all Debian Free Software Guidelines except guideline 2 (Source Code).

Which would sound almost exactly like the amendment I already proposed.
-- 
 .''`.   Josselin Mouette/\./\
: :' :   [EMAIL PROTECTED]
`. `'[EMAIL PROTECTED]
  `-  Debian GNU/Linux -- The power of freedom


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: kernel firmwares: GR proposal

[Thomas Bushnell BSG]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Not for some reason, for some very obvious reasons.  They're not adequate
> as an immediate solution to this problem because separating the firmware
> from the packages that currently contain it is hard and needs development
> and because d-i currently can't (as I understand these threads) cope with
> that split.

Right.  And the problem is that the d-i team seems to say to
themselves, "as long as we never do the work, we can badger the rest
of Debian into sacrificing the Project's principles, and the work will
never be necessary."

The solution requires a little stick to go with the carrot:

"I'm sorry, but the fact that you dithered for eighteen months does
not mean the Project must now sacrifice its principles so that you can
dither some more."

Thomas


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

Re: kernel firmwares: GR proposal

[Thomas Bushnell BSG]

"Marco d'Itri" <[EMAIL PROTECTED]> writes:

> No, it's a contentious issue because some people are trying hard to
> change the values of Debian replacing what was a compromise widely
> accepted by everybody in Debian and most people outside Debian with
> mindlessly following their idea of the DFSG.

I'm sorry, when did Debian accept that compromise?

I must have missed the GR.

Thomas


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

Re: Firmware & Social Contract: GR proposal

[Thomas Bushnell BSG]

Anthony Towns  writes:

> We'll fail to meet it for firmware and logos in etch, including our own
> logo, and to the best of my knowledge, we're yet to consider addressing
> the license of documents like the Debian Manifesto, or the Debian
> Constitution.

What?  Are you declaring now that we will release etch in violation of
the Social Contract?


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

Re: Firmware & Social Contract: GR proposal

[Thomas Bushnell BSG]

Josselin Mouette <[EMAIL PROTECTED]> writes:

> Following the social contract change, we have been able to remove most
> of non-free stuff from the distribution, especially documentation. It
> wasn't easy and we couldn't make it in time for sarge, but we can make
> it in time for etch. For etch, we have the remaining firmware issue. And
> just because we can't meet our expectations for firmwares, we should
> abandon them all?

For me the key question is whether the d-i team is actually doing the
work or not.  Are they?  If the answer is "yes", then I might vote for
a delay.  If the answer is "no", then I see no reason that a delay
will change things.

> First, it is a fact that we are going to release etch with non-free
> firmwares. There is no decision to make here, it is too late. Those
> polls are only a means to legitimate this fact in a political way, by
> making it looking as a decision.

Really?  I'm flabbergasted.  So I can just put whatever nonfree code I
want into a package, and boom, it gets into etch?  Because our
principles do not control our actions?

Thomas


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

Re: Firmware & Social Contract: GR proposal

[Thomas Bushnell BSG]

Anthony Towns  writes:

> No. Ceasing to make commitments we can't keep doesn't mean we should
> stop meeting the commitments we can. Which is why the bullet points you
> didn't quote were in the proposal.

What do you mean that we "can't keep" the commitment to make the
kernel free software?

We just stop shipping the relevant drivers.

It's *trivial*.  If we wanted to keep our commitment, we could do so.
Very easily.

Thomas


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

Re: Let's vote ... (Was: kernel firmwares: GR proposal)

[Anthony Towns]

On Tue, Sep 05, 2006 at 05:54:25PM +0200, Sven Luther wrote:
> We are quickly reaching the point where holding a vote on this issue and still
> maintaining a timely etch release, so i believe that we should held a vote on
> this issue sooner rather than later.
> This GR, which was seen by Steve as orthogonal to his GR, 

Steve's resolution was proposed two weeks ago, this one was proposed one
week ago. The minimum discussion period is two weeks, though I suppose
I could vary that down to one week if it's really that urgent.

I believe Goswin and Wouter are currently working on a solution to
have the firmware issue resolved by technical means; at the moment,
I think it seems pretty reasonable to let them have a week to work on
that before going to a vote.

Cheers,
aj



signature.asc
Description: Digital signature

Re: kernel firmwares: GR proposal

[Russ Allbery]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> writes:

>> Not for some reason, for some very obvious reasons.  They're not
>> adequate as an immediate solution to this problem because separating
>> the firmware from the packages that currently contain it is hard and
>> needs development and because d-i currently can't (as I understand
>> these threads) cope with that split.

> Right.  And the problem is that the d-i team seems to say to themselves,
> "as long as we never do the work, we can badger the rest of Debian into
> sacrificing the Project's principles, and the work will never be
> necessary."

Point 2.1.1 of the Debian Constitution is relevant here.  Under the Debian
Constitution, you have no grounds for expecting the d-i team to work on
this on your preferred time scale.  If you want to get work done that
other people have not completed as fast as you would like, I suggest
investigating how you can do that work yourself.

Not to mention that my impression was that the first part of the problem
that I stated is actually harder than the second part, so I think
targetting the d-i team here in particular is questionable.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: kernel firmwares: GR proposal

[Thomas Bushnell BSG]

Russ Allbery <[EMAIL PROTECTED]> writes:

> Point 2.1.1 of the Debian Constitution is relevant here.  Under the Debian
> Constitution, you have no grounds for expecting the d-i team to work on
> this on your preferred time scale.  If you want to get work done that
> other people have not completed as fast as you would like, I suggest
> investigating how you can do that work yourself.

I am entirely happy for the d-i team to never do the work.  But that
does not mean that the kernel team should therefore be allowed to go
ahead and ship non-free programs in their packages.

And I am entirely happy to do the work to make the kernel packages
free, but I have the feeling that this isn't what's desired.

Point 2.1.1 does not mean that a developer can say "nyaa nyaa nyaa,
i'm shipping nonfree code and you can't stop me, because you can't
order me to remove it, because of point 2.1.1."

I see the task as "make Debian conform to the Social Contract".  I see
there are two ways to accomplish this task:

1) Make the installer able to load the firmware from somewhere other
   than the normal packages, and split the firmware out accordingly,
   or
2) Drop the relevant drivers from the kernel packages.

I would prefer option (1), but I am content with option (2).

I regard the following pseudo-option as unacceptible:

PO) Release in intentional violation of the Social Contract.

If option (1) is too hard to do for the release, then option (2) must
be chosen by default, and yes, I am happy to do the work for option
(2) if that's necessary.

But my unwillingness to do the work for option (1) does not somehow
mean that (PO) must be chosen.

Well, if our principles mean much at all, that is.

Thomas


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

Re: kernel firmwares: GR proposal

[Russ Allbery]

Thomas Bushnell BSG <[EMAIL PROTECTED]> writes:

> I am entirely happy for the d-i team to never do the work.  But that
> does not mean that the kernel team should therefore be allowed to go
> ahead and ship non-free programs in their packages.

That's something different than what you said in your original message,
which was about using a stick to get developers to do work.  I don't agree
with that way of looking at it.

The above is less objectionable and comes down to a question of whether
we, as a project, want to try to solve this problem for etch, postpone it,
or not solve it at all, with the understanding that postponing it has so
far not resulted in a solution later.  I think you've made it clear what
side you're on.

But please, let's not talk about trying to force developers to work on
particular projects.

-- 
Russ Allbery ([EMAIL PROTECTED])   


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

Re: Firmware & Social Contract: GR proposal

[Romain Francoise]

I voted against the SC change back in 2004, and I haven't changed my
mind.  I second the proposal quoted below.

> 
> The Debian Project resolves that:

> (a) The Social Contract shall be reverted to its original form,
> as at http://www.debian.org/social_contract.1.0

> (b) The term "software" as used in the Social Contract shall be
> presumed only to cover programs, scripts, libraries and similar
> executable works to be executed directly as part of the Debian
> System.

> (c) In addition to the commitments made in the Social Contract,
> the Debian System shall only include documentation, images,
> sounds, video, fonts and similar works that meet the Debian
> Free Software Guidelines, and are available in some reasonably
> modifiable form.

> (d) Notwithstanding the above, the Debian Free Software Guidelines
> shall not be applied to logos, firmware or the text of copyright
> licenses that may be included in the Debian System.

> (e) Following the release of etch, the Debian Project Leader shall:
>   i.   ensure that the Debian community has a good understanding
>of the technical and legal issues that prevent the Debian
>Free Software Guidelines from being applied to logos and
>firmware in a manner that meets the needs of our users;
>   ii.  ensure that project resources are made available to
>people working on addressing those issues;
>   iii. provide a report to the Debian community on progress achieved
>in these areas at DebConf 7 in Edinburgh.

> (f) Following the release of etch, the Debian Project as a whole shall
> reopen the question of which commitments should be codified in the
> project's Social Contract. This shall including both an online
> consultation with Debian users, Debian derivatives and the free
> software community, and a public in-person discussion and debate
> at DebConf 7 in Edinburgh in honour of the 10th anniversary of
> the original publication of the Social Contract on the 4th
> of July 1997.
> 

-- 
  ,''`.
 : :' :Romain Francoise <[EMAIL PROTECTED]>
 `. `' http://people.debian.org/~rfrancoise/
   `-


pgpxqFC8tBdxe.pgp
Description: PGP signature