Re: NEW processing friction
Hello Russ,
On Tue 25 Jan 2022 at 01:45pm -08, Russ Allbery wrote:
> Jonas Smedegaard <jonas@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
Reply to: