Web lists-archives.com

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




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

Attachment: signature.asc
Description: OpenPGP digital signature