Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3731005imm; Mon, 8 Oct 2018 08:38:25 -0700 (PDT) X-Google-Smtp-Source: ACcGV61ob3AT10WLLynrnJVoPlHP9kLBrzcyK4nVy7NWJ4/o6xos61H77mkD51YXncFWjw/OBTWI X-Received: by 2002:a63:f347:: with SMTP id t7-v6mr21135403pgj.255.1539013104943; Mon, 08 Oct 2018 08:38:24 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1539013104; cv=none; d=google.com; s=arc-20160816; b=nHg2KC8v7Ll/FYQzHzCKMYxM0ijVIECMNvzw0UDY60a5AXJP6U985sJhF3Ng7XJCzj sEBmRZF7/latRHWxjNaU3sNQZFzbNciZuU/4/pKITDuDtu0yOpu0V92f/gZPlztob/j1 aMtH4NYpZuZ8YLLQGgd0CW3SIaproxsyEQwyPf+NKnFNVWgvitVZsejbjzFg2XYXh8fN ZABtzVYZ4eX9x/1bEy7Ibc+DpyveRF5sxrGYsZ0vSPcbhPgQ5ch7qp4uVc8DXyEXL1H+ TAG5IH0raGmMgiFpB5jC+D06m6euEA4FSVz5p4Pl5n28Wh7DLheDL32SjaJESHHZN4h6 2Ylw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=wc+oIseG7OT8qXKc6nfLR/l1T9EYJlCmR0K46gtu3YU=; b=nobPRQhTom1oeY3EcZjWHsEegqp5yl3WIxjdxf8dUkHJ8OSgDymg9SLbuzCPcuCeh+ aZH/Z2R2oaAu4NAuRbv8NTQaZXp8RlTvkvZH7q2dSTWK3B1riWB59vQ5FG8eH6mAEKLx 5uBnUGPv9YNsoiZ+5bqx6ElU7FrSveFkZyOpxAi6aekR1Iu1V+RPL0+TD6B0ZRF/mhNs 4EXLfKVM62FCU26xfVL6vp5wUMPivNvHp4tBBtlYl0xrc5jsmtYW/dFpd5q0YTlPehFD 0nMvWKWM/BXaUFvCZZw35QpVWSBkvTq0E9SH1c2GG0MNflHRBmZOJxHC2K+Heqbv0OFc dYUg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a16-v6si16341797pgw.187.2018.10.08.08.38.09; Mon, 08 Oct 2018 08:38:24 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727879AbeJHWuS (ORCPT + 99 others); Mon, 8 Oct 2018 18:50:18 -0400 Received: from www.llwyncelyn.cymru ([82.70.14.225]:51716 "EHLO fuzix.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726679AbeJHWuR (ORCPT ); Mon, 8 Oct 2018 18:50:17 -0400 Received: from alans-desktop (82-70-14-226.dsl.in-addr.zen.co.uk [82.70.14.226]) by fuzix.org (8.15.2/8.15.2) with ESMTP id w98Fbn4c013828; Mon, 8 Oct 2018 16:37:49 +0100 Date: Mon, 8 Oct 2018 16:37:48 +0100 From: Alan Cox To: James Bottomley Cc: Tim.Bird@sony.com, ksummit-discuss@lists.linuxfoundation.org, linux-kernel@vger.kernel.org Subject: Re: [Ksummit-discuss] [PATCH 2/2] code-of-conduct: Strip the enforcement paragraph pending community discussion Message-ID: <20181008163748.0e68cba5@alans-desktop> In-Reply-To: <1538883209.4088.14.camel@HansenPartnership.com> References: <1538861738.4088.5.camel@HansenPartnership.com> <1538861851.4088.7.camel@HansenPartnership.com> <1538883209.4088.14.camel@HansenPartnership.com> Organization: Intel Corporation X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > I happen to think that the fact that the TAB cannot compel where it > cannot persuade is a huge strength of the system because it means > there's no power structure to subvert if someone were interested in > using it to try to impose their own viewpoint on the community. But > that's just my opinion and I did write the TAB charter, so I'm probably > biased in this viewpoint. The TAB can't handle it anyway because the privacy promise about reporting is incompatible with reality for three reasons (and I bet there are more) 1. Things like the EUCD can force almost all but the name to be revealed to the person complained about as the tab has no legal privilege. 2. There are lots of laws in lots of locations where some allegations *MUST* be reported to law enforcement. 3. We know from things like the catholic church debacle that serious allegations need to be fast-pathed to the legal system - yet the privacy promises are incompatible with that. It ever got really nasty then the scenario that unfolds is potentially the following Developer A makes a complaint about developer B Developer B's employer fires developer B Developer B then uses things like the EUCD to force the TAB to provide the complaint details (with personal data redacted) and the TAB has no real defence as it's not legally privileged. Developer B then sues developer A, the TAB for all sorts of things, the LF and their employer. In court what's going to happen to the TAB ? = Where is your written policy ? = Who approved it and reviewed it for legal compliance ? = What are your qualifications in this area ? = Where are the full minutes of the decision ? = Which of you work for rival companies ? = What personal connections do or your frends have to A and B ? Needless to say answers like 'we don't have one, nobody, none, umm I think there's an email thread' are not going to go down well. This sort of mess works with big company HR departments because they've got lawyers and they have lots of written process. If it hits a court then B's employer is able to point at all their rules and policies, employment contracts etc. All of the decisions were either legally privileged or minuted properly. The people who made the decisions have appropriate professional qualifications. The TAB can't enforce anything. If maintainers decide to carry on accepting patches from someone what can they do ? So both patches: Reviewed-by: Alan Cox