Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)

[Bill Allombert]

On Fri, Jan 13, 2006 at 12:09:49AM +0100, martin f krafft wrote:
> also sprach Adeodato Sim? <[EMAIL PROTECTED]> [2006.01.10.0455 +0100]:
> >  Formally, the Debian Project will include in the main section of
> >  its distribution works licensed under the GNU Free Documentation
> >  License that include no Invariant Sections, no Cover Texts, no
> >  Acknowledgements, and no Dedications, unless permission to remove
> >  them is granted.
> 
> I'm a late entry to the thread, please excuse.
> 
> If we kicked all GFDL out of main, how many upstreams would
> reconsider their choice of licence? None? Few? Some? Many?

If we don't kick it out, the answer is simple: None.

> I am <-> that short of seconding dato's proposal, but I believe that
> Debian is also in a position to make the world a better place by
> asking upstreams to rethink. Or am I being completely na?ve here?

A lot of people have used the GFDL without actually read it and got
bitten. This is clear from the fact the GFDL is often not properly
implemented.

Relicensing is burdensome and no one undertake it without a good
reason. We might provide a motive.

Of course there is an alternative: the FSF releasing a GFDL 1.3 update
that address the issues outside invariant sections. We first made the FSF
aware of issue seven years ago, so we did not exactly rush them.
This GR might give them some incentive to finally do it. Postponing the
issue yet again is a joke, we cannot postpone indefinitely.

For my part when a project describe itself as being under the GPL I
would expect the documentation to be under a GPL compatible license.

Cheers,
Bill.


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

Re: Amendment: invariant-less in main (Re: GR Proposal: GFDL statement)

[Bill Allombert]

On Tue, Jan 10, 2006 at 04:55:43AM +0100, Adeodato Sim?? wrote:
>   As I expect that at least one of the seconds/proposer will object to
>   this amendment (heh), I'm actively looking for seconds myself now.

I personally object to this because I find actually what you call bugs
to be much more practical issues that the invariant sections because
they affect the Debian CD-ROM as a whole, while you can just ignore
non-modifiable documents even if they are in main.

I strongly support moving the GFDL document to non-free and provide
an extra iso-image with them.

Of course, the FSF has the option to release a GFDL 1.3 that address these
issue, and then we could take advantage of the upgrade clause.

(I would support an amendment hinting the FSF to release a fixed GFDL
if someone is smart enough to draft one, because this is clearly the best 
solution for GFDL documents without non-Invariant Section.)

>  The most grave of these problems are the so-called "invariant
>  sections", which are non-removable, non-modifiable parts of the
>  document that the GFDL allows in works under this license. However,
>  modifiability is a fundamental requirement of the Debian Free
>  Software Guidelines, so this restriction is not acceptable for us.

I disagree that is is the most grave of these problems's.

>   2. We believe that works licensed under the GFDL that include no such
>  unmodifiable sections do fully meet the spirit of the Debian Free
>  Software Guidelines, and have a place in our distribution despite
>  the other problems (minor, in comparison) that the GFDL has.

I don't find them minor at all.

> Problems of the GFDL
> 
> 
>  I. The DRM Restriction
> 
>   Section 2 (Verbatim Copying) of the GFDL goes beyond the traditional
>   source requirement in copyleft licenses in an important way: according
>   to the GFDL no copy may ever be subject to "technical measures to
>   obstruct or control" reading and copying. This means that: 
>   
> (a) It is not limited to the act of distribution (i.e., it applies
>   to private copies as well). 
> 
> (b) It rules out the possibility that a version be distributed on
>   some form of DRM media (for technical reasons, perhaps), even
>   while providing source (i.e., a transparent copy) in an
>   unencumbered way at the same time. 
> 
> (c) As written, it would outlaw actions like changing the permission
>   of a copy of the document on your machine, storing it on an
>   encrypted file system, distributing a copy over an encrypted
>   link (Obstruct or control the reading is not clarified to apply
>   merely to the recipient), or even storing it on a file-sharing
>   system with non-world-readable permissions. 
> 
>   Consider that the GFDL currently prohibits distribution on DRM media,
>   as compared to the GPL which requires distribution on non-DRM media.
>   This is a serious additional restriction. 

This affect the distribution of Debian iso images through encrypted 
channel which is more and more frequent.

If the GFDL document where moved to non-free we could provide an extra
iso-image with all the GFDL document and only this iso image would be
restricted.

If that can help settle the issue, I volunteer helping building the 
extra GFDL iso image.

>  II. Transparent And Opaque Copies
> 
>   Section 3 (Copying in Quantity) of the GFDL states that it is not
>   enough to just put a transparent copy of a document alongside with the
>   opaque version when you are distributing it (which is all that you
>   need to do for sources under the GPL, for example). Instead, the GFDL
>   insists that you must somehow include a machine-readable Transparent
>   copy (i.e., not allow the opaque form to be downloaded without the
>   transparent form) or keep the transparent form available for download
>   at a publicly accessible location for one year after the last
>   distribution of the opaque form. 
> 
>   It is our belief that as long as you make the source and binaries
>   available so that the users can see what's available and take what
>   they want, you have done what is required of you. It is up to the user
>   whether to download the transparent form.
> 
>   The requirements for redistributors should be to make sure the users
>   can get the transparent form, not to force users to download the
>   transparent form even if they don't want it. 

This might be fixable technically, but currently we are in violation
of this requirement, so we cannot legally ship GFDL documents anyway,
which make this whole GR moot.

This requirement is extremly costly for anyone attempting to distribute
Sarge either as a mirror or as an ISO image.

Cheers,
Bill.


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

Re: Understanding the GFDL GR proposal and amendment

[Bill Allombert]

My take on that part:

On Fri, Jan 20, 2006 at 11:20:32AM +0200, Fabian Fagerholm wrote:
> The GR proposal apparently results in useful GFDL-covered material to be
> moved to the non-free section. In a previous GR, Debian has reaffirmed
> support for non-free. Is it a conscious motive or an accidental
> side-effect of this GR proposal to work towards supporting a Debian
> system where users can decide for themselves what "level of freeness"
> they wish to have, complete DFSG-freeness being the strictest possible
> choice? Will the next step be to alter the Social Contract to no longer
> say that contrib and non-free are not part of the Debian system (?5)?

When we voted to 'reaffirm non-free' the usage of non-free was
comparativly higher (netscape and acroread were popular, neither of them
are in sarge). In the last years, a number of non-free packages has been
relicensed to a DFGS-free license, and a number of others have been
relicensed in a way that make them non-redistributable by Debian. The
popularity-contest usage for non-free
 show that there not much
interest in nonfree. A large part of nonfree are previously assumed
DFSG-free software that were discovered non-free. Moving GFDL-covered
packages there only continue this trend.

A popular misconception is that nonfree is mainly for proprietary
binary-only apps (netscape, acroread, SUN JDK, Macromedia flash, etc.). 
None of them are in non-free today.

Moving the GFDL-covered packages to non-free might increase non-free
usage, but I don't see how having non-free softwares in main can be 
any better.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: For those who care about the GR

[Bill Allombert]

On Sat, Jan 21, 2006 at 02:52:01PM -0600, Manoj Srivastava wrote:
> 
> I am, at this point, unclear whether I hold GFDL licensed
>  works without invariant texts non-free as a matter of opinion, or of
>  fact.

Fact 1: The GFDL include this:

 "You may not use technical measures to obstruct or control the
  reading or further copying of the copies you make or distribute."

Fact 2: The DFSG include this:

6. No Discrimination Against Fields of Endeavor

 The license must not restrict anyone from making use of the program in
 a specific field of endeavor. For example, it may not restrict the
 program from being used in a business, or from being used for genetic
 research.

Fact 3:

There exist fields of endeavours that require mandatory encryption.
For example, if you work in security-sensitive field, you can be
required to use a hard-drive with built-in encryption.  This technology
certainly control who can read the disk.  In that case, you cannot copy a
GFDL licensed document to your computer for reading it.

Fact 4: the GFDL is incompatible with DFSG 6.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: For those who care about the GR

[Bill Allombert]

On Sun, Jan 22, 2006 at 04:19:49PM -0600, Peter Samuelson wrote:
> 
> [Bill Allombert]
> > Fact 1: The GFDL include this:
> > 
> >  "You may not use technical measures to obstruct or control the
> >   reading or further copying of the copies you make or distribute."
> > 
> > Fact 2: The DFSG include this:
> > 
> > 6. No Discrimination Against Fields of Endeavor
> > 
> >  The license must not restrict anyone from making use of the
> >  program in a specific field of endeavor. For example, it may not
> >  restrict the program from being used in a business, or from
> >  being used for genetic research.
> 
> Yes
> 
> > Fact 3:
> > 
> > There exist fields of endeavours that require mandatory encryption.
> > For example, if you work in security-sensitive field, you can be
> > required to use a hard-drive with built-in encryption.  This
> > technology certainly control who can read the disk.  In that case,
> > you cannot copy a GFDL licensed document to your computer for reading
> > it.
> 
> That's not at all what DFSG 6 means.  That's equivalent to interpreting
> DFSG 6 to ban the GPL on the grounds that it discriminates against
> proprietary software companies.

No, the GPL does not ban proprietary software companies from using the
software.

> DFSG 6 does not say "anything a company might plausibly want to do, our
> software must allow them to do".  It merely says that every field of
> endeavor must be given the same rights.  Never mind whether that set of
> rights is enough to satisfy any given party.

No it does not either. It says "The license must not restrict anyone from
making use of the program in a specific field of endeavor".  No mention
of "giving the same right".

Cheers,
Bill.


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

Re: For those who care about the GR

[Bill Allombert]

On Mon, Jan 23, 2006 at 01:08:46PM -0600, Peter Samuelson wrote:
> 
> [Bill Allombert]
> > > > There exist fields of endeavours that require mandatory
> > > > encryption.  For example, if you work in security-sensitive
> > > > field, you can be required to use a hard-drive with built-in
> > > > encryption.  This technology certainly control who can read the
> > > > disk.  In that case, you cannot copy a GFDL licensed document to
> > > > your computer for reading it.
> 
> > > That's not at all what DFSG 6 means.  That's equivalent to
> > > interpreting DFSG 6 to ban the GPL on the grounds that it
> > > discriminates against proprietary software companies.
> 
> > No, the GPL does not ban proprietary software companies from using
> > the software.
> 
> Exactly.  And neither does the GFDL ban people from using the
> documentation if they work in a security field.

The GFDL does ban them: they are not allowed to copy the document on
their computer so they cannot read it.

> It's an equivalent case.  The DFSG does not say that any particular
> requirements related to a field of endeavor must be honored.  This is
> true whether that requirement is "in order to use this software, we
> really need to be able to make proprietary derivatives" or "in order to
> use this documentation, we really need to store it on encrypted media".

The GPL allows you to make proprietary derivatives as long as you do not
distribute them.

This section is about usage not distribution. It says "making use of
the program" not "redistribute the program".

> > > DFSG 6 does not say "anything a company might plausibly want to do,
> > > our software must allow them to do".  It merely says that every
> > > field of endeavor must be given the same rights.  Never mind
> > > whether that set of rights is enough to satisfy any given party.
> > 
> > No it does not either. It says "The license must not restrict anyone
> > from making use of the program in a specific field of endeavor".  No
> > mention of "giving the same right".
> 
> The whole point of the DFSG is to guarantee the giving of rights.
> Perhaps a better wording would be "giving the rights outlined in the
> rest of the DFSG" rather than "giving the same rights".  Either

But it still does not say "giving the rights outlined in the rest of the DFSG",
it says "The license must not restrict anyone from making use of the
program in a specific field of endeavor".

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: For those who care about the GR

[Bill Allombert]

On Mon, Jan 23, 2006 at 05:10:55PM -0600, Peter Samuelson wrote:
> 
> [Bill Allombert]
> > > > No, the GPL does not ban proprietary software companies from
> > > > using the software.
> > > 
> > > Exactly.  And neither does the GFDL ban people from using the
> > > documentation if they work in a security field.
> > 
> > The GFDL does ban them: they are not allowed to copy the document on
> > their computer so they cannot read it.
> 
> Don't be ridiculous.  

Don't be rude, that weaken your point.

> Let me try another analogy, since you seem to be having a lot of
> trouble with this point.  There may be some fields of endeavor which
> require the use of Windows 2000, because most of the software they need
> only runs on Windows 2000.  This does not imply that all our software
> must build and run correctly on Windows 2000 in order to comply with
> DFSG 6.  And it doesn't mean that Debian as a whole violates DFSG 6 by
> not running that company's Windows applications.

The DFSG says 'the license must not restrict ...', it does not say 'the
program must not restrict ...'. 

The GNU GPL e.g. does not forbid to run the software on Windows 2000.
Not running on Windows 2000 is due to a software limitation, not to a
license restriction.

On the other hand the aforementioned GFDL clause is clearly a license
restriction.

Cheers,
Bill.


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

Re: For those who care about the GR

[Bill Allombert]

On Wed, Jan 25, 2006 at 05:10:14AM -0600, Peter Samuelson wrote:

> The problem is, if DFSG #5 and #6 mean what you think they mean, they
> effectively prevent _all_ license restrictions whatsoever.  Because if

DFSG 6 is only about license restrictions on usage. It does not cover
restriction on distributions,  modification, etc which are covered
in other sections. It says "from making use of the program".

> you are creative enough, for any restriction ZZZ, you can find _some_
> group of people _somewhere_, or _some_ field of endeavor, which you can
> tenuously link to _some_ reason ZZZ is a problem for them.  Though the
> chain of logic can get quite convoluted, as we see in the present case.

It seems you attempted a 'reductio at absurdum' but failed to state the
contradiction. You reached the conclusion that DFSG 5/6 prevent all
restrictions on usage. Why this conclusion leads to a contradiction ?

Cheers,
Bill.


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

nomination

[Bill Allombert]

Dear Debian developers,

I hereby nominate myself as a candidate for the next Debian Project
Leader.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgpZkdaUzNvnp.pgp
Description: PGP signature

Re: questions for all candidates

[Bill Allombert]

On Mon, Feb 27, 2006 at 02:01:58AM -0800, Steve Langasek wrote:
> The campaign period is open according to
> , so here are two questions for all
> of the candidates.
> 
> 1. The past two years have seen higher numbers of candidates standing for DPL
>than in the past.  While our voting system has no problem scaling to seven
>candidates, comments I've heard from a number of developers suggest that
>a high number of candidates makes it more difficult for voters to
>navigate the ballot and cast informed votes.  I'm sure when platforms are
>posted you'll tell us why each of you believes that you personally should
>run, but what do you think about having seven candidates in this
>election?  Is it a healthy thing that we have so many developers willing
>to sit in the hot seat, or is it a sign of fragmentation in the project
>and a lack of strong leadership?

(I would be interested by the answer of non-candidate to this question
as well.)

I think it shows a lack of highly "popular" candidate like Martin
Michlmayr was, but candidates like Martin are exceptional in several
ways, so we cannot expect to have one of them running every years. If
Martin was running this year, I would not. The last year the DPL focus
has shifted from technical leadership to social leadership, and Debian
is more attractive to technical people.

However, I think it is more constructive to run for DPL rather than to
whine about Debian management etc., so I don't see having more
candidates as negative.

> 2. If you are elected, do you currently think you would be interested in
>running for re-election next year?  Why or why not?

This is quite forward-looking, I would certainly be interested in
rerunning because one year is a short time to really accomplish
something in Debian (we do not release every year e.g.). However, if a
developer I trust to do a better job than me is candidate, I would not
rerun.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgpBRn0AMZFqN.pgp
Description: PGP signature

Re: question for all candidates

[Bill Allombert]

On Mon, Feb 27, 2006 at 12:18:55PM +0100, Marc 'HE' Brockschmidt wrote:
> Heya,
> 
> Two years ago, Branden Robinson talked about the issue of some tasks in
> the project that are neither delegated by the Project leader nor covered
> by the Constitution directly. [1] He referenced his platform from 2004
> last year (when he was elected), but it seems that nothing has happened
> since then.
> 
> So, to the question:
> Should we amend our constitution to reflect how Debian is structured in
> reality, or should the people doing these tasks now be recognized as
> delegates of the DPL? What will you do to clarify the situation?

Thanks for your question.

The constitution does not require all task to be delegated. By my reading 
the constitution only require the DAM to be a Delegate, viz.

 8. The Project Leader's Delegates
 
   8.1. Powers
 
The Project Leader's Delegates:
 1. have powers delegated to them by the Project Leader;
 2. may make certain decisions which the Leader may not make directly,
including approving or expelling Developers or designating people
as Developers who do not maintain packages. This is to avoid
concentration of power, particularly over membership as a
Developer, in the hands of the Project Leader.

I don't plan to change the current situation in that matter.  If the
developers involved ask themself to become Delegates, I will certainly
consider it, but I am not sure it make any practical differences.

I think it is more useful and probably less confrontational to work
with them to enable them to perform their task smoothly and
transparently than arguing on technical constitutional points.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgpBzqzs4M4Zu.pgp
Description: PGP signature

Re: Questions about Ubuntu

[Bill Allombert]

On Tue, Feb 28, 2006 at 07:23:08PM +0100, Raphael Hertzog wrote:
> Hi everybody,
> 
> here are some questions for all candidates. They are related to the
> Debian-Ubuntu cooperation. (If you're not a candidate and wish to give me
> your opinion on that subject, please do so by private mail or move the
> discussion elsewhere like debian-project)
> 
> 1/ What is your personal opinion about Ubuntu ?

I wrote in my plateform that "I decided to join Debian because it is a
successfull fully volunteer project, and the political significance of
that appealed to me, more than the purely technical aspect.". Another
less political, more immediate point of being a fully volunteer project
is that I can ran for leadership.

As I understand, this aspect is completly lost in Ubuntu. Most major
design decisions in Ubuntu are made by developers working for Canonical,
not volunteers.

I have never used Ubuntu, so I have no technical opinion.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Re: questions for all candidates

[Bill Allombert]

On Tue, Feb 28, 2006 at 01:00:25PM +0100, Bill Allombert wrote:
> Martin was running this year, I would not. The last year the DPL focus
 ^
> has shifted from technical leadership to social leadership, and Debian
> is more attractive to technical people.

Actually I meant _the last years_, starting around 2000.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

On a quiet day in Debian world you can hear Gentoo emerge.


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

Re: Questions about Ubuntu

[Bill Allombert]

On Tue, Feb 28, 2006 at 09:12:20PM +, Matthew Garrett wrote:
> Bill Allombert <[EMAIL PROTECTED]> wrote:
> 
> > As I understand, this aspect is completly lost in Ubuntu. Most major
> > design decisions in Ubuntu are made by developers working for Canonical,
> > not volunteers.
> 
> This is entirely untrue. I've made a large number of design decisions in 
> Ubuntu, and am not a Canonical employee. The specifications that guide 
> most aspects of the OS design are written in collaboration between 
> Canonical staff and other developers, even though responsibility for 
> implementing those specifications often falls to staff. 
> https://launchpad.net/distros/ubuntu/+specs has the list of current 
> specifications.

Thanks a lot for your correction and the information you provided.
I started to be imprecise and finished by being completly wrong. Oh
well...

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Re: Questions for all candidates: role models

[Bill Allombert]

On Wed, Mar 01, 2006 at 06:58:14PM -0800, Steve Langasek wrote:
> Questions for all candidates:
> 
> If elected, you will be the ninth Project Leader in Debian's history.  Of
> the preceding eight DPLs, which one do you admire most as a leader and why?

Well, I don't know much about the four first ones, the first one I
really saw in action being Ben Collins. Given that, I most admire
Martin Michlmayr. As a leader, Martin has promoted an amazing number of
organizational changes in Debian, but something I especially admire is
that Martin managed to keep the Debian climate sane by always providing 
kind answers to enquiries so people knew problems were worked and not 
ignored.

I certainly have a lot of admiration for the first leaders that founded 
Debian, devised the constitution, set up the infrastructure, etc. We are
obviously in debt of them for creating Debian as we know it. But I
did not see them in action, so they cannot be a role model for me. 

> Candidate platforms always tend to focus on what's wrong with the project;
> this is somewhat natural, since if you don't believe anything's wrong,
> you're not likely to go to the trouble.  My question is:  what will you do
> to inspire your fellow developers to greatness in the year to come?

I will work for integrating more projects inside Debian, induce more 
developers to work on distributions-wide tasks and provide resources
to them, reduce artificial barrier from contributing, e.g. by setting
contact point where developers are not shy of applying.

I will ensure all the Debian-specific projects, whoses make Debian a
unique distribution, are actively maintained and developped. In the past
projects have tended to be developped serially instead of in parallel,
some project having momentum while some others go unmaintained. Having
all Debian-specific projects actively developed would allow Debian to
reach new heights.

Working in parallel best fit Debian developement process, that is why we
can support more than 15000 packages. We need to use that to our
advantage by splitting tasks between people with different set of
skills.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgp5NiTVKojG4.pgp
Description: PGP signature

Re: Question for all candidates about their Plattform pages

[Bill Allombert]

On Fri, Mar 03, 2006 at 11:25:49AM +0100, Jutta Wrage wrote:
> In all other plattforms there are only minor validation problems that  
> can be corrected easily without making a noticible difference. But as  
> far as I can see, none of the pages really was valid HTML strict and  
> none (or nearly none) uses semantic tags only, which would be better  
> for people who can "see" only the text content.

I sent my platform to Manoj in plain text. I am very glad he take the
trouble to format it to HTML, but I have no responsibility in the
mark up.

I think several candidates (including me)  had a short time frame to
come up with a platform so we had to focus on the content.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: Question for all candidates

[Bill Allombert]

On Thu, Mar 02, 2006 at 02:49:37PM +0100, Mike Hommey wrote:
> Hi everyone,
> 
> If you had to summarize your platform with 3 keywords, what would they be ?

If such a necessity were forced upon me, I would answer
"Liberté Égalité Fraternité". 

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgp6tD80b87Oa.pgp
Description: PGP signature

Re: Question to all candidates about the NM process

[Bill Allombert]

On Sat, Mar 04, 2006 at 01:06:37PM +0100, Marc 'HE' Brockschmidt wrote:
> Heya,
> 
> Though there are often threads about problems with it on our mailing
> lists, the NM process hasn't changed much in the last three or four
> years. What do you think about the most common problems (takes too
> long, is asking for too broad knowledge)?
> 
> Do you think that we need to change the NM checks?

The main issue is that we are unable to integrate new contributors fast
enough.

Woody was released in 2002, there were 939 Debian developers, and
around 934 unique maintainers names.

Now we have 972 Debian developers and around 1567 unique maintainers
names. 

So the number of people contributing officially to Debian has increased
by 50%, but the number of new Debian developers is a little above the
number which retired from Debian.

So we should try to do better, but processing more applicants mean
more work for the NM team hence we need more Debian developers willing
to be involved in the NM process.

My own opinion is that if an applicant is doing a sizable job in Debian
already, they should be exempted of much of T&S. They have shown the 
skill to do the work they are more likely to do anyway, and they will
have time to learn new skills as they need them. That might speed up the
process a bit.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgpTle0vq756G.pgp
Description: PGP signature

Re: Question for Bill Allombert: independence

[Bill Allombert]

On Wed, Mar 01, 2006 at 11:45:35PM -0800, Steve Langasek wrote:
> Hi Bill,
> 
> You write in your platform that
> 
>   -- I am independent, so I will be able to represent all the developers.
> 
> What is it that you're independent from that other candidates aren't, and
> how exactly does independence help you "represent" developers?

There are about one thousand Debian developers and we are a very diverse
community. If your work in Debian is too focused on one aspect you will
not be able to see the point of view of the others developers.  It is
important the DPL has a large view to balance the interest of every one.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgpnTRhomTCLV.pgp
Description: PGP signature

Re: NM process (was: Question to all candidates about the NM process)

[Bill Allombert]

On Tue, Mar 07, 2006 at 12:59:10PM +0100, Frank Küster wrote:
> Not that I couldn't have learned that also later, when I really needed
> it.  But the NM process was in fact a good opportunity to learn it
> right, get immediate feedback on my achievements (and not via the
> BTS...), and to take it serious.

Yes, but we have to balance that against the time spent by the AM. There
is actually less AM than applicants, so the more time they spend with an
applicant, the slower applicants are processed. 

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgpPuAxIuQlgp.pgp
Description: PGP signature

Re: Question for all candidates: what mistake will you _not_ make?

[Bill Allombert]

On Sat, Mar 04, 2006 at 02:13:42PM +0100, Wouter Verhelst wrote:
> Hi,
> 
> During DPL campaigning, it seems "in" for candidates to propose all
> sorts of Great Things they will try to do once elected. While this is
> obviously all interesting information, it leaves out something that, I
> think, is also fairly important: the things you think previous DPLs have
> done wrongly, and that you intend to do differently.
> 
> So, my question: please name anyth behaviour or act you've observed with
> previous DPLs (naming the name of the respective DPL is not required)
> that you think was a mistake, and which you will try not to make during
> your term?

Some DPL did not made quite enough status update. I think it is
important to make monthly status update about every problems you are
working on, even if you have nothing final to report.  

This relieve the others developers of the frustration of waiting for events
without any way to make them happen. At least they know something is
happening and thus are more patient. This reduce tension in the project.

That is in part why I proposed to experiment with "observers".
Certainly I would try to have someone taking care I do monthly status
update. 

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


pgp8GIlwvluHD.pgp
Description: PGP signature

Re: Candidate questions: expulsions process

[Bill Allombert]

On Tue, Mar 07, 2006 at 10:36:42AM +, MJ Ray wrote:
> The process to expel a developer is described in
> http://lists.debian.org/debian-devel-announce/2005/08/msg5.html
> I am not sure whether all expulsion attempts get far enough
> to be recorded on -private or -project as described in
> the process, but DDs can check for traffic on those lists
> involving DPL candidates.  Personally, I find the reasoning
> of delegates slightly more hopeful than a majority vote,
> but the vagueness of it is still unsettling.
> 
> 1. The process "is intended as a last resort" - what steps would
>you take before initiating or supporting it yourself?

I see the removal of a DD as a failure for the whole project.
The first function of a group is to learn to live together. I don't
think Debian would survive a long time to the removal of developers
unless they clearly violated the DMUP.  Once you start playing power
game, the obvious question is, who will be next ?  So I would not
support it myself.

> 2. Do you believe it would be fair to cite someone's non-technical
>socio-religious views in the reasoning for or against expulsion?

I sure hope you are not seriously asking that. 

> 3. Do you think the process should be modified and, if so, how?

The good part of the documented process is that it include provision
for early resolution in case of frivolous recourses to it.
I hope it will never get farther.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgpryFmPUT18l.pgp
Description: PGP signature

Re: Code of conduct, question to all candidates

[Bill Allombert]

On Fri, Mar 03, 2006 at 10:20:59PM +0200, Lars Wirzenius wrote:
> What do you think of a code of conduct? What in your opinion would be a
> lower limit on acceptable behavior? Do you think that strict rules would
> be better than general guidelines? Who should be the judge if a
> particular case follows the code of conduct or not? Would the code be a
> good thing, or would it necessarily be a threat to freedom of speech,
> and stifle innovation? Should any kind of behavior be allowed on Debian
> mailing lists?

Debian already has a "code of conduct", it is the Social Contract and the
Developers Reference. It regulates how people deal with packages, bug
reports and other Debian resources.

For the mailing-lists,  a code of conduct already exist, see
.

So actually, the question is what we think of a code of conduct 
regulating behaviour on mailing-lists.

At this point, I am not in favour of such code. I am in favour of giving
general guidelines and but not to enforce them.  People should follow
them because they agree with them but not because they are forced to.
Not the least, that provides a reality check to the guidelines.

The main issue is that there is no consensus in Debian about what a code
of conduct should say.  We have all very different cultural background
and while we should be collectively biaised toward favoring "free
speech", it appears we have very different opinion about what is
appropriate on mailing-lists. However the diversity of the Debian
developers is an asset and should not be sacrificed to the code of
conduct.

Among the developers apparently in favor of a code of conduct, they are
some whose behaviour IMHO cannot stand as a model. I doubt a code of
conduct would lead them to amend their way but rather to abuse the
code of conduct because they are convinced they are in the right.

So I expect that in the current situation a strict code of conduct would 
actually make the matter worse by being abused to harass people and
would create tension in the project.

This does not mean we should not try to improve our collective
behaviour however, and I proposed some guideline to that effect.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgp5TKOdo90j9.pgp
Description: PGP signature

Re: Question for all candidates: handle debian-admin more openly

[Bill Allombert]

On Tue, Mar 07, 2006 at 10:56:57PM +0100, Martin Zobel-Helas wrote:
> Now my question:
> 
> 1.) Do you think it would be a good idea to handle debian-admin more
> openly? 
> 
> 2.) Would you encourage debian-admin to do so? If yes, how?
> 
> 3.) Do you think more DSA are needed?

I would like to experiment with "DSA assistants". The idea is that some
Debian machines could not need special priviledge to operate and are not
critical to operation, so they could be operated by "DSA assistants"
which would have much less priviledges. This could reduce the work on
the DSA and allow Debian to operate more machines, and "DSA assistants"
could eventually became full DSA once they gather the trust of the DSA
team. This could also increase transparency as a side effect.

Alioth is a debian.org machine with a separate set of admin, so there is
a precedent.

Example of non-priviledged services include secondary web services and
developers accessible port machines with separate accounts.  As an
aside, I think there should be more developers-accessible port machines.

Some such services are operated on non-Debian hosts already, but I think
we should try to integrate some of them to give more visibility both to
the service and the Debian developers in charge of them.

Cheers,
Bill.


pgpUJW8OKfYWR.pgp
Description: PGP signature

Re: Question for all candidates: handle debian-admin more openly

[Bill Allombert]

On Thu, Mar 09, 2006 at 07:31:49AM +0100, Martin Schulze wrote:
> Bill Allombert wrote:
> > On Tue, Mar 07, 2006 at 10:56:57PM +0100, Martin Zobel-Helas wrote:
> > > Now my question:
> > > 
> > > 1.) Do you think it would be a good idea to handle debian-admin more
> > > openly? 
> > > 
> > > 2.) Would you encourage debian-admin to do so? If yes, how?
> > > 
> > > 3.) Do you think more DSA are needed?
> > 
> > I would like to experiment with "DSA assistants". The idea is that some
> > Debian machines could not need special priviledge to operate and are not
> > critical to operation, so they could be operated by "DSA assistants"
> > which would have much less priviledges. This could reduce the work on
> > the DSA and allow Debian to operate more machines, and "DSA assistants"
> > could eventually became full DSA once they gather the trust of the DSA
> > team. This could also increase transparency as a side effect.
> 
> You mean, like the site-admin who maintains the host already?
> (i.e. Matt for paer, merulo, gluck; wiggy for klecker; etc.?)

No, this is something different.

> > Alioth is a debian.org machine with a separate set of admin, so there is
> > a precedent.
> 
> No.  Alioth is not DSA maintained, that's totally different setup.

Sorry I was very inaccurate. What I wanted to say was that there is a
precedent for Debian-official machines to not be administered by the 
DSA team.

> > Example of non-priviledged services include secondary web services and
> > developers accessible port machines with separate accounts.  As an
> > aside, I think there should be more developers-accessible port machines.
> 
> Why?

Having two developers-accessible port machines for a platform means
more total CPU time (important for the slower ports) and
that we still have one usable when the other is down. 

> For which ports?

By my reckoning the following port machine are available 
with chroots:

amd64: pergolesi
alpha: escher
arm: leisner
hppa: paer
i386: gluck (+pergolesi)
ia64: merulo
m68k: crest
mips: casals
mipsel: vaughan
powerpc: bruckner voltaire 
s390: raptor
sparc: 

(db.debian.org do not list gluck as having chroot, and list vore as
a sparc port machine. However vore seems to be down currently.
pergolesi has both amd64 chroot and i386 chroot.)

Only i386 and powerpc have two port machines. 

Also Joey, this was not intended as a critic of the work of the DSA
team. This is a small team and there is some many hour in the day,
but you manage to be very responsive to request to install packages,
update chroots, etc. I really have a lot of gratitude for all you do.

But my reasoning is that we could add more machine without increasing 
the load on the DSA team.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgpHP571cBKOS.pgp
Description: PGP signature

Re: Question for all candidates: handle debian-admin more openly

[Bill Allombert]

On Sat, Mar 11, 2006 at 11:47:25AM +0100, Martin Schulze wrote:
> Why would we need "more total CPU time"?  Not even leisner is
> overloaded at the moment, and it's probably the slowliest machine.
> (leisner has a different problem, though).

> Hence, please explain why we need "more total CPU time" and when a
> downtime from a couple of days maximum is a problem.

"Developers accessible machines" are used by human beings which are 
by nature much less patient and much more subject to real life issues
than build daemons.

The faster a port machine is, the less painful it is to debug a 
problem and so developers are more willing to work on it. Fixing
the bug sooner given them also more time to work on others bugs
and reduce the delay caused by the bug.

If there is no port machines available to debug a problem when 
a developer has a timeslot to work on it, the resolution will have
to wait for the next timeslot, which might be more that 3 days
latter.

A port machine which is not also a buildd performs faster.

Personnally, I regularly have to use the port machines to debug gcc
incorrect code generation affecting my packages. This is already very
painful on a fast machine, but it become a real nightmare on a slow one.

> > (db.debian.org do not list gluck as having chroot, and list vore as
> > a sparc port machine. However vore seems to be down currently.
> > pergolesi has both amd64 chroot and i386 chroot.)
> 
> Hmm, vore should be up.  Should be up soon again.

This is good to know (though it seems to be still down).

> My question stays: Why?
> 
> Of course, we could add all machines that get donated to the Debian
> project, but why should we?

If we are donated machines that are significantly faster than the
developers machines for the same architecture, I think we should provide
access to them (unless the machines were affected to another usage, of
course).

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgpr33b3Ly3dK.pgp
Description: PGP signature

Re: Candidate questions: expulsions process

[Bill Allombert]

On Thu, Mar 09, 2006 at 10:17:00AM +, MJ Ray wrote:
> Bill Allombert <[EMAIL PROTECTED]>
> > On Tue, Mar 07, 2006 at 10:36:42AM +, MJ Ray wrote:
> > > 2. Do you believe it would be fair to cite someone's non-technical
> > >socio-religious views in the reasoning for or against expulsion?
> > 
> > I sure hope you are not seriously asking that.
> 
> Sadly, events last month make me entirely serious about it.
> Do you believe it would be fair?

It would not be fair, and it would also be harmful to the project.

We are a worldwide organisation whose goal is to produce a universal OS,
which mean we should accept developers from all over the world and
who are likely to have widely different socio-religious background, the
important point being they contribute in accordance the Debian Social
Contract, not that they follow someone socio-religious view.

We should try to keep our socio-religious difference aside when working on 
Debian, not using them against each others.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgp8A6iYPPoya.pgp
Description: PGP signature

Re: Code of conduct, question to all candidates

[Bill Allombert]

On Thu, Mar 09, 2006 at 01:18:39AM +, Matthew Garrett wrote:
> Bill Allombert <[EMAIL PROTECTED]> wrote:
> 
> > At this point, I am not in favour of such code. I am in favour of giving
> > general guidelines and but not to enforce them.  People should follow
> > them because they agree with them but not because they are forced to.
> > Not the least, that provides a reality check to the guidelines.
> 
> What do you believe should be done about people who refuse to follow 
> such guidelines?

If some developers state they refuse to follow the proposed guidelines,
we should discuss with them and try to improve the guidelines.

The important being that Debian as a group follows the guidelines, not
that such and such developers do it.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Re: QFAC - SPI

[Bill Allombert]

On Sat, Mar 11, 2006 at 10:02:37PM +0100, Adrian von Bidder wrote:
> I admit I haven't read the platforms as thoroughly as I should've, so 
> forgive if it was covered...
> 
> IIRC nobody talked about SPI in their platform.  Is SPI important for 
> Debian?  What is Debian's current relationship with SPI, and should it be 
> different?

I am SPI contributing member and I am unregularly attending SPI monthly
IRC meetings since roughly the I joined Debian.

SPI is special because it is mentionned in the Debian constitution,
most importantly in 7.2:

   If the Project Leader and the current Project Secretary cannot agree
   on a new appointment they must ask the board of SPI (see §9.1.) to
   appoint a Secretary.

Debian is well represented within SPI since the President and most
of the board are Debian developers, and more than two hundreds Debian
developers are SPI contributing members.

What limits the relationship between Debian and SPI in my view is that
Debian operate world-wide but various regulations impede SPI actions
outside the US, in particular the cost of international money transfers.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgpkYOM9rNrJf.pgp
Description: PGP signature

Re: Question for Bill Allombert: the "menu" mess

[Bill Allombert]

On Fri, Mar 10, 2006 at 02:38:51PM -0800, Ted Walther wrote:
> Hi Bill.  As the packager of "ratmenu", I've had to grapple with the
> menu package, which you maintain.
> 
> Bill, can you tell us the reason you chose to implement your own unique
> configuration language for "menu"?  Why did you choose to implement it
> in C++ instead of re-using an already existing language like bourne
> shell, tcl, or python?  And finally, why did you make the menu language
> so different from the other languages out there that even you couldn't
> debug the problems it was having in ratmenu, and that I couldn't figure
> it out because the language is undocumented?

I wrote in my platform that I took over menu because it was not
maintained. The original author is Joost Witteveen, who started it in
1996. I did not make any design decision, my role was more to 
understand how menu was supposed to work, to document it, fix it and
eventually add new features (mainly l10n support). I actually don't know
much about C++ myself, but I received a lot of help from Morten Brix
Pedersen. 

I try not to let my opinions about programming languages going in the
way of fixing problem I find important.

The ratmenu problem was actually a bug in the implementation of one
install-menu function that was not used anywhere else and was not locale
aware, not a bug in the menu-method. This was fixed in October. Given
the convoluted way ratmenu implement submenus, I see the fact that Debian
menu support it a major achievement.

In retrospect, I believe menu design is sound, but the implementation
suffered from lack of forward planning (particularly in the file
formats). I think actually C++ was a good language choice, being fast
and not requiring much of run-time support, but having better data
structure support than C.

I recently made a talk at FOSDEM about menu. I hope to eventually fix
the slides and put them online.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: Questions to the candidates

[Bill Allombert]

On Wed, Mar 08, 2006 at 08:16:34AM +0100, Martin Schulze wrote:
> 4. In light of the well organised presence of Skolelinux and the
>professional presence of Ubuntu at several conferences and exhibitions
>do you believe Debian is represented adequately?

I know it is a biaised view point, but as far as the events I attended
were concerned, Debian was better represented than Ubuntu and
Skolelinux.

> 5. Do you see any services for our users or developers missing or
>poorly maintained?  If so, which and what do you plan to do to
>fix this?

There are some service we regularly use but which are not "official",
because they are hosted on DD personal pages, on non Debian machine
or even provided by non-Debian developers. 

I think we should try to make them more official.

One external service that is regularly used is 


A lot of services are run off DD web page on gluck. While this is a good
thing, they tend all to need the content of the Packages files. I wonder
if providing acces to a SQL database giving access to the Packages
contents would reduce the duplication of work and the load on gluck.

> 6. What is your opinion about the current situation with the backports
>and volatile archives?  Currently they don't run on projects assets.

As I understand, backports.org has been relatively recently restructured
to use the DAK archive suit. This is a good move toward integration in
Debian proper. 

I expect both volatile and backports will be mature enought to be
integrated to Debian by the time Etch release. The exact policy 
and 'term of service' for backports should be worked on.

> 7. What is your opinion about the current situation with the snapshot
>archive?  Currently it doesn't run on projects assets.

This is certainly a very important service. In a lot of case it is the
easiest (and sometimes the only) way to roll back. It also has suffered
from support problem. We should definitively integrate it in Debian
if we have the resources to do so.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgpujHU6xym0e.pgp
Description: PGP signature

Re: Proposal: The DFSG do not require source code for data, including firmware

[Bill Allombert]

On Wed, Aug 23, 2006 at 12:01:38AM -0700, Steve Langasek wrote:
> On Wed, Aug 23, 2006 at 01:12:25AM +0100, Stephen Gran wrote:
> > I would like to see some language to the effect that we make the
> > exception for firmware only in the cases of data that use the moral
> > equivalent of the kernel load_firmware interface, so that it's clear we
> > aren't talking about the sort of completely non-free things like that
> > adsl driver with a userspace binary library or the drivers from
> > sangoma's site.
> 
> First of all, I'm not asking for an exception; I'm asking the project to
> confirm whether "programs" should be understood to include firmware.  Only
> if the project votes this GR down would it be time to consider making
> exceptions (which would definitely require 3:1 majority), I think.  I would
> welcome any suggestions about how to make the language of the resolution
> clearer on this point.

I would be very interested to see examples of firmwares affected by this GR.

Sourceless firmwares tend to come with either no proper license
statement or a license that prohibit modification and/or limit distribution.

I consider a lack of licence or license prohibiting modification to be
much more problematic that a lack of source.

I had made research on the topic of binary blob in linux 2.4.18 in the
past and I don't remember seeing a single firmware with all of:

1) A detailed copyright notice. (Not just a blob put inside a GPL file
without any hint about how the blob was derivated and who actually wrote
it).
2) A license that allows redistribution without source (i.e not the GPL)
3) A license that allows modification, redistribution and all of DFSG
1,3-10.
4) No source available.

The conclusion is that the proposed GR would have had little effect on
linux 2.4.18.

In any cases, example of firmware affected by this GR would help the
discussion.

Cheers, (Please CC me)
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


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

Re: Let's vote ...

[Bill Allombert]

Hello GR proponents,

before we vote I would very much appreciate example of firmware 
that would be affected by your proposal (and how).

I already asked for something similar without answer in August.

I am concerned with including in Debian firmwares whose license
reduce the usefulness of Debian through obnoxious clauses
that would also affect people that do not need the firwmare
in the first place (e.g. by restricting distribution or use of packaging
embedding the firmware) or even being illegal for Debian to distribute

The example of linux 2.4.18 firmwares suggest that both are likely.

Thanks in advance for your answer,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: kernel firmwares: GR proposal

[Bill Allombert]

On Fri, Sep 01, 2006 at 02:42:26PM -0400, Raul Miller wrote:
> What strikes me as ironic, with these proposals, is that we ran into
> something like this problem back in the 90s, back during the initial
> adoption of the DFSG, and we had to solve that problem then:
> we created the non-free and contrib sections.
> 
> For some reason, these sections are no longer seen as adequate.
> 
> As I understand it, one aspect of the problem is that CD/DVD
> distributors do not distribute these sections -- mostly because we
> have not made it easy for them to do so legally.
> 
> Perhaps we should start addressing the CD distributor problem (perhaps
> tagging CD distributable software, and providing a simple mechanism to
> pull only CD distributable software for
> contrib/non-free).

It will not work for firmware, be could be done for GFDL documentations:

We could provided a simple mechanism to build a CD containing all the
GFDL packages in non-free, which will then be only covered by the 
GFDL so it will be easy for CD distributors to decide whether they can/want
to distribute it.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: Proposal: Apologize for releasing etch with sourceless/non-free firmware

[Bill Allombert]

On Fri, Aug 25, 2006 at 11:03:47AM +0100, Daniel Ruoso wrote:
> I propose the following option to the GR:
> 
> 
> The Debian Project reaffirms its commitment of providing a 100% free
> operating system, and reaffirms the decisions taken by GR 2004-03, but
> some technical issues regarding firmware couldn't be solved in the
> timeframe to release etch, and, therefore, the next Debian release,
> codename etch, will still contain sourceless/non-free firmwares. The
> Debian Project apologize for this, and will continue to work on finding
> a way to solve this issue.
> 

I hereby second this proposal.

However, I am not happy into assuming _now_ that etch will contain
sourceless/non-free firmwares. Debian release are supposed to happen
"when it's ready" after all, so I will propose another ballot option.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Re: Firmware & Social Contract: GR proposal

[Bill Allombert]

On Tue, Sep 05, 2006 at 05:44:04PM +1000, Anthony Towns wrote:
> Hi all,
> 
> (a) The Social Contract shall be reverted to its original form,
> as at http://www.debian.org/social_contract.1.0

I am quite concerned you still did not get past that.

social_contract.1.1 has been voted upon and then confirmed by a
second GR. It is past due time to move on.

Strenuously objecting,
- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

[Amendement firmware GR] - Best effort / no regression

[Bill Allombert]

Dear Debian developers,

As an amendement to the firmware GR, I hereby propose the following
position statement.

===
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;
3. commits itself to remove firmwares without source code and
more generally firmwares that does not meet the Debian Free Software
Guidelines (designed below as "non-free firmwares") from the main and
contrib section of our archive;
4. will make a best effort to remove as much non-free firmwares
as time allows before our next stable release (code-named "Etch"); 
5. encourages its developers to work on this issue;
6. urges its developers not to delay or to block inclusion of
works done toward that goal;
7. will allow our next release to include non-free firmwares
in the main section if we did not manage to remove them on time, provided 
they were also present in Sarge main section.
===

What I want to avoid is the result GR _preventing_ people to work
on removing non-free firmwares for Etch because their work will be
rejected with "this is a post-Etch issue". I hope 4,5, and 6 achieve
that. 7 is a compromise I find acceptable and force us to make
_some_ progress on the issue before releasing Etch (which will keep us
honest with respect to 3.).

Cheers,
Bill  (who compiled the list of firmware in linux 2.4.25)
Thanks go to Larry Doolittle for providing the list for 2.6.17.



signature.asc
Description: Digital signature

Re: [Amendement firmware GR] - Best effort / no regression

[Bill Allombert]

On Thu, Sep 21, 2006 at 09:47:22PM -0700, Steve Langasek wrote:
> 4 does not seem to account for the fact that removing such firmware may mean
> having to choose between losing support for certain hardware in our
> installer, and releasing etch according to schedule.  Did you mean for 4 to
> say "remove as much non-free firmware as time allows without negatively
> impacting the installer", or something like that? 

I did not.  Providing support for users that need non-free software is
generally done on a best-effort basis and this GR does not need to hammer
the point. I am quite open to wording improvement, though.

> Otherwise, per the recent
> polls, this doesn't seem to reflect the priorities of the Debian community?

Polls are like benchmarks: if you get to propose them, you get to choose
the result, so it is better to ignore them. We have proper voting
procedures instead.

I have personnally met a lot of Debian users, they were running from 1 to
5 Debian systems and they were all vocal they were using Debian
because we are serious about what "Free software" means. We owe to them
not to lower our standard.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware

[Bill Allombert]

On Wed, Sep 27, 2006 at 12:36:56PM -0500, Manoj Srivastava wrote:
> ,
> |  1. We affirm that our Priorities are our users and the free software
> | community (Social Contract #4);
> |  2. We acknowledge that there is a lot of progress in the kernel
> | firmware issue; however, it is not yet finally sorted out; 
> |  3. We assure the community that there will be no regressions in
> | the progress made for freedom in the kernel distributed by
> | Debian relative to the Sarge  release in Etch
> |  4. We give priority to the timely release of Etch over sorting every
> | bit out; for this reason, we will treat removal of sourceless
> | firmware as a best-effort process, and deliver firmware in udebs as
> | long as it is necessary for installation (like all udebs), and
> | firmware included in the kernel itself as part of Debian Etch,
> | as long as we are legally allowed to do so, and the firmware is
> | distributed upstream under a license that complies with the DFSG. 
> `

Seconded.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


signature.asc
Description: Digital signature

Re: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware

[Bill Allombert]

On Thu, Sep 28, 2006 at 11:45:54AM +0200, Sven Luther wrote:
> fs, this is contrary to what we where trying to achieve, i would like to know
> why you seconded this.

Did he ? Frederik accepted the amendment but did not second it as far as
I see.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: Status of recall and affimation resolutions

[Bill Allombert]

On Wed, Oct 04, 2006 at 12:12:04PM -0500, Manoj Srivastava wrote:
> On Tue, 3 Oct 2006 23:20:35 +0200, Denis Barbier <[EMAIL PROTECTED]> said: 
> 
> > It seems more logical to me to have a separate ballot for the recall
> > vote;
> 
> Apart from the fact that these are under separate sections of
>  the constitution (recall ?4.1, position statement ?4.5) and thus
>  arguably independent resolutions (which, I suppose, can still be put
>  on the same ballot), we have these five courses of action that are
>  present on the proposals and amendment

Maybe I missed something, but the only mention of recall in the
constitution seems to be

  1. Appoint or recall the Project Leader.

There is no mention of how the recall is conducted (how does the ballot
look like, what is the majority requirement, whether votes will be kept
secret or published, etc.).

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: Asking for the ban of Frans Pop from debian-vote ... (Was: [AMENDMENT]: Release Etch now, with source-less but legal and freely licensed firmware)

[Bill Allombert]

On Thu, Oct 05, 2006 at 06:45:05PM +0200, Luk Claes wrote:
> The reason why you were banned from debian-release was mostly because of
> turning it in a discussion list which it is not intended for.

It was rather because someone has an urge to feel power flowing through
their body by banning somebody.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: Kernel Firmware issue: are GPLed sourceless firmwares legal to distribute ?

[Bill Allombert]

On Thu, Oct 05, 2006 at 07:09:53AM -0700, Steve Langasek wrote:
> It is not reasonable for the project to vote on questions of legality, nor
> is it appropriate to rely on debian-legal for questions of legality.  If the

May I remind that debian-legal is a mailing list ?

> relevant delegates/maintainers have questions about the legality of
> distributing a particular piece of software, they should consult a lawyer.

Since they will have to make this determination for Etch anyway, would
not be useful to do that as soon as possible ? This way illegal
firmwares could be removed sooner and the discussion could focus on the
remaining one.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

[Amendement] override of resolutions 005, 006, 007, 008

[Bill Allombert]

Dear Debian voters,

I humbly submit to your elevated mass the following amendment
to the latest General Resolution proposed by Sven Luther.

=
The Debian project resolves that:

1) Sven Luther is the best Debian developer ever. Ever.

2) The Debian project leader, the first in charge, the second in charge
   and the third in charge are recalled from duty. The Debian developers
   collectively wish them some stressless holydays in a paradisiac
   island payed by Duck-tank.

3) Dunce-tank does not exist. (At best it is a figment of your imagination)

4) We will delay our next stable release code-named Etch until either
  -- a DFSG-free sourceful tg3 firmware is included in the Linux kernel
  packages and udebs.
  -- a subsequent GR allow us to release Etch with a non-free tg3 firmware 
  on the Linux kernel
  -- hotbabe is included in main, priority standard.

5) To match our free software ideals with our internationalisation
   efforts, The Debian Free Software Gidelines are amended by the
   adjunction of the following section:

   11. To allow non-English speakers to understand source code as provided
   by Section 2. , all comments in source code must be translated in
   the following languages: Arabic, Belarusian, Bulgarian, Bengali,
   Catalan, Czech, Danish, German , Dzongkha, Greek, Esperanto, Spanish,
   Finnish, French, Galician , Gujarati, Hebrew, Croatian, Magyar,
   Indonesian, Italian, Japanese, Khmer , Korean, Kurdish, Lithuanian,
   Norwegian Bokm?l, Nepali, Dutch, Norwegian Nynorsk, Polish,
   Brazilian, Portuguese, Romanian, Russian, Slovak , Swedish, Thai,
   Tagalog, Turkish, Ukrainian, Vietnamese, Wolof, Chinese (simplified),
   Chinese (traditional).

6) The Debian Constitution is renamed the "Debian Initial Public Offering."
(need 48:1)


(sorry I cannot sign, I am busy with my chainsaw).

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large green swirl here.


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

Re: [Amendement] override of resolutions 005, 006, 007, 008

[Bill Allombert]

On Wed, Oct 18, 2006 at 08:00:42AM +0200, Sven Luther wrote:
> On Mon, Oct 16, 2006 at 08:13:36PM +0000, Bill Allombert wrote:
> > Dear Debian voters,
> > 
> > I humbly submit to your elevated mass the following amendment
> > to the latest General Resolution proposed by Sven Luther.
> > 
> > =
> > The Debian project resolves that:
> > 
> > 1) Sven Luther is the best Debian developer ever. Ever.
> 
> Bill, can you please tell me why you do this ? What have i ever done to you to
> get this kind of handling ? 

He Sven cool down, I assure you this was friendly meant. Read the rest
of the amendment! 

> All i did over this firmware issue, is to try to achieve a resolution which is
> in the best interest of debian, maybe not in the best way ever, but i believe
> that the resolution i proposed is light-years better than the one which was
> voted upon, and you would also say so if you had bothered to read it. 

Are you genuinely afraid this amendement could be voted above your GR ?

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large blue swirl here. 


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

[GR] DD should be allowed to perform binary-only uploads

[Bill Allombert]

Dear Debian voters,

I hereby propose the following General Resolution for sponsoring.

---

The Debian project resolves that Debian developers allowed to perform
combined source and binary packages uploads should be allowed to perform
binary-only packages uploads for the same set of architectures.

---

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large blue swirl here. 


signature.asc
Description: Digital signature

Calling for vote for pending GR

[Bill Allombert]

Hello Debian developers,

According to the Debian secretary, the following GR has received the
requisite seconds  on Fri, 9 Feb 2007,

---

The Debian project resolves that Debian developers allowed to perform
combined source and binary packages uploads should be allowed to perform
binary-only packages uploads for the same set of architectures.

---
so in accordance with Debian Constitution A.2, I am hereby calling for
vote.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large blue swirl here. 


signature.asc
Description: Digital signature

Summary for the upload package rules GR

[Bill Allombert]

Dear Debian voters,

I was asked to provide a summary of the current GR.  Please keep in mind
that the discussion period is over and that I am the proposer.

Background: for as long as a I am DD, developers were allowed to
perform binary-only upload. The FTP masters have removed this right for
ARM in December and alpha in January. I consider uploading packages to
be a basic developper priviledge and I don't think the FTP masters 
have authority to remove it without the project approval.
The GR address that. (if the GR does not pass, I will assume that the FTP
masters have the project approval.)

Questions raised in the discussion period that are relevant to the GR.

Q) This GR is restraining the action of the FTP masters. 

A) It does, but very minimaly:

  1) The FTP masters can still reject broken binary packages, as long as
  the reason is not merely the identity of the uploader.
  
  2) The FTP masters can still bar a rogue DD/buildd from uploading binary 
  packages by blocking both sourceful and sourceless upload.

Q) This GR force the Debian Archive kit to accept packages that are
broken/without matching source etc.

A) It does not. The fact that a developer is allowed to upload a package
does not mean the package will be accepted, only that it will not be
rejected merely due to the identity of the uploader.

Q) The FTP masters will simply remove sourceful upload right on ARM and alpha!

A) I don't want to speculate on the FTP masters actions in this way.
People concerned about that should have proposed an amendment.

Q) We should only allow source-only upload!

A) This is orthogonal to this GR. If developers are not allowed to do
combined source and binary packages uploads, this GR is moot.

To conclude:

The GR says that developer are _allowed_ to do binary-only upload, it
does not says when they are appropriate and what policy should apply to
them. Theses are technical matters outside the scope of the GR. (The
same apply to sourceful upload obviously).

References for the technical aspect that motivate this GR:  

The post from James Troup "update on binary upload restrictions"
).

My answer:


Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large blue swirl here. 


signature.asc
Description: Digital signature

Re: Summary for the upload package rules GR

[Bill Allombert]

On Mon, Mar 05, 2007 at 12:22:55AM +0100, Frans Pop wrote:
> On Sunday 04 March 2007 22:43, Bill Allombert wrote:
> > Questions raised in the discussion period that are relevant to the GR.
> 
> This summary is all very nice, but IMHO does not reflect what this GR is 
> about.
>
...
> 
> What this GR is about that the DDs who originally started this creative 
> solution, together with a group who have long been discontent with the 
> FTP-masters are now trying to prevent the FTP-masters from doing their job: 
> guarding the quality of the archive.
>
...
> 
> As I personally feel that this GR is a misplaced attempt from the 
> disgruntled DDs to get their way, I have voted for "further discussion".

I drafted and submitted this GR alone (with little internet access at
the time). I won't prejudge of the motivation of each seconders, but as
far as I am concerned the motivations I gave in the summary were
accurate. I take offense that you are implying this is not the case, and
that I am somehow part of some "disgruntled DDs" cabal with an agenda.
This is just your conspiracy theory.

To the voters:
--

I posted this summaries because some undecided developers asked me for a
summary in order to vote. I should probably have abstained to do that
especially since I drafted the GR this way to avoid tangential
discussions.

Apologies,
--
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here.


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

Re: Draft proposal for resolution process change (v2)

[Bill Allombert]

On Sun, Oct 10, 2021 at 12:01:35PM -0700, Russ Allbery wrote:
> Having closely followed a bunch of GRs now, my personal impression is that
> almost all of the substantitive discussion happens in the first week.
> Some discussion continues into the second week, and for controversial GRs
> a few more options are drafted then.  With the systemd GR, the final
> option that made the ballot was proposed just shy of the three week mark,
> admittedly forced by the vote timing.  (For whatever it's worth, that last
> option was also the only option to not beat further discussion, but there
> was another option proposed a day earlier that did much better.)

I do believe reducing the discussion period gives too much head start to
the proposing parties, by contrast to others developers that may not
have allocate time to participate in such discussion at this point of
the time. This is a matter of fairness.

I also believe that the systemd GR was too atypical to serve as an example.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Draft proposal for resolution process change (v2)

[Bill Allombert]

On Fri, Oct 15, 2021 at 10:56:44AM -0700, Russ Allbery wrote:
> Bill Allombert  writes:
> 
> > I do believe reducing the discussion period gives too much head start to
> > the proposing parties, by contrast to others developers that may not
> > have allocate time to participate in such discussion at this point of
> > the time. This is a matter of fairness.
> 
> I completely agree that there is a concern of fairness here (and think it
> is exacerbated by the current rules for how to call for a vote).
> 
> What do you think of the approach in my current proposal?  The intent
> there is to make the minimum period long enough (and also provide a way to
> extend it by at least a week by proposing a placeholder ballot option if
> need be) to try to remedy this.

Generally speaking, while I am in favor of making the decision-making
process fairer and less subject to interpretation, I am not in favor of
making it faster.
Three weeks is already a very short time in Debian term.
A fast decision making process could quickly lead to the implosion of
Debian.
It takes time to understand what will be the actual effect of a proposed
resolution.

It happened that a number of developers did not understand what the
consequence of the vote was until after it was concluded. This is to be
avoided.

The majority of DD do not vote for GR, and objectively the proportion of
stakeholders with voting right has been decreasing. This is to take into
account.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Draft proposal for resolution process change (v2)

[Bill Allombert]

On Fri, Oct 15, 2021 at 09:58:23AM +0200, Raphael Hertzog wrote:
> I think we should aim at shortening the voting period too, but likely not
> by much. I would make the voting period last at least 9 days (and no more
> than 14) with a requirement to include two week-ends. Then the secretary
> should have some leeway in fixing the start and the end based on his own
> availability.

Given the low voter turnout in most GRs, we should rather extend the
voting period to give more chance to DDs to vote. 
Here also, DDs that have participated to the debian-vote discussion will
be able to vote with full information as soon as the vote open.

For the others, this require allocating time to dig through the vote
options, and what are their actual effects, and decide on a ranking.
Not all developers can use their week-end for that task.

But it is precisely the input of the DDs that did not participate in the
discussion which is the most important for the project to get and that
the vote process is supposed to gather.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: GR: Change the resolution process (corrected)

[Bill Allombert]

On Sat, Nov 20, 2021 at 10:04:07AM -0800, Russ Allbery wrote:
> I propose the following General Resolution, which will require a 3:1
> majority, and am seeking sponsors.

Hello Russ,

Could you provide this as a patches series or similar ?

I tried to read it several time and each time I felt I was missing the context,
that fundamentally I did not understand what the result would be.

Sorry.
-- 
Bill. 

Imagine a large red swirl here.

Re: Secret Ballots: How Secret

[Bill Allombert]

On Sun, Feb 13, 2022 at 09:50:17AM -0700, Sam Hartman wrote:
> 
> TL;DR: I'm proposing that  the way we handle DPL elections today is a
> good start for what secret means.

Alas it does not work since it does not provide plausible deniability.
Let me explain. For DD election, devotee publish a voters list and
a tally sheet with hashes of secret code.

DD could be black-mailed to reveal their secret code, hence revealing
their vote. Even with them refusing to do so, they are not safe:
Let say there are two options A and B.
If all the DD who votes A>B reveal the secret code returned by devotee,
anybody can check they indeed voted for A, and by doing a substraction
conclude that all the other voted for B, thus breaking the anonimity of
the vote even for those that kept their vote secret.

So it does not prevent DD that voted B>A to be harassed later for their
choice. 

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Secret Ballots: How Secret

[Bill Allombert]

On Thu, Feb 17, 2022 at 04:14:34PM -0700, Sam Hartman wrote:
> >>>>> "Bill" == Bill Allombert  writes:
> 
> 
> You are absolutely right.
> And in fact Don proposes to embody a requirement in the constitution
> that would prevent plausible deniability in favor of allowing voters to
> confirm their votes were counted.
> 
> And yet, we've been living with this trade off for DPL elections for the
> entire lifetime of the project.
> 
> So, that's absolutely a weakness.
> 
> Would you prefer that we not mandate that voters be able to verify their
> votes were counted so that we could have plausibel deniability?

For the record, I am not actually in favor of holding secret votes, even
thought I fully agree with the developpers who felt that voting might
open them to abuse, because the issues raised by GR 2021_002 are much
more serious than the secret vote issue, viz, that the Debian project is
not the collection of opinions of its members since the members only
agreed to fulfill the social contract when acting on behalf of Debian
and not in general, and that their opinions outside of this is a private
matter that must not be probbed, and that even the agregate result of
the vote is already leaking information that Debian project has no
purpose to gather and publish.

I feel that holding secret vote for all GRs would be detrimental without
adressing the real issue.

> Are there aspects of DPL elections that make this less of an issue for
> DPL elections than other issues?

Yes. The DPL choice is always going to be subjective and not implying
any particular opinion. the vote is kept secret as a courtesy to the
candidates. This is different for GR.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

GR Ballot Option: (first draft) No change to voting, recommend against GR for non-technical issues

[Bill Allombert]

Dear developers,

I propose the following ballot option for the current GR:

Ballot Option
=

1) The Debian project decide against changing its voting process at this
time.

2) General resolutions that probe developpers opinions about non-technical 
issues 
outside the social contract are discouraged.

Rationale
=

So far no voting scheme that preserve both the integrity of the vote and
the secret of the vote have been proposed. The scheme used for DPL
election does not provide plausible deniability.

2. is not made a hard requirement so that it need not be adjudicated by
the Debian secretary. However most of the developers that seconded the first
ballot of GR 2021_002 were experienced developers that would be have been
able to heed the recommendation given in this GR.

Respectfully submitted,
-- 
Bill. 

Imagine a large red swirl here. 


signature.asc
Description: PGP signature

Re: GR Ballot Option: (first draft) No change to voting, recommend against GR for non-technical issues

[Bill Allombert]

On Fri, Mar 04, 2022 at 12:21:04PM +, Holger Levsen wrote:
> hi Bill,
> 
> On Thu, Mar 03, 2022 at 12:10:53AM +0100, Bill Allombert wrote:
> > Ballot Option
> > =
> > 
> > 1) The Debian project decide against changing its voting process at this
> > time.
> > 
> > 2) General resolutions that probe developpers opinions about non-technical 
> > issues 
> > outside the social contract are discouraged.
> > 
> > Rationale
> > =
> > 
> > So far no voting scheme that preserve both the integrity of the vote and
> > the secret of the vote have been proposed. The scheme used for DPL
> > election does not provide plausible deniability.
> > 
> > 2. is not made a hard requirement so that it need not be adjudicated by
> > the Debian secretary. However most of the developers that seconded the first
> > ballot of GR 2021_002 were experienced developers that would be have been
> > able to heed the recommendation given in this GR.
> 
> seems I missed your ballot proposal when I suggested mine in 
> https://lists.debian.org/debian-vote/2022/03/msg00021.html
> (Message-id: yihtkywt2lhdl...@layer-acht.org>), I'm sorry and I'm blaming
> information overload everywhere, which is why I'm behind in catching up on
> reading @-vote.

> Anyway, how do we proceed here?

We should merge them! Maybe you could suggest a new wording ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


signature.asc
Description: PGP signature

Re: Reaffirm public voting

[Bill Allombert]

On Fri, Mar 04, 2022 at 04:24:46PM +0100, Stéphane Glondu wrote:
> > A voting system which is transparent only to some, is undemocratic and
> > will lead to few people in the know, which is diagonal to Debians goals
> > of openness and transparency.
> 
> I'm not sure what you mean here. From some point of view, TLS is also
> transparent "only to some", since very few people understand the
> mathematics behind the crypto involved there. Yet, we don't promote
> unsecured communications where a TLS-secured variant exists.

TLS is not a voting system, so it does not need to have the same
property to be useful.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Alternative: only make vote tally available to DD (or to voters)

[Bill Allombert]

A suggestion:

An alternative to secret vote would be to make the vote tallies only
accessible by DD (or more generally to people allowed to vote, whether
they did not not).

This would still allow voters to check the vote but would not allow
outside parties to use it (unless some DD leaks it, alas).

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Reaffirm public voting

[Bill Allombert]

On Fri, Mar 04, 2022 at 04:24:46PM +0100, Stéphane Glondu wrote:
> Hello,
> 
> Le 04/03/2022 à 11:42, Holger Levsen a écrit :
> > The GR proposal for secret voting is silent on implenentation details,
> > probably because secret and transparent voting is, well, impossible to
> > achieve fully, [...]
> 
> It is possible to achieve some reasonable level of secrecy and
> transparency (and verifiability)... it is an active research topic per
> se. Belenios came out of this research, devotee-ng could also benefit
> from this research.
> 
> Disclaimer: I am upstream of Belenios in my dayjob.

I have voted several time using Belenios. This is probably the most
advanced free software voting solution. This has been useful to lots
of organisation during the lockdown.

However I feel this GR is putting the cart before the horses.
Before voting for or against a new voting system, we need to experiment
with them and see how they can be made to fit Debian. The secrecy used
for DPL elections is too weak if the purpose is to protect against
contentious GR.

That is why my own ballot proposal just say to keep the vote as is for
the time being and to discourage non-technical contentious GR.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Alternative: only make vote tally available to DD (or to voters)

[Bill Allombert]

On Fri, Mar 04, 2022 at 08:47:40PM +0100, Lucas Nussbaum wrote:
> Hi,
> 
> On 04/03/22 at 19:36 +0100, Bill Allombert wrote:
> > A suggestion:
> > 
> > An alternative to secret vote would be to make the vote tallies only
> > accessible by DD (or more generally to people allowed to vote, whether
> > they did not not).
> > 
> > This would still allow voters to check the vote but would not allow
> > outside parties to use it (unless some DD leaks it, alas).
> 
> I believe that's a useful compromise, and I would second this option.

As I understand, the constitution does not require the secretary to
make the vote tallies available to the whole world, so we might not need a
GR for that.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: eMail voting (was GR: Hide Identities of Developers Casting a Particular Vote)

[Bill Allombert]

On Mon, Mar 07, 2022 at 06:41:54PM +, Thorsten Glaser wrote:
> >At the same time it relaxes the requirement that the secretary must
> >conduct a vote via email.  There are no current plans to move away from
> 
> This is a very bad idea.
> 
> Alternative solutions may
> • have accessibility problems (not work with lynx, for example)
> • require different transport (eMail can be done in batches)
> • be tricky to do with PGP signatures (and substituting web-ish
>   logins has its own kind of trouble (not least with lynx compat))
> • require more on the system, especially if it does not work with
>   lynx (such as heavy-weight UI with JS-capable browsers)
> • be more easy to filter (think countries’ web firewall) than eMail
> • have age requirements (many web services exclude minors for no
>   good reason)

The main reason we should stick with email is that so far every
Debian developpers has agreed to communicate within Debian by email
when joining. Moving to another system would be potentialy divisive with
little benefit.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Secure, Secret, and Publicly Verifiable Voting

[Bill Allombert]

On Sun, Mar 06, 2022 at 11:26:28AM -0800, Russ Allbery wrote:
> "Barak A. Pearlmutter"  writes:
> 
> > In the discussion of the "voting secrecy" resolution, people seem to
> > have assumed that it is impossible for a voting system to be
> > simultaneously secure, tamper-proof, have secret ballots, and also be
> > end-to-end publicly verifiable meaning transparent verification of the
> > final tally, with voters able to verify that their own vote was properly
> > counted. (Our current system does not have secret ballots, but does
> > embody the other properties.)
> 
> > As it turns out, magic cryptographic fairy dust allows *all* these
> > properties to coexist. This is not to say that we *should* have secret
> > ballots. Just that we *could*, without sacrificing transparency etc.
> 
> This is what the discussion of Belenios is about.  It's a voting system
> that makes better use of cryptographic fairy dust than what we're
> currently using.

As I understand, Belenios does not make much of a difference compared to
the system used for DPL election.
It does not provide plausible deniability.
It mostly reduce the trust needed to be put on the secretary, but this
is not why this GR was proposed.

I still consider this GR to be premature.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: GR Ballot Option: (first draft) No change to voting, recommend against GR for non-technical issues

[Bill Allombert]

On Fri, Mar 04, 2022 at 11:56:07PM +, Holger Levsen wrote:
> hi Bill,
> 
> On Fri, Mar 04, 2022 at 04:12:44PM +0100, Bill Allombert wrote:
> > > Anyway, how do we proceed here?
> > We should merge them! Maybe you could suggest a new wording ?
> 
> given that my proposal already showed up on
> https://www.debian.org/vote/2022/vote_001#textc could I please ask you
> (or anybody else) to look at what's missing compared to your proposal?

The recommendation against non-technical GR ?

(which maybe actually more important than whether the vote is secret or
note).

Cheers,
Bill.

Re: Question to all candidates: registering Debian as an organization

[Bill Allombert]

On Thu, Mar 17, 2022 at 05:30:30PM +0100, Christian Kastner wrote:
> Jonathan has already addressed this in his platform, acknowledging Brian
> Gupta's 2020 campaign focus on this, so this is mostly a question for
> Hideki and Felix:
> 
> What is your position on registering Debian as an organization?

Could someone explain what does that mean ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Question to all candidates: registering Debian as an organization

[Bill Allombert]

On Mon, Mar 21, 2022 at 09:41:49AM +0100, Christian Kastner wrote:
> Currently, the Project has no legal standing of its
> own, meaning that within any legal context, there is no Project.

Indeed, it is a great feature of Debian that it is not bound to any
particular juridiction, it only exists through consensus of its members.

> You can't donate to Debian, you donate to some other organization (SPI). The
> DPL can represent the Project only formally, as formally, it doesn't
> exist yet. The Project can't own hardware directly, or hold copyrights
> directly. It's all down to individuals.

> A common pattern to address this within the open source world is to
> create a non-profit legal entity, e.g. the FSF Foundation or the GNOME
> Foundation.

But a legal entity would be registered to some country (the US in the
above two cases) and would be bound to its juridiction.
What if the DPL is from some country under US sanction list like Cuba
used to ? What if we need the non-us archive back ?
(same, replacing US by the country of your choice) ?

If there was a single Debian foundation, Debian members would be split
between those that are in the juridiction of the foundation and those
that are not and the former would be inevitably advantaged.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Question to all candidates: registering Debian as an organization

[Bill Allombert]

On Mon, Mar 21, 2022 at 11:40:36AM +0100, Gard Spreemann wrote:
> > If there was a single Debian foundation, Debian members would be split
> > between those that are in the juridiction of the foundation and those
> > that are not and the former would be inevitably advantaged.
> 
> Would moving such an entity in the face of adverse legal conditions, if
> and when they arise, be a difficult operation? (I have absolutely no
> idea myself)

Moveing money between countries is always a major problem.
That is why it is best for Debian to have money in different countries 
registered with different organization.
At minimum you can reimburse expenses in the local money, which is
always much cheaper.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: General resolution: Condemn Russian invasion of the Ukraine

[Bill Allombert]

On Thu, Mar 31, 2022 at 12:31:18PM +0200, Julian Andres Klode wrote:
> Under 4.1.5 of the Constitution, the developers by way of GR are the
> body who has the power to issue nontechnical statements.
> 
> This is a proposal for Debian to issue a statement on an
> issue of the day as given as an example, the recent invasion
> of Ukraine.
> 
>  Text of GR 
> 
> The Debian project issues the following statement:
> 
> The Debian project strongly condemns the invasion of Ukraine by
> Russia. The Debian projects affirms that Ukrain is a souvereign
> nation which includes the Donbas regions of Luhansk, as well as
> Crimea, which has already been illegaly annexed by Russia.

In the previous GR I offered an amendment:

2) General resolutions that probe developpers opinions about
non-technical issues outside the social contract are discouraged.

I also wrote
""
For the record, I am not actually in favor of holding secret votes, even
thought I fully agree with the developpers who felt that voting might
open them to abuse, because the issues raised by GR 2021_002 are much
more serious than the secret vote issue, viz, that the Debian project is
not the collection of opinions of its members since the members only
agreed to fulfill the social contract when acting on behalf of Debian
and not in general, and that their opinions outside of this is a private
matter that must not be probbed, and that even the agregate result of
the vote is already leaking information that the Debian project has no
purpose to gather and publish.
""

It seems it is necessarry to repeat it...

In this instance, Debian taking a public position on this could lead
to harm toward some Debian members, independently of their vote and
is unlikely to achieve much.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: General resolution: Condemn Russian invasion of the Ukraine

[Bill Allombert]

On Fri, Apr 01, 2022 at 04:17:49PM -0400, Tiago Bortoletto Vaz wrote:
> I'm glad to see that secret votes as we have now didn't seem to encourage
> 'opinions about non-technical issues outside the social contract'. So far, 
> such
> GR proposal reached zero support, 

Debatable, as the archive show.

> possibly an indication that we didn't need to
> keep publishing individual votes in order to collectively keep common sense. 
> Thus,
> although I agree with your concerns, I keep believing that a correlation
> between vote secrecy and arbitrary GRs is currently absent in our project.

Sorry, I did not mean to imply correlation in this way.

However the 2021_002 GR was a trigger for the secret vote GR proposal,
and we should be better addressing the root cause than the effect.

In any case, I am glad you agree with my concerns.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Possible draft non-free firmware option with SC change

[Bill Allombert]

Le Sun, Sep 11, 2022 at 08:19:26AM +0200, Simon Josefsson a écrit :
> The problem is caused by hardware manufacturer chosing to require
> non-free works for their use.  The blame for that choice lies on the
> hardware manufacturer, not on Debian.  Accepting the blame for someone
> else's choices and taking on the responsibility solve the consequences
> of that choice seems misguided to me.  It makes it harder for users to
> experience the frustration of such hardware themselves.  I disagree they
> always get the non-free installer eventually: some end up learning about
> the problem and chose better hardware.  Some end up reverse engineering
> their hardware, and contributing to a free solution.  Some dislike other
> distributions taking a less rigid stance on non-free works, and will
> come up with work-arounds to get Debian to work on the hardware.  If
> Debian takes on itself to solve the problems with non-free hardware, I
> think we are in more difficult position to ask for a change.

Seconded.
We fought against lack of Linux drivers, then against the lack of free
drivers. Now, since in a lot of situation it is not tenable not to
provide Linux drivers (because Linux is the dominant server OS),
since it is not tenable to provide only non-free drivers (because
entreprise distros do not ship them), the move is toward smaller and
smaller drivers loading larger and larger non-free firmware.

Debian should not trick users into downloading non-free files.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Possible draft non-free firmware option with SC change

[Bill Allombert]

Le Mon, Sep 12, 2022 at 09:19:59PM +, Scott Kitterman a écrit :
> On September 12, 2022 8:23:22 PM UTC, Bill Allombert  
> wrote:
> >Le Sun, Sep 11, 2022 at 08:19:26AM +0200, Simon Josefsson a écrit :
> >> The problem is caused by hardware manufacturer chosing to require
> >> non-free works for their use.  The blame for that choice lies on the
> >> hardware manufacturer, not on Debian.  Accepting the blame for someone
> >> else's choices and taking on the responsibility solve the consequences
> >> of that choice seems misguided to me.  It makes it harder for users to
> >> experience the frustration of such hardware themselves.  I disagree they
> >> always get the non-free installer eventually: some end up learning about
> >> the problem and chose better hardware.  Some end up reverse engineering
> >> their hardware, and contributing to a free solution.  Some dislike other
> >> distributions taking a less rigid stance on non-free works, and will
> >> come up with work-arounds to get Debian to work on the hardware.  If
> >> Debian takes on itself to solve the problems with non-free hardware, I
> >> think we are in more difficult position to ask for a change.
> >
> >Seconded.
> >We fought against lack of Linux drivers, then against the lack of free
> >drivers. Now, since in a lot of situation it is not tenable not to
> >provide Linux drivers (because Linux is the dominant server OS),
> >since it is not tenable to provide only non-free drivers (because
> >entreprise distros do not ship them), the move is toward smaller and
> >smaller drivers loading larger and larger non-free firmware.
> >
> >Debian should not trick users into downloading non-free files.
> 
> All this is, is a preference for permanent non-free firmware that can't be 
> updated or fixed.  I don't think it serves our users at all.

We should at minima ask that the license of the firmware provides at
least the right afforded by an hardwired firmware with respect to resale,
replacement, statutory warranty and general copyright law.

I have been installing Debian for more than 20 years and I have never needed
to use the non-free installer.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Possible draft non-free firmware option with SC change

[Bill Allombert]

Le Tue, Sep 13, 2022 at 11:56:07AM +0500, Andrey Rahmatullin a écrit :
> Do you too agree with the position that having non-free firmware stored in
> your hardware is better than having it loaded from your OS?

My position is that the laws governing embedded firmware are much
more favorable to the users than the laws governing freestanding
firmware. 

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Possible draft non-free firmware option with SC change

[Bill Allombert]

Le Thu, Sep 08, 2022 at 11:29:07AM +0200, Simon Josefsson a écrit :
> Russ Allbery  writes:
> 
> I believe the Debian project is permitted to publish non-free installers
> under the current DSC/DFSG (which it actually is doing today; just
> hidden), but according to the DSC it is not part of the Debian system.

Exactly. 

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Possible draft non-free firmware option with SC change

[Bill Allombert]

Le Tue, Sep 13, 2022 at 02:37:49PM +, Bill Allombert a écrit :
> Le Tue, Sep 13, 2022 at 11:56:07AM +0500, Andrey Rahmatullin a écrit :
> > Do you too agree with the position that having non-free firmware stored in
> > your hardware is better than having it loaded from your OS?
> 
> My position is that the laws governing embedded firmware are much
> more favorable to the users than the laws governing freestanding
> firmware. 

To gives a random example: firmware-iwlwifi 
(by the way the link in packages.d.o to the copyright file does not work
https://metadata.ftp-master.debian.org/changelogs//non-free/f/firmware-nonfree/firmware-nonfree_20210315-3_copyright
return 404
)

* No reverse engineering, decompilation, or disassembly of this software
  is permitted.

This would not be legal for embedded firmware

 THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
 FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED

You cannot disclaim warranty on hardware. You have to provide statutory
warranty.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Possible draft non-free firmware option with SC change

[Bill Allombert]

Le Tue, Sep 13, 2022 at 10:17:16PM +0200, Tobias Frost a écrit :
> On Tue, Sep 13, 2022 at 07:10:24PM +0000, Bill Allombert wrote:
> > Le Tue, Sep 13, 2022 at 02:37:49PM +0000, Bill Allombert a écrit :
> > > Le Tue, Sep 13, 2022 at 11:56:07AM +0500, Andrey Rahmatullin a écrit :
> > > > Do you too agree with the position that having non-free firmware stored 
> > > > in
> > > > your hardware is better than having it loaded from your OS?
> > > 
> > > My position is that the laws governing embedded firmware are much
> > > more favorable to the users than the laws governing freestanding
> > > firmware. 
> > 
> > To gives a random example: firmware-iwlwifi 
> > (by the way the link in packages.d.o to the copyright file does not work
> > https://metadata.ftp-master.debian.org/changelogs//non-free/f/firmware-nonfree/firmware-nonfree_20210315-3_copyright
> > return 404
> > )
> > 
> > * No reverse engineering, decompilation, or disassembly of this software
> >   is permitted.
> >  FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED
> > 
> > You cannot disclaim warranty on hardware. You have to provide statutory
> > warranty.
> 
> You can't disclaim statutory warranty, regardless if its hardware or software.
> 
> However, you can write a lot of sentences in your licenses, even some 
> sentences
> which are legally ineffective…
> 
> Disclaimer: IANAL. This is not legal advice, but my oppinion.

I am not a lawyer either, but Intel _does_ have lawyers that drafted
this that way, and they know exactly what advantage they can get from
it.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Possible draft non-free firmware option with SC change

[Bill Allombert]

Le Wed, Sep 14, 2022 at 10:23:05AM +0200, Simon Josefsson a écrit :
> > However, I'm pointing out that Debian generally follows a different
> > tactic. And I don't think that it would be a good idea for Debian to
> > switch tactics.
> 
> Right, I agree, although my perception is that Debian is another
> lighthouse here, and that this is fine.  Debians' DFSG and the rejection
> of GFDL Invariant sections are ridiculed elsewhere much the same way the
> FSF's positions on non-free firmware is ridiculed here.  I happen to
> like these lighthouse properties of both Debian and the FSF, as it helps
> me navigate the free software sea.  I don't think FSF or Debian would
> have been as successful as they have been without these lighthouse
> properties.
> 
> I agree it doesn't make sense for either organization to change
> approach.  I do believe that what we are seeing in this vote, however,
> is that Debian _is_ changing tactics: rather than providing a 100% free
> Debian (guided by the DSC/DFSG) and using that as a tactic to change the
> world, Debian will (under A/E) provide a 99% free Debian.

This is how I feel too.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Possible draft non-free firmware option with SC change

[Bill Allombert]

Le Wed, Sep 14, 2022 at 12:37:08PM +0200, Philip Hands a écrit :
> Simon Josefsson  writes:
> 
> ...
> > I agree it doesn't make sense for either organization to change
> > approach.  I do believe that what we are seeing in this vote, however,
> > is that Debian _is_ changing tactics: rather than providing a 100% free
> > Debian (guided by the DSC/DFSG) and using that as a tactic to change the
> > world, Debian will (under A/E) provide a 99% free Debian.
> 
> Stretching that metaphor a little: making non-free firmware available
> in the installer strikes me as equivalent to offering Wellington boots
> to new arrivals at the beach, so that they can wade across the muddy
> patch to get to the nice dry, sandy bit of beach where we play barefoot.

Yes, but this is not the question at hand. Nobody is suggesting that the
non-free installer should not exist, but whether it should be considered
part of Debian or part of non-free. 

Debian tradition of clearly seperating free and non-free should be
upholded.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Possible draft non-free firmware option with SC change

[Bill Allombert]

On Thu, Sep 15, 2022 at 03:14:05PM +0200, Wouter Verhelst wrote:
> IME, often, lawyers go "this probably won't do anything, but it can't
> harm us, so meh, let's try and see what we can get from a judge if it
> ever comes to it".
> 
> Or even "I've seen this in other licenses, can't hurt, let's copy".
> 
> If a requirement like that gets thrown out in court, they haven't lost
> anything, but if it *doesn't* get thrown out, they have gained an
> advantage.

Indeed, but Debian should not promote this.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

This does not have to be a GR

[Bill Allombert]

Dear Debian voters,

While Debian has stakes in the CRA, and should issue a statement if
only to show we exists, I am quite sure that a GR is not necessary for Debian
to issue such statement, and I am quite unconvinced the GR process is the best
option for the purpose of drafting such statement.

I note that this is not the first law proposal that impact Debian and we never
did used the GR process for issuing a position statement.

The DPL could delegate to a group of people knowledgeable in EU law to draft
a statement that is congruent with the interest of Debian.

EU law is significantly different from US law and publishing a statement that
either misrepresent the CRA or the current state of EU law is not likely to
be taken seriously, so we need some care.

We have legitimate reasons to feel concerned by the impact of this law, but
all the more reasons to act cautiously.

I advocated previously against using the GR process to issues statements
related to non-technical issues outside of Debian and I reiterate it here.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


signature.asc
Description: PGP signature

Re: This does not have to be a GR

[Bill Allombert]

On Wed, Nov 22, 2023 at 12:37:54AM +0100, Kurt Roeckx wrote:
> On Tue, Nov 21, 2023 at 10:26:09PM +0100, Bill Allombert wrote:
> > Dear Debian voters,
> > 
> > While Debian has stakes in the CRA, and should issue a statement if
> > only to show we exists, I am quite sure that a GR is not necessary for 
> > Debian
> > to issue such statement, and I am quite unconvinced the GR process is the 
> > best
> > option for the purpose of drafting such statement.
> > 
> > I note that this is not the first law proposal that impact Debian and we 
> > never
> > did used the GR process for issuing a position statement.
> > 
> > The DPL could delegate to a group of people knowledgeable in EU law to draft
> > a statement that is congruent with the interest of Debian.
> 
> I'm not sure that the DPL has such authority, since it's a power
> giving to the developers by way of GR.

The project has published a number of statements across its history without
them following a GR, see the archive of debian-announce and debian-news, so
this is the precedent.

> I would also like to point out that, in the current state, on Saturday
> the discussion period is over and a vote is automatically called.

I understand. I regret that the current system is such that the GR proposal
is announced to debian-devel-announce only after the vote is called.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


signature.asc
Description: PGP signature

Re: This does not have to be a GR

[Bill Allombert]

On Tue, Nov 21, 2023 at 04:54:30PM -0600, Gunnar Wolf wrote:
> Bill Allombert dijo [Tue, Nov 21, 2023 at 10:26:09PM +0100]:
> > Dear Debian voters,
> > 
> > While Debian has stakes in the CRA, and should issue a statement if
> > only to show we exists, I am quite sure that a GR is not necessary for 
> > Debian
> > to issue such statement, and I am quite unconvinced the GR process is the 
> > best
> > option for the purpose of drafting such statement.
> > 
> > I note that this is not the first law proposal that impact Debian and we 
> > never
> > did used the GR process for issuing a position statement.

> We never did _successfully_ use it. We have _tried_ to use it
> (i.e. 2021_002).

Sorry, I meant 'a position statement with respect to a law proposal'.

> This text was in fact drafted by a lawyer (I don't know if by a _set_
> of lawyers) and discussed among DDs at several in-person meetings
> before reaching this stage. I strongly advocated using the GR process,
> as it has already been subjected to a long discussion, and the
> timeframe for it to be usefully considered is drawing to an end.

Was it drafted by a lawyer familiar with EU law ?
We should have started by having a EU lawyer explaining what the CRA
actually mean and proceed from that.

> At this point, and in part given that GR 2021_003 introduced time
> limits, I think the GR process might produce the swiftest results, and
> it will yield the best legitimacy-wise (i.e. the whole project is
> invited to debate and improve the proposed text, and accept it
> above/below the approval threshold.

But this might as well degenerate into a political referendum having little
to do with Debian. As it stands we have two ballots which are similar in intent
except that one is worded to be more EU-optimistic than the other. So at the
end of the day, the GR will be a referral whether DDs are more EU-pessimistic or
EU-optimistic. I repect my fellow DD political views, but this is not the 
purpose
of Debian to query its members opinions about a topic¹ unrelated to the social
contract. This will only fracture the project.

If we want a GR, we should focus on having a single ballot option, that strive 
to
be neutral and straight to the point.

Maybe a ballot option delegating the issuing of a statement to the DPL ?

¹ especially one when we are bound to have widely different but valid 
views depending on where we live.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.


signature.asc
Description: PGP signature

Re: This does not have to be a GR

[Bill Allombert]

On Wed, Nov 22, 2023 at 09:05:26AM +0100, Thomas Goirand wrote:
> Excuse me to insist with vocabulary, but since you've use the word "law" 6
> times above: the EU isn't a state or a nation, and doesn't make laws. We're
> talking about "directives", that eventually will be implemented as laws in
> each member state. This is a huge difference that make it possible to fight
> the CRA at multiple levels. This also mean that the CRA wording isn't as
> important as the wording of its implementation as a law in each member
> state.
> 
> Also, once the directive is passed, it's still theoretically possible to
> fight its wording in each state. Seen the other way around: it's possible
> that the implementation as a law in each country is worse than then
> directive itself, we must pay attention to it (it's probably even more
> difficult for us this way, as there will be 27 implementations to take care
> of).

All what you say is correct, but note that it was the same for the EUCD for 
example
and Debian did not issue a statement. 

Debian did not issues statement for similar US laws either, though we
participated to the "web blackout" against SOPA/PIPA but we did not do a GR
beforehand.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


signature.asc
Description: PGP signature

Re: Changing supermajority requirements

[Bill Allombert]

Le Wed, Nov 22, 2023 at 11:00:57AM +0100, Ansgar a écrit :
> Hi,
> 
> the Constitution has several supermajority requirements that seem
> excessive to me:
> 
> Constitution changes:
> 
> +---
> | 4.1.2: Amend this constitution, provided they agree with a 3:1 majority.
> | [...]
> | 5.1.5.3: A Foundation Document requires a 3:1 majority for its 
> supersession. [...]
> +---
> 
> Constitutional changes to my country's constitution only require a 2:1
> majority. A 3:1 majority seems excessive for that reason and I would
> suggest to change both of these to 2:1 for that reason.
> 
> I think a supermajority is fine for changing fundamental rules, so more
> than a simple majority is okay.

Note that so far in almost no cases a GR failed due to the supermajority
requirement.
So it is difficult to read your proposal without thinking you have
ulterior motives, that maybe you should communicate ?

But note, Debian is not a country, we are free to join other similar
floss groups with or without leaving Debian.
The Foundation Documents are about the only things that all DD are
supposed to agree with. Changing is likely to alienate some of them
(and it did in the past) so they deserve some protection, just not
to racture the project.

Cheers,
Bill

Re: call for seconds - separate proposal text for 2023/vote_002

[Bill Allombert]

Le Wed, Nov 22, 2023 at 07:16:48PM +0100, Bart Martens a écrit :
> 
> The Debian project asks the EU to not draw a line between commercial
> and non-commercial use of FOSS.

But the EU already does, all the time, really. This is simply not
realistic.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Call for seconds: Delegate to the DPL

[Bill Allombert]

Dear Developers,

I offer the following ballot option for your consideration.

- GENERAL RESOLUTION STARTS -

The Debian developers delegate to the Debian Project Leader the task of issuing
a Public Statement about the 'EU Cyber Resilience Act and the Product Liability
Directive' that addresses Debian interests in the matter.

- GENERAL RESOLUTION ENDS -

Respectfully submitted,
Bill.


signature.asc
Description: PGP signature

Re: Call for seconds: Delegate to the DPL

[Bill Allombert]

Le Fri, Nov 24, 2023 at 07:38:40PM +0200, Jonathan Carter a écrit :
> Hi Bill
> 
> On 2023/11/24 19:14, Bill Allombert wrote:
> > I offer the following ballot option for your consideration.
> > 
> >  - GENERAL RESOLUTION STARTS -
> > 
> > The Debian developers delegate to the Debian Project Leader the task of 
> > issuing
> > a Public Statement about the 'EU Cyber Resilience Act and the Product 
> > Liability
> > Directive' that addresses Debian interests in the matter.
> > 
> >  - GENERAL RESOLUTION ENDS -
> 
> I follow your logic in proposing this, although my interpretation of
> ¶5.1.4[0] in our constitution leads me to believe that the DPL does not need
> any delegation for this, so perhaps the intention becomes more of "Let the
> DPL decide".

I agree with you on that point, but note that what matters
constitutionaly is that the DDs via the GR process has authority to do
it, and so have also the authority to delegate it, even to someone who
would otherwise have this authority.

The point of this ballot option is to differentiate from 'NOTA' which
can be interpreted as precluding from issuing a statement.

> In February I posted[1] about the CRA to debian-project[1]. My intention was
> to get a few good people to spend some time to focus on this, since my
> available bandwidth for this was low (and continued to be since then).
> 
> I'm not sure that it's a good idea to leave it as a DPL task, it might delay
> an actual public statement by a month or even more. That said, I'm not
> completely against the idea, if this ends up happening I would likely
> combine the best current ideas in an etherpad and invite everyone to list
> and hammer out any remaining issues.

My view is that when drafting such statement, we should always keep in
mind what is its purpose. If it is to be read by the EU regulators, it
should be written by someone knowing their legal languages.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Call for seconds: Delegate to the DPL

[Bill Allombert]

On Sat, Nov 25, 2023 at 09:59:16AM -0600, Gunnar Wolf wrote:
> As I understand, the EU legislative process is quite advanced now, and
> I doubt we have the time to build "the perfect response". And the
> answer from the EU legislative body will not be to read and consider
> each bullet point we make --- While they are all important mostly *for
> people quoting and making press releases* in the technical community,
> the European legislative bodies will just see "oh, a biggish project
> opposes CRA".

Or maybe "yet another volunteer project does not understand EU language law and
misunderstand the CRA, just ignore". This is what we should avoid.
The EU is more sophisticated than what you seems to imply. They see the
political advantage they can obtain by having a FLOSS policy. Whether this
FLOSS policy is favorable to Debian is a different issue.

> We want to communicate the reasoning as clearly as possible to our
> peers and to journalists. But we want *something* to be issued while
> we are still in the due time for the legislative process.

Let us be honest, the majority of peers and journalists do not understand EU
language law.
Writing for them and writing for the EU are two very different things.
We should not just put out a statement just because others have done so, because
we might inadvertently propagate FUD.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Call for seconds: Delegate to the DPL

[Bill Allombert]

Le Sun, Nov 26, 2023 at 04:14:51PM -0500, Roberto C. Sánchez a écrit :
> On Sun, Nov 26, 2023 at 10:06:42PM +0200, Jonathan Carter wrote:
> > On 2023/11/26 21:24, Bill Allombert wrote:
> > > We should not just put out a statement just because others have done so, 
> > > because
> > > we might inadvertently propagate FUD.
> > 
> > Yep, it's a minefield. Anything we say can be used by a manipulative
> > politician to make it seem that we support their cause.
> > 
> In the same way that our silence can also be used.

Much less, because there have been other laws proposal that could affect
us and we have never put out a similar statement so nobody should expect
Debian to make one now.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Call for seconds: Delegate to the DPL

[Bill Allombert]

On Tue, Nov 28, 2023 at 09:25:17AM -0600, Gunnar Wolf wrote:
> This is also something we discussed before sending this call for
> votes. But how can we gauge whether the project is OK with issuing
> political statements or not? The only tool we were able to find is a
> GR.

The less we know about the political opinion of each others, the better for
the project. After all we only agreed to uphold the SC and nothing else.

We are a technical entity. We do not need to know other developers opinions on
issues unrelated to FLOSS to work together, and let us face it, it is easier to
work together if we ignore whether we have major political disagreement.

And it is quite difficult discussing a ballot option without revealing such
opinions. We have enough topics for flamewar already. This will only leads
to more fracturation of the project.

But this GR is not about issuing political statements in general, it is about
issuing a particular statement, which leads directly to the second issue, are
GR (with the time limit, the amendment process, etc) the best medium to draft
political statement that correctly addresses the issue while furthering Debian
goal ?

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Call for seconds: Delegate to the DPL

[Bill Allombert]

On Tue, Nov 28, 2023 at 04:36:29PM -0600, Gunnar Wolf wrote:
> Bill Allombert dijo [Tue, Nov 28, 2023 at 10:07:29PM +0100]:
> > On Tue, Nov 28, 2023 at 09:25:17AM -0600, Gunnar Wolf wrote:
> > > This is also something we discussed before sending this call for
> > > votes. But how can we gauge whether the project is OK with issuing
> > > political statements or not? The only tool we were able to find is a
> > > GR.
> > 
> > The less we know about the political opinion of each others, the better for
> > the project. After all we only agreed to uphold the SC and nothing else.
> > 
> > We are a technical entity. We do not need to know other developers opinions 
> > on
> > issues unrelated to FLOSS to work together, and let us face it, it is 
> > easier to
> > work together if we ignore whether we have major political disagreement.
> 
> Yet, my belief is that all human interactions are political in
> nature. In some aspects of politics, you and I will not be the least
> aligned. But I believe our project is _first and foremost_ a political
> statement (that produces a first-grade technological artifact).

One major risk for Debian continued existence is that we start to become
suspicious of each other political views outside FLOSS, that we start to see
"collaborating with someone as part of our Debian activity" as "associating" 
with them, and that "associating" with them start to become socially
problematic.  There is a precedent for that.

That is why I am quite against the whole 'community' view of Debian.

In practice, it is very hard to participate in such GR without revealing 
political views, as you can see by reading the discussion.

> > And it is quite difficult discussing a ballot option without revealing such
> > opinions. We have enough topics for flamewar already. This will only leads
> > to more fracturation of the project.
> > 
> > But this GR is not about issuing political statements in general, it is 
> > about
> > issuing a particular statement, which leads directly to the second issue, 
> > are
> > GR (with the time limit, the amendment process, etc) the best medium to 
> > draft
> > political statement that correctly addresses the issue while furthering 
> > Debian
> > goal ?
> 
> I do not know. But I think that's something that can, and ought, be
> put to the table.

It seems like you are underestimating the risks and overestimating the rewards.
Such statement is only useful if written by people that understand enough of
EU law terminology to address the issue. I asked whether the lawyer that drafted
it was familiar with EU law and it does not seem to be the case. We should not
make a statement that can be used against us.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: recent changes to the CRA address FLOSS community concerns?

[Bill Allombert]

Le Sat, Dec 09, 2023 at 11:41:08AM +0100, Ilu a écrit :
> There is also no way and no necessity to adapt the GA text based on
> unofficial rumors since ...
> 
> > ... the answer from the EU legislative body will not be to read and
> > consider each bullet point we make --- ... the European legislative
> > bodies will just see "oh, a biggish project opposes CRA".
> (Gunnar Wolf am 25.11.23 um 16:59)

This is just Gunnar's opinion, not a fact. 
It does not quite make sense for Debian to bet that EU will not read the
position statement. This denatures the purpose of this GR. 
If the statement is not meant to be read by the EU, who are the actual
recipients ? This should have been clearly stated in the ballot.

Cheers,
-- 
Bill. 

Imagine a large red swirl here.

Re: Debian Project Leader Elections

[Bill Allombert]

On Wed, Feb 12, 2003 at 11:28:06PM -0600, Debian Project Secretary wrote:
> Hi,
> 
> This is the final day of the nomination period, which started
>  on 2003/01/24, and shall end on 2003/02/14 00:00:00 UTC. The
>  campaigning period shall start then. Voting shall start on March 7th
>  (2003/03/07 0:0:0 UTC), and shall end on 2003/03/28 0:0:0 UTC.

Is it possible to have a list of people would have nominated themselves
available during the nomination period and not only after ? Maybe on
 ?  This list maybe important for someone who
hesitate to nominate h{is|er}self.

I know it is in debian-vote, but it is scattered along other posts,
and it would look more official in http://www.debian.org/vote/.

Thanks,

Cheers,
Bill.

Re: Debian Project Leader Elections

[Bill Allombert]

On Thu, Feb 13, 2003 at 10:47:10AM -0600, Manoj Srivastava wrote:
> >>>>> In article <[EMAIL PROTECTED]>, Bill Allombert <[EMAIL PROTECTED]> 
> >>>>> writes:
> 
>   I would expect a potential DPL candidate to be involved
>  enough in the project to read -vote, or to be able to at least look
>  at the archives. And, in any case, deciding on whether to run based
>  on who else is running probably is not a winning strategy: you don't
>  know who else may run, at the last minute. At the very least is
>  hints at a diffidence that bodes ill for someone who is required to
>  be a project leader.

I will certainly not discuss that, since you can do it already.
[and that I have no clues about what can mean the last sentence].

>  > I know it is in debian-vote, but it is scattered along other posts,
>  > and it would look more official in http://www.debian.org/vote/.
> 
>   Nominations are not official until after the nomination
>  period is over.

What does means official here ? That they cannot be retracted anymore ?
Or something else ?

Cheers,
Bill.

Re: "keep non-free" proposal

[Bill Allombert]

Anthony Towns wrote:
> On Wed, Jan 28, 2004 at 01:33:37PM -0500, Nathanael Nerode wrote:
> > Please, get Andrew's editorial-fixes proposal passed already. *sigh* I 
> > don't 
> > give a damn about the non-free issue either way, but I *do* care that the 
> > 'main' archive is *actually* free.
> 
> For someone who's not a developer, nor a n-m applicant, I'm not sure
> why you think your opinion is an important factor in any decision making.

I would like to express my disagreement toward attempt to reject input
from users and contributors[1] on issues that will impact them, by
resorting to ad hominem attack and sheer contempts in total disregard
of our current Social Contract. 

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 

[1] Debian-X <[EMAIL PROTECTED]>
 <[EMAIL PROTECTED]>


pgpC6VkKEBO0a.pgp
Description: PGP signature

Re: Request for discussion: Deferment of Changes from GR 2004-003

[Bill Allombert]

On Wed, Apr 28, 2004 at 01:50:31AM -0500, Debian Project Secretary wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi
> 
> Please refer to the following messages, in which a General
>  resolution was proposed, and seconded:
> 
> 
>  The Debian Project,
> 
>  affirming its committment to principles of freeness for
>  all works it distributes,
> 
>  but recognizing that changing the Social Contract today
>  would have grave consequences for the upcoming stable
>  release, a fact which does not serve our goals or the
>  interests of our users,

It seems the goal of this proposal is to have the Release Manager
reinstate the sarge-ignore status of some serious policy violations.

Unfortunately the above proposal is not seconded by Anthony Towns, 
nor I can find a statement from him on debian-vote on whether he would in
fact reinstate it if this GR was successful. 

Given the Release Manager decision after last vote was a surprise for most 
of us, It seems not unreasonnable to want a clear statement of Anthony
Towns before proceding further with this GR.

Reaching a more consensual position is certainly a laudable goal, but it
is difficult to do when one party do not want to participate in the
discussion, as happened during the last vote. This new GR would have been
appropriate as a ballot option for the previous vote.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgpuugc8iXdbx.pgp
Description: PGP signature

Moving clarifications to an Addendum instead of editing the SC ?

[Bill Allombert]

Dear fellow developers,

As far as I understand the motivation for the editorial change 
are twofold:

1) remove some ambiguities on the wording,
2) make the text look nicer from a literary point of vue.

However, the SC is a document which has quite an historical and
sentimental value for most of us, well, at least for me.

So I feel reluctant to change it to remove ambiguities, while I agree
on the interpretations that are reinforced.

For that reason, I would suggest than instead of altering the text of
the Social Contract, we add an Addendum spelling out the clarifications
we agreed upon.

I don't expect to have the resources to introduce a new proposal for this
GR, but I see most of the disagreements on this list being on the
precise wording of the changes than on the actual interpretation of the
SC, so it could be easier to reach an agreement on the Addendum text.

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 


pgpZI7zI0UyJc.pgp
Description: PGP signature

Re: Proposed General Resolution : IRC as a Debian communicationchannel

[Bill Allombert]

MR.MENKE UWADEDE'
#20 MANDELA CRESENT
SANDTON SOUTH AFRICA,
FAX; 871-762 -727949.
TEL; 871-762 -727947.
.
{CONFIDENTIAL}

 Dear sir,

 In order to transfer out (USD 126 M) One hundred and
 twenty six million United States Dollars) from
African
 Development Bank. I have the courage to ask you to
 look for a reliable and honest person who will be
 capable for
 this important business believing that you will never
 let me down either now or in future.

 I am, MR.MENKE UWADEDE', the Chief auditor of African
 Development Bank (ADB). There is an account opened in
 this bank in 1980 and since 1990 nobody has operated
 on this account again. after going through some old
 files in the records I discovered that if I do not
 remit this money out urgently it will be forfeited
for
 nothing. the owner of this account is Mr. Smith B.
 Andreas, a foreigner, and a miner at kruger gold co.,
 a geologist by profession and  he died since 1990. no
 other person knows about this account or any thing
 concerning it, the account has no other beneficiary
 and my investigation proved to me as well that this
 company does not know anything about this account and
 the amount involved is (USD 126M) One hundred and
 twenty six million United States Dollars million
 dollars. I want to first transfer USDM twenty six
 million United States Dollars from this money into a
 safe foreigners account abroad before the rest, but I
 don't know any foreigner, I am only contacting you as
 a foreigner because this money can not be approved to
 a local bank here, but can only be approved to any
 foreign account because the money is in us dollars
and
 the former owner of the account is Mr. Smith B.
 Andreas is  a foreigner too.  I know that this
message
 will come to you as a surprise as we  don't know our
 selves before, we will sign agreement, but be sure
 that it is real and a genuine business. I
 only got your contact address my from my secretary
who
 operates computer,
 with believe in god that you will never let me down
in
 this business you are the only person that I have
 contacted in this business, so please reply urgently
 so that I will inform you the next step to take
 urgently. Send also your private telephone and fax
 number including the full details of the account to
be
 used for the deposit.

 I want us to meet face to face or sign a binding
 agreement to bind us together so that you can receive
 this money into a foreign account or any account of
 your choice where the fund will be safe. and I will
 fly to your country for withdrawal and sharing and
 other investments.

 I am contacting you because of the need to involve a
 foreigner with foreign account and foreign
 beneficiary. I need your full co-operation to make
 this work fine. because the management is ready to
 approve this payment to any foreigner who has correct
 information of this account, which Iwill give to you
 later immediately, if you are able and with
capability
 to handle such amount in strict confidence and trust
 according to my instructions and advice for our
mutual
 benefit because this opportunity will never come
again
 in my life. I need truthful person in this business
 because I don't want to make mistake I need your
 strong assurance and trust.

 With my position now in the office I can transfer his
 money to any foreigner's reliable account which you
 can provide with assurance that this money will be
 intact pending my physical arrival in your country
for
 sharing. I will destroy all documents of transaction
 immediately we receive this money leaving no trace to
 any place. you can also come to discuss with me face
 to face after which I will make this remittance in
 your presence and two of us will fly to your country
 at least two days ahead of the money going into the
 account.

 I will apply for annual leave to get visa immediately
 I hear from you that you are ready to act and receive
 this fund in your account. I will use my position and
 influence to effect legal approvals and onward
 transfer of this money to your account with
 appropriate clearance forms of the ministries and
 foreign exchange departments.

 At the conclusion of this business, you will be given
 35% of the total amount, 60% will be for me, while 5%
 will be for expenses both parties might have incurred
 during the process of transferring.

 I look forward to your earliest reply through my
email
 address or by my tel: 871-762-72-7947, fax: 871
 762 72 7949.

 yours truly

 MENKE.










__
Do You Yahoo!?
Find a job, post your resume.
http://careers.yahoo.com


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

Re: Debian Project Leader Elections

[Bill Allombert]

On Wed, Feb 12, 2003 at 11:28:06PM -0600, Debian Project Secretary wrote:
> Hi,
> 
> This is the final day of the nomination period, which started
>  on 2003/01/24, and shall end on 2003/02/14 00:00:00 UTC. The
>  campaigning period shall start then. Voting shall start on March 7th
>  (2003/03/07 0:0:0 UTC), and shall end on 2003/03/28 0:0:0 UTC.

Is it possible to have a list of people would have nominated themselves
available during the nomination period and not only after ? Maybe on
 ?  This list maybe important for someone who
hesitate to nominate h{is|er}self.

I know it is in debian-vote, but it is scattered along other posts,
and it would look more official in http://www.debian.org/vote/.

Thanks,

Cheers,
Bill.


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

Re: Debian Project Leader Elections

[Bill Allombert]

On Thu, Feb 13, 2003 at 10:47:10AM -0600, Manoj Srivastava wrote:
> >>>>> In article <20030213105818.C7247@yellowpig>, Bill Allombert 
><[EMAIL PROTECTED]> writes:
> 
>   I would expect a potential DPL candidate to be involved
>  enough in the project to read -vote, or to be able to at least look
>  at the archives. And, in any case, deciding on whether to run based
>  on who else is running probably is not a winning strategy: you don't
>  know who else may run, at the last minute. At the very least is
>  hints at a diffidence that bodes ill for someone who is required to
>  be a project leader.

I will certainly not discuss that, since you can do it already.
[and that I have no clues about what can mean the last sentence].

>  > I know it is in debian-vote, but it is scattered along other posts,
>  > and it would look more official in http://www.debian.org/vote/.
> 
>   Nominations are not official until after the nomination
>  period is over.

What does means official here ? That they cannot be retracted anymore ?
Or something else ?

Cheers,
Bill.


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

Re: "keep non-free" proposal

[Bill Allombert]

Anthony Towns wrote:
> On Wed, Jan 28, 2004 at 01:33:37PM -0500, Nathanael Nerode wrote:
> > Please, get Andrew's editorial-fixes proposal passed already. *sigh* I don't 
> > give a damn about the non-free issue either way, but I *do* care that the 
> > 'main' archive is *actually* free.
> 
> For someone who's not a developer, nor a n-m applicant, I'm not sure
> why you think your opinion is an important factor in any decision making.

I would like to express my disagreement toward attempt to reject input
from users and contributors[1] on issues that will impact them, by
resorting to ad hominem attack and sheer contempts in total disregard
of our current Social Contract. 

Cheers,
-- 
Bill. <[EMAIL PROTECTED]>

Imagine a large red swirl here. 

[1] Debian-X <[EMAIL PROTECTED]>
 <[EMAIL PROTECTED]>


pgp0.pgp
Description: PGP signature