Re: Banning Norbert Preining from planet.d.o

[Dr. Bas Wijnen]

This entire thread makes me worry quite a bit about the current state of
Debian, so I feel the need to respond to several posts in it.

Tl;dr: Debian should be a project where everyone can feel comfortable to
contribute. That is not possible if we allow bullying to stand unchallenged.

On Wed, Mar 23, 2022 at 07:23:25AM +0100, to...@tuxteam.de wrote:
> On Tue, Mar 22, 2022 at 09:01:27PM +0100, Thomas Goirand wrote:
> In my opinion it seems better to let it be. Granted, Norbert's
> behaviour comes across as resenful, which isn't very constructive,
> but trying to respond in kind risks making things worse rather
> than better.

I understand this impulse and in my personal life, this is often what I do.
However, it is wrong, especially in an environment where more people are
involved. If someone tries to make me feel bad and I ignore it, there is not
much harm. However, if they do the same to someone else, it's different. This
is because the other victim may not be in a position to ignore it. For whatever
reason, they may not be able to mentally defend themselves as I can. So while I
might conclude "they're ignoring it, so it's probably not a real problem", that
conclusion may be incorrect. Therefore, it's up to people like me, who can
handle the abuse that may result from it, to speak out and try to stop the
behavior.

Because of this, while I'm sympathetic to your impulse of ignoring bad
behavior, that is in fact a very counterproductive thing to do.

On Wed, Mar 23, 2022 at 06:01:02PM +, Martina Ferrari wrote:
> I saw this message yesterday, and left me thinking how nobody seems too
> concerned with how Preining's actions have impacted and continue to impact
> members of this project.

Indeed. Thanks for posting this. I have not followed Norbert's interactions
with the project closely, but the things you mention here make it
overwhelmingly clear that he is indeed the abuser, not the victim.

> It is funny (not) to see the person I called an asshole back then -for
> stating publicly that he chooses to intentionally misgender transgender
> people- is still having opinions in this thread. It is all very polite, of
> course; after all, nobody really cares about the people who get hurt.

It's not entirely clear to me if Norbert was the one doing the misgendering or
someone who defended him, but I'm leaving this quoted as an example of behavior
that is extremely hurtful, and for which the victims typically aren't in a
mental state to defend themselves properly. Anyone who cares about the
wellbeing of our contributors should realize this. "This person misgendered
someone on purpose" and "someone complained about it" are not equally
offensive. On the contrary: the former is offensive and because of that the
latter is a positive thing to do.

> Debian keeps showing for anybody to see that as long as you keep your tone
> down, you will be allowed to bully, harass, and generally make others
> miserable; that nobody cares enough to stop it.

Again, thank you for posting this. I hope you're able to handle everything.
Let's all make sure that this problem goes away.

On Wed, Mar 23, 2022 at 05:07:06PM +0100, Diederik de Haas wrote:
> On woensdag 23 maart 2022 14:05:57 CET Antonio Terceiro wrote:
> > ¹ of course correlation is not causation, I am not saying the perceived
> >   growth is happening *because* of the CoC etc.
> 
> Indeed. It could also be *in spite of*.
> There's an equal amount of evidence for that: zero.

Your post suggests that until causation is proven, correlation should be
ignored. Why would you think that?

There was an assertion that we are losing lots of contributors because we
trying too hard to be nice. Instead of going "no they aren't", "yes, they are",
Antonio got the numbers that can show such an effect. I thank him for that,
this is how we want to debate among smart people. But of course those numbers
aren't purely showing one effect, so he adds a disclaimer about it. Even
better. To go from there to "those numbers mean nothing at all" is nonsense
though. They are still the best way we have to check if the assertion is true.
Even if they don't give a definitive answer, they do give an indication. That
has value. And the alternative is a fact-free opinion war, which has zero
value.

> > > Mailing lists seem to be really quiet compared to older times, traffic
> > > on IRC is also far less traffic than it used to be. Maybe
> > > communication shifted to other media or maybe DDs are more silent
> > > because they fear to be punished in some way or another for what they
> > > say.
> > 
> > I see that being thrown around a lot, yet nobody has never received any
> > real sanction in the project for giving their opinion on a topic,
> 
> Self-censorship is also a thing.
> I could say there's a correlation between self-censorship and lower ML 
> traffic, 
> but for that there's also an equal amount of evidence: zero

Yes, self censorship is the entire point here. Antonio's statement was that
it's 

Re: Debian and Non-Free Services

[Dr. Bas Wijnen]

On Thu, Sep 12, 2019 at 07:49:26PM +0200, Ansgar wrote:
> >   Subject: Free Software Needs Free Tools
> >
> >   No Debian contributor should be expected or encouraged, when working
> >   to improve Debian, to use non-free tools.
> 
> Does this include:
> 
>  - non-free firmware on Debian hardware,
>  - non-free software for interacting with hardware,
>  - non-free backup systems?

As far as I'm concerned, yes. But note that the proposal is not to say "our
users must not be allowed to use github". It's "our developers must not be
allowed to force contributors to use github".

I think that is very reasonable, at least for tools (including services) where
free alternatives are available.

> AFAIK Debian uses all of these and you are probably expected to deal
> with them when contributing to relevant parts in Debian.

You may be correct. In that case, this GR, if passed, declares that we want to
change that. Is that controversial?

> >   This includes proprietary
> >   web services.  We will ensure this, insofar as it is within Debian's
> >   collective control.
> 
> Does this include use of proprietary CDN networks, DNS services, cloud
> services (such as VMs or storage) or social network services (Twitter)?
> Again, you probably cannot avoid them when contributing to relevant
> parts of the project.

Yes, it should mean that. Again, it doesn't mean people are not allowed to use
them. It means that people who don't want to use them can still contribute to
Debian. So for example, it would not be allowed to ignore the bts and only
accept bug reports through Twitter. 

> >   For example, Vcs-Git fields in source packages must not refer to
> >   proprietary git code management systems.  Non-Debian services are
> >   acceptable here so long as they are principally Free Software.
> 
> That would just lead to packages using these to no longer including the
> Vcs-* fields...  There are some valid reasons to host packages on
> services such as GitLab or GitHub such as when they are hosted there as
> part of the upstream project and/or for better cooperation with
> upstream.
> 
> I would not like to make cooperation with upstream more complicated.

I agree with that. However, I'm not sure if it would make it harder. How does
this cooperation work, where you need your packaging to be on the same host as
upstream?

I usually download their release and work on that. It really doesn't matter
where I do that. Of course I report issues upstream in their issue tracker, but
that doesn't need to be on the host where my packaging is.

On Thu, Sep 12, 2019 at 10:19:46PM +0200, Marc Haber wrote:
> Count my vote in as a firm "No". This is going the same road as the
> "editorial changes" two decades ago, the first occasion where my
> motivation in Debian was damaged.

The problem with that GR was that at the time of voting, people did not realize
what they were deciding. With this GR that won't be the case, if people like
you explain what the problem is. So I don't believe it is a similar situation.

But please, in order to avoid the problem, elaborate on what the problem with
this proposal is.

Thanks,
Bas


signature.asc
Description: PGP signature

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

[Dr. Bas Wijnen]

On Fri, Dec 01, 2017 at 06:09:12AM +0100, Adam Borowski wrote:
> On Thu, Nov 30, 2017 at 01:52:18PM +, Ian Jackson wrote:
> > Over the years, d-legal has discussed a number of packages which
> > automatically download non-free software, under some circumstances.
> > 
> > The obvious example is web browsers with extension repositories
> > containing both free and non-free software.
> > 
> > We have also recently discussed a media downloader/player which, when
> > fed a particular kind of url, will offer to automatically download a
> > proprietary binary-only protocol module to access the specified
> > proprietary web service.
> [...]
> > I would like to establish a way to prevent this.  (There are even
> > whole Debian derivatives who have as one of their primary goals,
> > preventing this.
> 
> No, those derivatives are damage.  While their hearts are in the right
> place, they cause data loss and security holes by at least making people on
> Intel and AMD machines use known-buggy microcode.

This is a different subject, though.  We had a discussion about software
supporting non-free hardware a while ago.  I'm still planning to propose a GR
for that, but have been distracted so it's taking a while.

What Ian is talking about is not "this software is non-free, but I need it
because I have hardware that won't run properly without it", but "this software
is non-free and my program from main just installs it on my computer".  Ian
didn't talk about hardware supporting software, so he didn't exclude it
explicitly, but I think we should do that.  Because with hardware you make
valid points, but they are irrelevant for pure software, such as the example of
a web browser downloading non-free add-ons.

I believe Ian's intent was to discuss the pure software problem (Ian, please
correct me if I'm wrong).  So if you want to talk about microcode and wifi
firmware, please do so in a different thread.

> Even Debian is not without fault here: for example, the ftpmasters accept
> such a blatantly non-free licence as AGPL[1] into main.

In today's digital environment, a lot of programs are moved from the user's
machine to a network service.  The purpose of the GPL is to give all downstream
users freedoms.  This can be circumvented by putting the code on a remote
server and never installing it on the user's machine, because the GPL only
talks about code that runs on the user's machine.  The AGPL fixes that problem
by requiring those hosting such programs to pass the freedoms on to their
networked users.  This is a necessary fix for a problem that didn't exist when
the GPL was originally written.

There may be some issues with the way it is written, but the fact that
networked users deserve the same rights as local users is self evident in
today's networked world.  So while you can advocate for minor modifications to
the license so that it becomes legally better, advocating against it entirely
is not reasonable IMO.

> [1]. AGPL fails FSF freedom 0: you can't reuse snippets of code from an
> AGPLed project in anything networked that has no, or cumbersome, ways to
> pass advertising statements to the user (such as, eg, an IMAP server).

The AGPL only says it must "prominently offer" an opportunity to receive the
source code.  I think it is possible to do this for example on the web site
that tells the users about the address of the server.  What "prominent" means
depends on how the service is normally used.  That's why they used such a
subjective description.

> It also fails the Dissident Test: take a blogging software with
> steganographic features, that you provide hosting for, for two classes of
> users: fellow dissidents, and public at large.  The former receive the code
> (both binaries and source), the latter do not.  Even revealing the existence
> of your changes is a serious risk for the life of you and your friends.
> Regular GPL has no such problems.

Yes, it does have these "problems" and they're the main difference between the
GPL and BSD-style licenses: the GPL requires users to have access to the source
code, so if you don't want your users to know that changes to the source were
made, you cannot let them run your code.

The AGPL closes the loophole that the GPL did not cover networked users.  But
if we take your example and run it locally (for example, make it a message
board on a multi-user machine that is used by students of a university in a
country with an oppressive regime), you have the exact same problem and with
your logic now the GPL is failing the dissident test.

I don't agree that it does.  For dissidents, just like anyone else, things are
easier without copyleft, because they are more free personally (at the cost of
the freedom of their users).  However, if they choose to host the software
without changes for the public and an extra copy with changes for fellow
dissidents, there should be no problem.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Are online services also software for Debian's rules?

[Dr. Bas Wijnen]

On Mon, Aug 14, 2017 at 08:51:06AM -0400, Holger Levsen wrote:
> you are running this on a computer with non-free software (*). Should 
> everything
> now be in contrib?

No, I explained before that I think we should be pragmatic.

> Or can we maybe rather bury this thread?

I do not see how "you run non-free software" should imply "you cannot care
about software freedom in anything, ever".

If there is disagreement about what software freedom means, I think it is
important that we know each other's positions.  We may eventually agree to
disagree, but at the moment I don't think we understand each other yet.

If you don't care, of course feel free to ignore the thread.  But please don't
tell others that they must not talk about it.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Are online services also software for Debian's rules?

[Dr. Bas Wijnen]

On Sun, Aug 13, 2017 at 05:28:29PM -0700, Russ Allbery wrote:
> Miles Fidelman  writes:
> 
> > Getting past all the obfuscatory count and counterpoint, there seem to
> > be two clear questions on the table:
> 
> > 1.  Given a piece of FOSS client software, that has no purpose other
> > than to interface with a proprietary back-end service (say a FOSS
> > twitter GUI), should that be considered "free software" for the purposes
> > of placement in main vs. contrib vs. non-free?  (Or alternatively, where
> > should it reside?)
> 
> > 2.  Given a piece of FOSS client software that interfaces to, among
> > other things, a proprietary back-end service (e.g., a multi-protocol
> > chat interface that includes AIM and MS Messenger among the back-ends it
> > supports), be placed in contrib or non-free, simply because its
> > description mentions those services?

Yes, thank you for this summary.  One correction: I don't think anyone claims
that mentioning a non-free service in the description is a problem.
Recommending it is a different story.

It was also mentioned somewhere (here or on -devel, I don't remember) that RMS
agreed that an ICQ client can still be free software, even if there is no free
server.  I agree with that.  But being free is not enough to be in main.  I'm
not saying that an ICQ client should be in non-free.  It should be in contrib
(if it is free software).  That does not conflict with RMS's view that it is
free software.

> The point that I think may not yet be clear enough is that if the answer
> to 2 is that such software should not be moved to contrib (as has
> historically always been the case), the answer to 1 *also* has to be that
> the software is not moved to contrib.

I don't agree that this automatically follows.  You make a good argument, but
it is still a policy choice to do one or the other.

> Because the way you get software of type 2 is that it uses a variety of
> libraries of type 1, so if those libraries are moved to contrib, the main
> software of type 2 would also have to be moved to contrib.
> 
> Writing a library specifically to interact with a non-free service is
> *good software engineering* (do one thing and do it well), and the correct
> way to implement software of type 2.  So unless you want to see all
> software of type 2 kicked out of Debian, at least libraries of type 1 also
> need to be allowed in Debian.

That depends on the reasoning for letting 2 be in main.  It was my impression
that it is a matter of convenience: ideally, we have a clear separation of free
and non-free software.  Software of type 2 would then need a plugin system and
the part interacting with the non-free service would be in contrib, while the
rest can be in main.  This is done by several programs, including the Linux
kernel.  Debian is often a driving force behind such splits, and I am proud of
that.

But before the non-free parts were removed from the main Linux binary, it was
software of type 2, and it was still in main.  With your logic,
linux-firmware-nonfree should now also be in main, because it was acceptable in
main when it was part of the kernel-image package.  That is obviously not
correct: the entire reason for splitting the package was to put it in non-free.

Following this logic, it seems logical to me that we can accept non-free
interfacing programs (and libraries) in main as a workaround for the bug that
the non-free part cannot be split yet.  However, it is a bug, it should be
fixed (when someone considers it important enough to work on it) and when it is
fixed, the plugin library should indeed move to non-free.

> I believe this would be hugely counter-productive for free software.  It
> would hurt us way more than it would hurt proprietary services.

I don't care about hurting proprietary services, so I'm also not interested in
knowing who is hurt more.  If it hurts us, we shouldn't do it.  But I disagree
that it does.  I think in the long run, making Debian free not only in terms of
what runs on the local cpu, but also what runs remotely, would be beneficial
for software freedom overall.  Especially because many services are moved to
the network, it means that local software is less and less relevant.  If we
ignore remote software for the purpose of our rules, we can soon as well not
have rules.

Thanks,
Bas

P.S: I just wrote a post on -devel explaining that I do not mean to say our
rules should apply to external software.  If that is not clear when reading
this post, please read that post for clarification.


signature.asc
Description: PGP signature

Re: Are online services also software for Debian's rules?

[Dr. Bas Wijnen]

On Sat, Aug 12, 2017 at 12:07:51PM +0200, Vincent Bernat wrote:
>  ❦ 12 août 2017 09:12 GMT, "Dr. Bas Wijnen" <wij...@debian.org> :
> > No, it doesn't.  2.2.1 says "None of the packages in the main archive area
> > require software outside of that area to function."  In other words, if
> > software outside of main would not exist, the program would still work.  
> > But if
> > that software wouldn't exist, the non-free service would not be available 
> > and
> > the free client would be useless.
> 
> Then, please file bugs against offending packages, severity
> serious. Otherwise, all this discussion is useless. A starting point
> could be golang-github-datadog-datadog-go and golang-google-api
> packages.

My purpose of this thread (which is a question asked elsewhere) is to find out
if there is consensus about this issue.  If there isn't, I don't want to bother
everyone with a mass bug report.  Which, as Russ pointed out, would be a pretty
large operation.

Also, I don't want to move lots of software to contrib.  I would much rather
have it fixed by removing the support for the non-free services, or by having
plugin systems that allow only the non-free-interfacing part to be in contrib.
However, that is still a large operation, so I still do not want to do a mass
bug filing unless there is consensus that it should be done.  So far, it
doesn't seem like there is consensus at all.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Are online services also software for Debian's rules?

[Dr. Bas Wijnen]

On Sat, Aug 12, 2017 at 09:55:17AM +0200, Vincent Bernat wrote:
>  ❦ 12 août 2017 07:37 GMT, "Dr. Bas Wijnen" <wij...@debian.org> :
> > Your argument seems to be:
> >
> > Debian cares about free software.
> > Therefore, Debian does not enable contrib and non-free by default.
> > Therefore, users may not see non-free related software.  This is a problem.
> > Let's fix it by pushing that software into main anyway.
> 
> No, _your_ argument is that contrib and non-free are part of Debian and
> are just a fine recipient for random software. I just emphasize the fact
> they are not part of Debian.

I agree that they are not part of Debian, but they are indeed fine as recipient
for software (free software in the case of contrib).  Debian is a
self-contained system that does not require anything outside it.  This is not
true for a client of a network service that is not packaged in main, so such a
client cannot be in main.

> My argument is that services are not software.

How do you think those services are implemented, if not as software?

> > In other words: We care about free software, therefore we should put 
> > non-free
> > (related) software in main.  What?
> 
> Strawman argument. Please, refrain from that.

If you read my message, I explained that this was what I understood your
argument to be.  Instead of accusing me of rhetorical tricks, please just point
out that I misunderstood you.

> > If you believe it is a problem that our users don't have access to the 
> > software
> > in contrib by default, then propose to fix that.  The obvious way to do that
> > would be by enabling contrib by default, not by moving software that 
> > belongs in
> > contrib into main.
> 
> Contrib cannot be enabled by default, it is not part of Debian.

So?  You just said that there is no problem whatsoever with Debian packages
using non-free services, which I hope we agree are not a part of Debian either?
Isn't contrib just a network service?

> It's an additional service using Debian infrastructure. Policy is quite clear
> about that.

Yes, and your position is that programs using additional services outside of
Debian can be in main.  So how is this a problem for you?

To be clear: I like to ship main-only by default, but I would understand if
contrib was enabled by default and I don't think it would be against the SC,
DFSG, or Policy.

> And honestly, I don't have to do a thing. Nothing will change. Free
> software using "non-free services" will stay in main because they meet
> the proper requirements (policy 2.2.1).

No, it doesn't.  2.2.1 says "None of the packages in the main archive area
require software outside of that area to function."  In other words, if
software outside of main would not exist, the program would still work.  But if
that software wouldn't exist, the non-free service would not be available and
the free client would be useless.

> >> Debian is about free software. There is nothing in DFSG about "free
> >> services". How do you know if a service is implemented with free
> >> software or not? Amazon S3 could be free software, but only distributed
> >> internally at Amazon.
> >
> > They can be, but that is irrelevant to this discussion.  There is no 
> > question
> > that the client is free software.  If the server is not packaged in main, 
> > that
> > means this free client software belongs in contrib.  Whether that is 
> > because it
> > is non-free or for some other reason does not matter.  That is, unless you 
> > are
> > claiming that their service is not "software".  Are you?
> 
> Yes, I am! They are services. Even the FSF acknowledges they are
> different. They have created the AGPL for that.

They have created the AGPL to close a loophole, namely that it was possible to
move a program into the cloud and thereby the users lost their freedoms.  The
idea of copyleft is to guarantee those freedoms to downstream recipients and
this trick made that impossible.  So the AGPL says "if you access software over
a network, you're still considered a user and need to receive all the rights".
In other words, the AGPL is created specifically _because_ they acknowledge
that a network service is also software.

On Sat, Aug 12, 2017 at 10:06:40AM +0200, Christian Seiler wrote:
> Because it's so fun, let me play devil's advocate for a bit:

Sure. :)

> On 08/12/2017 08:29 AM, Dr. Bas Wijnen wrote:
> > No.  The question is not "is there non-free software that the program can 
> > work
> > with?"  That would be much too broad, and it would make anything that 
> > touches
> > the network non-free.  Instead, the question is "is non-free software 
> > required
&

Are online services also software for Debian's rules?

[Dr. Bas Wijnen]

On Sat, Aug 12, 2017 at 08:55:01AM +0200, Vincent Bernat wrote:
>  ❦ 12 août 2017 06:29 GMT, "Dr. Bas Wijnen" <wij...@debian.org> :
> 
> > That is a disservice to our users.  While for many users this is true, those
> > users will have contrib (and probably non-free) enabled in their 
> > sources.list.
> > So moving the package to contrib doesn't change anything for them.  The only
> > people who see a difference are the ones who asked not to see this kind of
> > software, and they will no longer see it.  That is a great outcome, not
> > something to get upset about.
> 
> By default, contrib and non-free repositories are not enabled. They are
> also unsupported from the security team. They are not part of
> Debian. They are an additional service provided to users requesting it
> specifically.

Your argument seems to be:

Debian cares about free software.
Therefore, Debian does not enable contrib and non-free by default.
Therefore, users may not see non-free related software.  This is a problem.
Let's fix it by pushing that software into main anyway.

In other words: We care about free software, therefore we should put non-free
(related) software in main.  What?

If you believe it is a problem that our users don't have access to the software
in contrib by default, then propose to fix that.  The obvious way to do that
would be by enabling contrib by default, not by moving software that belongs in
contrib into main.

Another solution for those users is to install one of our many derivatives,
most of which don't care about non-free software like we do.

> Debian is about free software. There is nothing in DFSG about "free
> services". How do you know if a service is implemented with free
> software or not? Amazon S3 could be free software, but only distributed
> internally at Amazon.

They can be, but that is irrelevant to this discussion.  There is no question
that the client is free software.  If the server is not packaged in main, that
means this free client software belongs in contrib.  Whether that is because it
is non-free or for some other reason does not matter.  That is, unless you are
claiming that their service is not "software".  Are you?

Thanks,
Bas


signature.asc
Description: PGP signature

Re: [pkg-go] Bug#856139: certspotter: long description advertises commercial service

[Dr. Bas Wijnen]

First of all, a clarification: This post (like most in this thread) is
primarily about Debian's philosophy, not about certspotter (but I do talk about
that at the end as well).  For this reason, I'm not CC'ing the bug.

On Fri, Aug 11, 2017 at 05:26:58PM -0400, Faidon Liambotis wrote:
> On Fri, Aug 11, 2017 at 08:03:09AM -0400, Wouter Verhelst wrote:
> > If a free software implementation of the remote service exists that a
> > package can work with, then it can remain in main. If not, it cannot.
> 
> There are no free software server-side implementation of e.g. the ICQ
> protocol, as far as I know, but multiple client-side implementations in
> main.

That is a bug as far as I'm concerned; a client designed purely (or mostly) for
such a non-free service should not be in main.

> For that matter, there is no free software server-side implementation of
> QUIC, so I guess by that rule, Chromium should be in contrib as well.

No.  The question is not "is there non-free software that the program can work
with?"  That would be much too broad, and it would make anything that touches
the network non-free.  Instead, the question is "is non-free software required
for major functionality of the program?"  With an ICQ client, it is.  With a
web browser, it's not.

Also note that the reason we split our free packages between main and contrib
is a service to our users: those who do not want to depend on non-free software
can disable contrib.  Not showing an ICQ client to those users is a service to
them, not a burden: it's what they ask for when putting only main in their
sources.list.

Now if an upstream or a maintainer gets upset about software being moved from
main to contrib, that is a sign that they (like Debian) would prefer to live in
a world where all software is free.  Because of that, they don't want to
support non-free software, which means (if all dependencies are packaged) that
their software should be in main.  So when people tell them "your software
belongs in contrib", especially if the reason is that it requires non-free
software (as opposed to non-packaged software), it hurts their pride.

I think that is a good thing: it should be an incentive for them to get rid of
the dependency.  However, I've seen on multiple occasions that the response is
to deny the problem and to push for keeping the software in main anyway,
claiming something to the effect of "it's more important for our users that
they have access to this software than it is to have a completely free system".

That is a disservice to our users.  While for many users this is true, those
users will have contrib (and probably non-free) enabled in their sources.list.
So moving the package to contrib doesn't change anything for them.  The only
people who see a difference are the ones who asked not to see this kind of
software, and they will no longer see it.  That is a great outcome, not
something to get upset about.

> As for certspotter [...]

It has become clear a while ago (to me anyway) that certspotter belongs in
main.  From the start, the bug report was about the description, not about the
program itself and thus the fix would be to change that, not to move the
package to contrib.  I agree with the bug that descriptions of Debian packages
(even those in non-free) should not advertise non-free software or services.
If there is a free option (and there must be for it to be in main) that should
be mentioned as the recommended way to use the program.  If there also is a
non-free option, it can be mentioned as an alternative, especially if many
users are expected to know about it.  If it is unknown to most users, I think
it should be left out.

> the conversation has derailed quite a bit [...] Not cool.

Actually, that is "cool".  Jonas made the larger community aware of the issue,
which means we can discuss it.  On our mailing lists, the tangents this went to
are not off-topic.  Perhaps the bug should be removed from the Cc, but that's a
minor issue.

> - People called SSLMate "non-free" and objected to the certspotter
> description pointing to it.

No, pointing does not need to be a problem.  Recommending it (in effect
advertising for it) is.

> - I don't have any personal or business connection to SSLMate or
>   certspotter, other than using the software and maintaining the
>   package. I haven't communicated with my upstream about this issue
>   either and my comment on the bug report are just my views. I just want
>   to be fair to a nice upstream, who has graciously released part of
>   their business as free (as in speech and as in beer) software, for
>   anyone to use instead of using their service.

I agree that it is unfortunate that people get so upset over discussions like
this one, and I appreciate that you keep it away from upstream, so they are not
bothered with it; this has nothing to do with them.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Bug#856139: certspotter: long description advertises commercial service

[Dr. Bas Wijnen]

On Tue, Aug 08, 2017 at 07:58:06AM -0700, Don Armstrong wrote:
> On Mon, 07 Aug 2017, Dr. Bas Wijnen wrote:
> > Ah, that's good then! Still, I think its description has the same
> > problem as certspotter, namely that it recommends the use of a
> > non-free service. In Debian, I would prefer to see a recommendation
> > for the free alternative, while the non-free alternative may be
> > mentioned (or not, depending on what users need).
> 
> An important counterpoint is that the long description helps with the
> discoverability of a package. Mentioning a famous non-free service helps
> users discover the package and also notice that there are free
> alternatives.

Yes, I agree.  If the non-free service is famous, I think it makes sense to
mention it.  However, even in that case I think we should still recommend the
free option(s).

If the free options are limited to a point where it does not make sense to
recommend them to our users, that means the non-free service should be
recommended and IMO that means the program should be in contrib.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Bug#856139: certspotter: long description advertises commercial service

[Dr. Bas Wijnen]

On Tue, Aug 08, 2017 at 02:25:51AM +0800, Shengjing Zhu wrote:
> The description of s3cmd is outdated. It's *not* useless without AWS.
> It can be used with self-hosted S3 protocol compatible service, such
> as Ceph RGW, minio[1]. Both are free softwares, and Ceph is in our
> main archive.

Ah, that's good then!  Still, I think its description has the same problem as
certspotter, namely that it recommends the use of a non-free service.  In
Debian, I would prefer to see a recommendation for the free alternative, while
the non-free alternative may be mentioned (or not, depending on what users
need).

Thanks,
Bas


signature.asc
Description: PGP signature

Re: [pkg-go] Bug#856139: certspotter: long description advertises commercial service

[Dr. Bas Wijnen]

On Sun, Aug 06, 2017 at 02:15:17PM +0200, Vincent Bernat wrote:
>  ❦  4 août 2017 20:03 +0200, Jonas Smedegaard  :
> > No, at worst this is misuse of Debian ressources for commercial gain - 
> > i.e. using long description field for advertising a non-free service.
> 
> We have all kind of software advertising non-free services. Search for
> "Google" or "Amazon". The comparison is even unfair as the service
> advertised here is available as free software (not the case for most
> services from Amazon and Google we advertise).

If other packages are worse, that means they should be fixed, not that this
should be allowed.

> Example: [s3cmd]

How is this not in contrib?  This software is useless without the non-free
service (which is also software, and it is not in main) from Amazon.  Policy
even mentions as an example for things in contrib: wrapper packages or other
sorts of free accessories for non-free programs.  That's exactly what this is.

I didn't know that this was in main, and I expect most others to not know
either.  But I don't think they should be.  I wouldn't expect this to be
controversial, but it seems that it is, given that you suggest they obviously
belong in main?

To be clear: the sort of software (of this type) I expect in main is like
mumble: it connects to a server, and you can connect to a commercially hosted
server if you want to, but you can also run your own server, because it's free
software.  If the mumble server would not be free, and the only way to use the
client was to connect to a commercial server, mumble should not be in main.

As I wrote, I expected there to be consensus on this.  Am I incorrect about
that?

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Bug#856139: certspotter: long description advertises commercial service

[Dr. Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Sat, Aug 05, 2017 at 09:38:45AM -0400, Paul Wise wrote:
> > No, at worst this is misuse of Debian resources for commercial gain -
> > i.e. using long description field for advertising a non-free service.
> 
> I got the impression that Faidon is not involved with SSLMate so this
> and the relevant DMUP clause does not seem to apply in this case.

While perhaps not strictly against the letter of any of our rules, that doesn't
make it any less an advertisement for a non-free service and that certainly is
against the spirit.  Similarly to not adding a Recommends: from a package in
main to one in non-free, we should not recommend non-free services either IMO.
I don't think that is controversial?

I would make an exception for source files from upstream.  If they want to
advertise a non-free service, they can do that.  For Debian, IMO we should
remove such advertisements as part of packaging the software.  That means it
should not be in the binary package at all.

> In this case, the advertisement is also present on the upstream github
> page, via the README, which is also in the Debian package, so removing
> it from the Debian package description will not remove the
> advertisement entirely. Personally I'd prefer to not have it present
> in any of the locations, but leaving it in the README in Debian and
> upstream seems like a reasonable compromise.

Agreed; I would remove it from the program itself or its upstream-written
manpage if it would have been there (and of course it should definitely not be
in a manpage created by a maintainer), and while removing it from the source
(or its documentation) would be nice, I think it's acceptable to leave it
there.

Then again, it's similar to having non-free software in a release tarball, and
we do repackage the source for that.  So perhaps that would be the preferred
way to handle it.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJZhr4gAAoJEJzRfVgHwHE6jTwQAJGgJL0vKRlcGj70YhjoDDrR
/pQiDALVRq0wiQqx+9MNy0px2OeA89TgTtfvm6fh+ibSI+9cC/+FO8GruqGPrxjK
NKgyUVUvVNqvSupIzEpbnLQE1QVzi31dvYVzir+lLjJB8sN4oUbNOtTjUWlO4rhT
XH8ixzLADqT3VWC30TPUoE8UJ+Nf82eHF67h/4sEwrZWMZgfVfqPR3qTAF0AZsnS
ezOtkHl8a3E/QlxOGeMZJ/g2zLVlcRnXU7svEAWdhuSZUT7D9t9I3m5KGwwE1ZLj
Kzmlly59DdhyWkqsvWdpifo97avQXlIna4MJeGZW9U8JRdw0V0taWxv1oZ1auprA
Cm3hWi/X8DTtvUwOVqEW4aarvvC26dk1uyIz7Z+qHqKF5amir7HxfG81cGNiryyz
bBjp6MJAYnnfUeYnn1ZM4qlnJFPNqYSUgoZ/S0uLtOwZGTjaBQsqwewPWKr5pON9
hlG+at1u6wcxTfYJ3guzhB04bp4cISL5Ze3WZwXH3nmTPJi5Rnd7dXaQvkwdzziJ
DVcGjZqb3G1LQKABpWmwCxGEXiEgfjki/DmlSDaonX0SUN1lvtfsQ9COcp7kczU1
gb+jcJCR3uerLHvNnmKT8RowQe7j4AHpFGDJuPKid1B+fdYqpNO8/yqE7kScpI97
82ed9JaRCIbFYfXoL+YT
=YnvG
-END PGP SIGNATURE-

Re: Debian contributor Register of Interests

[Dr. Bas Wijnen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, May 09, 2017 at 11:51:23PM +, Scott Kitterman wrote:
> On May 9, 2017 8:09:28 AM EDT, Ian Jackson  
> wrote:
> >Jonathan Dowland   wrote:
> >> However in the interests of transparency I feel that a voluntary,
> >> opt-in "Register of Interests" is a good idea for the project. I feel
> >> that such a list (populated) would demonstrate the transparency and
> >> openness that are part of our project's values.
> >
> >I think this is a good idea.
> 
> I think it's a horrible idea.  One of the major draws of Debian is that we
> are all here for our own reasons.  I don't judge your motivations and you
> don't judge nine.

It's voluntary, so you decide what you want to share.  If you don't want to
share anything, that's fine.

> If this became a requirement, I'd have to terminate my relationship with
> Debian.  These are frankly none of anyone's business.  

Nobody is suggesting that it would be a requirement.  But I disagree that we're
not allowed to know your motivations.  The NM process spends considerable time
to check that applicants agree with the project's philosophy.  If they do, we
can conclude that this will motivate them to work on Debian.  While also having
other motives is perfectly fine, we require people to have at least those
motives before we let them join the project.

> I've packaged software because a project I was being paid to work on needed
> it and I was able to convince them it made sense to put it in the Debian
> archive.

That's great, and as far as I'm concerned, just disclosing that you have been
paid for certain packages would be nice (but again, not doing it is also fine).
Whether or not it's relevant to mention who's paying is up to you.  I can
imagine that some companies would like to be mentioned, because they can use
that to show they are favorable to free software.  But if they don't wan't to
be mentioned, then don't mention them.

> If there were a case where I had an actual conflict of interest (e.g.
> recommending Debian spend funds with an organization that I had a financial
> interest in), that should be disclosed.  That's oddly missing from the list.

That's a good point, and while I agree it should be on the list, I don't think
it will have the effect you expect: this list is voluntary and therefore
incomplete.  People who intentionally misbehave aren't going to declare their
conflict of interest.  They wouldn't do that if they had to, either.

Finally, I'm not sure how useful this list would be, but I don't see a problem
in setting it up.  If someone makes good use of it, great.  If not, nothing is
lost.

Thanks,
Bas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJZEu4bAAoJEJzRfVgHwHE6bZAP/jm7P7v9kEazuuiQaUKnpMFc
yLW0Es6IalXmQVNJ/AHe4rwDMuC28CppECEejJVt4SiHkUclYMt++QzUWHLmNrCf
WraVuUGh27SMpnlacC0AxyDLXTtTGHHeA/0dwS/C4UHynRwTyVgIjuwwapwbofGi
IJqcUQlnAiVO7mzCLSZUTyEwxtY6kRjBx8QJ/0vd8lZ9+uh4nPtmq4+m3P0kziTb
A6vrTnJwUjLWbPhBsEbVtnTDcCK+fNcnNMjbXJYWIo8a13pJvZu6krtXGgoWLxmE
zImwySagYZC1XIxis1AV6exLYWCmHdJYvbvaBFk7Y2UielPntOV3ps+AflZmAoXX
Cy2+gAJAR8X5bzEqluHwvqA5V2YSMeDv6BKYBtUdoq3BSc7NcmfdTGXMCIkwrGPC
ylvlhMck015f/TW6BeqZOVeyV02/0zZRPLAZUAbB2dhV1c8CyctVnRCrZcPPQx1s
5F9eqlHqFQgLoVL/grLFYUYWnGbixQ4++Vy79ENV1GngvA7h9XJ5wNnI3owUgBYA
BuEJSljBj6YudqIrzO4QPwuMlsv2BaiI2c7U9WcvmbJnfbS2iMwHcfhPRbuI+DF4
xqb7cuvulHUZxrc2HCqktdg7GSfqFTaCPVDYZAvwakvvXThA9lUFYdjHDo/HaQX8
9Bo8P6pq3YEs6vqtABvC
=Fmz0
-END PGP SIGNATURE-