Re: A policy on use of AI-generated content in Debian

[Stefano Zacchiroli]

On Thu, May 02, 2024 at 08:21:28PM -0400, Tiago Bortoletto Vaz wrote:
> So I'm actually more concerned about LLM being mindlessly applied in
> our communication processes (NM, bts, debconf, irc, planet, wiki,
> website, debian.net stuff, etc) than one using some AI-assisted code
> in our infra, at least for now.

On that front, useful "related work" are the policies that scientific
journals and conferences (which are exposed *a lot* to this, given their
main activity is vetting textual documents) have put in place about
this.

The general policy usually contains two main points (paraphrased below):

(1) You are free to use AI tools to *improve* your content, but not to
create it from scratch for you.

This point is particular important for non-native English speakers,
who can benefit a lot more than natives from tool support for tasks
like proofreading/editing. I suspect the Debian community might be
particularly sensible to this argument. (And note that on this one
the barrier between ChatGPT-based proofreading and other grammar/
style checkers will become more and more blurry in the future.)

(2) You need to disclose the fact you have used AI tools, and how you
have used them.

Exactly as in your case, Tiago, people managing scientific journals and
conferences have absolutely no way of checking if these rules are
respected or not. (They have access to large-scale plagiarism detection
tools, which is a related but different concern.) They just ask people
to *state* they followed this policy upon submission, but that's it.

If your main concern is people using LLMs or the like in some of the
processes you mention, a checkbox requiring such a statement upon
submission might go a longer way than a project-wide statement (which
will sit in d-d-a unknown to n-m applicants a few years from now).

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . https://upsilon.cc/zack  _. ^ ._
Full professor of Computer Science  o o   o \/|V|\/
Télécom Paris, Polytechnic Institute of Paris o o o   <\>
Co-founder & CTO Software Heritageo o o o   /\|^|/\
https://twitter.com/zacchiro . https://mastodon.xyz/@zacchiro   '" V "'

Re: Debian infra services and tools looking for programming contributions

[Stefano Zacchiroli]

Heya, thanks for this initiative!

On Thu, May 21, 2020 at 03:36:15PM -0300, Antonio Terceiro wrote:
> I'm planning a talk titled "I'm a programmer, how can I help Debian?" in
> which I intend to present contribution opportunities for people who are
> programmers, but are not necessarily interested in packaging. My plan is
> to present several Debian infrastructure services and tools that could
> receive contributions, highlighting a few where contributions could have
> a larger impact in the community (IMO).
> 
> For services, my starting point is https://wiki.debian.org/Services For
> tools, I currently have a list of the ones I usually contribute to, but
> can add more.
> 
> Not the part where I need your help. I'm looking for people who maintain
> or contribute to a Debian infrastructure service or tool that could use
> some help with programming, have the availability to provide some
> mentoring for someone who is already a programmer but not necessarily
> already involved with Debian, and would like your project to be
> highlighted in such a talk.
> 
> If that's you, please reply to this message and provide some information
> about your service or tool. Package names are enough for tools in the
> archive, otherwise links/wiki pages/etc are appreciated. Please also
> mention a contact point (IRC channel, mailing list etc).

sources.debian.org, AKA Debsources, could use some help. I'm definitely
MIA on it, and the bulk of code maintenance is being assured by Mathieu
alone, including migration to Python 3 (thanks!). Having someone else
would be good, and I think it might be a piece of infra that might be
interesting to work on even for people that don't have a lot of Debian
insider knowledge.

Links:

- service: https://sources.debian.org/
- code: https://salsa.debian.org/qa/debsources
- bugs:
  
https://bugs.debian.org/cgi-bin/pkgreport.cgi?dist=unstable;include=subject%3Adebsources;package=qa.debian.org

Hope this helps and thanks again !
Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Re: Pride Month Discussion has Run its Course

[Stefano Zacchiroli]

On Sat, Jul 06, 2019 at 08:00:58PM +0200, Alexander Wirt wrote:
> But that is my personal mindset I am coming from. If such a mindset is
> outdated nowadays and not wanted anymore I offer to resign as a listmaster.

I think there are two separate aspects here. One is the "mindset" you're
discussing here, which I'm positive is shared by most in the project.
Another is explicitly pushing back against the DPL, whose constitutional
roles include "Lead discussions amongst Developers", when he asks gently
to please stop a discussion.

I'm sure that was not your intention, but to bystanders that gives the
feeling that you're undermining the DPL's authority, and gets in the way
of the DPL doing his constitutional job in this specific area. So,
personally, I'm torn here: I agree with your open discussion mindset,
but the main issue here was (as I understand it at least) of a different
nature.

No need to threaten resignation about this, I'm sure your work as
listmaster is still very much appreciated in the project (and certainly
it is appreciated by me).

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Re: Accessibility of Ledger Reports

[Stefano Zacchiroli]

On Wed, Jun 12, 2019 at 03:36:09PM -0400, Sam Hartman wrote:
> Well, in general, people are trying to share these reports in email, so
> I'm not quite sure how that would work.
> 
> But yes, GUIs or web UIs do work fairly well for this.

Can you check if Fava (a web UI for beancount) works well for you? There
is a demo link on the project homepage:

  https://beancount.github.io/fava/

I'm asking because together with Martin we have a very effective bridge
from ledger to beancount, so that might be another viable option to
access Debian-reported ledger reports. (It's, in fact, also my preferred
solution for browsing my family ledger books.)

Cheers

PS if, OTOH, you want to give it a try locally:

  apt install ledger2beancount python3-fava

-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Re: metaphors and feminism

[Stefano Zacchiroli]

On Sat, Mar 30, 2019 at 08:31:48PM -0400, Sam Hartman wrote:
> I always assumed debian member was a term that included developer and
> maintainer.

In the Constitution, "Debian [Project] Member" is used as a synonym of
"Debian Developer". Hence it doesn't include Debian Maintainers. We
discussed this when we generalized project membership to non-uploading
(an unfortunate name in itself). The only more generic thing that we
have historically used is "Debian Contributors", which is not formalized
anywhere AFAIK, but is used in a bunch of official services, e.g.,
https://contributors.debian.org .

Cheers
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader & OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Debian contributors survey - preliminary analysis available

[Stefano Zacchiroli]

Hi everybody,

this is just to let the Debian Project know that preliminary analysis of
the results of the Debian contributors survey we ran last December are
now available at:

  https://upsilon.cc/debian-survey-2016/

(Note that since we didn't, on purpose, ask for participant emails, we
 have no direct way to inform each of them about results availability.
 The above URL was announced at the end of the survey though, so the
 participants who reached the end of the survey have a chance of
 eventually finding out. Of course feel free to spread the news to
 anyone you think might have participated in the survey.)

The above is just a preliminary analysis, with no discoursive commentary
yet, but it gives a statistical overview of the entire response set, as
well as drilling down into the specific sub-group of (uploading) Debian
Developers.

Enjoy!
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Re: Replace the TC power to depose maintainers

[Stefano Zacchiroli]

On Tue, Dec 06, 2016 at 02:29:13PM +, Ian Jackson wrote:
> Can we come up with some way whereby the maintainership authority is
> always shared, somehow ?

The net result of this would be that anyone who maintains packages in
Debian will do so as part of a team. Likely, people maintaining more
than one package will end up being part of several teams.

In such a hypothetical world you seem to be persuaded that, within all
those teams, people will generally learn to work together amicably and
find ways to avoid stepping on each other toes. This definitely matches
my teamwork experience in Debian --- Sometimes you, as a team member,
are confident you're doing the right thing, and will just go ahead and
make a change. Sometimes you'll have doubts and ask before acting.
Sometimes you'll screw things up, and either you'll clean up after
yourself or someone else will do so for you (when this happens, cursing
will be involved).

So my question here is: why would someone who has learned to work
amicably *within* the boundaries of several teams, will behave any
different *across* those boundaries, when contributing to packages that
belong to other teams? I think the behavior will be the same. So, if we
go down this path, I'm not sure why we should stop at teams, instead of
just having the de facto equivalent of "Maintainer: Debian" for all
packages.

*Of course* there will be conflicts, but it is absolutely not clear to
me why they would be any worse, or any more frequent, than the conflicts
we have today within (potentially very large) teams.

[ As a caveat: the "Maintainer" field currently acts as both a contact
  point for a given package, and as "fences" separating who is allowed
  to contribute without asking for permission and who should ask first.
  I'm advocating only against the latter meaning, not the former. But
  the former can be implemented in other ways. For instance, Nicolas
  Dandrimont pointed me to the fact that Fedora uses as contact point a
  list of the most recent N committers to any given package. Which
  sounds like a great solution. ]

Cheers.
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Re: Replace the TC power to depose maintainers

[Stefano Zacchiroli]

On Thu, Dec 01, 2016 at 03:46:05PM +, Ian Jackson wrote:
> 3. Abolish maintainership entirely.

This is the obviously right solution.

Everything else would be a temporary work-around to inefficiencies and
bugs introduced by the existence of explicit maintainership.

With explicit maintainership Debian is ignoring well-known software
engineering best practices, and most notably the fact that "strong code
ownership" is bad and invariably gets in the way of effective
collaborative development.

We should go for "weak code ownership" instead, which *in theory* is
what we already have (given every DD can NMU any package), but the
*culture* of strong ownership is so rooted in the project that people
are still too afraid of using it. Also, we don't have good tools[^] that
make it trivial to integrate back changes that have been NMUed by
others; again, getting in the way of efficient collaboration.

I'm personally convinced that a strong, symbolic act is needed to
actually make weak code ownership a reality in Debian. Abolishing the
Maintainer field all together[*] might be it.

Revolutionary yours,
Cheers.

[^] well, we have dgit, but AFAICT is not really popular yet
[*] together with making sure that any DD can commit to any public repo
    on alioth
-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

[fwd: call for participation - Debian contributors survey, 1st ed.]

[Stefano Zacchiroli]

This was originally posted to debian-devel-announce minutes ago. I'm
forwarding it to debian-project in order to reach out to
non-Debian-Developers contributors.

Cheers.

- Forwarded message from Stefano Zacchiroli <z...@debian.org> -

TL;DR: all Debian contributors --- from bug reporters to Debian project
members and participants in any Debian team --- are invited to take part
in the first edition of the Debian contributors survey. To participate
visit:

  http://debian.limequery.org/696747

The deadline for participation is: 4 December 2016, at 23:59 UTC.



This is the first instance of what we hope will become a recurring
annual survey of Debian contributors. The survey is intended to help the
Debian project and community by enabling them to understand and document
the evolution of the project's population over time, through the lenses
of common demographics.

In addition, each year the survey will explore a specific aspect of the
project. The focus for this first edition is on work and labour issues,
specifically on the extent to which Debian contributors are volunteers
or paid to work on Debian, and on how that affects their contributions.

Participation in the survey is completely anonymous, with no logging of
any provenance information (e.g., IP address, HTTP referrer), and all
questions are optional.  The survey is conducted using the Free Software
platform LimeSurvey and hosted by LimeSurvey.org.  The results of the
survey will be analyzed as part of ongoing research work by the
organizers and released in aggregate form only. A report discussing the
results will be published under a DFSG-free license and distributed to
the Debian community as soon as it's ready. The raw, disaggregated
answers will not be distributed and will be processed under the
responsibility of the organizers.

The survey will remain open until: 4 December 2016, 23:59 UTC.

If you have any questions, you can always reach the survey organizers
at:

- Mathieu ONeil (mathieu.on...@canberra.edu.au)
- Molly de Blanc (debl...@riseup.net)
- Stefano Zacchiroli (z...@debian.org)

We thank you in advance for your participation!

For the organizers,
- End forwarded message -

-- 
Stefano Zacchiroli . z...@upsilon.cc . upsilon.cc/zack . . o . . . o . o
Computer Science Professor . CTO Software Heritage . . . . . o . . . o o
Former Debian Project Leader . OSI Board Director  . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Re: Publicly-readable list for only DDs and DMs to post to

[Stefano Zacchiroli]

On Mon, Jul 18, 2016 at 05:46:46PM +0100, Ian Jackson wrote:
> In any case, with the renewed opposition here I'm certainly not going
> to push this issue unless there are others who agree with me and
> disagree with the views of others posted so far.

I agree what you proposed would be an interesting experiment to carry
on.

Debian is committed to openness and transparency, not to empower anyone
who has an opinion on the Internet voice it in every possible Debian
forum. Also https://xkcd.com/1357/ (the "Free Speech" one).

I'm also absolutely unconvinced by the "raising the barrier of entry"
argument.  First of all what you're proposing is not replacing any
existing communication forum; it's increasing their number, not making
it harder for anyone out there to contribute.  Second, I don't buy that
posting to a public mailing list is necessarily a contribution; it might
be, or it might be not. In almost all cases where it actually is a
contribution, I can see it being more helpful and better tracker if it
is sent elsewhere, and most notably our BTS---which you're not proposing
tightening in any way. Sure, there would be cases where a mail from a
non-DD/DM is a useful contribution and we would be making it hard to
receive it, but the price we are currently paying for empowering those
(IMO very rare) contributions is likely reduced participation by DDs/DMs
that feel overwhelmed, if not scared, by the kind of traffic we
currently have on -devel.

Plus, I love having data to base decisions on. And we currently have no
idea of how such a list would work out. Let's just try it as an
experiment and see how it goes.

I won't have time/energy to push for this idea more than this. But if
you were in need of gentle encouragement... here you go :-)

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Re: Proposed GR: Acknowledge that the debian-private list will remain private

[Stefano Zacchiroli]

On July 7, 2016 4:48:19 PM GMT+02:00, Didier 'OdyX' Raboud  
wrote:
>Point is; only "Developers" (the term our constitution uses) are 
>supposed to ever have been subscribed to d-private.

JFTR: the Constitution uses both "developers" and "members", interchangeably.

-- 
Sent from my mobile phone with K-9 Mail. Please excuse my brevity.

Re: Software Freedom Conservancy needs our cash

[Stefano Zacchiroli]

On Tue, Dec 01, 2015 at 11:44:34AM -0800, Russ Allbery wrote:
> I thought we paid a retainer to the Software Freedom Law Center, not the
> Software Freedom Conservancy.  Am I confused?

I'm not aware of any retainer paid to Software Freedom Law Center (SFLC)
directly by Debian. SFLC is Debian's lawyer "transitively", via the
services that they offer to SPI's affiliated projects. It might be the
case that SPI's pay legal services to SFLC, but I really don't know.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Re: Software Freedom Conservancy needs our cash

[Stefano Zacchiroli]

On Tue, Dec 01, 2015 at 03:17:33PM +0100, Raphael Hertzog wrote:
> Let's give them a part of our money for the service they do us by
> enforcing the GPL for Debian developers.

We already pay for those services. There is a forfait amount of money
that Debian pays to Conservancy per year (1000 USD, IIRC), which
corresponds to a forfait amount of lawyer hours that Conservancy give to
Debian per year. If any enforcement (or other legal) action will require
more than those hours, Conservancy will bill Debian for the extra time.

If we want to donate to Conservancy, it should be on a different basis
than paying for the services we get from them, because those are
regulated on a contractual basis.

FWIW, I'm a conservancy supporter and also a testimonial for their
current fund raising campaign. But I'm against "transitive donations" of
money that Debian received as donations to other charitable initiatives
because, e.g., there is no reasonable guarantee that the goals of
Conservancy align well with the reasons why the initial donor gave money
to Debian.

Also, in this specific case, I don't think that significant one-shot
donations is what Conservancy needs the most in the current situation
(even though of course I don't and can't speak for the organization).
What they need is to build a significant basis of individual supporters
that will, on average, remain supporters in the long term.

So if Debian really wants to help Conservancy, promoting their current
campaign for individual memberships would be a very useful thing to do.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: PGP signature

Re: Software Freedom Conservancy needs our cash

[Stefano Zacchiroli]

On Tue, Dec 01, 2015 at 03:52:35PM +0100, Jakub Wilk wrote:
> >We already pay for those services. There is a forfait amount of money that
> >Debian pays to Conservancy per year (1000 USD, IIRC), which corresponds to
> >a forfait amount of lawyer hours that Conservancy give to Debian per year.
> 
> What does "forfait" mean?

Oops, sorry.
I realized too late the expression doesn't work in English :)

It means we pay that sum per year, and we have pre-allocated to us a
given amount of lawyer hours each year. If we use more, the difference
is billed to us.

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »

Re: cdimage?? What should we call it?

[Stefano Zacchiroli]

On Tue, Aug 18, 2015 at 11:20:38PM +0100, Steve McIntyre wrote:
   - get.debian.org
 I think it's a cool name, and my clear favourite thus far. :-)

FWIW, same here. It's a verb, short, straight to the point, and
memorable. I don't see the point of looking elsewhere :-)

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Debian Project Leader Elections 2015: Call for nominations

[Stefano Zacchiroli]

On Wed, Mar 04, 2015 at 08:06:11PM +0100, Debian Project Secretary - Kurt 
Roeckx wrote:
 | Nomination | Wednesday, March  4th, 2015 | Tuesday, March  9th, 2015 |
   ^

The above should rather be Tuesday, March 10th, right?

TIA,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: What do you expect from the DPL?

[Stefano Zacchiroli]

On Sat, Feb 14, 2015 at 10:07:08AM +0100, Lucas Nussbaum wrote:
 My own view on the original question (What are you expected the DPL to
 do?) is that the main thing the DPL must absolutely do is being a good
 garbage collector (I think the original naming comes from Zack).

Possibly. I think I actually used decision garbage collector, but the
notion is exactly the one you explained.

FWIW, that aspect of the DPL job seems to be frequently overlooked in
DPL candidate platforms, which often tend to focus on ambitious Debian
reform plans. They are all fine and well of course, but DPL time will in
the end have to be split among implementing those plans and tending to
often unpredictable day by day duties, with the latter often dominating
the DPL agenda (IME).

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: What do you expect from the DPL?

[Stefano Zacchiroli]

[ just pointing to some related work / previous discussion on this topic ]

On Thu, Feb 12, 2015 at 09:57:04PM +0100, Ana Guerrero Lopez wrote:
 This is, globally, people are expecting the DPL to do all of the above and 
 maybe
 more. I think it's clear this is NOT humanly possible. What are the 
 alternatives?
 Should we redefine the role of the DPL? Should we maybe split the role of the
 DPL in a few elected roles? Should we discuss (again) the possibility of
 replacing the DPL for a board? Sometimes I have felt like the DPL election was
 a popularity contest, and that's probably not what it should be.

I've in the past analyzed this problem, and presented some thoughts in
my bits from the DPL talk at DebConf12. Slides are at
https://upsilon.cc/~zack/talks/2012/20120708-dc12-dpl.pdf (second part
of the deck, challenges ahead). The talk video is at
http://meetings-archive.debian.net/pub/debian-meetings/2012/debconf12/low/881_Bits_from_the_DPL.ogv
; the relevant part starts around minute 29:30. I haven't watched the
video, but IIRC the board idea has raised quite a bit of interest in the
audience, and spawned several questions during the question time.

Thanks Ana for raising this very important topic!

Hope the above helps,
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Alternative proposal (+call for seconds): Expire 2-R members every year

[Stefano Zacchiroli]

On Sun, Dec 07, 2014 at 02:55:23PM +0100, Lucas Nussbaum wrote:
 Your scenario describes a case where a member of the TC fullfills their
 voting duties, but does not otherwise really participate in TC work.
 This can happen, but I don't really see a correlation between this
 happening, and the seniority of that specific TC member.
 
 One could imagine a scenario where a recently-appointed TC member goes
 semi-MIA very early, and still stay on the TC for 4 years. After all, in
 Debian teams, people go MIA for various reasons, and this is not
 correlated with their seniority in those particular teams.

We don't have date for this either way, but I'd say (as gut feeling /
experience in various teams) that yes: the likelihood of going MIA is
very much correlated with seniority in any given team. Intuitively,
that's also very easy to explain: when you join a team, you do so
because you're enthusiastic about it; with time passing, boredom kicks
in. After all, that's why team rotation is an encouraged practice in
many large-scale organization.

 Also, if the version of the GR I proposed gets chosen, I hope that the
 fact that resignations or removals can 'save' other members from
 expiration will result in yearly discussions where the status and
 activity level of each member gets reviewed, which could actually help
 address the general problem of semi-MIA TC members.

Discussions about under-performing fellow team members are very
difficult/awkward in general, and even more so in volunteer
organizations where we are all peers. This is why I'm convinced that an
automatic, non-optional expiry method would actually be a plus, rather
than a hindrance.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: GR proposal, Call for Seconds - term limit for the tech-ctte

[Stefano Zacchiroli]

On Mon, Dec 01, 2014 at 07:30:25PM -0300, Lisandro Damián Nicanor Pérez Meyer 
wrote:
  +6. If the Technical Committee and the Project Leader agree they may
  remove or replace an existing member of the Technical Committee.
 
 In the special case that a member is replaced, the new member resets it's 
 status or does him inherits the status of the one being replaced?

My take: from the point of view of the replacer that would be a new
appointment, so to me the only (reasonable) interpretation is that
seniority gets reset, as per the seniority rule in §6.2.

But even if the converse interpretation were to be in effect, the ctte
and the DPL can route around that by doing the removal first and then a
fresh appointment.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: GR proposal, Call for Seconds - term limit for the tech-ctte

[Stefano Zacchiroli]

On Tue, Dec 02, 2014 at 09:46:01AM +, Philip Hands wrote:
 It does not strike me as obvious that popularity correlates to
 competence.  Also, it would not be helpful if members of the committee
 were tempted to take the popular side of an argument, against their
 better judgement, because they were coming to the end of their term,
 and they would like to be reelected.

+1

All the usual arguments against elected judges in democracies apply
here, and I'm personally very much against the election of arbitration
bodies in general. If anything, the highly technical nature of a project
like Debian reinforces those arguments.

More importantly, it doesn't seem to me we're near having a concrete GR
proposal for electing ctte members. So IMO it would be best to
disentangle this discussion from the term limit GR proposal.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

GR proposal, Call for Seconds - term limit for the tech-ctte

[Stefano Zacchiroli]

[ Cross post -vote, -project ; M-F-T: to -vote.

  For more background information on the development of this proposal,
  see https://lists.debian.org/debian-vote/2014/11/msg00274.html ]

I'm hereby formally submitting the GR proposal included below between
dashed double lines, and calling for seconds.  With respect to past
discussions on the -vote mailing list, this is the proposal code-named
2-S; see [1,2] for (the last known versions of) alternative proposals.

[1]: https://people.debian.org/~zack/gr-ctte-term-limit/
[2]: http://git.upsilon.cc/?p=text/gr-ctte-term-limit.git;a=tree

===
The Constitution is amended as follows:

---
--- constitution.txt.orig   2014-11-17 18:02:53.314945907 +0100
+++ constitution.2-S.txt2014-11-21 16:56:47.328071287 +0100
@@ -299,8 +299,20 @@
Project Leader may appoint new member(s) until the number of
members reaches 6, at intervals of at least one week per
appointment.
-5. If the Technical Committee and the Project Leader agree they may
+5. A Developer is not eligible to be (re)appointed to the Technical
+   Committee if they have been a member within the previous 12 months.
+6. If the Technical Committee and the Project Leader agree they may
remove or replace an existing member of the Technical Committee.
+7. Term limit:
+ 1. On January 1st of each year the term of any Committee member
+who has served more than 42 months (3.5 years) and who is one
+of the two most senior members is set to expire on December
+31st of that year.
+ 2. A member of the Technical Committee is said to be more senior
+than another if they were appointed earlier, or were appointed
+at the same time and have been a member of the Debian Project
+longer. In the event that a member has been appointed more
+than once, only the most recent appointment is relevant.
 
   6.3. Procedure
 
---

As a transitional measure, if this GR is passed after January 1st, 2015,
then the provision of section §6.2.7.1 is taken to have occurred on January
1st, 2015.
===

I'd like to thank Anthony Towns for introducing the term limit idea
several months ago [3] and for his help in polishing it through several
rounds of feedback on the -vote mailing list.

[3]: https://lists.debian.org/debian-project/2014/05/threads.html#00054

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Can I still depend on Debian?

[Stefano Zacchiroli]

Thanks for your mail Joe,

On Mon, Nov 17, 2014 at 04:08:10AM -0600, Joe Neal wrote:
 The thing is, Debian seems to be self-destructing.  Can you blame me
 for wondering if I should upgrade my servers to Jessie when the time
 comes or migrate them to another distro entirely?

As a user, I think you should keep on judging Debian on the basis of the
quality of our products (Debian stable seems to be the product
you're most interested in), rather than paying too much attention to the
amount of Debian gossip that these days seems to be everywhere in the
Free Software tech news.

If Debian Jessie is good for you, use it. If it is not, don't.

In the meantime, as user, you can do plenty to help us helping you, in
maximizing the chances that Debian Jessie *will* be a good product, for
you and everyone else out there. You can for instance try upgrades to
the current testing, and report bugs against ugprade-reports [1] if it
didn't work for you; you can try fresh Jessie installations and report
bugs against installation-reports [2] to let us know how it went; you
can more generally just use the current testing and report bugs or
submit patches accordingly.

[1]: 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=upgrade-reports;dist=unstable
[2]: 
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=installation-reports;dist=unstable

In short: if you want to play your user part at its best, just focus on
Debian quality and how you can help in maximizing it. It's in your
interest, after all (and I suspect it will be overall less work for you
than migrating to another distro, YMMV).

If, OTOH, you'd like to get more involvement in Debian development,
we'll be more than happy to have you! And maybe at that point we can
discuss together more in depth about the current state of internal
discussions going on in the Debian Project, and how to improve their
quality.

All the best,
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: The proper place to announce GRs (was Re: piece of mind (Re: Moderated posts?))

[Stefano Zacchiroli]

On Mon, Oct 13, 2014 at 07:30:43PM +0100, Jonathan Dowland wrote:
 Whilst researching for a reply to a different post in this thread on
 -user (the thread sadly spans at least three lists), I realised that
 the constitution doesn't say where GRs should be announced, and I
 couldn't find any advice on the subject in a scan over policy, either.

FWIW, Constitution §4.2.5 says:

   5. Proposals, sponsors, amendments, calls for votes and other formal
  actions are made by announcement on a publicly-readable
  electronic mailing list designated by the Project Leader's
  Delegate(s); any Developer may post there.

Cheers,
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: DEP-5 (copyright file format) ... gap with practice

[Stefano Zacchiroli]

On Wed, Sep 10, 2014 at 11:48:38PM +0900, Osamu Aoki wrote:
 The debmake command (in python) offers such copyright file
 verification against the current source files by running it in the
 source tree as.

Thanks Osamu, I meant to check the implementation before replying, but
ran out of time before doing that --- so better ask here directly and
let others know than forget about this :)

Is debamake's implementation of this feature based on the same corpus of
well-known license paragraphs than that mentioned in this thread
earlier on? If so, I'd say that it would be best not to scatter that
corpus of information in multiple places, as divergences might be quite
annoying.

Or is debmake only comparing past debian/copyright declarations by the
maintainer with the licenses it can currently infer from the upstream
package? That would be tremendous help for the maintainer, but it's a
different issue than the one we are discussing here.

Finally, it's great that debmake can help maintainer with this, but
unfortunately that won't help maintainers which are not using debmake.
Given that lintian is a tool that all maintainers are supposed to use
(and also a tool for which we have a project-wide monitoring
infrastructure at lintian.d.o), I believe it'd be much better to
integrate in lintian these warnings, than to have them emitted by
various tools which are opt-in for individual maintainers.

That said, I'll definitely start playing with debmake -k on my own
packages and see how it goes :-)
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: DEP-5 (copyright file format) ... gap with practice

[Stefano Zacchiroli]

On Wed, Sep 10, 2014 at 10:01:42AM +0200, Jonas Smedegaard wrote:
 How about - instead of codifying into Polict that some licensing is ok 
 to ignore (which sounds very wrong to me) we instead recognize that some 
 pattern of files are very commonly the same across packages: Add a DEP-5 
 snippet to /usr/share/common-licenses that is always assumed included in 
 debian/copyright of any package.
 
 Concretely I propose the attached file for that.

Thanks a lot for your snippet!, I find it very helpful.

OTOH, the proposal of shipping it under /usr/share/common-licenses/
violates the self-containedness of copyright information, which is a
nice property to have.  (To some extent we already violate that property
by shipping some full license texts under /usr/share/common-licenses/,
but at least the information about the mapping file-license names is
currently expected to be available in the packages themselves.)

How about using your snippet to improve our packaging work-flows
instead? For instance, we can have a lintian check that verifies if
those files are present in the source package and emit a warning if they
are not listed (with the correct license) in debian/copyright.

Note that, thanks to the semantics of DEP-5, it is possible to do this
properly and avoid false positives also in the few cases where the files
are present in the source package but do not need explicit mention
(e.g., because their license matches the more general license of the
rest of the package).

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Maximum term for tech ctte members

[Stefano Zacchiroli]

On Fri, May 23, 2014 at 06:58:36PM +0200, Tollef Fog Heen wrote:
 ]] Anthony Towns 
  Would anyone else be supportive of a proposal to set a term for tech
  ctte membership?

Seconded as well.

I've a couple of contributions I wanted to make to this thread, even
though they've largely been superseded by Russ' comments :-). But
anyway:

- in this kind of reform discussions I find generally useful to
  distinguish two aspects: 1) the ideal model we want to have, 2) how to
  migrate from the current model to that. Entangling the two aspects
  usually make the status quo win over everything else, just because
  migration is hard.

  For the migration in this specific case, random assigning start term
  dates as suggested by Russ seems to be a brilliant idea.

- continuity is valuable in a body like the tech-ctte, where there
  aren't that many decisions on a yearly basis (and hence, for instance,
  it takes time to get new members up to speed). There might have been
  too much continuity in the current tech-ctte membership, but that's no
  reason to exaggerate in the opposite direction when introducing a
  turnover process.

  Based on examples I've recently witnessed in other organizations, I
  agree that a good model for the tech-ctte would be the one already
  mentioned by Russ (consecutive year limit + minimum suspension time),
  but with less stringent durations. I believe a maximum of 5 years in a
  row with a minimum 1-year suspension before being able to join again
  would work well for our tech-ctte.

- more generally, I think that all Debian core teams (if not *all*
  teams...) would benefit from a turnover process that requires
  individual members to reaffirm, on a yearly basis, their continued
  interest in keeping the role. This is to avoid that people remain on
  the team simply for inertia, even though they have no more
  time/interest for the corresponding tasks. It will also help
  developers in periodically reassessing/retargeting their Debian
  involvement, reducing the burnout risk.

  This is nothing specific to the tech-ctte, but they could probably
  benefit from it too.

My 2 cents,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Sponsoring a Tails hackfest?

[Stefano Zacchiroli]

On Sat, May 03, 2014 at 08:43:07AM +0200, Lucas Nussbaum wrote:
 Given that:
[snip]
 I am planning to allocate 5000 EUR.
 Comments?

+1

In addition to the good reasons above, I'd also like to add that Tails
is also being *exemplar* in how to be a good derivative citizen, see for
example:

  https://lists.debian.org/debian-devel/2014/02/msg01186.html
  https://tails.boum.org/contribute/how/debian/

Keep up the good work,
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: State of the debian keyring

[Stefano Zacchiroli]

On Mon, Feb 24, 2014 at 08:28:53PM +0100, Enrico Zini wrote:
 I think it would be useful to see an update to debian-devel-announce,
 explaining what's the current vulnerability status of 1024bit keys, and
 asking to please switch NOW.
 
 As a potential follow-up plan, I propose this one:

Seconded.  If I'm reading Clint's reports right, the aspect that worries
me the most is that in 1 month (the delay between the two reports) we've
only got 10 additional 4K keys, which is a very slow progress rate.

I agree with Enrico that the next step is communicating clearly to
project members the *urge* of switching, and I also agree that we should
actively nag people to do the switch.

Regarding the doc on the migration, I don't have clear proposals on how
to make it better, but I AOL other comments in this thread: I've been
misreading the text myself for quite a while (or maybe it did change and
I didn't notice? no idea) as mandating a third-party to request the
change. And I've been chatting with various DDs over time who were
postponing the change due to that extra step --- yes, I agree that's a
silly reason, but given the urge of migrating I think we should make the
procedure as simple as possible and make sure that people *know* it is
simple.

Just my 0.02 EUR,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: GR proposal: code of conduct

[Stefano Zacchiroli]

On Wed, Feb 12, 2014 at 11:45:05AM -0600, Ean Schuessler wrote:
 I hope many of you will agree that while the CoC may be a necessary
 feature for our community it should be governed in a transparent,
 policy-driven and unbiased manner with detailed record keeping and
 peer review.

I agree with your general reasoning here. For mailing list bans, I think
it's pretty straightforward to implement a mechanism that is up to the
accountability requirements you ask for: just publish bans, as requested
/ discussed in [1]. I don't think we need anything more than that. With
public bans one can review the actions of listmasters, without having to
force them to provide elaborate reasoning (which, as Don pointed out,
would be too bureaucratic with very little benefit, IMHO). If enough
people in the project are against a specific listmaster action, they can
resort to the usual mechanisms (e.g. a GR) to override listamsters.

I understand that there are drawbacks in public bans, as Don pointed out
as well. But as I've argued in [2] I think the benefits for the
community of publishing them outweigh the drawbacks.

For IRC it's a bit more difficult, because we do not long our IRC
channels by default (or at least I'm not aware we do), with the
exception of meetings run with the help of meetbot. That means that it
would be rather difficult for the moderators to point out to the
evidence on the basis of which they've banned someone.  I can't help
wondering if the solution to this shouldn't just be radical,
i.e. publicly log our IRC channels. A less invasive solution is to just
ask moderators to publish log excerpts that they think justify the ban.

[1]: https://lists.debian.org/debian-project/2013/10/threads.html#00090
[2]: https://lists.debian.org/debian-project/2013/10/msg00124.html
[3]: http://meetbot.debian.net/

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: [Proposal] GR: Selecting the default init system for Debian

[Stefano Zacchiroli]

On Mon, Jan 27, 2014 at 02:42:39PM -0500, Paul Tagliamonte wrote:
 I'd like to raise the objection that the TC hasn't done their job yet,
 and while the TC has done a great job of getting *true* technically
 grounded facts out yet, we've not let the process work.
 
 Let the TC do their work. They're coming up on a vote, and they may
 even suggest a GR.
 
 This GR is premature.

AOL.  For both the reason I mentioned in [1] --- which clearly Guillem
disagrees with --- and the reason given above by Paul.

Cheers.

[1]: https://lists.debian.org/debian-devel/2013/10/msg00821.html
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Debian services and Debian infrastructure

[Stefano Zacchiroli]

On Wed, Jan 22, 2014 at 11:07:49PM +0100, Tollef Fog Heen wrote:
  Since we discussed that back in June, you added 'providing an OpenStack
  cloud' on the DSA radar (it noticed that it was mentioned in the 'just
  starting' category of DSA meeting minutes).
 
 It's sgran who's been thinking about how to do this, but afaik he's seen
 close to zero interest from developers for it, so it's not happened
 yet.  I don't think we need anything from the DPL as such, but if people
 are actually interested in something like this happening, saying so
 would be a good start.

 The lack of feedback worries me a bit, since one one hand it seems like
 you're pushing quite hard for a cloud and all that, yet we're not seeing
 a user demand. It could be that people don't approach DSA for whatever
 reason (if so, we should fix that), but doing lots of work for something
 we don't know if it's needed doesn't sound like a good use of our time.

You're quite right on this.  On the other hand, as a random DD, I
wouldn't have dared asking DSA to set up a sort of Debian private cloud
(which I think would be a good idea in general) without knowing
beforehand that DSA had at least some interest in the idea. This is not
because I'm scared of approaching DSA or anything such, but because I
know that setting up such an infra could be a lot of work. In general,
Due to the way improvements are usually achieved in Debian, I'm much
more likely to ask fellow DDs to implement small changes (better if I've
patches to propose) than to ask them to do a lot of work for my needs.

But I certainly understand that DSA is not willing to work on something
substantial until you know there is enough demand to make it worth.

So, in the end, this sounds like a good match-making situation. If
you're worried about demand how about mentioning this in a future DSA
mail to d-d-a? (No, I don't think this thread is enough visibility,
especially considering the conflictual parts it went through.) Just ask
people that would potentially use this service to let you know.

I, for one thing, would be interested in something like this. To be
clear, I don't have anything which is currently *waiting* for this.
Looking back at the services I've recently worked on in Debian: it
wouldn't have been a good fit for sources.d.n (due to the large storage
requirement), but it would've been for the initial experimental phase of
pts.d.n and possibly (depending on how difficult it'll be to set up VMs)
also for fire-and-forget VMs we have used in the past as build nodes for
BSPs.

Just my 0.02 EUR,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Debian real-time communication (RTC) project - SIP

[Stefano Zacchiroli]

On Sat, Jan 18, 2014 at 09:11:51AM +0100, Daniel Pocock wrote:
 The Debian Project now has a SIP service available to all Debian
 Developers.  Your Debian.org email identity becomes your SIP address.

Thanks Daniel, and thanks DSA, I'm very happy about this new service.

Project-wide SIP is good for development reasons (voice talking could be
way more efficient than emails at times), that it is good for social
reasons (it could help in smoothing conflicts), and that it is good for
political reasons (it promotes federated ways of communicating).

I'm particularly proud that the Debian Project is trying hard to set an
example in the latter area.  For that reason I'm Cc:-ing the maintainers
of the Do they federate? page [1] to ask for an update of Debian's SIP
column there. To their benefit, the full context of this mail of mine is
at [2]. A good link for the SIP anchor on the page is probably [3].

Cheers.


[1]: http://freeyourspeech.org/do-they-federate/
[2]: https://lists.debian.org/debian-devel-announce/2014/01/msg4.html
[3]: https://wiki.debian.org/UnifiedCommunications/DebianDevelopers/UserGuide
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Updating the Policy Editors delegation

[Stefano Zacchiroli]

On Mon, Jan 06, 2014 at 03:38:46PM +0100, Lucas Nussbaum wrote:
 .oO ( funny that this comes up now, given the same delegation text was
 already used in
 https://lists.debian.org/debian-devel-announce/2012/10/msg6.html and 

*nod*

FWIW, the job description detailed in that delegation---which I
believe is the first that has been done with the current text---didn't
come out of the blue. It was discussed at length with the policy editors
back then. AFAICT it was consensual between me and them at the time.

This, of course, doesn't necessarily mean the text is bug-free or
non-problematic wrt the Constitution. Bugs happen. But it is what we
collectively believed to be a correct representation of the status quo
back then and of the powers that should be delegated to the Policy
editors.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Debian services and Debian infrastructure

[Stefano Zacchiroli]

On Sun, Jan 05, 2014 at 02:28:59PM +0100, Joerg Jaspert wrote:
  Q3. What should be our definition of official services?
  Even if this is highly preferable, I don't think that official services 
  (.d.o services) should necessarily be running on Debian hardware managed
  by DSA, provided that:
  - the service is clearly useful and used
  - the service has a sustainable maintainance model (active team +
instructions on how to contribute, run a local copy, etc. + DFSG-free)
  - the service's design does not raise security or scalability concerns
 
 I disagree on that, official services should run under project
 overview. So far that the project can take it over and move it, should
 all of the team go away. Active team today doesn't mean they are there
 tomorrow to properly hand it over. Having the project itself have
 access (via DSA at least) ensures it can continue.

I very much agree with Joerg on this.

A team like DSA offers to the Debian Project two key features. One,
which is the most visible one, is the technical output and continued
service of a team of talented sysadmins.

The other is the governance guarantee that we, as a project, can always
take over the maintenance of a service whose current maintainers go MIA
or become unwilling to work with the rest of the project for any reason.
As Joerg points out.

I understand that we can come up with a list of requirements that
diminish the risk. This is, I believe, what Lucas was trying to do with
the requirements quoted above. But I think it is much better to
centralize those requirements on a single, DPL-delegated team, than
trying to replicate that to many different, de facto self-proclaimed
teams.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: working with FSF on Debian Free-ness assessment

[Stefano Zacchiroli]

On Wed, Dec 25, 2013 at 12:06:43PM -0500, Paul Tagliamonte wrote:
 zack@ was the last person to work with the FSF on this, and I've not
 heard much else.

Correct. Unfortunately I haven't heard much else either. Discussions
went on on the fsf-collab-discuss list on alioth, but the state of the
art is still that we're waiting for the FSF to refine current freeness
assessment into more actionable items.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Please update the DSA delegation

[Stefano Zacchiroli]

On Wed, Dec 04, 2013 at 06:32:19PM -0800, Steve Langasek wrote:
 It absolutely should.  The constitution stipulates that authority flows from
 the developers, through the DPL, to the delegated teams.  To say that the
 DPL delegation is nothing than a rubber stamp is to say that the team does
 not recognize the constitutionally-defined power structures.

I'm not a native English speaker so I can't comment on whether rubber
stamp is an appropriate expression or not. But I definitely agree with
what Steve wrote here. It's very important that any substantial extra
power that a DD has wrt other DDs is tied to a delegation (and that, as
such, it can be publicly revoked by the DPL if needed). The DPL is the
only power in Debian that is periodically re-established via a vote
among Debian citizens; it is fundamental that disparities among DD
powers stems from him/her.

Then, of course we can debate on what is a substantial extra power
that need delegation and what is not. For one thing, I don't think that
commit access to a package maintenance Git repo on alioth qualifies,
especially considering that all DDs can bypass that power by doing
NMUs. But I'm positive we can agree on the fact that teams like DSA,
Ftp-masters, and the Release Team do have substantial more powers than
DDs who are not part of those teams [1].

So, talking strictly at the level of general principles, I don't think
that such teams should have the formal ability to self-delegate their
powers to new team members.  In practice, though, we need to be very
careful of not getting in the way of working teams by imposing extra
hops on how they work or, worse, trying to inflict on them team members
they don't like to work with.  It is important that we, as a project,
have the *ability* to do that via the DPL, but I don't think we should
actually *use* that ability, except in exceptional circumstances.

(FWIW, I think this characterization of things should work is compatible
with the explanation of rubber stamp that Ian has given in this
thread. But meh, I'm an Italian living in a French-speaking country,
what do I know about English linguistic subtleties :-))

Finally, I think implementing in practice the above principles, avoiding
awkward threads like the beginning of this one, can be easy as long as
we all adopt some simple communication best practices. Delegated teams
can try to avoid announcing new team members before giving a heads up to
the DPL; and the DPL can try to promptly acknowledge new team
memberships as soon as they get public. This way the general rubber
stamp principle is preserved and at the same time no DPL-team tensions
are created.  (Note: I've no idea on whether this has actually happened
in this case or not. I'm only trying to address the general aspect of
how core teams delegations should work.)


Cheers.

[1] yes, I know, the Release Team is currently not a delegated team. I
think that is a bug that needs to be fixed, and I apologize for not
having done that.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Code of Conduct: picking up

[Stefano Zacchiroli]

On Tue, Nov 26, 2013 at 06:07:58PM -0800, Russ Allbery wrote:
 Debian is not a meritocracy.  Real meritocracies are vanishingly rare,
 and certainly no technical organization that is as lacking in
 diversity as Debian is should claim to be a meritocracy. Simple
 demographics show that it's not.

I'm not sure I follow this argument. It all depends on which public
you're trying to verify whether there exists a meritocracy or not. If
you use Debian contributors as a public, you can certainly verify
whether they do advance toward powers in a meritocratic way. And if you
do so, the starting lack of diversity doesn't get in the way of being a
meritocracy --- the lack of diversity is certainly a problem, given
Debian ambitious goals, but it's not a hindrance to be a meritocracy.

 The people who have social power in Debian largely have that power
 based on their ability to express themselves convincingly in writing:

On the other hand, I agree that this does get in the way of being a
meritocracy. Or, put it differently, it means that part of the merit
that is recognized in the Debian project is the ability to express
themselves convincingly. That might be good or not, but it's hardly
something that any Internet-based community can get along without.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Should mailing list bans be published?

[Stefano Zacchiroli]

On Mon, Nov 04, 2013 at 02:21:17PM +0100, Didier 'OdyX' Raboud wrote:
 I disagree on the point of not making the ban durations public. Although 
 I understand the effect you're afraid of, I think that the benefits of 
 having the durations public outweigh the downsides: even if the banned 
 persons could try to trick the system, that would be easily detected I 
 think. Also, most of the effects of the ban are social, not technical.

Right.

 The ban durations should be made public (and very much communicated to 
 the banned person) because that gives a dimension to the punishment, you 
 can then get short or long bans, depending on how far you crossed 
 the line. An offender could first get a short ban, and when coming back, 
 if crossing the line again, a longer ban (exponentially). The only limit 
 to that would be the listmasters' patience.

So, what would be the beneficial social effects of publishing the ban
*duration*? I can't see any of that. The main beneficial effect we're
looking for is sending the message that bad behavior on Debian mailing
lists is not tolerated here, see what happens when you post nasty
messages like those?. To have this effect you don't need to disclose
ban duration. (Of course, the banned person should be made aware of the
ban duration, but I'm sure that's already the case.)

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Should mailing list bans be published?

[Stefano Zacchiroli]

On Mon, Nov 04, 2013 at 02:51:52PM +0100, Tollef Fog Heen wrote:
  So, what would be the beneficial social effects of publishing the ban
  *duration*?
 
 The ban duration is an indication of how severe we think the violation
 is.  You don't get a lifetime ban for a minor transgression and you
 don't get a one-day ban for serious harassments.

Of course. The question is: do you think disclosing ban duration will
discourage bad behavior on our mailing lists more than just disclosing
the bans currently in effect? (I don't.)

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Possibly moving Debian services to a CDN

[Stefano Zacchiroli]

Just a minor nitpick on the point below; for the more general discussion
I stand behind the opinion I've previously posted in this thread.

On Sun, Oct 20, 2013 at 04:00:42PM +0200, Lucas Nussbaum wrote:
 After all, if we could use and point to 3-4 CDNs that are advocating
 Free Software, isn't it better to show that such core Internet
 services can be run using Free Software?

I don't think whether CDN offerings (and/or the companies behind them)
are *advocating* Free Software or not is relevant. IMO it's neither
relevant for this discussion, nor it's relevant in general to decide the
kind of relationships Debian should have with companies. Basically all
medium-to-big sized companies are split on how much they advocate Free
Software. You invariably find company parts that are hard-core Free
Software advocates, and other parts that don't care and turn a living by
developing non-free software and services that deprive users of the
software freedoms they are entitled to.

For the specific case of CDN offerings to the Debian Project, the
point---well, my point, I respect the fact that others disagree it's a
problem---is whether we're going to force our user to receive the Free
Software we're distributing via infrastructures built using non-free
software.  That problem would exist even if the companies behind those
services were big Free Software advocates, which just happen to have a
single service (the CDN) built using non-free software.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Possibly moving Debian services to a CDN

[Stefano Zacchiroli]

On Tue, Oct 29, 2013 at 11:19:14AM +0100, Tollef Fog Heen wrote:
 You seem to be under the impression that CDN implies non-free software.

Oh, no, not at all.  I'm just saying that we should judge CDN offerings
on the basis of the kind of software they're build upon, and not on the
basis of how much the companies offering them advocate Free Software.

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Possibly moving Debian services to a CDN

[Stefano Zacchiroli]

On Tue, Oct 29, 2013 at 02:22:36PM +0100, Tollef Fog Heen wrote:
 I don't believe we ask mirror operators what OS their mirror runs on or
 whether it's free software today.  While I'd like both them and a CDN to
 use free software, this doesn't look like it'll change anything from
 current practice.

We're running in circles :-) See:
https://lists.debian.org/debian-project/2013/10/msg00058.html

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Possibly moving Debian services to a CDN

[Stefano Zacchiroli]

On Sun, Oct 13, 2013 at 08:44:56AM +0200, Tollef Fog Heen wrote:
 We appreciate feedback while we continue our investigation of CDNs.

Hi Tollef, thanks for bringing this discussion to -project.

I'm myself against switching to a CDN, but it might be due to a lack of
information on my part, so I'd love if DSA could fill in my gaps.

Debian is a Free Software project. I think that is what should drive our
choices and nothing else.  As such I'd hate seeing Debian moving, by
default, to a content delivery solution that is made of proprietary
software parts. That would be very bad for the Debian Project, as it
would send the message that while we do create an entirely Free OS for
others, we are fine with using proprietary software to do so (Mako has
expressed this concept much better than I could possibly do in his Free
Software Needs Free Tools essay
http://mako.cc/writing/hill-free_tools.html ). In my mind, using a CDN
made of non-free parts would be exactly the same as using a proprietary
BTS, or replacing the DBMS that backs dak with Oracle Database.

I do realize that most of the value of a CDN is not in its software
parts. But I'm under the impression there is still quite a bit of
software behind commercial CDN offerings. So my question is: would the
CDN providers we're going to choose be able to ensure that the software
parts behind their offerings to us are 100% Free Software? I don't think
we have enough leverage to impose that. But if it is the case my non
100% Free Software concern above would certainly disappear.

Another way of making my concern moot would be to use the CDN only as a
non-default option that users should explicitly choose, and label it as
some non official service. That would reduce the impression that the
Debian Project endorses infrastructures that rely on non-free software.
For instance, we could repurpose the cdn.debian.net name (assuming the
current maintainer is fine with the idea) and present it as an option to
our users. A corollary of this is that it would be difficult to use the
CDN for things like www.debian.org (probably making moot many of the
advantages you're looking for).

An unrelated concern is that of technical independence. I do see a lot
of value in Debian social experiment (quoting here a very nice way of
calling it that Lucas has come up to) of trying to do almost everything
by ourselves, from packaging to legal, from marketing to sysadm'ing. Of
course it comes with a lot of drawbacks, and I don't think it is
something rooted in Debian principles. But it is a very nice
characteristic of our Project, and I think we should be very careful
before giving it up, even if in only in specific areas.  In your mail
you've addressed the concern of excessive dependence on a *single* CDN
provider, mentioning that you're looking into how easily switch from one
provider to another. Would it be equally easy to get rid of the CDN ---
or switch to a more home brew (set of) CDN(s) --- if things go awry?

(FWIW, I'm not myself worried about dependency on money / hw coming from
companies, I'm very well aware that Debian needs quite a bit of
resources from companies. But that concern is very much mitigated by the
diversity in donors, or at least by the fact that we can have that
diversity. Technical dependency is IMHO much worse, because to get
diversity there you need to have in place, beforehand, the needed
abstraction layers.)

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Possibly moving Debian services to a CDN

[Stefano Zacchiroli]

On Wed, Oct 16, 2013 at 03:40:48PM +0200, Thijs Kinkhorst wrote:
 It is of course a good target to strive for, but putting such a demand on
 a service is probably not fair, because our current distribution system
 also does not run on 100% Free Software. We do not know what software our
 mirrors are running (we can make a guess that there will be Debian hosts
 in there, but just as well we can be quite sure there will be some Solaris
 or commercial Linux variants) so it's just as opaque as a commercial CDN
 offering would be.

I disagree with that, both on a principle basis and on a practical
one. Right now, as a project, we do not take any stance on the free-ness
of our mirror network. It's some sort of don't ask, don't tell regime.
In practical terms I'm myself convinced that many mirrors are run
entirely on Free Software (see about network equipment below), and I can
guarantee that was the case for mirrors I've been running myself in the
past.

Switching *by default* to a CDN could make the situation much better (if
the offer is 100% Free Software, which is unfortunately unlikely) or
much worse (the most likely case).  If the situation is going to get
much worse, I frankly prefer the status quo.

BTW, I forgot to add a very important note to the previous mail. I
realize that switching to a CDN could make things much better for DSA,
and that's why it pains me to object to the idea by being someone that
is not contributing in anyway to the DSA team. I do that only because I
think we're here on a topic where what I believe to be Debian principles
are at stake.

 The principled point that everything Debian does should involve 100% Free
 Software is not the status quo nor is it attainable. We will deliver bits
 using equipment running Cisco IOS, and we will not have the source of the
 bank software that processes our donations. The question is therefore: do
 we consider such CDN services to be more like network- or financial
 services, which we source externally, or is it a core aspect of developing
 Debian?

Right, that's indeed the question. And I realize that different people
will place their bars at different levels. My bar is that content
delivery is indeed a core aspect for a project producing a Free Software
distribution. YMMV, and I've no desire of trying to convince otherwise
people who place their bars differently.  But this thread was about
opinions on the idea; this is mine :-)

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Moving to stronger keys than 1024D

[Stefano Zacchiroli]

On Sat, Oct 05, 2013 at 12:41:41AM -0500, Gunnar Wolf wrote:
   Yes, our WoT has naturally weakened due to bitrot
   (i.e. cross-signatures made with keys which are later retired might
   have created WoT islands), but we do have at least identity
   assurance history.

So, I've a question about this and I'm looking for best practices in the
area. I've migrated to a 4096R key in 2010, but I haven't yet revoked my
old 1024D key. My initial, maybe naive, idea was to wait for the new key
to be as well connected in the WoT as the old one before retiring the
latter. 3 years into that, is not very clear to me that this is not
gonna happen any time soon: even though I've been traveling a lot over
the past 3 years and met a lot of Free Software people, the MSD ranking
of my new key is ~180 whereas the old one is ~62. Given I've collected
many signatures on the new key, the reason is likely that the migration
of many people (and possibly the fact that some other very well
connected people haven't migrated?) is making the WoT much more
scattered than what it was ~13 years ago, when I started using my former
key.

What worries me is that by revoking my old key I'll make the situation
for the WoT worse. Given the current state and evolution trends of WoT,
is it actually the case, as Gunnar hints at above, or not?

OTOH by not retiring my old 1024D key I feel increasingly more
irresponsible, as impersonating me via the old key (and possibly sign
other keys with it...) is becoming increasingly easier.

Oh mighty Debian keyring maintainers and WoT gurus, what do you suggest
to do in this respect? When is the right moment to retire old keys after
migration to stronger ones?

TIA,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Moving to stronger keys than 1024D

[Stefano Zacchiroli]

On Sat, Oct 05, 2013 at 08:17:48AM -0700, Jonathan McDowell wrote:
 Now. If you have a 2048 bit or larger key that has been signed by at
 least 2 other DDs but still have a 1024D key in our keyring you should
 be filing a request for replacement.

I'm sorry, I realize only now I wasn't clear on this point.

I was talking about the WoT at large, not only the Debian keyring. I've
indeed replaced my 1024D key wih my 4096R key in the Debian keyring a
long time ago. What I haven't yet done is _revoking_ the old key.  Doing
that now should have no bad effect on the Debian keyring, as any
potentially bad effect there has already happened when I did the
replacement.

 The more useful question is how many of the signatures on your new key
 come from strong keys, and how many strong keys have you signed with
 that new key?

Right. If you happen to have a oneliner to verify that I'll be happy to
answer these questions :)

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


--
To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131005153218.ga3...@upsilon.cc

Re: Paths into Debian

[Stefano Zacchiroli]

On Tue, Sep 24, 2013 at 07:51:53AM -0400, Paul Tagliamonte wrote:
 Its not just you - while I appreciate using a word other than bitesized or
 low-hanging-fruit, I tend to get the same slightly off putting feeling
 about gift
 
 Not to bikeshead.

So, folks, what do you propose instead? :)

If the chosen terminology send the wrong message, and hence it's
potentially a blocker, let's change it (but better do it only *once*,
hence the need of getting it right this time).

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Debian companies group

[Stefano Zacchiroli]

On Fri, Sep 06, 2013 at 09:07:22AM +0200, Lucas Nussbaum wrote:
 But there are other ways for business entities to help Debian. I can
 think of at least two:

Just off the top of my head, two more:

- OEM work to have Debian pre-installed on machines available on the
  market

- certification lobbying: back when I was DPL I've spoken a number of
  times with companies interested in proposing Debian to their
  customers, but unable to do so because Debian is not $foo certified

Both kind of activities are not particularly suitable for volunteers,
because they're definitely not fun / exciting tasks to spend your
volunteer time on. On the other hand, they are activities that, if
pursued, would benefit the Debian ecosystem, and around which companies
can expect to find sustainable business models.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Debian companies group

[Stefano Zacchiroli]

On Tue, Sep 03, 2013 at 12:18:05PM -0700, Steve Langasek wrote:
 The graphs on lists.debian.org seem to indicate that the list has not
 seen much use:

Indeed it hasn't.  IMO due to the lack of an active group coordinator,
whom we now seem to have.

Regarding the privateness of the list, sure, the list can be moved
elsewhere if *hosting* a private list on Debian infrastructure is not
considered acceptable. I've argued at
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=650082#133 that mere
hosting of this list doesn't, IMO, go against any Debian principle.

My intuition for that is that the list is just a facility offered to an
interest group, mostly formed by non-Debian actors, whose Debian-related
actions to become effective will need to go through the usual Debian
public channels (the BTS, VCS, packaging team lists, etc). If, in
addition to that, companies would like to use the list also to discuss
stuff that is private to them, e.g. commercial strategies or fleshing
out announcements before they're public, that's fine by me, as I don't
consider those Debian activities.

If anyone think the project will gain something in moving such a list
outside the Debian infra, sure, why not.

FWIW, I've myself much more of an issue with private lists (and mail
aliases) used by official Debian bodies, core teams, etc. Because those
lists are used by project members to take decisions that impact directly
on the project and won't necessarily go through other public channels
before becoming effective.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Proposal #3: Upstream/Debian Project donations (was: PaySwarm-based donations)

[Stefano Zacchiroli]

On Wed, Jun 19, 2013 at 07:53:42AM +0100, Lars Wirzenius wrote:
 Donations from end-users are highly likely to go mainly to highly
 visible projects, such as Firefox/Iceweasel and LibreOffice.

But doesn't this problem already exist with the status quo?

Let's assume that Firefox, LibreOffice, FSF, and Piuparts all solicit
donations upstream. Some of them will be more visible and, more
generally, better than others at doing so. They will get more money even
if, according to your own judgement, they deserve less. That's the
basic unfairness of any opt-in donation mechanism.

A mechanism that makes it easier, via a more consistent interface /
better tooling, to donate to recipients that *already* seek for
donations, doesn't solve that problem. But AFAICT it doesn't make it
worse either.

On the other hand, I agree as well that something like this is no longer
Debian-specific, and should be better discussed / adopted at a
cross-distro level, relying on existing standards (e.g. DOAP) if
available.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: PaySwarm-based Debian donations (was: Re: KickStarter for Debian packages)

[Stefano Zacchiroli]

On Sun, Jun 16, 2013 at 10:05:48AM +0100, Lars Wirzenius wrote:
 You suggest that package maintainers get to suggest where donations go.
 There's two glaring problems there. First, it disregards all the great
 things people do to make Debian better that are _not_ about packaging
 at all.

Yeah, I agree with this concern as well. Everything which tries to
pay/tip Debian contributors and stays at the package level only is
doomed to fail, and bring with it some of the nasty consequences that
have been highlighted.

OTOH, I think it would be fine to have something at the package level to
pass on donations to our upstreams, as well as to ease donating to the
Debian project as a whole. See [1,2], already mentioned by Paul Wise in
his initial followup to this thread.

[1]: https://lists.debian.org/debian-www/2013/05/msg00025.html
[2]: http://upstream-metadata.debian.net/table/Donation

All the problems that have been highlighted are related to pay/tip
Debian contributors and the distorsions that institutionalizing that
process might introduce. But we already have at least 2 other kinds of
entities that actively seek donations (upstreams and Debian as a
project), and we do tolerate that. Making it easier for them to seek
donations doesn't seem problematic to me. On the contrary, there is an
active debate on how to sustain Free Software development while at the
same time keeping it away of companies and the need of turning a profit
(see for instance [3]).

[3]: https://lwn.net/Articles/511260/

Using Debian as a conduit to *ease* donation flows to FOSS that already
exist seems an useful thing to do to me. That is, after all, exactly
what [2] was meant for, maybe it can be improved and become more
successful adopting some of Manu's ideas.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Debating difficult development issues in essay form

[Stefano Zacchiroli]

On Sun, May 12, 2013 at 12:50:56PM +0100, Lars Wirzenius wrote:
  Technical hint: subpages syntax in Moin can be quite frustrating,
  especially for those who do not often edit Moin pages. It might be
  useful to have some sample (dangling) links for subpages pointing to
  alternative positions directly in the page template.
  
  (Of course I can implement the above changes myself in the wiki, but
  first I need to know if you agree with them or not :-))
 
 Please do that. I obviously failed to do it with the current wiki setup
 (the release essay is not a subpage of the Debate page, for example).

Sorry for the delay. I've now finished doing that: JessieReleaseProcess
is now a subpage of Debate, and AlwaysReleasableTesting a subpage of
JessieReleaseProcess, as recommended in /Debate. I've fixed all the
links I've found, but redirect pages are in place, so nothing should be
broken by the change. I've also created DebateTemplate, with the correct
syntax for subpages.

In the meantime, it seems that other users of /Debate have gone their
way, though :-), with the main essay residing in the debate page, rather
than in dedicated pages. This is a bit unfortunate, as it makes more
difficult to understand the positions at play, which should have one
essay per position, if I understand the approach you were trying to
propose properly.  I haven't attempted to fix that, though.

Hope this helps,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: 2nd draft (was: Re: Revising the Code of Conduct)

[Stefano Zacchiroli]

On Thu, May 23, 2013 at 03:17:48AM -0400, Chris Knadle wrote:
 I'd like this to be more global in coverage, and not just focus on the
 mailing lists.  In this draft of the Code of Conduct, 8 out of the 9
 rules are about email, so it feels more like a mailing list CoC
 right now than a CoC.  ;-)

This is my main comment as well. What we currently have is precisely a
*mailing list* CoC. And while that specific document might need
improvements, which Wouter is addressing, I think we should enlarge the
scope. I don't think we would gain much by addressing only interaction
problems on mailing lists. We definitely need to do the same on the BTS,
IRC, and other discussion fora.

As a second comment, I'd love if we could separate more clearly
technical aspects (e.g. the Reply/M-F-T discussion) from more general
community interaction guidelines. In the general part we should distill
what are our expectations of good interactions in Debian, e.g.: show me
the code, as well as politeness/professionalism requirements. In the
media-specific parts we can then put stuff like Reply/M-F-T and whatnot.


To help with the general effort of publishing a Debian CoC, a while ago
I started collecting some related work at

https://openhatch.org/wiki/Project_codes_of_conduct

with the help of friends from other FOSS projects. I think we can
benefit a lot from looking at what others have done in this area over
the past decade.  Many of us are aware of the Ubuntu CoC, but there is
more out there, some derived from Ubuntu's, some written from scratch.
I'm pretty sure we can find reusable pieces there, to be adapted to
Debian's culture. (Oh, and do not hesitate to contribute to that page!)


Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Debating difficult development issues in essay form

[Stefano Zacchiroli]

On Thu, May 09, 2013 at 08:45:08PM +0100, Lars Wirzenius wrote:
 The executive summary: We'd like to see more thoughtful debates
 of important Debian development issues, and have created
 http://wiki.debian.org/Debate as a way to encourage them.

Dear Lars and Russ, thanks for this initiative. I applaud the effort and
generally agrees this is something worth trying.

We've been asking people to summarize discussions in the past, but most
often we did so asking new summaries on lists, and that is prone to the
lack of a running documentation for a given discussion at hand. What
you propose might be a solution to that, aside from having other nice
properties. Let's see how it goes!

I've a general question here and a couple of more detailed comments
inline below.

Question: there are various overlaps from this proposal and DEPs
( http://dep.debian.net/ ). Not only in some of the explicit goals you
state (e.g. documenting the state of discussions), but also in the fact
that other FOSS communities out there are using DEP-like solutions to
address the debating difficulty. Given that Lars has been one of the
main proponents of DEPs, I suspect you have put quite some thought on
the relationships of the two approaches. Can you share with us what you
think are the pro/con of this wrt DEPs?

 * Write a document explaining your point of view. Make it as
   convincing as you can. If you like, gather a group of
   like-minded people to help write the document.
   Add your names to the end of the page so it's clear whose
   viewpoint it represents.

About this, it's not clear to me if you actually encourage sign-offs
from people other than the original authors or not. There's no mention
of it here, but Russ' answer to Wouter on -project seems to hint at the
fact that they would be welcome. (Yes, it's very clear to me that this
is not a voting system, but I think sign-offs, possibly clearly
differentiated from the essay authors / proposal drivers, might be
useful. In fact, I think this is very similar to the proposer/seconds
distinction we have in GRs, which I find useful in the initial phase of
the opinion formation process.) If this is something you encourage, I
suggest adding a Signed-off section to your page template.

 * Publish the document on as a subpage of the topic page
   in the wiki. Add a link to the subpage from the topic page.

Technical hint: subpages syntax in Moin can be quite frustrating,
especially for those who do not often edit Moin pages. It might be
useful to have some sample (dangling) links for subpages pointing to
alternative positions directly in the page template.


(Of course I can implement the above changes myself in the wiki, but
first I need to know if you agree with them or not :-))


Thanks again for this initiative,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Donations to Debian are too difficult

[Stefano Zacchiroli]

[ Cc += debian-sponsors-discuss ]

On Mon, May 06, 2013 at 12:14:36AM +0300, Vladislav Zorov wrote:
  If it's possible to accept PayPal, an even better solution would be to just
  use PayPal's donate button, thus most users will only need one click and
  their PayPal password, avoiding the point where most users abort their
  payments (the credit card details entry form). I understand if there's an
  ideological reason to not accept PayPal, but neither Debian nor SPI said
  anything about it.
 
  That's a good question for debian-project.
 I bet they have a good reason, let's wait and see :)

I don't think there's any particularly good reason not to accept
donations via PayPal. There are various good reasons not to use PayPal
in general, but from a strictly Free Software-specific point of view
(which IMHO is the only one value horizon Debian should have) they
aren't worse than reasons not to use any other bank out there. As a data
point, many other Free Software projects (e.g.: Tor, GIMP, KDE, the FSF,
OSI, SFLC, Software Freedom Conservancy, etc) accept PayPal donations
without much of a hassle. They all seem to value more the simplicity for
donors than other concerns; and I don't think that any of those project
values Free Software any less than we do at Debian.

In terms of fees, PayPal fees would actually be better than the fees
that Debian pays to at least some of other Trusted Organizations that
currently accept donations on behalf of Debian (e.g. SPI). As such they
would be more respectful of donors' money, because a larger share of the
donation will actually reach Debian.

Last point: we wouldn't need to rely on any Trusted Organizations to
take care of PayPal money, we would just need to coordinate with the
Debian auditors for proper accounting --- I haven't spoken with them, so
that *might* be a problem, but I don't think it would be.

Just thinking out aloud,
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: A Debian contributor StackOverflow

[Stefano Zacchiroli]

On Thu, Apr 04, 2013 at 11:18:27AM -0700, Russ Allbery wrote:
 The Shapado software seems a little bit clunky (the formatting is weird in
 Iceweasel, it won't let me save a photo in the profile, and every edit to
 the profile apparently requires changing my password, which is weird).
 But the basic functionality seems to be there.

Right. Let me add as a shameless plug that the service is in dire need
of volunteer admins that help with the setup (shapado configuration,
themes, etc.) and also keep a link with upstream development to discuss
our needs, cherry pick patches, etc.

Once that basic level of service is assured again, the service could
also use some publicity/buzz, to actually encourage the formation of a
more active support community there --- for the people who are fond of
the StackOverflow-like approach.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Debian participation into GNOME Outreach Program for Women

[Stefano Zacchiroli]

On Fri, Apr 05, 2013 at 09:45:46AM +0200, Andreas Tille wrote:
 I do not have trouble personally in spending the money on OPW but I
 would also see a similarly fair use of the GSoC org money to keep on
 sponsoring DebConf newbees and explicitly prefer women who apply for
 the support.

FWIW, this is no either/or situation. We can do both and in the past we
have never needed GSoC org money to support the DebConf newbies
initiative. The bottleneck to the viability of DebConf newbies have
historically been 1) someone taking care of the initiative (announcing
it ahead of time, reviewing applicants, etc.) and 2) coordination with
regular DebConf applications (ideally, newbies could just be a
category of regular applicants, that is somehow favored when doing
travel sponsoring decisions).  I should also point out that OPW does
reserve part of intern budget to allow them to attend project
conferences.

So, if people want to have DebConf newbies happen again, do not worry
about money, rather volunteer to help out the DebConf team to make it
happen from an organization POV!

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Debian participation into GNOME Outreach Program for Women

[Stefano Zacchiroli]

On Tue, Apr 02, 2013 at 09:26:18PM +, Sune Vuorela wrote:
  TL;DR: we've been invited to participate into GNOME Outreach Program
  for Women and I'd like to accept the invitation.
 
 I'm very much against spending debian money on paying for contributors
 time.  While I would love a more diverse group of debian developers, I
 really don't think that using our money is the right thing to do.  So
 please, pretty please, let us reconsider.

Hi Sune, thanks for your feedback. We can surely reconsider. In fact,
while I'd like to go ahead right now with the preliminary organization
for OPW participation (e.g. collecting the internship topics, which
might be useful anyhow), I'll be happy to leave plenty of way outs: OPW
application deadline is May 1st, so there will also be time for the next
DPL to object to this.

And of course I'll be happy to stop this right now, in presence of
substantial objections from the project.  So let's have this discussion
as I think it's a very important one to have, no matter what.



I think we really need to participate in outreach program, of any kind.
Quite some of those programs focus on positive discrimination to
increase diversity and offer some kind of monetary incentive. Let's see
if we have fundamental objections in Debian to that sort of programs.

Back in the days (say, dunc-tank, for those of us who remember it) the
main objection to paying contributors time was that it creates
differences in the community. That's a very sensible objection.

It seems to me that we have overcome that objection with GSoC, program
in which we have participated for many many years, and where
contributors are paid. We have done so 2 ways.  One is the focus on
attracting *new* contributors, which is the point of pretty much every
outreach program; we don't strictly enforce the new rule, but it is
evident to anyone that contributors won't be GSoC students for long, and
that reduces the disparity.  Another one is positive discrimination: we
realized we need to reach out to a specific class of contributors
(students) and we accept some differences in the hope that they will
remain around in Debian afterwards, when the incentives are over.

My feeling is that the origin of money in GSoC (Google) is not
particularly relevant in addressing the create differences objection,
but I might be wrong. I'll be happy to be convinced of that.

(Note, in passing, that we have in the past directed part of GSoC money
to individual GSoC mentors, de facto paying their contributors time. But
that's a detail, which we should probably reconsider in the future, as
there all the above good reasons to ignore the create differences
objection do not hold.)


For OPW, the money do not come from GNOME, they ask participating
organizations to provide them (after all, differently from Google, they
don't have anything to gain from the program). Therefore one way to
overcome your objection on the money origin is to seek specific
sponsoring for Debian participation into OPW. We can do that. In fact,
what Ana proposed in this thread (targeting GSoC per-project 500 USD to
our OPW participation) is a possible implementation. Do you consider
that solution acceptable?

If not, we can do mission-specific fund raising, I wouldn't mind that
either, as we do something similar for, say, DebConf already. It
wouldn't be possible, in my opinion, to raise all the needed money
before OPW application deadline. But I'm 100% sure that given few months
we can raise the needed money. Hence, I do not see this as a blocker to
go forward (as long as people believe in my prevision). Would you
consider this acceptable?


Honestly, it still seems to me that the origin of money is not relevant.
For instance, even if in GSoC the money is not Debian's, it is Debian
who decides who get them, and it is Debian who can take them away
(e.g. by failing students at mid-term), under the authority of DPL
delegates. All this seems well-established in our community, even if we
can obviously reconsider that too.

The main point is rather how do we make the disparities created by this
kind of outreach programs acceptable. For OPW I think the path is pretty
clear: do not accept people with significant prior Debian involvement
(e.g. DM or DD, but we might consider other kinds of activities), and do
not accept interns more than once over the years.  But we can *also* do
ad hoc fund-raising (possibly to top left-overt GSoC money) if people
prefer that.


Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Debian participation into GNOME Outreach Program for Women

[Stefano Zacchiroli]

On Tue, Apr 02, 2013 at 12:41:17PM +0200, Ana Guerrero wrote:
 I shared Monica's confusion when first reading this thread, I find the
 participation in the program was somehow rushed with zack's initial
 email leaving some things unclear.

I should indeed apologize for rushing things a bit; that was due to the
tight timeline. Basically, we're already late, as the OPW deadline for
mentoring organization has already passed (the deadline mentioned by
Lucas on -women is for students). I was trying to get the best out of a
very kind last-minute invitation we got from GNOME. Let's see if we can
make things work, otherwise we can easily postpone this to next OPW
round, as the program happens every 6 months.

 First of all, the program needs a separate coordinator and I'm happy to see
 Mònica volunteering for this. I will be happy to join her, but with her
 keeping the main seat.

Thanks for volunteering to help Mònica.

 About the 2 main issues:
 
 *) overlap / relation with GSoC and kind of tasks

Nothing to comment on what you wrote here: it is indeed the best
possible course of action.

One thing to add, though, I've already got one ping from Marina
Zhurakhinskaya at GNOME (not sure why it's not on -women archive, as it
seems it has been sent there too), saying:


 Hi Debian folks,

 We are about ready to start spreading the word about the internships
 and it would be great to have Debian's landing page added to
 https://live.gnome.org/OutreachProgramForWomen/2013/JuneSeptember/#Participating_Organizations
 as soon as possible.

 It just needs to be a short page and
 https://live.gnome.org/OutreachProgramForWomen/Admin/GettingStarted
 describes what it should have.


I'd like to answer to that ping tomorrow. So if we want this to happen,
I need someone creating the appropriate landing page today or early
tomorrow the latest. If someone could do that, I'll be happy to go
forward with this; otherwise I'll apologize with the GNOME people and
call off our participation. It would be an occasion lost, yes; but not
such a big deal if it will result in us planning our participation for
next OPW round with some more advance.

  *) Money
 Google pays 5500 USD per project, where 5000 USD goes to the student and 500
 USD to the mentoring organization.

I wouldn't mind directing those GSoC founds to OPW participation, if
they will end up being available (the if is subject to 2 conditions:
(1) Debian gets accepted in GSoC with enough projects, and (2) GSoC
admins are OK with asking mentors to direct the 500 USD per project to
the OPW earmark). Otherwise, I'll be happy to pre-approve covering up
what remains on general Debian funds.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Debian participation into GNOME Outreach Program for Women

[Stefano Zacchiroli]

On Tue, Mar 26, 2013 at 05:00:19PM +0100, Stefano Zacchiroli wrote:
 TL;DR: we've been invited to participate into GNOME Outreach Program for
 Women and I'd like to accept the invitation. To maximize impact, though,
 we need mentors and topics to complement the current GSoC tasks.

OK, so, thanks everyone for the feedback thus far, in particular to
Karen and Marina for guidance and further thoughts on the synergies
between OPW and GSoC.

To go forward we now need (quickly!) a couple of things:

1) a coordinator for Debian participation into OPW
2) (optional) other internship topics to complement the GSoC idea list

Francesca has proposed something for (2), but is waiting for feedback
from the publicity/press team. Please follow up there if you're
interested in those topics and/or if you are willing to volunteer as
mentor for related topics.

We are stuck on (1).



Given how often we discuss how cool it would be to have more mentoring
activities in Debian---and in particular more of such activities aimed
at increasing women participation---I was hoping (and still am!) in some
more feedback and volunteering.

Is anyone up to volunteer as coordinator for Debian participation into
OPW? The task looks relatively easy: set up some nice landing page on
the Debian wiki, similar to the GNOME one, with a pointer to the GSoC
idea list and to a separate page where we will collect non-GSoC
internship topic. It could be specific to this round of OPW, but I think
it would be way more interesting to take this chance to actually have a
more long-lasting list of such projects. Additionally, the coordinator
will have to coordinate (sorry) with GSoC admins the applications at the
border between the two initiatives.

If noone else volunteers for that, I will *consider* doing it myself,
but I'd rather not --- mainly because the timeframe of this OPW round
coincides with the DPL change of guard and I'd rather devote my Debian
time to ensure a smooth transition than joining new activities.

So, if you're interested in kickstarting a very valuable mentoring
opportunity for Debian, please speak up, ... quickly :-), e.g. a couple
of days.

Thanks for considering.
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Debian participation into GNOME Outreach Program for Women

[Stefano Zacchiroli]

[ mail followup to: -women, please continue discussion there ]

TL;DR: we've been invited to participate into GNOME Outreach Program for
Women and I'd like to accept the invitation. To maximize impact, though,
we need mentors and topics to complement the current GSoC tasks.



GNOME Outreach Program for Women (OPW) is a great internship initiative,
by GNOME, initially for GNOME internship only, but which has recently
been extended to other FOSS projects. If you don't know about it but are
interested in this conversation, please have a look at [1], and in
particular at [2].

[1]: https://live.gnome.org/OutreachProgramForWomen
[2]: 
https://live.gnome.org/OutreachProgramForWomen#For_Organizations_and_Companies

A couple of days before my trip at LibrePlanet, I've been contacted by
Karen Sandler (Cc:-ed, in case I mess up something :-)) for inviting
Debian to participate in the program. To that end we need (a) some money
(entry level is ~5,500 USD for 1 internship), (b) internship topics, and
(c) mentors. As one of my last act as DPL I'll be more than happy to
approve using Debian money for 1 OPW internship, hoping it will prove
successful and that we can expand our participation even further in next
years. So we just lack b/c :-)

At LibrePlanet, I've discussed the matter further with Karen and it
turns out that, first, we have a bit more time for the internship topics
than the strict timeline suggests: application deadline for interns is
May 1st, it'll be enough to have topics/mentors around April 10th. Also,
it is quite comment, and welcome, to have some overlap with GSoC that
will be ongoing during the same period.

We can for instance include GSoC tasks in the pool of OPW internship
topics. Of course we should better not accept two students (1 OPW and 1
GSoC) for the same tasks. But we can propose to worthy GSoC candidates
to do the internship as OPW _instead_, or we can let them do their GSoC
and label their participation as OPW internship.

However, note that an important aspect of OPW is that there is no code
restriction. So while I think we should *also* propose GSoC tasks as
part of it, it would be way more interesting to add non-coding tasks to
them, therefore offering a wider range of choices to OPW candidates. But
for that, we do need topics and mentors. Could be anything useful to
Debian, from coding to artwork, from communication to accounting, from
management to packaging, anything that would provide a GSoC-like, but
broader in scope, internship experience. And, the most important part,
would help in increasing women participation in Debian, something on
which we've been working for a very long time. (FWIW, GNOME's
experiences on the usefulness of OPW are quite impressive, see
LibrePlanet 2013 talk by Marina Zhurakhinskaya.)

I don't feel like piggybacking this extra work, rather last minute, onto
the shoulders of the GSoC admins. Ideally, this is something that should
be coordinated by someone on -women, in coordination with GSoC admins
for dealing with the cases at the crossing of the two initiatives.

Anyone up to it?

Even if you're not, but you do have internship topics and mentors to
propose, please mention it. It might be good enough to have just a few
topics in addition to the GSoC tasks, as long as we have mentors for all
of them. In that case I might help with the remaining coordination part
myself (but not with mentoring, sorry, I'm already taken for GSoC this
year).

Thanks for your help,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: [RFH] answering trademark@d.o inquiries

[Stefano Zacchiroli]

On Tue, Feb 12, 2013 at 02:56:13PM -0500, Brian Gupta wrote:
  So: anyone up to help with this?  The load is very light: in 2012 we've
  received only 16 requests. Still, it is important to reply promptly and
  professionally to them.  The requirements to help are some minimal
  familiarity with trademark law --- minimal because all non-obvious
  cases should better be routed to SPI legal support.
 
 I can help. I'm pretty familiar with *US* trademark law, as this field
 is an area of interest for me, and my wife is a practicing trademark
 attorney, who was a trademark examiner at the USPTO earlier in her
 career. Please let me know what I can do to help.

Thanks Brian for volunteering.

Brian is now behind trademark@d.o, together with leader@d.o (whoever is
DPL at the time). As suggested, this is now documented at
www.debian.org/intro/organization

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Copyright assignement for Debian tools?

[Stefano Zacchiroli]

On Sat, Feb 09, 2013 at 06:51:54PM +0100, Stefano Zacchiroli wrote:
 It wouldn't make sense to assign copyright to the Debian Project, but
 it might make sense to assign it to some of our trusted organization,
 like SPI. I'm myself not aware of mechanisms offered by SPI to allow
 volunteer copyright assignment. Hence I've just asked on the
 spi-general mailing list if that is something the organization is
 interested in supporting. I'll let you know if I hear back of anything
 actionable; in the mean time you can follow the discussion there.

The thread is at
http://lists.spi-inc.org/pipermail/spi-general/2013-February/003156.html

In essence, at present there is no standardized mechanisms to assign
copyright (or enter into specific licensing agreements, e.g. to delegate
SPI the power to do license enforcement and/or relicensing) to SPI. My
inquiry has raised some interest in the matter and things might change
in the future, but they are not there yet.

There are entities using copyright notices Copyright (c) SPI... (as we
do in our website), but the validity of that practice is dubious. I'm
myself skeptical it would do any good when it really comes to needing
it, but IANAL.

Bottom line: sorry Thomas, not much help at the moment. But thanks to
your inquiry things might change in the future. (And might change faster
if someone interested and knowledgeable on these matters will join SPI
and help out.)

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Copyright assignement for Debian tools?

[Stefano Zacchiroli]

On Sun, Feb 10, 2013 at 09:14:12AM +0800, Paul Wise wrote:
 If you are contributing to copyleft projects, it is important to have
 diverse copyright holders to prevent converting projects to
 proprietary licenses.

FWIW, we are far from having consensus on this aspect in the free
software world at large. For many, copyright assignments to trusted,
transparent, and non-profits entities is a good thing, because: 1/ it
makes licensing enforcements easier in court, and 2/ allow to switch
between free software licenses (or even only decide whether you want to
move to an or later version of a license or not) downstream even in
case of dramatic events like the death of copyright holders. This is the
reason why entities like FSF and KDE e.V. offer the possibility of
centralizing copyright ownership.

In essence: YMMV. But it seems to me that we are by no mean near a point
where, in the public debate on FOSS policies, it is well established
whether this specific kind of copyright assignment is good or bad.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Copyright assignement for Debian tools?

[Stefano Zacchiroli]

On Sat, Feb 09, 2013 at 05:23:59PM +0100, Thomas Koch wrote:
 I'm currently hacking on the maven-repo-helper package. The source code 
 contains copyright statements from the original author. Now when I add 
 classes 
 it would be logical to add Copyright 2013 Thomas Koch.
 
 But I don't see any sense in this. I've no interest to be the copyright 
 holder. I'd much rather like to write Copyright 2013 The Debian Project. 
 (Actually I'm totally annoyed by anything related to copyright...)
 
 Do you have any advise for code that originates in the Debian project?

In essence, you're asking for some sort of volunteer copyright
assignment (or more likely contributor licensing agreement), similar to
what KDE e.V. offers to contributors of the KDE project, see
http://ev.kde.org/rules/fla.php

Those kind of agreements are entirely optional and interesting for
contributors like you, who don't want to care about copyright related
matter and empower trusted 3rd party entities to take care of them
(e.g. for licensing enforcements if/when the need arises).

It wouldn't make sense to assign copyright to the Debian Project, but it
might make sense to assign it to some of our trusted organization, like
SPI. I'm myself not aware of mechanisms offered by SPI to allow
volunteer copyright assignment. Hence I've just asked on the spi-general
mailing list if that is something the organization is interested in
supporting. I'll let you know if I hear back of anything actionable; in
the mean time you can follow the discussion there.

Thanks for raising this topic!
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Copyright assignement for Debian tools?

[Stefano Zacchiroli]

On Sat, Feb 09, 2013 at 01:00:27PM -0500, Brian Gupta wrote:
 It may also be worth reaching out to the Software Freedom Conservancy
 if this turns out to be out of scope for SPI
 http://sfconservancy.org/members/current/ (If I recall the SFLC helped
 get them off the ground, and they were founded to own projects that
 weren't a good fit for the FSF's GNU project).

Thanks Brian. As a matter of fact, I discuss with Bradley (Conservancy's
Executive Director) fairly regularly and I've in the past discussed with
him the possibilities of benefiting of SF Conservancy services as Debian
Project. The problem is that SF Conservancy, for various good reasons,
adopt a more exclusive model than SPI. They generally do not welcome
projects that have assets (of various kinds) scattered throughout
different organizations, which is the case for Debian. This has been a
blocker in the past. It *might* be that voluntary copyright assignments
are a special case, especially if SPI does not offer that service, but
I very much doubt it. Either way, several people active in SF
Conservancy people are also active on SPI mailing list, so we won't miss
chances of collaborating on this if there are some!

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Copyright assignement for Debian tools?

[Stefano Zacchiroli]

On Sat, Feb 09, 2013 at 11:20:17AM -0800, Russ Allbery wrote:
 Doesn't Debian as a whole also have nearly as many assets as all other
 projects in the Software Freedom Conservancy put together?

In terms of reserves, it might be. But in terms of expenses / revenue
they're way more active than we are due to the fact they have employees
(for the orga itself or on behalf of affiliated projects), revenues from
court settlement, etc. Both SPI and SFC are very transparent in their
budgets, so anyone can check the actual numbers.

... here we're getting off-topic I suspect :)

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Inbound trademark policy, round 3

[Stefano Zacchiroli]

in between, is blurry. What would be relevant in case of litigation is
whether the applied changes have changed the nature of the product,
possibly undermining upstream reputation. Trademarks policies can be
used to forbid those kind of changes, but cannot be used to forbid other
kind of changes (i.e. those that do not bring user confusion or
substantially change the nature of the product). I think we did have
consensus on the fact to ignore trademark restrictions that are clearly
outside the scope of trademark law.

A related question is obviously who, in Debian, should judge which part
of specific trademark policies are overstepping the limits of trademark
laws. I think we do have a natural, and agreed upon answer for this: FTP
Masters (sorry folks :-)).

Then, there is the matter of the guarantees that we should offer to our
users and downstreams who want to modify Debian packages, who are
possibly trademark encumbered. In particular, I disagree with your
comment:

 ]  So personally I think this is a practical question.  People who get
 ]  Debian and want to modify it in the ways one ordinarily would should
 ]  not have to check trademark conditions.

because the only common guarantees that we (try to!) offer for our
archive is that the material there is DFSG-free. Given that DFSG do
account for trademarks, I think it should be up to our downstreams to
verify whether they are allowed to do a specific change without
rebranding or, on the contrary, if they have to rebrand.  I don't see
this as a significant extra burden wrt checks that our users should
already do in the realm of copyright: for example, the kind of linking
and redistribution people could do with software in the Debian archive
is significantly different for GPL-, BSD-, or LGPL-licensed software.

My bottom line on this is that: it is acceptable to have restrictions
that force rebranding, as long as they do not overstep the purpose of
trademarks. And downstream modifying software are responsible for their
choices.

Clearly, we should document trademark restrictions prominently, in
debian/copyright (and too bad for the misnomer).

 B. Due to the exigencies of trademark law and the management realities
   of most Free Software projects, it is sometimes the case that an
   upstream project will publish a restrictive trademark policy (or
   indeed simply mention that something is a trademark without writing
   a licence at all) but in fact not carry out any enforcement against
   bona fide downstreams.
[…]
 C. What about the risk of trademark licences (or informal toleration,
   if we accept that) being revoked ?
 
  Stefano wrote:
 
For trademark encumbered software that could at a given point in
time be distributed without rebranding, maintainers should
carefully evaluate the risk of having to rebrand them later on,
and seek advice from the teams that would be impacted by impromptu
rebranding (e.g.: security team, release team, ftp-masters).
 
 ]  Personally I agree with Stefano's approach which is to treat this
 ]  as a practical problem.

In fact, I think that B and C are essentially the same problem:
evaluating the *risk* of accepting something trademark encumbered in the
Debian archive, *without rebranding* it. It is not a risk in the DFSG
sense, as via rebranding the material become unencumbered. It is a risk
in terms of the efforts that will cost us (and possibly our downstream)
to do the rebranding later on.

I don't think this part should be regulated in the guidelines: it is
very hard to detail actionable criteria for this and we'll likely always
find exceptions. So I'm much more inclined to threat *both* at the same
practical problem of evaluating the likelihood of having to do
rebranding in the future.

Once more, we do have gatekeepers of this kind of issues in the archive
(FTP Masters) and I'm happy to leave the final decision on this matters
to their discretion, of course in consultation with the package
maintainers and the other teams that might be affected by impromptu
rebranding.  On this, I'd also like to note that considerations like
how much is upstream hostile?, how much we risk of being sued by
upstream and their cats? are *already* taken into account when
accepting software in the archive. Trademark considerations are both
similar and much simpler issues, as we can always rebrand-away.

Hope this helps,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: trademark policy draft - redux

[Stefano Zacchiroli]

On Sun, Jan 06, 2013 at 06:26:26PM +0100, Stefano Zacchiroli wrote:
 Dear all, after having postponed this for way too long, here is the
 second, hopefully final, iteration of the trademark policy draft. I've
 discussed with SPI lawyers at SFLC all the comments collected during the
 past discussion, namely:
[…]
 The complete new draft is attached to this mail.

Thanks everyone for the extra feedback you've provided.

I've now gone ahead and committed a patch to the .wml file generating
http://www.debian.org/trademark that contains the last policy draft
discussed here, stamping it as Debian Trademark Policy, version 2.0.

Similar to previous versions of the policy (published by former DPLs), I
consider that a DPL decision on Debian assets, but I'm confident that
we've reached a policy which is as consensual as it could be, without
jeopardizing our future possibilities to defend our marks.

The new text at http://www.debian.org/trademark will be live at the next
pulse of website regeneration. Thanks to David Prévot for his feedback
on an early draft of my patch for that page.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: authoritative list of DFSG-free licenses

[Stefano Zacchiroli]

On Tue, Jan 08, 2013 at 08:51:54PM +0100, Joerg Jaspert wrote:
  Joerg, it would be nice to rebuild it adding the repolist plugin
  http://ikiwiki.info/plugins/repolist/ , which would add the rel-vcs
  metadata, making the following work nicely out of the box with mr:
$ webcheckout http://ftp-master.debian.org/
 
 I don't see why I need a plugin (and whatever settings) for a one-line
 change, so I just went and added
 
 link rel=vcs-git href=http://ftp-master.debian.org/git/licenses.git; 
 title=licenses.git /
 
 to the page.tmpl. It isn't supposed to change location every other day. :)
 But feel free to get me patches to change it, if you think it should.
 I'm not set on it.

Thanks. webcheckout http://ftp-master.debian.org/; works indeed as a
charm now.

  I haven't found the ikiwiki configuration in Git, so I'm unable to
  provide a patch for that.
 
 You are blind. :) It's all in git, but we don't use a setup file. The
 ikiwiki foo is in ikiwiki/ and the way we call it from our git hook is
 documented in README.

Oops, sorry :) So yes, there are no excuses to try it out and propose
patches, all is needed to test it locally is indeed there (hint hint).

  Any taker for writing a script that gather the corresponding
  statistics?

[ snip useful tips ]

OK, thanks for the pointers. I'll spread a bit the news about this, in
case there are volunteers interested in some dak-related hacking to get
this done.

 Technically I would think it ends up somewhere along
 
 - volunteers clone from the central place and do their work.
 - every now and then they ping one of ftp*, to have us review it, merge
   it (or reject the change) and push it to the central place.
 
 That would allow anyone to contribute, while keeping the FTPTeam, with
 us masters being delegates, the ones who publish it. Similar like policy
 editing works, IIRC.
 
 And discussion around it, happen on IRC and (for a start)
 debian-...@lists.debian.org.

Sound suitable to me. It just lacks one bit, IMHO, where to store
pending patches to avoid forgetting about them. Can we overload
http://bugs.debian.org/ftp.debian.org (possibly with some specific
usertagging) for this? If so, please name the desired usertags /
categories, I'll then be happy to submit a first patch ... documenting
where to report bugs against :-)

 Much more interesting is to get it all started, soo
 
  - Do we have volunteers? Who wants to? Keep in mind it will start with
a heavy load. Which will go down when we got most of the stuff
documented, but it will never end.
Damn Humans, always get up with new licenses...

According to this thread, we got at least two (Ian, MJ, not sure about
Charles). After DPL-retiring :-), I'll be happy to help too. I guess the
natural next step is subscribing to debian-dak@lists.d.o. Please do,
everyone, if you're interested in helping with this.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Validity of DFSG #10

[Stefano Zacchiroli]

On Sat, Jan 12, 2013 at 06:07:33PM +0530, Vasudev Kamath wrote:
  So, sure, we could drop it. (Note that this isn't entirely trivial, as
  it will require a GR with a 3:1 majority, given that the DFSG is one of
  our foundation documents.)
 
 So we would need to start a GR for this process but I'm not sure being
 not a Debian Developer I can start a GR.

Proposed addendum to PP phase, question: can a non Debian project
member start a GR?  SCNR :)

 Can you suggest me how I can help in this. Of course I know it is more
 important to have the valid list of license which we considers DFSG
 free first but again we are not sure how long it will take us to
 document this.

As it usually happens, getting rid of something is much easier than
building something new (possibly its replacement). So, even if I agree
that the two aspects are somewhat orthogonal, I personally don't see
much of a point in getting rid of DFSG §10 without we have a decent, and
better, replacement for it. This is just to say that *I* won't
personally lead the effort of getting rid of DFSG §10 until we have a
decent (and maintained) list of DFSG-free licenses. Others could do
that, if they want to; and anyone could help in phases that don't
require Debian membership like discussion, text drafting, etc.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: I wish you a wonderful 2013 DebConf13! (oh, and DebConf14 too)

[Stefano Zacchiroli]

On Mon, Jan 14, 2013 at 07:04:06PM +0100, Daniel Pocock wrote:
 I would call on the DPL to finally appoint an independent audit of the
 circumstances and report for once and for all whether the allegations
 are true, false or simply misunderstood.

I thought my position on this matter was already clear from
https://lists.debian.org/debian-project/2012/12/msg00068.html (in
particular the final part of it).

To answer specifically your direct request: I will not appoint any
independent audit of this matter, because I don't consider we need one.
In fact, I also think it will be counterproductive. If there were
anything to be gained in running the process you suggest --- and I'm
entirely unconvinced there is any --- the potential damages to our
community would be far superior to what we could possibly gain.

If you are convinced something went wrong this time, please stop looking
for someone to blame, and start thinking at how to improve processes so
that next time things would work better.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Validity of DFSG #10

[Stefano Zacchiroli]

Hi MJ, thanks for your feedback!

On Mon, Jan 07, 2013 at 01:32:20PM +, MJ Ray wrote:
 Stefano Zacchiroli lea...@debian.org wrote:
  Hold on :-) All you're discussing here already exists. FTP masters vet
  software that enters the archive, de facto deciding whether the
  associated licenses are DFSG free or not.
 
 Actually, don't they decide whether the *software* follows the DFSG?
 They're not the DFLG, after all.

Right. That's in fact why I've written de facto in the sentence you
quoted ;)

So, let's be more precise. The list that I think would be useful is a
list of copyright licenses that, if they were the only constraints
attached to the usage/modification/redistribution of some content, would
make that content suitable for the Debian main archive.

That does not cover corner cases (not only the interaction between
copyright and trademarks, but also license mixes), but it's useful---to
us and others---in a whole lot of common scenarios.

And then nothing stops us to do more to deal with the complex cases
(e.g. which mixes of copyright licenses we consider acceptable, when
code get linked together, in Debian main? which mixes of
copyright/trademark?, etc), even though that's would require more work.

 It is quite possible to use a licence that works fine for some other
 software and botch it (I think there's a famous example where a
 trademark licence is applied in tandem with the copyright one),
 resulting in a fail.

FWIW: the problem with iceweasel/firefox was the *burden* caused by the
intermix of trademark/copyright licenses (e.g. the obligation of
renaming the package upon security patches not vetted by Mozilla), not
that it didn't make the package free per se. That is something that has
been addressed in the current best approximation we have of a working
draft of our inbound trademark policy, see:
https://lists.debian.org/debian-project/2012/02/msg00073.html

 I think there have been at least three attempts to index them in the
 past, but few seemed to care about them and so they gradually bitrot.
 Even the DFSGLicenses wiki page was last edited 2012-08-16 and now
 appears to be immutable.

I guess this is simply related to the recent need of resetting your
wiki.d.o password. I can edit that page.

 Who wants this index?  Who's willing to put the time in?  I'd be happy
 to help, although I won't lead another attempt.

In passing, I note that having such a list is not much different in
principle than DFSG §10: it's a concretization, with real examples, of
the DFSG which are by their own nature in the abstract.

I don't think there is someone who wants this index. I think it's
social value that we can offer to the free software world by maintaining
it. Let's accept that we are not just yet another distro. Our licensing
choices have effects which extend past our project borders, they can
(and do) influence where the free software movement is going. We will do
a service to the free software world by documenting them better than now.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Validity of DFSG #10

[Stefano Zacchiroli]

On Mon, Jan 07, 2013 at 02:16:59PM +, Ian Jackson wrote:
 I found a report of Richard Fontana's talk here:
   http://lwn.net/Articles/516896/

Oh, thanks, I forgot about that one.

  […] we are not doing a good job at documenting and explaining our
  choices […]

 This is unfortunate.  But it's not true to say that the FTP masters
 have the final say.  The Developers have the final say by General
 Resolution and have exercised that power on multiple occasions
 including most of the most controversial licensing decisions.
 
 That's an open, transparent democratic and community-based process
 which OSI and the FSF would IMO do much better to emulate.

It is true that FTP masters do not have the final say: the Constitution
offers very good balances in that respect and we haven't been shy about
using them when needed. But I don't think that's the point.

And I don't have a problem with delegating the decision to a team. In
fact, I've been arguing with Richard (Fontana) this precise point at the
time of the preliminary discussions which --- I believe --- have been
the basis for his talk. You can see part of those discussions here:

  http://identi.ca/conversation/80340750#notice-83030966

(unfortunately, Richard's own dents are no longer available on
identi.ca)

So I think we are in agreement on this part.


The main point I think we should discuss is the part to which you
replied with This is unfortunate (I hope my quoting is correct here).
Namely: the fact that we could do a better job in documenting our
choices. Because that's useful to others and because there aren't that
many license review bodies out there, and finally also because we're
quite peculiar in our way of doing that --- as you pointed out.


 Debian is the only widely-referenced licence Free Software review body
 whose ultimate decisionmakers are anything other than a
 self-perpetuating oligarchy.

FWIW, OSI is opening up, so this might change in the future.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

authoritative list of DFSG-free licenses

[Stefano Zacchiroli]

On Mon, Jan 07, 2013 at 11:55:57PM +0100, Joerg Jaspert wrote:
 One thing first: The question if we change DFSG and documenting what we
 think is free (or not) are two entirely different things, and shouldn't
 be mixed together.
 
 I'm replying only to the documenting thing using my ftpmaster hat, the
 DFSG§10 one is entirely seperate and doesn't really touch ftp* opinions.

Fair enough, let's fix the subject then.

 The whole of ftp* agrees that it would be nice to have a place
 documenting this. So much so that we started something for it in 2009,
 see http://ftp-master.debian.org/licenses/ for it.

Oo, that's awesome! I had no idea something like that existed,
and I can't find it listed anywhere: can you people please link it from
http://ftp-master.debian.org/ ?

 And here is an ikiwiki instance in a git, check it out, ftp*.
 got it around 31 commits far, and then it slept in. It *is* entirely
 dull and non-fun and just boring work, with no direct payoff (in
 NEW/rm you at least have that direct payback :) ).

For those willing to play with it, the associated Git repository seems
to be at http://ftp-master.debian.org/git/licenses.git/

Joerg, it would be nice to rebuild it adding the repolist plugin
http://ikiwiki.info/plugins/repolist/ , which would add the rel-vcs
metadata, making the following work nicely out of the box with mr:

  $ webcheckout http://ftp-master.debian.org/

I haven't found the ikiwiki configuration in Git, so I'm unable to
provide a patch for that.

 That said, we would be happy to get it back to live and end up with it
 (either where it is now or wherever fits) being a useful place. Seeing
 how it directly touches us (decide if $foo can go into the archive and
 be distributed or not), it certainly makes sense to have it within FTP*
 overview.

Ideally, what I'd love is then to see that page replacing what we
currently have at http://www.debian.org/legal/licenses/ . MJ, has you
seem to have participated in the maintenance of the latter page, what do
you think of that? Of course, we'll first need to bring the ftp-master
page up to date.

Also, I think Charles' idea of also publishing stats about which
licenses are currently found in main/non-free would be useful. It can be
toned down wrt the claim that these licenses are DFSG-free and
presented as mere factual data of what we currently have in the
archive. Doing it on the basis of machine parseable debian/copyright
sounds reasonable and might further encourage adopting the new format.
Any taker for writing a script that gather the corresponding statistics?

 That said, it is clear it can't be the FTP Team who is doing the work
 - the oh-so-recentness of it shows that it is a task that won't get
 done. There is too much else for us and we are few people only.
 
 But we would be happy to work with / lead / whatever-one-names it with a
 group of volunteers together. Exact details of how that works out are to
 be found, but im sure we can. If there are volunteers for it...

Fair enough. Of course good part of the work will be reviewing the
licenses that are already found in the archive and marking them as
DFSG-free in your table. Which review status would you (as in
ftp-masters  assistants) want for those licenses? More generally, is
there a specific work-flow, or state chart, you want to follow? That
would help in proposing patches to the ikiwiki repo...

The other big part of it is keeping up to date with future
DFSG-free-ness ruling by ftp-masters. As pointed out in this thread, you
usually send motivated REJECTs to maintainer only. How would you like to
proceed to keep track of motivation for new licenses? Is Cc:-ing
-project, as you did for the Ubuntu Font License and then indexing a
link to the list archives something that would work for you? If not,
what would?

Thanks for this enlightening pointer to related work,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Validity of DFSG #10

[Stefano Zacchiroli]

On Tue, Jan 08, 2013 at 05:26:18PM +, Ian Jackson wrote:
 Joerg Jaspert writes (Re: Validity of DFSG #10):
  But we would be happy to work with / lead / whatever-one-names it with a
  group of volunteers together. Exact details of how that works out are to
  be found, but im sure we can. If there are volunteers for it...
 
 I would volunteer.  But:

Uhm... It looks like we've interpreted in radically different ways what
ftp-masters are looking volunteers for.

I interpreted it in the sense that they are looking for volunteers to
*document* past, present, and future decisions made by ftp-masters. You
interpreted it in the sense that they are looking for volunteers to
participate in the decision process itself.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: trademark policy draft - redux

[Stefano Zacchiroli]

On Mon, Jan 07, 2013 at 09:39:20PM +0900, Charles Plessy wrote:
 Thanks a lot, Stefano, for this change.  I think that it will strenghen our
 position when asking to relax license clauses restricting commercial use for
 some software we distribute or would like to distibute.

Thanks for your feedback, Charles.

 I have one final comment, not related to the above.  For understandable
 reasons, the proposed trademark policy is quite insisting on not
 misrepresenting Debian.  But how about parody and satire ?  Do we rely on fair
 use regulations in each countries to allow them despite our trademark policy ?

IIRC it is something we have discussed in the previous occurrence of
this thread. But in the avoidance of doubt: the policy, and trademarks
in general, do not care much about misrepresenting Debian as in parody
and satire. Rather, they care about avoiding customer confusion. So it
is perfectly fine to mock Debian; what is not fine is pretending you're
shipping Debian to users while you're shipping, say, Windows with
malware or a different distribution (in the latter case you can of
course redistribute by simply stating based on Debian, as many custom
Debian modifications out there already do).

Hope this clarifies,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Validity of DFSG #10

[Stefano Zacchiroli]

On Sat, Jan 05, 2013 at 08:35:00PM +0530, Vasudev Kamath wrote:
 Just to give a background as part of my NM process me and my AM
 (intrigeri) started a discussion on ambiguity in DFSG #10 which
 specifies example of DFSG free license as BSD, GPL and Artistic.

Heya, thanks for pointing this out here and all the best for your NM
process! :-)

 In brief Jakub Wilk wanted to get rid of DFSG #10 as it is creating
 ambiguous situation by pointing to licenses which have multiple
 variants. rather than rephrasing him I'm attaching his mail with his
 permission to this.
 
 In my opinion DFSG #10 is not a guideline but a statement giving example
 compared to other DFSG's so even I feel it is better to drop DFSG
 #10. So I would like to formally start a discussion on this topic
 here. Please share your suggestions.

Sure enough, DFSG §10 is doomed to be outdated and it's already quite
misleading in the BSD case. It could even get worse if, say, future
*versions* of licenses that are listed there and that we currently
consider free, won't be considered free anymore.

So, sure, we could drop it. (Note that this isn't entirely trivial, as
it will require a GR with a 3:1 majority, given that the DFSG is one of
our foundation documents.) But I doubt we will gain much in clarity by
*only* doing that. We need an extra step: an authoritative and
maintained lists of licenses that the Debian Project considers free. (We
currently only have approximations of this, more details below.)

The rationale is that when considering licenses many people look at
Debian and at our choices. They will surely also look at other sources,
like FSF and OSI, but people do look at what we do. In a sense, we are a
well established moral and political authority in defining what free
software *is*. (In passing, we are among the very few that considers
software in its broadest meaning of content. As a consequence we
also encompass free culture, something that others don't do as
prominently as we do.)

Unfortunately, we are not doing a particularly good job at documenting
our choices --- in particular: which licenses do we consider free ---
and at explaining the rationales behind them.

This has been discussed in various occasions. A recent one within the
project is the question time of my talk at DebConf12 [1], thanks to
input by Steve Langasek. But our flaws on this matter are being
discussed also outside the project border; see for instance the
interesting talk The Tragedy of the Commons Gatekeepers by Richard
Fontana at LinuxCon North America last year [2,3].

[1]: http://penta.debconf.org/dc12_schedule/events/881.en.html
[2]: http://faif.us/cast/2012/oct/10/0x33/
[3]: http://linuxcon2012-fontana.rhcloud.com/

I agree with Richard that, modulo some notable exception like FTP
masters' ruling about the Ubuntu Font License [4], we are not doing a
good job at documenting and explaining our choices. The best
approximations we have are either non-authoritative, or not maintained,
or both. The net result is that by searching the web license names and
Debian one will likely end up on debian-legal discussions, that are not
the official project stance on license free-ness.

[4]: https://lists.debian.org/debian-devel/2011/04/msg01239.html
[5]: http://www.debian.org/legal/licenses/
[6]: http://wiki.debian.org/DFSGLicenses

Bottom line: I'd be very much in favor of dropping DFSG §10 as long as
we replace it with a (pointer to a) place where we maintain an
authoritative list of licenses we consider free, together with (pointers
to) explanation of why it is so.  I'm quite sure the explanations do
exist already, but we do need people that do the work of finding them
and documenting them in a central place. For the place in itself, [5]
would be perfectly fine, but needs to be turned in something
authoritative (and maintained) as opposed to something that is only
advisory.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

trademark policy draft - redux

[Stefano Zacchiroli]

[ please refer to
  https://lists.debian.org/debian-project/2012/07/msg00047.html
  and subsequent thread for context ]

On Tue, Jul 31, 2012 at 06:07:17PM +0200, Stefano Zacchiroli wrote:
 I'm happy to attach a first complete draft of such a policy, and I'm
 looking for comment on it.

Dear all, after having postponed this for way too long, here is the
second, hopefully final, iteration of the trademark policy draft. I've
discussed with SPI lawyers at SFLC all the comments collected during the
past discussion, namely:

1) [minor] make it clear in the first section that those are permissions
   for using the trademark(s) without having to ask permission
   explicitly (rationale: diminish the burden of answering bogus
   requests)

2) [editorial] DEBIAN - Debian

3) [editorial] SPI, INC - Software in the Public Interest, Inc.

4) [minor] in section Permission to Use, make it clear (again) that
   one should not mail us for permissions already granted in the policy

5) demote the obligation that, when using the trademarks for commercial
   purposes, one should advertise how much of the price will be donated
   to the Debian Project. It is now a recommendation only

6) drop you cannot alter the […] trademarks in any way (rationale: the
   main goal is avoiding customer confusion, and that is already stated
   elsewhere)

7) drop obligation to retain official logo color

8) drop obligation to retain logo proportion when scaling

They have all been implemented except the last one, number (8). Given
the logo is not a registered trademark, we have been advised to be a bit
stricter for that one, hence the requirement remains.  Nonetheless, this
requirement looks compatible with the inbound trademark policy for the
archive we have been discussed previously.

The complete new draft is attached to this mail.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
\section{DRAFT Debian Trademark Policy DRAFT}

Software in the Public Interest, Inc. owns a number of trademarks in both word
and logo form including brands, slogans, styles. This policy encompasses all
marks, in word and logo form, collectively referred to as ``Debian
trademarks''. You can see a non-exhaustive list of Debian trademarks, including
both registered and unregistered (but otherwise legally recognized) trademarks
at: \texttt{http://www.debian.org/trademark} .

The objective of this trademark policy is :

1) To encourage widespread use and adoption of the Debian trademarks,

2) To clarify proper usage of Debian trademarks by third parties,

3) To prevent misuse of Debian trademarks that can confuse or mislead users
with respect to Debian or its affiliates.

Please note that it is not the goal of this policy to limit commercial activity
around Debian. We encourage businesses to work on Debian while being compliant
with this policy.

Following are the guidelines for the proper use of Debian trademarks by
publishers and other third parties. Any use of or reference to Debian
trademarks that is inconsistent with these guidelines, or other unauthorized
use of or reference to Debian trademarks, or use of marks that are confusingly
similar to Debian trademarks, is prohibited and may violate Debian trademark
rights.

Any use of Debian trademarks in a misleading and false manner or in a manner
that disparages Debian, such as untruthful advertising, is always prohibited.


\subsection{When Can You Use the Debian Trademarks Without Asking Permission}

\begin{enumerate}[1.]

\item You can use Debian trademarks to make true factual statements about
  Debian or communicate compatibility with your product truthfully.

\item Your intended use qualifies as nominative fair use of the Debian
  trademarks, i.e., merely identifying that you are talking about Debian in a
  text, without suggesting sponsorship or endorsement.

\item You can use Debian trademarks to describe or advertise your services or
  products relating to Debian in a way that is not misleading.

\item You can use Debian trademarks to describe Debian in articles, titles or
  blog posts.

\item You can make t-shirts, desktop wallpapers, caps, or other merchandise
  with Debian trademarks for \emph{non-commercial usage}.

  You can also make merchandise with Debian trademarks for \emph{commercial
usage}. In case of \emph{commercial usage}, we recommend that you
  truthfully advertise to customers which part of the selling price, if any,
  will be donated to the Debian project. See
  \texttt{http://www.debian.org/donations} for more information on how to
  donate to the Debian project.

\end{enumerate}


\subsection{When You Can NEVER Use the Debian Trademarks Without Asking
  Permission}

\begin{enumerate}[1.]

\item You cannot use Debian trademarks

Re: license of http://udd.debian.org/ data collection?

[Stefano Zacchiroli]

[ Note: I think -qa would be a better place where to discuss this, as it
  is the list where UDD development is happening. Setting M-F-T
  accordingly. ]

On Sun, Dec 16, 2012 at 12:27:29PM +0800, Paul Wise wrote:
 On Sat, Dec 15, 2012 at 7:03 PM, Jonas Smedegaard wrote:'
  What is the license of the collection of data?
 
  Not the script to collect it (I do notice the GPL in the header of above
  referenced script), but the *database* of knowledge that is composed.
 
 Most of the stuff is from packages themselves. Debian packages are
 under a number of different licenses, so the answer is a collection
 of various free (and or non-free) licenses, depending on the package.

If I understand correctly what Jonas is aiming at, that's not (yet) a
satisfactory answer. The license of a collection of a data might very
well be different than the license of the individual pieces of data
itself. I'm not expert on database licensing, but the underlying
intuition here is that there might be a creative effort in assemblying
the data, and that _that_ creative act might be copyrightable and hence
have a license in itself.

In the UDD case, the data collection is destroyed and recreated (with
some minor exception, for the historical tables) at each database
updated pulse. Hence the creativity is mostly captured by the scripts
that do this job.

Still, it is likely that in the future more and more people interested
in UDD will ask what is the license of the collection as opposed
to..., as it is a topic of increasing interest together with the big
data movement.

It would be wise hence to have a proper data collection license
associated to the UDD database. A popular one is ODBL
http://opendatacommons.org/licenses/odbl/ . I suggest we license the
_collection_ that way, also pointing to the sources creating the
database, which will be under their own license.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: [Debconf-discuss] Insider manipulation of DC13 site selection, and apparent coverup

[Stefano Zacchiroli]

On Wed, Dec 12, 2012 at 11:54:05AM +, Ian Jackson wrote:
 However, that DC13 team member did tell me that the DPL was fully
 informed, with all the details, before the DPL approved the DC13
 budget.

Please name names or facts to support this or, alternatively, drop it.

- My budget approval mail (subject to conditions) [1] is dated November
  26th. Before that, I've tried to stay as far away as possible from
  DebConf13 organization, pretty much as I've done in the past 3 years
  as DPL for previous DebConf. Not because I'm mean, but simply because
  I've no spare energies to devote to DebConf organization and I've
  always trusted the DebConf Team to do a good job at that. My
  activities in DebConf organization has basically remained at the level
  of answering, as DPL, to the question I got asked from the team, on
  mostly budget-related manners.

  My main involvement in DebConf organization ever has mostly been at a
  process level, to strengthen the formal relationship between DebConf
  organization and Debian as a Project (see the DebConf11 BoF, the
  chairs delegations, and my various 'bits from the DPL' entries on this
  matter over the years).

- As I recall, the first time I've heard about this anonymous donation
  is from your mail to -project [2], that is dated November 30th, 4 days
  later than [1].

- Later on, on December 2nd according to my IRC logs, a DebConf team
  member insisted, on the basis of I think you should know it, to give
  me some background about that anonymous donation --- that is 6 days
  later than [1]. So, I do *now* know more about this matter, but I
  didn't at the time of the budget approval.

Now, even if I've never considered long term memory to be one of my
strong suites, I do suspect your source is wrong --- at least on this
point.

[1]: http://article.gmane.org/gmane.linux.debian.conference.team/8996 
[2]: https://lists.debian.org/debian-project/2012/11/msg00027.html



I think the above clarification was in order, because you were asserting
(based on sources that are unknown to me) something about myself which
AFAICT is not true.

On the more general matter, that you are clearly still very much
interested in, you probably have noticed that I didn't change my mind
(i.e. un-approve the budget) based on what I've been told on December
2nd. This is because I'm in stark agreement with the position that Russ
expressed on -project [3].  I agree with you that a donation coming from
a DebConf team member with strings attached to a venue would have been
unappropriate. And that is the conclusion that has been reached by the
team (quotes because it's not clear to me how the sponsorship sub-team
is structured or works). That was indeed the expected outcome, I'm happy
it's been achieved --- well in advance wrt budget approval and before my
knowledge about all this issue --- and I found no further reasons to
complain.

[3]: https://lists.debian.org/debian-project/2012/12/msg00034.html

Cheers.
-- 
Stefano Zacchiroli . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: [Debconf-discuss] [Debconf-discuss-discuss-discuss-and-keep-discussing] ...

[Stefano Zacchiroli]

On Wed, Dec 05, 2012 at 08:38:42AM +0100, Josselin Mouette wrote:
  If other people find that it *had almost nothing to do* with DebConf,
  please tell us.
 
 As currently planned, Debconf 13 has nothing to do with a conference you
 would ask sponsorship to a fortune 500 company for.

You mean those companies that from time to time send their managers and
teams to spend time in the woods, sleeping in tents, because it's so
good for team building? :-) /joke

Jokes aside, over the past years I've spoken with representatives of
those companies, discussing their interests in supporting financially
Debian --- by sponsoring DebConf or by donating to Debian over the
year. My personal bottom line is that the kind of gain they look for
when sponsoring us is different than the usual advertisement to get new
customers gain that you often find at technology conferences.

Several of those companies asked me, at the time of evaluating whether
to sponsor Debian or not, questions like how can we turn our money into
code?. Companies that ask those usually rely on the well being of
Debian and want to make sure their money help volunteers having fun
improving our OS. It's some sort of strategic investment. Or, for the
more cynical, they simply have an already approved budget for FOSS
sponsoring and they need to distribute it among well reputed FOSS
projects.

Granted, the choice of DebConf venue (and way more so the choice of
country) will have an impact on companies that do hope to get new
customers by sponsoring a conference. We might lose some of them. But at
the end of the day, what we should care about money-wise is whether the
conference budget is sustainable or not. If it is, I wouldn't care much
about whether it has been assembled by a handful of fortune 500
companies, a long tail of small-ish companies, or funding by public
administrations.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Position statements short of a GR - DPL statements

[Stefano Zacchiroli]

On Mon, Oct 29, 2012 at 05:39:08PM +, Ian Jackson wrote:
 There are often topics about where it would be useful to have a
 statement of position, or some recommendations for project
 participants (or for users or citizens).  I'm speaking here primarily
 of nontechnical matters.

Ack.

 But there are also topics which aren't covered by an existing team or
 delegation.  There are a couple of these that are on the DPL's plate
 right now:
 
   - Dealing with inbound trademarks.  Ie, how best to deal with
 possible trademark risks in the software we deal with;

For ease of reference, this is the summary I've posted here
https://lists.debian.org/debian-project/2012/02/msg00073.html

I think it's a very good example. On one hand we did the corresponding
discussions and synthesized the outcome in a summary that was consensual
at the time. On the other, if we simply leave things as they are, we
will lose track of the result of that discussion and we will be doomed
to repeat the whole discussion eventually. The need is then to document
the result somewhere, as a project best practice.

 Up to this point in the project we have normally published only:
   - GRs

FWIW, we can theoretically keep on using GRs. But there is a huge
disincentive in doing so due to the heavy footprint of the process.
Additionally, as the last part of the diversity statement GR has shown,
there are also legitimate concerns that GR results are set in stone,
hence improving them (which is generally needed over time) will force
to use the same heavyweight process over and over again.

 I think it would be useful to add a new category to this list:
 
   - Formal policy document from the DPL
 
 Of course like any other DPL decision these would be published by the
 DPL after discussion and consensus-seeking.  And if the matter turns
 out to be too controversial, or the DPL wants to make sure the
 document has a good mandate, the GR process is available (either via
 the route of a DPL-initiated GR, or an overruling GR).

I think this would be sensible, but I'm biased on this discussion for at
least 6 more months :-).

I'd like to point out that, de facto, DPL statements already exist: if
a DPL is interviewed at events or for magazines for example, people will
pay a lot of attention to what is said and consider them as somehow
official _project_ statements.  And if those statements are annoying for
the project, I'm pretty sure GR will be used to overrule the DPL. We
have seen examples of this in the past, both regarding the DPL and other
core teams.

So I don't think formalizing this would change current practices. I'll
just give us a new, less volatile place (e.g. a www.d.o section) where
to store information that at present have no good place where to live.

I'd like to hear more thoughts on this matter...
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: ditching the official use logo?

[Stefano Zacchiroli]

On Sat, Oct 13, 2012 at 04:09:18PM -0400, Paul Tagliamonte wrote:
 I was hoping someone else would chime in (I hate dominating discussions
 on MLs, so someone, please cut me off)

No worries, it's always good to have (constructive) feedback :-)

  The arguments in favor of keeping it seem reasonable in the abstract
  but, frankly, all a tad too theoretical. As a matter of fact we do not
  use the restricted logo that much (if at all) in official documents: as
  DPL I've signed quite a few of them (letters, certificates, some
  contracts, etc.) and I've never used the restricted logo. I also don't
 
 I mean, sure. This is something we can change, if we decide to do so.
 It's also true this is not currently an active concern.

Oh, I fully agree with that. My, let's say, cultural point is that I
don't see us doing that, ever. Simply because using restricted content
is something we viscerally don't like. So, even if rationally we see
reasons to use the restricted logo somewhere, I don't see it us doing
and sticking to it. But again, if we still consider something
potentially useful to do, let's keep the possibility --- we'll see a few
years from now what happens...

  How about the attached patch?
 
 Looks great to me. Calling it restricted is technically correct, and
 well, that's the the best kind of correct.

Given the patch seems quite consensual, and appreciated from both
camps in this discussion, I've just applied it. It will go live at the
next website rebuild.  Wording improvements are appreciated, as usual.

As I've forgotten to do so in the initial patch proposal, I should give
credit to Ian Jackson for proposing the entirely appropriate restricted
logo name, during an IRC conversation: thanks Ian!

Thanks everybody for this thread,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: ditching the official use logo?

[Stefano Zacchiroli]

Thanks to all participants on this thread thus far.

On Wed, Oct 10, 2012 at 12:05:46PM +0200, Luca Capello wrote:
 On Mon, 08 Oct 2012 16:52:18 +0200, Paul Tagliamonte wrote:
  or other official documentes should carry the official logo, so
  their reproduction and modification is not legal.
 I completely agree with such a point.

All in all, we seem to have people on both camps of keep it and ditch
it, ... as it often happens :-)

The arguments in favor of keeping it seem reasonable in the abstract
but, frankly, all a tad too theoretical. As a matter of fact we do not
use the restricted logo that much (if at all) in official documents: as
DPL I've signed quite a few of them (letters, certificates, some
contracts, etc.) and I've never used the restricted logo. I also don't
see us doing that anytime soon, because we love free content and we're
naturally *not* inclined to use non-free stuff. Also, there is a
communication backlash if we start using the restricted logo in such
places now, because it is not known, and people will wonder hey, this
is not the Debian log, what's going on?.

But let's assume for the sake of the argument we want to keep both
logos. (Maybe nowadays we're not yet convinced it's pointless to keep
the restricted one, but maybe we'll be in a few years from now if our
pattern of usage for it won't change *g*.)

How about the attached patch?

In hindsight, it doesn't change the logos, but just improve our
communications about them. It clarifies that our preferred logo is the
open use one, and call the other for what it is, a restricted logo for
basically internal use only. It also explicitly encourages people to use
the open use logo, when referring to Debian.

Would such a patch constitute an acceptable compromise?

Thanks in advance for your comments,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
Index: index.wml
===
RCS file: /cvs/webwml/webwml/english/logos/index.wml,v
retrieving revision 1.65
diff -u -r1.65 index.wml
--- index.wml	30 Sep 2012 13:51:14 -	1.65
+++ index.wml	13 Oct 2012 14:11:52 -
@@ -1,14 +1,12 @@
 #use wml::debian::template title=Debian logos BARETITLE=true
 #include $(ENGLISHDIR)/logos/index.data
 
-pAlthough Debian can be obtained for free and will always remain
-that way, events such as the problem with the ownership of the
-term ldquo;Linuxrdquo; have shown that Debian needs to protect its
-property from any use which could hurt its reputation./p
-
-pDebian has decided to create two logos: a href=#official-useone
-logo/a is for official Debian use; the a href=#open-useother
-logo/a falls under an open use type license./p
+pDebian has two logos. The a href=#open-useofficial logo/a (also known
+  as open use logo) contains the well-known Debian qswirl/q and best
+  represents the visual identity of the Debian Project. A separate, a
+  href=#restricted-userestricted-use logo/a, also exists for use by the
+  Debian Project and its members only. To refer to Debian, please prefer the
+  open use logo./p
 
 hr
 
@@ -51,11 +49,11 @@
 col width=35% /
 /colgroup
 tr
-th colspan=2a name=official-useDebian Official Use Logo/a/th
+th colspan=2a name=restricted-useDebian Restricted Use Logo/a/th
 /tr
 tr
 td
-h3Debian Official Use Logo License/h3
+h3Debian Restricted Use Logo License/h3
 
 pCopyright (c) 1999 Software in the Public Interest/p
 ol
@@ -74,7 +72,7 @@
 	liWe reserve the right to revoke a license for a product/li
 /ol
 
-pPermission has been given to use the official logo on clothing (shirts,
+pPermission has been given to use the restricted logo on clothing (shirts,
 hats, etc) as long as they are made by a Debian developer and not sold for
 profit./p
 /td


signature.asc
Description: Digital signature

DFSG-free relicensing of the Debian logo(s) - DONE

[Stefano Zacchiroli]

On Mon, Aug 27, 2012 at 05:36:04PM +0200, Stefano Zacchiroli wrote:
 The actual relicensing shall be done by SPI (as copyright owner) and has
 not happened yet. But it should happen during the next SPI board
 meeting, scheduled for September 13th, 2012.

The above has now happened. SPI resolution is at:

  http://www.spi-inc.org/corporate/resolutions/2012/2012-09-07.rtb.1/

Yesterday I've committed the change to the licensing information at:

  http://www.debian.org/logos/

the change is now live.

 If you're working on Debian artworks or the like, feel free to start
 using the official logo in them. Assuming that it will be DFSG-free RSN
 is now a safe bet. You should just avoid claiming that it is *already*
 free until my final announcement here (after September 13th).

For the -desktop people, I've reviewed the content of the desktop-base
package, and it seems that none of the new themes uses the debian
label, so there should be no need to change them at all. But if you
didn't use the debian label for licensing reason, you still have a to
add it (to be verified with the package maintainer and release team for
unblock reasons, though). The spacefun team does use a debian label,
typeset in the non-official typeface, though. If you want to update it
to use the official typeface, you do have a chance to do so now (under
similar constraints than above).

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

ditching the official use logo?

[Stefano Zacchiroli]

Note for those who have never looked into this: the official use logo
is the one with the bottle. Its license is non-free, fairly restrictive,
and only allows usage after some official vetting by Debian, in various
forms.

On Mon, Oct 01, 2012 at 12:14:04PM +0200, Bernhard R. Link wrote:
 What is the trademark situation of the official logo? I was under the
 impression that is still only to be used for Debian proper so isn't the
 use of the official logo in themes quite problematic for derivatives
 that do not derivate enough to change the themes?

I haven't touched (nor looked into) the official logo. My impression is
that that that logo is massively underused and basically unknown to most
of our public out there. My personal take on it is that we should simply
ditch it, focusing on a single logo (the open use one) with a
DFSG-free license, that we do now have.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Why LGPLv3/CC-by-sa-v3.0 for the logo?

[Stefano Zacchiroli]

On Thu, Sep 20, 2012 at 11:31:55PM +0200, Francesco Poli wrote:
 There are two issues with your previous reply:
 
  * it was not clear that your request for more info also included
 questions about the particular copyright licenses to be chosen

YMMV, I guess.

  * the reply itself was only sent to debian-project (something that you
 have just done again...), despite my explicit request to be Cced on
 replies

I'm not sure it is correct to call this issue. You asked the
*courtesy* of Cc:-ing you on replies. I generally try to be courteous,
but it's easy to forget about these things when they are not
automated. I'm sorry, but I forgot (again) to Cc you. I humbly suggest
that you use headers like Mail-{Followup,Reply}-To in the future. That
would decrease the chances that someone forget about respecting your Cc
courtesy requests.

 But let's assume, for the sake of argument, that a copyleft
 *copyright* license is indeed the right choice to make.  Even assuming
 this, I am deeply disappointed by the GPLv2-incompatible license
 choice.
[…]
 I repeat: I strongly recommend to *at least* choose the GNU LGPL v2.1
 or later!

Your disappointment was clear to me, and I'm sorry about it. But in
choices that have alternatives, it is often the case that someone will
be disappointed by each of the possible choices. In this specific case,
I've *considered* your comments and investigated each of them further.
But in the end I had to make a decision regarding a specific asset of
the Debian project, and did that. I've weighted the drawbacks that you
mentioned (modulo the ones I completely disagree with --- like your
allegation in this mail about the broken copyleft mechanism in GPLv3)
and considered them not severe enough to choose otherwise.

 I am really disappointed by this decision and I hope you will
 reconsider.

I'm sorry about your disappointment, but I'm not inclined to reconsider.
In fact, the decision has now been implemented as a SPI board resolution
last week:
http://www.spi-inc.org/corporate/resolutions/2012/2012-09-07.rtb.1/

I haven't yet done a proper announcement, simply because I yet have to
prepare the patch to update the logo license page on the Debian website.

If you feel strongly about this (as you clearly do), I remind you that
the right path to escalate is not starting a thread against the decision
on -project and/or -legal, but rather propose to override the decision
via the appropriate Debian mechanisms.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Why LGPLv3/CC-by-sa-v3.0 for the logo? [was: Re: bits from the DPL: August 2012]

[Stefano Zacchiroli]

On Sun, Sep 09, 2012 at 09:31:41PM +0200, Francesco Poli wrote:
 I am following up to your August bits from the DPL, since I still have
 to understand why it was suggested to dual license the Open Use Logo
 with Debian under LGPLv3+ / CC-by-sa-v3.0.
 
 I have already asked in
 https://lists.debian.org/debian-project/2012/08/msg00017.html
 but I have received no answer for this question.

As I've pointed out in my reply to that, I've collected your comments
though and asked more info about that. In particular, I've asked the
possibility about relicensing under more liberal licenses (such as
Expat) and I've been advised not to do that. I don't have a detailed
argumentary to share, as the discussion has been informal, but the main
argument is that a license that basically allows you to do whatever you
want is a bad mix with marks (be them registered or not). This explains
the general choice of copyleft.

 Anyway, as long as a copyleft is needed, I think that a LGPLv3+ /
 CC-by-sa-v3.0 dual license would be a poor choice, since it's
 GPLv3-compatible, but GPLv2-incompatible.

Regarding the version of the license (which I've been advised to
choose), instead of reasoning about abstract issue, I've reviewed some
of the usual documentation material and also asked [1] the teams that
IMHO would be potentially impacted the most by the change. I've asked
explicitly if they had issues with the license choice, including the
version. Having got no reasons to choose otherwise I've ended up
deciding, under my sole responsibility of course, for the aforementioned
licenses.

[1] https://lists.debian.org/debian-www/2012/08/msg00115.html

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: A media type for the machine-readable copyright format ?

[Stefano Zacchiroli]

On Tue, Sep 11, 2012 at 08:10:18AM +0900, Charles Plessy wrote:
 here is the information that I consider submitting to the IANA.

Hi Charles, thanks for taking care of this! I'm no expert in the sort of
document you're submitting, but to my layman eyes all seem good.

 Person  email address to contact for further information:
   Charles Plessy ple...@debian.org
[…]
 Change controller:
   The Debian Project http://www.debian.org

I wonder if the contact address shouldn't be something less tied to
project individuals, like for instance debian-project@lists.d.o. Given
there is already a separation between this and the author field
(allowing to give proper credit to who worked on the application), I
think it'd be better to have as contact point some role address of
sort. What do you think?

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: A media type for the machine-readable copyright format ?

[Stefano Zacchiroli]

On Tue, Sep 11, 2012 at 04:41:52PM +0900, Charles Plessy wrote:
  I wonder if the contact address shouldn't be something less tied to
  project individuals, like for instance debian-project@lists.d.o. Given
  there is already a separation between this and the author field
  (allowing to give proper credit to who worked on the application), I
  think it'd be better to have as contact point some role address of
  sort. What do you think?
 
 Hi Stefano and debian-policy@lists.d.o subscribers,
 
 I was wondering about the same, but I was worried that having a
 broad-readership mailing list as a contact point would create confusion about
 who is expected to answer.  How about debian-policy@lists.d.o ?  It is anyway
 the contact point for the specification itself.

Hi again Charles,
  in fact the above is a typo of mine :-). debian-*policy*@lists.d.o is
in fact what I wanted to propose. Sorry for the confusion.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: Presentation of iso downloads - simpler like Fedora?

[Stefano Zacchiroli]

On Thu, Aug 16, 2012 at 08:11:13AM -0300, Ben Armstrong wrote:
 On 08/13/2012 05:10 AM, Philip Hands wrote:
  While contrasting with Ubuntu, there is also the issue of Debian
  Live CDs which are close to impossible to find, and if you
  eventually manage to find them, turn out to be too big to fit on a
  CD.
 
 I have put some work into www.debian.org to improve things. The click
 path is:

Thanks a lot for working on this. Considering that installing Linux
(as they say) is still something very scary for many potential users out
there, advertising prominently the possibility of trying Debian out
without having to touch your system is something that I consider very
important. I'm happy to see interest and work in this direction.

Along the same lines, I suggest to simplify the choices according to the
ways of acquiring Debian that are more likely for users. The suggestion
is implemented in the attached patch:

- it put first the two options that I think are more likely for our
  users, i.e. downloading debian (be it in the live flavor of not), and
  the other options (buying CD or pre-installed systems) next

- the choice of small vs large is now a sub-choice of downloading an
  installation image (the title of the section points to small, as I
  believe is the choice we recommend)

The wording can surely be improved.

Let me know if you want a bug report against www.d.o to keep track of
this.

Thanks for considering,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »
Index: index.wml
===
RCS file: /cvs/webwml/webwml/english/distrib/index.wml,v
retrieving revision 1.53
diff -u -r1.53 index.wml
--- index.wml	3 Apr 2012 21:49:43 -	1.53
+++ index.wml	21 Aug 2012 10:01:50 -
@@ -12,49 +12,43 @@
 
 div class=line
   div class=item col50
-h2a href=netinstDownload a small installation image/a/h2
-   pstrong
-  Use Internet to download additional files during installation.
-   /strong/p
-   p
-  These small qnetinst/q images can be downloaded quickly
-  and should be recorded onto a CD/DVD/USB disk.
- These allow you to download only those Debian packages that
- you actually want, but require an Internet connection on the
- machine you are installing Debian onto.
-   /p
-
-ul class=quicklist downlist
-lia title=Download installer for normal 32-bit Intel and AMD PC
-   href=stable-images-url//i386/iso-cd/debian-current-tiny-cd-release-filename/-i386-netinst.iso32-bit PC netinst iso/a/li
-lia title=Download installer for 64-bit Intel and AMD PC
-   href=stable-images-url//amd64/iso-cd/debian-current-tiny-cd-release-filename/-amd64-netinst.iso64-bit PC netinst iso/a/li
-/ul
+h2a href=netinstDownload an installation image/a/h2
+pDepending on your Internet connection, you might choose between:/p
+ul
+  lia a href=netinststrongsmall installation image/strong/a:
+	can be downloaded quickly and should be recorded onto a removable
+	disk. To use this, you will need a machine with an Internet
+	connection.
+	ul class=quicklist downlist
+	  lia title=Download installer for normal 32-bit Intel and AMD PC
+		 href=stable-images-url//i386/iso-cd/debian-current-tiny-cd-release-filename/-i386-netinst.iso32-bit
+	  PC netinst iso/a/li
+	  lia title=Download installer for 64-bit Intel and AMD PC
+		 href=stable-images-url//amd64/iso-cd/debian-current-tiny-cd-release-filename/-amd64-netinst.iso64-bit
+	  PC netinst iso/a/li
+	/ul
+  /li
+  lia larger a href=CD/strongcomplete installation
+	image/strong/a: contains more packages, making it easier to install
+	machines without an Internet connection.
+	ul class=quicklist downlist
+	  lia title=Download torrents for normal 32-bit Intel and AMD PC
+		 href=stable-images-url//i386/bt-cd/32-bit PC torrents/a/li
+	  lia title=Download torrents for 64-bit Intel and AMD PC
+		 href=stable-images-url//amd64/bt-cd/64-bit PC torrents/a/li
+	/ul
+  /li
+/ul
   /div
   div class=item col50 lastcol
- h2a href=../CD/Download large installation images/a/h2
-   pstrong
-  Useful when the install target has no Internet connection.
-   /strong/p
-   p
-  The CD/DVD images can be downloaded using
-  a href=../CD/http-ftp/HTTP/FTP/a,
-  a href=../CD/torrent-cd/BitTorrent/a, or
-  a href=../CD/jigdo-cd/Jigdo/a.
-   /p
-   p
-  The large CD and DVD images contain more packages, making it
-  easier to install machines without an Internet connection.
-  However, if you get a whole set of CDs or DVDs, you will get a lot of
-  packages that you won't actually use.
-   /p
-
-ul class=quicklist downlist
-lia title=Download torrents for normal 32-bit Intel

Re: trademark policy draft

[Stefano Zacchiroli]

On Mon, Aug 13, 2012 at 03:30:16PM -0700, Steve Langasek wrote:
  Down to the specificities of Debian procedures, I consider my duty
  to take care of Debian assets, including trademarks. I would not
  take the responsibility of acting in a way that --- according to our
  legal advisors --- might endanger them..
 
 Even if there was a clear consensus that endangering the trademark was
 the Right Thing To Do?
[…]
 For a free software project like Debian, I believe it's more important
 to uphold the principle of not being jerky to our neighbors than it is
 to have an ironclad assurance that our trademark could never be
 invalidated.  I don't think the argument we could lose our trademark
 unless we [...] is complete unless it also includes some examination
 of how likely that outcome really is.

You raised various important points.

According to my reading of the sub-thread started at Thijs' message, we
were discussing giving up the trademarks all together (just let go of
these trademarks [1]). As it happens, different participants in the
sub-thread might have head different opinions. But on such an extreme
position, yes, I don't think I would trust apparent consensus on any
mailing list.

For various reasons. One is that many people tend not to care about
bureaucratic topics (and I surely won't blame them for that :-)).
Another is that it'd be a typical instance of the age long democracy vs
technocracy debate. Very few of us --- if any --- are experts in
trademark law (as several threads have shown), and I do not consider
myself among them. So the consensus would hardly be well-informed.

The above doesn't imply we could not implement the extreme position of
giving up trademarks. It simply mean that I wouldn't personally do it,
on the sole basis of apparent consensus. There are other ways, such as a
GR, overruling me or not (depending on how it'll be formulated0. It
wouldn't be such a big deal, and I surely would not take it personally.

[1] as I'm not sure if a formal act to do that exists, let's assume for
the sake of this discussion give up trademark ~= act in a way
that would be considered, trademark-wise, foolish by any trademark
expert you could find on the planet

 I'm hoping to write a longer response to the proposed policy where I
 can do justice to the specifics,

Please do :-)

 but for the moment, suffice it to say that I think that some of the
 recommendations for how to protect our trademark cross the line from
 things it's reasonable for everyone to do to protect their mark into
 jerky things that you do because there's some bit of case law
 somewhere that led to a mark being invalidated and you're paranoid
 that the same thing will happen to you.  Sometimes the right answer
 is that the case law is *bad* and needs to be overturned - which never
 happens if no one is willing to take a stand against it.

I agree with this. In dealing with lawyers on behalf of Debian, I've
quickly learned that there are almost never 100% safe or 100% risky
positions. It is *always* a cost/benefit/risk analysis. You ask the
experts to evaluate the risks of the positions you're interested in, and
then you pick a position.

I wouldn't call the position implemented by the first policy I've posted
here paranoid. But, as I mentioned before, there might be extra
constraints that might be loosened, which have fallen through the
cracks. I do hope that most of the criticism that have been raised in
this thread could be addressed in the second draft --- but as I haven't
yet received it, I'm not sure yet.

If you, or anyone else, have arguments to justify the loosening of
further constraints in the policy, by all means bring them forward. But
please realize that I will likely turn down arguments of the I think
that... kind, when they go against the legal advice we've got.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: trademark policy draft

[Stefano Zacchiroli]

On Mon, Aug 06, 2012 at 03:25:55PM +0100, Ian Jackson wrote:
 Thijs Kinkhorst writes (Re: trademark policy draft):
  On Wed, August 1, 2012 18:54, Russ Allbery wrote:
   We can choose to abandon our trademark and make it indefensible, but we
   should do that intentionally and not under an illusion that we're just
   creating a better usage policy.
 
 I would not be in favour of this.

FWIW, I agree with Ian's position here.

Generally speaking, I think there is room in Free Software for project
marks and that, in principle, there is nothing wrong with defending
them. As observed elsewhere in this thread, it is just hard to defend
them in a reasonable way, given that the law is what it is. Oddly
enough, trademark policies that try to embrace Free Software principle
are still relatively uncharted territory, which is slowly getting better
in recent years. By giving it a try, working together with lawyers that
do understand Free Software, I think we can actually contribute
something useful for other Free Software projects out there.

Down to the specificities of Debian procedures, I consider my duty to
take care of Debian assets, including trademarks. I would not take the
responsibility of acting in a way that --- according to our legal
advisors --- might endanger them..

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: trademark policy draft

[Stefano Zacchiroli]

On Sun, Aug 05, 2012 at 11:08:04PM +0200, Francesco Poli wrote:
 first of all, thanks for working on this issue, especially taking into
 account that the outcome could be a hopefully acceptable trademark
 policy and a DFSG-free Open Use Logo with Debian, as you mentioned in
 your latest bit from the DPL message [1]:
[…]

As a general status update on this:

- I've collected the comments I got from this thread and elsewhere
  (private mail, /query, etc.), and forwarded them to SFLC, asking for a
  new draft. (Tentative) ETA for it is this week.

- to disentangle the issues of 1/ relicensing the logo under a better
  (copyright) license and 2/ defining a new trademark policy, I've also
  asked for a minimal patch to our *current* trademark policy that would
  allow the relicensing to happen in isolation.

Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Debian Project Leader . . . . . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: trademark policy draft

[Stefano Zacchiroli]

On Tue, Jul 31, 2012 at 01:37:06PM -0600, Paul Wise wrote:
  I'm happy to attach a first complete draft of such a policy, and I'm
  looking for comment on it.
 
 Some of the things that are explicitly allowed by the policy are
 things that AFAIK are not restricted by trademark law, is the purpose
 of including those to reduce the number of questions from people who
 aren't well informed about the restrictions in trademark law?

Yes, and in my experience that is very much needed. For example, we
already get quite a number of requests at trademark@d.o which are, in
fact, fully covered by nominative usage. As such, they are useless
requests but they still come in. Documenting more visibly when they are
not needed will reduce our load in handling them.

 Does the domain name restriction mean that sites like these will have
 to rename themselves?

Peter is right on this: we should give them explicit permission. But
note that this part, in most cases, is a no-op change wrt the current
policy, which already restricts the usage of the debian name in domain
names by others.

Cheers.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: trademark policy draft

[Stefano Zacchiroli]

On Wed, Aug 01, 2012 at 07:10:51AM +0900, Charles Plessy wrote:
 I think that we should show the example and remove restrictions on the
 commercial use of our trademark.  We can of course, in a non-normative
 section, keep a recommendation to indicate if a donation will be made
 to Debian.

Thanks for your feedback on this.

 Here are minor comments.
 
  - It would be nice to indicate somewhere which restrictions stem from
laws, and which restrictions are additions by us.

As a disclaimer, trademark policies are not as binding as other law-ish
stuff we tend to be more familiar with, such as copyright licenses. They
offer the owner own interpretation of what constitute proper usage of
some mark. This is to say that stem from laws is less well-defined
than what you might think.

That said, I think I've already commented on this in my premise. We've
asked SPI lawyers for a trademark policy as free as possible, as long
as it allows us to retain our trademark rights. As long as we trust
their judgements what we've got is, essentially, stemming from law.

The only addition is the merchandise provision, on which I've explicitly
asked for feedback.

  - If this policy focuses on trademarks owned by SPI, perhaps it can
exhaustively list them ?

Yes, but they'll be listed side by side with the policy, rather than
within it. In fact, this is already the case at
http://www.debian.org/trademark/

  - Is it necessary to capitalise DEBIAN in the document ?

In my experience is the canonical form that one use in such documents; I
believe textual trademarks are case-insensitive anyhow.

  - Requests to not be misleading and be truthful are vague.

Again, common and tested practice in trademark law, AFAIU.

  - When one can use the Debian trademarks without asking, is it because of 
 fair
use, or is it because Debian grants a trademark license ?

Neither. First of all it wouldn't be fair use (which is in the realm
of copyright), but it'd rather be nominative use (which is in the
realm of trademark). And again, it is our own interpretation of what
would constitute usage of our marks in a way that does not dilute the
Debian identity, which is the purpose of a trademark policy document.

It'd be useful if people interested in participating in this discussion
could review some general info about trademark law. They're available in
a number of places, including wikipedia and --- for a more Free Software
oriented view --- in a nice FAQ on SFLC website.

  - Imagine that we in Debian follow the spirit of this policy when using other
trademarks (GNOME, Linux, etc.) in our websites.  Wouldn't the requriement
of including a disclaimer be a bit heavy ?

Nope, as nominative use is permitted by trademark law in general anyhow.

Cheers.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: trademark policy draft

[Stefano Zacchiroli]

On Wed, Aug 01, 2012 at 10:41:31AM -0400, Joey Hess wrote:
 Stefano Zacchiroli wrote:
  \item You can use DEBIAN trademarks to make true factual statements about
DEBIAN or communicate compatibility with your product truthfully.
 
 Can I use DEBIAN trademarks to make snarky ill-supported statements?
 (Anticipating a decrease in list traffic.)

(Fearing an increase in nitpicking threshold.) Well, you can, people
will, and I'm sure nobody will bother, on average. But I can imagine all
sorts of journalistic declarations about Debian that would undermine
the project reputation. If they are factual (or non-disprovable) fine,
if not this gives the project a edge to defend its reputation/identity.
This is what trademarks are about.

  \item You cannot use DEBIAN trademarks in a domain name, with or without
commercial intent.
 So debian.mirror.my.org is illegal?

I've been correct by Mako on this before. Short answer: hostname !=
domain name, so debian.mirror.my.org is perfectly fine.  (No, I don't
have a clear definition for domain name to offer, but it is intended
here as the things that you register via a domain name registrar.)

For the record, this provision is already present in our _current_
trademark policy, quoting: « we insist that no business use the name
‘Debian’ in the name of […] a domain name ».

Cheers.
-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: trademark policy draft

[Stefano Zacchiroli]

On Wed, Aug 01, 2012 at 05:10:41PM +0100, Lars Wirzenius wrote:
 On Wed, Aug 01, 2012 at 05:50:56PM +0200, Stefano Zacchiroli wrote:
  (Fearing an increase in nitpicking threshold.) Well, you can, people
  will, and I'm sure nobody will bother, on average. But I can imagine all
  sorts of journalistic declarations about Debian that would undermine
  the project reputation. If they are factual (or non-disprovable) fine,
  if not this gives the project a edge to defend its reputation/identity.
  This is what trademarks are about.
 
 Do I understand correctly? If a journalist says bad things about Debian,
 you want to use trademark law to shut them up?

No, I'm trying to explain why there are provisions like this one. But
I'm kind of man in the middle here and I can't say I like it. In fact, I
don't like it at all.

We've some trademarks, and that's a fact. We've been advised, via the
legal trademark owners (SPI), to set up a proper trademark policy for
it. Because without it: (1) it might turn out to be useless to have
them, and (2) we hand up over protecting on other sides (e.g. licensing
stuff like our own logo under non-free licensing). I'm trying to solve
this intertwined mess.

Also, I do have an interest in this, because it's ended up also on my
shoulder for the past years to deal with trademark stuff, including when
they're actually useful (e.g. in retrieving squatted domain names).

And the way I've chosen to do it is given a spec to SPI lawyers saying,
as free as possible (with only one exception, which I've clearly
marked as such). And I've posted here the result. It is possible that
some of not needed stuff has creeped in, of course, but it is unlikely.
To stay on the safe side: I'll double check by explicitly asking about
this provision and if it is a good idea or not to remove it (with a
rationale).

In the meantime, I'd appreciate if you can refrain from assuming that
it's me wanting to have specific provisions in the policy (modulo the
mentioned exception) and also from assuming I want to use them in
specific ways.

  I've been correct by Mako on this before. Short answer: hostname !=
  domain name, so debian.mirror.my.org is perfectly fine.  (No, I don't
  have a clear definition for domain name to offer, but it is intended
  here as the things that you register via a domain name registrar.)
 
 If you don't have a clear definition of what it means, then having it
 in the license is not acceptable, in my opinion.

It is not a license. It is a policy. As such it is more fuzzy.

-- 
Stefano Zacchiroli zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ..   http://upsilon.cc/zack   ..   . . o
Debian Project Leader...   @zack on identi.ca   ...o o o
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature