Re: [RFC] Extending project standards to services linked through Vcs-*

[Ian Jackson]

Hi.  Thanks for giving me an excuse for some axe-grinding :-).

David Bremner writes ("Re: [RFC] Extending project standards to services linked 
through Vcs-*"):
> I have a project currently hosted off salsa. I'm willing to have
> read-only mirror, but I'm not willing to put much effort in to it.

Knowing you, I think you probably do your uploads with dgit.  I hope
you find it convenient, but of course there is another advantage:
Your git history is available via "dgit clone".

Unlike the Vcs-Git tree, mirrors on non-free services, etc., the
package contents seen by a user of "dgit clone" is precisely equal to
what is actually in the archive, and therefore actually useable by
someone who isn't a Debian expert.

I wrote more about this in detail in 2021
https://diziet.dreamwidth.org/9556.html

> Maybe someone(TM) should take on the task of mirroring, in some way that
> makes it clear this is not a place to send MRs. In a small way, that
> could be a technical (partial) solution to a social problem. It could
> even be automated based on Vcs-Git urls.

Automatically importing from the archive doesn't get you git history,
of course.  But that's what dgit does.  Currently it does that
client-side: if the maintainer didn't use dgit to upload, it must
import the .dsc, and therefore the user doesn't get the git history.

I'm hoping we can increase the availability of reliable and useable
git histories, by increasing dgit adoption, and, eventually, deploying
tag2upload.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Re: Support for non-free-firmware in project webpages

[Ian Jackson]

Bill Allombert writes ("Re: Support for non-free-firmware in project webpages"):
> The link in the footer points to a page on SALSA with all the informations
> already.

I had indeed found the page you link to.  But, for me it didn't answer
these questions.  Let me lead you through it.

The popcon.debian.org website page footer says:

  [Popularity-contest project] by Avery Pennarun, Bill Allombert and
  Petter Reinholdtsen.

I did indeed follow that link.  It is a link to

  https://salsa.debian.org/popularity-contest-team/popularity-contest

which starts with

  | The popularity-contest package sets up a cron job that will ...

Then there is some general information about what the popcon system is
for.  So, the reader has been told that the are looking at the data
upload client.

The text you then quote is right at the bottom of that README, which
is 137 lines long.  On my screen it does indeed say, on the 4th page:

> ""
> FINDING THE SOURCE
> ==
> 
> This package is being maintained in GIT on salsa.debian.org.
   ^^^
> The project summary page is available from
> https://salsa.debian.org/popularity-contest-team/popularity-contest>
> The project home page is at https://popcon.debian.org/>.

Now we are talking about the *package*.

What will not be obvious to many readers is that:

 * The source code to the live popcon.debian.org *website instance*
   is to be found within this *Debian source package*.

 * Change requests *for the website* should be submitted to the
   *package* in the Debian bug system.

Perhaps it seems obvious to you that the source code for the website
would be in the source package containing the upload client.  But that
is not a universal way of organising things.  Indeed, I think,
nowadays, it is slightly unusual [1].

I think it would be better if the page footer explicitly said where
its own source code was.

Indeed, it ought to tell you *where in the source tree* it is.  Since,
it's in the "examples" directory!  After you told us it was in that
git repo, I looked again, and I did I eventually find the source code
for the website - but only by grepping the git repo for strings that
were displayed in my browser.

Amending the text at the bottom of the README would also be good, but
only helps a reader who is quite determined - a casual reader isn't
going to scroll through and skimread many pages of what they will
probably think is an irrelevant document.

Ian.

[1] I do it myself: src:dgit contains the source code for the
server-side.  But the deployed instance is not running from an
installed copy of dgit-infrastructure..deb.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Re: Support for non-free-firmware in project webpages

[Ian Jackson]

Bill Allombert writes ("Re: Support for non-free-firmware in project webpages"):
> On Fri, Jan 27, 2023 at 11:41:10AM +, Ian Jackson wrote:
> > Would an MR to be more explicit about the precise code location be
> > welcome?
> 
> Actually I prefer bug reports against popularity-contest.

I presume that someone who wants to fix something with the web page
should do so starting with the source code from salsa, though ?
After all, I guess the website probably isn't running off
the .debs from stable ?

> This link used to point to a page hosted on alioth that provided links
> to the package page, BTS page and the alioth source repo.

OK, great, but I'm not sure precisely now what patch I should send -
ie, what ought to be in the page footer.  Since you know the answers,
would you mind arranging that the popcon web pages contain the right
references ?

I think a reader (potential contributor) needs to know:

 * Where to get the source code for the actually deployed instance[1]
 * Where and in what form to send patches (or MRs, as the case may be)

Since in the general case, Debian services are managed by different
people in different ways, the reader won't be able to just guess the
answers to these questions.


[1] I think this means the git history, if the service source code is
maintained in git.

And the arrangements should be such that publication of the source
code for an updated deployment is automatic, rather than depending on
a manual release step (eg, an upload to sid).  If deployment is done
via git, this typically happens for free, since it's easy to make the
deployments happen from a branch which is also public.

If the deployment is done some other way then perhaps the software
should have a "download my own source code" feature.

Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Re: Support for non-free-firmware in project webpages

[Ian Jackson]

Cyril Brulebois writes ("Re: Support for non-free-firmware in project 
webpages"):
> I might have overlooked better contact information, but couldn't find a
> popcon.debian.org to report bugs against, or a repository for the server
> side to file merge requests against.

I looked here:
  https://popcon.debian.org/
and then at the page footer.

It has
  [Popularity-contest project] by Avery Pennarun, Bill Allombert and
  Petter Reinholdtsen. 
where that's a link to
  https://salsa.debian.org/popularity-contest-team/popularity-contest

I think that is where the server side code lives ?  Ie, the code for
generating the charts reports ?  I grepped and found
  examples/bin/popcon.pl
which looks like it might be the right thing.

Would an MR to be more explicit about the precise code location be
welcome?  Soemthing like this perhaps.

  https://salsa.debian.org/popularity-contest-team/popularity-contest; 
> Popularity-contest project  by Avery Pennarun, Bill Allombert and Petter 
Reinholdtsen.
  
+ This page generated by https://salsa.debian.org/popularity-contest-team/popularity-contest/-/blob/master/examples/bin/popcon.pl;>examples/bin/popcon.pl
+ 

Thanks,
Ian.

-- 
Ian JacksonThese opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.

Re: Request to Mini DebConf Montreal Organizers: Fight Israel not the DC20 Team

[Ian Jackson]

Felix Lechner writes ("Re: Request to Mini DebConf Montreal Organizers: Fight 
Israel not the DC20 Team"):
> Hi Ian,
> 
> On Thu, Feb 20, 2020 at 3:50 AM Ian Jackson
>  wrote:
> >
> > The BDS movement is not antisemitic.
> 
> Please have a look at this report, especially the final page.
> http://bit.ly/TheNewAnti-SemitesReport

I started to look at this but it is seems to be based primarily on the
conflation of Israel with Jews.  (See my discussion headed "double
standards" in my article below.)

Also it relies on the IHRA definition of anti-semitism which I reject.
I wrote a lengthy analysis of it in uk.legal.moderated when the UK
Labour party were being criticised for not adopting it.

But my main point is this: Ansgar asserted that it is uncontroversial
that the BDS movement is antisemitic.  Obviously that was not true.
If it were true then the Montreal team's message would be a CoC
problem.

Ian.

Newsgroups: uk.legal.moderated
Message-ID: 
References: <2h1jmdpd669ubv0er3akcks8k0inpj5...@4ax.com> 
 
NNTP-Posting-Host: chiark.greenend.org.uk
NNTP-Posting-Date: Mon, 13 Aug 2018 13:27:56 +0000 (UTC)
From: ijack...@chiark.greenend.org.uk (Ian Jackson)
Subject: Re: Labour - anti-semitism
Date: 13 Aug 2018 14:27:52 +0100 (BST)

In article ,
The Todal   wrote:
>This ought to be a good forum in which to debate the wording. It's what 
>lawyers do, debate wordings.
>
>The original IHRA definition and examples:
>https://www.holocaustremembrance.com/working-definition-antisemitism
>
>The Labour Party NEC antisemitism policy:
>https://www.jewishvoiceforlabour.org.uk/app/uploads/2018/07/ASdoc3.pdf

Thanks for this prompt.  I haven't read the rest of the thread.

I'm starting by reading the Labour document.


I'm slightly concerned by the reference in para 7 to the ECHR freedom
of expression principles.  There is much conduct that a political
party might want to prohibit in its members, which the mandatory and
universal force of the public law ought to tolerate.

Relatedly (perhaps, conversely) I'm concerned by its narrow focus on
tone.  As a part of the Left, the Labour party should be alert to the
difficulties of policing the tone used by the oppressed.  (IMO This
applies here both to the tone used by Israel's critics to criticise
Israel, and the tone used by Jews and their allies to criticise
antisemitism.)

However, perhaps that doesn't matter because in the examples in para
9, they do give many examples of antisemitism that relate to substance
rather than tone.

Paragraphs 10-15 are impressive.


Paragraph 16 rather fudges the question of comparing Isreal to the
Nazis.  This is a very contentious issue.  Having spoken to many of my
friends about this, the majority feeling seems to be that such
comparisons are inherently antisemitic and must be avoided.

I think this is going too far.  Nazi comparisons are a staple way of
characterising things as evil, in our culture.  (Hence Godwin's law,
now suspended by Godwin of course.)  I think it's unfair and
unreasonable to insist that Israel should get an immunity from many of
the most effective shorthand criticisms of some of its actions.


Now I turn to the IHRA document.  It's not clear to me what portion of
the IHRA web page you link to was agreed by the Plenary.  The list of
examples is not in the quote box.  The Labour document says of the
text on the IHRA web page:
 | The publication of the IHRA definition was accompanied by a
 | series of examples to guide IHRA in its intergovernmental work.

So is the web page even authoritative as a formally and firmly agreed
statement of the opinion of the IHRA ?  I doubt it.  That suggests to
me that it's being asked by critics of Labour to bear rather too much
weight.

But supposing it is authoritative, or at least relevantly interesting,
let us compare it to the Labour party document.


There is a lot in the Labour document that is not in the IHRA page.

In particular paragraph 10 of the Labour document makes a very
important point which captures a lot of -ist behaviour.  Paragraph 15
identifies and prohibits the `zio-' prefix, and generally prohibits
using Zionist to mean Jew.  Paragraph 14 deals with antisemitistic
requirements that Jews condemn Israel, more than anyone else should.
These are important additions which I expect anti-antisemitists will
applaud.

Paragraphs 7, 8, 11-13 and the rest of 14 and 15, provide a much
fuller discussion of the context, and will be much more helpful with
the difficulties that someone may face if they are trying to make a
judgement about someone's words or conduct.


The real dispute is surely about simply the lists of examples.

The IHRA definition doesn't number them but I will call them
(1)-(11).  That allows me to conveniently also refer to the Labour
document's examples (a)-(g) and its paragraphs as 1-16.

(1)-(5) = (a)-(e).

(6) ("loyal") is the last paragraph of 14.  I can see w

Re: Request to Mini DebConf Montreal Organizers: Fight Israel not the DC20 Team

[Ian Jackson]

Ansgar writes ("Re: Request to Mini DebConf Montreal Organizers: Fight Israel 
not the DC20 Team"):
> I think the announcement by the organizers framed the conference as
> being organized specifically to support the BDS movement, a movement
> that is uncontroversially seen as antisemitic.  They could have chosen
> not to frame the announcement this way, but they did not.

The BDS movement is not antisemitic.

Ian.

Re: Using Debian funds to support a gcc development task

[Ian Jackson]

Tollef Fog Heen writes ("Re: Using Debian funds to support a gcc development 
task"):
> Ian Jackson:
> > Such a small, essentially honorary, contribution wouldn't distort our
> > volunteer setup, and don't need the levels of serious review and
> > engagement that a larger amount does.  But it would act as a tangible
> > way to express that we would like to see something done and might
> > encourage others.
> 
> For me, it's not about the amount at all, but rather that we don't spend
> Debian money on directly paying people or use Debian money as carrots
> for directing effort.

Yes, I understand that.  I think a small amount like $100 or so
doesn't raise the same problems - it's too small to be a significant
carrot, and it seems more of a token/gesture than actually "paying
people".

But I guess from your mail that you see it differently.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Using Debian funds to support a gcc development task

[Ian Jackson]

Charles Plessy writes ("Re: Using Debian funds to support a gcc development 
task"):
> given the reminders that Debian refrains from paying developers for
> their time, I wonder if it would still be possible to make a small
> contribution that expresses Debian's interest and sympathy to your goal,
> with the hope that our name will help the crowdfunding effort.
> Something on a scale that would allow us to answer positively to similar
> requests without putting a significant burden on our finances... Maybe
> $100 ?  This is the same amount as what Debian is willing to reimburse
> for travel costs to bug-squashing parties, for instance.

I think this would be a good idea.  (And I speak as one of the
strongest opponents of Dunc-Tank.)

Such a small, essentially honorary, contribution wouldn't distort our
volunteer setup, and don't need the levels of serious review and
engagement that a larger amount does.  But it would act as a tangible
way to express that we would like to see something done and might
encourage others.

We could afford to make at least dozens of such honorary contributions
a year.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Using Debian funds to support a gcc development task

[Ian Jackson]

Paul Wise writes ("Re: Using Debian funds to support a gcc development task"):
> To be clear, I think the work that folks are doing on the unofficial
> Debian ports is valuable and important and that the m68k GCC task is a
> good idea. I only dislike using Debian funds to pay people for their
> time. I think that crowdfunding the m68k GCC task could work.

I absolutely agree with this.

John, please let us know if you (or someone else) tries to do this
via crowdfunding.  I promise to contribute.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Debian and Non-Free Services

[Ian Jackson]

Sam Hartman writes ("Debian and Non-Free Services"):
> I'm trying to move a thread from -devel.
> 
> Ian Jackson responded [1] to part of a consensus discussion on Git
>   recommendations.  I had said that I think we recommend against the use
>   of non-free services like Github but do not forbid their use.
>   Ian disagreed with this recommendation.

Sam, from this thread, it seems very likely[1] that you were right
about where Debian's consensus was, and that I was wrong.

> He proposed the following text for such a GR.

Also Enrico Zini sent a couple of messages where he strongly objected
to this escalation by me.  IME Enrico Zini is usually right.  I should
have listened to him more carefully the first time.

For my own part, I'm going to drop this suggestion now.  I still don't
agree with the apparent project consensus but I want to spend my
energy on something more constructive.

Ian.

[1] Even allowing for the fact that mailing list threads are not a
 very reliable way to judge the project's overall views.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Intent to Delegate: Delegation Advisory Group

[Ian Jackson]

Holger Levsen writes ("Re: Intent to Delegate: Delegation Advisory Group"):
> On Thu, Aug 29, 2019 at 12:22:35PM +0100, Ian Jackson wrote:
> > I'm not sure why you think this isn't a thing that can be delegated ?
> 
> mostly because it's very unusual, usually delegations are about the
> powers defined in in 5.1.4 ("Make any decision for whom noone else has
> responsibility.") and not about the powers defined in 5.1.X where X!=4.

Right, that's very true.

In this case I think this is a good expansion of current practice.
I think DPLs should make much more use of delegation so I think
that Sam's proposal here is a step in the right direction.

Also I'm happy with the proposed list of people.

Regards,
Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Intent to Delegate: Delegation Advisory Group

[Ian Jackson]

Holger Levsen writes ("Re: Intent to Delegate: Delegation Advisory Group"):
> On Wed, Aug 28, 2019 at 11:47:44AM -0400, Sam Hartman wrote:
> > Task Description
> > 
> [...] 
> > The group is delegated the power to introduce or amend a general resolution
> > overriding a delegation that the DPL makes without requiring other
> > developers to second the resolution.
>  
> I'm not sure our constituion allows this.

  8.1 The Project Leader's Delegates:
  (1) have powers delegated to them by the Project Leader;

The implication of "delegate" is that these are powers of the DPL.
Looking at powers of the DPL:

  5 Project Leader
  5.1 Powers
  (5) Propose draft General Resolutions and amendments.

I'm not sure why you think this isn't a thing that can be delegated ?

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Found USB stick

[Ian Jackson]

James Robson writes ("Found USB stick"):
> I found a lime green Sandisk USB in Edinburgh with a ton of your files, 
> logos, etc. This seems important to your project and I’m just looking to get 
> it back to its owner if you can help?

I think you have probably found a USB stick onto which someone put a
Debian installer image.  Ie the contents of the stick are a public
download, provided by our project.

If I am right then you are not going to get anywhere very useful with
this line of enquiry.  Hand the stick in to lost property, or keep it.

Regards,
Ian.

(I am assuming this is not a new form of scam email.  I haven't seen
one like this so I'm giving it the benefit of the doubt.  James, if
this is genuine, thanks for your efforts and sorry to be so
suspicious.)

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Upstream metadata to help our users contribute back to projects we redistribute. [and 1 more messages]

[Ian Jackson]

Paul Wise writes ("Re: Upstream metadata to help our users contribute back to 
projects we redistribute."):
> https://wiki.debian.org/UpstreamMetadata

Alex Muntada writes ("Re: Upstream metadata to help our users contribute back 
to projects we redistribute."):
> We use debian/upstream/metadata in the Perl team to easily
> obtain the CPAN distribution name and the bug tracker URL,
> so we can forward patches to CPAN RT or GitHub or mail them
> to the upstream authors:
> 
> https://manpages.debian.org/unstable/pkg-perl-tools/dpt-forward.1.en.html

Thanks for these links etc.

I have bounced them to the Debian bug where I requested that dgit do
something useful with this information.

Ian.

Bug#934062: Upstream metadata to help our users contribute back to projects we redistribute.

[Ian Jackson]

Package: dgit
Version: 9.0

Felipe Sateler writes ("Re: Upstream metadata to help our users contribute back 
to projects we redistribute."):
> On Thu, 25 Jul 2019 16:26:02 +0200, Xavier wrote:
> > pkg-js-tools embeds a tool that generates debian/upstream/metadata for
> > Github repositories (github-missing-upstream).
> 
> Thanks, this is useful. It's named github-debian-upstream though ;)
> 
> > dpt from pkg-perl-tools uses this file to link locally upstream repo in
> > "git remote"
> 
> This sounds cool too. Sounds more useful than for just perl packages.

Yes.  I think "dgit clone" should set up a remote for this
automatically.  (The information is useful for a lot more than
contributing back: having the upstream git history, where it can be
found, is often useful for bugfixing, etc.)

What does pkg-perl-tools call this remote ?  dgit and pkg-perl-tools
should agree.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: anti-tarball clause and GPL

[Ian Jackson]

Simon McVittie writes ("Re: anti-tarball clause and GPL"):
> Are you asking this hypothetically, or is there a piece of software that
> someone intends to apply this to?

There are existing packages for which I consider the PFM to include
the git history.  I'm not pressing this point from a legal point of
view because, well, that just generates lots of heat and no light.

I think that we should address this potential problem by arranging to
give to the history to our users and downstreams.  There are lots of
other really good reasons to do this.

(ISTM that whether the PFM needs the upstream vcs history or not is a
question of fact which depends strongly on the context, how the thing
is developed, etc.  I don't think a GPL rider like the one quoted
earlier is definitive either way - it's a statement of the author's
opinion and perhaps implies something about their practices.)

> Redistributing the entire history of a third-party project is practically
> problematic because it is no longer enough to check that there is nothing
> you don't want to distribute (e.g. non-free software) in the HEAD commit:

This boat already sailed a long time ago.  Via alioth and now salsa,
and via the dgit git server, we are in many cases distributing that
complete history already.

> For established projects, the complete history is also inconveniently
> large: my git clone of glib2.0 has a 57M .git, which compares poorly
> with a 4.5M source tarball (and glib2.0 isn't even particularly big or
> old by the standards of projects like glibc and the Linux kernel).

Right.  Bundling up git histories in tarballs is not a really sensible
way to carry on (unless trying to make a source CD for offline use or
something).  Better to just have a git server, since then you only
need to keep one copy of the history, and in many cases clients can
only transfer updates.

> We have to draw a line somewhere. You could equally well say the software's
> bug tracking system and mailing lists, which also store human-readable
> comments, are part of the preferred form for modification - but those
> don't normally have any copyright license granted (I certainly didn't
> put this email under a copyright license!) so they are non-free.

So that interpretation of the PFM is not compatible with upstream's
practices.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Cultural differences and how to handle them

[Ian Jackson]

Martina Ferrari writes ("Re: Cultural differences and how to handle them"):
> Ian, Norbert observation seems to be true. While you have highlighted
> problematic behaviour in many cases, it does seem to be the case that
> you are using non-blind CCs to AH as a way to put extra pressure on
> people you disagree with.

That was not my intention, but now that you point it out, I can see
that this is an obvious effect/interpretation.

> Please, don't do that unless absolutely
> necessary, you can always BCC.

I will try to follow your advice, sorry.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Cultural differences and how to handle them

[Ian Jackson]

Adam Borowski writes ("Re: Cultural differences and how to handle them"):
> On Tue, Jul 02, 2019 at 11:21:03PM +0300, Adrian Bunk wrote:
> > People in the US are used to minority quotas in various places.
> > 
> > In most European countries it would be considered unacceptable racism
> > if skin color would play any role in university admission.
> [...]
> > Children in the US grow up learning that they are living in the greatest 
> > country in the world, an example for the world.
> > 
> > Children in Germany grow up learning that "I am proud of being German"
> > is an unacceptable antisemitic expression, nearly synonymous to
> > "I am proud of the holocaust".
> [...]
> 
> This.  This and the rest of your post.
> You nailed it.

I think this is compete nonsense.

1. Those of us who are in favour of promoting diversity this way
include Russ and Colin and me and numerous other people from whatever
side of the Atlantic and elsewhere.

2. The stuff about Germany and the Nazis, wtf ?  Is this some kind of
crazy alt-right dogwhistle ?  It has no relevance here.

3. What you say about positive discrimination is simply untrue in at
least the UK.  See for example Equality Act 2010 Part II Chapter 2,
"Positive action".

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: paying people for Debian work (Re: Why do we take so long to realise good ideas

[Ian Jackson]

Sam Hartman writes ("Re: paying people for Debian work (Re: Why do we take so 
long to realise good ideas"):
> Moving this subthread to -project too.
> 
> Holger> But there's one significant difference between LTS and dunc
> Holger> tank: dunc tank was ment as an initiative inside Debian,
> Holger> while LTS is carefully set up on both sides, in- and outside
> Holger> Debian, and the money part of it is *completly* handled
> Holger> outside Debian, and I very much like this and I consider
> Holger> this a main reason why LTS is accepted by the Debian
> Holger> community.
> 
> Is it true that dunc tank was an initiative inside Debian?
> When I go back and read Joerg's mail to debian-devel-announce
> summarizing the concerns with Dunc Tank, it sounds like it was outside
> Debian possibly sharing some of the same people running it.

I think it is probably not helpful to go into these kind of details
now but since you raise the point I feel I must respond.  Whether
Dunc-Tank was a Debian initiative was precisely one of the seriously
contested points.

Dunc-Tank was presented as an initiative which was outside Debian, in
the sense that it was (for example) outside the purview of a GR.
However it was an initiative of the person who was currently the DPL,
and their deputy, and would have involved paying Debian core team
members for their role within Debian.

It seems to that it was not something that would have been possible
for someone without very significant standing in the project; possibly
it was only possible for the DPL.

Frankly, the idea that it was not an initiative of the DPL seems to me
to have been an artificial distinction, contrived to allow it to go
ahead without oversight from the rest of the Debian project.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Question for Planet Admins: What Should I do if another Developer Removes my Blog

[Ian Jackson]

Sam Hartman writes ("Question for Planet Admins: What Should I do if another 
Developer Removes my Blog"):
> Imagine that I get a note from a random developer saying they have
> removed my blog from planet.  I understand what they are saying enough
> to believe it is not vandalism; they honestly believe I did something
> wrong.  I can't understand from their message how they hope I'd fix it.
> 
> I cannot engage with them in what I think is a timely manner.
> 
> They copied the planet admins who have not gotten involved in the
> conversation.
> 
> What should I do?

Does the answer to this question depend very much on whether it's
Planet that's the territory for the revert war ?

ISTM that the same can be true of bugs.d.o at the very least, and
salsa, and, in principle, even the archive.  In theory there is
supposed to be a maintainer to decide, but the maintainer may be away
or simply not responding, or the package may be QA maintained, or
whatever.

I suppose you are asking the Planet admins and they won't necessarily
have an answer.  But maybe owner@bugs or d-release or ftpmaster may
want to say how they think these things should be dealt with in their
areas of responsibility (specifically, before or in the absence of a
specific authoritative answer from that team on the issue in
question).  That might be illuminating.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: metaphors and feminism

[Ian Jackson]

Sam Hartman writes ("Re: metaphors and feminism"):
> I always assumed debian member was a term that included developer and
> maintainer.
> I'm all for Debian member replacing developer, but if so, I'd like a
> term that encompasses maintainer and developer.

There are at least the following statuses/roles:

 1. "Debian Developer" as per the constitution.
 2. "DM" aka "Debian Maintainer", ie someone in the DM keyring
 3. "Maintainer:" or "Uploader:" in some source package
 4. Other contributors

You can vote in GRs and DPL elections if you are 1.
You become 1 by going through the NM process, which is supposed to
guage your technical and nontechnical suitability.

You can upload a particular package without needing sponsorship if you
are 1; or are 2, and also 3 for the package in question.
You usually become 2 by demonstrating a track record of good
contributions in role 3.

You may make management decisions[*] with respect to a particular
package if you are 3; you are also then primarily responsible for
preparing new versions, although you need a sponsor to upload them
unless you are 1 or 2 as well.


Your comment was ambiguous as to what you meant by `maintainer': did
you mean 2 or 3 ?

I think Paul has been using `member' to mean only 1.  I think that is
appropriate: `member' is then highest status that is not membership of
some special group.

3 is usually called `maintainer'.  `Maintainer' is actually right for
this role: it refers to the responsibility and authority for package.
So we need a different term for 2.

Lots of organisations use `associate'.  And 2 are specially
authorised.  Hence my suggestions of
  Authorised/Approved Debian Maintainer
  Associate Debian Member

I think the former is better because the status 2 implies only a
technical authority, not a sociopolitical authority.


Thanks,
Ian.


[*] By `management decisions' I mean, for example: giving go-ahead for
an NMU; approving/disapproving proposed patches; deciding what VCS and
packaging workflow should be used; helping choose other members of the
package team; filing a removal request; deciding on a bug severity;
negotiating with those handling other packages.  If there are others
listed as Maintainer/Uploader then these decisions are collective.
And most are subject to possible review by eg release or ftp team,
etc.  But, this is the most usual kind of authority in Debian and it
is not gatekept by any kind of access control mechanism; rather like
any management decision, it is a kind of authority honoured by humans
rather than computers.


-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: metaphors and feminism

[Ian Jackson]

Paul Wise writes ("Re: metaphors and feminism"):
> Personally I think the phrase "Debian Developer" and the abbreviation
> DD is a relic of an earlier era when the set of tasks available to
> Debian contributors were more technical and less varied.

As the person perhaps most responsible for the choice of the word
`Developer' I think your explanation is very ... charitable.  It is
certainly clear to at least me that it is the wrong word.

> I try to use "Debian member" in mails since it is clearer what that
> means to a larger set of people and I'd like to see Debian culture
> (and perhaps the official documents) move towards that too.

I see other people doing this too.  I like it.

The problem of course is that the official term is not "member" so
this is unclear and arguably wrong in some sense.  It should be.  I
would second a GR to change it.

There is also a problem with acronyms.  Debian Member => "DM" but we
already have "Debian Maintainers".  I think it would be best to rename
Debian Maintainers too.  Particularly since you can be a maintainer of
a package in Debian without having your key in the Debian Maintainers'
keyring, so this term is very confusing.

ADM = "Authorised Debian Maintainers" or "Assistant/Associate Debian
Members" or something maybe ?

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Call for experiences

[Ian Jackson]

Ian Jackson writes ("Call for experiences of Norbert Preining"):
> Very regrettably, [...]

Several people whose opinions I hold in high regard have told me that
this was a seriously bad idea.  On an official level, I received a
complaint from listmaster.

So, I'm sorry.  I failed to anticipate how badly people would see
this; no doubt it unhelpfully contributed to the toxic atmosphere.

So, I withdraw my previous message.  Please don't reply to it any
further.  Thanks also to those who took the time and energy to write
to rebuke me.

Sorry,
Ian.
(*sigh*)

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Call for experiences of Norbert Preining

[Ian Jackson]

Very regrettably, it may become necessary to produce a fuller list of
incidents, including responses, to justify the recent DAM decision.

Please search your communications archives.  If you have had an
adverse experience of any kind with Norbert Preining, in public or in
private, please email me.

Please:
 * Summarise each incident, but:
 * Then give as much additional detail as you like.
 * Give URLs where possible.
 * If there was a complaint (to Norbert or to anyone else),
   say what the reponse/result of that was.
 * Say whether I may include your name in my collation.
 * Use `Call for experiences of Norbert Preining' as your Subject
   line.

I will summarise and collate these reports.  I will *only* share this
information if there is a Debian GR which would have the effect of
reinstating Norbert.  If there is such a GR, I will share the
collation publicly.

(If the Constitution is amended to permit the GR to be held in private
within Debian, I will share it only there.)

If it becomes necessary to make the collation public I may do so via a
web page or as an email, as seems convenient to me.  In January 2021
and every three years thereafter I will review whether retention of
the provided information is still necessary, and if I consider it not
any longer to be necessary, I will delete it.

Ian.

If you have difficulty emailing me because of my spamfilter, send the
bounce to postmaster@chiark, or talk to Diziet on oftc or freenode.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Appeal procedure for DAM actions

[Ian Jackson]

Joerg Jaspert writes ("Re: Appeal procedure for DAM actions"):
> On 15276 March 1977, Karsten Merker wrote:
> > Therefore the clause "If more than half of the NMC (excluding DAM) abstain
> > or do not vote, the decision is not overturned" would IMHO need to be
> > removed completely from the rules.
...
> So while I agree there might be possible improvements in how the
> vote goes, I don't think just deleting that one sentence is it. But
> I'm not an expert in voting systems, so am happy for any
> input. Could go with a quorum (and then count abstains for it) and
> requiring a (3 quarter?) majority of voters?! Could go with
> something else? Somebody come up with a nice thing, please. :)

I'll bit.  Having some kind of quorum requirement is a good idea.

Yours is not ideal because it is non-monotonic.  Specifically, the
sometimes best way to defeat something would be to simply not vote, so
that the 50% quorum is not reached.

I suggest instead that you say that the decision is not overturned
unless supported by (i) at least sqrt() of the eligible voters
(ii) strictly more than 50% of the people voting.

sqrt is a good function here because it adjust the quorum proportion
according to the voting pool.  If for some reason only a small number
of people are available/eligible, the quorum is most of them.
Currently you say there are 17 so a revocation decision would have to
be supported by at least ~4.123 people, ie (since supporters only come
in whole numbers) at least 5.  That is close to the implied 25% of
your proposal.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Censorship in Debian

[Ian Jackson]

Miles Fidelman writes ("Re: Censorship in Debian"):
> Thanks!  It's actually high on my list.  I've been waiting for it to 
> mature just a bit, and it seems to have.  Any observations on how it 
> stacks up for a production server?  Anything else that strikes you as a 
> particularly strong Debian alternative for servers?

I'm not running it myself.  All I've done is had (positive)
interations with Devuan developers and looked and (and borrowed) some
of their source code.  So I'm afraid you'll have to evaluate that for
yourself.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Censorship in Debian

[Ian Jackson]

Miles Fidelman writes ("Re: Censorship in Debian"):
> I've basically been nursing a couple of aging systems.  When next I do a 
> major upgrade to our server farm, It will be to something other than 
> Debian.  Until then, the pressure hasn't been there, and I've been - 
> I've been waiting and watching to see how different alternatives mature 
> (along with what direction several key server-side applications, on 
> which we depend, go).

I would have been very surprised if you had told me 6 months ago that
I would be writing this, but:

Please consider Devuan as an alternative.  You have probably seen
awful mails from one or two very toxic trolls pushing Devuan, but the
actual Devuan developers I have dealt with have been lovely, and on a
technical level they seem to be doing good work.

Regards,
Ian.

Re: Censorship in Debian

[Ian Jackson]

Martin Steigerwald writes ("Re: Censorship in Debian"):
> Ian Jackson - 05.01.19, 18:17:
> > Very competently toxic people will calculate precisely what they can
> > get away with: they will ride roughshod over weak victims or in
> > situations with less visibility; when challenged by an authority who
> > can impose consequences, they will lie and obfuscate and distract as
> > much as they can get away with.  They will turn the dispute about
> > their personal bad behaviour into a big poltical fight so as to
> > increase the cost of enforcing the rules against them.  And if that
> > fails they will do precisely as much as is needed to avoid further
> > punishment.
> 
> Have you actually really seen such kind of behavior?

Yes.

> I disagree with calling people toxic.

Well, I don't want to name names, of course.  But it hardly seems
controversial that toxic people exist ?  We have maybe 1000-10,000
active contributors.

So, making for a moment the assumption that there is no correlation
either way with someone's toxicity and being a Debian contributor, we
should expect our community to have between 1 and 10 people who are
more toxic/abrasive/dishonest/whatever than 99.9% of the population.

We can make a much nicer community by applying a gatekeeping
function...

> Also I am not sure how you'd come to know about about any agenda behind 
> the behavior. How do you know about the intentions?

It is not actually necessary to infer intention.  Since it is not
necessary, in order to take action, to prove that bad behaviour is
malicious.

Rather, it is sufficient to observe that continuation of the behaviour
is harmful, and that lesser efforts to stop it have failed.


But, it is useful to understand intentions because they can be
predictive.  This is true even for intentions inferred from past
behaviour (which is the only way you will ever discover the real
intention of someone dishonest, obviously):

> One part of the code of conduct as I got it is to assume good 
> intentions, here, if I got you correctly you assume bad, harmful 
> intentions for at least some people, people that you call toxic.

No, I am not assuming bad behaviour.  My first assumption if I see an
abrasive message is that the person is having a bad day.  My first
assumption if I see someone stating a falsehood is that they are
mistaken.

These assumptions can, however, be overcome by evidence.

In particular, things like: refusal to acknowledge error or apologise;
use of sophistry of various kinds; escalation in response to every
criticism; making mutually inconsistent statements or repeating
falsehoods already debunked; significantly worse behaviour to weaker
victims or in less auditable scenarios.  Recurrence of the above.

> For me, any code of conduct and its enforcement needs to be based on 
> actual behavior, never on assuming intentions or assuming about how 
> people are.

Once again, there is a difference between *assuming* and *inferring*.

I doubt this will really convince you.  But I couldn't let stand the
claim that I am *assuming* bad intentions.  I most certainly am not.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Censorship in Debian

[Ian Jackson]

Anthony Towns writes ("Re: Censorship in Debian"):
> On Fri, Jan 04, 2019 at 10:47:05AM -0800, Russ Allbery wrote:
> > People seem to feel they're unreasonably put-upon by having to think about
> > what they're saying *at all*, but this is absurd.  Everyone else in the
> > world is doing this all the time.
> 
> There are times when you don't have to think about what you're saying
> before you say it; that situation is often called being "among friends",
> or "in a safe space", or "able to let your guard down".
> 
> I think it's probably news to a lot of people that Debian isn't that
> sort of a situation today.

Yes.  I think you have put your finger on it.

For a significant minority of Debian's contributors - including me -
Debian definitely used to be a place where we didn't have to think
about what we were saying.


The effects of that unbridled expression on other (potential) members
of the community was not something we thought about much.  But, at
least speaking for myself:

I have been hearing from a lot of people whose participation I care
about - often, people who already have lots of shit to deal with in
wider society.  Those people are saying that it would really help them
to have spaces like Debian have a nicer atmosphere, so that there is
less risk of being harshly criticised and where having a thick skin,
and plenty of emotional resilience, is not so necessary.

So I have been (haltingly) trying to improve my own behaviour.  Yes,
that's work.  Being pleasant to people whose ideas I consider
seriously wrong does not come naturally to me.  Sometimes, I fail.
But now that I and others in Debian are making this effort, I can see
the benefits - on both small and large scale.


But it's not enough for just those of us who have been convinced of
the value of this change, to try to make that change personally and to
help each other.

Unfortunately in a community of thousands there will inevitably be
some people who will continue to do what is harmful, but easy and
convenient and fun for themselves, and who will - at least initially
- reject suggestions that they too may need to think hard about how
their behaviour affects others people (and particular, how it affects
people who are not like themselves).

It is indeed natural for people to resent it, when previously they
could do what they liked, but now they are being being asked to
think about and moderate what they say and do,

So without some kind of consequences, unfortunate behaviour will
continue.  It is in fact very natural human behaviour to push
boundaries like that.  Even very agreeable people will sometimes
misbehave to the point of being mildly told off.

Very competently toxic people will calculate precisely what they can
get away with: they will ride roughshod over weak victims or in
situations with less visibility; when challenged by an authority who
can impose consequences, they will lie and obfuscate and distract as
much as they can get away with.  They will turn the dispute about
their personal bad behaviour into a big poltical fight so as to
increase the cost of enforcing the rules against them.  And if that
fails they will do precisely as much as is needed to avoid further
punishment.


Maybe even such a person could provide a net positive contribution,
but only by the community maintaining a constant threat of punishment.
(At least for many years, until perhaps their personal growth changes
the situation.)  That is exhausting for the moderators who are
responsible for policing the offender.

Particularly, patterns of lying, selective compliance, and so on, make
that job very hard, especially if the moderators are subject to
oversight by a body of largely naive and detached people who are
unfamiliar with how toxic people operate generally, and who cannot
fully and properly analyse every reported incident.

Perhaps it is better for the world as a whole for such a person to be
given the very serious shock of being permanently ejected.  That will
teach them that trying to constantly play the exact line (of getting
away with things) does carry a serious risk of serious consequence.
Maybe the next community they get involved with will find them a more
positive influence, and easier to deal with.  And at least the
community they were ejected from is spared the work of educating
(and fighting) the unwilling.


Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Planet Debian revisions [and 1 more messages]

[Ian Jackson]

Ulrike Uhlig writes ("Re: Planet Debian revisions"):
> Please, no. A commit message ensures that everybody is aware of the
> removal reason, including planet admins. Resorting to email? I don't
> think emails are encoded in the feeds and we cannot reasonably expect
> people to search for them...

I agree that some kind of publication of the reason is a good thing.

However:

Sean Whitton writes ("Re: Planet Debian revisions"):
> I'm afraid I don't follow.  I wanted to keep details out of commit
> messages because of the fact that commit messages are a permanent
> record.  How does contacting the planet admin team solve this?

I very strongly agree with Sean that we should not immemorialise such
things in commit messages.

Years later someone who did some bad things when they were much
younger might reasonably come to us and say "can you please redact
that unfortunate incident from your public web page - it's ancient
history now".  We should be able to honour such a request without
using git-filter-branch.

Surely we can find a way to make this information transparent in a way
that makes it easier to expire it ?  Even a dedicated mailing list
would be better since it would let us expire the archives.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: On Mediation and Warnings

[Ian Jackson]

Norbert Preining writes ("On Mediation and Warnings"):
> What I want to make clear that I have received in total
>   5 (five)
> personal messages from DPL/DAM/AH Teams:

You are implying (while carefully avoiding saying it directly) that
until the DAM decision, you didn't know that many people have been
finding many of your messages unnecessarily abrasive.

That is dishonest of you.


I searched my own private mail records for 2017-2018 and I found:

1. In December 2017, you wrote this [1] on the TC list:

  | I have been "moderated" by [listmaster] (AFAIR) in the same
  | way, with implicit threats using the CoC.  Don't play the "I
  | haven't said anything directly" game.  This *is* moderation,
  | even if you don't see it like that.

   I haven't looked deeper to see what if you explained what prompted
   a listmaster to remind you informally of the CoC.  But I am
   confident that I would concur with listmaster's judgement.

2. In October 2017 you wrote very harshly about someone who you
   thought might be MIA.  You were publicly called out about your
   tone by Ulrike Uhlig [2].  I wrote you a private email with
   a similar complaint.  You replied to me:

  | And I [wasn't] aggressive, I stated facts, even if they are
  | harsh. Facts are verifiable and this [is] not aggressive.

   Obviously I didn't agree, but I didn't escalate it because I lacked
   confidence that anything useful would come of a complaint.


It is dishonest of you to give people the impression that you had no
idea that your behaviour was falling foul of the Code of Conduct.

You have been complaining for a long time that the CoC is making you
into a victim of unjustifiable threats.  But now that the threats have
been actually implemented, you play naive and pretend they never
existed.


I note that your careful phrasing in your message just now talks only
about the DPL/DAM/AH teams.  It does not, for example, include our IRC
operators or owner@bugs etc. - nor listmaster, who by your own words
evidently sent you something you considered a warning ("threat").

Nor does it include messages like mine and Ulrike Uhlig's, sent in a
purely personal capacity.


I have no doubt that DAM were aware of the incident (2) above even
though it wasn't included in their list of examples of your poor
behaviour.

I also have no doubt that if other contributors search their personal
email archives they will find similar complaints from themselves and
others, which no doubt in each case you decided you did not agree
with.

Ultimately, since you will not accept feedback, action had to taken to
stop you harming the wellbeing of the rest of the project.

Since unfortunately our listmasters do not act on bad behaviour, your
aggression was allowed to continue until it reached a point where
AH/DAM decided to expel you.


Ian.

[1] https://lists.debian.org/debian-ctte/2017/12/msg00025.html
[2] https://lists.debian.org/debian-devel/2017/10/msg00438.html

Re: Support WKD (and WKS) for @debian.org email addresses?

[Ian Jackson]

Guilhem Moulin writes ("Re: Support WKD (and WKS) for @debian.org email 
addresses?"):
> On Wed, 07 Nov 2018 at 18:20:16 +, Ian Jackson wrote:
> > Personally I think the hash is bizarre.  Why make this protocol depend
> > on an obsolete hash function ?  One could just url-encode the email
> > address.  The server could deal with case-folding etc.
> 
> Dunno if you'll find the arguments convincing, but FWIW this was brought up to
> gnupg-devel in May 2016: see 
> https://lists.gnupg.org/pipermail/gnupg-devel/2016-May/031068.html
> and follow-ups in that thread.

Huh.

Well, I followed the breadcrumbs to the spec and found an Internet
Draft.  So I decided that the IETF's openpgp list was the right place
to make my comments.

https://www.ietf.org/mail-archive/web/openpgp/current/msg09100.html

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Support WKD (and WKS) for @debian.org email addresses?

[Ian Jackson]

W. Martin Borgert writes ("Support WKD (and WKS) for @debian.org email 
addresses?"):
> One way to help senders getting the real receivers key is WKD (web key
> directory). That is one HTTPS URL per email address, e.g. a static
> directory with PGP key files. (See https://wiki.gnupg.org/WKD)

This is still an unapproved Internet Draft.  So the protocol may yet
change.

Personally I think the hash is bizarre.  Why make this protocol depend
on an obsolete hash function ?  One could just url-encode the email
address.  The server could deal with case-folding etc.

Ian.

Re: Bits from the Debian Anti-harassment team

[Ian Jackson]

Laura Arjona Reina writes ("Bits from the Debian Anti-harassment team"):
> In order to help the Debian community understand the community health
> and status of the Anti-harassment team, we will be sending out regular
> small reports.

Thank you.  Inevitably the project don't generally directly see the
work you do.  Thanks also for taking the time to write this report.

Regards,
Ian.

Re: Do we need embargoes for GPL compliance issues?

[Ian Jackson]

Ben Hutchings writes ("Re: Do we need embargoes for GPL compliance issues?"):
> As you may know, an individual copyright holder in the Linux kernel is
> understood to have succesfully sued various infringing companies

Bet you a dime to a dollar that these same infringing companies are
vigorously opposed to GPLv3 with its much more reasonable termination
clause.  (In GPLv2 your licence is automatically terminated as soon as
you violate.)

I have no sympathy for them at all.  Hoist by their own petard.  Don't
want our bugfixes to the licence ?  Fine, keep the bugs you care about
too.

I don't think Debian is at significant risk even from the trollish
people being discussed here.

Ian.

Re: Do we need embargoes for GPL compliance issues?

[Ian Jackson]

Ian Jackson writes ("Re: Do we need embargoes for GPL compliance issues?"):
> I think it was entirely wrong of the Conservancy's Linux GPL
> enforcement project to go along with the idea of promising to give
> violators a GPLv3-style termination clause.

Needless to say I don't approve of this "common cure" thing either.

Ian.

Re: Do we need embargoes for GPL compliance issues?

[Ian Jackson]

Florian Weimer writes ("Do we need embargoes for GPL compliance issues?"):
> Nothing can be done about GPLv2-only violations and the resulting
> license termination, of course.

This is a bit of a tangent, of course, but: I see this as a feature.

If corporations are upset by the possibility that their poor source
code management, untransparent processes, and lack of attention to the
needs of their downstreams, mean that they may be at risk of doom due
to the GPLv2 termination clause - why, then they should encourage
everyone to upgrade to GPLv3+.

I think it was entirely wrong of the Conservancy's Linux GPL
enforcement project to go along with the idea of promising to give
violators a GPLv3-style termination clause.

Instead, copyrightholders should dual licence their contributions to
the kernel and perhaps promise not to enforce GPLv2 breaches
(including GPLv2 termination) if the GPLv2-violator is willing to
behave in a way that would comply with GPLv3 within the GPLv3 30-day
period.

Ian.


-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Article 13 of the EU copyright review

[Ian Jackson]

Chris Lamb writes ("Article 13 of the EU copyright review"):
> Would there any strong objections to the Project aligning itself
> against the new EU copyright review? For more background, here's a
> recent Linux Journal article about this reform attempt:
> 
>   
> https://www.linuxjournal.com/content/how-eus-copyright-reform-threatens-open-source-and-how-fight-it
> 
> … and the FSFE's campaign which anyone can sign in an individual
> capacity:

I haven't researched this, but FSFE are IMO an extremely reliable
guide to what to think about things.  As a general rule, I woud
support any of their campaigns.  (I have a number of their excellent
T-shirts too.)

NB that FSFE are quite are a different thing to the FSF, although,
obviously, they are allies.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Debian trademark, EAN, proposed letter, SPI heads-up

[Ian Jackson]

MENGUAL Jean-Philippe writes ("Re: Debian trademark, EAN, proposed letter, SPI 
heads-up"):
> Le 03/05/2018 à 13:30, Ian Jackson a écrit :
> > Martin Michlmayr writes ("Re: Debian trademark, EAN, proposed letter, SPI 
> > heads-up"):
> >>> Ian Jackson <ijack...@chiark.greenend.org.uk> [2018-05-02 16:42]:
> >>>> I'll discuss with the SPI board.
> >>>
> >>> When should we expect to hear from you ?
> >>
> >> I'm not sure.  I had a deadline a few days ago and I'm just catching
> >> up on my TODO list.
> >>
> >> How urgent is this?
> > 
> > I don't know.  It has already been dragging on for a long time.
> 
> As the topic has been opened on 2017, I would be glad to finish it this
> month if possible.

Martin, sorry to press you, but when should we expect to hear from
SPI, please ?  Or should we keep polling every few weeks ?

Thanks,
Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Request for official help

[Ian Jackson]

MENGUAL Jean-Philippe writes ("Re: Request for official help"):
> Yes I understand. Just keep in mind that the letter is not public, just
> for amazon staff. But well, I propose we try without explicit name and
> see wether it is enough for Amazon.

I was thinking we would put it on our website.  That way any CD vendor
with similar needs can use it.

Ian.

Re: Request for official help

[Ian Jackson]

MENGUAL Jean-Philippe writes ("Re: Request for official help"):
> I saw the topic in quite progress last weeks ago. When do you think I could 
> get
> a signed letter, ideally mentioning explicitly Hypra?

I don't think it's likely that we would want to explicitly mention
anyone in particular.  Is that necessary ?

We wouldn't want to give the impression of an endorsement.

Ian.

Re: Debian trademark, EAN, proposed letter, SPI heads-up

[Ian Jackson]

Martin Michlmayr writes ("Re: Debian trademark, EAN, proposed letter, SPI 
heads-up"):
> > Ian Jackson <ijack...@chiark.greenend.org.uk> [2018-05-02 16:42]:
> > > I'll discuss with the SPI board.
> > 
> > When should we expect to hear from you ?
> 
> I'm not sure.  I had a deadline a few days ago and I'm just catching
> up on my TODO list.
> 
> How urgent is this?

I don't know.  It has already been dragging on for a long time.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Debian trademark, EAN, proposed letter, SPI heads-up

[Ian Jackson]

Martin Michlmayr writes ("Re: Debian trademark, EAN, proposed letter, SPI 
heads-up"):
> I'll discuss with the SPI board.

When should we expect to hear from you ?

Thanks,
Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: UEFI Secure Boot sprint report

[Ian Jackson]

Tollef Fog Heen writes ("UEFI Secure Boot sprint report"):
> In the end, we decided to have a signing service which will construct
> a source package based on a "template" package and a list of files to
> sign and upload this to be processed by the normal buildd and dak
> processes. The signing service will also have an audit log which makes
> it public what was signed and when.

Thanks for the update.

> Once this was agreed and various corner cases ironed out, we started
> implementing the signing service, and the necessary changes in the
> Linux kernel package, dak, fwupdate, shim and grub. The source for the
> signing service can be found at
> https://salsa.debian.org/ftp-team/code-signing.

One small point: Do you think tht the source for the signing service
is part of the source for the signed output ?  If so it probably needs
to be in the Debian archive, not just on salsa.  Sorry if this is
inconvenient.

> By the end of the sprint, we were able to:
> - generate a signing template for Linux kernel modules
> - generate a signing template for shim
> - generate a signing template for fwupdate
> - have DAK detect such signing template packages automatically and
>   generate a request for signing
> - run the code of the signing box by hand to generate the source code
>   packages containing the generated signatures

Thanks for your work.

Regards,
Ian.

Re: Debian trademark, EAN, proposed letter, SPI heads-up

[Ian Jackson]

Alvaro Herrera writes ("Re: Debian trademark, EAN, proposed letter, SPI 
heads-up"):
> Ian Jackson wrote:
> > There's one bugfix: "the the" should read "the".
> 
> No bugfix for "anticpate" or "predjudice"?

Thanks for the proofreading :-).  I have run it through a spillchucker
too.

> (I also wonder about "Nor do ... do so on Debian's behalf". Looks odd to
> me, but then I'm not a native English speaker; maybe it's just my
> ignorance.)

This is correct, I think.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Debian trademark, EAN, proposed letter, SPI heads-up

[Ian Jackson]

Martin Michlmayr writes ("Re: Debian trademark, EAN, proposed letter, SPI 
heads-up"):
> Ian Jackson <ijack...@chiark.greenend.org.uk> [2018-04-19 13:53]:
> > SPI: are you willing to have the SPI Secretary sign this letter ?  If
> 
> Just to make sure we're on the same page, you're talking about the
> draft letter you posted 31 Aug 2017 15:19:18.  There have been no
> changes since that post, right?

That's right.  For your convenience my mail
  Date: Thu, 19 Apr 2018 13:53:34 +0100
quoted the thing again.

There's one bugfix: "the the" should read "the".

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Debian trademark, EAN, proposed letter, SPI heads-up

[Ian Jackson]

Chris Lamb writes ("Re: Debian trademark, EAN, proposed letter, SPI heads-up"):
> Hi Ian,
> > Chris, are you now content ?  Would you be happy with me putting
> > my name on the bottom ofthis letter ?
> 
> Thanks for running with this. I am happy with the content and with
> your name at the bottom.
> 
> (Happy to sign it too if that's needed or helpful for whatever
> reason.)

It might make it more convincing if you were to sign it, indeed.

I will wait a bit now to see what SPI says.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Debian trademark, EAN, proposed letter, SPI heads-up

[Ian Jackson]

Ian Jackson writes ("Debian trademark, EAN, proposed letter, SPI heads-up"):
> We (Debian, me specifically) are about to ask Free Software
> Conservancy for legal advice - specifically whether there is anything
> wrong with this proposed letter.

I am picking this up again now after a long delay.  Sorry about that.
We had a reply from Conservancy.  They weren't able to offer us formal
legal advice.  On an informal basis they did say that they didn't see
anything wrong with the letter, but cautioned us that they weren't
experts in the relevant areas of law or the relevant jurisdictions.

Personally I am sufficienty reassured that we should draft this
letter.  The DPL delegated this matter to me, but: Chris, are you now
content ?  Would you be happy with me putting my name on the bottom of
this letter ?

SPI: are you willing to have the SPI Secretary sign this letter ?  If
not, who should we ask for further legal advice ?  Michael Schultheiss
suggested SFLC but I don't think that any involvement of Debian or SPI
with SFLC is or would be appropriate.

If this all meets with everyone's approval I will make a nice-looking
pdf, with some logos, for the SPI Secretary and me to sign and scan.
We can then put the final scan on our website somewhere.

Thanks,
Ian.


> === draft letter ===
> 
>RE DEBIAN - EUROPEAN ARTICLE NUMBER (EAN)
> 
>To Whom It May Concern
> 
>The Debian Project ("Debian") and Software In The Public Interest
>Inc ("SPI") wish to make known that:
> 
>1. Debian, through its Trusted Organisations including SPI, owns and
>controls the trademark "Debian" in various jurisdictions.
> 
>2. Debian does not provide European Article Numbers (EANs).  Nor do
>any of Debian's associated organisations do so on Debian's behalf.
> 
>3. Debian and SPI give public permission for products embodying
>Debian's software and documentation to be sold, according to the
>Debian Trademark Policy (which can be found at
>https://www.debian.org/trademark).  That policy does not make any
>requirement about EANs.  Therefore (provided the policy is adhered
>to) we have no objection to Debian branded products being sold without
>EANs.
> 
>4. Debian do not anticpate this situation changing in the next 2
>years.  Specifically, we do not expect to be issuing EANs within the
>next 2 years.
> 
>5. Please therefore allow vendors of Debian merchandise to trade,
>notwithstanding any lack of EANs for those products.
> 
>6. This is without predjudice, of course, to our right to enforce our
>trademarks against anyone found violating our trademark policy.  We
>are simply saying that lack of an EAN is, in itself, completely fine.
> 
>Signed
> 
>for the Debian Project  for Software in the Public Intere

Re: Request for official help

[Ian Jackson]

MENGUAL Jean-Philippe writes ("Re: Request for official help"):
> Did I miss something about this topic? Any news?

I'm sorry, I dropped this.  Please do hassle me if you don't hear more
in the next week.

Ian.

Re: Conflict escalation and discipline

[Ian Jackson]

Gunnar Wolf writes ("Re: Conflict escalation and discipline"):
> But my critique to Ian's original point stands: As long as the people
> involved in said "hard" social interactions post their messages to
> debian-devel or debian-whatever, no conflict-prevention-body will ever
> prevent that friction.

Indeed.  My point of view arises from considering what might induce
such people to try a different approach.

The answer is, carrot: advertising that the alternative route has a
possibility of delivering something like what an angry person actually
thinks they want - punishment for the wrongdoer.

And, of course, stick: if you post to d-devel anyway then your own
behaviour will be scrutinised by that some body, and will be
officially looked on unfavourably (rather than just get you dogpiled).

I'm going to let other people drive this conversation for a while.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Conflict escalation and discipline

[Ian Jackson]

Lars Wirzenius writes ("Re: Conflict escalation and discipline"):
> "Debian emotional support group", maybe.

I find this suggestion very surprising, possibly even insulting.  At
the very least I need to be much clearer.

> But maybe wait with the naming until there's a clear description of
> what the group is reponsible for.

This group would:

 * Receive reports of bad behaviour on the part of Debian
   contributors, in whatever forum or venue including in person.

   Bad behaviour includes but is not limited to: harassment; exceeding
   any form of authority (eg, package hijack); persistent or severe
   rudeness; blocking others' work without reasonable justification
   and adequate communication.

 * Handle matters in private (except in very exceptional cases).

 * Where appropriate, facilitate, mediate and/or conciliate, in the
   hope that the problem can be resolved by better communication.

 * Where appropriate, make judgements about the behaviour of relevant
   parties, and express those judgements to the parties in the hope of
   influencing them.

 * Where appropriate, recommend action to: DAM, TC, listmaster, IRC
   operators, DPL.  Information about the situation would be provided
   by the disputes team to the gatekeeper team; but the gatekeeper
   team would not be expected to make its own enquiries and would
   normally be expected to follow the recommendation.

 * Write and publish guidelines for how to behave, how to complain,
   and write down its own processes.

 * Resolution might include simply informal discussions and
   reconciliation.  It might involve formal apologies, usually private
   but perhaps public.  It might involve preventative measures
   (intended to limit the damage done); punative disciplinary measures
   (intended to deter); and exclusionary disciplinary measures
   (intended to remove a problem from the community or part of it).
   It might involve a formal transfer of one or more forms of
   authority held by some of the disputants.

 * The new group would have a foundational document which would
   explicitly give it authority to do all of the above.

 * All of the above is without prejudice to the continuing rights of
   listmaster and other forum operators to take action when they think
   it appropriate.

 * Where the dispute includes a technical question about the behaviour
   of software, the dispute team would firstly try to get people to be
   able to discuss it constructively.  If that failed to produce
   agreement, the disputes team would say who was the person whose
   decision it was.

   If the other side wish they may refer the technical question to the
   TC.  The behaviour of the participants during the TC conversdation
   would be monitored by the disputes group and if necessary the
   disputes group would be able to have the discussion suspended or
   some participant(s) blocked.

Ian.

Re: Conflict escalation and discipline

[Ian Jackson]

Lars Wirzenius writes ("Re: Conflict escalation and discipline"):
> Most of the problems being discussed right now, and in general, seem
> to be of the sort where feelings are hurt, but harassment isn't
> happening. The situations seem to be "A did something, and B was
> offended, how do we get A and B to understand each other, and resolve
> any conflict, and get A and B to collaborate in the future?".
> 
> This implies to me that, at the least, "anti-harassment" is the wrong
> name for a team that deals with this.

That's certainly true.  I thought of these ideas:

 all @debian.org
   trouble too vague, also negative
   behaviour   seems somehow hostile, also vague
   conduct seems somehow hostile, also vague
   appeals too strongly advertises judicial function
   arbitration too strongly advertises judicial function
   upset   can minimise and subjectify bad actions
   conflictvery negative
   resolution  too vague but at least positive
   reconciliation  not attractive to complaints who want action
   dispute[s]  maybe?

Ian.

Re: Conflict escalation and discipline

[Ian Jackson]

Don Armstrong writes ("Re: Conflict escalation and discipline"):
> On Tue, 17 Apr 2018, Gunnar Wolf wrote:
> > But that's my point: Do you want to solve that by adding... Yet
> > another contact point?
> 
> Would it be OK if leader@ stayed the contact point, but leader@ had a
> pool of individuals who were willing to mediate in such a case? [Perhaps
> with secretary@ or the CTTE chair as the backup in case leader@ was
> involved?]
> 
> Such individuals would have the ability and knowledge to involve the
> existing levers of power (TC, DAM, leader@, anti-harassment etc.) if
> escalation was required.

There are several things wrong with this suggestion IMO:

1. It depends on the DPL selecting a suitable delegate for each
   incoming enquiry.  At best, with a standing panel, this is makework
   and an opportunity for things to get dropped.  At worst it is
   another way for an escalation of bad behaviour to be blocked.

2. You are suggesting mediation.  Mediation is certainly *one* part of
   what is needed, but also *conciliation* and *arbitration*.
   Generally I am not a fan of mediation because it does not look at
   the rights and wrongs behind an issue; so it reinforces the
   existing power structures.

3. Complaintants should not be expected to repeatedly explain/justify
   their views to a succession of different
   teams/officeholders/whatever.

4. Your proposed people seem to lack real authority; and also public
   legitimacy.  The lack of authority/legitimacy is a problem because
   (i) awkard disputants will just say the appointee is wrong
   (ii) if escalation is required, see (3).

5. Each individual dispute should be dealt with by more than one
   person.  Because otherwise escalation to enforcement action will
   inevitably have to violate (3), since there are some serious steps
   which might be necessary for which a single person's recommendation
   would be clearly insufficient; and even for less serious steps,
   collective rather than individual judgement is probably better.

6. You mention `anti-harassment' as a `lever of power" but of course
   anti-harassment have no inherent authority.

IMO the antiharassment team's members would be a good starting point
for the members of my proposed new structure.  But the new structure
needs to relate entirely differently to our existing institutions.

I wonder if I should propose a GR.  That would provide a way of
testing whether my ideas (which do seem controversial) are more widely
held, and also if the GR passes, give clear legitimacy to the new
team.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Conflict escalation and discipline

[Ian Jackson]

Chris Lamb  writes ("Re: Conflict escalation and discipline"):
> Hi Gunnar et al.,
> > [Ian:]
> > > An effective, reliable and unified disciplinary mechanism
> [..]
> > Thing is, I believe we have several bodies / mechanisms that partially
> > cover the case.
> 
> I also am reluctant to speak for Ian (!) but I believe he is making
> the point that it is this very diversity of contact points that
> could be part of the problem.

Yes.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Conflict escalation and discipline

[Ian Jackson]

Jonathan Carter (highvoltage) writes ("Re: Conflict escalation and discipline"):
> On 2018-04-17 14:39, Ian Jackson wrote:
> > We desperately need:
> > 
> >  * Somewhere people can escalate a dispute involving ill-feeling,
> >that isn't debian-devel[0] or the DPL[1].
> > 
> >  * An effective, reliable and unified[2] disciplinary mechanism that
> >(i) promotes healing, apology and reconciliation where that is
> >feasible (ii) failing that, limits the damage done by difficult
> >people (iii) when inappropriate behaviour appears in public is able
> >to authoritatively declare and demonstrate that it is not how we do
> >things here.
> 
> +1!

I should say that I am volunteering, in the event that anyone
considers me suitable to be part of such a thing.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Conflict escalation and discipline

[Ian Jackson]

We desperately need:

 * Somewhere people can escalate a dispute involving ill-feeling,
   that isn't debian-devel[0] or the DPL[1].

 * An effective, reliable and unified[2] disciplinary mechanism that
   (i) promotes healing, apology and reconciliation where that is
   feasible (ii) failing that, limits the damage done by difficult
   people (iii) when inappropriate behaviour appears in public is able
   to authoritatively declare and demonstrate that it is not how we do
   things here.

[0] Doing this kind of thing in public is really poor.  d-devel is a
good place for escalation of a tricky technical problem.  It can also
work well for technical disagreement, if the participants still regard
each other as collaborators and remain friendly or, at least, polite.

[1] We must not pile this problem onto one person.

[2] That is, there should be a single set of decisionmakers who can
ultimate make disciplinary decisions[3] regardless of which communication
channel(s) and/or contributor status privileges are being (ab)used;
and regardless of whether the bad behaviour is said to be harassment
or rudeness or whatever.

[3] It would be OK if they made recommendations which DAM, TC, or
whoever, were expected to follow.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Problems with source DVDs.

[Ian Jackson]

Scott Kitterman writes ("Re: Problems with source DVDs."):
> There are packages where upstream includes files for testing that trigger a/v 
> alerts, even though they are safe.  Without knowing which files triggered the 
> alerts, it's almost impossible for us to answer your question.

That might be the cause.

However: the PuTTY project has been suffering for some time from being
occasionally listed as malware.  Notably, for example, the hash of the
actual released putty.exe appeared in a malware list.  PuTTY's
developers complained, and it was removed.  The next release, same
thing.

The problem occurred with many virus checkers.  PuTTY were mostly
dealing with ClamAV because they have the least horribly-closed
process - ie you can actually talk to them and sometimes even get an
individual false positive fixed.  But AFAICT ClamAV get their
signatures from some kind of secret database which you have to sign up
to an NDA to get access to.

No-one was ever able to explain why PuTTY keeps getting listed as
malware.  In IRL conversations with Simon Tatham he had a number of
theories about how this might occur by accident, but I have to say I
didn't find them plausible.

My theory is that one of PuTTY's proprietary competitors is
deliberately poisoning AV databases.  After all, by now, there is
almost no reason for a straight head-to-head proprietary competitor to
PuTTY to even exist.  Most of those products are, now, produced by
shysters, who are monetising users' ignorance.  They need to
differentiate their product from PuTTY and one way is "doesn't set off
your AV".

Sadly it seems unlikely we'll ever be able to find out what's really
going on, unless someone leaks a trove of documents or something.

It is possible that something similar is happening to these ISOs.  I
doubt that any of *Debian's* competitors would bother with such
shenanigans, but we ship an enormous variety of software, at least
some of which must have unscrupulous competitors.

Ian.

(sad that the world has come to this kind of state)

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

[Ian Jackson]

Martin Steigerwald writes ("Re: Let's Stop Getting Torn Apart by Disagreement: 
Concerns about the Technical Committee"):
> Any workable solution lies beyond blame, however.
> Any workable solution lies beyond "I am right and you are wrong".

Traditionally Debian has a very workable approach for disagreements
over whether software X or Y is better.  (For whatever value of
"better")  Offer both and let people decide for themselves.

When things start to get really emotional and heated is when people
feel (rightly or wrongly) that such choices are being curtailed.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

technical terms (Re: Automatic downloading of non-free software by stuff in main)

[Ian Jackson]

Holger Levsen writes ("technical terms (Re: Automatic downloading of non-free 
software by stuff in main)"):
> On Thu, Dec 07, 2017 at 04:06:43PM +, Ian Jackson wrote:
> > (Your logic would argue that browser porn mode is basically
> > pointless.)
>  
> I didnt get what you ment originally, but after the 3rd mail using these
> words I realized you ment "privacy mode".
> 
> I dont understand why you are using demeaning words for "privacy mode".
> Are you suggesting privacy=porn? I dont think so, so please use the
> proper words.

If you think "porn mode" is demeaning, I'm happy to call it "privacy
mode" instead.  I don't think "porn mode" is demeaning; it's just what
my real-life social calls it.

Ian.
(who does a lot of hir browsing in privacy mode.)

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Automatic downloading of non-free software by stuff in main

[Ian Jackson]

Paul R. Tagliamonte writes ("Re: Automatic downloading of non-free software by 
stuff in main"):
> I claim if you can read this attribute, you can observe the rest of those
> actions passively. 

So the secret police who have seized my computer, or my spouse who
suspects me of looking at the "wrong" sort of websites (but doesn't
want to risk installing spyware), or my employer who has suspended me
because they to fire me unjustifiably and is now searching my
computer, can easily get into their time machine and go back and make
the computer tell them what I did last week ?

No.

(Your logic would argue that browser porn mode is basically
pointless.)

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Automatically marking downloaded files (was Re: Automatic downloading of non-free software by stuff in main)

[Ian Jackson]

~Stuart Prescott writes ("Re: Automatically marking downloaded files (was Re: 
Automatic downloading of non-free software by stuff in main)"):
> * wget in stretch doesn't set xattrs (but the version in sid does)

Cripes.

> * chromium doesn't set xattrs if you "File→Save" but does if the
> file type is downloaded.
> 
> * I wasn't successful in doing this on a tmpfs - perhaps there are 
> additional runes to add to the mount options that would make that possible.

Can we have a single place to enable/disable this behaviour ?  I think
it should be disabled by default!

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Automatic downloading of non-free software by stuff in main

[Ian Jackson]

Paul R. Tagliamonte writes ("Re: Automatic downloading of non-free software by 
stuff in main"):
> I hilariously discovered this last night as well (playing with IMA), and
> removing the creation of that attr would be a huge step back.
> 
> Restricting the execution of files one downloads or disabling macros on word
> documents you download and open would be a huge security win.
> 
> These attributes are destroyed by merely coping the file, and are on
> the filesystem, not the file. It's not like sending a file via email
> leaks where I downloaded it from.

So if I use a browser in porn mode to download a file, and when I
close the browser the browser's record of the url where I got it is
deleted, but the url is saved in a hidden thing attached to the file.
Surely that is undesirable ?

And that's what happens if the browser implements this feature.  If
the browser doesn't implement it (or suppresses it for porn mode
downloads), then I am vulnerable to the obvious clickbait attacks.

Furthermore, this "file is dangerous" attribute ought to be copied
much more.  There are surely situations where that it is not copied
into copies of the file is a problem.

And, files can be dangerous if they came from emails, or file transfer
clients, as well as if they came from web pages.  Some of these
sources might not have sensible URLs (and saving a dummy URL seems
wrong).

Finally, if a user thinks it useful to know where a file came from - I
can definitely see that this might be good (although personally I
think it should be disabled by default) - they might well want to do
that _and_ also mark the file as trusted for execution.  That way if
they hear that the file is out of date they don't have to trust a
general search engine and re-navigate to the same url.

And, the privacy concerns mean that browser authors will properly
resist implementing it or enabling it by default.

It seems to me therefore that this XDG url saving attribute is not the
right shape to be reused as a boolean "file was downloaded from the
internet and might be dangerous" flag.

Ian.

Re: Automatic downloading of non-free software by stuff in main

[Ian Jackson]

Adam Borowski writes ("Re: Automatic downloading of non-free software by stuff 
in main"):
> It looks like we two are in agreement that all non-free software is bad,
> even if we differ wrt how acceptable using it is.  But we disagree about
> the reason _why_:
> 
> * I say that the primary reason is that a person not blessed by the upstream
>   has no way to fix problems.  You can't debug Windows Update to see why
>   your aunt's computer hangs during it.  You can't print a cheat sheet of a
>   GFDLed manual without the cover and invariant sections.  To me, every
>   part of DFSG (other than 4.) solves a real _practical_ problem.
> 
> * the distributions you're talking about state this as a moral issue.

I don't see that this is a sensible distinction.  But anyway, it
doesn't matter.  People who use those downstreams are doing it because
they have decided that they agree with those downstreams' very zealous
objection to non-free software, including firmware etc.

I propose to help those users, and those downstream developers, by
doing some more of the work in Debian.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Automatic downloading of non-free software by stuff in main

[Ian Jackson]

Enrico Zini writes ("Re: Automatic downloading of non-free software by stuff in 
main"):
> On Fri, Dec 01, 2017 at 08:22:58PM +0500, Andrey Rahmatullin wrote:
> > [Ian Jackson:]
> > > Debian ought to be a good upstream for everyone, not just "me"
> > > (whoever me is).
> > Our users are declared our priority, our downstreams aren't.
> 
> It never occurred to me that our downstreams could be considered as not
> being a part of our users. Is that a common understanding?

I hope not!  I consider all the users of all our downstreams, as users
of Debian.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Automatic downloading of non-free software by stuff in main

[Ian Jackson]

(Dropping the crossposts.  The stuff I want to reply to is probably
material for -project.)

Adam Borowski writes ("Re: Automatic downloading of non-free software by stuff 
in main"):
> On Thu, Nov 30, 2017 at 01:52:18PM +, Ian Jackson wrote:
> > I would like to establish a way to prevent this.  (There are even
> > whole Debian derivatives who have as one of their primary goals,
> > preventing this.
> 
> No, those derivatives are damage.  While their hearts are in the right
> place, they cause data loss and security holes by at least making people on
> Intel and AMD machines use known-buggy microcode.

I think it's very rude to call something damage just because you
disagree with someone's political stance with respect to the software
they un on their own computer.

Also, if you care so much about this you should probably worry about
Debian's current default approach to microcode.

> The biggest reason for me

Debian ought to be a good upstream for everyone, not just "me"
(whoever me is).

Ian.

Automatic downloading of non-free software by stuff in main

[Ian Jackson]

This mail is going to a lot of lists.  I have set the followups to
d-policy because ultimately this is hopefully going to result in a
change to policy.


Over the years, d-legal has discussed a number of packages which
automatically download non-free software, under some circumstances.

The obvious example is web browsers with extension repositories
containing both free and non-free software.

We have also recently discussed a media downloader/player which, when
fed a particular kind of url, will offer to automatically download a
proprietary binary-only protocol module to access the specified
proprietary web service.

We have generally put software like this in main, because it asks the
user first, and can be used perfectly well without the proprietary
parts.  But the overall result is that a user who wants to use Free
software can be steered by Debian into installing and using non-free
software, sometimes unwittingly,

I would like to establish a way to prevent this.  (There are even
whole Debian derivatives who have as one of their primary goals,
preventing this.  We should aim for most of the changes necessary for
such derivatives to be in Debian proper, so the derivative can be
little more than a change to the default configuration.)

I think the necessary new central technical component is a
configuration somewhere, checked by programs with plugin download
capability.

We should have a conversation about:

 * What user experience options should ideally be available
 * How those options should be represented in configuration
 * Bug severity for programs that do not respect the "only free
   stuff" setting.

Ideally we can come up with a technical solution which means that it
is easy for existing programs implement the new check, so that failure
to do so can be RC for buster.

The minimum required changes to individual packages should be small.

NB that this is going to be a _user option_.  I'm not trying to shut
down non-free extension repositories.  (Indeed I sometimes use them.)
I want to give users more control.


Obviously excluded from this discussion are downloader packages, which
have the fetching and use of proprietary things as their primary
purpose, and which therefore live in contrib.


But there is another category I want to distinguish:

Applications for processing Turing-complete file formats.  This
includes web browsers, because of Javascript; but it also includes
PostScript viewers; interactive fiction interpreters; and so on.

The distinction between this and the general plugins I mention above
is that these applications all restrict the capabilities of the code
being executed, by running it in some kind of sandbox or container.
The idea being that the code gets to control the user's interactions
_with the providers of that code_, but not anything else.

There are some people who object to executing any non-free code on
their computer and I don't mind providing a facility for people to
restrict that.  But I don't know exactly how to design such a thing.

For web browsers, there is the FSF's libre-JS.  Personally I think
that is rather quixotic (and doesn't really address the real user
freedom question anyway), but I have no objection if anyone wants to
do the work to integrate that into some kind of freeness control
system.

But with file formats, the situation is much harder.  I don't feel we
can introduce a policy requirement requiring package maintainers to
support users who want this kind of restriction, until we can come up
with a scheme that will actually work and be useable (and indeed, will
be minimal effort for a package maintainer to opt into).

(The question is: how do we stop a Postscript file received by email
being rendered automatically when the user clicks on it, while
allowing the user to still open a Postscript file they generated
themselves ?)


Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Emeritus status, and email forwarding [and 1 more messages]

[Ian Jackson]

Peter Palfrader writes ("Re: Emeritus status, and email forwarding"):
> Without a key in a keyring that somebody maintains, authenticating such
> requests, even manually, is going to be a PITA.

Mattia Rizzolo writes ("Re: Emeritus status, and email forwarding"):
> In many cases (such this particular one) people don't have a viable gpg
> key anymore in the keyring: that means they can't email
> chan...@db.debian.org to update their LDAP details (theoretically, they
> might still know the LDAP password and do it from there, but in practice
> all the people who reach that point already forgot it).

It would be possible to have an "emeritus" keyring, I guess.  Since it
would only be used for email forwarding and a few other things, it
could have weaker security requirements.

But this is all just hot air from me now, because I'm afraid I am not
volunteering to implement or maintain it :-/.

Regards,
Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Debian banners

[Ian Jackson]

martin f krafft writes ("Debian banners"):
> I still have some heavy-duty banners we've used at conferences, as
> well as a banner stand in my basement that I need to get rid of.
> If you want them or you have an idea what to do with them, please
> let me know. Else, come the end of November, I'll be forced to throw
> them out.

In the interests of saying something concrete and maybe-helpful: I
have enough storage space that I could store such a thing.  I am
content to store it until it's needed and then arrange for it to be
shipped to wherever it is wanted.

So, you could ship it to me.  Perhaps Debian wants to pay for the
shipping out of Debian funds.

Please contact me by private email for the right shipping address.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Emeritus status, and email forwarding

[Ian Jackson]

Someone who was sort-of-MIA said on -private that they would like to
keep their @debian.org email forwarding indefinitely, as they move to
emeritus status.

I think that, with some safeguards[1], this would be a good thing to
offer people.  If nothing else people have often used @d.o addresses
in Debian work, where the addresses live on after they move on, and we
should definitely encourage even an emeritus member to be reachable
for answering questions or whatever, as their time and interest
permits.

Unfortunately it would mean that such people would still need some
kind of login on Debian systems, so that they could update the email
forwarding.  But it wouldn't have to have the wide powers of an active
DD/DM account.

What do people think ?  How hard would this be ?

[1]

Safeguards I think would be appropriate:

The emeritus member should refrain from advertising the @debian.org
email address, so outgoing emails, web pages, etc., should be updated
to show a different address.  Obviously the point of retaining the old
address is to avoid having to deal with a massive array of existing
places where the address is published, but there should be no active
uses, and any particular instances should be changed on requests by
Debian.  The forwarding would have to be withdrawn if the emeritus
member continued to advertise their @d.o address, or if they did
something sufficiently bad that we would want to disassociate
ourselves from them more completely.

Ian.

Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

[Ian Jackson]

Thanks for your mail.  I have trimmed vigorously the parts I agreed
with :-).

Sam Hartman writes ("Re: Let's Stop Getting Torn Apart by Disagreement: 
Concerns about the Technical Committee"):
> That said, I actually think in some cases we need to spend more energy
> rather than less.  Minimizing energy spent on the process is not one of
> my goals.  I think that the TC in particular may need to spend more
> energy to have a chance of people feeling valued even when there is
> disagreement.

That may be true.  I think perhaps what I mean is that we are not
spending our energy well.

Unstructured mailing list discussions work reasonably well when
everyone feels that everyone else is on the same side, and everyone is
trying to understand the issues and feel they will be able to come to
a consensus, or at least a conclusion that everyone finds tolerable.

When things get more difficult, they become sprawling horrors.
Participants (quite understandably) feel the need to respond to
everything their now-opponents say.  People feel under time pressure.
It becomes difficult to see the wood for the trees.  Because the
parties are replying directly to each others' emails, there is ample
opportunity for misunderstanding, and all the escalations of minor
aggressions or poor word choices etc. into meta-disputes and anger.

I think it would be better if we asked participants to write a much
smaller number of longer and more comprehensive statements.  The TC
would have to explicitly forbid the use of the email-thread-based
debate style, even as a supplement (perhaps, by blocking it from the
TC's list).  If after however many (small number of) rounds of
refinement/response are permitted, one party decides they need to add
something to their statement of their case, they should have to ask
permission.


> Interestingly, the one area where I think conserving energy is important
> is the one you call out: minimizing the energy people need to spend
> responding to a complaint.
> Even there, I think that in a case where the TC thinks it is likely to
> ask a maintainer to make a change (or override the maintainer) it is
> reasonable to expect the maintainer/respondant to spend enough time to
> explain their position well enough that the TC understands it.

Yes, I absolutely agree.  But I think your suggestion that the TC
should evaluate an incoming complaint, to see if there is a case to
answer, before expecting anything from the maintainer, would be very
helpful.


> I also think the court emphasis on justice and "right" is harmful.  As I
> said in my blog entry, technical correctness is an important factor, but
> I think it is a less important factor than maintaining our community.

IMO injustice _itself_ undermines community.

When you say you want to put "community" ahead of "justice", what I
hear is that you want to put the opinions of some people ahead of
others, because they might be hurt more if the decision goes against
them, or because the are more important to the project somehow.

After all, if we are not to put some people's opinions ahead of
others, what we are left with is making decisions based on the merits,
which is what I am thinking of as justice.

That's not to say that we should not try to maintain our community.
Certainly we should try to reduce the damage done by disputes.

And "merits" does not usually mean technical merits.  Normally it
means thinking about whose interests are more vitally at stake.  It
often means thinking about those for whom the status quo is least
tolerable.


> However, because of who we are, we tend to emphasize technical
> correctness.

I agree with you on this part though.  It is very rare that a dipute
before the TC is mostly technical (let alone entirely technical).

The things people are usually arguing about are:

* Tradeffs between the interests of users with different use cases.

* Whose job is it to do some work that people think is desirable - or
to put it another way, who will bear the pain of the fact that the
work has not yet been done.

* Who is allowed and required to review (and, ultimately, if they see
it as necessary, block) others' work.

* To what extent must a maintainer permit contributions (and,
therefore, maybe to carry patches) that others care about, but which
the maintainers feel are not worthwhile (or even, inappropriate).

These are all, ultimately, questions of politics: they concern the
balance of competing interests, and the location and scope of power
and control.


Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Appropriate escalation (or non-escalation) re rude emails

[Ian Jackson]

Sam Hartman writes ("Re: Appropriate escalation (or non-escalation) re rude 
emails"):
> It seems like you could act as an individual listmaster who has not
> reviewed things with the rest of the team.  "It's my opinion as an
> individual listmaster that you are violating our code of conduct...
> If you disagree, you can talk to me or the rest of the
> listmasters..."

I think the availability of this approach is essential, for almost
anyone who is in a team which has any kind of authority.  This applies
to everything from the maintainers of an individual package, to the
TC.

> By acting as an individual listmaster, you make it clear that I have a
> path for a second opinion: asking the other listmasters.  But you also
> make it clear that if the community has concerns about the aggregate
> actions of the individual listmasters, we can also take that up with the
> listmasters.
> So, you can send mails  promptly without seeking review, provided the
> other listmasters are OK with that.

Yes.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Let's Stop Getting Torn Apart by Disagreement: Concerns about the Technical Committee

[Ian Jackson]

Sam Hartman writes ("Re: Let's Stop Getting Torn Apart by Disagreement: 
Concerns about the Technical Committee"):
> I am discussing how we handle conflict because I hope we can do a better
> job of helping  people feel valued even when we do not agree with their
> technical positions.

You've perhaps heard me say this before, but I think the TC process
lacks structure and that if the TC set out the process more formally,
things might go less awry.  (And also it would involve less of an
investment of energy by all the partipants, particularly the
respondents to a complaint.)

One of the most toxic things that can happen in any kind of dispute is
for there not to be a clear understanding of what the rules are,
within which the dispute will be conducted.  Ie, who is allowed to do
and say what, and when.

When people disagree about the metarules, community disintegrates
because people feel that not only are their opponents disregarding
their needs, but they are also playing foul.


I know that some people disagree, but I think that the TC should take
on much more of the trappings of other formal dispute resolution
mechanisms that we find in wider society.  Particularly, the TC should
be more like a civil court or tribunal.

Courts are of course stressful, but I think that stress is usually the
result of the underlying dispute.  (Courts in some jurisdictions are
awful, too, of course, and I'm not suggesting we set up professional
advocates with a vested interest in prolonging and exacerbating
disagreements...)

One big advantage of court-like formality is is that it provides
neutral (and possibly even constructive) ways to express and handle
the disagreement.  And of course it can avoid arguments over the
ground rules.

There are other models: mediation, perhaps.  But mediation is just
facilitated negotiation, and explicitly excludes the question of
justice or rightness.  What really matters for the outcome of
mediation is not who has the best arguments, but what are the parties'
"best alternatives to negotiation".

So the TC should formally adopt rules of procedure, saying how and
when issues should be brought to the TC, and how the TC will handle
them.  The rules should cover questions of when TC members should use
their ability to call for votes, and add amendments.  They should say
what interval is normally appropriate before asking the TC for help.
The rules will need to be bent on occasion, of course - but the rules
themselves should say who can grant permission to bend them.

The TC rules could also limit the email discussion, at least by
default - one of the most exhausting things about the TC right now is
the never-ending email threads.

It would also IMO be a good idea for the TC to explicitly adopt some
"form letters" that should be used in various circumstances.  If there
were a standard TC-approved text for the message saying "I feel
strongly enough about this, and you don't seem to agree, so I think I
will ask the TC for help soon" then that text could be made suitably
collegiate and refined over time, and there would be no arguments
about the tone of someone's email.


> I was not planning on discussing systemd again.

Thanks.  I don't think doing so is going to be illuminating.  It will
just reopen wounds.

Ian.

Appropriate escalation (or non-escalation) re rude emails

[Ian Jackson]

In the last week or so I have sent two mails to Debian contributors
saying to them that I felt their message was rude or otherwise had
inappropriate elements.

Normally when I do this I get a reply saying "sorry, that's not what I
meant" or "you are right and I was angry, I have written to XYZ to
clarify/apologise" or some such.  (Indeed as someone who sometimes
finds it difficult to maintain an even keel about things I feel
strongly about, I have received such messages myself and generally
tried to use them to become a better person etc.)

However, in the last two cases I the contributors I complained to have
said they disagree.  I won't quote their words.

How serious does an issue have to be, or how persistent the
misbehaviour, before I should forward the question to someone ?

Personally I don't often get the impression that listmaster@ welcome
complaints about what might be seen as mild misbehaviour.  And if I
see someone being rude directly to another contributor, but CC'd to
the public, it feels odd to be reporting that to the antiharassment
team.  Do I need to have standing ?

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Bitcoin donations

[Ian Jackson]

Elise Wood writes ("Bitcoin donations"):
> Have you considered adding an address for bitcoin donations? Would you?

After reading _Attack of the 50-foot blockchain_ by David Gerard, my
(previously merely rather sceptical) attitude to Bitcoin has
hardenened.

IMO Debian should not encourage or support Bitcoin in any way.  The
ecological consequences alone are too bad.

I recognise that as a matter of Debian's internal governance, there is
not a way to stop individual Debian Developers from providing Bitcoin
etc. software in Debian (and perhaps indeed there should not be).  But
more centrally provided things like accepting donations are a
different matter.

Everyone should read David's book.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Project to improve Debian support model

[Ian Jackson]

Katy Tolsen writes ("Project to improve Debian support model"):
> I've started a project with the aim to improve Debian's support
> model by designing software to help integrate and track all our
> support efforts and make a system that bridges the gap between our
> supporters, developers, and users in a synergistic way to make the
> most of our efforts and help us identify and solve issues more
> effectively and make sure the issues are documented and accessible
> to everyone in a way most suitable to their needs.
> 
> https://kathryntolsen.github.io/diss/

Thanks for coming to try to help improve Debian and for talking to us
about your plans.

This project may very well turn into something interesting, but right
now it seems to be mostly a combination of handwaving, and extensive
and ambitious high-level spec documents.

Do you have any prototypes / code / etc. that we could see ?

> For consideration of our developers, I ask for your input on this
> matter because I envision that this project can benefit development
> on the Debian system by allowing developers to make use of our
> proposed diagnostic tree model to supply such files with their
> packages that will help users file better bug reports and resolve
> issues with your packages.

reportbug already does some of this.  You should clearly reuse the
information already provided in packages, that reportbug already
consumes.  See /usr/share/doc/reportbug/README.developers.gz.

It's not very structured.  If you want more information in packages
(eg a more structured way to collect info), then you should propose
extensions to the reportbug per-package-information protocol.

You should propose only the minimum set of metadata that is needed
right now and expect to extend things later.

This goes for your project in general: you would be much better off
creating the Minimum Viable Product and then extending it later, than
by spending a lot of time writing documentation for how you expect the
distant future to look.

One concrete comment: I did see you mention here
  https://github.com/kathryntolsen/diss/wiki/DISS-Diagnostic-Trees
that you were planning to use XML as a metadata format.  Debian has
long disfavoured XML for these kinds of uses (for good technical
reasons).

I hope this is helpful and good luck.

Regards,
Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Debian trademark, EAN, proposed letter, SPI heads-up

[Ian Jackson]

Joshua D. Drake writes ("Re: Debian trademark, EAN, proposed letter, SPI 
heads-up"):
> On 08/31/2017 07:19 AM, Ian Jackson wrote:
> > Debian would like to sign, jointly with SPI, a letter stating that we
> > do not intend to apply for EANs.  A draft of the letter is below.
> 
> The vendor should apply for their own EANs. If Debian/SPI applies for 
> them it will provide a communication of validity to the vendor 
> ("Official Debian Images").
> 
> +1 for Debian not allowing an external vendor to appear as the official 
> distributor (unless they actually are).

I'm not sure I follow everything you said there, but it sounds to me
like you are happy with my proposed letter.  If I have misunderstood
then I'm afraid you'll have to clarify...

Regards,
Ian.

Re: Debian trademark, EAN, proposed letter, SPI heads-up

[Ian Jackson]

Guillem Jover writes ("Re: Debian trademark, EAN, proposed letter, SPI 
heads-up"):
> I'm not sure whether this is splitting hairs, but wouldn't issuing a
> letter stating those 2 years make any similar request in the near
> future that demands a 2 years span, require reissuing a new letter?
> Perhaps it should be 3 or 4 years instead? One possible problem is that
> this means we cannot change our minds for a "long" time if need be, but
> I think there is indeed consensus that we'd not want to do that. But of
> course with these things you never know what will happen in 1 year! :)

This is a valid point, but I was imagining we would reissue this
letter as needed.  In practice an old letter which is still on our
website is likely to be accepted by the relying parties, I would have
thought.

Ian.

Debian trademark, EAN, proposed letter, SPI heads-up

[Ian Jackson]

 in product bundles or in bulk.
   With the exception of antique products, the condition of an item for
   which an EAN or UPC exemption is requested must be New.

   Please find more info about those EAN exemptions requests by clicking on
   the following link: ***

   No answer is require from your side, but if you have further questions
   concerning your sales, please never hesitate to contact *** again [...]

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Reasons for having DPL election terms 1 year

[Ian Jackson]

shirish शिरीष writes ("Reasons for having DPL election terms 1 year"):
> My query how did the idea of having yearly elections for choosing DPL
> come in place.

This was my doing.  And, TBH, I don't think I considered other options
very seriously, although I haven't searched my email archives.  (I may
not have email archives but maybe someone else does.  The discussion
was probably on d-devel.)

Nowadays I think 1 year is still right.  If the existing DPL is doing
a good job and wants to continue, they normally get re-elected.  Our
election campaigns don't seem to be too much of a distraction.  And
even a 1 year DPL term is a big commitment.

Ian.

Re: wanted: educate us please on key dongles

[Ian Jackson]

Marc Haber writes ("Re: wanted: educate us please on key dongles"):
> That's a point, but I cannot validate whether the free hardware
> design running the free software crypto app isn't backdoored anyway due
> to lack of knowledge and expertise.

You don't need to be able to validate it personally.  The thing spooks
most hate is discovery.  Backdooring supposedly-free hardware is
harder (more costly) because it comes with greater risk of discovery.

To put it concretely: if they backdoor all of them, someone (not
necessarily you) might notice.  (Backdooring only yours involves
messing with the shipping arrangements and so on, and supposes that
you specifically are of interest.)

That's not to say it's perfect (nothing is, in security).  But
supposedly-free hardware is easier for anyone else to validate and/or
audit, and by that measure is less likely to be compromised.

How far down the paranoia road you want to go is up to you, but buying
an open hardware / libre firmware security device, rather than a
proprietary one, has relatively few downsides (esp. compared to other
things you might do to reduce your risks).

Also of course buying a libre device has other wider benefits.

Ian.

Re: Request for official help

[Ian Jackson]

Steve McIntyre writes ("Re: Request for official help"):
> Looks good to me, but agreed also on the lawyer front.

Chris, could you please either nonexclusively delegate this issue to
me, or authorise me to contact Debian's lawers, and SPI, on Debian's
behalf, to ask them to review this letter (or some variant) ?

Jean-Phillippe, would this letter meet your needs ?

Ian.

Re: Request for official help

[Ian Jackson]

MENGUAL Jean-Philippe writes ("Re: Request for official help"):
> Here is the mail I could get in English. It sums up the situation.

Thanks.  This is very helpful.

As far as I can see:

 * Amazon seem to be concerned that products should not be sold
   on Amazon without an EAN, if the manufacturer in fact assigned
   (or will assign) an EAN.
 * Reading between the lines, Amazon also wants to avoid getting
   embroiled in trademark infringements.
 * Amazon think that manufacturers and trademark holders are
   always the same.  As a result, Amazon will probably be satisfied
   with a letter from Debian, even though Debian is not the
   manufacturer.

So I think the Debian project has the following options:

1. Write a letter like the one I propose below (NB this is
   slightly different to the original one proposed.)

2. Become an EAN issuer via something like this GSI website, and set
   up an arrangement for EAN issuance on behalf of manufacturers.

3. Become an EAN issuer and assign EANs for specific ISO files,
   with the expectation that all manufacturers of DVDs or whatever
   with the same contents, will use the same EAN.

4. Decide that Debian products should always be sold with EANs
   but that product manufacturers should acquire their own EANs
   somehow.

I think that (4) is unhelpful and I include it only for completeness.

I think (as previously discussed) that (3) is contrary to the intent
of the EAN system.  For example, one can imagine a hypothetical trade
fair where Debian DVDs from different manufacturers (maybe with
different cover art, different packaging, or different media quality)
are being sold, but via a unified checkout system.  If they have the
same EAN they aren't distinguishable by barcode.

Furthermore it would mean that a manufacturer couldn't make
hypothetical "Debian ISO - Enterprise Edition" with cover appealing to
idiots in suits, but with the same contents, and have the barcode at
the till distinguish it from the "Debian ISO - home edition" with a
colourful logo and a cheaper price.  That can't be right.

(2) is extra work.  Debian is desperately short of volunteer effort
for administrative stuff.  I don't think (2) would be a good use of
Debian's volunteer effort.

Therefore I propose that we should write a letter (1).  Draft below.
We should probably run this past a lawyer.

Ian.

  Debian Project
  

RE DEBIAN - EUROPEAN ARTICLE NUMBER (EAN)

To Whom It May Concern

The Debian Project ("Debian") and Software In The Public Interest ,
Inc (SPI) wish to make known that:

1. Debian, through its Trusted Organisations including SPI, own and
control the trademark "Debian" in various jurisdictions.

2. Debian does not provide European Article Numbers (EANs).  Nor do
any of Debian's associated organisations do so on Debian's behalf.

3. Debian and SPI give public permission for products embodying
Debian's software and documentation to be sold, according to the
Debian Trademark Policy (which can be found at
https://www.debian.org/trademark).  That policy doese not make any
requirement about EANs.  Therefore (provided the the policy is adhered
to) we have no objection to Debian branded products being sold without
EANs.

4. Debian do not anticpate this situation changing in the next 2
years.  Specifically, we do not expect to be issuing EANs within the
next 2 years.

5. Please therefore allow vendors of Debian merchandise to trade,
notwithstanding any lack of EANs for those products.

6. This is without predjudice, of course, to our right to enforce our
trademarks against anyone found violating our trademark policy.  We
are simply saying that lack of an EAN is, in itself, completely fine.

Signed

for the Debian Project  for Software in the Public Interest




Debian Project Leader   corporate Secretary

Re: Request for official help

[Ian Jackson]

MENGUAL Jean-Philippe writes ("Re: Request for official help"):
> Le 25/07/2017 à 20:36, Ian Jackson a écrit :
> > Henrique, can you please point me to the documentation about these
> > exemption letters ?  I continue to think that this is perhaps the
> > right route, but that your proposed letter wording is backwards.
> 
> Probably, hence my submission to the community.

Right.

> ok but this approach enables to ask a more fundamental question then. Is
> Debian a trademark?

Yes.

> If it is, Debian is the manufacturer of the Debian
> ISOs, and then of the OS.

An "ISO" is a file, not a physical object.  "The OS" is a collection
of data.  Debian is the originator of the Debian image ISOs and of the
Debian operating system.  But because ISOs, and the Debian operating
system, are not physical objects, they are not manufactured.  There is
no manufacturer.

Physical DVDs containing a copy of the Debian ISOs *are* physical
objects.  Their manufacturers are the people who arrange for, or
perform, the production of those physical objects (eg by burning the
DVD, or mass-producing them in presses, or whatever).

Debian has publicly licenced its trademark.  We give our legal
permission for the name "Debian" to be applied to such physical
objects when they are sold.

>  So it should have EANs to enable others to
> sell its OS on their support. If it is not, it means that, for example,
> Hypra could say: Hypra is a trademark (there is all a pocess for it in
> Amazon). From this trademark, we sell Debian products, which are from us
> (manufacturer) and then we can ust freely the trademark. And sell hen
> Debian-Hypra for example, eg Debian OS+DVD costomized by Hypra on their box.

I don't understand the connection between EANs and trademarks.

Does Amazon's EAN system assume that the manufacturer of goods is
always the same person as the trademark holder ?

> > So I think the "right" way for the EAN system to operate in this case,
> > if it is to be operated at all, is for each manufacturer to get a
> > different EAN for each product.  If manufacturers find registering
> > with the EAN system too cumbersome then surely we can look into using
> > our institutional resources to help.
> 
> The only problem of this is that payment is needed and I have to say I
> am not fan of paying for EANs.

Something like the EAN system probably costs money to administer.  We
pay for domain names and things too.  If the payment is too large for
a single vendor to be economic maybe we can effectively amortise it
across multiple vendors.

> > Can someone show us the agreement we (or SPI or FFIS or some other TO)
> > would have to sign if we were to become an issuer of EANs ?  Perhaps
> > we can simply do that and have an easy way for a Debian vendor to get
> > an EAN from our allocation.
> 
> Debian can subscribe each year, for 85 euros, to gs1.org (we need to
> choose the country we want). Plus 100 euros, just once. It enables to:
> - have an access to 100 or more EANs
> 
> 85 euros is the anual cost for the organizations with less than 500K of
> budget.

I think Debian's annual expenditure is less than that, but it might
depend on whether we count Debconf.  I'm sure we could afford Eur85
per year.  I don't know whether we would have more than 100
organisations who would want EANs for Debian merchandise, but if we
did I think we could consider it a success and pay more money.

> cf http://gs1.org for more information

Can you please provide deep links to the relevant pages ?

(Also, what a horrible website.  Almost unreadable for me due to
pale-grey-onwhite disease, and at least some kind of
probably-cookie-related redirect breakage.)

Ian.

Re: Request for official help

[Ian Jackson]

MENGUAL Jean-Philippe writes ("Re: Request for official help"):
> Is it a problem if it is a French message?

I'll cope somehow :-).

Ian.

Re: Request for official help

[Ian Jackson]

MENGUAL Jean-Philippe writes ("Re: Request for official help"):
> Le 25/07/2017 à 23:59, Ian Jackson a écrit :
> > MENGUAL Jean-Philippe writes ("Re: Request for official help"):
> > Can you please point me to the documentation you are reading about
> > these letters ?
> 
> hmm I requested it, but they have no public URL for it. It is just a
> request they do per e-mail. I can produce a screenshot of mail il you want.

Can you forward me the email ?  Privately if you like.

Ian.

Re: Request for official help

[Ian Jackson]

MENGUAL Jean-Philippe writes ("Re: Request for official help"):
> The alternative is my initial proposal, more simple than others indeed:
> mentioning in an official letter that Debian will not get any EAN in
> next two years, and that Debian does not want Hypra to sell Debian
> without EAN. It does mean that anybody else cannot do it (anybody which
> want to sell with or without EAN do what they want), but not Hypra (and
> we agree of course), and it gives me the required base to request an EAN
> exemption to Amazon.

Can you please point me to the documentation you are reading about
these letters ?

Ian.

Re: Request for official help

[Ian Jackson]

Chris Lamb writes ("Re: Request for official help"):
> Henrique de Moraes Holschuh wrote:
> > Run that through some legal advice, though.  If "we" (Debian, SPI, etc)
> > get to be co-responsible for the actions of someone using our EANs with
> > permission [in some relevant juridisction], it is best to not have them
> > in the first place.

Henrique, can you please point me to the documentation about these
exemption letters ?  I continue to think that this is perhaps the
right route, but that your proposed letter wording is backwards.

> I'm inclined to agree… Jean-Phillipe, is there no other way you can
> ship these images? I would be very happy to write/sign some kind of
> "yeah this is really all fine" document but am wary of going doing
> some kind of official EAN registration thing that might tie us to
> .. well, who knows.

I think part of the problem here is the misunderstanding that Debian
is the manufacturer here.  We are not (except in the very limited
cases where Debian people make and sell Debian merchandise for
Debian's funds).

EANs usually refer to specific manufactured products, from a specific
manufacturer.  I don't think the EAN system is well set up for a
situation where a particular product can be manufactured independently
by multiple people.  (The products are presumably supposed to be
more-or-less identical: but of course different manufacturers might
use different DVD stock, or print with or without a picture on the
front, etc.)

So I think the "right" way for the EAN system to operate in this case,
if it is to be operated at all, is for each manufacturer to get a
different EAN for each product.  If manufacturers find registering
with the EAN system too cumbersome then surely we can look into using
our institutional resources to help.

Can someone show us the agreement we (or SPI or FFIS or some other TO)
would have to sign if we were to become an issuer of EANs ?  Perhaps
we can simply do that and have an easy way for a Debian vendor to get
an EAN from our allocation.

I'd also be interested to see what approach is taken for physical
prints of 3D models, which have certain similarities to (say) Debian
DVDs in this context.

Thanks,
Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Request for official help

[Ian Jackson]

MENGUAL Jean-Philippe writes ("Re: Request for official help"):
> Any vendor then has threee solutions:
> 
> 1. Getting from Debian an official letter (see attached template) to
> say: a) we don't want any seller to send Debian without an EAN on a
> marketplace; b) we will not get our own EANs in the next two
> years. Such letter enable vendor to request for an EAN exemption
> laid on it.

This is odd.  Are you sure about this - or have you dropped a "not"
somewhere ?

If Debian did not want you to sell without an EAN then why would that
mean you should get an EAN exemption allowing you to sell without an
EAN ?

That seems backwards.

Currently I don't think Debian has an opinion about EANs but it is not
likely that Debian will issue a statement saying that we do not wish
things sold without EANs.  After all, in fact, we are quite happy for
people to sell Debian CDs etc and we want to encourage that - EAN or
no EAN.

It is not part of our role to make statements supporting (or opposing)
the EAN system.  OTOH we should do what we can to make it easy for
people who want to use such a system wrt physical artefacts embodying
or related to Debian.

> 2. Buying an EAN, but it does not worth to sell several things (eg
> architecture, live, installers, etc).

Why are EANs expensive ?  Is it that getting an EAN prefix is
expensive ?  Are there not arrangements for subdelegation ?

Also, is it really the case that Amazon Marketplace requires
everything sold to have an EAN ?  That seems quite unlikely.  There
must be lots and lots of small manufacturing (not to say "craft")
businesses who don't engage with this bureaucracy.

> 3. Getting an EAN from Debian organization itself, eg. on
> 
> www.gs1.fr. Debian thus would pay for EANs for his releases, etc, and vendors 
> would use them to sell Debian medias. But would be somewhat expensive and not 
> sure it is useful and project-compliant.

I don't think there should be a single EAN for multiple different
physical manufacturing chains even if notionally-identical bits,
particularly as Debian would have no way of verifying or controlling
the content.  So this does not work.

Ian.

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

[Ian Jackson]

Sean Whitton writes ("DEP 15: Reserved namespace for DD-approved non-maintainer 
changes"):
> I am hereby reserving DEP number 15 for my draft DEP, "Reserved
> namespaces for DD-approved non-maintainer changes".
> 
> I'd like to suggest discussing this DEP on d-devel (which is the
> Reply-to for this e-mail).  The canonical DEP text is at
> <http://dep.debian.net/deps/dep15/>.
> 
> The drivers are myself and Ian Jackson, who came up with the idea, but I
> said I'd write up the formal proposal.

Thanks, Sean.

For others: this was prompted by a conversation Sean and I had in a
pub on Monday.

Before we get into a detailed discussion here on -devel I think it
would be worth Sean and me getting the DEP draft into some kind of
reasonable shape that we both agree on.

So I won't reply in detail to the comments.

Ian.

Re: If Debian support OS certification?

[Ian Jackson]

Paul Wise writes ("Re: If Debian support OS certification?"):
> For Debian I expect your proposal "do not require loading externally
> supplied non-free firmware" is something that most of Debian can agree
> is a reasonable endorsement target for now.

Yes.

I think this is rather unfortunate for all the reasons you set out in
your mail, but I can't see a politically workable alternative bright
line.

> > Otherwise, we'll have to display different types of logo, like "works
> > with Debian ... but", and then that starts to confuse users, which is
> > counter-productive.
> 
> I think for hardware that doesn't support whatever criteria we come up
> with, we just wouldn't have a certification logo but would say "this
> hardware is *not* Debian certified because ..., but can run Debian if
> ...". For "certified" hardware we would include the logo and say "this
> hardware is Debian certified, but you need to be aware of these
> proprietary components and what their capabilities are".

I think this is a very good idea.

A trustworthy certification report that said "this machine would have
passed the certification, except that the wifi card requires a
separately supplied firmware blob from Debian non-free" would be
extremely useful to many users and potential purchasers.

I wonder if we could have a certification level (and associated name,
logo, etc.) that specifically permits exactly this kind of deviation.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: If Debian support OS certification?

[Ian Jackson]

Paul Wise writes ("Re: If Debian support OS certification?"):
> On Wed, May 17, 2017 at 12:18 AM, Thomas Goirand wrote:
> > If we made such a decision, I'd be very supportive of it. We could make
> > it in a "soft" way, ie tell that we accept some kind of (re-occurring?)
> > sponsorship, and providing a range of acceptable payment. We could make
> > such payment not completely mandatory, but strongly recommended. I'm
> > convinced that, with proper wording (meaning someone *else* than me
> > would attempt it, as I don't think I'd be the best person to write such
> > thing), it would work, and help the project to find more sponsors.
> 
> I think it would be acceptable for the certification process to
> promote donating to Debian and or becoming Debian partners, but not to
> make the certification conditional on payment. That seems to be what
> you are saying here.

I would be in favour of asking for payment.

The work of actually doing the testing is tedious.  If we think people
should be doing that, they should be paid for their time.

We shouldn't be expecting hardware vendors to self-certify.  That is
an invitation to trouble.  We don't have the effort to properly audit
such a thing.  (See above.)

I think the only sensible structure is probably for us to outsource
the certification testing, and administration.  There must be at least
only mildly-useless corporations who could handle this for us.  Of
course the Debian project could contract with some of our existing
contributors, but I think we should engage in a proper supplier
selection process.

I suggest we would set the testing fee to cover the price we pay the
outsourced contractor, plus a 10% donation to Debian.

Ian.

Re: Debian contributor Register of Interests

[Ian Jackson]

Paul Wise writes ("Re: Debian contributor Register of Interests"):
> Perhaps what we need is a a culture of awareness of our own personal
> potential conflicts of interest and guidelines for disclosure (where
> relevant) and examples of conduct that is not appropriate.

Yes.

> Personally, I disclose in the Sponsors section of my activity blog
> posts which aspects of my involvement in FLOSS were influenced by
> employers. I usually mention in bug reports when I've filed a bug
> because of issues experienced by employers. I haven't mentioned
> employers in commit logs or debian/changelog though.

I (usually[1]) use my work email address (eg, in signed-off-by) when I
make contributions which were driven by my employment.

Ian.

[1] Sometimes I fail to do so through oversight, or because I have to
work around busted work email systems.

Re: Debian contributor Register of Interests

[Ian Jackson]

Tollef Fog Heen writes ("Re: Debian contributor Register of Interests"):
 Ian Jackson :
> > From Debian's point of view: I think that anyone who takes prolonged
> > employment with an organisation which takes an active interest in
> > their Debian work, to the extent of taking an interest in what they
> > say about Debian and Free Software, ought to declare that.
> 
> My employer pays for me to go speak at Debconf.  I'm not sure if that
> passes that bar or not.

Certainly it does.  There are things you might reasonably say in a
Debconf talk, or topics that you might choose, that many employers
would object to.

It may be that there are no things you might feel like saying that
you think your employer would actually object to.  But of course that
depends on your assessment of your relationship with your employer.
People outside that relationship aren't privy to the conversations you
have with your management.  And they may have a different view about
your employer's overall trustworthiness than you do.

> > >  An example of what I do think could cause conflicts of interest is
> > > where I'm part of some community (free software or not) and my
> > > interest is in ensuring I have a good standing or status in that
> > > community and this colours judgements I make in Debian.
> > 
> > Most of the communities like that I am part of, are either
> > sufficiently remote from software that they wouldn't care, or are
> > themselves technology projects.
> > 
> > In the latter case, most of the information is already public.  It
> > would be impractical and pointless to ask everyone to collate it.
> 
> Isn't that what the wiki page is about?  Else, you're saying I should
> put nothing on there, since it's all public already.

I think we are still exploring the question of scope in this thread.

As I said earlier, I think substantial financial interests, including
employment in particular, are special.  (They may also, in general,
not already be public for everyone.)

Ian.

Re: should debian comment about the recent 'ransomware' malware.

[Ian Jackson]

I agree with your conclusion that we shouldn't make a public statement
trying to capitalise on this, but:

Russ Allbery writes ("Re: should debian comment about the recent 'ransomware' 
malware."):
> This is not a case where Microsoft did something clearly wrong, or even
> differently than we would have done, or where free software would have
> helped significantly.

I can't let this slide.

If these systems were running Debian, big organisations like the
British government could hire people to provide security support for
their users, even for versions which we no longer support.  When the
obsolete operating system is Windows, they can only hire Microsoft,
who can set the price at whatever they think the market will bear.

As it happens this particular vulnerability was indeed fixed by
Microsoft, and that the UK NHS suffered so much is because of
government and management failures[1].  But in general, users who for
any reason are stuck on very old systems are in a much better position
if those systems are free software.

Also, Debian's engineering approaches mean it's easier to support
obsolete environments, eg via chroots and/or mixed systems and/or
selective backporting.

Ian.

[1] The NHS has been seriously underfunded and can't afford to hire
enough good IT people (or indeed enough medics); and there has been a
drive to replace IT systems with massive centralised IT disaster
projects, which has starved existing systems of attention and
resources.

Re: Debian contributor Register of Interests

[Ian Jackson]

Tollef Fog Heen writes ("Re: Debian contributor Register of Interests"):
> Indeed.  I also think there's a hang-up about financial conflicts of
> interest in the discussion, but for at least me (and I suspect others),
> money is a pretty weak motivator.  I generally have enough that it's
> something I don't need to spend much mental energy on.

That makes sense.

But these things can change.  If you don't have enough money then it
can be a very powerful motivator.  Worry about (say) losing one's job
can be pretty significant.  For me, being employed to work on free
software means an inevitable tension between the interests of my
employer, and my own views.  Indeed such difficulties contributed to
my need to depart from Canonical.

>From Debian's point of view: I think that anyone who takes prolonged
employment with an organisation which takes an active interest in
their Debian work, to the extent of taking an interest in what they
say about Debian and Free Software, ought to declare that.

Contracting is a bit different.  I wouldn't expect a contractor to
declare the names of all their clients.  OTOH if a client's scenario
motivated a particular software change, I would expect that to be
mentioned even if the name of the client is not.

The main reasons why money is different seem to me to be:

 * Money-related situations often involve significant power imbalances
   where the individual is subject to the opinions of a payer.

 * Money-related interactions are often kept secret.

>  An example of what I do think could cause conflicts of interest is
> where I'm part of some community (free software or not) and my
> interest is in ensuring I have a good standing or status in that
> community and this colours judgements I make in Debian.

Most of the communities like that I am part of, are either
sufficiently remote from software that they wouldn't care, or are
themselves technology projects.

In the latter case, most of the information is already public.  It
would be impractical and pointless to ask everyone to collate it.

I don't intend to declare my membership of political pressure groups
etc., unless I get appointed to lead one or made a political party's
election candidate, or something.  But those folks don't really have
an opinion about my Free Software work.

That I'm a GNU maintainer, upstream for various other programs, the
operator of chiark, and so on, is all public anyway.  A register of
interests ought not to be a list of everyone's software projects, nor
of all of their hobbies.

Ian.

-- 
Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Debian contributor Register of Interests

[Ian Jackson]

Didier 'OdyX' Raboud writes ("Re: Debian contributor Register of Interests"):
> That said, I still think that there are situations in which declaring one's 
> conflicts of interest _does_ matter, but I do expect the affected individual 
> to 
> either explcitly retract (or stay away) from the discussion, or declare the 
> conflict of interest at that point.

I try to always declare any conflict of interest I have (or may appear
to have) in a particular situation.  Where the interest is my
employer, I try to use my work email address (badness of email system
permitting).

Ian.

Re: Debian contributor Register of Interests

[Ian Jackson]

Jonathan Dowland writes ("Re: Debian contributor Register of Interests"):
> I'm not sure how to word it but I felt that it was appropriate to
> disclose that I work for Red Hat (Even though I do not work on RHEL
> or Fedora), since Red Hat produces something "similar" to Debian, or
> more specifically a third party could hypothetically allude that it
> was in Red Hat's interests for Debian to make a particular technical
> decision. (I didn't see this rationale on your list)

Yes.

I guess I missed out:

  * Being paid to work on free software more generally

> > I would like to settle the boundaries before we start populating the
> > list.
> 
> I respect that, but I hope that those who are happy to add
> themselves to the list as it stands are not dissuaded from doing so
> (in my view, I'd happily see the shape of the list evolve and adapt
> my entry to fit as necessary).

Right.

TBH I now think this may be too much work.  I guess I will just write
my own entry and we can see how it evolves.

> > The list should have a date at which the user's entry was last
> > updated and signed off by them as complete.
> 
> The former can be inferred from the wiki page history.

Well, it's a bit awkward.  And it just shows you the last edit, not
the last time the user themselves thought it was up to date.

Ian.

Re: Debian contributor Register of Interests

[Ian Jackson]

Jonathan Dowland   wrote:
> However in the interests of transparency I feel that a voluntary,
> opt-in "Register of Interests" is a good idea for the project. I feel
> that such a list (populated) would demonstrate the transparency and
> openness that are part of our project's values.

I think this is a good idea.

>> This is a voluntary, opt-in register of Debian contributor's "Interests"
>> (such as: employer).

It would be a good idea to make an annex, giving a list of kinds of
"interest" that do not need to be mentioned; and ones that should be
mentioned.

Things that are _not_ interests worthy of disclosure:

  * Holding positions of responsibility within the Debian project,
or a Debian Trusted Organisation

  * Involvement with political parties (even ones focusing on
technology or information rights)

  * Using Debian or one of its derivatives, on one's personal
systems

  * Holding positions of responsibility in Free Software projects,
other than positions of financial responsibility for projects with
assets or annual income of more than Eur1,000.

  * Mere membership of charities, pressure groups, industry
associations, etc.

Things that _are_ interests worthy of disclosure:

  * Being paid to work on Debian

  * Being paid to work on hardware that Debian runs on or might run on

  * Being in a position of influence or authority regarding technology
purchasing decisions.  Exceptions: your own personal purchasing
and that of your household and your friends; Debian and Debian's
TOs.; spends of less than Eur1,000 per year.

  * Holding a formal position of influence or authority in charities,
pressure groups or industry associations which relate to software
or computing hardware, information rights, or state-granted
information monopolies ("intellectual property").

I would like to settle the boundaries before we start populating the
list.

>> || '''User''' || '''Interest''' || '''From''' || '''Until''' ||
>> || JonDowland || Red Hat || 2015 || - ||

The list should have a date at which the user's entry was last
updated and signed off by them as complete.

Ian.

Re: Inappropriate content on planet.debian.org and need of evolution of documentation and CoC

[Ian Jackson]

shirish शिरीष writes ("Inappropriate content on planet.debian.org and need of 
evolution of documentation and CoC"):
> Please CC me as I'm not subscribed to the mailing list. Please excuse
> the non-brievity of the mail.
> 
> Couple of weeks back, I put up a blog post
> https://flossexperiences.wordpress.com/2017/03/30/the-tale-of-the-dancing-girl-nsfw/

I don't much read blogs, and I don't read planet, mostly because I'm
too old-school for that kind of thing.  But:

> Because the subject matter is mature and uncomfortable to many people
> my feed was turned off.

In response to your email, I went and visited that blog posting.

Thank you for the NSFW warning.  Due to that, I read your posting in
w3m.  That avoided me having sexualised imagery appearing on my screen
in the open-plan office I work in.

I agree with everything Russ said in his posting about "Safe for
work".  In particular, if I had been a reader of planet.d.o, and a
NSFW image had appeared on my screen, I would immediately have
reported it to the appropriate administrators and expected them to
remove it.  (After reacting in panic to hide the offending tab!)

I am much more relaxed about textual content.  I found the textual
content of your article fine from a policy point of view.  I have no
problems with extended philosophical musings on an aggregator like
p.d.o, so long as the rate at which they are posted is low enough that
they don't start to overwhelm other stuff.

Thanks,
Ian.

Re: contacting Debian is too easy to get wrong

[Ian Jackson]

Ritesh Raj Sarraf writes ("Re: contacting Debian is too easy to get wrong"):
> When a user asks for a question, most usually end up on a web
> forum. Developers mostly prefer monitoring hand-picked mailing lists
> only. That's where the disconnect is, in my opinion.
> 
> What we need is to relate these interfaces to one another.

I think the problem with user questions is even worse than that.

Many developers don't actually want to spend much (or any) time
answering user questions.  Partly for bad reasons; but also for the
very good reason that it doesn't scale.

Ian.