* Debian Project Secretary:
> In accordance with principles of openness and transparency, Debian
> will seek to declassify and publish posts of historical or ongoing
> significance made to the Debian Private Mailing List.
>
> This process will be undertaken under the following cons
* Kalle Kivimaa:
> Florian Weimer <[EMAIL PROTECTED]> writes:
>> If I read the constitution correctly, you cannot decide such a thing
>> by GR.
>
> Could you give us your reasoning why this isn't "Issuing, superseding
> and withdrawing nontechnical policy
* Daniel Ruoso:
> In accordance with principles of openness and transparency, Debian
> will seek to declassify and publish posts of historical or ongoing
> significance made to the Debian Private Mailing List.
What is the "Debian Private Mailing List"?
[EMAIL PROTECTED], or any other alias pointi
* Daniel Ruoso:
>> This distinction is important because for years, [EMAIL PROTECTED]
>> was an aliases for debian-private, and people who sent mail to that
>> address might be very surprised that it's subject to declassification
>> (and that it was sent to hundreds of Debian developers in the fir
* Wouter Verhelst:
>> > In accordance with principles of openness and transparency, Debian
>> > will seek to declassify and publish posts of historical or ongoing
>> > significance made to the Debian Private Mailing List.
>> >
>> > This process will be undertaken under the followin
* Kalle Kivimaa:
> Florian Weimer <[EMAIL PROTECTED]> writes:
>> Some of these issues are certainly unfixed, and very, very few might
>> even be unpublished. It's unlikely that one of those has been sent to
>> Debian, though.
>
> And if it has been sent t
* MJ Ray:
> Nearly all messages sent to debian-private are covered by copyright
> and I think republishing any such past message could get Debian into
> legal trouble, in general, unless there's explicit permission from its
> author. If someone has a good global argument against that, please post
* Anthony Towns:
> Bcc'ed to -project, -legal and -private; followups to -vote please.
>
> It's been six months since the social contract changes that forbid
> non-free documentation went into effect [0], and we're still distributing
> GFDLed stuff in unstable [1]. I think we should get serious ab
* Craig Sanders:
> there's nothing in the GFDL that prevents you from doing that. the
> capabilities of your medium are beyond the ability of the GFDL (or any
> license) to control.
Uhm, the existence of the anti-DRM clause disproves this claim.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
wi
As you might have noted, the Constitution does not spell out the
process how a new delegation is made. Would you please summarize the
process you intend to follow if you are elected? Thanks.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL
* Manoj Srivastava:
> On 11 Jun 2006, Martin Wuertele stated:
>
> ]Since Debian has no authority to hold money or property, any
> ]donations for the Debian Project must be made to any
> ]one of a set of organizations designated by the Project leader
> } or a delegate to be aut
* Manoj Srivastava:
>
> 4. The Developers by way of General Resolution or election
>4.1. Powers
> Together, the Developers may:
> +6. Together with the Project Leader make decisions about
> + property held
* Steve Langasek:
> - The author's preferred form for modification may require non-free tools
> in order to be converted into its final "binary" form; e.g., some
> device firmware, videos, and graphics.
I would prefer if the term "firmware" would be defined or at least
explained in the
* Steve Langasek:
>> I'd actually see some restriction with regard to interoperability
>> (i.e. some reasonably documented interface between the firmware and
>> the driver code), but getting this right is likely not worth the
>> effort.
>
> Hmm, I'm not sure what that would look like at all; as so
* Debian-project Secretary:
> The details of the general resolution can be found at:
> http://www.debian.org/vote/2006/vote_003
This document has been garbled, possibly due to charset issues.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL
* Manoj Srivastava:
> On Sun, 10 Sep 2006 11:24:23 +0200, Florian Weimer <[EMAIL PROTECTED]> said:
>
>> * Debian-project Secretary:
>>> The details of the general resolution can be found at:
>>> http://www.debian.org/vote/2006/vote_003
>
>> This docum
* Andreas Barth:
> perhaps we should, independend of current GRs, consider how to change
> the GR procedure so that it doesn't happen to be as painful as it is
> now.
Perhaps pain is highly subjective in this case. I guess it's less
bizarre if you've been exposed to Robert's Rules of Order. (Bu
* Martin Schulze:
> It's not about a timely release, it's about Debian directly or indirectly
> paying *some* developers for the work they signed up to.
But this is hardly a new thing. The difference is that this time,
there is a debate. Debian developers are currently not required to
disclose
* Steve Langasek:
> On Thu, Sep 21, 2006 at 01:08:17PM +0200, Pierre Habouzit wrote:
>
>> just let me rephrase it then.
>
>> 1. The DPL is the one that appoints the RM as per constitution
>
> You know, this is true only in the most hypothetical sense. Neither Colin,
> nor Andi nor I, nor any of
* Hamish Moffatt:
> Do you think it's likely that it can boot the kernel and run the build
> environment without crashing, but produce broken binaries?
We've got a few cases where emulated builds on amd64, sparc64 and
s390x failed to produce working binaries for i386, sparc and s390.
Usually, the
* Ian Jackson:
> I disagree with this position. See Fabian Fagerholm's explanation.
> For a strong copyleft licence like the GPL it's particularly
> troublesome if people go around making minor edits: all of that code
> is licence-incompatible with all unedited-GPL code. So the FSF have
> worked
* Anthony Towns:
> 5) The intial policy for the use of the Debian Maintainer keyring with the
>Debian archive will be to accept uploads signed by a key in that keyring
>provided:
>
> * none of the uploaded packages are NEW
>
> * the Maintainer: field of the uploaded .changes fi
* Pierre Habouzit:
> Well, maybe we could avoid some bike-shedding. While Ian was too busy
> writing mails in capital letters, explaining how Debian should weigh in
> the IETF RFC drafting,
The IETF will probably remove Rule 9 altogether (for both IPv4 and IPv6,
since the TLA/NLA/SLA model is d
* Steve Langasek:
>> The IETF will probably remove Rule 9 altogether (for both IPv4 and IPv6,
>> since the TLA/NLA/SLA model is dead and we're heading for IPv4-style
>> portable addresses in IPv6 land, too).
>
> Is this speculation, or have you heard this from the IETF?
"The IETF" as such does no
* Andreas Barth:
> So, I would replace your 2. with the current text, and your 3. with:
> 3. During any DPL term, the DPL might appoint up to two new members
> unilaterally. He might replace an existing member, or add them as
> additional members at his choice, provided the maximum num
* Stephen Gran:
> It's not possible to express the full set of relations in a single
> winner vote, as far as I can tell. It might be someone's vote to say
> 'none of this non-free crap in the archive ever' and simultaneously
> say 'but the release team does have the authority to downgrade these
* Neil McGovern:
> On Mon, Dec 02, 2019 at 05:18:35PM +0100, Thomas Goirand wrote:
>> On 11/29/19 11:32 PM, Sam Hartman wrote:
>> > Imagine that we have a program that has compile time support for systemd
>> > and for other mechanisms. It provides enhanced functionality when built
>> > against sy
* Sam Hartman:
> I don't think we're going to get much benefit out of a prolonged
> discussion, and I think that there is significant benefit in acting
> quickly in this instance.
I think the appendix to the open letter is problematic, and that might
warrant some discussion. Am I alone in this r
* Paul Wise:
> Does anyone have any more info about the changes?
Isn't that the crux of the matter?
It appears that everyone in the EU political process is withholding
details, like the concrete text as it exists today. Selective leaks
are likely manipulative to some extent, perhaps trying to u
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 w
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
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 absur
[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 modificatio
[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 w
[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 GP
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 is
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/D
Theodore Ts'o <[EMAIL PROTECTED]> writes:
> Actually, this may be useful. If this inspires the pragmatists to go
> make a "Debian Useful" variant that actually has documentation,
> firmware, fonts, etc. then the fringe fanatics that want to spend all
> of their time arguing over the Social Contra
Scott Dier <[EMAIL PROTECTED]> writes:
> I'm going to see how Steve Langasek's proposal fares. If it doesn't
> fare well after a vote (or appears to not fare well) I'm going to start
> thinking seriously about coming up with a 'custom debian distribution'
> based on a subset of packages in testin
Martin Schulze <[EMAIL PROTECTED]> writes:
> 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
Henning Makholm <[EMAIL PROTECTED]> writes:
> I solicit comments about the above from -vote in general, but I
> would especially like to hear reactions from the proponent of each
> proposal.
Given that most of the GR proposals are written to work around our
RM's conscience, it would be helpful to
* Julien BLACHE:
>>> [ ] Choice 2: Allow Lenny to release with proprietary firmware [3:1]
>>
>> We're not changing the DFSG. So there's no need for 3:1.
>
> We're overriding it, so it requires 3:1, and it was the same for the
> waiver for Etch.
Are we? I mean, this stuff is already in the arch
* Theodore Tso:
> I'm not ashamed at all; I joined before the 1.1 revision to the Debian
> Social Contract, which I objected to them, and I still object to now.
> If there was a GR which chainged the Debian Social contract which
> relaxed the first clause to only include __software__ running on th
* Mike Hommey:
> On Mon, Dec 29, 2008 at 03:01:19PM +0100, Florian Weimer
> wrote:
>> * Theodore Tso:
>>
>> > I'm not ashamed at all; I joined before the 1.1 revision to the Debian
>> > Social Contract, which I objected to them, and I still object to n
* Gerfried Fuchs:
>> For instance, while I have no particular opinion on firmware, I object
>> to packages in main which, when run on a web browser, execute
>> proprietary Javascript blobs (either by shipping them in the package,
>> or by linking them in some way).
>
> But it is. The web browser
* Charles Plessy:
> I wonder why not simply inviting the Debian Account Managers to
> accept the long term contributors as DDs, even if they to not
> maintain packages? Would an amendement be welcome?
Seems reasonable. (I'm among those who believe that voting rights are
more fundamental than upl
The GPLv2 contains a system library exception. This enables
proprietary operating systems (such as Solaris or Windows) to
distribute GNU software linked against proprietary libraries
(including the system libc and other compiler support libraries),
something the GPLv2 would not otherwise allow bec
* Chris Lamb:
> Dear Florian,
>
>> the more pressing example is libgcc (the compiler support library part
>> of GCC), which was upgraded to the GPLv3 some time ago. libgcc is
>> mandatory on some architectures, but the GPLv3 is incompatible with
>> the GPLv2 (under which important software such a
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 w
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
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 absur
[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 modificatio
[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 w
[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 GP
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 is
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/D
Theodore Ts'o <[EMAIL PROTECTED]> writes:
> Actually, this may be useful. If this inspires the pragmatists to go
> make a "Debian Useful" variant that actually has documentation,
> firmware, fonts, etc. then the fringe fanatics that want to spend all
> of their time arguing over the Social Contra
Scott Dier <[EMAIL PROTECTED]> writes:
> I'm going to see how Steve Langasek's proposal fares. If it doesn't
> fare well after a vote (or appears to not fare well) I'm going to start
> thinking seriously about coming up with a 'custom debian distribution'
> based on a subset of packages in testin
Martin Schulze <[EMAIL PROTECTED]> writes:
> 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
Henning Makholm <[EMAIL PROTECTED]> writes:
> I solicit comments about the above from -vote in general, but I
> would especially like to hear reactions from the proponent of each
> proposal.
Given that most of the GR proposals are written to work around our
RM's conscience, it would be helpful to
* Manoj Srivastava:
>> For our users, we promise to do regular releases; as a guideline, a
>> major release of the distribution should happen about once a year.
>
> On what basis do you think we can make this promise?
On the same basis that we promise not to hide bugs? Or not to rely on
no
* Andreas Barth:
> Actually, we hide security bugs. Of course not, if they are filled
> into the bts, but we hide them if they are sent to [EMAIL PROTECTED]
> Please don't misunderstand me; I think the current approach is the
> right one, but with literal reading SC #3 is tangled (and I know that
* Andrew Suffield:
> Ah yes, that's another of those common memes. It's completely
> unfounded. There is no reason to think that it would take a long time
> to evict all the offending material - it's trivial in most cases.
The discussion about fonts, closed and semi-closed data formats, and
data
* Andrew Suffield:
>> The discussion about fonts, closed and semi-closed data formats, and
>> data formats which are inherently lossy and for which we lack the
>> lossless source files has not really started yet. It will take months
>> until Debian agrees on policies for these cases, and further
* Matthew Garrett:
>>Refusal to act is a decision and a rejection.
>
> A stated refusal to act would be. An absence of communication is not.
In the long run, it is. If you watched German politics during much of
the 80s and 90s, you would know how far you can get by just ignoring
things, instead
* James Troup:
> If anyone thinks that trying to decide technical issues through voting
> is a good idea, I pity them.
In my eyes, voting on technical issues is still better than no
explicit decision at all. Both options are horrible, but explicit
decisions are still better than implicit ones, n
66 matches
Mail list logo
