On Mon, Aug 14, 2017 at 08:58:00AM +1000, Ben Finney wrote: > "Dr. Bas Wijnen" <wijnen@debian.org> writes: > > > What seems to be the dispute is whether software that runs on a remote > > system is still "software" for the purpose of our rules. > > That is not in dispute, it seems to me. The rules of the Debian Project > can only bind what the Debian Project does. Yes, I agree of course. > The Debian Project could moot rules about what the project will do with > regard to software that runs on a remote system. While there are trends, > I don't think such rules exist yet, or if they do you haven't shown us > what rules you're referring to. I'm referring to policy 2.2, which lists what software belongs in main and what belongs in contrib. While this is not voted on and it does not follow directly from the SC, I thought there was agreement that what's in Policy 2.2 is a good way to determine where software should go. In particular, if it is free, but requires software outside of main to do its job, then it should go in contrib. People are arguing here that "It requires a network server that is not in main" is fundamentally different from "it requires local software that is not in main". I think they are equivalent; server software is still software and I don't see why it running remotely suddenly makes it acceptable to depend on it. > I hope we can agree that the Social Contract's rules about software in > Debian do not have any power to restrict software running on remote > systems (unless they also get their software from Debian). Yes, this is about whether our packages should be in main or contrib. External software may influence that, but the result is a rule about our package, not about the external software. > > I think [software that runs on a remote system] is [software for the > > purpose of the Debian Project's rules], especially considering the > > trend that almost everything is being moved into the cloud. > > Which of the Debian Project's rules are you referring to there? Can you > show from where in those rules you draw this interpretation? Policy 2.2. So again, I'm not saying the rules apply to the external software, I'm just saying that the external software is indeed software and therefore depending on it requires a package to be moved to contrib if the external software is not packaged in Debian (main). > > I believe Debian's philosophy should be that software running remotely > > on behalf of the user should be considered part of the system > > By that philosophy, if person Foo connects to a system I am operating on > the internet, the rules person Foo has chosen to accept are also binding > on me? Even if I do not accept those rules? Sorry, that is not what I meant. What I mean with "part of the system" is that it should be taken into account when deciding what to do with our software. So if Foo has chosen to always wear a hat while running /bin/bash, and that is their shell on your system, then they must not only wear a hat when running bash locally, but also when they log in at your system. You don't need to do anything, and you are obviously not bound by their rules. But your system does mean that they need to do something (if they want to follow their own rules). Similarly, if a client program's purpose is to connect to a server that is not in main, the server operator doesn't need to do anything, but the fact that it is not in main means (IMO, but apparently that is disputed) that the client must be in contrib. > > It seems clear to me that a program which is intended to interact with > > server software does indeed require that server software to function. > > So if there is no free implementation of the server, then the client > > cannot be in main. > > Maybe so, but that appears to be a different position: that the Debian > Project's rules apply to software in Debian which interacts with remote > systems. > > That's very different from stating that the remote system's software is > also part of Debian and therefore subject to the Debian Project's rules. > > Please help by clarifying which of those positions you hold. Yes, that was unclear. I meant "part of the system" in the way that you need to consider all forces in a system if you want to find the acceleration on an object. It was not my intention to imply that we have any say over the external software. Thanks for your questions, I hope my answers make my position more clear. Thanks, Bas
Attachment:
signature.asc
Description: PGP signature