On Sat, Aug 12, 2017 at 09:55:17AM +0200, Vincent Bernat wrote: > ❦ 12 août 2017 07:37 GMT, "Dr. Bas Wijnen" <wijnen@debian.org> : > > Your argument seems to be: > > > > Debian cares about free software. > > Therefore, Debian does not enable contrib and non-free by default. > > Therefore, users may not see non-free related software. This is a problem. > > Let's fix it by pushing that software into main anyway. > > No, _your_ argument is that contrib and non-free are part of Debian and > are just a fine recipient for random software. I just emphasize the fact > they are not part of Debian. I agree that they are not part of Debian, but they are indeed fine as recipient for software (free software in the case of contrib). Debian is a self-contained system that does not require anything outside it. This is not true for a client of a network service that is not packaged in main, so such a client cannot be in main. > My argument is that services are not software. How do you think those services are implemented, if not as software? > > In other words: We care about free software, therefore we should put non-free > > (related) software in main. What? > > Strawman argument. Please, refrain from that. If you read my message, I explained that this was what I understood your argument to be. Instead of accusing me of rhetorical tricks, please just point out that I misunderstood you. > > If you believe it is a problem that our users don't have access to the software > > in contrib by default, then propose to fix that. The obvious way to do that > > would be by enabling contrib by default, not by moving software that belongs in > > contrib into main. > > Contrib cannot be enabled by default, it is not part of Debian. So? You just said that there is no problem whatsoever with Debian packages using non-free services, which I hope we agree are not a part of Debian either? Isn't contrib just a network service? > It's an additional service using Debian infrastructure. Policy is quite clear > about that. Yes, and your position is that programs using additional services outside of Debian can be in main. So how is this a problem for you? To be clear: I like to ship main-only by default, but I would understand if contrib was enabled by default and I don't think it would be against the SC, DFSG, or Policy. > And honestly, I don't have to do a thing. Nothing will change. Free > software using "non-free services" will stay in main because they meet > the proper requirements (policy 2.2.1). No, it doesn't. 2.2.1 says "None of the packages in the main archive area require software outside of that area to function." In other words, if software outside of main would not exist, the program would still work. But if that software wouldn't exist, the non-free service would not be available and the free client would be useless. > >> Debian is about free software. There is nothing in DFSG about "free > >> services". How do you know if a service is implemented with free > >> software or not? Amazon S3 could be free software, but only distributed > >> internally at Amazon. > > > > They can be, but that is irrelevant to this discussion. There is no question > > that the client is free software. If the server is not packaged in main, that > > means this free client software belongs in contrib. Whether that is because it > > is non-free or for some other reason does not matter. That is, unless you are > > claiming that their service is not "software". Are you? > > Yes, I am! They are services. Even the FSF acknowledges they are > different. They have created the AGPL for that. They have created the AGPL to close a loophole, namely that it was possible to move a program into the cloud and thereby the users lost their freedoms. The idea of copyleft is to guarantee those freedoms to downstream recipients and this trick made that impossible. So the AGPL says "if you access software over a network, you're still considered a user and need to receive all the rights". In other words, the AGPL is created specifically _because_ they acknowledge that a network service is also software. On Sat, Aug 12, 2017 at 10:06:40AM +0200, Christian Seiler wrote: > Because it's so fun, let me play devil's advocate for a bit: Sure. :) > On 08/12/2017 08:29 AM, Dr. Bas Wijnen wrote: > > No. The question is not "is there non-free software that the program can work > > with?" That would be much too broad, and it would make anything that touches > > the network non-free. Instead, the question is "is non-free software required > > for major functionality of the program?" > > 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. > 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), and I think it is reasonable if Debian followed that rule as well. But it's certainly debatable. > Consider the following scenario: I write a chat client that supports > both XMPP and ICQ - but don't separate the code. As the "major > functionality", i.e. chat, still works with free services (there are > plenty of free software XMPP servers out there), by your logic it should > be in main. But if at some point I decide to refactor that thing and > separate out the protocol implementations into libs, the library that > does ICQ should now be in contrib, and by extension the program then > should either be in contrib or drop support for ICQ. (Or implement a > plugin mechnaism, which can be a lot of work.) Yes, this is how it works. > 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. > Or would you instead say - to be consistent here - that the ICQ part > should also be disabled in the case where the libs aren't factored > out? That is another option, and we leave that to the maintainer to decide. Which is good, IMO. There are many subjective choices to be made here and trying to force strict rules on them is usually not a good idea. But we should agree on the spirit of the rules. Saying that network services are not software is not in the spirit that I thought we had. > 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. Once there are free options, we should recommend them. So that means I don't think all of Debian should be in non-free because there are no free cpu designs (although I'm sure there are...) But when there are "real" computers with a free cpu, I think supporting features that only exist on non-free cpus would become debatable. Again this is a subjective choice which I wouldn't want to formalize. > - 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? Thanks, Bas
Attachment:
signature.asc
Description: PGP signature