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

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

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

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

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.

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

> and b) the act of unarchiving large amounts of data by sending them to a
> cloud service seems prohibitively costly.

Sure, it's obvious that it would be a very bad change for technical reasons.
However, what if the maintainer believes that getting the functionality in main
is more important?  Then if they split the package into a client and a server,
I would not want to allow the client in main.  But if non-free network servers
are not a blocker, I don't see how I could stop it.

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

Our software should not care about what data you want to access.  If it is
possible for an organization to set up a server and have their people use that
server for whatever purpose they have, then that software has value for users
of free software.  If you want to use the client to connect to a closed source
proprietary server, that's your business and I won't try to stop you.  But it
is irrelevant to where the package belongs: packages don't need to go into
contrib just because some user only cares about using it with non-free
software.  The criterion is if the software is useful for people who want to
use it with free software.

> So the line you draw is if a free server implementation exists. Will someone
> need to evaluate if it's a suitable implementation? Does an API mock server
> that's delivered for integration testing suffice? Does it need to be a
> production grade implementation?

That is indeed a problem.  I would leave this decision to the maintainer.  But
for that, it is important that we have (rough) consensus on what the
requirements are.  I think it makes sense to require the server to result in a
usable system in the same way that software in our packages should be useful if
they aren't client+server combinations.

> 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

So I don't think anyone should write a free server just to allow the software
in main.  I think people should be fine with having their software in contrib.

And if someone thinks it would be useful to have a server running on their own
system, they may write a free server.  And once that happens, not only the
server, but also the client, can go into main.

> Sure, but maybe peruse the policy process then to find that out if it's
> a problem that needs fixing. I don't think you have consensus for a MBF. :)

That process is discussing on our mailing lists, which is what we're doing. ;)
In addition I have so far identified a total of 0 packages which would actually
be affected.  Because for some reason people are writing servers for

> >> 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
> > changes.
> That's why I'm asking you where you'd draw the line. So your personal
> policy is to be ok living with non-free hardware and don't want to ban
> related software, but communicating with a non-free network service is a
> problem? I just want to force you to be clear about this.

It depends on society.  I would prefer everything to be free.  And like with
science, where new answers bring more questions, making more things free
exposes more non-free things that I wasn't aware of before.  Now "it wasn't a
problem when I didn't know about it" is not a good argument for me.  But
"requiring this to be free now would destroy our system" is.  So things for
which there is no reasonable alternative can have non-free components as far as
I'm concerned.  That includes most hardware.  But I wouldn't write it as a rule
saying hardware doesn't need to be free.  Just that it's pragmatically better
for the moment to ignore its non-freeness.

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

The DFSG is irrelevant to this discussion.  We're talking about clients that
are free software.  Nobody says they belong in non-free.  I'm just saying they
belong in contrib.  That means they follow all of the DFSG.

> You can always say that the authors did not think of the Cloud. To which
> I say: fair enough. But then put up a vote to insert a new point. If you
> fear that you don't have consensus, maybe you don't and you shouldn't
> assume so. If you think you have consensus, the vote should be easy to
> get to pass?

I have no idea whether I have consensus, and it seems that most people are no
longer reading this thread.  But I don't like putting it to a vote; that would
just make people angry that their side is overruled, regardless of the outcome.

Also, you seem to think I want to change the DFSG.  That is not the case, as I
explained above.  I just want to clarify policy.

Thanks for keeping the discussion useful,

Attachment: signature.asc
Description: PGP signature

Reply to: