Re: Are online services also software for Debian's rules?
Hi,
On 08/12/2017 11:12 AM, Dr. Bas Wijnen wrote:
> On Sat, Aug 12, 2017 at 10:06:40AM +0200, Christian Seiler wrote:
>> I don't think this is as black and white as you paint it:
>
> It's certainly not black and white, and as I wrote elsewhere, the line can
> move. But there is a line and I don't think it's anywhere near where some
> people seem to draw it.
The point of my email was to illustrate that if I want to come up with a
consistent set of principles that tries to further flesh out the very
vague basic idea of what contrib is, and then start to follow these
principles to their logical conclusion, then I always appear to be able
to come up with examples that just don't seem right to me.
So I don't think there's a clear and easy line to draw.
And to be explicitly clear: there are two types of gray areas: ones
where there is a set of consistent principles can be applied, but the
question where individual examples fall might not always be easy to
decide - and other ones where I don't think it's easy to come up even
with a consistent set of principles. I do believe this here is the
latter case, not just the former.
>> win32-loader probably doesn't run on Wine or ReactOS (though I haven't
>> tried it, so I may be wrong here) - should that be in contrib if that's
>> the case?
>
> Possibly.
> The GPL makes an exception for components of the OS (so "it runs on
> Windows" doesn't make things non-free),
Well, nobody claims that contrib is non-free. The GPL clause here
is more about making an exception to the requirement that all code
that a GPL'd software is linked to also has to be under a license
compatible with the GPL.
> and I think it is reasonable if Debian followed that rule as well.
Could you then not also argue that other exceptions are reasonable?
In the case of the GPL I think the rationale for this exception is
much more clear-cut, because there it talks about specific issues
related to copyright and licensing restrictions.
>> So should the packaging granularity, which in the end is to a certain
>> extent always somewhat arbitrary, dictate whether a program goes into
>> main or contrib?
>
> In practice, yes. That's how we do things. Not because package granularity is
> relevant, but because we don't want to keep software out just because it
> contains the option to interact with something non-free. But if that option is
> in a package of its own, yes it belongs in contrib.
I personally find this to be completely absurd.
I do believe that packaging granularity as a _consequence_ of the
ability to include certain things in main or not is fine and even
necessary. Take for example the non-free firmware blos that are
split out of the kernel.
But I don't think that packaging granularity as a _reason_ for
either including or dropping the _very same code_, producing the
_very same binaries_, from main is a sensible position.
>> Furthermore, you can go to more extremes: "requires non-free
>> software to work" can also be applied to hardware drivers in more
>> general terms.
>
> Yes, hardware is complex and I follow the principle of RMS there: if you need
> it to get to a better (more free) place, it's acceptable.
Couldn't you also say that about ICQ clients? That if you are in a
situation where you can't get rid of ICQ it's better to use a free
software client to connect to it?
> Once there are free options, we should recommend them.
I don't think anyone here has an objection to that.
> So that means I don't think all of Debian should be in non-free because there
> are no free cpu designs
Ahem, nobody said anything about non-free here, we're talking about
contrib. That said: for all release archs of Debian there are
actually free implementations of the CPU architecture, in the form
of Qemu. So I don't think this applies here.
> [free CPU designs]
> (although I'm sure there are...)
There are, take a look at RISC-V, for example. [1] And for the
requirement about not requiring non-free software, you don't need
to have a fully free CPU design, just one where the microcode is
free. And I believe that current POWER CPUs fall under that
category. (I may be wrong though.)
>> - any tool dedicated to updating the firmware of devices where no
>> free firmware exists for any of the devices it supports should
>> also be in contrib (I'm talking about devices that have a flash
>> where the firmware is in, not about firmware loading that takes
>> place during device initialization)
>
> Why the distinction?
If you have to load a firmware before the device works you have
to actually ship the blob to the user to make it useful. If the
firmware is already embedded in the hardware the software that
is distributed doesn't have to contain any non-free parts to
make the hardware work.
This distinction is certainly debatable, but is one that has been
made by a lot of people in the past, including the FSF.
(And to be absolutely clear: I'm not trying to advocate for a
specific position, because I don't have a clear position on these
issues. I just think there are flaws in the arguments I've seen
presented here, which I want to point out.)
Regards,
Christian
[1] https://wiki.debian.org/RISC-V
Reply to: