Re: Do we need to hide packages in NEW queue

2022-01-31 Thread Russ Allbery 
The Wanderer  writes:

> I am not on the inside of these things, certainly, but I have kept my
> eyes open from the outside, and I am not aware of there being any
> mechanism for removing something root-and-branch - across all affected
> versions, however far back those may stretch - from these repositories
> and archive locations once it's made it in. In order to avoid continuing
> to distribute something which we once accepted but which has since been
> deemed legally undistributable (and thus exposing ourselves to
> copyright-infringement lawsuits), we would need to have such a
> mechanism.

The thing is, we need this anyway for something we would legally need to
stop distributing, since otherwise we would be expecting ftp-master review
to be perfect *and* to never introduce unredistributable content in a
package update that doesn't go through NEW.  I don't think either of those
are realistic (or fair) expectations.

Now, we could defer creating such a thing until we actually need it and
then try to come up with something under emergency circumstances, and
maybe we'd get lucky and never need it.  But I think that's also true in
either scenario.  I'm not sure that the ftp-master review reduces the
likelihood so much as to change the risk analysis that much.  (But that
could well be a point of disagreement.)

-- 
Russ Allbery (r...@debian.org)

Re: Do we need to hide packages in NEW queue

2022-01-31 Thread Scott Kitterman 
On Monday, January 31, 2022 12:32:18 PM EST Russ Allbery wrote:
...
> A lawyer cannot make that risk trade-off decision for us.  We'll have to
> make it as a project.  But my hope would be that they could help put a
> number on the likely legal cost in the worst-case scenario and provide
> some input into the likelihood of that scenario, and some context in terms
> of what other organizations do and what risks it's common to accept and
> mediate if it becomes a problem.
...

I think this is exactly the right way to look at outside expertise.  An expert 
(in this case a lawyer) can give us information on trade offs related to legal 
risk (both to potentially losing in a legal action and to having to spend 
significant project resources even if we win), but the project has to make the 
decision about what level of risk it is willing to accept.

Scott K

signature.asc
Description: This is a digitally signed message part.

Re: Do we need to hide packages in NEW queue

2022-01-31 Thread The Wanderer 
On 2022-01-31 at 12:32, Russ Allbery wrote:

> Marc Haber  writes:
> 
>> Even if a lawyer says A, it doesn't buy us anything if J Robert DD
>> gets sued and the judge says B, or "not A".
> 
> Yes, a legal opinion cannot fully resolve the question,
> unfortunately, since it's a risk judgment.  Copyright law is murky
> enough that it's unlikely that any lawyer will be willing to
> guarantee that we won't lose a lawsuit, and of course no one can
> guarantee that we won't be sued.
> 
> What a lawyer can do is give us a better risk analysis.  How *likely*
> is it that we would be sued over such a thing, and if we were, what
> would happen then?  How much would it cost us to dispose of the
> resulting lawsuit?
> 
> I think it's useful to view this as a price.  We're paying a quite 
> substantial price right now to implement pre-screening.  If we
> increase the risk that we may temporarily distribute something that
> we shouldn't until we discover that and fix it, that comes with some
> corresponding increased risk of a legal cost.  But in the meantime
> we'd be saving a substantial pre-screening cost.

My understanding has been that the issue is partly that once something
makes it through NEW and into the repository, it is (in principle) there
forever; it'll continue to be available through various archive
locations, ultimately TTBOMK cascading back to snapshot.debian.org,
indefinitely.

I am not on the inside of these things, certainly, but I have kept my
eyes open from the outside, and I am not aware of there being any
mechanism for removing something root-and-branch - across all affected
versions, however far back those may stretch - from these repositories
and archive locations once it's made it in. In order to avoid continuing
to distribute something which we once accepted but which has since been
deemed legally undistributable (and thus exposing ourselves to
copyright-infringement lawsuits), we would need to have such a
mechanism. (If we already do, I'd be interested to learn what it is, in
terms of how it's invoked and - to the extent that this isn't
unimportant implementation details - how it functions.)

Even leaving aside the practicalities of that, I am on a certain
conceptual and/or philosophical level uncomfortable with such a removal;
having something which was once on a level of distribution to make it
into snapshot.debian.org (and might be installed on my machine, or on
one of my machines) be removed from that location, and thus no longer
available, feels somehow wrong to me. (IOW, I appear to approve of the
principle that these things remain there forever.)

That could easily not be (and, in fact, probably is not) enough to
outweigh the price we're facing now with the pre-screening of NEW, but
it's at the very least enough that if not, that would be yet one more
weight on the pile of the the reasons why copyright law is Why We Can't
Have Nice Things.


(I concur with your assessment and arguments overall, I just didn't see
this one angle being addressed anywhere, and I feel that it's important
enough - assuming it applies at all - to make sure it doesn't get
overlooked.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Do we need to hide packages in NEW queue

2022-01-31 Thread Maxime Chambonnet 

On 1/31/22 10:35, Pirate Praveen wrote:



On തി, ജനു 31 2022 at 10:07:32 രാവിലെ +0100 +0100, Stephan Lachnit 

 wrote:

On Sun, Jan 30, 2022 at 8:35 PM Russ Allbery  wrote:


I do think that the amount of effort that the project puts into this
pre-screening is of sufficiently high magnitude that it would be worth
paying a lawyer for a legal opinion about whether or not we need to do
it. The savings to the project if we found out that we didn't, or that we
could do something simpler and more easily automated, would be more than
the cost of the legal opinion.


+1

Looking at the last financial numbers I found [1], we have at least
~750k USD we could use for this purpose. I don't really know how
expensive lawyers are, but I doubt that this would cost more than 10k.
Heck, we could even hire two lawyers without any significant financial
impact (maybe in the US and EU as I think these are probably the most
prominent areas for potential copyright lawsuits), even if it costs
50k.

IMHO that would be totally worth it. And instead of investing scarce
man-hours into pre-screening, we could create a money pool for
financial support in case there is a copyright lawsuit. The
pre-screening in NEW doesn't prevent someone from claiming copyright
infringement anyway, there is just a smaller chance that the lawsuit
is justified. But sadly even winning a lawsuit can still cost a
significant amount of money.


I agree. We should get real lawyers involved, pay and settle this issue 
>once and for all. As a maintainer who maintains a large number of 
>packages, NEW queue is big friction point for me personally and I'd be 
>very happy to see a solution for it, other than the status quo. Even 
>if the status quo is correct, I'd like this to be backed by a legal 
>opinion that we can rely on.

Is there any precedent of a lawsuit against Debian due to copyrighted
content in its archives? The gross intellectual property theft, Oracle
sources found somewhere, Oodle compression applying for sid... will
likely not even pass NEW in any case, extensive pre-screening or not.
While I am sure that helping one of the big four consulting firms, or
Mazars, make a living, will not encounter particular difficulties from
them; there surely can be found resources in the association and
political landscapes, which will at least widen the discussion as to
where to take advise from? On different scales, I see at least:
## French scope
-CNIL - state entity [1]
-APRIL - notable association [2] - ap...@april.org
-Quadrature du net - notable association [3]
## EU scope
-There was a man whom helped pass GDPR with Margrethe Vestager,
was it Mathias Vermeulen? [4]
-CCBE - The voice of European Lawyers
-Reach to the Commission or Parliament directly?
## Global scope
-GNU foundation
-Linux foundation
Ultimately, Debian is not bound to a particular territory?
United Nations and its satellites [5]could be a relevant scope for
inquiries.
Thank you to everyone involved for trying to strike the right balance,
between archives being a haven of quality and free software, and
following the crazy pace of software complexity.
Best regards, Maxime
[1]https://www.cnil.fr/
[2]https://listes.april.org/wws?pk_vid=ead171ca7a6f2a4a16436549595cd1f6
[3]https://www.laquadrature.net/about/
[4]https://www.awo.agency/about/mathias-vermeulen/
[5]https://unctad.org/system/files/official-document/ecosoc_res_2021d30_Note_OpenSource_en.pdf

Re: Do we need to hide packages in NEW queue

2022-01-31 Thread Russ Allbery 
Stephan Lachnit  writes:

> If I compare how other mediums handle copyright violations, most
> services have a "file a claim infringed copyright here" button on their
> site (e.g. YouTube). For example, we could write a DMCA policy like
> e.g. Github [2], hyperlink in the footer of all our official websites,
> make a small "debian-dmca" tool that is always available in our builds
> to file claims and provide infrastructure to process such claims.

Just as a side note, I believe the DMCA safe harbor provisions only apply
to entities that allow unrelated third parties to upload material to their
web sites (social media, GitHub, etc.).  Debian only allows project
affiliates to upload packages, so I suspect that we cannot use the DMCA
safe harbor provision.  (A lawyer would of course be able to answer that
question more conclusively.)

This is a bit murky given that Debian has only murky legal existence, but
it doesn't feel like we're within the spirit of the DMCA safe harbor
provision.  (Also, I don't know what that looks like in non-US law, since
the DMCA thing is specifically a US law.)

> I highly doubt that anyone will ever directly start a lawsuit instead of
> sending a cease-and-desist letter first, I'm not even sure if it is
> legal to start a lawsuit without doing this first.

Right, the other angle that it would be nice to have some more legal
information about is what would happen if we did make a mistake.  How
likely is it that we wouldn't be able to remedy it without much cost if we
acted promptly?  This is less a question about the specific language of
the law and more a practical question of how the law works in the real
world, something that a lawyer would be better-qualified to weigh in on.

-- 
Russ Allbery (r...@debian.org)

Re: Do we need to hide packages in NEW queue

2022-01-31 Thread Russ Allbery 
Marc Haber  writes:

> Even if a lawyer says A, it doesn't buy us anything if J Robert DD gets
> sued and the judge says B, or "not A".

Yes, a legal opinion cannot fully resolve the question, unfortunately,
since it's a risk judgment.  Copyright law is murky enough that it's
unlikely that any lawyer will be willing to guarantee that we won't lose a
lawsuit, and of course no one can guarantee that we won't be sued.

What a lawyer can do is give us a better risk analysis.  How *likely* is
it that we would be sued over such a thing, and if we were, what would
happen then?  How much would it cost us to dispose of the resulting
lawsuit?

I think it's useful to view this as a price.  We're paying a quite
substantial price right now to implement pre-screening.  If we increase
the risk that we may temporarily distribute something that we shouldn't
until we discover that and fix it, that comes with some corresponding
increased risk of a legal cost.  But in the meantime we'd be saving a
substantial pre-screening cost.

A lawyer cannot make that risk trade-off decision for us.  We'll have to
make it as a project.  But my hope would be that they could help put a
number on the likely legal cost in the worst-case scenario and provide
some input into the likelihood of that scenario, and some context in terms
of what other organizations do and what risks it's common to accept and
mediate if it becomes a problem.

My personal guess is that, given how completely casual or even openly
contemptuous most companies are about copyright licensing and how insanely
difficult it's been to get them to face any legal consequences whatsoever,
it seems unlikely that dealing with some licensing issues more reactively
would be a substantial legal risk.  By dealing with them *at all*, and we
would of course continue to hold ourselves to the same high standard that
we always have, we're already doing far better than the industry norm.
But a lawyer would have much more concrete experience and would be able to
provide a far better analysis.

-- 
Russ Allbery (r...@debian.org)

Re: Do we need to hide packages in NEW queue

2022-01-31 Thread Erik Huelsmann 
Hi,

On Mon, Jan 31, 2022 at 12:05 PM Marc Haber
 wrote:

> >Looking at the last financial numbers I found [1], we have at least
> >~750k USD we could use for this purpose. I don't really know how
> >expensive lawyers are, but I doubt that this would cost more than 10k.
> >Heck, we could even hire two lawyers without any significant financial
> >impact (maybe in the US and EU as I think these are probably the most
> >prominent areas for potential copyright lawsuits), even if it costs
> >50k.
>
> Even if a lawyer says A, it doesn't buy us anything if J Robert DD
> gets sued and the judge says B, or "not A".

Correct, but how is that different over the current situation?


-- 
Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.

Re: Do we need to hide packages in NEW queue

2022-01-31 Thread Marc Haber 
On Mon, 31 Jan 2022 10:07:32 +0100, Stephan Lachnit
 wrote:
>On Sun, Jan 30, 2022 at 8:35 PM Russ Allbery  wrote:
>> I do think that the amount of effort that the project puts into this
>> pre-screening is of sufficiently high magnitude that it would be worth
>> paying a lawyer for a legal opinion about whether or not we need to do
>> it.  The savings to the project if we found out that we didn't, or that we
>> could do something simpler and more easily automated, would be more than
>> the cost of the legal opinion.
>
>Looking at the last financial numbers I found [1], we have at least
>~750k USD we could use for this purpose. I don't really know how
>expensive lawyers are, but I doubt that this would cost more than 10k.
>Heck, we could even hire two lawyers without any significant financial
>impact (maybe in the US and EU as I think these are probably the most
>prominent areas for potential copyright lawsuits), even if it costs
>50k.

Even if a lawyer says A, it doesn't buy us anything if J Robert DD
gets sued and the judge says B, or "not A".

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Do we need to hide packages in NEW queue

2022-01-31 Thread Jonathan Carter 

Hey Russ

On 2022/01/30 21:34, Russ Allbery wrote:

Francesco Poli  writes:


I thought the basis was the fact that copyright and licensing bugs may
have bad legal consequences (lawsuits against the Project for
distributing legally undistributable packages, things like that), while
technical bugs do not cause issues with lawyers and are, in this sense,
"easier" to fix.


Sure, everyone says this, but is this *true*?

The free software community has a tendency to assume a lot of things about
laws that aren't actually true.  Sometimes this is useful conservatism,
since there are a lot of legal areas for which the answer is not
clear-cut, and if it doesn't matter much either way, better to avoid any
sharp corners.  But in this case, this assumption has a very high cost for
the project, so maybe it's worth finding out whether it actually matters.


Very true indeed.


As people have pointed out in the numerous previous iterations of this
discussion, it's not like the ftp-master screen eliminates all copyright
and licensing bugs on project services.  I'm sure that we've accidentally
pushed non-distributable material to Salsa, we did to Alioth before that,
ftp-master will occasionally make mistakes, etc.

We should act with alacrity to remedy serious copyright and licensing
bugs; no one is arguing against that.  But is it legally necessary to take
the very specific measure that we are currently taking against them?


I don't believe it is, if a piece of work is uploaded in NEW, chances 
are that we already host that in a public git repository already. Also, 
in the legal framework the process is usually to first send a cease and 
desist before further escalating, so in the case of that happening, I'm 
quite confident that the FTP masters will oblige and that it wouldn't 
become a major issue. (but also #IANAL)


As for getting legal advice, we do have an existing contract with Aaron 
K. Williamson of Williamson Legal, PLLC (https://www.akwlc.com/). His 
specialty is Open Source softwware, technology, licensing and contracts, 
so he would be a good person to ask specific questions about this, and 
since we have an existing contract with him, it's really easy to set up 
a video call / email thread with him if anyone wants to get some advice 
from him. So if anyone has some time / energy to put together some 
concrete questions / examples (and ideally also recruit one or more 
people from FTP team to be involved), then I'd be happy to do the 
introductions and set that up.


-Jonathan

Re: Do we need to hide packages in NEW queue

2022-01-31 Thread Jonathan Carter 

Hey Russ

On 2022/01/30 21:34, Russ Allbery wrote:

Francesco Poli  writes:


I thought the basis was the fact that copyright and licensing bugs may
have bad legal consequences (lawsuits against the Project for
distributing legally undistributable packages, things like that), while
technical bugs do not cause issues with lawyers and are, in this sense,
"easier" to fix.


Sure, everyone says this, but is this *true*?

The free software community has a tendency to assume a lot of things about
laws that aren't actually true.  Sometimes this is useful conservatism,
since there are a lot of legal areas for which the answer is not
clear-cut, and if it doesn't matter much either way, better to avoid any
sharp corners.  But in this case, this assumption has a very high cost for
the project, so maybe it's worth finding out whether it actually matters.


Very true indeed.


As people have pointed out in the numerous previous iterations of this
discussion, it's not like the ftp-master screen eliminates all copyright
and licensing bugs on project services.  I'm sure that we've accidentally
pushed non-distributable material to Salsa, we did to Alioth before that,
ftp-master will occasionally make mistakes, etc.

We should act with alacrity to remedy serious copyright and licensing
bugs; no one is arguing against that.  But is it legally necessary to take
the very specific measure that we are currently taking against them?


I don't believe it is, if a piece of work is uploaded in NEW, chances 
are that we already host that in a public git repository already. Also, 
in the legal framework the process is usually to first send a cease and 
desist before further escalating, so in the case of that happening, I'm 
quite confident that the FTP masters will oblige and that it wouldn't 
become a major issue. (but also #IANAL)


As for getting legal advice, we do have an existing contract with Aaron 
K. Williamson of Williamson Legal, PLLC (https://www.akwlc.com/). His 
specialty is Open Source softwware, technology, licensing and contracts, 
so he would be a good person to ask specific questions about this, and 
since we have an existing contract with him, it's really easy to set up 
a video call / email thread with him if anyone wants to get some advice 
from him. So if anyone has some time / energy to put together some 
concrete questions / examples (and ideally also recruit one or more 
people from FTP team to be involved), then I'd be happy to do the 
introductions and set that up.


-Jonathan

Re: Do we need to hide packages in NEW queue

2022-01-31 Thread Pirate Praveen 




On തി, ജനു 31 2022 at 10:07:32 രാവിലെ +0100 
+0100, Stephan Lachnit  wrote:

On Sun, Jan 30, 2022 at 8:35 PM Russ Allbery  wrote:


 I do think that the amount of effort that the project puts into this
 pre-screening is of sufficiently high magnitude that it would be 
worth
 paying a lawyer for a legal opinion about whether or not we need to 
do
 it.  The savings to the project if we found out that we didn't, or 
that we
 could do something simpler and more easily automated, would be more 
than

 the cost of the legal opinion.


+1

Looking at the last financial numbers I found [1], we have at least
~750k USD we could use for this purpose. I don't really know how
expensive lawyers are, but I doubt that this would cost more than 10k.
Heck, we could even hire two lawyers without any significant financial
impact (maybe in the US and EU as I think these are probably the most
prominent areas for potential copyright lawsuits), even if it costs
50k.

IMHO that would be totally worth it. And instead of investing scarce
man-hours into pre-screening, we could create a money pool for
financial support in case there is a copyright lawsuit. The
pre-screening in NEW doesn't prevent someone from claiming copyright
infringement anyway, there is just a smaller chance that the lawsuit
is justified. But sadly even winning a lawsuit can still cost a
significant amount of money.


I agree. We should get real lawyers involved, pay and settle this issue 
once and for all. As a maintainer who maintains a large number of 
packages, NEW queue is big friction point for me personally and I'd be 
very happy to see a solution for it, other than the status quo. Even if 
the status quo is correct, I'd like this to be backed by a legal 
opinion that we can rely on.

Re: Do we need to hide packages in NEW queue

2022-01-31 Thread Stephan Lachnit 
On Sun, Jan 30, 2022 at 8:35 PM Russ Allbery  wrote:
>
> I do think that the amount of effort that the project puts into this
> pre-screening is of sufficiently high magnitude that it would be worth
> paying a lawyer for a legal opinion about whether or not we need to do
> it.  The savings to the project if we found out that we didn't, or that we
> could do something simpler and more easily automated, would be more than
> the cost of the legal opinion.

+1

Looking at the last financial numbers I found [1], we have at least
~750k USD we could use for this purpose. I don't really know how
expensive lawyers are, but I doubt that this would cost more than 10k.
Heck, we could even hire two lawyers without any significant financial
impact (maybe in the US and EU as I think these are probably the most
prominent areas for potential copyright lawsuits), even if it costs
50k.

IMHO that would be totally worth it. And instead of investing scarce
man-hours into pre-screening, we could create a money pool for
financial support in case there is a copyright lawsuit. The
pre-screening in NEW doesn't prevent someone from claiming copyright
infringement anyway, there is just a smaller chance that the lawsuit
is justified. But sadly even winning a lawsuit can still cost a
significant amount of money.

If I compare how other mediums handle copyright violations, most
services have a "file a claim infringed copyright here" button on
their site (e.g. YouTube). For example, we could write a DMCA policy
like e.g. Github [2], hyperlink in the footer of all our official
websites, make a small "debian-dmca" tool that is always available in
our builds to file claims and provide infrastructure to process such
claims. I highly doubt that anyone will ever directly start a lawsuit
instead of sending a cease-and-desist letter first, I'm not even sure
if it is legal to start a lawsuit without doing this first.

IANAL of course, but that's why we should actually pay one. If we just
keep discussing and amending "IANAL" to our messages we won't fix any
of our problems. And of course in addition to paying a lawyer, we
should ask what other distros do (especially Ubuntu, SUSE and RedHat
as they are from large companies with a legal department).

Regards,
Stephan

[1] https://lists.debian.org/debian-devel-announce/2021/08/msg5.html
[2] https://docs.github.com/en/github/site-policy/dmca-takedown-policy

Re: Do we need to hide packages in NEW queue

2022-01-30 Thread Russ Allbery 
Francesco Poli  writes:

> I thought the basis was the fact that copyright and licensing bugs may
> have bad legal consequences (lawsuits against the Project for
> distributing legally undistributable packages, things like that), while
> technical bugs do not cause issues with lawyers and are, in this sense,
> "easier" to fix.

Sure, everyone says this, but is this *true*?

The free software community has a tendency to assume a lot of things about
laws that aren't actually true.  Sometimes this is useful conservatism,
since there are a lot of legal areas for which the answer is not
clear-cut, and if it doesn't matter much either way, better to avoid any
sharp corners.  But in this case, this assumption has a very high cost for
the project, so maybe it's worth finding out whether it actually matters.

As people have pointed out in the numerous previous iterations of this
discussion, it's not like the ftp-master screen eliminates all copyright
and licensing bugs on project services.  I'm sure that we've accidentally
pushed non-distributable material to Salsa, we did to Alioth before that,
ftp-master will occasionally make mistakes, etc.

We should act with alacrity to remedy serious copyright and licensing
bugs; no one is arguing against that.  But is it legally necessary to take
the very specific measure that we are currently taking against them?

It's also worth remembering that absolutely nothing that we can do will
guarantee the project or some members of the project will not be sued.  As
the saying goes in the US, you can sue anyone for anything; you just might
not *win*.  If we're protecting ourselves against *losing* a lawsuit, or
can draw a direct line between the measures we're taking and decreased
liability, better settlements, etc., that would be useful to know,
including the rough shape of the parameters around that.  But I'm a little
worried that we've fallen into a reflexive defense of a specific
mitigation that may not be doing very much about the project's actual
legal risks, but which has accumulated enough weight of tradition that
everyone thinks it's necessary.

> I am under the impression that the pre-screening in the NEW queue is an
> attempt to catch legal issues *before* the package is introduced into
> the archive.

I also agree that this is the case, but I don't think it's obvious that
this attempt is necessary or that it's the most effective place to put
that level of effort and friction.

> Personally, I think the legal pre-screening by the FTP masters in the
> NEW queue is useful and should be kept.

Is this on advice of legal counsel?  Do you have some concrete reference
for this belief that we can rely on?

I do think that the amount of effort that the project puts into this
pre-screening is of sufficiently high magnitude that it would be worth
paying a lawyer for a legal opinion about whether or not we need to do
it.  The savings to the project if we found out that we didn't, or that we
could do something simpler and more easily automated, would be more than
the cost of the legal opinion.

> In fact, I wish the pre-screening were stricter.

> I've seen cases, where a bug is reported against a legally
> undistributable package and the issue is left unaddressed for ages with
> nobody apparently caring enough.

Doesn't this argue that it is not as important to pre-screen as we think
it is, given that this has happened multiple times and none of the
horrible consequences from which pre-screening is intended to protect us
have occurred?  (I know the argument is that we've just gotten lucky, but
I think it's worth being careful of that argument since it's inherently
irrefutable.  "We have to do this thing because horrible things will
happen if we don't, and those horrible things have never happened in the
past only because we've gotten lucky" is a circular argument that cannot
be disproven, and therefore we should be a bit skeptical about it.)

What if we took all the effort we put into pre-screening and instead
devoted it to resolving actual problems that have been reported to us?  Is
it possible that would resolve our legal issues *faster* than investing
huge amounts of project time and resources into pre-screening?

This is the point that this same argument for pre-screening could be made
about *any* bug.  For *any* type of bug, doing additional pre-screening
will reduce the incidence of that bug.  The question is whether that's the
most effective use of resources, not whether it has any positive effect at
all.  Clearly it does help, but does it help more than other things we
could be doing with the same time and energy?

The counterfactual is not "Debian stops caring about legal issues at all."
The alternative is instead "the primary responsibility for legal issues
lies with the person uploading the package, here are the rules that we
follow, we encourage audits and other analysis and will automate them to
the degree possible, and if anyone reports a copyright or licensing bug,
w

Re: 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))

2022-01-30 Thread Francesco Poli 
On Wed, 26 Jan 2022 07:38:10 +0100 Andreas Tille wrote:

> Am Tue, Jan 25, 2022 at 01:45:11PM -0800 schrieb Russ Allbery:
[...]
> > 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?

I thought the basis was the fact that copyright and licensing bugs may
have bad legal consequences (lawsuits against the Project for
distributing legally undistributable packages, things like that), while
technical bugs do not cause issues with lawyers and are, in this sense,
"easier" to fix.
The consequences of introducing a "legally botched" package into the
archive are thus harder to undo, with respect to introducing a
technically flawed package...

> > 
> > 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?

I am under the impression that the pre-screening in the NEW queue is an
attempt to catch legal issues *before* the package is introduced into
the archive.
As far as I remember, the FTP masters are the people responsible for
what the Debian Project distributes through its archive...

Is this wrong (or no longer valid)?

[...]
> > 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).

Personally, I think the legal pre-screening by the FTP masters in the
NEW queue is useful and should be kept.

In fact, I wish the pre-screening were stricter.

I've seen cases, where a bug is reported against a legally
undistributable package and the issue is left unaddressed for ages with
nobody apparently caring enough.
Maybe it's better, if such issues are addressed *before* the package is
accepted into the archive...


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpWiRMgvfmm3.pgp
Description: PGP signature

Re: 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))

2022-01-26 Thread Philip Hands 
Andreas Tille  writes:

...
> 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 have a repository on salsa: 
https://salsa.debian.org/installer-team/branch2repo
that allows one to easily take a collection of branches (with the same
branch name) from several repos, and assemble the (u)debs that one can
build from all those branches into an apt repo.

The motivation for that is for testing patches to Debian-Installer, but
it should work for anything, so if that (or something like it) got
merged into the main salsa-CI pipeline then people could more easily
decouple the testing of new packages from their progress through NEW.

This does of course raise the question of whether I ought to be able to
do that, since it creates apt repos, such as this (trivial) example:

  
https://salsa.debian.org/installer-team/branch2repo/-/jobs/2365384/artifacts/browse/public/

that publish .debs from a debian.org host, that could easily be created
from sources that have never been near NEW.

Of course, the URL is not exactly obvious there, and the artifacts will
get deleted, so maybe that's a difference, but I don't suppose it would
be too hard to make that into a stable 'pages' URL and ensure that it
got built often enough to keep the repo there permanently.  Would that
cross the line?

I think the important distinction is probably that once packages get
through NEW they are mirrored all over the world, by unsuspecting third
parties, who live in every jurisdiction under the sun. They are also
incorporated into down-stream distros, often with little/no manual
oversight, some of whom then do things like selling their resulting
distribution for profit.

That involves other people in a lot of risks that might not apply to
Debian itself, so I'd suggest requires rather more caution than trying
to see what we alone can expect to get away with.

Do we need to shut down salsa's ability to do the above (given that one
can do all of that from a guest account, using any old code you
uploaded), or is that OK because the URLs are unstable and/or obscure?
(obviously, given that I did it, I think it's OK)

If obscure URLs are enough, I'd think it would be OK to have things in
the NEW queue available from repo URLs that were not something that one
could easily mirror, and would not be an "all of current NEW repo" but
rather something like an apt repo per upload, so that one could easily
test stuff stuck in NEW, but wouldn't be tempted to just install
everything that hits NEW by default.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

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))

2022-01-25 Thread Andreas Tille 
Am Tue, Jan 25, 2022 at 01:45:11PM -0800 schrieb Russ Allbery:
> Jonas Smedegaard  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