Hello Russ, On Tue 25 Jan 2022 at 01:45pm -08, Russ Allbery wrote:
> Jonas Smedegaard <jo...@jones.dk> writes: > >> I just don't think the solution is to ignore copyright or licensing >> statements. > > That's not the goal. The question, which keeps being raised in part > because I don't think it's gotten a good answer, is what the basis is for > treating copyright and licensing bugs differently than any other bug in > Debian? > > The need for pre-screening was obvious when we had export control issues, > but my understanding is that those have gone away. Are we working from > legal advice telling us that this pre-screening is required for some legal > purpose? If so, is it effective for the legal purpose at which it is > aimed? Is this system left over from old advice? Have we checked our > assumptions recently? > > NEW processing is a lot of friction for the project as a whole and a lot > of work for the ftp team. If we were able to do less work at the cost of > a minimal increase in bugs, or at the cost of handling bugs a bit > differently, maybe that would be a good thing? > > In other words, it's unclear what requirements we're attempting to meet > and what the basis of those requirements is, which makes it hard to have a > conversation about whether the current design is the best design for the > problem we're trying to solve. I agree with you that we should consider treating license and copyright bugs just like other RC bugs, assuming a lawyer agrees. I think, though, that we should be more specific about what we want to treat differently. As an ftptrainee one learns various subtleties about licensing, copyright, the DFSG and the main/contrib/non-free distinction which most DDs would not disagree with, but of which they aren't explicitly aware, and don't incorporate into their packaging. Firstly, we can distinguish between copyright and licensing. The reason that ftpteam member ask for more copyright notices in d/copyright is because most licenses requires the preservation of all copyright notices in the binary distribution. When it comes to licensing, there are license compatibility issues, and the issue of d/copyright falsely claiming files are under one license when they're under another. I would guess that if the project wants to worry less about the former, we would also like to worry less about the latter, but the issues are distinct. Hardly anyone else in free software cares much about the copyright notices copying, but there is probably at least somewhat broader interest in being careful about license compatibility, for example. Secondly, there are the things which are self-imposed: the finer points of the DFSG, and the main/contrib/non-free distinction. Two issues which come up often are how we require that the preferred form for modification is included in main for every file in main, and the idea that main is self-contained. It is quite easy to violate these requirements, and it does seem to require training/practice to spot the issues. Typically new ftptrainees don't include them in their reviews. When we treat any of the above just like other RC bugs, we are accepting a lower likelihood that the bugs will be found, and also that they will be fixed. Severities can be changed and bugs can be ignored for purposes of testing migration. It would mean very different things for the identity of our project to accept a higher likelihood of strictly copyright/licensing bugs never being found or fixed, than it would to accept a higher likelihood of subtle DFSG bugs going unfound or unfixed. There are particular difficulties with trying to handle pure DFSG issues via the BTS rather than the simple accept/reject semantics of NEW. It is easy to disagree in particular cases, and sometimes judgement calls are required. The only people empowered to make those judgements calls are the ftpteam, and we can't be engaged with every bug in the BTS about DFSG issues, so it would seem particularly easy for bugs to languish. It means something, at present, that we treat these DFSG issues differently -- it's because we really care about shipping preferred forms for modification, and about how main is self-contained. It's not that we care about it /more/ than fixing programming bugs or whatever, but we care about it /differently/, because it's one of our founding ideas. We don't want to let that stuff in. We don't want to let technical bugs in either, but, well. I would like NEW to change so it can be faster, because I agree with you that the current focus on copyright and licensing does not line up with what we as a project really care about. I am not so sure that the character of the archive wouldn't change for the worse if we treated DFSG issues differently, however. -- Sean Whitton
