[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

> 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 you think "talking to an API for which only
a non-free server exists" is not a blocker, what is the blocker that keeps the
client of this split version of unrar-nonfree out of main?

> We have lots of historic precedent in this area. What are we going to do
> otherwise?

It wouldn't be the first time that we decided to follow our rules more strictly
than we have previously done.  In this case, I'm not even sure if it would make
any difference for any current package.  I am not aware of any package that
would be impacted by clarifying that "None of the packages in the main archive
area require software outside of that area to function" does in fact apply to
software on a server contacted through the network as well.  (I also wasn't
aware that this was more strict than the interpretation in recent history.)

> Proof for every program that there's a way to use them either
> entirely disconnected or against a free server/device?

This isn't about forcing everyone to prove that they are allowed in main.  It's
about agreeing on what the rules are, so that when a package violates them it
can be recognized and handled.  And a temporary solution can also be to ignore
the problem.  But we should at least agree that it is a problem.

This is similar to the dissident and desert island tests.  We don't need to go
through our packages to see if they pass.  We just need to agree that when
someone points out they don't pass, it is a problem that needs fixing.

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

Hardware is indeed a tough issue.  I would love to see a world where free
hardware is so abundant that it would be reasonable to require it.  But that is
not the world we currently live in.  So for now, we'll have to live with that.

I agree that it is a slope, and perhaps it is slippery.  But that doesn't mean
we shouldn't go on it at all.  Because that would mean abandoning free software
entirely, and I'm sure you agree that isn't the solution either.  So
discussions like this one are important to see where we stand on this slope.
There will always be a programs that are clearly allowed in main and those that
are clearly not allowed.  And some for which it isn't so clear.  And over time,
some packages will change from one side to the other.  Because the world

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

You are not answering the question.  If I see a rule in our Policy, I
understand the reason behind that rule and I can understand that the rule also
applies to a case which isn't made so explicit in the text.  You seem to say
that the letter of the text is the only thing that counts and even if it makes
no sense, the document must be followed to the letter.

I'm sure you don't think that the above description is an accurate
representation of your position.  However, it is unclear to me what your
position is.  Can you clarify?


Attachment: signature.asc
Description: PGP signature

Reply to: