Draft vote on constitutional issues

[Matthew Johnson-12]

As suggested [0] I think we should clarify these issues before any other
votes. As such I'd like to suggest a draft for the vote.

I'm proposing several options for a couple of reasons. Several of them I
would rank above further discussion, but I also want to make sure that
there is an option for everyone on here. I'm trying to clarify our
current situation. Resolving the vote without such a clarification does
not help this. You should all see an option below which you think is the
Status quo, but I'm certain that not everyone agrees with which one, so,
if you want the status quo, please vote for the option which describes
it, not for further discussion. If you _can't_ see what you think is the
status quo below, now is the time to point this out. (note, I'm not
formally proposing this as a vote yet, but would like to fairly soon)

Option 1 - No Supermajority

We do not believe that we should require anything more than a simple
majority for any changes to the constitution or foundation documents.

   - replace Constitution 4.1 point 2 with "Amend this constitution"
   - in Constitution 4.1 point 5, point 3, remove "A Foundation Document
      requires a 3:1 majority for its supersession. "

This option amends the constitution and hence requires a 3:1 majority.

Option 2 - All conflicting GR options require a Supermajority

We believe that any GR which has an option which overrides some or all
of a foundation document, even temporarily, implicitly modifies it to
contain this exception and thus requires a 3:1 majority

   - replace Constitution 4.1 point 5 with "Issue, supersede,
      withdraw, amend and add exceptions to nontechnical policy
      documents and statements."
   - in Constitution 4.1 point 5 add point 4: "All GR options which
      provide exceptions to a foundation document (temporary or
      permanent) implicitly modify the document to contain that
      exception and require a 3:1 majority"

This option amends the constitution and hence requires a 3:1 majority.

Option 4 - Balancing issues between users and freedom

We believe that there will be cases where the project must balance
between our priorities of our users and of Debian remaining 100% free.
Project decisions which make such a balance do not require a
Supermajority, but all others do

   - Add Social Contract 6:

   6. Works that our not 100% free but are required by our users.

   We acknowledge that there may be occasions where it is not possible
   to place the interests of our users first with purely free software.
   As such, we may on occasion provide software which does not meet our
   normal standards of freedom if it is necessary in the interests of
   our users. In all cases we will work towards a free system where such
   compromises are not necessary

   - replace Constitution 4.1 point 5 with "Issue, supersede,
      withdraw, amend and add exceptions to nontechnical policy
      documents and statements."
   - in Constitution 4.1 point 5 add point 4: "All GR options which
      provide exceptions to a foundation document (temporary or
      permanent) implicitly modify the document to contain that
      exception and require a 3:1 majority"

This option amends the constitution and social contract and hence
requires a 3:1 majority.

Option 5 - Temporary overrides without Supermajority

We believe that GRs may temporarily override foundation documents
without requiring a 3:1 majority. Resolutions which are in conflict with
a foundation document and make a permanent change must modify the
foundation document and require a 3:1 majority

   - replace Constitution 4.1 point 5 with "Issue, supersede,
      withdraw, amend and add exceptions to nontechnical policy
      documents and statements."
   - in Constitution 4.1 point 5 add point 4: "All GR options which
      provide permanent exceptions to a foundation document implicitly
      modify the document to contain that exception and require
      a 3:1 majority"
   - in Constitution 4.1 point 5 add point 5: "All GR options which
      provide temporary exceptions to a foundation document only require
      a simple majority to pass.

This option amends the constitution and hence requires a 3:1 majority.

Option 6 - Votes may modify or be a position statement, but must be explicit

We believe that any vote which overrides a Foundation Document modifies
it to contain that exception and must explicitly say so in the proposal
before the vote proceeds.  Such overrides require a 3:1 majority.
 
A GR which explicitly states that it does not override a Foundation
Document but instead offers a project interpretation of that Foundation
Document does not modify the document and therefore only requires a
simple majority.  This is true even if the Secretary disagrees with the
interpretation.  However, such interpretations are not binding on the
project.
 
In the event that it's unclear whether a particular GR falls into the
first group or the second group, the vote should not proceed until this
has been clarified in the GR.
 
   - replace Constitution 4.1 point 5 with "Issue, supersede,
      withdraw, amend and add exceptions to nontechnical policy
      documents and statements."
   - in Constitution 4.1 point 5 add point 4: "All GR options which
      provide exceptions to a foundation document (temporary or
      permanent) implicitly modify the document to contain that
      exception and require a 3:1 majority"
   - in Constitution 4.1 add a point between 5 and 6, renumbering
     subsequent points:
     "Clarify and provide interpretations of Foundation Documents, such
     interpretations being non-binding."
   - in Constitution A.3 add point 5: "Options which the Secretary deems
      to in some way conflict with one of the Foundation Documents must
      either explicitly amend the Foundation Document (in which case
      they require a 3:1 majority) or they must explicitly say that this
      is an interpretation and they do not conflict. Any vote which
      contains an ambiguous option will not be run until it is clarified"

This option amends the constitution and hence requires a 3:1 majority.

0. http://lists.debian.org/debian-vote/2009/05/msg00003.html

Matt
--
Matthew Johnson

[Luk Claes]

Matthew Johnson wrote:

> As suggested [0] I think we should clarify these issues before any other
> votes. As such I'd like to suggest a draft for the vote.
>
> I'm proposing several options for a couple of reasons. Several of them I
> would rank above further discussion, but I also want to make sure that
> there is an option for everyone on here. I'm trying to clarify our
> current situation. Resolving the vote without such a clarification does
> not help this. You should all see an option below which you think is the
> Status quo, but I'm certain that not everyone agrees with which one, so,
> if you want the status quo, please vote for the option which describes
> it, not for further discussion. If you _can't_ see what you think is the
> status quo below, now is the time to point this out. (note, I'm not
> formally proposing this as a vote yet, but would like to fairly soon)

I think trying to propose many options together is very wrong as you are
very probably not objective for all the options nor will you be able to
word it properly for the ones that do care about an option you don't
really care about.

The other risk you take by proposing many options at once is to mix
unrelated things in the same vote IMHO.

> Option 1 - No Supermajority
>
> We do not believe that we should require anything more than a simple
> majority for any changes to the constitution or foundation documents.
>
>    - replace Constitution 4.1 point 2 with "Amend this constitution"
>    - in Constitution 4.1 point 5, point 3, remove "A Foundation Document
>       requires a 3:1 majority for its supersession. "
>
> This option amends the constitution and hence requires a 3:1 majority.

I would be very surprised if this option would get enough seconds if you
would propose it.

> Option 2 - All conflicting GR options require a Supermajority
>
> We believe that any GR which has an option which overrides some or all
> of a foundation document, even temporarily, implicitly modifies it to
> contain this exception and thus requires a 3:1 majority

This all boils down to the definition of override which I tried to state
in the other thread. If you go by my definition, this is really a
non-option IMHO.

> Option 4 - Balancing issues between users and freedom
>
> We believe that there will be cases where the project must balance
> between our priorities of our users and of Debian remaining 100% free.
> Project decisions which make such a balance do not require a
> Supermajority, but all others do
>
>    - Add Social Contract 6:
>
>    6. Works that our not 100% free but are required by our users.
>
>    We acknowledge that there may be occasions where it is not possible
>    to place the interests of our users first with purely free software.
>    As such, we may on occasion provide software which does not meet our
>    normal standards of freedom if it is necessary in the interests of
>    our users. In all cases we will work towards a free system where such
>    compromises are not necessary
>
>    - replace Constitution 4.1 point 5 with "Issue, supersede,
>       withdraw, amend and add exceptions to nontechnical policy
>       documents and statements."
>    - in Constitution 4.1 point 5 add point 4: "All GR options which
>       provide exceptions to a foundation document (temporary or
>       permanent) implicitly modify the document to contain that
>       exception and require a 3:1 majority"

Same remark as above.

> This option amends the constitution and social contract and hence
> requires a 3:1 majority.

This option does not look related to supermajority requirements to me.

> Option 5 - Temporary overrides without Supermajority
>
> We believe that GRs may temporarily override foundation documents
> without requiring a 3:1 majority. Resolutions which are in conflict with
> a foundation document and make a permanent change must modify the
> foundation document and require a 3:1 majority
>
>    - replace Constitution 4.1 point 5 with "Issue, supersede,
>       withdraw, amend and add exceptions to nontechnical policy
>       documents and statements."
>    - in Constitution 4.1 point 5 add point 4: "All GR options which
>       provide permanent exceptions to a foundation document implicitly
>       modify the document to contain that exception and require
>       a 3:1 majority"
>    - in Constitution 4.1 point 5 add point 5: "All GR options which
>       provide temporary exceptions to a foundation document only require
>       a simple majority to pass.
>
> This option amends the constitution and hence requires a 3:1 majority.

This boils down to the definition of override again...

> Option 6 - Votes may modify or be a position statement, but must be explicit
>
> We believe that any vote which overrides a Foundation Document modifies
> it to contain that exception and must explicitly say so in the proposal
> before the vote proceeds.  Such overrides require a 3:1 majority.

This is already the case AFAICS

> A GR which explicitly states that it does not override a Foundation
> Document but instead offers a project interpretation of that Foundation
> Document does not modify the document and therefore only requires a
> simple majority.  This is true even if the Secretary disagrees with the
> interpretation.  However, such interpretations are not binding on the
> project.

This again boils down to the definition of override...

Cheers

Luk

PS: There is a reason why I send the mail about the definitions of the
terms even if Kurt as well as you seem to ignore it.


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Matthew Johnson-12]

On Sat May 02 00:32, Luk Claes wrote:
> I think trying to propose many options together is very wrong as you are
> very probably not objective for all the options nor will you be able to
> word it properly for the ones that do care about an option you don't really
> care about.

I would vote all of these above Further Discussion, so I think it is
legitimate for me to propose and second them. Further more, in this
specific case I do not believe that Debian would be well served by a
vote which does not list all those options. I am trying very hard to
make sure that people are not voting FD first.

> The other risk you take by proposing many options at once is to mix
> unrelated things in the same vote IMHO.

I am trying to be careful not to do this, I definitely believe that all
of the below are legitimate alternative options which very definitely
should be on the same ballot, as they address the same thing: making it
clear what options require a supermajority.

>> Option 1 - No Supermajority
>>
> I would be very surprised if this option would get enough seconds if you
> would propose it.

Then fine, it can be removed. I have seen, I think, at least 3 mails to
the lists explicitly suggesting this, however.

>> Option 2 - All conflicting GR options require a Supermajority
>>
>> We believe that any GR which has an option which overrides some or all
>> of a foundation document, even temporarily, implicitly modifies it to
>> contain this exception and thus requires a 3:1 majority
>
> This all boils down to the definition of override which I tried to state in
> the other thread. If you go by my definition, this is really a non-option
> IMHO.

I'll address that below

>> This option amends the constitution and social contract and hence
>> requires a 3:1 majority.
>
> This option does not look related to supermajority requirements to me.

I just had to clarify this on IRC too. This option is "all conflicting
options need supermajority even if temporary", but then amending the SC
so that balancing SC1 and SC4 isn't conflicting with the SC. Sorry if
that wasn't clear.

>> Option 6 - Votes may modify or be a position statement, but must be explicit
>>
>> We believe that any vote which overrides a Foundation Document modifies
>> it to contain that exception and must explicitly say so in the proposal
>> before the vote proceeds.  Such overrides require a 3:1 majority.
>
> This is already the case AFAICS

The entire point of this vote is that opinions vary on what is already
the case. You think that option 6 is already the case. I think that
option 2 is already the case and some people think that option 5  is
already the case. All of use are absolutely convinced it's the only way
to read the constitution. I'm fed up of having arguments about what it
means, whether a particular reading is consistent, or what the spirit of
the constitution is. I want it to be explicit, hence this vote to
clarify it.

> PS: There is a reason why I send the mail about the definitions of the
> terms even if Kurt as well as you seem to ignore it.

I posted a while back citing several types of vote option [0], with some
examlpes. I'm maybe not using the terminology you'd like, but I hope
you can see what I mean. Here they are again:

1. Option X conforms to a foundation document (clearly not 3:1)
2. Option X changes a foundation document (clearly 3:1)
3. Option X overrides a foundation document, possibly temporarily (?)
4. Option X is declared not to be in conflict with a foundation document (?)
5. Option X conflicts with a foundation document, but explicitly doesn't
   want to override the FD (?)
6. Option X would appear that it might contradict an FD, but doesn't say
   which of 2-5 it is.

1. and 2. are what we wish every vote were like.

3. is things like "we agree that the kernel modules aren't free, but
we'll ship them anyway" or "we'll ship them for this release".

4. is things like "we think that firmware can be its own source, so
shipping blobs is fine"

5. is something like "Allow Lenny to release with  firmware blobs.  This
does not override the DFSG", which I don't think makes any sense.

Now, I understand you don't like the use of 'override' when describing
option 3, I'm happy to describe it as something else, but _I_ think that
the constitution at the moment requires 3:1 majority for this sort of
vote. I know other people are equally certain it does not, but this is
why I want to clarify it one way or another, to avoid future upset.

Incidentally my point of view is that 3 requires supermajority, 4 does
not and that 5 and 6 should be rejected by the secretary as invalid.

I hope that has explained things better and you can see where I'm coming
from,
Matt

0. http://lists.debian.org/debian-vote/2009/03/msg00091.html
--
Matthew Johnson

[Steve Langasek]

On Sat, May 02, 2009 at 12:32:26AM +0200, Luk Claes wrote:
>> Option 1 - No Supermajority

>> We do not believe that we should require anything more than a simple
>> majority for any changes to the constitution or foundation documents.

>>    - replace Constitution 4.1 point 2 with "Amend this constitution"
>>    - in Constitution 4.1 point 5, point 3, remove "A Foundation Document
>>       requires a 3:1 majority for its supersession. "

>> This option amends the constitution and hence requires a 3:1 majority.

> I would be very surprised if this option would get enough seconds if you  
> would propose it.

Hmm, I wouldn't second this in its present form because I don't see any
reason to change the supermajority requirement for amending the constitution
- I don't think anyone has ever disputed the meaning of this requirement,
and it's been there since well before the Foundation Documents supermajority
requirement was instituted.  But I would strongly consider seconding (as one
option among many) a proposal to remove the 3:1 supermajority requirement
for amending Foundation Documents, because I think the most recent fiasco
has given cause to reevaluate the reasons we required a supermajority in the
first place.

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@...                                     vorlon@...


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Matthew Johnson-12]

On Sun May 10 04:13, Steve Langasek wrote:
> Hmm, I wouldn't second this in its present form because I don't see any
> reason to change the supermajority requirement for amending the constitution
> - I don't think anyone has ever disputed the meaning of this requirement,
> and it's been there since well before the Foundation Documents supermajority
> requirement was instituted.  But I would strongly consider seconding (as one
> option among many) a proposal to remove the 3:1 supermajority requirement
> for amending Foundation Documents, because I think the most recent fiasco
> has given cause to reevaluate the reasons we required a supermajority in the
> first place.

Yes, I was wondering if that was a good idea.

Do you want to draft that?

Matt

--
Matthew Johnson

[Luk Claes]

Matthew Johnson wrote:
> On Sat May 02 00:32, Luk Claes wrote:

>> PS: There is a reason why I send the mail about the definitions of the
>> terms even if Kurt as well as you seem to ignore it.
>
> I posted a while back citing several types of vote option [0], with some
> examlpes. I'm maybe not using the terminology you'd like, but I hope
> you can see what I mean. Here they are again:
>
> 1. Option X conforms to a foundation document (clearly not 3:1)
> 2. Option X changes a foundation document (clearly 3:1)
> 3. Option X overrides a foundation document, possibly temporarily (?)

Not possible. You can only override a decision and amending a foundation
document is the previous option.

> 4. Option X is declared not to be in conflict with a foundation document (?)
> 5. Option X conflicts with a foundation document, but explicitly doesn't
>    want to override the FD (?)
> 6. Option X would appear that it might contradict an FD, but doesn't say
>    which of 2-5 it is.

4-6 are normal position statements AFAICS.

> 1. and 2. are what we wish every vote were like.
>
> 3. is things like "we agree that the kernel modules aren't free, but
> we'll ship them anyway" or "we'll ship them for this release".

This one would be in 4-6 AFAICS.

> 4. is things like "we think that firmware can be its own source, so
> shipping blobs is fine"
>
> 5. is something like "Allow Lenny to release with  firmware blobs.  This
> does not override the DFSG", which I don't think makes any sense.

One cannot override a document.

As the DFSG is a document that state our guidelines of what is free, I
don't see how it would get changed even temporary when we would have a
vote on 'Allow Lenny to release with firmware blobs'.

> Now, I understand you don't like the use of 'override' when describing
> option 3, I'm happy to describe it as something else, but _I_ think that
> the constitution at the moment requires 3:1 majority for this sort of
> vote. I know other people are equally certain it does not, but this is
> why I want to clarify it one way or another, to avoid future upset.

Well, what I propose to do is to read the constitution and use its terms
instead, which would ease these discussions a lot AFAICS.

Cheers

Luk


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Matthew Johnson-12]

On Sun May 10 18:34, Luk Claes wrote:
> > 3. Option X overrides a foundation document, possibly temporarily (?)
>
> Not possible. You can only override a decision and amending a foundation
> document is the previous option.

What would you call the vote to ship non-free software in etch? Because
that is what I mean. We are agreeing to do something which the
foundation document said we would not, but only for a certain period of
time (etch).

I don't _care_ what you call that, I call it a temporary override of a
foundation document.

> > 4. Option X is declared not to be in conflict with a foundation document (?)
> > 5. Option X conflicts with a foundation document, but explicitly doesn't
> >    want to override the FD (?)
> > 6. Option X would appear that it might contradict an FD, but doesn't say
> >    which of 2-5 it is.
>
> 4-6 are normal position statements AFAICS.

That's certainly a point of view, but not the one every holds.

> > 1. and 2. are what we wish every vote were like.
> >
> > 3. is things like "we agree that the kernel modules aren't free, but
> > we'll ship them anyway" or "we'll ship them for this release".
>
> This one would be in 4-6 AFAICS.

Why do you say that. This is definitely contrary to a foundation
document (if you don't think it is, please pick a different example
which is) and we want it to be binding. Ergo, not a position statement.

> > 5. is something like "Allow Lenny to release with  firmware blobs.  This
> > does not override the DFSG", which I don't think makes any sense.
>
> One cannot override a document.

See above. I'm not interested in arguing about terminology, I think it's
clear what I mean by 'override a document', please suggest alternative
phrasing if you prefer.

> As the DFSG is a document that state our guidelines of what is free, I
> don't see how it would get changed even temporary when we would have a
> vote on 'Allow Lenny to release with firmware blobs'.

OK, if you prefer it changes the SC to allow exceptions which don't
conform to the DFSG. I'm sorry if I'm not being clear here,  I was
hoping people would get the gist of what I meant, but I'll try and be
more pedantic in future.

> > Now, I understand you don't like the use of 'override' when describing
> > option 3, I'm happy to describe it as something else, but _I_ think that
> > the constitution at the moment requires 3:1 majority for this sort of
> > vote. I know other people are equally certain it does not, but this is
> > why I want to clarify it one way or another, to avoid future upset.
>
> Well, what I propose to do is to read the constitution and use its terms
> instead, which would ease these discussions a lot AFAICS.

That would be great, unfortunately there seems to be a bit of a grey
area here, hence the problems.

Please do suggest better terms.

Matt

--
Matthew Johnson

[Steve Langasek]

On Sun, May 10, 2009 at 01:12:27PM +0100, Matthew Johnson wrote:

> On Sun May 10 04:13, Steve Langasek wrote:
> > Hmm, I wouldn't second this in its present form because I don't see any
> > reason to change the supermajority requirement for amending the constitution
> > - I don't think anyone has ever disputed the meaning of this requirement,
> > and it's been there since well before the Foundation Documents supermajority
> > requirement was instituted.  But I would strongly consider seconding (as one
> > option among many) a proposal to remove the 3:1 supermajority requirement
> > for amending Foundation Documents, because I think the most recent fiasco
> > has given cause to reevaluate the reasons we required a supermajority in the
> > first place.

> Yes, I was wondering if that was a good idea.

> Do you want to draft that?

If one of the other options gets enough seconds to become a formal GR
proposal, I would consider drafting a suitable amendment.  I'm not going to
spend the time on it when there isn't yet a GR on the table.

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@...                                     vorlon@...


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Wouter Verhelst]

On Sun, May 10, 2009 at 06:59:41PM +0100, Matthew Johnson wrote:

> On Sun May 10 18:34, Luk Claes wrote:
> > > 3. Option X overrides a foundation document, possibly temporarily (?)
> >
> > Not possible. You can only override a decision and amending a foundation
> > document is the previous option.
>
> What would you call the vote to ship non-free software in etch? Because
> that is what I mean. We are agreeing to do something which the
> foundation document said we would not, but only for a certain period of
> time (etch).
>
> I don't _care_ what you call that, I call it a temporary override of a
> foundation document.

I think this is the core of the disagreement. I do not call it a
temporary override of a foundation document; I call it a temporary
practical consensus between "the needs of our users" and "the needs of
the free software community".

This is an option which we took reluctantly; but the only other option
was to delay the release even longer, which was not the best thing to
do.

We didn't say "we're throwing the DFSG out the window". We said "we're
trying, but it will take a shitload of work, and we don't think delaying
the release to get this done is worth it". Is that overriding a
foundation document? Not from where I'm standing.

--
<Lo-lan-do> Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Matthew Johnson-12]

On Tue May 12 17:06, Wouter Verhelst wrote:

> > What would you call the vote to ship non-free software in etch? Because
> > that is what I mean. We are agreeing to do something which the
> > foundation document said we would not, but only for a certain period of
> > time (etch).
> >
> > I don't _care_ what you call that, I call it a temporary override of a
> > foundation document.
>
> I think this is the core of the disagreement. I do not call it a
> temporary override of a foundation document; I call it a temporary
> practical consensus between "the needs of our users" and "the needs of
> the free software community".

Which is contradictory to one of our foundation documents.

> We didn't say "we're throwing the DFSG out the window". We said "we're
> trying, but it will take a shitload of work, and we don't think delaying
> the release to get this done is worth it". Is that overriding a
> foundation document? Not from where I'm standing.

Can you think of anything you would count as that? Something where the
project is saying "We are agreeing to definitely do something which the
social contract said we would not, but we aren't permanently modifying
it".

Perhaps we need a vote option which says "these things definitely aren't
something we need 3:1 for, regardless of what you think they are"

Matt

--
Matthew Johnson

[Thomas Bushnell BSG]

On Tue, 2009-05-12 at 17:06 +0200, Wouter Verhelst wrote:
> I think this is the core of the disagreement. I do not call it a
> temporary override of a foundation document; I call it a temporary
> practical consensus between "the needs of our users" and "the needs of
> the free software community".

I don't understand.

Either Social Contract section one and the DFSG prohibit the
distribution of a non-free blob in the release, or they do not.

If they prohibit it, then it is an override to distribute
notwithstanding the prohibition.

If they do not prohibit it, then no resolution is necessary.

You seem to say an inconsistent thing: that they do prohibit it, and we
can avoid that prohibition by calling it a "practical consensus" instead
of an "override".  Surely, however, it is the effect that matters, and
not the label you give it.

Thomas



--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Luk Claes]

Thomas Bushnell BSG wrote:

> On Tue, 2009-05-12 at 17:06 +0200, Wouter Verhelst wrote:
>> I think this is the core of the disagreement. I do not call it a
>> temporary override of a foundation document; I call it a temporary
>> practical consensus between "the needs of our users" and "the needs of
>> the free software community".
>
> I don't understand.
>
> Either Social Contract section one and the DFSG prohibit the
> distribution of a non-free blob in the release, or they do not.

This 'in the release' is bogus, I guess you mean in 'main'?

> If they prohibit it, then it is an override to distribute
> notwithstanding the prohibition.
>
> If they do not prohibit it, then no resolution is necessary.
>
> You seem to say an inconsistent thing: that they do prohibit it, and we
> can avoid that prohibition by calling it a "practical consensus" instead
> of an "override".  Surely, however, it is the effect that matters, and
> not the label you give it.

Well that's the thing with goals, they are not strict rules, but we do
try to reach them (though not at all cost) ...

Cheers

Luk


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Giacomo A. Catenazzi]

Thomas Bushnell BSG wrote:

> On Tue, 2009-05-12 at 17:06 +0200, Wouter Verhelst wrote:
>> I think this is the core of the disagreement. I do not call it a
>> temporary override of a foundation document; I call it a temporary
>> practical consensus between "the needs of our users" and "the needs of
>> the free software community".
>
> I don't understand.
>
> Either Social Contract section one and the DFSG prohibit the
> distribution of a non-free blob in the release, or they do not.
>
> If they prohibit it, then it is an override to distribute
> notwithstanding the prohibition.
>
> If they do not prohibit it, then no resolution is necessary.
>
> You seem to say an inconsistent thing: that they do prohibit it, and we
> can avoid that prohibition by calling it a "practical consensus" instead
> of an "override".  Surely, however, it is the effect that matters, and
> not the label you give it.

DFSG is a guideline and a target: we must no go far as the nearest point
we reached, but it still a guideline.
Consider:
- we never had a full DFSG Debian (also when DFSG was written)
- we have "RC" also on stable releases. What should we do in such cases?
   Block all dDbian website, all mirrors, etc. because it is clearly against
   our foundations? No.

Where to put the line? This is the main problem: we have different interpretations
and our foundation documents (and related discussions) doesn't provide us
a true (and clear) interpretation.
So I applaud the recent discussion to rewrite (better, clearer) our foundation
documents.

ciao
        cate


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Manoj Srivastava]

On Tue, May 12 2009, Wouter Verhelst wrote:

> On Sun, May 10, 2009 at 06:59:41PM +0100, Matthew Johnson wrote:
>> On Sun May 10 18:34, Luk Claes wrote:
>> > > 3. Option X overrides a foundation document, possibly temporarily (?)
>> >
>> > Not possible. You can only override a decision and amending a foundation
>> > document is the previous option.
>>
>> What would you call the vote to ship non-free software in etch? Because
>> that is what I mean. We are agreeing to do something which the
>> foundation document said we would not, but only for a certain period of
>> time (etch).
>>
>> I don't _care_ what you call that, I call it a temporary override of a
>> foundation document.
>
> I think this is the core of the disagreement. I do not call it a
> temporary override of a foundation document; I call it a temporary
> practical consensus between "the needs of our users" and "the needs of
> the free software community".

        I thought we had agreed to adhere to a document that lays out
 how these conflicts between the need of the users and the free software
 pledge we made is to be resolved:

,----
|    5. Works that do not meet our free software standards
|
|       We acknowledge that some of our users require the use of works
|       that do not conform to the Debian Free Software Guidelines. We
|       have created "contrib" and "non-free" areas in our archive for
|       these works.  
`----

        As I understand it, we, as a project, have acceoted that there
 is tension between the needs of our users, and the  dictates of free
 software; and the solution we have come up with is called "contrib" and
 "non-free" areas in our archive.

        Isn't that perfectly clear?

        manoj
--
Non-sequiturs make me eat lampshades.
Manoj Srivastava <srivasta@...> <http://www.debian.org/~srivasta/>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Thomas Bushnell BSG]

On Tue, 2009-05-12 at 20:09 +0200, Luk Claes wrote:
> > Either Social Contract section one and the DFSG prohibit the
> > distribution of a non-free blob in the release, or they do not.
>
> This 'in the release' is bogus, I guess you mean in 'main'?

Debian is only free software.  Non-free is distributed by Debian, but it
is not part of Debian.  By "in the release" I mean the released versions
of Debian (which includes only main and optional).  

> > If they prohibit it, then it is an override to distribute
> > notwithstanding the prohibition.
> >
> > If they do not prohibit it, then no resolution is necessary.
> >
> > You seem to say an inconsistent thing: that they do prohibit it, and we
> > can avoid that prohibition by calling it a "practical consensus" instead
> > of an "override".  Surely, however, it is the effect that matters, and
> > not the label you give it.
>
> Well that's the thing with goals, they are not strict rules, but we do
> try to reach them (though not at all cost) ...

Perhaps you should propose an amendment to our Social Contract, which
speaks not of goals and aims, but of promises.  Indeed, the point behind
the language of *contract* is that these are not merely goals, but firm
promises.  You presumably would support an amendment to section one of
the social contract, changing it from a promise into a statement of a
goal.  But such an amendment has not yet been passed, and your clear
declaration that you are not willing abide by the social contract as
written is troubling.

Thomas



--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Thomas Bushnell BSG]

On Wed, 2009-05-13 at 10:53 +0200, Giacomo A. Catenazzi wrote:
>
> DFSG is a guideline and a target: we must no go far as the nearest point
> we reached, but it still a guideline.
> Consider:
> - we never had a full DFSG Debian (also when DFSG was written)
> - we have "RC" also on stable releases. What should we do in such cases?
>    Block all dDbian website, all mirrors, etc. because it is clearly against
>    our foundations? No.

The Social Contract does not leave vague how we use the DFSG.  It could
say that we take the DFSG as a guideline, or as a target, but it does
not.  It does not say that we try to abide by it, or that we weigh it
against other things; it says that we *do* abide by it, 100%.  I wonder,
how could it be written even more strongly?  I have the feeling that if
it said "we will never intentionally include non-free software in
Debian, no matter what the circumstances" you would still start telling
us that this is a mere statement of goals and intentions, but not
anything actually binding.

Of *course* there will be bugs.  We cannot promise not to make mistakes.
The argument is *not* about whether non-free things get in
unintentionally.  We can't make a promise never to make a mistake.  But
we can promise not to intentionally include non-free software, and it is
this promise which we have now broken twice.

Note that the Social Contract does *not* say that we treat non-free
things as bugs just like other bugs.  We make no promise about other
bugs, except the general one to prioritize the interests of the free
software community and our users, both of which involve fixing bugs.
But section one doesn't just say it's a goal, or a priority, but says
that it is actually a *promise* not just to try hard, but *never* to
release non-free software as part of Debian.

> Where to put the line? This is the main problem: we have different interpretations
> and our foundation documents (and related discussions) doesn't provide us
> a true (and clear) interpretation.

I think there is nothing unclear about it.  We have a perfectly clear
firm promise, and we have some people who do not want a firm clear
promise, and are willing to pretend that the social contract doesn't say
"100% free software".

Thomas



--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Philipp Kern-4]

On 2009-05-13, Thomas Bushnell BSG <tb@...> wrote:

>> DFSG is a guideline and a target: we must no go far as the nearest point
>> we reached, but it still a guideline.
>> Consider:
>> - we never had a full DFSG Debian (also when DFSG was written)
>> - we have "RC" also on stable releases. What should we do in such cases?
>>    Block all dDbian website, all mirrors, etc. because it is clearly against
>>    our foundations? No.
> The Social Contract does not leave vague how we use the DFSG.  It could
> say that we take the DFSG as a guideline, or as a target, but it does
> not.

[...]
> Note that the Social Contract does *not* say that we treat non-free
> things as bugs just like other bugs.  We make no promise about other
> bugs, except the general one to prioritize the interests of the free
> software community and our users, both of which involve fixing bugs.
> But section one doesn't just say it's a goal, or a priority, but says
> that it is actually a *promise* not just to try hard, but *never* to
> release non-free software as part of Debian.

Actually, going by the word of the Social Contract, it does not speak
of releases at all.

Regards,
Philipp Kern


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Luk Claes]

Thomas Bushnell BSG wrote:
> On Tue, 2009-05-12 at 20:09 +0200, Luk Claes wrote:
>>> Either Social Contract section one and the DFSG prohibit the
>>> distribution of a non-free blob in the release, or they do not.
>> This 'in the release' is bogus, I guess you mean in 'main'?
>
> Debian is only free software.  Non-free is distributed by Debian, but it
> is not part of Debian.  By "in the release" I mean the released versions
> of Debian (which includes only main and optional).  

We don't have a component called optional, nor do we only distribute our
releases.

>>> If they prohibit it, then it is an override to distribute
>>> notwithstanding the prohibition.
>>>
>>> If they do not prohibit it, then no resolution is necessary.
>>>
>>> You seem to say an inconsistent thing: that they do prohibit it, and we
>>> can avoid that prohibition by calling it a "practical consensus" instead
>>> of an "override".  Surely, however, it is the effect that matters, and
>>> not the label you give it.
>> Well that's the thing with goals, they are not strict rules, but we do
>> try to reach them (though not at all cost) ...
>
> Perhaps you should propose an amendment to our Social Contract, which
> speaks not of goals and aims, but of promises.  Indeed, the point behind
> the language of *contract* is that these are not merely goals, but firm
> promises.  You presumably would support an amendment to section one of
> the social contract, changing it from a promise into a statement of a
> goal.  But such an amendment has not yet been passed, and your clear
> declaration that you are not willing abide by the social contract as
> written is troubling.

It's already included in there: Debian will remain 100% free. As we're
only improving, I don't see how it's not a goal as we were never 100%
free, we are not 100% free and probably will never be 100% free.

Cheers

Luk


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Philipp Kern-4]

On 2009-05-13, Manoj Srivastava <srivasta@...> wrote:

> ,----
>|    5. Works that do not meet our free software standards
>|
>|       We acknowledge that some of our users require the use of works
>|       that do not conform to the Debian Free Software Guidelines. We
>|       have created "contrib" and "non-free" areas in our archive for
>|       these works.  
> `----
>         As I understand it, we, as a project, have acceoted that there
>  is tension between the needs of our users, and the  dictates of free
>  software; and the solution we have come up with is called "contrib" and
>  "non-free" areas in our archive.
>         Isn't that perfectly clear?

Sure, but why the heck was the discussion if we should delay the release
instead of moving the kernel to non-free because it's tainted with few
binary blobs?

Kind regards,
Philipp Kern


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Giacomo A. Catenazzi]

Thomas Bushnell BSG wrote:
> On Wed, 2009-05-13 at 10:53 +0200, Giacomo A. Catenazzi wrote:
>> DFSG is a guideline and a target: we must no go far as the nearest point
>> we reached, but it still a guideline.
>> Consider:
>> - we never had a full DFSG Debian (also when DFSG was written)
>> - we have "RC" also on stable releases. What should we do in such cases?
>>    Block all dDbian website, all mirrors, etc. because it is clearly against
>>    our foundations? No.

> The Social Contract does not leave vague how we use the DFSG.  It could
> say that we take the DFSG as a guideline, or as a target, but it does
> not.  

"We provide the guidelines that we use to determine (...)"
DFSG is that guideline. "Guideline" indicates direction.
(note that it is in the sentence, not as acronym)

"We promise (...) will be free". *will* indicate a future intention.
we must not add more non-free software (but by errors), and we should
try to remove non-free (the target).

> It does not say that we try to abide by it, or that we weigh it
> against other things; it says that we *do* abide by it, 100%.  I wonder,
> how could it be written even more strongly?

So, I think the actual social contract is not so strong.

"Debian releases only distributions that contain only softwares, documentations
and art-works that is free according to DFSG" would be stronger.

But it is very dangerous to have to strict rules:
if we found a non-free software (outside the exceptions) in potato o in lenny,
do we annihilate because we don't follow the guidelines?

As you wrote, there will always bugs, and also wrong attributed code,
unchecked licenses, ...; so I would not like to have a stronger statement.

> I have the feeling that if
> it said "we will never intentionally include non-free software in
> Debian, no matter what the circumstances" you would still start telling
> us that this is a mere statement of goals and intentions, but not
> anything actually binding.
>
> Of *course* there will be bugs.  We cannot promise not to make mistakes.
> The argument is *not* about whether non-free things get in
> unintentionally.  We can't make a promise never to make a mistake.  But
> we can promise not to intentionally include non-free software, and it is
> this promise which we have now broken twice.

We I joined debian, I read that we (DD) was never obliged to do things
(but with a kind request to retire gracefully if we cannot
improve debian). But I don't find anymore such document.

I cannot work on Debian kernel: I've no time and capabilities, so
I cannot help reducing such non-free code, but I'm helping in
other parts.

So what we should do?
Never release, because we have no man-power on some complex tasks?
But so we throw the other works, where we removed non-free software,
and improved freedom.

I try to do most as I can do, to have a 100% free Debian,
on my packages, and on other packages, but you are telling me
that I go to every RC bug and try harder to resolve bugs?
[I can do it, but I'm sure it is a waste of time]

ciao
        cate


--
To UNSUBSCRIBE, email to debian-vote-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...