Do we need to hide packages in NEW queue (Was: Lottery NEW queue (Re: Are libraries with bumped SONAME subject of inspection of ftpmaster or not))
Am Tue, Jan 25, 2022 at 01:45:11PM -0800 schrieb Russ Allbery:
> 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?
May be some intermediate step would be to not hide packages in NEW queue
but exposing them as an apt source. If I'm correct this is not the case
since it had certain legal consequences for the project if code with
certain non-free licenses would be downloadable from some debian.org
address. May be NEW could be considered as some kind of pre-non-free as
long as it is not checked and the legal consequences are not valid for
us any more. But I'm not educated in international law - just asking
whether somebody might know better.
I'd consider it a big step forward to develop against packages from NEW
queue. (And yes, *I* know how to help myself with a local mirror but
team wide development is something else.)
> 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'm CCing debian-legal for this branch of the discussion (but I do not
read this list and think keeping debian-devel in the row is a good idea).
Kind regards
Andreas.
--
http://fam-tille.de
Reply to: