Re: Whether remotely running software is considered "software" for Debian.

[Tollef Fog Heen]

]] "Dr. Bas Wijnen" 

> On Thu, Aug 31, 2017 at 11:16:36AM +0200, Ansgar Burchardt wrote:
> > python-digitalocean, ruby-azure*, waagent, twittering-mode,
> > probably HBCI clients, python3-googleapi,
> > python3-pyicloud, python-yowsup, youtube-dl,
> > libgfbgraph-0.2-dev
> 
> Thank you for this list.  I removed servers that cannot run on a general
> purpose system, because for obvious reasons they cannot be included in main
> even if they were free software.

Then you shouldn't remove usbmuxd for instance.  iOS devices are general
purpose computing devices, they just run another OS, and there's nothing
stopping somebody from implementing the same interfaces using free
software and, say, the Linux USB APIs.

I'm not sure what OS modern HP printers run, but I would also not be
surprised if they run a pretty straightforward Linux.  Somebody could
implement the APIs and produce, say, PDFs, or print using a hand-built
printer.  For the first case, you could easily run that on a general
purpose system.

You say that the requirement for an implementation to be useful is
orthogonal to whether it's suitable for main.  Does that also hold with
s/useful/functional/?

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

On Thu, Aug 31, 2017 at 11:16:36AM +0200, Ansgar Burchardt wrote:
> python-digitalocean, ruby-azure*, waagent, twittering-mode,
> probably HBCI clients, python3-googleapi,
> python3-pyicloud, python-yowsup, youtube-dl,
> libgfbgraph-0.2-dev

Thank you for this list.  I removed servers that cannot run on a general
purpose system, because for obvious reasons they cannot be included in main
even if they were free software.  For the others, so far there have been people
popping up with "a free server for this exists" for every example we came up
with, so I'll wait to see if that happens for those as well.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Andrey Rahmatullin]

On Mon, Aug 28, 2017 at 09:15:01AM -0400, The Wanderer wrote:
> Adding a 'firmware' repository (and even enabling it by default), while
> it would similarly both improve that out-of-the-box experience and make
> the free-software bubble easier to achieve for those who want it, would
> not remove the "accessibility to end users" barrier which provides
> incentive for maintainers to want their packages to be in main.
> 
> Perhaps adding that 'firmware' repository and enabling both it and
> contrib by default, while keeping non-free disabled by default, would be
> the most optimal solution? Although that would seem to imply a change in
> what is considered "part of Debian", which might be controversial.
This will be require a GR. Several GRs, I suppose.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Ansgar Burchardt]

"Dr. Bas Wijnen"  writes:
> Actually, that isn't so clear at all.  At least when it comes to current
> practice, I have yet to find any client for which nobody wrote a free server.
> People keep implying that we have many such clients currently in main, but I
> don't think we do.  So there is no clear current practice that can be used as
> an argument.

hplip ("server" runs on printers / multi function devices),
python-digitalocean, ruby-azure*, waagent, twittering-mode, smart cards
("server" runs on card), probably HBCI clients, python3-googleapi,
usbmuxd, python3-pyicloud, python-yowsup, youtube-dl,
libgfbgraph-0.2-dev, other proprietary web APIs, drivers for SATA disks
("server" runs on SDD/HDD), ...

Ansgar

Re: Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

On Mon, Aug 28, 2017 at 09:15:01AM -0400, The Wanderer wrote:
> On 2017-08-28 at 07:59, Dr. Bas Wijnen wrote:
> > I think if someone wants to write a client with the purpose of
> > interacting with a non-free service, that client should go in contrib
> > and there is nothing wrong with that.  I find the obsession that some
> > people seem to have with getting their software in main startling.
> > Why should software be in main if its purpose is to work with
> > non-free software?  That's exactly what we have contrib for.
> 
> One plausible rationale for this is accessibility to end users, and that
> goes back exactly to your other point about what repository
> configuration should be the default.

Agreed.  Now as far as I know, in Debian we try not to use dirty workarounds,
but fix bugs when we find them.  In this case, the bug is that many users need
software from contrib or non-free (especially now that we have properly put
lots of firmware in there), but it's rather hard to get to it.  Should
maintainers work around that problem by putting packages in main even if they
don't belong there?  Or should we fix the actual problem and make contrib and
non-free more easily accessible?

As long as almost essential firmware is in there, I think they should be
enabled by default.  And once that issue is fixed (by creating a separate
firmware section, for example), I think we should still make it easy to enable
them, both at install time (there should be a question about enabling them in
the installer; I thought there was, but it's been a while since I ran the
installer) and on an installed system (I know Ubuntu has a graphical tool that
allows enabling and disabling sections; doesn't that tool work for us?)

In short: the fact that quite a few maintainers are trying to push their
contrib packages into main should be fixed by making it easier for users to
install packages from contrib.  I am surprised that this is so controversial.

> There's also the fact that it's repeatedly stated that anything not in
> main is not part of Debian; it's easy to see why a maintainer would want
> to have a package in Debian, rather than having it be a second-class
> citizen.

But that's the way it should be.  Debian is a self-contained free software
operating system.  If you install things from main, it will not tell you that
you need stuff that isn't in main in order to use those things.  If you find a
problem with your software, you know that you can get the source code from our
repositories and fix the problem.

If a client requires communication to a non-packaged server, then the bug you
are seeing could be on that server and you cannot get the source for it from
Debian.  That is an experience we tell our users they will not have.

Again, it surprises me that the same people who don't seem to care all that
much about freedom and happily make their package depend on a non-free server,
have such strong opinions on which section of Debian their software should be
in.  The fact that contrib and non-free are not a part of Debian is because we
care about software freedom.  How can you say "this software really needs to be
in main, not contrib", but at the same time say "I'm indifferent to whether or
not the software depends on non-free stuff"?  That like saying "I don't care
what text editor you provide me with, but I hate you if it isn't gedit".  How
is it not obvious to everyone that this is a contradiction?  Obviously those
people care a lot about what section their software is placed in, but they
don't want to follow the rules that come with the section placement.

We should explain to those people that if they want to be part of the
self-contained free system that Debian is, they must follow the rules that we
made for it.  If they think those rules are stupid, then they should ignore the
sections and accept when we sort their package into contrib or non-free.

> Perhaps adding that 'firmware' repository and enabling both it and
> contrib by default, while keeping non-free disabled by default, would be
> the most optimal solution? Although that would seem to imply a change in
> what is considered "part of Debian", which might be controversial.

I think we should do that (and until there is a firmware repository, also
non-free) and I don't think it's a problem.  Having a link to a network service
in our system does not make the target of that link part of the system.
Everyone who claims that requiring a non-free and/or non-packaged server is
acceptable for a package in main should certainly agree with that.  Just having
contrib and/or non-free enabled doesn't mean we are requiring them, so that
isn't a problem either.  And if even people like me agree with that, I think it
is to be expected that there is consensus about it.

On Mon, Aug 28, 2017 at 10:18:02PM +0200, Tollef Fog Heen wrote:
> The value of an ICQ server with a singular user is pretty low.  The
> value there lies not in the software itself, but the network effects 

Re: Whether remotely running software is considered "software" for Debian.

[Ben Finney]

Andrey Rahmatullin  writes:

> On Wed, Aug 30, 2017 at 01:51:16AM -0400, Anthony DeRobertis wrote:
> > Policy is not the Social Contract, Policy is not the Constitution.
> > Policy can be relatively easily changed and is supposed to largely
> > document actual practices. So really, Policy needs to be amended.
> > And attempting to language-lawyer Policy like this is pointless.
> I don't it *needs* to be amended as there is no data that the current
> policy language cause problems.

Yes, I'm in agreement that the Policy wording has not been demonstrated
to cause the alleged problems.

I'm also in agreement with Anthony that, *if* the Policy wording is in
conflict with agreed consensus practice, in that hypothetical scenario
that would mean it is Policy that need to change.

-- 
 \  “A thing moderately good is not so good as it ought to be. |
  `\Moderation in temper is always a virtue; but moderation in |
_o__)   principle is always a vice.” —Thomas Paine |
Ben Finney

Re: Whether remotely running software is considered "software" for Debian.

[Andrey Rahmatullin]

On Wed, Aug 30, 2017 at 01:51:16AM -0400, Anthony DeRobertis wrote:
> > Actually, I haven't seen anyone citing the following part of policy
> > 2.2.1: "None of the packages in the main archive area require software
> > outside of that area to function."
> > 
> > If we agree that "functioning software" does more than print an error or
> > a usage note, this part makes it rather clear where free client software
> > to non-free server software belongs.
> 
> It also would apply to anything where the server isn't packaged (in
> main)—whether or not a free server exists.. 
Yup.

> The plain wording of Policy requires that the server (if it's required
> for the client to operate) not only be free, but also be packaged in
> main.
Or, instead, the way some people read it requires that.

> That clearly doesn't match historical or current practice.
Yup.

> Policy is not the Social Contract, Policy is not the Constitution. Policy
> can be relatively easily changed and is supposed to largely document actual
> practices. So really, Policy needs to be amended. And attempting to
> language-lawyer Policy like this is pointless.
I don't it *needs* to be amended as there is no data that the current
policy language cause problems.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Paul Wise]

On Mon, Aug 28, 2017 at 7:59 PM, Dr. Bas Wijnen wrote:
> On Mon, Aug 28, 2017 at 12:31:15PM +0200, Philipp Kern wrote:
>> I think the sanity check that fails today is a) free implementations of
>> the RAR algorithm exist so this is unnecessary
>
> I'm not familiar with the details, but I know some rar files cannot be
> extracted with unrar-free.  So I'm pretty sure unrar-nonfree contains things
> that are not free and are required for some features.

You might not be aware that there exists free code to convert newer
RAR archives to a directory tree. That code is within the upstream
software known as "The Unarchiver". The command-line version of this
is known as "unar" and is packaged in Debian main. AFAIK there is no
free tool to produce RARv3 archives from a directory tree though.

https://theunarchiver.com/command-line
https://packages.debian.org/search?keywords=unar
https://en.wikipedia.org/wiki/RAR_(file_format)

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Whether remotely running software is considered "software" for Debian.

[Ben Finney]

Anthony DeRobertis  writes:

> Policy is not the Social Contract, Policy is not the Constitution.
> Policy can be relatively easily changed and is supposed to largely
> document actual practices. So really, Policy needs to be amended. And
> attempting to language-lawyer Policy like this is pointless.

Thank you, that's all well put.

-- 
 \   “I love and treasure individuals as I meet them, I loathe and |
  `\ despise the groups they identify with and belong to.” —George |
_o__) Carlin, 2007 |
Ben Finney

Re: Whether remotely running software is considered "software" for Debian.

[Anthony DeRobertis]

On 08/29/2017 03:25 AM, Carsten Leonhardt wrote:

Actually, I haven't seen anyone citing the following part of policy
2.2.1: "None of the packages in the main archive area require software
outside of that area to function."

If we agree that "functioning software" does more than print an error or
a usage note, this part makes it rather clear where free client software
to non-free server software belongs.


It also would apply to anything where the server isn't packaged (in 
main)—whether or not a free server exists.. The plain wording of Policy 
requires that the server (if it's required for the client to operate) 
not only be free, but also be packaged in main.


That clearly doesn't match historical or current practice.

Policy is not the Social Contract, Policy is not the Constitution. 
Policy can be relatively easily changed and is supposed to largely 
document actual practices. So really, Policy needs to be amended. And 
attempting to language-lawyer Policy like this is pointless.

Re: Whether remotely running software is considered "software" for Debian.

[Andrey Rahmatullin]

On Tue, Aug 29, 2017 at 11:03:36AM +0200, Nikolaus Rath wrote:
> > My position is that it should acceptable for a program in main to require
> > a non-free service, or data, or whatever, as long as that program itself
> > is free and running it doesn't compromise the freedom of the user.
> > contrib should be for wrappers, downloaders etc. The policy uses the word
> > "supplemental".
> 
> If this is your position, then your position on the unrar scenario
> should logically be that putting the non-free components on a server
> somewhere is sufficient to allow unrar into main. If not, please
> explain.
Putting the non-free components on a server somewhere is so stupid I don't
even want to think about that.

> >> Finally, for the third time, please explain your position on my 
> >> hypothetical
> >> unrar-nonfree scenario.
> >
> > I don't have a position in that scenario because I don't intend to dig it
> > and examine it.
> 
> There is no need to dig and examine. Bas has provided all the context
> that is necessary.
Not really.

> > I don't know why are you counting times unless you view this
> > discussion as a battle between you and the world.
> 
> I probably share your point of view rather than Bas', but the way you
> represent it is a disservice. It makes you look silly and for some
> reason unwilling to address Bas core argument.
Sure, but the whole discussion is pointless and won't result in anything.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Nikolaus Rath]

On Aug 28 2017, Andrey Rahmatullin  wrote:
> My position is that it should acceptable for a program in main to require
> a non-free service, or data, or whatever, as long as that program itself
> is free and running it doesn't compromise the freedom of the user.
> contrib should be for wrappers, downloaders etc. The policy uses the word
> "supplemental".

If this is your position, then your position on the unrar scenario
should logically be that putting the non-free components on a server
somewhere is sufficient to allow unrar into main. If not, please
explain.

>> Finally, for the third time, please explain your position on my hypothetical
>> unrar-nonfree scenario.
>
> I don't have a position in that scenario because I don't intend to dig it
> and examine it.

There is no need to dig and examine. Bas has provided all the context
that is necessary.

> I don't know why are you counting times unless you view this
> discussion as a battle between you and the world.

I probably share your point of view rather than Bas', but the way you
represent it is a disservice. It makes you look silly and for some
reason unwilling to address Bas core argument.

Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Whether remotely running software is considered "software" for Debian.

[Ben Finney]

Carsten Leonhardt  writes:

> Actually, I haven't seen anyone citing the following part of policy
> 2.2.1: "None of the packages in the main archive area require software
> outside of that area to function."

Yes, that's been raised. I've responded to that at
.

-- 
 \  “Software patents provide one more means of controlling access |
  `\  to information. They are the tool of choice for the internet |
_o__) highwayman.” —Anthony Taylor |
Ben Finney

Re: Whether remotely running software is considered "software" for Debian.

[Carsten Leonhardt]

Bernd Zeimetz  writes:

> On 08/12/2017 07:35 PM, Marco d'Itri wrote:
>> On Aug 12, "Dr. Bas Wijnen"  wrote:
>> 
>>> Which would be a great example of software that is free interacting with
>>> software that is non-free.  Thus the package with this as its main purpose
>>> should live in contrib.  There's nothing wrong with that.
>> There is no such requirement for Debian packages and there has never 
>> been one.
>> This was settled about 15 years ago, discussing ICQ clients.
>> Even RMS agreed.
>
> Also nobody will stop you from writing your own server for a protocol
> which is implemented by a client. Also nobody stops you from changing
> the client code to work with a different/similar kind of server you've
> implemented.
>
> So it is free software, please move on.

Mind you, all the software contained in main and contrib's packages is
free software. The question is into which of main and contrib the
software under discussion should go.

Actually, I haven't seen anyone citing the following part of policy
2.2.1: "None of the packages in the main archive area require software
outside of that area to function."

If we agree that "functioning software" does more than print an error or
a usage note, this part makes it rather clear where free client software
to non-free server software belongs.

In another message Tollef writes about a software's or service's
usefulness. That's orthogonal to classification into main, contrib and
non-free.

Re: Whether remotely running software is considered "software" for Debian.

[Bernd Zeimetz]

On 08/12/2017 07:35 PM, Marco d'Itri wrote:
> On Aug 12, "Dr. Bas Wijnen"  wrote:
> 
>> Which would be a great example of software that is free interacting with
>> software that is non-free.  Thus the package with this as its main purpose
>> should live in contrib.  There's nothing wrong with that.
> There is no such requirement for Debian packages and there has never 
> been one.
> This was settled about 15 years ago, discussing ICQ clients.
> Even RMS agreed.


Also nobody will stop you from writing your own server for a protocol
which is implemented by a client. Also nobody stops you from changing
the client code to work with a different/similar kind of server you've
implemented.

So it is free software, please move on.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



signature.asc
Description: OpenPGP digital signature

Re: Whether remotely running software is considered "software" for Debian.

[Tollef Fog Heen]

]] "Dr. Bas Wijnen" 

> But it's running on a different server.  How is the "unrar-server" different
> from an icq server?  The unrar-client would be free software.

The value of an ICQ server with a singular user is pretty low.  The
value there lies not in the software itself, but the network effects and
the people you can talk to.

Likewise, a lot of the value in using various cloud services is not in
the software implementations. It's in how they are run, that there's
«always» capacity available and so on.

I think this is important, because those are attributes that can't be
packaged.  Having the source (and redistribution rights) to some cloud
provider's software would not really put us that much closer to having
what they offer and make them attractive.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

Re: Whether remotely running software is considered "software" for Debian.

[The Wanderer]

On 2017-08-28 at 07:59, Dr. Bas Wijnen wrote:

> On Mon, Aug 28, 2017 at 12:31:15PM +0200, Philipp Kern wrote:

>> The existence of that API in the form of the client is a
>> documentation that should be sufficient to reproduce a server that
>> can communicate with the client. Do we expect that someone does
>> that work before a client implementation for a protocol can land?
> 
> I think if someone wants to write a client with the purpose of
> interacting with a non-free service, that client should go in contrib
> and there is nothing wrong with that.  I find the obsession that some
> people seem to have with getting their software in main startling.
> Why should software be in main if its purpose is to work with
> non-free software?  That's exactly what we have contrib for.

One plausible rationale for this is accessibility to end users, and that
goes back exactly to your other point about what repository
configuration should be the default.

As things currently stand, with main enabled by default but contrib and
non-free not, the directions for a user to get a package from main
installed consist of one trivial step:

apt-get install [packagename]

However, for the same user to get a package from contrib installed, the
directions consist of three steps, of which one is - while still easy
and straightforward - less trivial, in that it does not consist of a
single easily-memorable command:

[add contrib to sources.list]
apt-get update
apt-get install [packagename]

Minor though it may be in the grand scheme of things, this added barrier
- which is in place intentionally, if I'm not mistaken, as part of
enabling that same free-software bubble you cited in an earlier mail -
is enough to provide an incentive for preferring a package to be in main.

There's also the fact that it's repeatedly stated that anything not in
main is not part of Debian; it's easy to see why a maintainer would want
to have a package in Debian, rather than having it be a second-class
citizen.

Switching the default repository configuration so that contrib and
non-free are enabled, while also becoming more rigid and rigorous about
the requirements for what can be in main, would simultaneously improve
the out-of-the-box experience for many users and make it more practical
for those (such as yourself, and in some circumstances myself) who want
that free-software bubble to get it.

Adding a 'firmware' repository (and even enabling it by default), while
it would similarly both improve that out-of-the-box experience and make
the free-software bubble easier to achieve for those who want it, would
not remove the "accessibility to end users" barrier which provides
incentive for maintainers to want their packages to be in main.

Perhaps adding that 'firmware' repository and enabling both it and
contrib by default, while keeping non-free disabled by default, would be
the most optimal solution? Although that would seem to imply a change in
what is considered "part of Debian", which might be controversial.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

Thanks Philipp, unlike the mail I responded to a few minutes ago, yours is
constructive and I'm happy to continue discussing this with you.

On Mon, Aug 28, 2017 at 12:31:15PM +0200, Philipp Kern wrote:
> On 08/27/2017 12:20 PM, Dr. Bas Wijnen wrote:
> > On Sat, Aug 19, 2017 at 06:21:23PM +0200, Philipp Kern wrote:
> >> On 08/18/2017 10:36 AM, Dr. Bas Wijnen wrote:
> >>> Consider the following: unrar-nonfree contains some software which is 
> >>> non-free
> >>> and can therefore not be in main.  The reason we don't put it in main is 
> >>> that
> >>> we want users who care about freedom to not even see this software.  
> >>> Agreed?
> >>
> >> Ex falso quodlibet?
> >>
> >> Archive areas serve a purpose of grouping and indeed everything that is
> >> not main is not part of the distribution. But I don't think the purpose
> >> of the separate areas is to hide anything.
> > 
> > Let me put it differently then: for me, one of the major benefits of Debian
> > over (most of) our derivatives is that I can set the system up in a way that
> > allows me to live in a free software bubble.  Is there a non-free 
> > alternative
> > to my free program?  I don't care, and I'm happy that it doesn't show up in 
> > my
> > package list.  Is there a program that is only useful in conjunction with a
> > non-free program?  Same thing.
> > 
> > So I'm not talking about hiding in the sense of "let's make sure people will
> > not find this", but instead in the sense of "let's allow people to not be
> > bothered by those packages".
> 
> I don't think I'm sufficiently convinced of this singular use case. We
> provide one selection of what's free and it's very hard to generalize
> that over many - as opinionated - people. People apply different
> standards on what they consider acceptable. You might take the view that
> what's the status quo in main is acceptable to you and hence that's what
> you want to see. But as it stands, that's not the case.

Of course.  But the point of splitting the packages into those categories is to
allow users to handle them differently.  Keeping non-free related software off
your system is one way to handle them, and it is in fact what we recommend by
making that the default.  Obviously if users disagree with how we sort them
this has no value to them and they should enable everything so they can make
their own choices.  But for those that do agree, we should make it useful.  If
the only sensible way to write a sources.list file is by enabling contrib and
non-free, that should be the default.

I would prefer to solve this by making a "firmware" repository (or similar) so
we can enable that without throwing all the optional non-free stuff in with it.
But as long as that's not done, the situation of "you really need contrib and
non-free, but we disable them by default" seems unacceptable to me.

> The policy expresses that it's about package dependencies.

I disagree.  It gives those as examples, but it does not specify that it is
only about those.  Perhaps they meant it to be only this, but that's not what
is written.  And I think if they meant it that way, it's because they didn't
think about the cloud and they would have wanted it to include network
services.  So if you stick to the letter of the text, it says it shall not
require non-free software and doesn't make an exception for remote non-free
software.  And if you want to go with the spirit, I find it hard to believe
that they meant "unless it's running in the cloud".

> I understand that you - again - don't want to read the letter of the various
> policies, but the spirit. But it does allow client implementations of things
> that interact with non-free services and devices since the beginning, because
> that's what we had to do with to get a usable system.

Yes, and I agree it's good to be pragmatic about such things, which means that
sometimes we should allow them (although contrib is meant for that kind of
thing).

> As Andrey points out the way free software purists went was that a ROM
> with code is fine as long as you don't update that and as long as it's
> essentially initializing the hardware before the main OS starts. I -
> personally - view this as a silly stance, but then to everybody their
> own opinion as long as they don't force theirs over others without a
> vote/say in things.

Agreed.  My position is that we want everything to be free, including firmware
and hardware, but as long as the world around us isn't ready for that, we
shouldn't make our system unusable just to further that goal (also, I don't
think it really helps the goal if it means crippling our system so severely).

> >> I think such a package would fail other sanity checks (the existence of
> >> a free implementation of the algorithm being one of them - there's no
> >> right to be included in the distribution).
> > I'm glad you agree that it fails sanity checks.  However, can you find a 
> > rule
> > that actually forbids it?  If a maintainer were to do this, how 

Re: Whether remotely running software is considered "software" for Debian.

[Andrey Rahmatullin]

On Mon, Aug 28, 2017 at 10:46:16AM +, Dr. Bas Wijnen wrote:
> > > > > Are you saying that a Debian system where only main is enabled is 
> > > > > unsafe?
> > > > [...]
> > > > > If that is correct, it is a huge problem that that is the default 
> > > > > setup
> > > > > we ship, don't you think?
> > > > It is, but solving it most likely means actually violating Debian
> > > > principles,
> > > 
> > > You cannot be serious...  You believe that if our rules say we should 
> > > harm our
> > > users, the rules are more important than the users?  
> > No, I believe our users are more important and so you shouldn't set
> > arbitrary restrictions on main just so your apt search output could be
> > untainted.
> Don't change the subject.  You say that non-free is essential for our users to
> be safe, but you find it acceptable that it is not enabled by default. 
Have I really said that?

> > > Also, I'm interested to hear which rule would be broken
> > "Debian will remain 100% free", "non-free is not part of Debian" etc.
> Your position is that it is acceptable for a program in main to require a
> non-free service, as long as that non-free service doesn't run on the same
> computer.  
Wrong.
My position is that it should acceptable for a program in main to require
a non-free service, or data, or whatever, as long as that program itself
is free and running it doesn't compromise the freedom of the user.
contrib should be for wrappers, downloaders etc. The policy uses the word
"supplemental".

> > > if we make it the default to provide our users with updates that they
> > > need to be safe.
> > But then you will be able to see and install non-free software, isn't that
> > what you don't want to happen?
> 
> It's a sacrifice I'm willing to make for our users.  
Oh wow.

> Finally, for the third time, please explain your position on my hypothetical
> unrar-nonfree scenario.
I don't have a position in that scenario because I don't intend to dig it
and examine it.
I don't know why are you counting times unless you view this discussion as
a battle between you and the world.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

I'm getting tired of this.  You keep avoiding my questions and changing the
subject.  Unless you start answering my questions, I'm going to stop
responding.

On Mon, Aug 28, 2017 at 02:21:01PM +0500, Andrey Rahmatullin wrote:
> On Mon, Aug 28, 2017 at 08:55:43AM +, Dr. Bas Wijnen wrote:
> > > > Are you saying that a Debian system where only main is enabled is 
> > > > unsafe?
> > > [...]
> > > > If that is correct, it is a huge problem that that is the default setup
> > > > we ship, don't you think?
> > > It is, but solving it most likely means actually violating Debian
> > > principles,
> > 
> > You cannot be serious...  You believe that if our rules say we should harm 
> > our
> > users, the rules are more important than the users?  
> No, I believe our users are more important and so you shouldn't set
> arbitrary restrictions on main just so your apt search output could be
> untainted.

Don't change the subject.  You say that non-free is essential for our users to
be safe, but you find it acceptable that it is not enabled by default.  How is
that not hurting our users?

> > Also, I'm interested to hear which rule would be broken
> "Debian will remain 100% free", "non-free is not part of Debian" etc.

Your position is that it is acceptable for a program in main to require a
non-free service, as long as that non-free service doesn't run on the same
computer.  Why is that suddenly no longer true when the non-free service is
hosted on our own servers?  Or do you perhaps agree with me that a program
requiring a non-free service cannot be in main?

> > if we make it the default to provide our users with updates that they
> > need to be safe.
> But then you will be able to see and install non-free software, isn't that
> what you don't want to happen?

It's a sacrifice I'm willing to make for our users.  It would be better if the
essential parts would be in a separate repository so I could enable only those,
but as long as that isn't implemented, of course I think the safety of our
users is more important than the looks of my package list.

Finally, for the third time, please explain your position on my hypothetical
unrar-nonfree scenario.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Philipp Kern]

On 08/27/2017 12:20 PM, Dr. Bas Wijnen wrote:
> On Sat, Aug 19, 2017 at 06:21:23PM +0200, Philipp Kern wrote:
>> On 08/18/2017 10:36 AM, Dr. Bas Wijnen wrote:
>>> Consider the following: unrar-nonfree contains some software which is 
>>> non-free
>>> and can therefore not be in main.  The reason we don't put it in main is 
>>> that
>>> we want users who care about freedom to not even see this software.  Agreed?
>>
>> Ex falso quodlibet?
>>
>> Archive areas serve a purpose of grouping and indeed everything that is
>> not main is not part of the distribution. But I don't think the purpose
>> of the separate areas is to hide anything.
> 
> Let me put it differently then: for me, one of the major benefits of Debian
> over (most of) our derivatives is that I can set the system up in a way that
> allows me to live in a free software bubble.  Is there a non-free alternative
> to my free program?  I don't care, and I'm happy that it doesn't show up in my
> package list.  Is there a program that is only useful in conjunction with a
> non-free program?  Same thing.
> 
> So I'm not talking about hiding in the sense of "let's make sure people will
> not find this", but instead in the sense of "let's allow people to not be
> bothered by those packages".

I don't think I'm sufficiently convinced of this singular use case. We
provide one selection of what's free and it's very hard to generalize
that over many - as opinionated - people. People apply different
standards on what they consider acceptable. You might take the view that
what's the status quo in main is acceptable to you and hence that's what
you want to see. But as it stands, that's not the case.

The policy expresses that it's about package dependencies. I understand
that you - again - don't want to read the letter of the various
policies, but the spirit. But it does allow client implementations of
things that interact with non-free services and devices since the
beginning, because that's what we had to do with to get a usable system.

As Andrey points out the way free software purists went was that a ROM
with code is fine as long as you don't update that and as long as it's
essentially initializing the hardware before the main OS starts. I -
personally - view this as a silly stance, but then to everybody their
own opinion as long as they don't force theirs over others without a
vote/say in things.

>> I think such a package would fail other sanity checks (the existence of
>> a free implementation of the algorithm being one of them - there's no
>> right to be included in the distribution).
> I'm glad you agree that it fails sanity checks.  However, can you find a rule
> that actually forbids it?  If a maintainer were to do this, how would you 
> argue
> that their package cannot go in main?

I find the rule that the policy talks about not requiring packages that
are not in main. This is not the case even in this example.

I think the sanity check that fails today is a) free implementations of
the RAR algorithm exist so this is unnecessary and b) the act of
unarchiving large amounts of data by sending them to a cloud service
seems prohibitively costly.

However, if this is the only way to access the data I want to access and
the implementation is free, then yes, that ought to be acceptable. DRM
is very valuable as an example as there is a lot of content that is
really only usable with a proprietary server.

> The two arguments you mention don't work:
> 
> No free implementation: That's what this discussion is all about.  For all the
> real examples that have been mentioned in this thread (amazon s3, icq), 
> someone
> has noted that there actually is a free implementation of the server software.
> Which as far as I understand means everybody agrees (I know I do) that that is
> enough to allow the package in main.  The question is if a package can be in
> main if it requires a non-free service.  Even if that requirement cannot be
> written as a package dependency because it doesn't run on the same machine.
> Because if it does, policy is very clear.  If it doesn't, it seems obvious to
> me that the same principle still stands and it must not be in main, but
> apparently others disagree.

Yeah, as you see, there is disagreement about your interpretation of the
language after your changes. :)

> No right to be included: we're assuming that a maintainer wants to include 
> this
> in Debian and they don't need a right, they can just do it if nobody stops
> them.  So we still need a reason to stop them.

Apply common sense as the ftp-masters do.

>> In my view a more interesting thought example would be DRM: What about
>> an DFSG-compliant module that communicates with a remote license server
>> returning encryption keys. There's not an inherent need for a DRM module
>> to be Closed Source, given that the Linux platform does not offer any
>> security guarantees against Reverse Engineering and leaking the key
>> material anyway.
>>
>> Would that be acceptable for 

Re: Whether remotely running software is considered "software" for Debian.

[Andrey Rahmatullin]

On Mon, Aug 28, 2017 at 08:55:43AM +, Dr. Bas Wijnen wrote:
> > > Are you saying that a Debian system where only main is enabled is unsafe?
> > [...]
> > > If that is correct, it is a huge problem that that is the default setup
> > > we ship, don't you think?
> > It is, but solving it most likely means actually violating Debian
> > principles,
> 
> You cannot be serious...  You believe that if our rules say we should harm our
> users, the rules are more important than the users?  
No, I believe our users are more important and so you shouldn't set
arbitrary restrictions on main just so your apt search output could be
untainted.

> Have you not read the social contract?
Have you?

> Also, I'm interested to hear which rule would be broken
"Debian will remain 100% free", "non-free is not part of Debian" etc.

> if we make it the default to provide our users with updates that they
> need to be safe.
But then you will be able to see and install non-free software, isn't that
what you don't want to happen?

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

On Mon, Aug 28, 2017 at 12:29:07PM +0500, Andrey Rahmatullin wrote:
> On Mon, Aug 28, 2017 at 06:58:50AM +, Dr. Bas Wijnen wrote:
> > Are you saying that a Debian system where only main is enabled is unsafe?
> [...]
> > If that is correct, it is a huge problem that that is the default setup
> > we ship, don't you think?
> It is, but solving it most likely means actually violating Debian
> principles,

You cannot be serious...  You believe that if our rules say we should harm our
users, the rules are more important than the users?  Have you not read the
social contract?

Also, I'm interested to hear which rule would be broken if we make it the
default to provide our users with updates that they need to be safe.  If such a
rule exists, I believe it should be changed (because our users are our
priority, as per SC), but I'm not aware that we would break any of our rules.
Please clarify.

Also, as a reminder, I'm still waiting for anyone to answer the unrar-nonfree
question: if the non-free part is split off and placed in the cloud, would the
other part be allowed into main?  In other words, would this be a way for the
unrar-nonfree maintainer to get the package into Debian?  And if not, why not?

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Andrey Rahmatullin]

On Mon, Aug 28, 2017 at 06:58:50AM +, Dr. Bas Wijnen wrote:
> > > Let me put it differently then: for me, one of the major benefits of 
> > > Debian
> > > over (most of) our derivatives is that I can set the system up in a way 
> > > that
> > > allows me to live in a free software bubble.  
> > So you don't update the non-free software in your CPU?
> I suppose so.  Are you saying that a Debian system where only main is enabled
> is unsafe?
Not only that, but also "free software purists often don't understand the
current world".
And it looks like all your hardware has its non-free software installed on
the board and thus not required to be downloaded from Debian non-free.

> If that is correct, it is a huge problem that that is the default setup
> we ship, don't you think?
It is, but solving it most likely means actually violating Debian
principles, unlike things you are complaining about.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

On Sun, Aug 27, 2017 at 04:00:54PM +0500, Andrey Rahmatullin wrote:
> On Sun, Aug 27, 2017 at 10:20:27AM +, Dr. Bas Wijnen wrote:
> > Let me put it differently then: for me, one of the major benefits of Debian
> > over (most of) our derivatives is that I can set the system up in a way that
> > allows me to live in a free software bubble.  
> So you don't update the non-free software in your CPU?

I suppose so.  Are you saying that a Debian system where only main is enabled
is unsafe?  If that is correct, it is a huge problem that that is the default
setup we ship, don't you think?

> > No free implementation: That's what this discussion is all about.  For all 
> > the
> > real examples that have been mentioned in this thread (amazon s3, icq), 
> > someone
> > has noted that there actually is a free implementation of the server 
> > software.
> Did anyone realy mention a free implementation of the ICQ server?

Yes, I believe so.  I don't care enough to look it up, as it isn't all that
relevant to the discussion.

> > Which as far as I understand means everybody agrees (I know I do) that that 
> > is
> > enough to allow the package in main.
> No, we happily had s3cmd in main even before someone found a free server
> implementation. 

I did not contradict that.  My statement is that if there is a free
implementation, it is certainly good enough.  The situation without a free
server is obviously not as clear.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Andrey Rahmatullin]

On Sun, Aug 27, 2017 at 10:20:27AM +, Dr. Bas Wijnen wrote:
> Let me put it differently then: for me, one of the major benefits of Debian
> over (most of) our derivatives is that I can set the system up in a way that
> allows me to live in a free software bubble.  
So you don't update the non-free software in your CPU?

> No free implementation: That's what this discussion is all about.  For all the
> real examples that have been mentioned in this thread (amazon s3, icq), 
> someone
> has noted that there actually is a free implementation of the server software.
Did anyone realy mention a free implementation of the ICQ server?

> Which as far as I understand means everybody agrees (I know I do) that that is
> enough to allow the package in main.
No, we happily had s3cmd in main even before someone found a free server
implementation. 
Not to mention ICQ.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

On Sat, Aug 19, 2017 at 06:21:23PM +0200, Philipp Kern wrote:
> On 08/18/2017 10:36 AM, Dr. Bas Wijnen wrote:
> > Consider the following: unrar-nonfree contains some software which is 
> > non-free
> > and can therefore not be in main.  The reason we don't put it in main is 
> > that
> > we want users who care about freedom to not even see this software.  Agreed?
> 
> Ex falso quodlibet?
> 
> Archive areas serve a purpose of grouping and indeed everything that is
> not main is not part of the distribution. But I don't think the purpose
> of the separate areas is to hide anything.

Let me put it differently then: for me, one of the major benefits of Debian
over (most of) our derivatives is that I can set the system up in a way that
allows me to live in a free software bubble.  Is there a non-free alternative
to my free program?  I don't care, and I'm happy that it doesn't show up in my
package list.  Is there a program that is only useful in conjunction with a
non-free program?  Same thing.

So I'm not talking about hiding in the sense of "let's make sure people will
not find this", but instead in the sense of "let's allow people to not be
bothered by those packages".

> > Now what would be the result of moving this non-free part to a network 
> > server?
> > In terms of freedom there are no benefits to this.  The user is still using 
> > the
> > non-free software, but now they can also be tracked by the server admin, and
> > they can't use a debugger to hack it, should they want to.  So it is 100% 
> > bad
> > for them.
> > 
> > However, according to your logic, because it is no longer running on your 
> > own
> > cpu, this change would allow unrar-nonfree to go into main.  You do agree 
> > that
> > this is not a sensible result of making software worse, right?
> 
> I think such a package would fail other sanity checks (the existence of
> a free implementation of the algorithm being one of them - there's no
> right to be included in the distribution).

I'm glad you agree that it fails sanity checks.  However, can you find a rule
that actually forbids it?  If a maintainer were to do this, how would you argue
that their package cannot go in main?

The two arguments you mention don't work:

No free implementation: That's what this discussion is all about.  For all the
real examples that have been mentioned in this thread (amazon s3, icq), someone
has noted that there actually is a free implementation of the server software.
Which as far as I understand means everybody agrees (I know I do) that that is
enough to allow the package in main.  The question is if a package can be in
main if it requires a non-free service.  Even if that requirement cannot be
written as a package dependency because it doesn't run on the same machine.
Because if it does, policy is very clear.  If it doesn't, it seems obvious to
me that the same principle still stands and it must not be in main, but
apparently others disagree.

No right to be included: we're assuming that a maintainer wants to include this
in Debian and they don't need a right, they can just do it if nobody stops
them.  So we still need a reason to stop them.

> In my view a more interesting thought example would be DRM: What about
> an DFSG-compliant module that communicates with a remote license server
> returning encryption keys. There's not an inherent need for a DRM module
> to be Closed Source, given that the Linux platform does not offer any
> security guarantees against Reverse Engineering and leaking the key
> material anyway.
> 
> Would that be acceptable for main?

You seem to think that I want to kick everything out of main that is capable of
interacting with non-free software?  If so, you are mistaken.  I want to kick
things out of main if the _only_ way to use (major parts of) it is by
interacting with non-free software (and I don't care on what machine that is
running).

> Would the existence of a free server implementation change the opinion, even
> though it likely would not help the media files you intend to view?

Yes, of course.  That would mean that it is possible to make use of the
software without interacting with non-free software.  Again, my goal here is
not to stop people from using non-free software; it is to make sure people who
don't want to use it will not have to decide that they don't want to use this
package.  They made that decision when leaving contrib out of their
sources.list and Debian should respect that choice.

> At the same time: As long as programs are talking to an API - even if
> RE'ed - and doing so lets users accomplish their tasks at hand and the
> programs in question are completely DFSG-compliant, I think we should
> carry them in main if they provide a benefit.

How is that not true for my unrar-nonfree example?  I'm assuming an API has
been set up for the communication between the free client and the non-free
server.  It seemed that you agreed that such a client should still not be
allowed in main.  But why not?  If 

Re: Whether remotely running software is considered "software" for Debian.

[Philipp Kern]

On 08/18/2017 10:36 AM, Dr. Bas Wijnen wrote:
> Consider the following: unrar-nonfree contains some software which is non-free
> and can therefore not be in main.  The reason we don't put it in main is that
> we want users who care about freedom to not even see this software.  Agreed?

Ex falso quodlibet?

Archive areas serve a purpose of grouping and indeed everything that is
not main is not part of the distribution. But I don't think the purpose
of the separate areas is to hide anything.

> Now what would be the result of moving this non-free part to a network server?
> In terms of freedom there are no benefits to this.  The user is still using 
> the
> non-free software, but now they can also be tracked by the server admin, and
> they can't use a debugger to hack it, should they want to.  So it is 100% bad
> for them.
> 
> However, according to your logic, because it is no longer running on your own
> cpu, this change would allow unrar-nonfree to go into main.  You do agree that
> this is not a sensible result of making software worse, right?

I think such a package would fail other sanity checks (the existence of
a free implementation of the algorithm being one of them - there's no
right to be included in the distribution).

In my view a more interesting thought example would be DRM: What about
an DFSG-compliant module that communicates with a remote license server
returning encryption keys. There's not an inherent need for a DRM module
to be Closed Source, given that the Linux platform does not offer any
security guarantees against Reverse Engineering and leaking the key
material anyway.

Would that be acceptable for main? Would the existence of a free server
implementation change the opinion, even though it likely would not help
the media files you intend to view?

At the same time: As long as programs are talking to an API - even if
RE'ed - and doing so lets users accomplish their tasks at hand and the
programs in question are completely DFSG-compliant, I think we should
carry them in main if they provide a benefit.

We have lots of historic precedent in this area. What are we going to do
otherwise? Proof for every program that there's a way to use them either
entirely disconnected or against a free server/device? What about
proprietary hardware connected over, say, USB? Would we remove the
corresponding drivers from the kernel? Where would we stop on this
slippery slope?

>> The language in Policy §2.2 does not relate to any program's purpose at
>> all.
> What do you think the purpose of policy is, if not to ensure that our software
> gives freedom to our users?

The agreed-upon baseline is the DFSG which does not offer this premise
you interpret as a guarantee, though.

Kind regards
Philipp Kern



signature.asc
Description: OpenPGP digital signature

Re: Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

On Tue, Aug 15, 2017 at 08:46:43AM +1000, Ben Finney wrote:
> The language is clear that it is talking about dependency in the sense
> of requiring the program installed on the system in order for the
> program to build or execute.

I think the mention of package dependencies is an incomplete list of examples.
But even if it was meant to be complete, thinking for a moment about the
purpose of Debian should make clear that your interpretation cannot be correct:

The reason we have the rules is because we care about freedom.  That doesn't
suddenly end when a program runs on a different server.

Consider the following: unrar-nonfree contains some software which is non-free
and can therefore not be in main.  The reason we don't put it in main is that
we want users who care about freedom to not even see this software.  Agreed?

Now what would be the result of moving this non-free part to a network server?
In terms of freedom there are no benefits to this.  The user is still using the
non-free software, but now they can also be tracked by the server admin, and
they can't use a debugger to hack it, should they want to.  So it is 100% bad
for them.

However, according to your logic, because it is no longer running on your own
cpu, this change would allow unrar-nonfree to go into main.  You do agree that
this is not a sensible result of making software worse, right?

> > I think they are equivalent; server software is still software and I
> > don't see why it running remotely suddenly makes it acceptable to
> > depend on it.
> 
> You appear to be using “depend” here to mean “without this the program
> *is not useful*”.

Most programs in contrib can build and run without non-free software.  They
will just immediately produce an error message.  Our users would describe that
as depending on the non-free software.

> The language in Policy §2.2 does not relate to any program's purpose at
> all.

What do you think the purpose of policy is, if not to ensure that our software
gives freedom to our users?

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Ben Finney]

"Dr. Bas Wijnen"  writes:

> I'm referring to policy 2.2, which lists what software belongs in main
> and what belongs in contrib. While this is not voted on and it does
> not follow directly from the SC, I thought there was agreement that
> what's in Policy 2.2 is a good way to determine where software should
> go. In particular, if it is free, but requires software outside of
> main to do its job, then it should go in contrib.

The parts of Policy §2.2 relevant to this appear to be:

§2.2.1 “The main archive area”

[…]
In addition, the packages in _main_
* must not require or recommend a package outside of _main_ for
  compilation or execution (thus, the package must not declare a
  [dependency relationship] on a non-_main_ package)
[…]

§2.2.2 “The contrib archive area”

The _contrib_ archive area contains supplemental packages intended
to work with the Debian distribution, but which require software
outside of the distribution to either build or function.

[…]
Examples of packages which would be included in _contrib_ are:
* free packages which require _contrib_, _non-free_ packages or
  packages which are not in our archive at all for compilation or
  execution
[…]

The language is clear that it is talking about dependency in the sense
of requiring the program installed on the system in order for the
program to build or execute.

> People are arguing here that "It requires a network server that is not
> in main" is fundamentally different from "it requires local software
> that is not in main".

I don't know of any program even proposed for Debian that would require
a network server in order to build or execute that program. So yes, that
is a distinction that is salient in the above Policy language.

> I think they are equivalent; server software is still software and I
> don't see why it running remotely suddenly makes it acceptable to
> depend on it.

You appear to be using “depend” here to mean “without this the program
*is not useful*”.

That is not a distinction relevant to the above Policy sections. They
speak only to whether the program will build or execute.

Whether the program does something useful is not relevant for the
categorisation into different archive areas, as laid out in the above
Policy sections.

> Policy 2.2. So again, I'm not saying the rules apply to the external
> software, I'm just saying that the external software is indeed
> software and therefore depending on it requires a package to be moved
> to contrib if the external software is not packaged in Debian (main).

The text of the above Policy sections uses “depend” and “require” in the
sense only for the cases they explicitly state: that of building the
program or executing it.

> Similarly, if a client program's purpose is to connect to a server
> that is not in main, the server operator doesn't need to do anything,
> but the fact that it is not in main means (IMO, but apparently that is
> disputed) that the client must be in contrib.

The language in Policy §2.2 does not relate to any program's purpose at
all.

Policy experts may correct me, but I find that your interpretation does
not fit what is written there.

-- 
 \  “When I was born I was so surprised I couldn't talk for a year |
  `\and a half.” —Gracie Allen |
_o__)  |
Ben Finney

Re: Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

On Mon, Aug 14, 2017 at 08:58:00AM +1000, Ben Finney wrote:
> "Dr. Bas Wijnen"  writes:
> 
> > What seems to be the dispute is whether software that runs on a remote
> > system is still "software" for the purpose of our rules.
> 
> That is not in dispute, it seems to me. The rules of the Debian Project
> can only bind what the Debian Project does.

Yes, I agree of course.

> The Debian Project could moot rules about what the project will do with
> regard to software that runs on a remote system. While there are trends,
> I don't think such rules exist yet, or if they do you haven't shown us
> what rules you're referring to.

I'm referring to policy 2.2, which lists what software belongs in main and what
belongs in contrib.  While this is not voted on and it does not follow directly
from the SC, I thought there was agreement that what's in Policy 2.2 is a good
way to determine where software should go.  In particular, if it is free, but
requires software outside of main to do its job, then it should go in contrib.

People are arguing here that "It requires a network server that is not in main"
is fundamentally different from "it requires local software that is not in
main".  I think they are equivalent; server software is still software and I
don't see why it running remotely suddenly makes it acceptable to depend on it.

> I hope we can agree that the Social Contract's rules about software in
> Debian do not have any power to restrict software running on remote
> systems (unless they also get their software from Debian).

Yes, this is about whether our packages should be in main or contrib.  External
software may influence that, but the result is a rule about our package, not
about the external software.

> > I think [software that runs on a remote system] is [software for the
> > purpose of the Debian Project's rules], especially considering the
> > trend that almost everything is being moved into the cloud.
> 
> Which of the Debian Project's rules are you referring to there? Can you
> show from where in those rules you draw this interpretation?

Policy 2.2.  So again, I'm not saying the rules apply to the external software,
I'm just saying that the external software is indeed software and therefore
depending on it requires a package to be moved to contrib if the external
software is not packaged in Debian (main).

> > I believe Debian's philosophy should be that software running remotely
> > on behalf of the user should be considered part of the system
> 
> By that philosophy, if person Foo connects to a system I am operating on
> the internet, the rules person Foo has chosen to accept are also binding
> on me? Even if I do not accept those rules?

Sorry, that is not what I meant.  What I mean with "part of the system" is that
it should be taken into account when deciding what to do with our software.  So
if Foo has chosen to always wear a hat while running /bin/bash, and that is
their shell on your system, then they must not only wear a hat when running
bash locally, but also when they log in at your system.

You don't need to do anything, and you are obviously not bound by their rules.
But your system does mean that they need to do something (if they want to
follow their own rules).

Similarly, if a client program's purpose is to connect to a server that is not
in main, the server operator doesn't need to do anything, but the fact that it
is not in main means (IMO, but apparently that is disputed) that the client
must be in contrib.

> > It seems clear to me that a program which is intended to interact with
> > server software does indeed require that server software to function.
> > So if there is no free implementation of the server, then the client
> > cannot be in main.
> 
> Maybe so, but that appears to be a different position: that the Debian
> Project's rules apply to software in Debian which interacts with remote
> systems.
> 
> That's very different from stating that the remote system's software is
> also part of Debian and therefore subject to the Debian Project's rules.
> 
> Please help by clarifying which of those positions you hold.

Yes, that was unclear.  I meant "part of the system" in the way that you need
to consider all forces in a system if you want to find the acceleration on an
object.  It was not my intention to imply that we have any say over the
external software.

Thanks for your questions, I hope my answers make my position more clear.

Thanks,
Bas


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Ben Finney]

"Dr. Bas Wijnen"  writes:

> What seems to be the dispute is whether software that runs on a remote
> system is still "software" for the purpose of our rules.

That is not in dispute, it seems to me. The rules of the Debian Project
can only bind what the Debian Project does.

The Debian Project could moot rules about what the project will do with
regard to software that runs on a remote system. While there are trends,
I don't think such rules exist yet, or if they do you haven't shown us
what rules you're referring to.

The Debian Project does have rules about software *in Debian*, as
described in, for example, our Social Contract.

I hope we can agree that the Social Contract's rules about software in
Debian do not have any power to restrict software running on remote
systems (unless they also get their software from Debian).

> I think [software that runs on a remote system] is [software for the
> purpose of the Debian Project's rules], especially considering the
> trend that almost everything is being moved into the cloud.

Which of the Debian Project's rules are you referring to there? Can you
show from where in those rules you draw this interpretation?

> I believe Debian's philosophy should be that software running remotely
> on behalf of the user should be considered part of the system

By that philosophy, if person Foo connects to a system I am operating on
the internet, the rules person Foo has chosen to accept are also binding
on me? Even if I do not accept those rules?

If not, please explain where that interpretation of your statement is
inaccurate.

> It seems clear to me that a program which is intended to interact with
> server software does indeed require that server software to function.
> So if there is no free implementation of the server, then the client
> cannot be in main.

Maybe so, but that appears to be a different position: that the Debian
Project's rules apply to software in Debian which interacts with remote
systems.

That's very different from stating that the remote system's software is
also part of Debian and therefore subject to the Debian Project's rules.

Please help by clarifying which of those positions you hold.

-- 
 \  “One time I went to a drive-in in a cab. The movie cost me |
  `\  ninety-five dollars.” —Steven Wright |
_o__)  |
Ben Finney

Re: Whether remotely running software is considered "software" for Debian.

[Ondřej Surý]

I fail to see what is the purpose of this thought exercise. Could you first 
clearly define the problem/goal/... and only then start finding solutions?


Ondřej


On 12 August 2017 09:19:51 "Dr. Bas Wijnen"  wrote:


Note: this post is not about certspotter at all, so I'm not Cc'ing the bug and
changed the Subject line.

On Wed, Aug 09, 2017 at 05:30:19PM -0400, Jonas Smedegaard wrote:

Stuff like s3cmd are tools connecting to cloud services.  Arguably
usable to have tools to free data from the clouds.


Which would be a great example of software that is free interacting with
software that is non-free.  Thus the package with this as its main purpose
should live in contrib.  There's nothing wrong with that.

(Note: I'm not saying s3cmd must be in contrib.  It can work with free servers,
so it can be in main.)

On Thu, Aug 10, 2017 at 12:45:39PM +0200, Philipp Kern wrote:

On 09.08.2017 23:30, Jonas Smedegaard wrote:
> ...but bug#856139 is, I believe, about a tool advertising a cloud
> service which is *not* used by the tool.  Instead that cloud service is
> advertised as an option *instead* of installing and using the Free tool.
>
> Anyone having opinions more narrowly on that kind of advertisements?

And then you go to the bug and you see that it degenerated into a "if it
uses a non-free service, it should go into contrib" subdiscussion. Since
when do we believe that? Neither the DFSG nor the Social Contract would
imply that you need to have a free server for an API client
implementation. Now, I understand that this would be desirable and we
should encourage it but we shouldn't just move goal posts willy-nilly.


What seems to be the dispute is whether software that runs on a remote system
is still "software" for the purpose of our rules.  I think it is, especially
considering the trend that almost everything is being moved into the cloud.  If
this continues, the only thing people will still run locally is their web
browser.  I believe Debian's philosophy should be that software running
remotely on behalf of the user should be considered part of the system and thus
free programs interacting with such software should be in contrib if the remote
software is non-free (and there is no free alternative).


The only crucial sentence might be this one from §2.2.2 in the policy:

"The contrib archive area contains supplemental packages intended to
work with the Debian distribution, but which require software outside of
the distribution to either build or function."


It seems clear to me that a program which is intended to interact with server
software does indeed require that server software to function.  So if there is
no free implementation of the server, then the client cannot be in main.


The policy isn't something we voted upon.


We codify existing practice in our policy.  If you think it was a mistake to
put this in there, and it needs to be changed, please explain what you believe
it should say instead.  I don't think this part of policy is controversial at
all.


Do people really understand that this means tools calling an API on the
Internet would need to be in contrib?


Let's frame that differently: From the point of view of a user who does not
want to deal with non-free software, what is the best solution?  That user will
not have contrib in their sources.list.  So should they see an ICQ client?  I
don't think they should.  You can say that it limits them to not be able to use
ICQ, and surely they care more about that than about not dealing with non-free
software?  No, they don't.  They specifically asked not to see software that
will take them to non-free software, so we should respect their decision and
not sneak clients to non-free servers (without free alternatives) into main.
Of course there are users who care more about not losing functionality, but
those are not the users this is about.  Those users have contrib and non-free
enabled in their sources.list, and thus they will find this software in
contrib.


I don't think I agree with this non-free'ization of Debian.
Stuff like licq never belonged into contrib either, despite its main
purpose back then being to connect to the ICQ (and MSN?) services.


If you agree that the main purpose of the program is to interact with non-free
software, do you not agree that it requires software outside of main to
function?  If you do, please propose new wording for policy.  Do you want to
make an exception for services on the network?  I don't think such an exception
would serve our users.  Those who ask not to see non-free related software
should not see clients to non-free services.  Does that not make sense to you?


Someone wrote a Free client implementation, hence we should offer it to
our users.


Yes, we should.  You imply that software in contrib isn't really free.  It is!
The only difference with software from main is that it cannot properly function
in a world where only Debian main is available.  If a maintainer or upstream

Re: Whether remotely running software is considered "software" for Debian.

[Marco d'Itri]

On Aug 12, "Dr. Bas Wijnen"  wrote:

> Which would be a great example of software that is free interacting with
> software that is non-free.  Thus the package with this as its main purpose
> should live in contrib.  There's nothing wrong with that.
There is no such requirement for Debian packages and there has never 
been one.
This was settled about 15 years ago, discussing ICQ clients.
Even RMS agreed.

You may argue to introduce one if you feel so inclined, but this kind of 
policy does not currently exist.

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Whether remotely running software is considered "software" for Debian.

[Jeremy Stanley]

On 2017-08-12 17:51:49 +0200 (+0200), Simon Richter wrote:
> On 12.08.2017 09:19, Dr. Bas Wijnen wrote:
> > (Note: I'm not saying s3cmd must be in contrib. It can work with
> > free servers, so it can be in main.)
> 
> It can be in main as soon as a free server exists, I think.

Not that I've personally tested them together, but this would
probably count if someone gets a chance to try:

https://git.openstack.org/cgit/openstack/swift3/
https://tarballs.openstack.org/swift3/

It's not packaged in Debian though (at least not yet anyway).
-- 
Jeremy Stanley


signature.asc
Description: Digital signature

Re: Whether remotely running software is considered "software" for Debian.

[Simon Richter]

Hi,

On 12.08.2017 09:19, Dr. Bas Wijnen wrote:

> (Note: I'm not saying s3cmd must be in contrib.  It can work with free 
> servers,
> so it can be in main.)

It can be in main as soon as a free server exists, I think.

   Simon



signature.asc
Description: OpenPGP digital signature

Whether remotely running software is considered "software" for Debian.

[Dr. Bas Wijnen]

Note: this post is not about certspotter at all, so I'm not Cc'ing the bug and
changed the Subject line.

On Wed, Aug 09, 2017 at 05:30:19PM -0400, Jonas Smedegaard wrote:
> Stuff like s3cmd are tools connecting to cloud services.  Arguably 
> usable to have tools to free data from the clouds.

Which would be a great example of software that is free interacting with
software that is non-free.  Thus the package with this as its main purpose
should live in contrib.  There's nothing wrong with that.

(Note: I'm not saying s3cmd must be in contrib.  It can work with free servers,
so it can be in main.)

On Thu, Aug 10, 2017 at 12:45:39PM +0200, Philipp Kern wrote:
> On 09.08.2017 23:30, Jonas Smedegaard wrote:
> > ...but bug#856139 is, I believe, about a tool advertising a cloud 
> > service which is *not* used by the tool.  Instead that cloud service is 
> > advertised as an option *instead* of installing and using the Free tool.
> > 
> > Anyone having opinions more narrowly on that kind of advertisements?
> 
> And then you go to the bug and you see that it degenerated into a "if it
> uses a non-free service, it should go into contrib" subdiscussion. Since
> when do we believe that? Neither the DFSG nor the Social Contract would
> imply that you need to have a free server for an API client
> implementation. Now, I understand that this would be desirable and we
> should encourage it but we shouldn't just move goal posts willy-nilly.

What seems to be the dispute is whether software that runs on a remote system
is still "software" for the purpose of our rules.  I think it is, especially
considering the trend that almost everything is being moved into the cloud.  If
this continues, the only thing people will still run locally is their web
browser.  I believe Debian's philosophy should be that software running
remotely on behalf of the user should be considered part of the system and thus
free programs interacting with such software should be in contrib if the remote
software is non-free (and there is no free alternative).

> The only crucial sentence might be this one from §2.2.2 in the policy:
> 
> "The contrib archive area contains supplemental packages intended to
> work with the Debian distribution, but which require software outside of
> the distribution to either build or function."

It seems clear to me that a program which is intended to interact with server
software does indeed require that server software to function.  So if there is
no free implementation of the server, then the client cannot be in main.

> The policy isn't something we voted upon.

We codify existing practice in our policy.  If you think it was a mistake to
put this in there, and it needs to be changed, please explain what you believe
it should say instead.  I don't think this part of policy is controversial at
all.

> Do people really understand that this means tools calling an API on the
> Internet would need to be in contrib?

Let's frame that differently: From the point of view of a user who does not
want to deal with non-free software, what is the best solution?  That user will
not have contrib in their sources.list.  So should they see an ICQ client?  I
don't think they should.  You can say that it limits them to not be able to use
ICQ, and surely they care more about that than about not dealing with non-free
software?  No, they don't.  They specifically asked not to see software that
will take them to non-free software, so we should respect their decision and
not sneak clients to non-free servers (without free alternatives) into main.
Of course there are users who care more about not losing functionality, but
those are not the users this is about.  Those users have contrib and non-free
enabled in their sources.list, and thus they will find this software in
contrib.

> I don't think I agree with this non-free'ization of Debian.
> Stuff like licq never belonged into contrib either, despite its main
> purpose back then being to connect to the ICQ (and MSN?) services.

If you agree that the main purpose of the program is to interact with non-free
software, do you not agree that it requires software outside of main to
function?  If you do, please propose new wording for policy.  Do you want to
make an exception for services on the network?  I don't think such an exception
would serve our users.  Those who ask not to see non-free related software
should not see clients to non-free services.  Does that not make sense to you?

> Someone wrote a Free client implementation, hence we should offer it to
> our users.

Yes, we should.  You imply that software in contrib isn't really free.  It is!
The only difference with software from main is that it cannot properly function
in a world where only Debian main is available.  If a maintainer or upstream
cares about that, they should fix the dependency (by convincing the server
upstream to release their code, or by writing a free alternative).  And if they
don't care about it, they should not