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

[Florian Weimer]

* 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 undermine
the credibility of the legislative process itself, without actually
caring much about FOSS.

An objective analysis would need the complete consolidated text,
including translations.  The German version tends to be clearer what
commercial activity is supposed to mean, for example.

Re: Asking DPL to shorten Discussion Period for rms-open-letter

[Florian Weimer]

* 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 regard?

Re: Question Under Proposal D: Compile Time Option

[Florian Weimer]

* 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 systemd, but when so built, it cannot run without systemd.
>> > 
>> Is this a real life case (if so, please name the package...), or just a
>> pure fictional one, just because you love debating?
>> 
>
> Or a hypothetical one, but one which could be fairly reasonable to
> expect. This GR seems to be trying to put in place a statement on what
> exactly we mean by support, and so considering things which may
> reasonably happen in the future is something that we should do.

It's certainly what we have seen with SELinux, where support causes
packages to grow additional library dependencies.  Even though
libselinux is overall quite benign (even Fedora and downstreams do not
*require* that the kernel activates SELinux), I'm sure it initially
caused problems for chroot setups.

Re: Q to the candidates: GPLv2 system library exception

[Florian Weimer]

* 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 as Git and OpenJDK are
>> released).  It is unclear whether the GCC run-time library exception
>> restores GPLv2 compatibility.
>
> Thank you for bringing up this important issue; these complicated
> issues of GPL compliance are not as widely known as they should be.
>
> My response as DPL candidate is that whilst I would agree that the
> situation needs addressing in some way, I don't believe any decision
> should fall under the scope or influence of a Project Leader, modulo
> ensuring that any discussion does not get "stuck" or to act as
> liason with outside parties for their expertise, experience or opinion.

The DPL could approve funds to obtain qualified external advice.  I
think this is what happened with ZFS (scroll to the end):



Would you consider the issue important enough to allocate the
necessary funds?

Q to the candidates: GPLv2 system library exception

[Florian Weimer]

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 because full machine
readable source code for the executable cannot be provided.

Historically, Debian has assumed that unlike proprietary operating
systems, it cannot use the system library exception in the GPLv2 to
permit linking against libraries part of Debian which are licensed in
a way that is not compatible with the GPLv2.  This position is
somewhat unique among free software distributions, and is not fully
enforced within Debian, either.  We currently distribute GPLv2
software in such away that we apparently invoke the system library
exception to avoid a GPL violation.

In the past, the most prominent example was OpenSSL.  (The OpenSSL
relicensing in progress will not substantially alter this situation
because the new license is still incompatible with the GPLv2.)  Today,
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 as Git and OpenJDK are
released).  It is unclear whether the GCC run-time library exception
restores GPLv2 compatibility.

For OpenSSL, we obtained permission to link against OpenSSL from many
upstream projects.  But for libgcc, that seems rather excessive.

Do you think this situation needs addressing?  What do you propose do
about it?  Do you think the way the ZFS situation was resolved could
be an example?

(Question as suggested by Moritz Mühlenhoff in
 on debian-devel.)

Re: GR: welcome non-packaging contributors as Debian project members

[Florian Weimer]

* 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 upload rights.)

We could also suggest (outside the GR) that DAM provides something
which enables DDs to permanently break a key for uploads, without
invalidating it for other purposes.  That might be useful for some DDs
and would-be DCs.

We may also need a more flexible NM process to accommodate those who
do non-packaging work.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874odpcyjm@mid.deneb.enyo.de

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Florian Weimer]

* 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 does run on the Host CPU, thus the
> javascript engine does run on the Host CPU, too.
>
>  Problem solved. :)

The counterargument is that for a server application, the Javascript
blob isn't intended to run on the host CPU, but on the client. 8-/

(Conversely, firmware shouldn't doesn't non-free material only because
you can run it using qemu because it happens to be a supported
architecture.)


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Florian Weimer]

* 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 now.
>> > If there was a GR which chainged the Debian Social contract which
>> > relaxed the first clause to only include __software__ running on the
>> > Host CPU, I would enthusiastically vote for such a measure.
>> 
>> I think it's not that simple anymore.
>> 
>> 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).
>
> Following the same logic, you should be opposing to packages such as the
> kernel, that allows to run proprietary ELF blobs. This is ridiculous.

If the kernel automatically downloaded some binary from the network
and executed it, I would consider that unacceptable for a default
configuration, too.

It's not the mere possibility that counts.  I'm against doing this by
default (or requiring it for almost any use of a package).


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Results for General Resolution: Lenny and resolving DFSG violations

[Florian Weimer]

* 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 the
> Host CPU, I would enthusiastically vote for such a measure.

I think it's not that simple anymore.

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).


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: Bundled votes and the secretary

[Florian Weimer]

* 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 archive, in main, and as
far as I can tell, the release team can release from main at any point
in time they see fit (practical considerations notwithstanding).

The Social Contract does not even mention the word "release".  A
release doesn't really change if we are in conformance or not.  The
release team has little control over the conformance aspect,
especially if core packages are affected for which remove is not an
option.

In this light, requiring a 3:1 supermajority just to underscore that
the release team is, in fact, the release team and can release from
main is a bit out of line, isn't it?

Oh, and I'm quite offended how this whole thing is used to pressure
developers to do certain work, contrary to the spirit of Constition
2.1.1.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Re: call for seconds: on firmware

[Florian Weimer]

* 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 bug
> reports if they need to'.  Unless I've missed something and we're
> planning on having a multi winner vote, 

We can always put the elements of the power set of all proposals on
the ballot.

I suppose the ballot should be structured in a way that guarantees
halfway meaningful outcomes, while not actively discriminating against
certain proposals.  To be honest, I'm glad I need not decide such
things.


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

Re: Technical committee resolution

[Florian Weimer]

* 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 number of eight
>  members is not exceeded.

This is ambiguous.  Can the DPL replace two members or just one?

(And, BTW, does the Constitution make gender assumptions WRT to the DPL
in other places? 8-)


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

Re: Supermajority requirement off-by-one error, and TC chairmanship

[Florian Weimer]

* 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 not exist, so my wording was a bit careless.
It's been discussed on the v6ops mailing list, and one of the authors of
the successor RFCs (Arifumi Matsumoto) seemed to favor the proposal to
drop Rule 9 (actually for both IPv4 and IPv6).  Currently, IETF activity
is mostly frozen due to IETF-71.  We'll see what happens afterwards.

Participation in the relevant WGs (v6ops and 6man, I think) is a good
idea if you care about IPv6, irrespective of this issue.


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

Re: Supermajority requirement off-by-one error, and TC chairmanship

[Florian Weimer]

* 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 dead and we're heading for IPv4-style
portable addresses in IPv6 land, too).

> upstream made a proper fix for IPv4, in a very sensible way, and the
> problem is gone

Have you got a pointer to the discussion/patch?  Thanks.


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

Re: Debian Maintainers GR Proposal

[Florian Weimer]

* 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 file matches the
> key used (ie, maintainers may not sponsor uploads)
>
>   * none of the packages are being taken over from other source packages
>
>   * the most recent version of the package uploaded to unstable
> or experimental lists the uploader in the Maintainer: or Uploaders:
> fields (ie, cannot NMU or hijack packages)
>
>   * the usual checks applied to uploads from Debian developers pass

I suppose their should be checks for unchanged "Provides:" and
"Replaces:" lines, too.  (Not sure about "Enhances:".)


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

Re: Request for GR: clarifying the license text licensing / freeness issue

[Florian Weimer]

* 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 to prevent that by using the copyright on their licence text
> and I don't think that's unreasonable.

So in practice, authors add additional permissions and conditions as a
GPL commentary.  The actual license is a GPL derivative in a
functional sense, but probably not in the copyright sense.

> The status quo is quite fine and should be left as it is.
>
> If this is forced to a GR we should have an option along these lines:
>
>   We note that many license texts are copyrighted works, licensed only
>   under meta-licenses which prohibit the creation of derivative
>   license texts.
>
>   We do not consider this a problem.

I think it should be made more clear that "derivative license texts"
means actually that, and does not include derivatives that are created
by patching of some other license.

(Nothing in this message should be interpreted as support for any GR
proposal.)


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

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

[Florian Weimer]

* 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, these are considered bugs in the affected packages.


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

Re: Proposal: Recall the Project Leader

[Florian Weimer]

* 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 the current release assistants, were ever the
> subject of a formal delegation by the DPL,

How would you know?  The Consitution does not require that the DPL
makes delegations public.  Strictly speaking, even the delegate
doesn't need to know aboutit.  For instance, Branden has made Andi a
formal delegate AFAIK, but I can't find any public documentation.


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

Re: Proposal: Recall the Project Leader

[Florian Weimer]

* 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 to the project (or the public) how they make money through
the privileges granted to them to the project.

The current situation is roughly this: Debian exclusively assigns some
roles to a few developers (either through delegation, or by other
means).  In some cases, it turns out that in this role, you can carry
out tasks that are commercially significant to entities outside
Debian, and you get paid for both your expertise and your privileges
granted to you by the project.  In this case, the decision who gets
assigned such roles by the project certainly has economic aspects, and
to me it seems that this suffers from the same risks as paying
developers directly.  Unfortunately, it's difficult to debate about
this publicly because we can't name any specifics.

NB: Ordinary package maintenance tasks are not affected by this
because we have well-established conflict resolution procedures and
ways to work around inactive maintainers.


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

Re: Filibustering general resolutions

[Florian Weimer]

* 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.  (But I
still think that the Rules themselves are horrible.)


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

Re: First call for votes for the assets handling constitutional amendment GR

[Florian Weimer]

* 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 document has been garbled, possibly due to charset issues.
>
> Garbled how? Seems perfectly fine to me, apart from an
>  accented character of a proposer's name.

The paragraph references were garbled as well.  Thanks for correcting
them.


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

Re: First call for votes for the assets handling constitutional amendment GR

[Florian Weimer]

* 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 PROTECTED]

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

[Florian Weimer]

* 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 someone else noted,
> one generally doesn't talk to the firmware even, one talks to the device.

The higher-layer protocol the device speaks to the driver is typically
implemented by the firmware.

But it turns out that what I want has not much to do with
interoperability.  The thing I'd like to rule out is that
application-specific code is transferred to a device, and we do not
provide source code for that device.  For example, implementing OpenGL
primitives (or JPEG decompression) on the GPU in sourceless firmware
might be acceptable, but putting computer AI for games in there, or
rendering a proprietary video format using it would be much harder to
accept.


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

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

[Florian Weimer]

* 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 GR.  Something like:

  firmware (data which is sent to attached devices for processing and
  which is not, directly or indirectly, executed on the host CPU)

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.

It seems the present language also covers CA certificates, which is
fine.

A completely different issue is whether we take upstream's word for
GPL compability, or if we claim that something is not redistributable
because it contains a firmware blob *and* is licensed under the GPL as
a whole.


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

Re: Donations

[Florian Weimer]

* 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 in trust for purposes related to Debian. (See
> +   §9.).  Such decisions are made by announcement on a 
> +   electronic mailing list designated by theProject Leader's 
> +   Delegate(s), which is accessible to all developers. 
> -
>
> So, we can disburse funds privately, if we wish, but there is
>  still a modicum of oversight, since  any DD  would have access to
>  it.

Shouldn't this be parallel to the second instance below, that is
"designated by the Project Leader or their Delegate(s)", instead of
requiring delegation?

Re: Donations

[Florian Weimer]

* 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 authorized to handle such things in name
>  ]  of the Debian project. 
>  \footnote{Historically, Any property in hardware, trademarks, or in
>  copyright was handled by SPI, our original legal umbrella organization
>  in the U.S.}
>
>
>> Why limit the change to monetary donations?
>
> No reason.  I also changed allowed -> authorized,  and added
>  allowed for the possibility of delegation.  How does this sound?

I'd like to see a requirement that such authorization must be public.
Something like "Such authorization, or its withdrawal, must be
published on an appropriate Debian mailing list."


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

To all candidates: delegation process

[Florian Weimer]

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 PROTECTED]

Re: A new practical problem with invariant sections?

[Florian Weimer]

* 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]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: GR Proposal: GFDL statement

[Florian Weimer]

* 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 about fixing
> that, and as part of that that we should release the following statement
> (or one like it) on the GFDL:

This GR effectively overrides decisions by the DPL and his delegates,
and should mention this.

Apart from that, I've mixed feelings about it.  I don't know what's
really going on behind the scenes.


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

Re: Proposal for *Real* Declassification of debian-private archives

[Florian Weimer]

* 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
> it here and/or the debian-legal thread. ("Fair use" is somewhat
> variable globally.)

Globally, I'm not sure.  A typical mailing list article is not subject
to German copyright law because it lacks originality.  I know that the
U.S. situation is somewhat different.

> I've not thought much about trade secrets and privacy laws. Can someone
> explain how they cause problems, please?

For a couple of years, I dealt with security issues for a large
institution, and we received quite a bit of sensitive information on
our security@ mailbox from external parties: IP addresses of attackers
and victims, excerpts from communication, the fact that someone was
attacked successfully, embarrassingly incorrect log file analysis.
Nothing you'd really like to see published, and some of it is probably
also protected by law.

> All in all, it looks like redefining -private to have no privacy
> would be evil, bad and wrong. 

Indeed.  But in some sense, people are already anticipating that:
-private is mostly unused.  Developers prefer to operate in almost
complete secrecy.

> It would still be good to see a team trying to publish the stuff
> that shouldn't be on there or that is public interest, but that can
> happen without a policy change GR.

I don't understand why a GR is needed.  But then, I can't find a
policy document which makes postings on -private confidential, either.


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

Re: Proposal for *Real* Declassification of debian-private archives

[Florian Weimer]

* 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 to Debian and ignored, I'd say that our Social
> Contract _mandates_ us to publish it ("We do not hide problems" - not
> taking any action in _three_years_ is hiding).

It's inaction, not hiding.  Secret bug trackers (which allegedly exist
nowadays) are hiding.

>> But anyway, we are dealing with *bugs*, and we have publicly
>> documented that we won't hide them, so this aspect is probably okay in
>> some twisted way.  I'm not sure if such a move will be well-received
>> in the security community, though.
>
> I don't think any security watchlist has a three-year time limit
> between bug reporting and bug publishing. I may be wrong.

Many of the interesting security issues are never disclosed.  You
shouldn't assume that disclosure is industry standard practice just
because some folks on BUGTRAQ like to play whack-the-vendor.

> This is a valid concern. I would think that the declassification team
> takes this into account. And as you can see from the proposal, we all
> have a veto on the declassification (the list is published first to
> the developers, who can then propose a GR - and I would think that
> valid, strong objections directly to the team would work even without
> a GR).

I cannot grasp how that would work.  Sure, you could publish hashes of
the message in the GR, but this kind of partially secret GR is at odds
with the spirit of the Constitution.


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

Re: General Resolution: Declassification of debian-private list archives

[Florian Weimer]

* 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 following constraints:
>> >
>> > * The Debian Project Leader will delegate one or more volunteers
>> >   to form the debian-private declassification team. 
>> 
>> If I read the constitution correctly, you cannot decide such a thing
>> by GR.
>
> Just for clarity, by "such a thing", you mean "order the DPL to do
> something", right?

Correct.

> First of all, I do think we can, per 4.1.3 (as others have already
> pointed out). However, I don't think that is relevant; "Debian will seek
> to do foo" doesn't mean "Debian will do foo", and "This process will be
> undertaken under the following constraints" means "if done, this is how
> it'll be done". In other words, I don't think it's a violation of the
> text if we eventually end up not doing it.

Ah, I didn't read it this way, but it makes sense.  This means that
the whole thing is basically completely unnecessary because the DPL
could already form a declassification team if he wants.


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

Re: Proposal for *Real* Declassification of debian-private archives

[Florian Weimer]

* 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 first
>> place).
>
> Even if it is a five years old message? I do think security problems
> released 5 years ago are already fixed, or are you talking about
> something else?

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.

But anyway, we are dealing with *bugs*, and we have publicly
documented that we won't hide them, so this aspect is probably okay in
some twisted way.  I'm not sure if such a move will be well-received
in the security community, though.

I also worry about security reports that include personally
identifiable information, trade (business?) secrets or copyrighted
material, which are not really relevant to the bug itself, but were
sent in with the expectation that this was a typical vendor security
contact.  Publishing such things might get Debian into legal trouble,
especially if the publication was not requested by the original
author.


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

Re: Proposal for *Real* Declassification of debian-private archives

[Florian Weimer]

* 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 pointing to this
address?

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 first
place).

(Nowadays, the security mailbox is handled by the Debian security
team, IIRC.)


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

Re: General Resolution: Declassification of debian-private list archives

[Florian Weimer]

* 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 documents and statements"?

It's not the mailing list policy part, it's the mandated delegation by
the DPL.  I suppose a GR can create a declassification team, but a GR
cannot force the DPL to create one by delegation.

So it's a technicality only (unless this is done on purpose to
establish a precedent, which is unlikely).


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

Re: General Resolution: Declassification of debian-private list archives

[Florian Weimer]

* 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 constraints:
>
> * The Debian Project Leader will delegate one or more volunteers
>   to form the debian-private declassification team. 

If I read the constitution correctly, you cannot decide such a thing
by GR.


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

Re: -= PROPOSAL =- Release sarge with amd64

[Florian Weimer]

* 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, no matter how they are
made.

I suppose most the proposers feel the same.  Why they resort to such a
desperate means is something to think about, IMHO.


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

Re: -= PROPOSAL =- Release sarge with amd64

[Florian Weimer]

* 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 of deciding them. 8-)

On the other hand, if we have a communication problem, we better
should resolve that, instead of starting to decide mostly technical
matters in GRs.


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

Re: Analysis of the ballot options

[Florian Weimer]

* 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 classes
>> of non-programs which aren't on the radar at this point probably
>> exist, too.
>
> Nonsense. There is generally nothing to discuss, and where there is,
> it was settled a long time ago.

Where's the settlement with respect to fonts?  And what about
technical vector drawings that have been converted to bitmaps by
upstream?

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


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

Re: Analysis of the ballot options

[Florian Weimer]

* 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 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 classes
of non-programs which aren't on the radar at this point probably
exist, too.

It's extremely shortsighted to think that this is just about
documentation and firmware.

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


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

Re: Proposal G

[Florian Weimer]

* 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
> Florian disagrees with me here).

Just for the record, because opinions sometimes change over time: I
see this particular case as a mere example where we must somehow
balance one goal expressed in the SC against another, conflicting one.
I think it's important to realize that the SC does not automatically
offer a clear-cut answer to every complex question.

Furthermore, I do no longer closely follow developments in
vulnerability handling.  I simply do not know if vendor-sec is playing
into the hands of commercial vulnerability resellers such as CERT/CC /
US-CERT / Internet Security Alliance, OIS, SecurityFocus / Symantec
and so on (those companies who do have a public BTS which incurs a
noticeable publication delay, to protect their business interests more
than their users' interests).

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


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

Re: Proposal G

[Florian Weimer]

* 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
non-free software?

>   That policy violates the SC. You essentially told a delegate
>  to go violate the social contract, and I don't think we can do that.

Ahem, this proposal tries to assure a delegate that his scruples are
unwarranted and that he should go on as previously planned.  After
reading Anthony's comment <[EMAIL PROTECTED]>,
I think this is a non-issue anyway.

>   As it stands, I do not think that this proposal meets the
>  requirements for helping determine the changes in release schedule
>  of sarge in voew of GR 2004_003; therefore I think it may need to go
>  on a separate ballot (since it is there fore a separate issue). I
>  need to think about it more before making an official ruling on
>  this, and I am open to being persuaded either way.

As a whole, I think it's in line.  IMHO, it's not more off target than
proposal E, for example.

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


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

Re: Short descriptions of GR proposals on ballot

[Florian Weimer]

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 point out which proposals
actually achieve this goal.

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

Re: Short descriptions of GR proposals on ballot

[Florian Weimer]

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 point out which proposals
actually achieve this goal.

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


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

Re: Social Contract GR's Affect on sarge

[Florian Weimer]

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 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.

SuSE probably wins on GB, but not on packages.

However, the FreeBSD ports collection beets them all hands-down. 8-/

-- 
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

[Florian Weimer]

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 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.

SuSE probably wins on GB, but not on packages.

However, the FreeBSD ports collection beets them all hands-down. 8-/

-- 
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.


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

Re: Social Contract GR's Affect on sarge

[Florian Weimer]

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 testing.  

An APT module which checks main and non-free packages against a
database is probably completely sufficient.

-- 
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

[Florian Weimer]

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 Contract can do that.  This, of
> course, assumes that people worked on Debian because they were
> interested in technical excellence.
>
> If instead, it turns out there are significant numbers of people who
> believe their participation in Debian is really more about proving
> that they are Holier Than Stallman, those that *are* interested in
> making something useful for their users have their choice of either
> (a) trying to see if they have the votes to shut-out the fanatics, (b)
> try to build something useful that uses Debian as a base, and leaves
> the insanity behind, or (c) join the Fedora project, or some other
> distribution.

The issue is actually more complex because of the non-free section of
the distribution.  The pragmatists will simply use that one.  People
like me who suffer from a mild form of Free Software Extremism are
those who are losing most because they can no longer rely on the way
Debian applies the DFSG to decide which packages can go into main.  It
looks as if they have to make their own decisions in the future.

The current issue is not the issue of main vs. non-free, but a
scrupulous Release Manager.  (But I'm not saying it's his fault if his
principles prevent him from releasing sarge under the current
circumstances.)

-- 
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

[Florian Weimer]

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 testing.  

An APT module which checks main and non-free packages against a
database is probably completely sufficient.

-- 
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.


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

Re: Social Contract GR's Affect on sarge

[Florian Weimer]

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 Contract can do that.  This, of
> course, assumes that people worked on Debian because they were
> interested in technical excellence.
>
> If instead, it turns out there are significant numbers of people who
> believe their participation in Debian is really more about proving
> that they are Holier Than Stallman, those that *are* interested in
> making something useful for their users have their choice of either
> (a) trying to see if they have the votes to shut-out the fanatics, (b)
> try to build something useful that uses Debian as a base, and leaves
> the insanity behind, or (c) join the Fedora project, or some other
> distribution.

The issue is actually more complex because of the non-free section of
the distribution.  The pragmatists will simply use that one.  People
like me who suffer from a mild form of Free Software Extremism are
those who are losing most because they can no longer rely on the way
Debian applies the DFSG to decide which packages can go into main.  It
looks as if they have to make their own decisions in the future.

The current issue is not the issue of main vs. non-free, but a
scrupulous Release Manager.  (But I'm not saying it's his fault if his
principles prevent him from releasing sarge under the current
circumstances.)

-- 
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.


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

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

[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.


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

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

[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

[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:

> "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

[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.


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

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.


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

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

[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]

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]

[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.


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

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.


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

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.


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

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.


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

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.


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