Re: Social Contract GR's Affect on sarge

[Michael Banck]

On Mon, Apr 26, 2004 at 11:46:43AM +0200, Martin Schulze wrote:
> Speaking of the GFDL, only those documents released under the GNU FDL
> are non-free that make use of invariant sections for anything else
> than its license, right?
> 
> Hence, every document released under the GNU FDL needs to be checked
> for every version, but the FDL doesn't render documentation non-free
> inherently, right?  It doesn't render it free inherently, either, which
> is very bad since a new version could become non-free unexpectedly.

Not according to Manoj's (still horribly formatted) position statement:

"The GNU FDL, as it stands today, does not meet the Debian Free Software
Guidelines. There are significant problems with the license, as detailed
above; and, as such, we cannot accept works licensed unde the GNU FDL
into our distribution."


Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html

Re: Social Contract GR's Affect on sarge

[Andreas Barth]

* Martin Schulze ([EMAIL PROTECTED]) [040426 12:10]:
> Anthony Towns wrote:

> > * firmware will need to be split out of the kernel into userspace
> >   in all cases
 
> It's good when this happens.

> > * debian-installer will need to be rewritten to support obtaining
> >   non-free firmware but not other non-free packages
 
> It would be a clean solution at the end of the day, so this is good.

I agree that both these issues are good in the end. However, I really
would prefer to tackle this issue after releasing of sarge. (On the
other hand, we now also have the time to restrict our kernel source
packages.)


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Social Contract GR's Affect on sarge

[Andrew Suffield]

On Mon, Apr 26, 2004 at 11:46:43AM +0200, Martin Schulze wrote:
> Speaking of the GFDL, only those documents released under the GNU FDL
> are non-free that make use of invariant sections for anything else
> than its license, right?

No. There are other issues with the GFDL, of the more common "This
license has a bug" variety that we get with lots of new
licenses. Those apply to every work licensed under it, and also need
to be fixed for the GFDL to be DFSG-free. There's no real reason why
they shouldn't be (resulting in a license that behaves how you
describe), except that RMS decided that he wouldn't discuss the
license with people who don't accept invariant sections as being free,
so getting anything done about the other problems has proven
difficult.

http://people.debian.org/~srivasta/Position_Statement.html provides a
decent summary of the issues.

-- 
  .''`.  ** Debian GNU/Linux ** | Andrew Suffield
 : :' :  http://www.debian.org/ |
 `. `'  |
   `- -><-  |


signature.asc
Description: Digital signature

Re: Social Contract GR's Affect on sarge

[Petter Reinholdtsen]

[Jochen Voss]
> By the way, what was the meaning of "editorial" in
> "Editorial changes to the Social Contract GR"?

Normally, in a political vote, "editorial change" is used to get
people to believe that a controversial change isn't, giving a minority
a better chance to get their vote passed while no-one is looking.

Re-vote?

Re: Social Contract GR's Affect on sarge

[Jochen Voss]

On Mon, Apr 26, 2004 at 02:56:09PM +1000, Anthony Towns wrote:
> The Social Contract now states:
> 
> ] 1. Debian will remain 100% free
> ] ...
> 
> As this is no longer limited to "software", and as this decision was
> made by developers after and during discussion of how we should consider
> non-software content such as documentation and firmware, I don't believe
> I can justify the policy decisions to exempt documentation, firmware,
> or content any longer, as the Social Contract has been amended to cover
> all these areas.

By the way, what was the meaning of "editorial" in
"Editorial changes to the Social Contract GR"?

Jochen
-- 
http://seehuhn.de/


signature.asc
Description: Digital signature

Re: Social Contract GR's Affect on sarge

[Martin Schulze]

Andreas Barth wrote:
> * Anthony Towns (aj@azure.humbug.org.au) [040426 07:10]:
> > As this is no longer limited to "software", and as this decision was
> > made by developers after and during discussion of how we should consider
> > non-software content such as documentation and firmware, I don't believe
> > I can justify the policy decisions to exempt documentation, firmware,
> > or content any longer, as the Social Contract has been amended to cover
> > all these areas.
> 
> I can remember that the title was "editorial changes", and I can't
> understand it how this can change the importance of the sections.
> Furthermore, the exceptions till now was not due to the fact that we
> don't require documentation to be free (quite contrary, there was a
> consensus on d-legal about GFDL not free), but due to the fact that we
> want to have enough time to come up with a proper solution.

Well, the changes were editorial to our understanding of the social
contract with regards to freeness of data, especially since this
was discussed over and over on debian-legal before.

Speaking of the GFDL, only those documents released under the GNU FDL
are non-free that make use of invariant sections for anything else
than its license, right?

Hence, every document released under the GNU FDL needs to be checked
for every version, but the FDL doesn't render documentation non-free
inherently, right?  It doesn't render it free inherently, either, which
is very bad since a new version could become non-free unexpectedly.

Regards,

Joey

-- 
The only stupid question is the unasked one.

Please always Cc to me when replying to me on the lists.

Re: Social Contract GR's Affect on sarge

[Matthew Garrett]

Martin Schulze wrote:

>Speaking of the GFDL, only those documents released under the GNU FDL
>are non-free that make use of invariant sections for anything else
>than its license, right?

No, everything under the GFDL appears non-free.
http://people.debian.org/~srivasta/Position_Statement.xhtml discusses
this in rather more length.

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: Social Contract GR's Affect on sarge

[Francesco P. Lovergine]

On Mon, Apr 26, 2004 at 11:23:16AM +0200, Martin Schulze wrote:
> Anthony Towns wrote:
> > As such, I can see no way to release sarge without having all these
> > things removed from the Debian system -- ie main.
> > 
> > This will result in the following problems:
> > 
> > * important packages such as glibc will have no documentation
> 
> This should not be too bad given that glibc is not only documented
> in its own info files but also in the man-pages package that is
> distributed from different sources.
> 
> Oh wait, man-pages became non-free upstream recently...
> 
> The Debian package was freed, though.
> 

Did you have a look to FSF-related software in the last few time?
Issue a 'man emacs' for instance


-- 
Francesco P. Lovergine

Re: Social Contract GR's Affect on sarge

[Martin Schulze]

Anthony Towns wrote:
> As such, I can see no way to release sarge without having all these
> things removed from the Debian system -- ie main.
> 
> This will result in the following problems:
> 
>   * important packages such as glibc will have no documentation

This should not be too bad given that glibc is not only documented
in its own info files but also in the man-pages package that is
distributed from different sources.

Oh wait, man-pages became non-free upstream recently...

The Debian package was freed, though.

>   * many pieces of hardware will not be supported by the Debian system
> itself

Since we already face this "problem" woody already due to new hardware
being incompatible with older one, only the number will grow.

>   * firmware will need to be split out of the kernel into userspace
> in all cases

It's good when this happens.

>   * firmware will need to be packaged separately from the
> kernel/X in all cases

Apparently.

>   * debian-installer will need to be rewritten to support obtaining
> non-free firmware but not other non-free packages

It would be a clean solution at the end of the day, so this is good.

>   * firmware for drivers needed for booting (network cards
> particularly) will need to be made available as udebs in
> non-free, and separate non-free d-i images will need to be
> made for people relying on that firmware

This is awkward, I admit.  On the other hand, developers also voted
to keep non-free distributed on debian.org machines, so this is a
good chance to support it accordingly, sigh.

> At the rate we're currently going, I don't really expect to be able to
> achieve this this year. In light of the new Social Contract, however,
> I don't believe there are any other decisions I can make in this area.

Thanks for the clarification.

Regards,

Joey

-- 
The only stupid question is the unasked one.

Re: Social Contract GR's Affect on sarge

[Martin Schulze]

Francesco P. Lovergine wrote:
> Did you have a look to FSF-related software in the last few time?

I normally use them, of course.

> Issue a 'man emacs' for instance

What am I supposed to read there?  Mine doesn't say that it's using
the FDL but since its date says it's from 1995 December 7, I doubt
it does.

Regards,

Joey

-- 
The only stupid question is the unasked one.

Please always Cc to me when replying to me on the lists.

Re: Social Contract GR's Affect on sarge

[Michael Banck]

On Mon, Apr 26, 2004 at 02:32:34PM +0200, Martin Schulze wrote:
> Francesco P. Lovergine wrote:
> > Issue a 'man emacs' for instance
> 
> What am I supposed to read there?  Mine doesn't say that it's using
> the FDL but since its date says it's from 1995 December 7, I doubt
> it does.

You're supposed to appreciate that although the Emacs manpage might
satisfy our requirements for inclusion in main, it is useless in
practice when compared to the GFDL manual/info page.

So even if the glibc functions might be documented in manpages in a
satisfactory way, this is probably not true for the rest of the GNU
packages.


Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html

Re: Social Contract GR's Affect on sarge

[Anthony Towns]

On Mon, Apr 26, 2004 at 11:23:16AM +0200, Martin Schulze wrote:
> > * many pieces of hardware will not be supported by the Debian system
> >   itself
> Since we already face this "problem" woody already due to new hardware
> being incompatible with older one, only the number will grow.

Joey, I realise you think this is the case, but it's not. It has been
quite possible to separate firmware into userspace, without separating
it into a separate package, or moving it to non-free.

GPL violations and DFSG violations are _always_ distinct: the former can
be fixed without moving stuff to non-free, and can never be fixed simply
by moving stuff to non-free; the latter can't be fixed without moving
stuff to non-free and can be fixed by just moving stuff to non-free.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
Don't assume I speak for anyone but myself. GPG signed mail preferred.

Protect Open Source in Australia from over-reaching changes to IP law
http://www.petitiononline.com/auftaip/ & http://www.linux.org.au/fta/


signature.asc
Description: Digital signature

Re: Social Contract GR's Affect on sarge

[Anthony Towns]

On Mon, Apr 26, 2004 at 11:15:59AM +0200, Andreas Barth wrote:
> * Anthony Towns (aj@azure.humbug.org.au) [040426 07:10]:
> > As this is no longer limited to "software", and as this decision was
> > made by developers after and during discussion of how we should consider
> > non-software content such as documentation and firmware, I don't believe
> > I can justify the policy decisions to exempt documentation, firmware,
> > or content any longer, as the Social Contract has been amended to cover
> > all these areas.
> I can remember that the title was "editorial changes", and I can't
> understand it how this can change the importance of the sections.

The title isn't the change, the contents of the GR is. The proposers
believed the changes were editorial, and that my and others'
interpretation was wrong, and sought to clarify the document so that
this was unambiguously the case.

> Furthermore, the exceptions till now was not due to the fact that we
> don't require documentation to be free (quite contrary, there was a
> consensus on d-legal about GFDL not free), but due to the fact that we
> want to have enough time to come up with a proper solution.

No, the exception is _entirely_ due to the fact that we don't require
documentation, data, or firmware to be free. And debian-legal is not a
delegated body, and is unable to make decisions of their own that have
any relevance to Debian -- those decisions are made by the DPL, and the
appointed delegates in charge of handling the archive.

> > At the rate we're currently going, I don't really expect to be able to
> > achieve this this year.
> This means that we continue to deliver woody, which has more or less
> exactly the same defects. 

An argument could well be made that we should drop existing releases
that violate the social contract.

> If you really require a GR to prevent this,
> this could happen - but it costs us a lot of time that I'd rather see
> put into fixing bugs.

I'm not willing to violate the social contract we provide to our
users. I'm happy if there's some other way of reading the new social
contract that doesn't mean we should disregard our users' interests,
but I can't see one, and I don't think that it'd be appropriate for me
to make one up. If there isn't another reading, though, and we're just
going to choose to ignore it in spite of what it clearly requires, well,
that's not something I can support at all.

On Mon, Apr 26, 2004 at 11:46:43AM +0200, Martin Schulze wrote:
> Well, the changes were editorial to our understanding of the social
> contract with regards to freeness of data, especially since this
> was discussed over and over on debian-legal before.
> 
> Speaking of the GFDL, only those documents released under the GNU FDL
> are non-free that make use of invariant sections for anything else
> than its license, right?

I believe various folks have quibbles with other sections of the GFDL too;
such as the inability to place GFDL'ed docs under DMCA-ish "technological
protection measures" (which can variously be interpreted as DVD region
coding or crypto).

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
Don't assume I speak for anyone but myself. GPG signed mail preferred.

Protect Open Source in Australia from over-reaching changes to IP law
http://www.petitiononline.com/auftaip/ & http://www.linux.org.au/fta/

Re: Social Contract GR's Affect on sarge

[Martin Schulze]

Michael Banck wrote:
> On Mon, Apr 26, 2004 at 02:32:34PM +0200, Martin Schulze wrote:
> > Francesco P. Lovergine wrote:
> > > Issue a 'man emacs' for instance
> > 
> > What am I supposed to read there?  Mine doesn't say that it's using
> > the FDL but since its date says it's from 1995 December 7, I doubt
> > it does.
> 
> You're supposed to appreciate that although the Emacs manpage might
> satisfy our requirements for inclusion in main, it is useless in
> practice when compared to the GFDL manual/info page.

Oh.  Since I don't remember reading either of them, I can't judge on
this anyway.

> So even if the glibc functions might be documented in manpages in a
> satisfactory way, this is probably not true for the rest of the GNU
> packages.

Granted.

Regards,

Joey

-- 
The only stupid question is the unasked one.

Re: Social Contract GR's Affect on sarge

[Martin Schulze]

Anthony Towns wrote:
> On Mon, Apr 26, 2004 at 11:23:16AM +0200, Martin Schulze wrote:
> > >   * many pieces of hardware will not be supported by the Debian system
> > > itself
> > Since we already face this "problem" woody already due to new hardware
> > being incompatible with older one, only the number will grow.
> 
> Joey, I realise you think this is the case, but it's not. It has been
> quite possible to separate firmware into userspace, without separating
> it into a separate package, or moving it to non-free.

I have noticed this.

Guess, this time you misunderstood me.

What I was trying to say is that some people already complain that it
is not possible to install woody on some machines, so it is nothing
new to us that some hardware is not supported by the released Debian
system.  Only the number of unsupported hardware will grow.

Regards,

Joey

-- 
The only stupid question is the unasked one.

Please always Cc to me when replying to me on the lists.

Re: Social Contract GR's Affect on sarge

[Raul Miller]

On Mon, Apr 26, 2004 at 02:56:09PM +1000, Anthony Towns wrote:
> So, if the technical committee would like to comment on this issue,
> take the decision out of my hands, or overrule any decision I might
> otherwise make, now would be a good time.

The technical committee can't override the constitution (nor foundation
documents) any more than you can.

However it might be worthwhile introducing a "Sarge Exception", making
an explicit grandfather clause applicable only to sarge, and earlier
distributions, so we can release the it.  This is philosophically ugly,
but then some people (perhaps RMS) think the same of debian as a whole.

The language of that GR might run something like: In the past, we
have had some disagreements between ourselves about what it is we're
trying to do and what should go in a free distribution.  We intend to
fix those issues, going forwards, however to release the version of
the distribution which we were about to release, it's going to have to
include some components which might have been acceptable under our old
social contract but which are definitely not acceptable under the new.
We resolve to distribute the "Sarge Distribution" with packages licensed
as they are currently licensed, even though these license conflict
with the updated social contract.  We'll also be providing in "Sarge"
a document listing at least one such conflict for each of these packages.

As an aside... or as a possibly related issue, consider glibc -- here
is a piece of software which is licensed as free (though RMS might say
that the LGPL licensed components aren't as free as he'd like), but
which in practice is still distributed in almost-binary form (you can't
build current versions of glibc on linux without having extremely current
binaries because the version skew is so great).  In essence, the preferred
form for working with this software must include its binaries... anyways,
I've not thought this all the way through, but parts of glibc are GPL'd
software and there's some possibility that without the sarge exception
we wouldn't be able to distribute glibc (or maybe any of the GPL licensed
parts of the tool chain) in its current form.

If RMS doesn't agree that this is some sort of problem, I'm not sure
what position that leaves us in.  Maybe we need to have an alternative
"can be built and statically linked from source mini libc" explicitly for
bootstrapping when building newer version of debian from older versions of
debian, to avoid this quandry?  [I can imagine this having some value in
other contexts, but even a "mini-libc" can take an awful lot of work to
get right -- not to mention the analogous work it would take to replace
other core stuff available from the FSF which we have problems with.]

-- 
Raul

Re: Social Contract GR's Affect on sarge

[Michael Banck]

On Mon, Apr 26, 2004 at 09:59:53AM -0400, Raul Miller wrote:
> On Mon, Apr 26, 2004 at 02:56:09PM +1000, Anthony Towns wrote:
> > So, if the technical committee would like to comment on this issue,
> > take the decision out of my hands, or overrule any decision I might
> > otherwise make, now would be a good time.
> 
> The technical committee can't override the constitution (nor foundation
> documents) any more than you can.
> 
> However it might be worthwhile introducing a "Sarge Exception", making
> an explicit grandfather clause applicable only to sarge, and earlier
> distributions, so we can release the it.  This is philosophically ugly,
> but then some people (perhaps RMS) think the same of debian as a whole.
> 
> The language of that GR might run something like: In the past, we
> have had some disagreements between ourselves about what it is we're
> trying to do and what should go in a free distribution.  We intend to
> fix those issues, going forwards, however to release the version of
> the distribution which we were about to release, it's going to have to
> include some components which might have been acceptable under our old
> social contract but which are definitely not acceptable under the new.
> We resolve to distribute the "Sarge Distribution" with packages licensed
> as they are currently licensed, even though these license conflict
> with the updated social contract.  We'll also be providing in "Sarge"
> a document listing at least one such conflict for each of these packages.

Well, I'd second this, if it was put forth.

> As an aside... or as a possibly related issue, consider glibc -- here
> is a piece of software which is licensed as free (though RMS might say
> that the LGPL licensed components aren't as free as he'd like), but
> which in practice is still distributed in almost-binary form (you can't
> build current versions of glibc on linux without having extremely current
> binaries because the version skew is so great).  In essence, the preferred
> form for working with this software must include its binaries... anyways,
> I've not thought this all the way through, but parts of glibc are GPL'd
> software and there's some possibility that without the sarge exception
> we wouldn't be able to distribute glibc (or maybe any of the GPL licensed
> parts of the tool chain) in its current form.

Huh??? This procedure is called bootstrapping...

I don't believe this is related to the issue in any way and just dilutes
your (valid, IMHO) point above.


Michael

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html

Re: Social Contract GR's Affect on sarge

[Raul Miller]

On Mon, Apr 26, 2004 at 09:59:53AM -0400, Raul Miller wrote:
> The technical committee can't override the constitution (nor foundation
> documents) any more than you can.

Hmm.. actually, maybe that's not true in this case...

Given that the intent of the most recent GR was "Editorial Changes", and
given that those editorial changes have had technical effects, and given
that the technical committee is empowered to decide on issues of technical
policy, it probably is within the committee's bailiwick to grandfather
the old meaning of the social contract in the context of Sarge.

I think this should be talked throough on the committee list.

-- 
Raul

Re: Social Contract GR's Affect on sarge

[Michael Poole]

Michael Banck writes:

> So even if the glibc functions might be documented in manpages in a
> satisfactory way, this is probably not true for the rest of the GNU
> packages.

I would disagree that even glibc functions are adequately documented
in man pages.  To pick just one example, the mcheck() and mallinfo()
functions are part of the malloc debugging support in glibc.  I cannot
find mention of them in the man pages, but they are described at
length in the info files; I have used them before to try to debug
memory bugs in a program I maintain [1].

To adequately re-document everything that is in upstream documentation
(but in a non-free format) will be an enormous amount of effort,
especially as upstream adds new features.

Michael Poole

[1]- To forestall the suggestion to use valgrind instead, the program
in question uses 500 MB of memory without any debugging overhead, and
has not exhibited the errors on smaller test sets.  32-bit valgrind
exhausts the user memory space before it loads the full data set.

Re: Social Contract GR's Affect on sarge

[Hamish Moffatt]

On Mon, Apr 26, 2004 at 10:07:12AM +0100, Jochen Voss wrote:
> On Mon, Apr 26, 2004 at 02:56:09PM +1000, Anthony Towns wrote:
> > The Social Contract now states:
> > 
> > ] 1. Debian will remain 100% free
> > ] ...
> > 
> > As this is no longer limited to "software", and as this decision was
> > made by developers after and during discussion of how we should consider
> > non-software content such as documentation and firmware, I don't believe
> > I can justify the policy decisions to exempt documentation, firmware,
> > or content any longer, as the Social Contract has been amended to cover
> > all these areas.
> 
> By the way, what was the meaning of "editorial" in
> "Editorial changes to the Social Contract GR"?

Usually it refers to changes that clarify the meaning without changing
that meaning. I'd be interested in hearing your definition, since you
seconded the GR.

I'm stunned that this GR passed. I was surprised when the secretary
called for votes because the proposal wasn't anything close to ready for
voting.

The tally sheet makes interesting reading:
http://www.debian.org/vote/2004/gr_editorial_tally.txt

Draw your own conclusions.

Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Social Contract GR's Affect on sarge

[Andreas Barth]

* Michael Banck ([EMAIL PROTECTED]) [040426 16:25]:
> On Mon, Apr 26, 2004 at 09:59:53AM -0400, Raul Miller wrote:
> > The language of that GR might run something like: [...]
> 
> Well, I'd second this, if it was put forth.

There is actually a draft for such a GR. However, I think it's better
to calm down a bit before proposing the next draft (read: I might
perhaps propose it, but not earlier than 48 hours after the initial
posting of Anthony).


Cheers,
Andi
-- 
   http://home.arcor.de/andreas-barth/
   PGP 1024/89FB5CE5  DC F1 85 6D A6 45 9C 0F  3B BE F1 D0 C5 D1 D9 0C

Re: Social Contract GR's Affect on sarge

[Steve Langasek]

On Mon, Apr 26, 2004 at 11:15:59AM +0200, Andreas Barth wrote:
> > At the rate we're currently going, I don't really expect to be able to
> > achieve this this year.

> This means that we continue to deliver woody, which has more or less
> exactly the same defects. If you really require a GR to prevent this,
> this could happen - but it costs us a lot of time that I'd rather see
> put into fixing bugs.

100% agreed.

Cheers,
-- 
Steve Langasek
postmodern programmer

Re: Social Contract GR's Affect on sarge

[Manoj Srivastava]

On Mon, 26 Apr 2004 22:40:08 +1000, Anthony Towns  
said: 

> On Mon, Apr 26, 2004 at 11:15:59AM +0200, Andreas Barth wrote:

>> Furthermore, the exceptions till now was not due to the fact that
>> we don't require documentation to be free (quite contrary, there
>> was a consensus on d-legal about GFDL not free), but due to the
>> fact that we want to have enough time to come up with a proper
>> solution.

> No, the exception is _entirely_ due to the fact that we don't
> require documentation, data, or firmware to be free. And
> debian-legal is not a delegated body, and is unable to make
> decisions of their own that have any relevance to Debian -- those
> decisions are made by the DPL, and the appointed delegates in charge
> of handling the archive.

I am surprised to hear you say that, since I would personally
 have thought that was against the spirit of the social contract.

manoj
-- 
A man would still do something out of sheer perversity - he would
create destruction and chaos - just to gain his point... and if all
this could in turn be analyzed and prevented by predicting that it
would occur, then man would deliberately go mad to prove his
point. Feodor Dostoevsky, "Notes From the Underground"
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Social Contract GR's Affect on sarge

[Manoj Srivastava]

On Tue, 27 Apr 2004 00:31:15 +1000, Hamish Moffatt <[EMAIL PROTECTED]> said: 

> On Mon, Apr 26, 2004 at 10:07:12AM +0100, Jochen Voss wrote:
>> On Mon, Apr 26, 2004 at 02:56:09PM +1000, Anthony Towns wrote:
>> > The Social Contract now states:
>> >
>> > ] 1. Debian will remain 100% free ] ...
>> >
>> > As this is no longer limited to "software", and as this decision
>> > was made by developers after and during discussion of how we
>> > should consider non-software content such as documentation and
>> > firmware, I don't believe I can justify the policy decisions to
>> > exempt documentation, firmware, or content any longer, as the
>> > Social Contract has been amended to cover all these areas.
>>
>> By the way, what was the meaning of "editorial" in "Editorial
>> changes to the Social Contract GR"?

> Usually it refers to changes that clarify the meaning without
> changing that meaning. I'd be interested in hearing your definition,
> since you seconded the GR.

> I'm stunned that this GR passed. I was surprised when the secretary
> called for votes because the proposal wasn't anything close to ready
> for voting

Then you need to read the constitution, you obviously do noty
 know how Debian works. Once a proposal has gathered the requisite
 number of seconds, the secretary has limited wiggle room in calling
 the vote;  A2.1. I had already put off Andrew once, pleasding
 technical issues, after he had called for a vote; I could notr, in
 good conscience, keep on postponing a properly proposed GR.

> The tally sheet makes interesting reading:
> http://www.debian.org/vote/2004/gr_editorial_tally.txt

> Draw your own conclusions.

I have no idea what you may be insinuating here, but let me
 point out that a better than 4:1 majority agreed with the proposal.

manoj
-- 
HR Manager to job candidate "I see you've had no computer
training. Although that qualifies you for upper management, it means
you're under-qualified for our entry level positions."
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Social Contract GR's Affect on sarge

[Manoj Srivastava]

On Mon, 26 Apr 2004 09:59:53 -0400, Raul Miller <[EMAIL PROTECTED]> said: 

> On Mon, Apr 26, 2004 at 02:56:09PM +1000, Anthony Towns wrote:
>> So, if the technical committee would like to comment on this issue,
>> take the decision out of my hands, or overrule any decision I might
>> otherwise make, now would be a good time.

> The technical committee can't override the constitution (nor
> foundation documents) any more than you can.

Correct.

> However it might be worthwhile introducing a "Sarge Exception",
> making an explicit grandfather clause applicable only to sarge, and
> earlier distributions, so we can release the it.  This is
> philosophically ugly, but then some people (perhaps RMS) think the
> same of debian as a whole.

That would be doable.

manoj
-- 
In like a dimwit, out like a light. Pogo
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Social Contract GR's Affect on sarge

[Manoj Srivastava]

On Mon, 26 Apr 2004 10:16:09 -0400, Raul Miller <[EMAIL PROTECTED]> said: 

> On Mon, Apr 26, 2004 at 09:59:53AM -0400, Raul Miller wrote:
>> The technical committee can't override the constitution (nor
>> foundation documents) any more than you can.

> Hmm.. actually, maybe that's not true in this case...

> Given that the intent of the most recent GR was "Editorial Changes",
> and given that those editorial changes have had technical effects,

I beg to differ. What technical changes? A release policy
 change of this nature is certainly onn technical in nature.

> and given that the technical committee is empowered to decide on
> issues of technical policy, it probably is within the committee's
> bailiwick to grandfather the old meaning of the social contract in
> the context of Sarge.

I would strongly disagree. The developers can certainly pass
 another GR, but the tech ctte should not override the wishes of the
 develoeprs when this is not a technical issue at hand.

> I think this should be talked throough on the committee list.

Let me put it this way: it is a technical issue if you would
 file a BTS bug to resolve the issue, and, usually, if it is related
 to code, or other package components. We also generally do not resort
 to GR's for technical issues; the fact that you first thought of a GR
 to solve this should give you a hint that this is not a technical
 issue. 

Deciding when to release, and what can be released, does not
 fall in that domain.

Expanding the powers of the tech-ctte for convenience, or the
 belief that the developers did not know what they were doing, or to
 take a short cut to a GR, is not acceptable.

manoj
-- 
"The subspace _W inherits the other 8 properties of _V. And there
aren't even any property taxes." MacKay, Mathematics 134b
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Social Contract GR's Affect on sarge

[Theodore Ts'o]

On Mon, Apr 26, 2004 at 02:56:09PM +1000, Anthony Towns wrote:
> As this is no longer limited to "software", and as this decision was
> made by developers after and during discussion of how we should consider
> non-software content such as documentation and firmware, I don't believe
> I can justify the policy decisions to exempt documentation, firmware,
> or content any longer, as the Social Contract has been amended to cover
> all these areas.
> 
> As such, I can see no way to release sarge without having all these
> things removed from the Debian system -- ie main.
> 
> This will result in the following problems:
>
> ...

You forgot one other thing.  We'll also have to strip **ALL**
**FONTS** from Debian, since fonts come in binary form, and we don't
have anything approaching the "preferred form for modification" for
fonts.  In particular, the Truetype Bitstream Vera fonts which were so
generously donated by Vera was generated not only using propietary
source files, but also using propietary non-free programs.  

>   * debian-installer will need to be rewritten to support obtaining
> non-free firmware but not other non-free packages

The debian installer will also need to be rewritten to support
obtaining fonts from non-free sources as well, and we will need to
move xfonts-100dpi, xfonts-75dpi, xfonts-base, xfonts-scalable, to
non-free.

What Fun.

- Ted

Re: Social Contract GR's Affect on sarge

[Anthony Towns]

On Mon, Apr 26, 2004 at 10:29:51AM -0500, Manoj Srivastava wrote:
> > No, the exception is _entirely_ due to the fact that we don't
> > require documentation, data, or firmware to be free. And
> > debian-legal is not a delegated body, and is unable to make
> > decisions of their own that have any relevance to Debian -- those
> > decisions are made by the DPL, and the appointed delegates in charge
> > of handling the archive.
>   I am surprised to hear you say that, since I would personally
>  have thought that was against the spirit of the social contract.

I'm sorry, you're mistaken. It was against Andrew's interpretation of the
social contract. It wasn't against mine, nor to the best of my knowledge
the interpretation of anyone else responsible in that area. I'm sorry if
you feel reasonable people can't hold such opinions.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
Don't assume I speak for anyone but myself. GPG signed mail preferred.

Protect Open Source in Australia from over-reaching changes to IP law
http://www.petitiononline.com/auftaip/ & http://www.linux.org.au/fta/


signature.asc
Description: Digital signature

Re: Social Contract GR's Affect on sarge

[Anthony Towns]

On Mon, Apr 26, 2004 at 10:43:47AM -0500, Manoj Srivastava wrote:
>   I would strongly disagree. The developers can certainly pass
>  another GR, but the tech ctte should not override the wishes of the
>  develoeprs when this is not a technical issue at hand.

The technical committee is empowered to make a decision when asked,
see 6.1(3).

Dear technical ctte, if you are able to come to a conclusion on this
topic, please make a decision as to whether the social contract requires
non-free documentation, firmware, etc to be removed from main before
release.

You've thus been asked, and thus been empowered to consider the issue as
you see fit. 

If individuals on the technical ctte do not wish to take part in such
a discussion, or do not wish to make a decision, or wish to defer to my
previously mentioned decision, or whatever else, that's fine, naturally.
I don't see much point in arguing about procedural technicalities though.

Cheers,
aj

-- 
Anthony Towns <[EMAIL PROTECTED]> 
Don't assume I speak for anyone but myself. GPG signed mail preferred.

Protect Open Source in Australia from over-reaching changes to IP law
http://www.petitiononline.com/auftaip/ & http://www.linux.org.au/fta/


signature.asc
Description: Digital signature

Re: Social Contract GR's Affect on sarge

[Raul Miller]

On Mon, Apr 26, 2004 at 10:43:47AM -0500, Manoj Srivastava wrote:
>   Expanding the powers of the tech-ctte for convenience, or the
>  belief that the developers did not know what they were doing, or to
>  take a short cut to a GR, is not acceptable.

Ok, thanks.

I hadn't thought through the implications very far on that one.

[I've a few minor quibbles between what I was thinking and what you said,
but arguing those quibbles wouldn't get us anywhere.]

-- 
Raul

Re: Social Contract GR's Affect on sarge

[Colin Watson]

On Mon, Apr 26, 2004 at 02:56:09PM +1000, Anthony Towns wrote:
> On Sun, Apr 25, 2004 at 07:28:11PM -0500, Debian Project Secretary wrote:
> >At this point, with 244 ballots resulting in 216 votes from
> >  214 developers, "Choice 1: Change the Social Contract [3:1 majority
> >  needed]" has carried the day., with a 4.462:1 majority, well over the
> >  3:1 needed.
> 
> The Social Contract now states:
> 
> ] 1. Debian will remain 100% free
> ] 
> ] We provide the guidelines that we use to determine if a work is "free"
> ] in the document entitled "The Debian Free Software Guidelines". We
> ] promise that the Debian system and all its components will be free
> ] according to these guidelines. We will support people who create or
> ] use both free and non-free works on Debian. We will never make the
> ] system require the use of a non-free component.
> 
> As this is no longer limited to "software", and as this decision was
> made by developers after and during discussion of how we should consider
> non-software content such as documentation and firmware, I don't believe
> I can justify the policy decisions to exempt documentation, firmware,
> or content any longer, as the Social Contract has been amended to cover
> all these areas.
> 
> As such, I can see no way to release sarge without having all these
> things removed from the Debian system -- ie main.

I'm just following up to note that [EMAIL PROTECTED] does not
forward to the technical committee (and apparently you won't get a
bounce ...). debian-ctte@lists.debian.org is the correct address, so
replies intended for them should go there.

-- 
Colin Watson  [EMAIL PROTECTED]

Re: Social Contract GR's Affect on sarge

[Raul Miller]

On Mon, Apr 26, 2004 at 05:27:14PM +0100, Colin Watson wrote:
> I'm just following up to note that [EMAIL PROTECTED] does not
> forward to the technical committee (and apparently you won't get a
> bounce ...).

Hmm... this feature might be a contributing factor on some of the
complaints that the committee is not very responsive.

-- 
Raul

Re: Social Contract GR's Affect on sarge

[Raul Miller]

> > As an aside... or as a possibly related issue, consider glibc -- here
> > is a piece of software which is licensed as free (though RMS might say
> > that the LGPL licensed components aren't as free as he'd like), but
> > which in practice is still distributed in almost-binary form (you can't
> > build current versions of glibc on linux without having extremely current
> > binaries because the version skew is so great).  In essence, the preferred
> > form for working with this software must include its binaries...

On Mon, Apr 26, 2004 at 04:08:54PM +0200, Michael Banck wrote:
> Huh??? This procedure is called bootstrapping...

Yes.  So?

If you can't build the sarge glibc from woody without first installing
binaries from sarge the bootstrapping procedure has turned glibc into
something that requires binaries -- there's some part of it which isn't
available in the sources.

> I don't believe this is related to the issue in any way and just dilutes
> your (valid, IMHO) point above.

It relates to the freeness of glibc.

More specifically, if glibc requires a binary component (a current
version of the glibc binaries) for its source to be built, then glibc
isn't distributable under the GPL.  Since the FSF distributes glibc
they're not likely to prosecute, which means this is less of a legal
issue and more of a DFSG issue.

-- 
Raul

Re: Social Contract GR's Affect on sarge

[Stephen Frost]

* Theodore Ts'o ([EMAIL PROTECTED]) wrote:
> You forgot one other thing.  We'll also have to strip **ALL**
> **FONTS** from Debian, since fonts come in binary form, and we don't
> have anything approaching the "preferred form for modification" for
> fonts.  In particular, the Truetype Bitstream Vera fonts which were so
> generously donated by Vera was generated not only using propietary
> source files, but also using propietary non-free programs.  

Well, now, I'm not entirely convinced of this.  Could a similar argument
not be used on JPEG's or PNG's?  Do we have *some* reasonable way to
modify these fonts?  It's been a long time, but I did hack on some fonts
a long time ago and while it wasn't the most fun thing I could have
sworn there was a free program available to do it..

Stephen


signature.asc
Description: Digital signature

Re: Social Contract GR's Affect on sarge

[Manoj Srivastava]

On Mon, 26 Apr 2004 11:23:51 -0400, Theodore Ts'o <[EMAIL PROTECTED]> said: 

> You forgot one other thing.  We'll also have to strip **ALL**
> **FONTS** from Debian, since fonts come in binary form, and we don't
> have anything approaching the "preferred form for modification" for
> fonts.  In particular, the Truetype Bitstream Vera fonts which were
> so generously donated by Vera was generated not only using
> propietary source files, but also using propietary non-free
> programs.

Are you sure about that? The 100dpi, 75dpi (and other
 bitmapped fonts) do seem to come with the sources (indeed, I am given
 to undertand that when the uTF-8 extentions were added by Markus
 Kuhn, only free software was used).

manoj
-- 
Just remember: when you go to court, you are trusting your fate to
twelve people that weren't smart enough to get out of jury duty!
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Social Contract GR's Affect on sarge

[Manoj Srivastava]

On Tue, 27 Apr 2004 01:49:12 +1000, Anthony Towns  
said: 

> On Mon, Apr 26, 2004 at 10:29:51AM -0500, Manoj Srivastava wrote:
>> > No, the exception is _entirely_ due to the fact that we don't
>> > require documentation, data, or firmware to be free. And
>> > debian-legal is not a delegated body, and is unable to make
>> > decisions of their own that have any relevance to Debian -- those
>> > decisions are made by the DPL, and the appointed delegates in
>> > charge of handling the archive.
>> I am surprised to hear you say that, since I would personally have
>> thought that was against the spirit of the social contract.

> I'm sorry, you're mistaken. It was against Andrew's interpretation
> of the social contract. It wasn't against mine, nor to the best of

It certainly was against what I took the social contract to
 be. I never imagined that Debian was about only part of main being
 free, indeed, as Bruce has stated, I, too, was under the impression
 that the  SC and the DFSG applied to everything on the Debian CD.

> my knowledge the interpretation of anyone else responsible in that
> area.

I hasve no idea who you think are people responsible in those
 areas. 

> I'm sorry if you feel reasonable people can't hold such
> opinions.

Don't put words in my mouth; I said I was surprised, not that
 you can't hold whatever surprising opinions you may.

manoj
 ps: my sig generator is eerily on topic
-- 
Knowledge, sir, should be free to all! Harry Mudd, "I, Mudd", stardate
4513.3
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Social Contract GR's Affect on sarge

[Michael Banck]

On Mon, Apr 26, 2004 at 12:47:58PM -0400, Raul Miller wrote:
> More specifically, if glibc requires a binary component (a current
> version of the glibc binaries) for its source to be built, then glibc
> isn't distributable under the GPL.

I've heard that there are a couple of hundred other packages which need
a current version of libc binaries to build. They are called 'C
programs'. We've even invented stuff like Build-Depends for them.

Stop the presses! File RC bugs!


Michael

(Incidently, I've built glibc_2.3.2ds1-12 packages on hurd-i386
yesterday. The current version of glibc on hurd-i386 is 2.3.1-5 which is
not so recent alltogether. Further, the glibc package does not even have
a versioned Build-Depends on libc6-dev)

-- 
Michael Banck
Debian Developer
[EMAIL PROTECTED]
http://www.advogato.org/person/mbanck/diary.html

Re: Social Contract GR's Affect on sarge

[Raul Miller]

On Mon, Apr 26, 2004 at 12:54:14PM -0400, Stephen Frost wrote:
> It's been a long time, but I did hack on some fonts
> a long time ago and while it wasn't the most fun thing I could have
> sworn there was a free program available to do it..

Fonts are something of a black art.  [Notice all the disclaimers about
fonts at www.unicode.org?]

Anwyays, sample font editors include cfe, fonter, pfaedit, xmbdfed, and
unpackaged stuff like http://hea-www.harvard.edu/~fine/Tech/bdfedit.html

-- 
Raul

Re: Social Contract GR's Affect on sarge

[Theodore Ts'o]

On Mon, Apr 26, 2004 at 12:54:14PM -0400, Stephen Frost wrote:
> * Theodore Ts'o ([EMAIL PROTECTED]) wrote:
> > You forgot one other thing.  We'll also have to strip **ALL**
> > **FONTS** from Debian, since fonts come in binary form, and we don't
> > have anything approaching the "preferred form for modification" for
> > fonts.  In particular, the Truetype Bitstream Vera fonts which were so
> > generously donated by Vera was generated not only using propietary
> > source files, but also using propietary non-free programs.  
> 
> Well, now, I'm not entirely convinced of this.  Could a similar argument
> not be used on JPEG's or PNG's?  Do we have *some* reasonable way to
> modify these fonts?  It's been a long time, but I did hack on some fonts
> a long time ago and while it wasn't the most fun thing I could have
> sworn there was a free program available to do it..

Ah, but I could hack around firmware using a hex editor as well.  The
question is whether or not a compressed PCF or truetype font file is
the "preferred form for modification" --- i.e., source.  If the
requirement is that "source" is available for all files shipped in
main, I don't see how we can include any of our fonts in the Debian
distribution.

- Ted

P.S.  For non-x86 kernels, the kernel includes fonts for console
support.  So despite removing the firmware from the kernel, at least
for non-x86 kernels, we will probably need to move the kernel into
non-free as well.

Yay, rah.

Re: Social Contract GR's Affect on sarge

[Raul Miller]

On Mon, Apr 26, 2004 at 12:47:58PM -0400, Raul Miller wrote:
> > More specifically, if glibc requires a binary component (a current
> > version of the glibc binaries) for its source to be built, then glibc
> > isn't distributable under the GPL.

On Mon, Apr 26, 2004 at 07:16:23PM +0200, Michael Banck wrote:
> I've heard that there are a couple of hundred other packages which need
> a current version of libc binaries to build. They are called 'C
> programs'. We've even invented stuff like Build-Depends for them.

As long as glibc itself is free that won't be a problem.

If glibc is not free, we have a much, much larger problem.

-- 
Raul

Re: Social Contract GR's Affect on sarge

[Stephen Frost]

* Theodore Ts'o ([EMAIL PROTECTED]) wrote:
> On Mon, Apr 26, 2004 at 12:54:14PM -0400, Stephen Frost wrote:
> > Well, now, I'm not entirely convinced of this.  Could a similar argument
> > not be used on JPEG's or PNG's?  Do we have *some* reasonable way to
> > modify these fonts?  It's been a long time, but I did hack on some fonts
> > a long time ago and while it wasn't the most fun thing I could have
> > sworn there was a free program available to do it..
> 
> Ah, but I could hack around firmware using a hex editor as well.  The
> question is whether or not a compressed PCF or truetype font file is
> the "preferred form for modification" --- i.e., source.  If the
> requirement is that "source" is available for all files shipped in
> main, I don't see how we can include any of our fonts in the Debian
> distribution.

That's what I'm contending.  For compressed PCF or truetype fonts I'd be
more inclined to say that's the 'preferred form for modification'.  I'm
less inclined to say the same about firmware and a hex editor though not
entirely opposed to it either.  Especially if the firmware is just
assembled assembly for a specific processor that could be disassembled.
I'm not very familiar with firmware though, is virtually all firmware
compiled C code or is alot of it assembly or what?

Stephen


signature.asc
Description: Digital signature

Re: Social Contract GR's Affect on sarge

[Steve Greenland]

On 26-Apr-04, 09:31 (CDT), Hamish Moffatt <[EMAIL PROTECTED]> wrote: 
> 
> The tally sheet makes interesting reading:
> http://www.debian.org/vote/2004/gr_editorial_tally.txt
> 
> Draw your own conclusions.

Sorry, you're going to have to spell out what you mean. The only
conclusion I can draw from it is that quite few more people voted for
the change than against it.

-- 
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world.   -- seen on the net

Re: Social Contract GR's Affect on sarge

[Glenn Maynard]

Removed Theodore Ts'o from the CC list, since he didn't ask to be CC'd.

On Mon, Apr 26, 2004 at 12:54:14PM -0400, Stephen Frost wrote:
> Well, now, I'm not entirely convinced of this.  Could a similar argument
> not be used on JPEG's or PNG's?  Do we have *some* reasonable way to

A similar argument has been made.  This is why I'm tending to think
it's unreasonable to expect source for everything.  I do think every
*other* requirement (except for DFSG#2) applies to other data.

I think that firmware is no different than any other program, and should
require source, but I'm not so sure about other types of software (such
as PNGs and fonts).

Some have argued that DFSG#2 doesn't apply to PNGs, etc. because it uses
the word "program".  I don't think the language is quite that clear.  If
there's disagreement on this, changing DFSG#2 from "The program ..." to
"Programs ..." might help.

I would tend to think that there's no need to define that further--"program"
seems to obviously include /bin/ls and firmware blobs, and exclude 
documentation,
fonts[1] and images--but the RM is apparently claiming that the old SC didn't
apply to firmware, as if firmware isn't software (a very strange claim, IMO).

Of course, this wouldn't change the need to remove non-free firmware or
GFDL'd documentation.

[1] Oops.  Hinted fonts have programs in them.  I'm not even sure where to
start on that.

-- 
Glenn Maynard

Re: Social Contract GR's Affect on sarge

[Florian Weimer]

Theodore Ts'o <[EMAIL PROTECTED]> writes:

> You forgot one other thing.  We'll also have to strip **ALL**
> **FONTS** from Debian,

Not all of them, we have quite a few METAFONT programs.

> The debian installer will also need to be rewritten to support
> obtaining fonts from non-free sources as well, and we will need to
> move xfonts-100dpi, xfonts-75dpi, xfonts-base, xfonts-scalable, to
> non-free.

Hand-tuned bitmap fonts are fine because the bitmaps are the preferred
form of modification.  Vector fonts are a different story, and so a
pre-rendered bitmap fonts.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, di-ve.com, netscape.net,
postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr.

Re: Social Contract GR's Affect on sarge

[Florian Weimer]

Stephen Frost <[EMAIL PROTECTED]> writes:

> Well, now, I'm not entirely convinced of this.  Could a similar argument
> not be used on JPEG's or PNG's?

For JPEGs?  Sure, the argument applies to any lossy compression
format.

In the case of PNG, it depends on the image contents.

> Do we have *some* reasonable way to modify these fonts?  It's been a
> long time, but I did hack on some fonts a long time ago and while it
> wasn't the most fun thing I could have sworn there was a free
> program available to do it..

It depends on the font format.  For METAFONT, you can use VIM or
Emacs, for bitmap fonts you can use some other editor.  But I doubt
that there is anything that supports Type 1 or Truetype fonts,
including hinting and kerning.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, di-ve.com, netscape.net,
postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr.

Re: Social Contract GR's Affect on sarge

[Florian Weimer]

Glenn Maynard <[EMAIL PROTECTED]> writes:

> A similar argument has been made.  This is why I'm tending to think
> it's unreasonable to expect source for everything.  I do think every
> *other* requirement (except for DFSG#2) applies to other data.

I've raised this argument as a reduction ad absurdum quite a number of
times.  It hasn't changed much, and quite frankly, I didn't see the
connection to these "editorial changes".

> I think that firmware is no different than any other program, and should
> require source, but I'm not so sure about other types of software (such
> as PNGs and fonts).

Fonts are firmware.  They are little programs to be loaded into the
printer (especially true of Type 3 fonts 8-).

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, di-ve.com, netscape.net,
postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr.

Re: Social Contract GR's Affect on sarge

[Thomas Bushnell, BSG]

"Theodore Ts'o" <[EMAIL PROTECTED]> writes:

> You forgot one other thing.  We'll also have to strip **ALL**
> **FONTS** from Debian, since fonts come in binary form, and we don't
> have anything approaching the "preferred form for modification" for
> fonts.  

Where are you quoted the words "preferred form for modification" from?
I can't find them anywhere in the Social Contract or the DFSG.

Thomas

Re: Social Contract GR's Affect on sarge

[Florian Weimer]

[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:

> "Theodore Ts'o" <[EMAIL PROTECTED]> writes:
>
>> You forgot one other thing.  We'll also have to strip **ALL**
>> **FONTS** from Debian, since fonts come in binary form, and we don't
>> have anything approaching the "preferred form for modification" for
>> fonts.  
>
> Where are you quoted the words "preferred form for modification" from?

GPL

> I can't find them anywhere in the Social Contract or the DFSG.

It's the definition of "source code" that makes the most sense.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, di-ve.com, netscape.net,
postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr.

Re: Social Contract GR's Affect on sarge

[Thomas Bushnell, BSG]

Florian Weimer <[EMAIL PROTECTED]> writes:

> > Where are you quoted the words "preferred form for modification" from?
> 
> GPL

Of course, but that only applies to GPL'd documents.  It is certainly
true that a bitmap font (unless it was created *as* a bitmap font
originally) can't be part of a GPL'd program.

But that isn't the issue here.

> > I can't find them anywhere in the Social Contract or the DFSG.
> 
> It's the definition of "source code" that makes the most sense.

We are not under an obligation to have a rigid definition of "source
code".

The GPL, because it is a license, must try to have a single and
unavoidable definition.  It therefore should err on the side of being
more restrictive in its definition of "source code", to make it harder
for people to get around its provisions.

But the DFSG, because it is not a license, need not worry about such
things.  We can say "source code", and then do what seems best to us
in each particular case.  We have no obligation to have one single
definition of the term that is rigidly applied to every situation.

So is Ted saying "this ought to be our definition of source code" (in
which case, it isn't now)?  Or is he saying "this is our definition,
and we should apply it" (but then where do we adopt it)?

Re: Social Contract GR's Affect on sarge

[Florian Weimer]

[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:

>> It's the definition of "source code" that makes the most sense.
>
> We are not under an obligation to have a rigid definition of "source
> code".

Yes, this is one of our advantages (IMHO).

> But the DFSG, because it is not a license, need not worry about such
> things.  We can say "source code", and then do what seems best to us
> in each particular case.  We have no obligation to have one single
> definition of the term that is rigidly applied to every situation.

Recently, there were some calls for such definitions, and lack of
clear definitions was often put forward as an argument to stamp some
practices as impractical.  For example, treating Data and Programs
differently.

I don't think that clear rules are necessary (mainly because our
decisions are political and of no legal relevance), and mere
guidelines are sufficient.  However, the current mess makes me wonder
if this is the correct approach.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, di-ve.com, netscape.net,
postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr.

Re: Social Contract GR's Affect on sarge

[Florian Weimer]

[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:

> I don't see a mess.  Ted Ts'o tried to apply an inappropriate standard
> to the question of fonts, and got an absurd result.  I think it was
> just a simple mistake.  Ted's a really smart guy, and I think he just
> automatically substituted the GPL's definition of "source code",
> without realizing or even noticing that the DFSG does not have that
> definition.
>
> Once one realizes that, the problem evaporates (and with it, the
> "current mess").

Why do you think so?  I'd still like to have some hinted non-METAFONT
DFSG-compliant fonts.  And I view the lack thereof an actual problem
which has bothered me for a long time.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, di-ve.com, netscape.net,
postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr.

Re: Social Contract GR's Affect on sarge

[Thomas Bushnell, BSG]

Florian Weimer <[EMAIL PROTECTED]> writes:

> Recently, there were some calls for such definitions, and lack of
> clear definitions was often put forward as an argument to stamp some
> practices as impractical.  For example, treating Data and Programs
> differently.

We decided clearly that data and programs were both subject to the
DFSG.  We did not decide that every term in the DFSG has a single
rigid interpretation.

> I don't think that clear rules are necessary (mainly because our
> decisions are political and of no legal relevance), and mere
> guidelines are sufficient.  However, the current mess makes me wonder
> if this is the correct approach.

I don't see a mess.  Ted Ts'o tried to apply an inappropriate standard
to the question of fonts, and got an absurd result.  I think it was
just a simple mistake.  Ted's a really smart guy, and I think he just
automatically substituted the GPL's definition of "source code",
without realizing or even noticing that the DFSG does not have that
definition.

Once one realizes that, the problem evaporates (and with it, the
"current mess").

Re: Social Contract GR's Affect on sarge

[Thomas Bushnell, BSG]

Florian Weimer <[EMAIL PROTECTED]> writes:

> > Once one realizes that, the problem evaporates (and with it, the
> > "current mess").
> 
> Why do you think so?  I'd still like to have some hinted non-METAFONT
> DFSG-compliant fonts.  And I view the lack thereof an actual problem
> which has bothered me for a long time.

I'm sorry, what's the mess, exactly?  The mess so far described on the
mailing list arose from an attempt to apply the GPL's definition to
fonts in Debian.

So I guess really, if there's a mess, can you explain it to me?

The DFSG says "The program must include source code."  So for works
which are programs, we know how to apply that.

The new Social Contract makes clear that this is to apply to
non-programs also.  But how, since "source code" is a term that
normally refers only to programs?  Well, one way would be to take the
GPL's definition of "source code".  But we need not do that, and there
are compelling reasons not to.

We should look to the reasons for insisting on source code.  One of
those is to preserve the ability of users to modify the program.
Usefully modifying machine binary code for a computer program, except
in the most trivial of cases, is impossible.

So for a program, the requirement to include source code is there to
make it possible to modify the program usefully.  Without that, one
would be stuck.

For a font, this is not quite true.  Many fonts in Debian are the
output of little languages or the equivalent.  So we have no problem
with the METAFONT-generated fonts.  IIUC, there is similarly no
problem with Truetype fonts.

There are many fonts which are created as bitmaps.  For them, there is
no problem also.

There may be a problem for fonts which were created by METAFONT or the
like, but which are distributed only as bitmaps.  Such cases need to
be addressed case by case, and there may be some hard cases where it
is not clear exactly what to do.  But we need not use exactly the same
definitions we do for source code, because we should always remember
that digital font designers have historically been quite happy to
modify the output of such programs by tinkering with pixels--that is,
the assumption that one *cannot* modify binaries is true for programs,
but not true for fonts.  And, as a result, our judgments about what
constitutes adequate source can vary.

But maybe they need not vary; all I'm saying is that we can look at
the cases and discuss them.  The appropriate forum for that is, of
course, debian-legal.

Thomas

Re: Social Contract GR's Affect on sarge

[Raul Miller]

On Mon, Apr 26, 2004 at 02:35:17PM -0700, Thomas Bushnell, BSG wrote:
> Florian Weimer <[EMAIL PROTECTED]> writes:
> 
> > > Where are you quoted the words "preferred form for modification" from?
> > 
> > GPL
> 
> Of course, but that only applies to GPL'd documents. 

The current context is "what is the definition of the phrase 'source
code'?" -- and we take definitions wherever we find them.

You might be thinking about copyright terms, but that's not the issue
here.

> > > I can't find them anywhere in the Social Contract or the DFSG.
> > 
> > It's the definition of "source code" that makes the most sense.
> 
> We are not under an obligation to have a rigid definition of "source
> code".
>
> The GPL, because it is a license, must try to have a single and
> unavoidable definition.  It therefore should err on the side of being
> more restrictive in its definition of "source code", to make it harder
> for people to get around its provisions.
> 
> But the DFSG, because it is not a license, need not worry about such
> things.  We can say "source code", and then do what seems best to us
> in each particular case.  We have no obligation to have one single
> definition of the term that is rigidly applied to every situation.

So, what definition are you suggesting is more relevant here?

As an aside, here's some alternate definitions:

http://www.google.com/search?q=define:source+code

I don't see any which seem better in this context.

-- 
Raul

Re: Social Contract GR's Affect on sarge

[Florian Weimer]

Raul Miller <[EMAIL PROTECTED]> writes:

> So, what definition are you suggesting is more relevant here?

"MU"

The alternative is no definition at all, and decide on a case-by-case
basis.  I don't think that this will work in practice, partiallly
because debian-legal has no ultimate say on this issue and those
Debian institutions that have are not particularly well-known for
their transparency.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, di-ve.com, netscape.net,
postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr.

Re: Social Contract GR's Affect on sarge

[Raul Miller]

On Mon, Apr 26, 2004 at 03:21:25PM -0700, Thomas Bushnell, BSG wrote:
> The DFSG says "The program must include source code."  So for works
> which are programs, we know how to apply that.
> 
> The new Social Contract makes clear that this is to apply to
> non-programs also.  But how, since "source code" is a term that
> normally refers only to programs?  Well, one way would be to take the
> GPL's definition of "source code".  But we need not do that, and there
> are compelling reasons not to.

Oh?

If we take "program" to mean "a sequence of instructions that a computer
can interpret and execute", then it's reasonable to consider a font file
as instructions on how to render characters in that font.

I think you could argue that a font file is not a program expressed in
a turing-complete langauge, but that hardly seems a relevant issue here.

Perhaps you had some other definition in mind for "program"?  If so,
which one?

[It's not sufficient to merely declare that some definition is inadequate
-- you must also supply a better definition.]

Thanks,

-- 
Raul

Re: Social Contract GR's Affect on sarge

[Isaac Jones]

Raul Miller <[EMAIL PROTECTED]> writes:

> The language of that GR might run something like: In the past, we
> have had some disagreements between ourselves about what it is we're
> trying to do and what should go in a free distribution.  We intend to
> fix those issues, going forwards, however to release the version of
> the distribution which we were about to release, it's going to have to
> include some components which might have been acceptable under our old
> social contract but which are definitely not acceptable under the new.
> We resolve to distribute the "Sarge Distribution" with packages licensed
> as they are currently licensed, even though these license conflict
> with the updated social contract.  We'll also be providing in "Sarge"
> a document listing at least one such conflict for each of these packages.

FWIW (as someone who voted 1), I agree with this interpretation of the
vote, as well as similar comments posted in this thread.

I considered it a commitment to refocus our efforts into making a more
free system.  I don't think that it has to be an immediate refocus, or
subordinate to the focus on this release.

Now, I'm pretty new to Debian, but in trying to decide how to vote, I
browsed through the thread using the web archives (didn't find
anything too interesting, though it's hard to separate the wheat from
the chaff), and read the text of the proposal side-by-side with the
current text.  I was in a bit of a hurry (as I was heading out of the
country), and a bit new at this, but I thought I was doing my best
there.

If it does indeed "force" us to delay the release, then I was mistaken
in my understanding of its short-term impact.  I surely would have
voted for an option "change the contract, but delay implementation
until after the next release", since that would have illuminated the
issue.  If I were aware of Anthony's objections, I would have voted 2.

If it takes another GR or an action of the technical committee to
clarify the intent of the voters so be it.  I think we should move
ahead with a release.


peace,

isaac

Re: Social Contract GR's Affect on sarge

[Raul Miller]

On Mon, Apr 26, 2004 at 03:21:25PM -0700, Thomas Bushnell, BSG wrote:
> For a font, this is not quite true.  Many fonts in Debian are the
> output of little languages or the equivalent.  So we have no problem
> with the METAFONT-generated fonts.  IIUC, there is similarly no
> problem with Truetype fonts.

P.S. in this case the source code for the program obviously includes the
source code to that little language, if we want the font to be 100% free.
If you have some other interpretation, please be more specific.

P.P.S.  I find it extremely ironic that one of the more vocal supporters
for the "get rid of non-free" meme is now arguing [rather vehemently]
against a somewhat milder implementation of that meme than was originally
proposed.

-- 
Raul

Re: Social Contract GR's Affect on sarge

[Raul Miller]

On Tue, Apr 27, 2004 at 12:51:22AM +0200, Florian Weimer wrote:
> Raul Miller <[EMAIL PROTECTED]> writes:
> 
> > So, what definition are you suggesting is more relevant here?
> 
> "MU"
> 
> The alternative is no definition at all, and decide on a case-by-case
> basis.  I don't think that this will work in practice, partiallly
> because debian-legal has no ultimate say on this issue and those
> Debian institutions that have are not particularly well-known for
> their transparency.

I disagree: "decide on a case-by-case basis" is not "no definition at
all", instead it is "each case has its own definition", and that still
leads to the question of "what is the definition in this case?"

"MU" would be "there is no decision".

-- 
Raul

Re: Social Contract GR's Affect on sarge

[Raul Miller]

> Raul Miller <[EMAIL PROTECTED]> writes:
> > The current context is "what is the definition of the phrase 'source
> > code'?" -- and we take definitions wherever we find them.

On Mon, Apr 26, 2004 at 04:18:35PM -0700, Thomas Bushnell, BSG wrote:
> Sure, but we shouldn't assume that any particular definition is the
> one we should use just because someone says so.  We should look at the
> consequences of such a decision.
> 
> Indeed, we already have a process: we work things out, case by case,
> relying on the good sense of people involved, and the general
> consensus of the folks on debian-legal.

All of which is completely irrelevant to the question of "what
definition(s) are we using for 'source code'".

We use words to communicate.

We do not, after the fact, try and decide what the words meant that we
used to communicate.

If we had to wait for debian-legal to propose what definitions would be
used in comprehending the language of the social contract before we could
discuss an issue it would be utterly impossible for us to understand
each other.

But maybe you think that would be a good thing?

-- 
Raul

Re: Social Contract GR's Affect on sarge

[Raul Miller]

On Mon, Apr 26, 2004 at 04:20:59PM -0700, Thomas Bushnell, BSG wrote:
> Which case are we speaking of, exactly?

Pick one.

-- 
Raul

Re: Social Contract GR's Affect on sarge

[Raul Miller]

> Raul Miller <[EMAIL PROTECTED]> writes:
> > If we take "program" to mean "a sequence of instructions that a computer
> > can interpret and execute", then it's reasonable to consider a font file
> > as instructions on how to render characters in that font.

On Mon, Apr 26, 2004 at 04:21:28PM -0700, Thomas Bushnell, BSG wrote:
> Sure, but not bitmaps.  Bitmaps are not "sequences of instructions". 

Why not?

Looking at the first definition that comes up on a google
define:instruction search, I see "a message describing how something is
to be done"

Maybe you're thinking of another definition:  "A single command in the
assembly language of the CPU"?  But if that's the case then either (a)
elisp files do not represent instructions, or (b) font files do.

If they were "not instructions" then I'd think that any rendition of
the font would be acceptable.  Who cares if the letter A looks like the
letter Z?

I'll grant that the instructions are pretty bloody simple (when
rendering this character, use these bits), but that doesn't make them
"not instructions".

-- 
Raul

Re: Social Contract GR's Affect on sarge

[Raul Miller]

> Raul Miller <[EMAIL PROTECTED]> writes:
> 
> > On Mon, Apr 26, 2004 at 03:21:25PM -0700, Thomas Bushnell, BSG wrote:
> > > For a font, this is not quite true.  Many fonts in Debian are the
> > > output of little languages or the equivalent.  So we have no problem
> > > with the METAFONT-generated fonts.  IIUC, there is similarly no
> > > problem with Truetype fonts.
> > 
> > P.S. in this case the source code for the program obviously includes the
> > source code to that little language, if we want the font to be 100% free.
> > If you have some other interpretation, please be more specific.

On Mon, Apr 26, 2004 at 04:24:45PM -0700, Thomas Bushnell, BSG wrote:
> Huh?  The little language is a language, not a program.  Do you mean
> the source code to the program?  Or the source code to the language
> interpreter?  Or both?

I mean both.

For a metafont generated font to be 100% free, both the compiler
(metafont) must be free, and the font itself must be free.  The source
code for the font is written in the language compiled by the compiler.

> As I said, the METAFONT-generated fonts (if we have the METAFONT
> programs) are no problem.  See how easy that was?

Ok, I missed the "no problem" part -- reading too fast -- sorry for
the aside.

> > P.P.S.  I find it extremely ironic that one of the more vocal supporters
> > for the "get rid of non-free" meme is now arguing [rather vehemently]
> > against a somewhat milder implementation of that meme than was originally
> > proposed.
> 
> It's only ironic if you want to see everything on a political
> spectrum.

That's not only false, it's confusing.

>  I think that we should not distribute non-free on Debian;
> that is an entirely separate question from whether a particular thing
> is or is not free.
> 
> Nor am I arguing for a milder implementation of anything.  All I have
> said is that it is inappropriate to apply the GPL's definition of
> sourcecode unreflectively.  That definition is not, and never has
> been, a part of the DFSG, and we should not make it so now.

Once again: it's meaningless to reject a definition if you're not
going to provide a better one in its place.

-- 
Raul

Re: Social Contract GR's Affect on sarge

[Raul Miller]

On Mon, Apr 26, 2004 at 04:33:47PM -0700, Thomas Bushnell, BSG wrote:
> Are you now
> in agreement that we did not need to change the Social Contract at
> all; and that *everything* that is made of bits is software?

That has always been my opinion.

-- 
Raul

Re: Social Contract GR's Affect on sarge

[GOTO Masanori]

At Mon, 26 Apr 2004 12:47:58 -0400,
Raul Miller wrote:
> > > As an aside... or as a possibly related issue, consider glibc -- here
> > > is a piece of software which is licensed as free (though RMS might say
> > > that the LGPL licensed components aren't as free as he'd like), but
> > > which in practice is still distributed in almost-binary form (you can't
> > > build current versions of glibc on linux without having extremely current
> > > binaries because the version skew is so great).  In essence, the preferred
> > > form for working with this software must include its binaries...
> 
> On Mon, Apr 26, 2004 at 04:08:54PM +0200, Michael Banck wrote:
> > Huh??? This procedure is called bootstrapping...
> 
> Yes.  So?

This is much off topic issue of this thread, but, "So you can make
effort to build glibc for debian main distribution on another system
that is not driven by the current glibc".  Nowdays, we don't need to
do this kind of work which is sometimes executed for system
bootstrapping.

Regards,
-- gotom

Re: Social Contract GR's Affect on sarge

[Jochen Voss]

Hi Hamish,

On Tue, Apr 27, 2004 at 12:31:15AM +1000, Hamish Moffatt wrote:
> Usually it refers to changes that clarify the meaning without changing
> that meaning. I'd be interested in hearing your definition, since you
> seconded the GR.
Yes, this is exactly my point of view, too.  And I think
this is what the GR did.  But somehow, strangely, the
release manager thinks that the meaning did change.

> I'm stunned that this GR passed. ...
You should not be.  Debian is about freedom, so we
should struggle to not distribute non-free items.

Jochen
-- 
http://seehuhn.de/


signature.asc
Description: Digital signature

Re: Social Contract GR's Affect on sarge

[Florian Weimer]

Jochen Voss <[EMAIL PROTECTED]> writes:

> You should not be.  Debian is about freedom, so we
> should struggle to not distribute non-free items.

Debian is the distribution that distributes the largest chunk of
non-free software.  Please keep this in mind.

-- 
Current mail filters: many dial-up/DSL/cable modem hosts, and the
following domains: atlas.cz, bigpond.com, di-ve.com, hotmail.com,
netscape.net, postino.it, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr.

Re: Social Contract GR's Affect on sarge

[Francesco P. Lovergine]

On Mon, Apr 26, 2004 at 02:32:34PM +0200, Martin Schulze wrote:
> Francesco P. Lovergine wrote:
> > Did you have a look to FSF-related software in the last few time?
> 
> I normally use them, of course.
> 
> > Issue a 'man emacs' for instance
> 
> What am I supposed to read there?  Mine doesn't say that it's using
> the FDL but since its date says it's from 1995 December 7, I doubt
> it does.
> 
> Regards,
> 
>   Joey
> 

Oh well, on my (sid) edition:

   Copyright (c) 1995, 1999, 2000, 2001 Free Software Foundation, Inc.
 
   Permission is granted to copy, distribute and/or modify this document 
under the terms of the GNU Free  Documenta-
   tion  License, Version 1.1 or any later version published by the Free 
Software Foundation; with no Invariant Sec-
   tions, with no Front-Cover Texts, and no Back-Cover Texts.



-- 
Francesco P. Lovergine

Re: Social Contract GR's Affect on sarge

[Hamish Moffatt]

On Tue, Apr 27, 2004 at 10:22:50AM +0100, Jochen Voss wrote:
> On Tue, Apr 27, 2004 at 12:31:15AM +1000, Hamish Moffatt wrote:
> > Usually it refers to changes that clarify the meaning without changing
> > that meaning. I'd be interested in hearing your definition, since you
> > seconded the GR.
> Yes, this is exactly my point of view, too.  And I think
> this is what the GR did.  But somehow, strangely, the
> release manager thinks that the meaning did change.
> 
> > I'm stunned that this GR passed. ...
> You should not be.  Debian is about freedom, so we
> should struggle to not distribute non-free items.

No, nor do I propose that we continue to do so indefinitely.

Do you believe that the GR has had no effect other than editorial?
Or simply that the change is a good thing anyway?

I was stunned because I didn't think this proposal was ready for a vote.
It needed more development and discussion. It was proposed on
debian-devel that the GR be discussed and dissected item by item, but
that never occurred - instead we went straight to a vote.

Perhaps for our next GR, we can contemplate whether it's appropriate
that less than 20% of the developers is enough to change one of our most
important documents. In fact, it could have been changed with as few as
35, being less than 4%. That is, a 3:1 majority of quorum(45.274).
That's a very uncomfortable feeling.


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Social Contract GR's Affect on sarge

[Raul Miller]

On Tue, Apr 27, 2004 at 09:41:53AM +0900, GOTO Masanori wrote:
> This is much off topic issue of this thread, but, "So you can make
> effort to build glibc for debian main distribution on another system
> that is not driven by the current glibc".  Nowdays, we don't need to
> do this kind of work which is sometimes executed for system
> bootstrapping.

Does that work?

Cross compilation is tricky -- do you know anyone who has done this?

If debian's glibc can be built on bsd running under bsd's libc, then
that fully satisfies the legal requirements, leaving just the practical
issues.

Thanks,

-- 
Raul

Re: Social Contract GR's Affect on sarge

[Raul Miller]

> > Once again: it's meaningless to reject a definition if you're not
> > going to provide a better one in its place.

On Mon, Apr 26, 2004 at 04:44:34PM -0700, Thomas Bushnell, BSG wrote:
> Not true.  It is my position that we do not need to write or adopt a
> definition at all.  I don't want you to change the status quo in this
> regard; I don't want *any* definition to be adopted.  We already have
> the term; it has a meaning; it has served us well.
...
> I am not obliged to propose a different departure just to object to
> the departure you want to make.  I want to leave things as they are
> (with respect to the definition of "source code").

I'll agree that you're not under any obligation to provide a suitable
definition in the same way you're not obliged to make sense.

Frankly, I don't see that that definition has the flaws you've claimed
it has.  [For example, if there are equivalent representations and one
is the preferred form then any of them are the preferred form.]

Anyways, status quo is: some of us use a definition of "source code"
which you disagree with.

-- 
Raul

Re: Social Contract GR's Affect on sarge

[Thomas Bushnell, BSG]

Raul Miller <[EMAIL PROTECTED]> writes:

> The current context is "what is the definition of the phrase 'source
> code'?" -- and we take definitions wherever we find them.

Sure, but we shouldn't assume that any particular definition is the
one we should use just because someone says so.  We should look at the
consequences of such a decision.

Indeed, we already have a process: we work things out, case by case,
relying on the good sense of people involved, and the general
consensus of the folks on debian-legal.

Thomas

Re: Social Contract GR's Affect on sarge

[Thomas Bushnell, BSG]

Florian Weimer <[EMAIL PROTECTED]> writes:

> The alternative is no definition at all, and decide on a case-by-case
> basis.  I don't think that this will work in practice, partiallly
> because debian-legal has no ultimate say on this issue and those
> Debian institutions that have are not particularly well-known for
> their transparency.

We've been using this system for programs for a long time, and it's
worked in practice.  Why do you think it's suddenly going to start
failing?

Re: Social Contract GR's Affect on sarge

[Thomas Bushnell, BSG]

Raul Miller <[EMAIL PROTECTED]> writes:

> I disagree: "decide on a case-by-case basis" is not "no definition at
> all", instead it is "each case has its own definition", and that still
> leads to the question of "what is the definition in this case?"

Which case are we speaking of, exactly?  "Fonts" is too broad, in my
opinion, covering fonts that were created in bitmap form originally,
and fonts which are bitmap-modified METAFONT output, and fonts which
are built from automatically-generated METAFONT programs, and fonts
which are made from Truetype bytecodes (some of which were written as
bytecodes, some not); etc.

We don't have a definition for "programs" either (though, indeed,
using the GPL's version there is a good first step, but not
dispositive).

Thomas

Re: Social Contract GR's Affect on sarge

[Thomas Bushnell, BSG]

Raul Miller <[EMAIL PROTECTED]> writes:

> If we take "program" to mean "a sequence of instructions that a computer
> can interpret and execute", then it's reasonable to consider a font file
> as instructions on how to render characters in that font.

Sure, but not bitmaps.  Bitmaps are not "sequences of instructions". 

Re: Social Contract GR's Affect on sarge

[Josip Rodin]

On Mon, Apr 26, 2004 at 02:56:09PM +1000, Anthony Towns wrote:
> The Social Contract now states:
> 
> ] 1. Debian will remain 100% free
> ] 
> ] We provide the guidelines that we use to determine if a work is "free"
> ] in the document entitled "The Debian Free Software Guidelines". We
> ] promise that the Debian system and all its components will be free
> ] according to these guidelines. We will support people who create or
> ] use both free and non-free works on Debian. We will never make the
> ] system require the use of a non-free component.
> 
> As this is no longer limited to "software", and as this decision was made
> by developers after and during discussion of how we should consider
> non-software content such as documentation and firmware, I don't believe I
> can justify the policy decisions to exempt documentation, firmware, or
> content any longer, as the Social Contract has been amended to cover all
> these areas.

Um, even before while it was "limited" to "software", those who were of the
opinion that documentation and such things are part of "software" still had
a fairly valid point. The new phrasing, IMO, changes nothing.

On the other hand, it's reasonable to expect that the release manager has a
say (if not the final and overriding say) in determining the interpretation
of ambiguous documents and how they apply to the release process.

Hence, if you wish to make what I feel are non sequitur conclusions with
regards to what the SC says, it's your prerogative, but don't try to blame
it on the developer body (which includes myself).

-- 
 2. That which causes joy or happiness.

Re: Social Contract GR's Affect on sarge

[Thomas Bushnell, BSG]

Raul Miller <[EMAIL PROTECTED]> writes:

> On Mon, Apr 26, 2004 at 03:21:25PM -0700, Thomas Bushnell, BSG wrote:
> > For a font, this is not quite true.  Many fonts in Debian are the
> > output of little languages or the equivalent.  So we have no problem
> > with the METAFONT-generated fonts.  IIUC, there is similarly no
> > problem with Truetype fonts.
> 
> P.S. in this case the source code for the program obviously includes the
> source code to that little language, if we want the font to be 100% free.
> If you have some other interpretation, please be more specific.

Huh?  The little language is a language, not a program.  Do you mean
the source code to the program?  Or the source code to the language
interpreter?  Or both?

As I said, the METAFONT-generated fonts (if we have the METAFONT
programs) are no problem.  See how easy that was?

> P.P.S.  I find it extremely ironic that one of the more vocal supporters
> for the "get rid of non-free" meme is now arguing [rather vehemently]
> against a somewhat milder implementation of that meme than was originally
> proposed.

It's only ironic if you want to see everything on a political
spectrum.  I think that we should not distribute non-free on Debian;
that is an entirely separate question from whether a particular thing
is or is not free.

Nor am I arguing for a milder implementation of anything.  All I have
said is that it is inappropriate to apply the GPL's definition of
sourcecode unreflectively.  That definition is not, and never has
been, a part of the DFSG, and we should not make it so now.

Thomas

Re: Social Contract GR's Affect on sarge

[Thomas Bushnell, BSG]

Raul Miller <[EMAIL PROTECTED]> writes:

> All of which is completely irrelevant to the question of "what
> definition(s) are we using for 'source code'".

We aren't using any particular single definition of "source code".  We
have never in the past, and we aren't now.  Nothing has changed.
"Source code" means, in the context of the DFSG, just what it always
has meant.

"Source code" has a meaning, though not a rigid one.  We mean "source
code".  We do not mean "the preferred form for making changes"; if we
had meant that, we would have said so.

What value is there in finding a rigid definition?  It seems to me
that the only value would be that it would box us in needlessly.  We
might come up with a case that we look at and say, "well, that looks
like source code, but it doesn't meet the test of our rigid
definition", and then we would be stuck.  Better not to have the rigid
definition, so we can say, "that looks like source code".

Thomas

Re: Social Contract GR's Affect on sarge

[Thomas Bushnell, BSG]

Raul Miller <[EMAIL PROTECTED]> writes:

> If you're saying that for the case where the font was generated by hand
> using a hex editor, the bitmap file itself is the source code.  [And,
> perhaps not by chance, it was "the preferred form for making changes".]

Naw, because there are many equivalent file formats for a bitmap
font.  I don't care which format it was edited in (that's why the GPL
definition loses here).  *Any* non-lossy format for editing the bitmap
will do; perhaps it should be required that it's an open format.

Binary code, you see, is a lossy translation of the source code.
Source code contains a lot more information than the binaries do.  By
contrast, alternative bitmap formats for a font generally all contain
exactly the same information, and it doesn't matter to me at all
which one is distributed.

Thomas

Re: Social Contract GR's Affect on sarge

[Thomas Bushnell, BSG]

Raul Miller <[EMAIL PROTECTED]> writes:

> On Mon, Apr 26, 2004 at 04:20:59PM -0700, Thomas Bushnell, BSG wrote:
> > Which case are we speaking of, exactly?
> 
> Pick one.

In the case of a font generated from a METAFONT program, without
modification of the bitmaps, the source is the complete METAFONT
program, though not the METAFONT compiler itself.

In the case of a font designed as a bitmap, the font is that bitmap.

Re: Social Contract GR's Affect on sarge

[Thomas Bushnell, BSG]

Raul Miller <[EMAIL PROTECTED]> writes:

> > Raul Miller <[EMAIL PROTECTED]> writes:
> > > If we take "program" to mean "a sequence of instructions that a computer
> > > can interpret and execute", then it's reasonable to consider a font file
> > > as instructions on how to render characters in that font.
> 
> On Mon, Apr 26, 2004 at 04:21:28PM -0700, Thomas Bushnell, BSG wrote:
> > Sure, but not bitmaps.  Bitmaps are not "sequences of instructions". 
> 
> Why not?

Um, ok, then they are.  I'm not sure I care either way.  Are you now
in agreement that we did not need to change the Social Contract at
all; and that *everything* that is made of bits is software?

I am not interested in a rigid distinction between programs and data;
I am (as a general rule) interested in avoiding the needless attempt
to rigidly specify everything.

We have never in the past had a rigid definition of "source code".  We
got by just fine without it, we will continue to do so.

Thomas

Re: Social Contract GR's Affect on sarge

[Thomas Bushnell, BSG]

Raul Miller <[EMAIL PROTECTED]> writes:

> For a metafont generated font to be 100% free, both the compiler
> (metafont) must be free, and the font itself must be free.  The source
> code for the font is written in the language compiled by the compiler.

As it happens, the compiler is free.

But this is not in general true.  For example, it was possible to
write a free C program long before there was a free C compiler.  We
should not require the language-processor to be free before we regard
a program in that language as free.

But there might still be excellent reasons to keep such programs out
of the main archive.  In my opinion, the right way to do that would be
to put a Build-Depends on the language processor, and since the
language processor cannot be in main, the package itself cannot be
either.

So we don't really need to debate that case, since either way, the
package shouldn't be in Debian.

> Once again: it's meaningless to reject a definition if you're not
> going to provide a better one in its place.

Not true.  It is my position that we do not need to write or adopt a
definition at all.  I don't want you to change the status quo in this
regard; I don't want *any* definition to be adopted.  We already have
the term; it has a meaning; it has served us well.

If you want to replace it with "preferred form for making
modifications", you can use the GR process to make such a change.

I think we have a good practical definition of source code *already*.
I reject Ted's attempt to import one from a different place; I
explained why--mentioning the very different roles of licenses and the
DFSG.  We should leave things as they are.

I would say that if you want to adjust the status quo (which is to
rely on our already-existing common-sense understanding of "source
code"), then the burden is on you to justify your departure.

I am not obliged to propose a different departure just to object to
the departure you want to make.  I want to leave things as they are
(with respect to the definitino of "source code").

Thomas

Re: Social Contract GR's Affect on sarge

[Hamish Moffatt]

On Mon, Apr 26, 2004 at 10:34:55AM -0500, Manoj Srivastava wrote:
> On Tue, 27 Apr 2004 00:31:15 +1000, Hamish Moffatt <[EMAIL PROTECTED]> said: 
> > I'm stunned that this GR passed. I was surprised when the secretary
> > called for votes because the proposal wasn't anything close to ready
> > for voting
> 
>   Then you need to read the constitution, you obviously do noty
>  know how Debian works. Once a proposal has gathered the requisite
>  number of seconds, the secretary has limited wiggle room in calling
>  the vote;  A2.1. I had already put off Andrew once, pleasding
>  technical issues, after he had called for a vote; I could notr, in
>  good conscience, keep on postponing a properly proposed GR.

Actually I cannot justify your position from my reading of the
constituition.

The constituition says that there is a minimum discussion period of two
weeks, plus/minus one week at the secretary's discretion.
It says nothing of a maximum discussion period.

It says that the proposers and sponsors may call for a vote. It does not
indicate that the secretary must act within any timeframe or even that
the secretary must act quickly.


I'm not actually suggesting that the secretary should stall the vote at
his own discretion. This is a hole in the constituition.

(Admittedly, somewhat smaller than the one that allows less than 4% of 
the developers to change the social contract.)


Hamish
-- 
Hamish Moffatt VK3SB <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>

Re: Social Contract GR's Affect on sarge

[Daniel Jacobowitz]

On Tue, Apr 27, 2004 at 07:06:43AM -0400, Raul Miller wrote:
> On Tue, Apr 27, 2004 at 09:41:53AM +0900, GOTO Masanori wrote:
> > This is much off topic issue of this thread, but, "So you can make
> > effort to build glibc for debian main distribution on another system
> > that is not driven by the current glibc".  Nowdays, we don't need to
> > do this kind of work which is sometimes executed for system
> > bootstrapping.
> 
> Does that work?
> 
> Cross compilation is tricky -- do you know anyone who has done this?
> 
> If debian's glibc can be built on bsd running under bsd's libc, then
> that fully satisfies the legal requirements, leaving just the practical
> issues.
> 
> Thanks,

I do this on a daily basis.  Generating the complete set of Debian
packages would be very difficult, but also unnecessary if you're
willing to scrap a couple of chroots in the process.

-- 
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer

Re: Social Contract GR's Affect on sarge

[Martin Schulze]

Florian Weimer wrote:
> Jochen Voss <[EMAIL PROTECTED]> writes:
> 
> > You should not be.  Debian is about freedom, so we
> > should struggle to not distribute non-free items.
> 
> Debian is the distribution that distributes the largest chunk of
> non-free software.  Please keep this in mind.

Remembering that SuSE shipped a lot of non-free software and demo programs
I doubt this.

Regards,

Joey

-- 
Let's call it an accidental feature.  -- Larry Wall

Please always Cc to me when replying to me on the lists.

Re: Social Contract GR's Affect on sarge

[Jason Gunthorpe]

On Mon, 26 Apr 2004, Stephen Frost wrote:

> entirely opposed to it either.  Especially if the firmware is just
> assembled assembly for a specific processor that could be disassembled.
> I'm not very familiar with firmware though, is virtually all firmware
> compiled C code or is alot of it assembly or what?

It varies.

Sometimes it is C code running in a bare bones environment, or it is
running on something like VxWorks.

Sometimes it can be truely weird stuff like FPGA configuration data. This
is becoming more common as people are just embedding mini-FPGA like blocks
in their ASIC's.

Sometimes it is assembly code assembled using an assembler the vendor
built just for the logic they designed.

Sometimes it is something else entirely - ie the intel microcode 
patches.

Pretty much everything has embedded 'firmware' of one kind or anyother. 
Sometimes you don't see it, because it is in flash or ROM'd into the chip.
Though, often it ends up in a driver primarily to save on the cost of
flash and/or to ease updating it to new versions.

The ocurrance of this is only going to increase with time..

Jason

Re: Social Contract GR's Affect on sarge

[Jason Gunthorpe]

On Mon, 26 Apr 2004, Andreas Barth wrote:

> * Martin Schulze ([EMAIL PROTECTED]) [040426 12:10]:
> > Anthony Towns wrote:
> 
> > >   * firmware will need to be split out of the kernel into userspace
> > > in all cases
>  
> > It's good when this happens.
> 
> > >   * debian-installer will need to be rewritten to support obtaining
> > > non-free firmware but not other non-free packages
>  
> > It would be a clean solution at the end of the day, so this is good.
> 
> I agree that both these issues are good in the end. However, I really
> would prefer to tackle this issue after releasing of sarge. (On the
> other hand, we now also have the time to restrict our kernel source
> packages.)

At my job we do alot of work with companies to write drivers for hardware
that requires firmware to drive internal processors/etc - and through it
all there is one recurring issue: A particular driver version requires a
particular firmware version to work 100% as intended.

Splitting them up just makes it that much more likely that the driver
won't work because it has a newer/older firmware that is not compatible :<

Jason

Re: Social Contract GR's Affect on sarge

[Xavier Roche]

On Tue, 27 Apr 2004, Hamish Moffatt wrote:
> Perhaps for our next GR, we can contemplate whether it's appropriate
> that less than 20% of the developers is enough to change one of our most
> important documents.

Especially considering that it was intended to be only a matter of several
"Editorial amendments"
What a joke ..

Re: Social Contract GR's Affect on sarge

[Manoj Srivastava]

On Tue, 27 Apr 2004 20:22:27 +1000, Hamish Moffatt <[EMAIL PROTECTED]> said: 

> Perhaps for our next GR, we can contemplate whether it's appropriate
> that less than 20% of the developers is enough to change one of our
> most important documents. In fact, it could have been changed with
> as few as 35, being less than 4%. That is, a 3:1 majority of
> quorum(45.274).  That's a very uncomfortable feeling.

That is bot, BTW, how quorum works.  You would need at least
 46 people to change the foundation documents, as long as they were of
 one mind.

I find it amusing that we have people who were horrified how
 hard it would be to change a foundation document when that GR
 was proposed, and now we have another set horrified at how easy
 it is change one.

manoj
-- 
Send your questions to ``ASK ZIPPY'', Box 40474, San Francisco, CA
94140, USA
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Social Contract GR's Affect on sarge

[Stephen Frost]

* Manoj Srivastava ([EMAIL PROTECTED]) wrote:
>   That is bot, BTW, how quorum works.  You would need at least
>  46 people to change the foundation documents, as long as they were of
>  one mind.
> 
>   I find it amusing that we have people who were horrified how
>  hard it would be to change a foundation document when that GR
>  was proposed, and now we have another set horrified at how easy
>  it is change one.

I don't see why you should be.  I expect most were concerned with the
3:1 super-majority requirment and didn't even consider or think about
the quorum.  Certainly, I didn't at the time.  I do think the quorum
requirement for foundation documents needs to be increased.  I'd be
tempted to suggest 40%-50% of developers but the fact that we didn't get
much above that for the DPL election makes me concerned that there's too
many MIA developers on our roles for that to work.

Stephen


signature.asc
Description: Digital signature

Re: Social Contract GR's Affect on sarge

[Josip Rodin]

On Tue, Apr 27, 2004 at 01:10:47PM -0400, Stephen Frost wrote:
> > That is bot, BTW, how quorum works.  You would need at least
> >  46 people to change the foundation documents, as long as they were of
> >  one mind.
> > 
> > I find it amusing that we have people who were horrified how
> >  hard it would be to change a foundation document when that GR
> >  was proposed, and now we have another set horrified at how easy
> >  it is change one.
> 
> I don't see why you should be.  I expect most were concerned with the
> 3:1 super-majority requirment and didn't even consider or think about
> the quorum.  Certainly, I didn't at the time.  I do think the quorum
> requirement for foundation documents needs to be increased.  I'd be
> tempted to suggest 40%-50% of developers but the fact that we didn't get
> much above that for the DPL election makes me concerned that there's too
> many MIA developers on our roles for that to work.

A third sounds doable, though, and at least remotely representative.

-- 
 2. That which causes joy or happiness.

Re: Social Contract GR's Affect on sarge

[Gunnar Wolf]

Anthony Towns dijo [Mon, Apr 26, 2004 at 02:56:09PM +1000]:
> The Social Contract now states:
> (...)
> As this is no longer limited to "software", and as this decision was
> made by developers after and during discussion of how we should consider
> non-software content such as documentation and firmware, I don't believe
> I can justify the policy decisions to exempt documentation, firmware,
> or content any longer, as the Social Contract has been amended to cover
> all these areas.
> 
> As such, I can see no way to release sarge without having all these
> things removed from the Debian system -- ie main.
> (...)

After the tremendous amount of dust this post has lifted, I think i
have only one complaint: I agree with you, we must remain true to what
ourselves define as our foundation documents. Many of us (I surely
did) could not see this consequence when we voted for the editorial
change. Probably because the vote had a misleading title, probably
because the issues had been previously beaten over and over, and they
were always tagged for 'after Sarge'. We could not imagine this
outcome.

If you had prevented this situation over two days ago, why didn't you
speak before it was too late? Why didn't you bring to our attention
the side effects of our unwise choice helping us correct it instead of
sending it as a punishment for erading and answering too hastily on an
important issue? 

I am not a regular IRC follower, I keep up with Debian's news mainly
thanks to this list and to -private. And -once again- I believe there
are many other developers in my situation. I have been also swamped by
my work (and by other personal factors) recently, so I have even
missed many discussions - but I am sure this would have ignited a
thread almost as hot as this one. Not the kind of thing that can be
ignored. 

As many people have pointed out already, given the consequences [for
Sarge], I would like to change my vote. Many people didn't vote, and
probably would have were they aware the issues you presented would
delay Sarge probably for another year. Many speak about disrespect for
the people who have worked hard squishing bugs, writing d-i and the
many other tasks needed for having Sarge ready this summer. 

There is only one thing I can suggest - once again, nothing new,
nothing that has not yet been said in this discussion, but anyway: We
should release Sarge adhering to the Social Contract as it was until a
couple of days ago, and make this SC valid only from Sarge+1 on. 

Greetings,

-- 
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5630-9700 ext. 1366
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF

Re: Social Contract GR's Affect on sarge

[Martin Schulze]

Gunnar Wolf wrote:
> After the tremendous amount of dust this post has lifted, I think i
> have only one complaint: I agree with you, we must remain true to what
> ourselves define as our foundation documents. Many of us (I surely
> did) could not see this consequence when we voted for the editorial
> change. Probably because the vote had a misleading title, probably
> because the issues had been previously beaten over and over, and they
> were always tagged for 'after Sarge'. We could not imagine this
> outcome.

I don't believe that the GR had a misleading title.  It were editorial
changes after all.  We've been argued a lot of times before that the
SC/DFSG does not only handle pure software but all kinds of data.  We
were a bit lax in requiring proper actions, though.  In order to
clarify this once and for all, the GR was proposed, and finally
accepted.

It is unfortunate that the outcome of the GR will delay the sarge
release, of course, but in the long-term we all knew that we had to
fix the kernel problem, which was known for nearly two years after
all, and have to come to a decision on the GNU FDL issue.  We knew
that we had to deal with both at the end of the day, but only for the
moment they should not disturbe our release plans.

> I am not a regular IRC follower, I keep up with Debian's news mainly
> thanks to this list and to -private. And -once again- I believe there
> are many other developers in my situation. I have been also swamped by
> my work (and by other personal factors) recently, so I have even
> missed many discussions - but I am sure this would have ignited a
> thread almost as hot as this one. Not the kind of thing that can be
> ignored. 

I hate to advertise myself, but DWN would be a good resource for you
as well.

Regards,

Joey

-- 
Let's call it an accidental feature.  -- Larry Wall

Please always Cc to me when replying to me on the lists.

Re: Social Contract GR's Affect on sarge

[Manoj Srivastava]

On Tue, 27 Apr 2004 20:22:27 +1000, Hamish Moffatt <[EMAIL PROTECTED]> said: 

> I was stunned because I didn't think this proposal was ready for a
> vote.

You were stunned, eh? Could you point me to teh message on
 -vote where you expressed your concerns?

> It needed more development and discussion. It was proposed on
> debian-devel that the GR be discussed and dissected item by item,
> but that never occurred - instead we went straight to a vote.

And, presuming you voiced your concerns (you did, didn't you?)
 did you manage to convince even 5 of you fellow developers about the
 horrors that were about to unfold? 

manoj

-- 
hacker, n.: A master byter.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Social Contract GR's Affect on sarge

[Manoj Srivastava]

On Tue, 27 Apr 2004 12:57:18 +0200 (CEST), Xavier Roche <[EMAIL PROTECTED]> 
said: 

> On Tue, 27 Apr 2004, Hamish Moffatt wrote:
>> Perhaps for our next GR, we can contemplate whether it's
>> appropriate that less than 20% of the developers is enough to
>> change one of our most important documents.

> Especially considering that it was intended to be only a matter of
> several "Editorial amendments" What a joke ..

The joke, apparently, is on you -- failing to read the
 changes, and failing to exercise your franchise, has only yourself to
 blame.

manoj
-- 
The more cordial the buyer's secretary, the greater the odds that the
competition already has the order.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Social Contract GR's Affect on sarge

[Manoj Srivastava]

On Tue, 27 Apr 2004 13:10:47 -0400, Stephen Frost <[EMAIL PROTECTED]> said: 

> * Manoj Srivastava ([EMAIL PROTECTED]) wrote:
>> That is bot, BTW, how quorum works.  You would need at least 46
>> people to change the foundation documents, as long as they were of
>> one mind.
>>
>> I find it amusing that we have people who were horrified how hard
>> it would be to change a foundation document when that GR was
>> proposed, and now we have another set horrified at how easy it is
>> change one.

> I don't see why you should be.  I expect most were concerned with
> the 3:1 super-majority requirment and didn't even consider or think
> about the quorum.  Certainly, I didn't at the time.  I do think the
> quorum requirement for foundation documents needs to be increased.
> I'd be tempted to suggest 40%-50% of developers but the fact that we
> didn't get much above that for the DPL election makes me concerned
> that there's too many MIA developers on our roles for that to work.


What on earth for? You can't mandate interest; and raising the
 quorum in general allows the slackers and the apathetic people to
 prevent the people who are interested in actually doing work.  If
 people are not interested, they are not interested -- you should not
 penalize every one else  for the disinterest of the rest.

manoj
-- 
You're working under a slight handicap.  You happen to be human.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Social Contract GR's Affect on sarge

[Manoj Srivastava]

On Tue, 27 Apr 2004 22:47:09 +1000, Hamish Moffatt <[EMAIL PROTECTED]> said: 

> On Mon, Apr 26, 2004 at 10:34:55AM -0500, Manoj Srivastava wrote:
>> On Tue, 27 Apr 2004 00:31:15 +1000, Hamish Moffatt
>> <[EMAIL PROTECTED]> said:
>> > I'm stunned that this GR passed. I was surprised when the
>> > secretary called for votes because the proposal wasn't anything
>> > close to ready for voting
>>
>> Then you need to read the constitution, you obviously do noty know
>> how Debian works. Once a proposal has gathered the requisite number
>> of seconds, the secretary has limited wiggle room in calling the
>> vote; A2.1. I had already put off Andrew once, pleasding technical
>> issues, after he had called for a vote; I could notr, in good
>> conscience, keep on postponing a properly proposed GR.

> Actually I cannot justify your position from my reading of the
> constituition.

Hmm. I guess we could ask for a formal disambiguation.

I do not indefinitely delay votes for no discernibl;e
 reason. After all, I am still convinced that the vote was a minor
 editorial clarificatrion of what the SC has always meant.  If you
 believed differently, how come you are so very vociferous _after_ the
 fact?

> The constituition says that there is a minimum discussion period of
> two weeks, plus/minus one week at the secretary's discretion.  It
> says nothing of a maximum discussion period.

> It says that the proposers and sponsors may call for a vote. It does
> not indicate that the secretary must act within any timeframe or
> even that the secretary must act quickly.

That is a quibble.  The call for votes does not go to the
 secretary, the call for votes goes to the voters. Once the call for
 votes has gone out, the voters vote; and the secretary must arrange
 for these votes to be counted.

> I'm not actually suggesting that the secretary should stall the vote
> at his own discretion. This is a hole in the constituition.

I do not think it s a hole in a reasonable reading of the
 constitution.

> (Admittedly, somewhat smaller than the one that allows less than 4%
> of the developers to change the social contract.)

That, too, is not a hole. If people were not so very
 apathetic, they could oppose any change -- by (gasp) exercising their
 franchise.

The people who did not vote should not be trying to pin the
 blame of their apathy on any and everyone else in spitting distance.

manoj
-- 
It is generally agreed that "Hello" is an appropriate greeting because
if you entered a room and said "Goodbye," it could confuse a lot of
people. Dolph Sharp, "I'm O.K., You're Not So Hot"
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Social Contract GR's Affect on sarge

[Manoj Srivastava]

On Tue, 27 Apr 2004 12:21:14 -0600, Gunnar Wolf <[EMAIL PROTECTED]> said: 

> Probably because the vote had a misleading title, probably because
> the issues had been previously beaten over and over, and they were

I reject the thesis that the vote had a misleading title. And,
 anyway, you are supposed to be voting for the substance, not the
 title, of the changes.  If you did not care to read the RFD, or any
 of the three CFV's that went out, perhaps you should try and take
 responsibility for your own vote (or lack thereof), rather than
 trying excuses and trying to pin the blame on anything and everything
 that moves? "Waaah. My dog ate my vote".

> As many people have pointed out already, given the consequences [for
> Sarge] , I would like to change my vote. Many people didn't vote, and

Got a time travel machine?

manoj
-- 
Remember, UNIX spelled backwards is XINU. Mt.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024R/C7261095 print CB D9 F4 12 68 07 E4 05  CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Social Contract GR's Affect on sarge

[Mark Brown]

On Tue, Apr 27, 2004 at 10:09:06PM +0200, Martin Schulze wrote:

> I don't believe that the GR had a misleading title.  It were editorial
> changes after all.  We've been argued a lot of times before that the
> SC/DFSG does not only handle pure software but all kinds of data.  We

The controversy surrounding the result really does suggest that for many
this has been more than a simple textual clarification.

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

Re: Social Contract GR's Affect on sarge

[Matt Zimmerman]

On Mon, Apr 26, 2004 at 12:06:05PM -0500, Manoj Srivastava wrote:

> On Tue, 27 Apr 2004 01:49:12 +1000, Anthony Towns  
> said: 
> > I'm sorry, you're mistaken. It was against Andrew's interpretation
> > of the social contract. It wasn't against mine, nor to the best of
> 
>   It certainly was against what I took the social contract to
>  be. I never imagined that Debian was about only part of main being
>  free, indeed, as Bruce has stated, I, too, was under the impression
>  that the  SC and the DFSG applied to everything on the Debian CD.

I do not see how it can be maintained that these were "editorial changes"
when there is clearly a significant number of developers who believe that
the meaning of the Social Contract was changed (to the point of forcing
action that was not forced before).

-- 
 - mdz