Hi all,
As everyone knows by now, we added a new Code of Conduct to the kernel
tree a few weeks ago.
When we did this, it raised a number of questions as to how this would
affect the kernel community. To help address these issues, I, and a few
other kernel developers including the TAB, have come up with the
following patch series to be added to the tree to both modify the
existing Code of Conduct to remove a confusing paragraph as well as to
add a new document to help explain how the Code of Conduct is to be
interpreted by our community.
I originally sent the first two patches in this series to a lot of
kernel developers privately, to get their review and comments and see if
they wanted to ack them. This is the traditional way we have always
done for policy documents or other "contentious" issues like the GPLv3
statement or the "closed kernel modules are bad" statement. Due to the
very unexpected way that the original Code of Conduct file was added to
the tree, a number of developers asked if this series could also be
posted publicly before they were merged, and so, here they are.
This patch series adds this new document to the kernel tree, as well as
removes a paragraph from the existing Code of Conduct that was
bothersome to many maintainers. It also does a bit of housekeeping
around these documents to get the documentation links correct as well as
fix up the email address and other links and add a MAINTAINER entry for
the files.
Also I would like to publicly thank Mishi Choudhary for being willing to
serve as a mediator for Code of Conduct issues. She has a long history
of working in many open source communities, many much more contentious
than ours. For more information about her, please see her wikipedia
entry:
https://en.wikipedia.org/wiki/Mishi_Choudhary
or take the chance to talk with her at the Plumbers conference in a few
weeks, as she will be attending that along with almost everyone on the
TAB as well as many kernel developers and maintainers, myself included.
thanks,
greg k-h
Chris Mason (1):
Code of conduct: Fix wording around maintainers enforcing the code of
conduct
Greg Kroah-Hartman (6):
Code of Conduct Interpretation: Add document explaining how the Code
of Conduct is to be interpreted
Code of Conduct Interpretation: Properly reference the TAB correctly
Code of Conduct: Provide links between the two documents
Code of Conduct Interpretation: Put in the proper URL for the
committee
Code of Conduct: Change the contact email address
MAINTAINERS: Add an entry for the code of conduct
.../code-of-conduct-interpretation.rst | 156 ++++++++++++++++++
Documentation/process/code-of-conduct.rst | 25 +--
Documentation/process/index.rst | 1 +
MAINTAINERS | 6 +
4 files changed, 178 insertions(+), 10 deletions(-)
create mode 100644 Documentation/process/code-of-conduct-interpretation.rst
--
2.19.1
From: Chris Mason <[email protected]>
As it was originally worded, this paragraph requires maintainers to
enforce the code of conduct, or face potential repercussions. It sends
the wrong message, when really we just want maintainers to be part of
the solution and not violate the code of conduct themselves.
Removing it doesn't limit our ability to enforce the code of conduct,
and we can still encourage maintainers to help maintain high standards
for the level of discourse in their subsystem.
Signed-off-by: Chris Mason <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Acked-by: Amir Goldstein <[email protected]>
Acked-by: Andrew Morton <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Acked-by: Benjamin Herrenschmidt <[email protected]>
Acked-by: Boris Brezillon <[email protected]>
Acked-by: Borislav Petkov <[email protected]>
Acked-by: Christian Lütke-Stetzkamp <[email protected]>
Acked-by: Christoph Hellwig <[email protected]>
Acked-by: Colin Ian King <[email protected]>
Acked-by: Dan Carpenter <[email protected]>
Acked-by: Dan Williams <[email protected]>
Acked-by: Daniel Borkmann <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Acked-by: Dave Hansen <[email protected]>
Acked-by: David Ahern <[email protected]>
Acked-by: David Sterba <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
Acked-by: Felipe Balbi <[email protected]>
Acked-by: Felix Kuehling <[email protected]>
Acked-by: Florian Fainelli <[email protected]>
Acked-by: Florian Westphal <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Acked-by: Gregory CLEMENT <[email protected]>
Acked-by: Guenter Roeck <[email protected]>
Acked-by: Gustavo A. R. Silva <[email protected]>
Acked-by: Hans Verkuil <[email protected]>
Acked-by: Hans de Goede <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Acked-by: Heiko Stuebner <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
Acked-by: Jaegeuk Kim <[email protected]>
Acked-by: James Smart <[email protected]>
Acked-by: James Smart <[email protected]>
Acked-by: Jan Kara <[email protected]>
Acked-by: Jason A. Donenfeld <[email protected]>
Acked-by: Jeff Kirsher <[email protected]>
Acked-by: Jens Axboe <[email protected]>
Acked-by: Jessica Yu <[email protected]>
Acked-by: Jia-Ju Bai <[email protected]>
Acked-by: Jiri Kosina <[email protected]>
Acked-by: Jiri Olsa <[email protected]>
Acked-by: Joerg Roedel <[email protected]>
Acked-by: Johan Hovold <[email protected]>
Acked-by: Johannes Thumshirn <[email protected]>
Acked-by: Jonathan Corbet <[email protected]>
Acked-by: Julia Lawall <[email protected]>
Acked-by: Kees Cook <[email protected]>
Acked-by: Kirill Tkhai <[email protected]>
Acked-by: Kuninori Morimoto <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
Acked-by: Lina Iyer <[email protected]>
Acked-by: Linus Torvalds <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Acked-by: Mark Brown <[email protected]>
Acked-by: Masahiro Yamada <[email protected]>
Acked-by: Masami Hiramatsu <[email protected]>
Acked-by: Matias Bjørling <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Acked-by: Michael Ellerman <[email protected]>
Acked-by: Mimi Zohar <[email protected]>
Acked-by: Miquel Raynal <[email protected]>
Acked-by: Nikolay Borisov <[email protected]>
Acked-by: Oded Gabbay <[email protected]>
Acked-by: Olof Johansson <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
Acked-by: Paul E. McKenney <[email protected]>
Acked-by: Peter Zijlstra <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Acked-by: Richard Weinberger <[email protected]>
Acked-by: Rik van Riel <[email protected]>
Acked-by: Rob Clark <[email protected]>
Acked-by: Rob Herring <[email protected]>
Acked-by: Rodrigo Vivi <[email protected]>
Acked-by: Sebastian Andrzej Siewior <[email protected]>
Acked-by: Sebastian Reichel <[email protected]>
Acked-by: Sergio Paracuellos <[email protected]>
Acked-by: Shawn Guo <[email protected]>
Acked-by: Shuah Khan <[email protected]>
Acked-by: Simon Horman <[email protected]>
Acked-by: Srinivas Kandagatla <[email protected]>
Acked-by: Stephen Hemminger <[email protected]>
Acked-by: Takashi Iwai <[email protected]>
Acked-by: Tejun Heo <[email protected]>
Acked-by: Theodore Ts'o <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Acked-by: Tim Bird <[email protected]>
Acked-by: Todd Poynor <[email protected]>
Acked-by: Wei Yongjun <[email protected]>
Acked-by: YueHaibing <[email protected]>
Reviewed-by: Mauro Carvalho Chehab <[email protected]>
Reviewed-by: Steven Rostedt <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
Documentation/process/code-of-conduct.rst | 4 ----
1 file changed, 4 deletions(-)
diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index ab7c24b5478c..a2641c19cf26 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -70,10 +70,6 @@ appropriate to the circumstances. The TAB is obligated to maintain
confidentiality with regard to the reporter of an incident. Further details of
specific enforcement policies may be posted separately.
-Maintainers who do not follow or enforce the Code of Conduct in good faith may
-face temporary or permanent repercussions as determined by other members of the
-project’s leadership.
-
Attribution
===========
--
2.19.1
We use the term "TAB" before defining it later in the document. Fix
that up by defining it at the first location.
Reported-by: Kuninori Morimoto <[email protected]>
Acked-by: Chris Mason <[email protected]>
Acked-by: Olof Johansson <[email protected]>
Acked-by: Theodore Ts'o <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
.../process/code-of-conduct-interpretation.rst | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/process/code-of-conduct-interpretation.rst b/Documentation/process/code-of-conduct-interpretation.rst
index b14441711f7b..ecf84cd29735 100644
--- a/Documentation/process/code-of-conduct-interpretation.rst
+++ b/Documentation/process/code-of-conduct-interpretation.rst
@@ -45,11 +45,11 @@ regarding conduct issues.
Maintainers should be willing to help when problems occur, and work with
others in the community when needed. Do not be afraid to reach out to
-the TAB or other maintainers if you're uncertain how to handle
-situations that come up. It will not be considered a violation report
-unless you want it to be. If you are uncertain about approaching the
-TAB or any other maintainers, please reach out to our conflict mediator,
-Mishi Choudhary <[email protected]>.
+the Technical Advisory Board (TAB) or other maintainers if you're
+uncertain how to handle situations that come up. It will not be
+considered a violation report unless you want it to be. If you are
+uncertain about approaching the TAB or any other maintainers, please
+reach out to our conflict mediator, Mishi Choudhary <[email protected]>.
In the end, "be kind to each other" is really what the end goal is for
everybody. We know everyone is human and we all fail at times, but the
@@ -125,9 +125,9 @@ are listed at <URL>. Members can not access reports made before they
joined or after they have left the committee.
The initial Code of Conduct Committee consists of volunteer members of
-the Technical Advisory Board (TAB), as well as a professional mediator
-acting as a neutral third party. The first task of the committee is to
-establish documented processes, which will be made public.
+the TAB, as well as a professional mediator acting as a neutral third
+party. The first task of the committee is to establish documented
+processes, which will be made public.
Any member of the committee, including the mediator, can be contacted
directly if a reporter does not wish to include the full committee in a
--
2.19.1
Create a link between the Code of Conduct and the Code of Conduct
Interpretation so that people can see that they are related.
Acked-by: Chris Mason <[email protected]>
Acked-by: Olof Johansson <[email protected]>
Acked-by: Theodore Ts'o <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
Documentation/process/code-of-conduct-interpretation.rst | 4 +++-
Documentation/process/code-of-conduct.rst | 8 ++++++++
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/Documentation/process/code-of-conduct-interpretation.rst b/Documentation/process/code-of-conduct-interpretation.rst
index ecf84cd29735..4d4e2cc94b5e 100644
--- a/Documentation/process/code-of-conduct-interpretation.rst
+++ b/Documentation/process/code-of-conduct-interpretation.rst
@@ -1,7 +1,9 @@
+.. _code_of_conduct_interpretation:
+
Linux Kernel Contributor Covenant Code of Conduct Interpretation
================================================================
-The Contributor Covenant Code of Conduct is a general document meant to
+The :ref:`code_of_conduct` is a general document meant to
provide a set of rules for almost any open source community. Every
open-source community is unique and the Linux kernel is no exception.
Because of this, this document describes how we in the Linux kernel
diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index a2641c19cf26..3046664c929e 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -1,3 +1,5 @@
+.. _code_of_conduct:
+
Contributor Covenant Code of Conduct
++++++++++++++++++++++++++++++++++++
@@ -75,3 +77,9 @@ Attribution
This Code of Conduct is adapted from the Contributor Covenant, version 1.4,
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+Interpretation
+==============
+
+See the :ref:`code_of_conduct_interpretation` document for how the Linux
+kernel community will be interpreting this document.
--
2.19.1
The contact point for the kernel's Code of Conduct should now be the
Code of Conduct Committee, not the full TAB. Change the email address
in the file to properly reflect this.
Acked-by: Chris Mason <[email protected]>
Acked-by: Olof Johansson <[email protected]>
Acked-by: Theodore Ts'o <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
Documentation/process/code-of-conduct.rst | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index 3046664c929e..be50294aebd5 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -65,12 +65,13 @@ Enforcement
===========
Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the Technical Advisory Board (TAB) at
-<[email protected]>. All complaints will be reviewed and
-investigated and will result in a response that is deemed necessary and
-appropriate to the circumstances. The TAB is obligated to maintain
-confidentiality with regard to the reporter of an incident. Further details of
-specific enforcement policies may be posted separately.
+reported by contacting the Code of Conduct Committee at
+<[email protected]>. All complaints will be reviewed and investigated
+and will result in a response that is deemed necessary and appropriate
+to the circumstances. The Code of Conduct Committee is obligated to
+maintain confidentiality with regard to the reporter of an incident.
+Further details of specific enforcement policies may be posted
+separately.
Attribution
===========
--
2.19.1
As I introduced these files, I'm willing to be the maintainer of them as
well.
Acked-by: Chris Mason <[email protected]>
Acked-by: Olof Johansson <[email protected]>
Acked-by: Steven Rostedt (VMware) <[email protected]>
Acked-by: Theodore Ts'o <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
MAINTAINERS | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 7f371d372bdd..21faaf4c6161 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -3673,6 +3673,12 @@ S: Maintained
F: Documentation/devicetree/bindings/media/coda.txt
F: drivers/media/platform/coda/
+CODE OF CONDUCT
+M: Greg Kroah-Hartman <[email protected]>
+S: Supported
+F: Documentation/process/code-of-conduct.rst
+F: Documentation/process/code-of-conduct-interpretation.rst
+
COMMON CLK FRAMEWORK
M: Michael Turquette <[email protected]>
M: Stephen Boyd <[email protected]>
--
2.19.1
There was a blank <URL> reference for how to find the Code of Conduct
Committee. Fix that up by pointing it to the correct kernel.org website
page location.
Acked-by: Chris Mason <[email protected]>
Acked-by: Olof Johansson <[email protected]>
Acked-by: Theodore Ts'o <[email protected]>
Acked-by: Thomas Gleixner <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
Documentation/process/code-of-conduct-interpretation.rst | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/process/code-of-conduct-interpretation.rst b/Documentation/process/code-of-conduct-interpretation.rst
index 4d4e2cc94b5e..e899f14a4ba2 100644
--- a/Documentation/process/code-of-conduct-interpretation.rst
+++ b/Documentation/process/code-of-conduct-interpretation.rst
@@ -123,8 +123,9 @@ Enforcement
The address listed in the Code of Conduct goes to the Code of Conduct
Committee. The exact members receiving these emails at any given time
-are listed at <URL>. Members can not access reports made before they
-joined or after they have left the committee.
+are listed at https://kernel.org/code-of-conduct.html. Members can not
+access reports made before they joined or after they have left the
+committee.
The initial Code of Conduct Committee consists of volunteer members of
the TAB, as well as a professional mediator acting as a neutral third
--
2.19.1
The Contributor Covenant Code of Conduct is a general document meant to
provide a set of rules for almost any open source community. Every
open-source community is unique and the Linux kernel is no exception.
Because of this, this document describes how we in the Linux kernel
community will interpret it. We also do not expect this interpretation
to be static over time, and will adjust it as needed.
This document was created with the input and feedback of the TAB as well
as many current kernel maintainers.
Co-Developed-by: Thomas Gleixner <[email protected]>
Co-Developed-by: Olof Johansson <[email protected]>
Acked-by: Alex Deucher <[email protected]>
Acked-by: Alexei Starovoitov <[email protected]>
Acked-by: Amir Goldstein <[email protected]>
Acked-by: Andrew Morton <[email protected]>
Acked-by: Andy Lutomirski <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Acked-by: Benjamin Herrenschmidt <[email protected]>
Acked-by: Boris Brezillon <[email protected]>
Acked-by: Borislav Petkov <[email protected]>
Acked-by: Chris Mason <[email protected]>
Acked-by: Christian L?tke-Stetzkamp <[email protected]>
Acked-by: Colin Ian King <[email protected]>
Acked-by: Dan Carpenter <[email protected]>
Acked-by: Dan Williams <[email protected]>
Acked-by: Daniel Borkmann <[email protected]>
Acked-by: Daniel Vetter <[email protected]>
Acked-by: Dave Airlie <[email protected]>
Acked-by: Dave Hansen <[email protected]>
Acked-by: David Ahern <[email protected]>
Acked-by: David Sterba <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]>
Acked-by: Eric Dumazet <[email protected]>
Acked-by: Felipe Balbi <[email protected]>
Acked-by: Felix Kuehling <[email protected]>
Acked-by: Florian Fainelli <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Acked-by: Gregory CLEMENT <[email protected]>
Acked-by: Guenter Roeck <[email protected]>
Acked-by: Gustavo A. R. Silva <[email protected]>
Acked-by: Hans Verkuil <[email protected]>
Acked-by: Hans de Goede <[email protected]>
Acked-by: Harry Wentland <[email protected]>
Acked-by: Heiko Stuebner <[email protected]>
Acked-by: Ingo Molnar <[email protected]>
Acked-by: Jaegeuk Kim <[email protected]>
Acked-by: James Smart <[email protected]>
Acked-by: James Smart <[email protected]>
Acked-by: Jan Kara <[email protected]>
Acked-by: Jani Nikula <[email protected]>
Acked-by: Jason A. Donenfeld <[email protected]>
Acked-by: Jeff Kirsher <[email protected]>
Acked-by: Jens Axboe <[email protected]>
Acked-by: Jessica Yu <[email protected]>
Acked-by: Jia-Ju Bai <[email protected]>
Acked-by: Jiri Kosina <[email protected]>
Acked-by: Jiri Olsa <[email protected]>
Acked-by: Joerg Roedel <[email protected]>
Acked-by: Johan Hovold <[email protected]>
Acked-by: Johannes Thumshirn <[email protected]>
Acked-by: Jonathan Corbet <[email protected]>
Acked-by: Julia Lawall <[email protected]>
Acked-by: Kees Cook <[email protected]>
Acked-by: Kirill Tkhai <[email protected]>
Acked-by: Kuninori Morimoto <[email protected]>
Acked-by: Laurent Pinchart <[email protected]>
Acked-by: Lina Iyer <[email protected]>
Acked-by: Linus Torvalds <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Acked-by: Mark Brown <[email protected]>
Acked-by: Masahiro Yamada <[email protected]>
Acked-by: Masami Hiramatsu <[email protected]>
Acked-by: Matias Bj?rling <[email protected]>
Acked-by: Mauro Carvalho Chehab <[email protected]>
Acked-by: Maxime Ripard <[email protected]>
Acked-by: Michael Ellerman <[email protected]>
Acked-by: Mimi Zohar <[email protected]>
Acked-by: Miquel Raynal <[email protected]>
Acked-by: Mishi Choudhary <[email protected]>
Acked-by: Nikolay Borisov <[email protected]>
Acked-by: Oded Gabbay <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
Acked-by: Paul E. McKenney <[email protected]>
Acked-by: Peter Zijlstra <[email protected]>
Acked-by: Rafael J. Wysocki <[email protected]>
Acked-by: Richard Weinberger <[email protected]>
Acked-by: Rik van Riel <[email protected]>
Acked-by: Rob Clark <[email protected]>
Acked-by: Rob Herring <[email protected]>
Acked-by: Rodrigo Vivi <[email protected]>
Acked-by: Sean Paul <[email protected]>
Acked-by: Sebastian Andrzej Siewior <[email protected]>
Acked-by: Sebastian Reichel <[email protected]>
Acked-by: Sergio Paracuellos <[email protected]>
Acked-by: Shawn Guo <[email protected]>
Acked-by: Shuah Khan <[email protected]>
Acked-by: Simon Horman <[email protected]>
Acked-by: Srinivas Kandagatla <[email protected]>
Acked-by: Stephen Hemminger <[email protected]>
Acked-by: Takashi Iwai <[email protected]>
Acked-by: Tejun Heo <[email protected]>
Acked-by: Theodore Ts'o <[email protected]>
Acked-by: Thierry Reding <[email protected]>
Acked-by: Todd Poynor <[email protected]>
Acked-by: Wei Yongjun <[email protected]>
Acked-by: YueHaibing <[email protected]>
Reviewed-by: Steven Rostedt <[email protected]>
Signed-off-by: Thomas Gleixner <[email protected]>
Signed-off-by: Olof Johansson <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
---
.../code-of-conduct-interpretation.rst | 153 ++++++++++++++++++
Documentation/process/index.rst | 1 +
2 files changed, 154 insertions(+)
create mode 100644 Documentation/process/code-of-conduct-interpretation.rst
diff --git a/Documentation/process/code-of-conduct-interpretation.rst b/Documentation/process/code-of-conduct-interpretation.rst
new file mode 100644
index 000000000000..b14441711f7b
--- /dev/null
+++ b/Documentation/process/code-of-conduct-interpretation.rst
@@ -0,0 +1,153 @@
+Linux Kernel Contributor Covenant Code of Conduct Interpretation
+================================================================
+
+The Contributor Covenant Code of Conduct is a general document meant to
+provide a set of rules for almost any open source community. Every
+open-source community is unique and the Linux kernel is no exception.
+Because of this, this document describes how we in the Linux kernel
+community will interpret it. We also do not expect this interpretation
+to be static over time, and will adjust it as needed.
+
+The Linux kernel development effort is a very personal process compared
+to "traditional" ways of developing software. Your contributions and
+ideas behind them will be carefully reviewed, often resulting in
+critique and criticism. The review will almost always require
+improvements before the material can be included in the
+kernel. Know that this happens because everyone involved wants to see
+the best possible solution for the overall success of Linux. This
+development process has been proven to create the most robust operating
+system kernel ever, and we do not want to do anything to cause the
+quality of submission and eventual result to ever decrease.
+
+Maintainers
+-----------
+
+The Code of Conduct uses the term "maintainers" numerous times. In the
+kernel community, a "maintainer" is anyone who is responsible for a
+subsystem, driver, or file, and is listed in the MAINTAINERS file in the
+kernel source tree.
+
+Responsibilities
+----------------
+
+The Code of Conduct mentions rights and responsibilities for
+maintainers, and this needs some further clarifications.
+
+First and foremost, it is a reasonable expectation to have maintainers
+lead by example.
+
+That being said, our community is vast and broad, and there is no new
+requirement for maintainers to unilaterally handle how other people
+behave in the parts of the community where they are active. That
+responsibility is upon all of us, and ultimately the Code of Conduct
+documents final escalation paths in case of unresolved concerns
+regarding conduct issues.
+
+Maintainers should be willing to help when problems occur, and work with
+others in the community when needed. Do not be afraid to reach out to
+the TAB or other maintainers if you're uncertain how to handle
+situations that come up. It will not be considered a violation report
+unless you want it to be. If you are uncertain about approaching the
+TAB or any other maintainers, please reach out to our conflict mediator,
+Mishi Choudhary <[email protected]>.
+
+In the end, "be kind to each other" is really what the end goal is for
+everybody. We know everyone is human and we all fail at times, but the
+primary goal for all of us should be to work toward amicable resolutions
+of problems. Enforcement of the code of conduct will only be a last
+resort option.
+
+Our goal of creating a robust and technically advanced operating system
+and the technical complexity involved naturally require expertise and
+decision-making.
+
+The required expertise varies depending on the area of contribution. It
+is determined mainly by context and technical complexity and only
+secondary by the expectations of contributors and maintainers.
+
+Both the expertise expectations and decision-making are subject to
+discussion, but at the very end there is a basic necessity to be able to
+make decisions in order to make progress. This prerogative is in the
+hands of maintainers and project's leadership and is expected to be used
+in good faith.
+
+As a consequence, setting expertise expectations, making decisions and
+rejecting unsuitable contributions are not viewed as a violation of the
+Code of Conduct.
+
+While maintainers are in general welcoming to newcomers, their capacity
+of helping contributors overcome the entry hurdles is limited, so they
+have to set priorities. This, also, is not to be seen as a violation of
+the Code of Conduct. The kernel community is aware of that and provides
+entry level programs in various forms like kernelnewbies.org.
+
+Scope
+-----
+
+The Linux kernel community primarily interacts on a set of public email
+lists distributed around a number of different servers controlled by a
+number of different companies or individuals. All of these lists are
+defined in the MAINTAINERS file in the kernel source tree. Any emails
+sent to those mailing lists are considered covered by the Code of
+Conduct.
+
+Developers who use the kernel.org bugzilla, and other subsystem bugzilla
+or bug tracking tools should follow the guidelines of the Code of
+Conduct. The Linux kernel community does not have an "official" project
+email address, or "official" social media address. Any activity
+performed using a kernel.org email account must follow the Code of
+Conduct as published for kernel.org, just as any individual using a
+corporate email account must follow the specific rules of that
+corporation.
+
+The Code of Conduct does not prohibit continuing to include names, email
+addresses, and associated comments in mailing list messages, kernel
+change log messages, or code comments.
+
+Interaction in other forums is covered by whatever rules apply to said
+forums and is in general not covered by the Code of Conduct. Exceptions
+may be considered for extreme circumstances.
+
+Contributions submitted for the kernel should use appropriate language.
+Content that already exists predating the Code of Conduct will not be
+addressed now as a violation. Inappropriate language can be seen as a
+bug, though; such bugs will be fixed more quickly if any interested
+parties submit patches to that effect. Expressions that are currently
+part of the user/kernel API, or reflect terminology used in published
+standards or specifications, are not considered bugs.
+
+Enforcement
+-----------
+
+The address listed in the Code of Conduct goes to the Code of Conduct
+Committee. The exact members receiving these emails at any given time
+are listed at <URL>. Members can not access reports made before they
+joined or after they have left the committee.
+
+The initial Code of Conduct Committee consists of volunteer members of
+the Technical Advisory Board (TAB), as well as a professional mediator
+acting as a neutral third party. The first task of the committee is to
+establish documented processes, which will be made public.
+
+Any member of the committee, including the mediator, can be contacted
+directly if a reporter does not wish to include the full committee in a
+complaint or concern.
+
+The Code of Conduct Committee reviews the cases according to the
+processes (see above) and consults with the TAB as needed and
+appropriate, for instance to request and receive information about the
+kernel community.
+
+Any decisions by the committee will be brought to the TAB, for
+implementation of enforcement with the relevant maintainers if needed.
+A decision by the Code of Conduct Committee can be overturned by the TAB
+by a two-thirds vote.
+
+At quarterly intervals, the Code of Conduct Committee and TAB will
+provide a report summarizing the anonymised reports that the Code of
+Conduct committee has received and their status, as well details of any
+overridden decisions including complete and identifiable voting details.
+
+We expect to establish a different process for Code of Conduct Committee
+staffing beyond the bootstrap period. This document will be updated
+with that information when this occurs.
diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
index 9ae3e317bddf..42691e2880eb 100644
--- a/Documentation/process/index.rst
+++ b/Documentation/process/index.rst
@@ -21,6 +21,7 @@ Below are the essential guides that every developer should read.
howto
code-of-conduct
+ code-of-conduct-interpretation
development-process
submitting-patches
coding-style
--
2.19.1
> +to the circumstances. The Code of Conduct Committee is obligated to
> +maintain confidentiality with regard to the reporter of an incident.
> +Further details of specific enforcement policies may be posted
> +separately.
Unfortunately by ignoring the other suggestions on this you've left this
bit broken.
The committee can't keep most stuff confidential so it's misleading and
wrong to imply they can. Data protection law, reporting laws in some
countries and the like mean that anyone expecting an incident to remain
confidential from the person it was reported against is living in
dreamland and are going to get a nasty shock.
At the very least it should say '(except where required by law)'.
There is a separate issue that serious things should always go to law
enforcement - you are setting up a policy akin to the one that got the
catholic church and many others in trouble.
You should also reserving the right to report serious incidents directly
to law enforcement. Unless of course you want to be forced to sit on
multiple reports of physical abuse from different people about
someone - unable to tell them about each others report, unable to prove
anything, and in twenty years time having to explain to the media why
nothing was done.
Alan
On Sat, 2018-10-20 at 19:28 +0100, Alan Cox wrote:
> > +to the circumstances. The Code of Conduct Committee is obligated
> > to
> > +maintain confidentiality with regard to the reporter of an
> > incident.
> > +Further details of specific enforcement policies may be posted
> > +separately.
>
> Unfortunately by ignoring the other suggestions on this you've left
> this
> bit broken.
>
> The committee can't keep most stuff confidential so it's misleading
> and
> wrong to imply they can. Data protection law, reporting laws in some
> countries and the like mean that anyone expecting an incident to
> remain
> confidential from the person it was reported against is living in
> dreamland and are going to get a nasty shock.
>
> At the very least it should say '(except where required by law)'.
>
> There is a separate issue that serious things should always go to law
> enforcement - you are setting up a policy akin to the one that got
> the
> catholic church and many others in trouble.
>
> You should also reserving the right to report serious incidents
> directly
> to law enforcement. Unless of course you want to be forced to sit on
> multiple reports of physical abuse from different people about
> someone - unable to tell them about each others report, unable to
> prove
> anything, and in twenty years time having to explain to the media why
> nothing was done.
>
...and then you get into questions about how this committee will
respond to queries from said law enforcement, and indeed to which legal
systems the committee will or will not report incidents.
Why would we want to be going down the path of trying to handle reports
about "serious incidents" in the first place? That seems way out of
scope for a code of conduct arbitration scheme. Even attempting to
counsel people as to whether or not they should report incidents can
get you in trouble in many parts of the world.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
[email protected]
Hi Greg,
On Sat, Oct 20, 2018 at 3:53 PM Greg Kroah-Hartman
<[email protected]> wrote:
> There was a blank <URL> reference for how to find the Code of Conduct
> Committee. Fix that up by pointing it to the correct kernel.org website
> page location.
>
> Acked-by: Chris Mason <[email protected]>
> Acked-by: Olof Johansson <[email protected]>
> Acked-by: Theodore Ts'o <[email protected]>
> Acked-by: Thomas Gleixner <[email protected]>
> Signed-off-by: Greg Kroah-Hartman <[email protected]>
Thanks for your patch!
> --- a/Documentation/process/code-of-conduct-interpretation.rst
> +++ b/Documentation/process/code-of-conduct-interpretation.rst
> @@ -123,8 +123,9 @@ Enforcement
>
> The address listed in the Code of Conduct goes to the Code of Conduct
> Committee. The exact members receiving these emails at any given time
> -are listed at <URL>. Members can not access reports made before they
> -joined or after they have left the committee.
> +are listed at https://kernel.org/code-of-conduct.html. Members can not
> +access reports made before they joined or after they have left the
> +committee.
This seems to be the wrong URL? It just points to the CoC, not to the TAB
members.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Sat, Oct 20, 2018 at 2:47 PM Trond Myklebust <[email protected]> wrote:
>
> On Sat, 2018-10-20 at 19:28 +0100, Alan Cox wrote:
> > > +to the circumstances. The Code of Conduct Committee is obligated
> > > to
> > > +maintain confidentiality with regard to the reporter of an
> > > incident.
> > > +Further details of specific enforcement policies may be posted
> > > +separately.
> >
> > Unfortunately by ignoring the other suggestions on this you've left
> > this
> > bit broken.
> >
> > The committee can't keep most stuff confidential so it's misleading
> > and
> > wrong to imply they can. Data protection law, reporting laws in some
> > countries and the like mean that anyone expecting an incident to
> > remain
> > confidential from the person it was reported against is living in
> > dreamland and are going to get a nasty shock.
> >
> > At the very least it should say '(except where required by law)'.
> >
> > There is a separate issue that serious things should always go to law
> > enforcement - you are setting up a policy akin to the one that got
> > the
> > catholic church and many others in trouble.
> >
> > You should also reserving the right to report serious incidents
> > directly
> > to law enforcement. Unless of course you want to be forced to sit on
> > multiple reports of physical abuse from different people about
> > someone - unable to tell them about each others report, unable to
> > prove
> > anything, and in twenty years time having to explain to the media why
> > nothing was done.
> >
>
> ...and then you get into questions about how this committee will
> respond to queries from said law enforcement, and indeed to which legal
> systems the committee will or will not report incidents.
>
> Why would we want to be going down the path of trying to handle reports
> about "serious incidents" in the first place? That seems way out of
> scope for a code of conduct arbitration scheme. Even attempting to
> counsel people as to whether or not they should report incidents can
> get you in trouble in many parts of the world.
>
Which is why the lawyers need to go over this document and I haven't
seen anything posted from them. In the same vein Mauro is concerned
that the way this is code is written it is a binding contract in
Brazil.
> --
> Trond Myklebust
> Linux NFS client maintainer, Hammerspace
> [email protected]
>
>
--
Jon Smirl
[email protected]
> -----Original Message-----
> From: Alan Cox
>
> > +to the circumstances. The Code of Conduct Committee is obligated to
> > +maintain confidentiality with regard to the reporter of an incident.
> > +Further details of specific enforcement policies may be posted
> > +separately.
>
> Unfortunately by ignoring the other suggestions on this you've left this
> bit broken.
>
> The committee can't keep most stuff confidential so it's misleading and
> wrong to imply they can.
I disagree with this assessment. We have managed to keep most stuff
confidential to the general public in the past, to the point where it has been
argued that the TAB have not been transparent enough. We're trying to
address that issue with the section about quarterly anonymized reports.
> Data protection law, reporting laws in some
> countries and the like mean that anyone expecting an incident to remain
> confidential from the person it was reported against is living in
> dreamland and are going to get a nasty shock.
OK - you seem to be talking about keeping the incident and reporter
confidential from the person reported against.
Certainly the person reported against has to have the incident
identified to them, so that part is not confidential. Many legal
jurisdictions require that the accused can know their accuser.
But these things come into play mostly when items have veered
into legal territory. Most violation reports are not in the territory.
There's no legal requirement that the Code of Conduct committee
tell someone who it was that said they were rude on the mailing list.
> At the very least it should say '(except where required by law)'.
That might be a good to add. It would be helpful, IMHO, to
re-visit the patch that's been floating around and see if it
can be added on top of this.
> There is a separate issue that serious things should always go to law
> enforcement - you are setting up a policy akin to the one that got the
> catholic church and many others in trouble.
>
> You should also reserving the right to report serious incidents directly
> to law enforcement. Unless of course you want to be forced to sit on
> multiple reports of physical abuse from different people about
> someone - unable to tell them about each others report, unable to prove
> anything, and in twenty years time having to explain to the media why
> nothing was done.
The scope of the code of conduct basically means that it covers
online interactions (communication via mailing list, git commits
and Bugzilla). Not to be flippant, but those are hardly mediums
that are susceptible to executing physical abuse. Also, they are
all mediums that leave a persistent, public trail. So I don't think the
comparison is very apt here.
-- Tim
On Sat, 2018-10-20 at 19:24 +0000, [email protected] wrote:
> The scope of the code of conduct basically means that it covers
> online interactions (communication via mailing list, git commits
> and Bugzilla). Not to be flippant, but those are hardly mediums
> that are susceptible to executing physical abuse. Also, they are
> all mediums that leave a persistent, public trail. So I don't think
> the
> comparison is very apt here.
> -- Tim
If that is the case, then why does this need to go into the Linux
kernel in the first place? The mailing lists, the kernel.org git
repository, and bugzilla presumably all have "terms of use" pages that
could specify the expected behaviour very explicitly, and could specify
how arbitration works as part of those terms of use (and if enforcement
is required, then it could specify legal venues etc).
IOW: if the scope is just communication online, then I would think
there are better tools for that.
Putting a code of conduct into the kernel code itself wants to be
justified by more than just regulating online behaviour.
--
Trond Myklebust
Linux NFS client maintainer, Hammerspace
[email protected]
On Sat, 2018-10-20 at 19:28 +0100, Alan Cox wrote:
> > +to the circumstances. The Code of Conduct Committee is obligated
> > to
> > +maintain confidentiality with regard to the reporter of an
> > incident.
> > +Further details of specific enforcement policies may be posted
> > +separately.
>
> Unfortunately by ignoring the other suggestions on this you've left
> this bit broken.
>
> The committee can't keep most stuff confidential so it's misleading
> and wrong to imply they can. Data protection law, reporting laws in
> some countries and the like mean that anyone expecting an incident to
> remain confidential from the person it was reported against is living
> in dreamland and are going to get a nasty shock.
>
> At the very least it should say '(except where required by law)'.
I've got a solution for this: the patches I've been curating also
modify the section so the merger will look like what I have below.
The intent of the series I'm curating was only the beginning to show
desire to change in 4.19 but to correct the obvious defect before we
started the debate, so after suitable discussion, this one can be
the final set.
> There is a separate issue that serious things should always go to law
> enforcement - you are setting up a policy akin to the one that got
> the catholic church and many others in trouble.
>
> You should also reserving the right to report serious incidents
> directly to law enforcement. Unless of course you want to be forced
> to sit on multiple reports of physical abuse from different people
> about someone - unable to tell them about each others report, unable
> to prove anything, and in twenty years time having to explain to the
> media why nothing was done.
I think we should debate that. Most legal systems provide significant
deference to victims wishing for confidentiality and we should both
respect that and remember that an automatic crime report is a
significant deterrent to vulnerable people in a lot of places.
James
---
diff --git a/Documentation/process/code-of-conduct.rst b/Documentation/process/code-of-conduct.rst
index eec768471a4d..8913851dab89 100644
--- a/Documentation/process/code-of-conduct.rst
+++ b/Documentation/process/code-of-conduct.rst
@@ -59,19 +59,27 @@ address, posting via an official social media account, or acting as an appointed
representative at an online or offline event. Representation of a project may be
further defined and clarified by project maintainers.
-Reporting
-=========
+Enforcement
+===========
Instances of abusive, harassing, or otherwise unacceptable behavior may be
-reported by contacting the Technical Advisory Board (TAB) at
-<[email protected]>. All complaints will be reviewed and
-investigated and will result in a response that is deemed necessary and
-appropriate to the circumstances. The TAB is obligated to maintain
-confidentiality with regard to the reporter of an incident (except where
-required by law).
+reported by contacting the Code of Conduct Committee at
+<[email protected]>. All complaints will be reviewed and investigated
+and will result in a response that is deemed necessary and appropriate
+to the circumstances. The Code of Conduct Committee is obligated to
+maintain confidentiality with regard to the reporter of an incident
+(except where required by law). Further details of specific enforcement
+policies may be posted separately.
+
Attribution
===========
This Code of Conduct is adapted from the Contributor Covenant, version 1.4,
available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
+
+Interpretation
+==============
+
+See the :ref:`code_of_conduct_interpretation` document for how the Linux
+kernel community will be interpreting this document.
> > Data protection law, reporting laws in some
> > countries and the like mean that anyone expecting an incident to remain
> > confidential from the person it was reported against is living in
> > dreamland and are going to get a nasty shock.
>
> OK - you seem to be talking about keeping the incident and reporter
> confidential from the person reported against.
> Certainly the person reported against has to have the incident
> identified to them, so that part is not confidential. Many legal
> jurisdictions require that the accused can know their accuser.
> But these things come into play mostly when items have veered
> into legal territory. Most violation reports are not in the territory.
> There's no legal requirement that the Code of Conduct committee
> tell someone who it was that said they were rude on the mailing list.
The 'who said' is generally safe (except from the it's in court case -
which is fine when that happens the legal process deals with it). The
other details are not so while someone accused of something might not
know who said it they can ask for what personal data (which would include
that email with names etc scrubbed).
You can possibly fight that in court of course, if you've got lots of
money and nothing better to do for six weeks.
> > You should also reserving the right to report serious incidents directly
> > to law enforcement. Unless of course you want to be forced to sit on
> > multiple reports of physical abuse from different people about
> > someone - unable to tell them about each others report, unable to prove
> > anything, and in twenty years time having to explain to the media why
> > nothing was done.
>
> The scope of the code of conduct basically means that it covers
> online interactions (communication via mailing list, git commits
> and Bugzilla).
I don't see it specifically stating that 'If someone is offensive at a
kernel summit we are going to refuse to listen'
Seriously ?
Alan
On Sun, 21 Oct 2018, Alan Cox wrote:
>
> I don't see it specifically stating that 'If someone is offensive at a
> kernel summit we are going to refuse to listen'
Kernel summit or Maintainer summit is covered by the CoC of the conference
it is attached to.
Thanks,
tglx
On Sat, Oct 20, 2018 at 09:01:57PM +0200, Geert Uytterhoeven wrote:
> Hi Greg,
>
> On Sat, Oct 20, 2018 at 3:53 PM Greg Kroah-Hartman
> <[email protected]> wrote:
> > There was a blank <URL> reference for how to find the Code of Conduct
> > Committee. Fix that up by pointing it to the correct kernel.org website
> > page location.
> >
> > Acked-by: Chris Mason <[email protected]>
> > Acked-by: Olof Johansson <[email protected]>
> > Acked-by: Theodore Ts'o <[email protected]>
> > Acked-by: Thomas Gleixner <[email protected]>
> > Signed-off-by: Greg Kroah-Hartman <[email protected]>
>
> Thanks for your patch!
>
> > --- a/Documentation/process/code-of-conduct-interpretation.rst
> > +++ b/Documentation/process/code-of-conduct-interpretation.rst
> > @@ -123,8 +123,9 @@ Enforcement
> >
> > The address listed in the Code of Conduct goes to the Code of Conduct
> > Committee. The exact members receiving these emails at any given time
> > -are listed at <URL>. Members can not access reports made before they
> > -joined or after they have left the committee.
> > +are listed at https://kernel.org/code-of-conduct.html. Members can not
> > +access reports made before they joined or after they have left the
> > +committee.
>
> This seems to be the wrong URL? It just points to the CoC, not to the TAB
> members.
The information at that web page will be updatd "soon" with the
information about the committee. Please give us a few more days for
this, as we are all traveling at the moment...
thanks,
greg k-h
On Sat, Oct 20, 2018 at 03:14:20PM -0400, [email protected] wrote:
>
> Which is why the lawyers need to go over this document and I haven't
> seen anything posted from them. In the same vein Mauro is concerned
> that the way this is code is written it is a binding contract in
> Brazil.
My understanding is that lawyers from the Linux Foundation have gone
over both the CoC and as well as the changes in this patchset, and
that this happened before they were sent out.
- Ted
On Sun, Oct 21, 2018 at 04:27:57AM -0400, Theodore Y. Ts'o wrote:
> On Sat, Oct 20, 2018 at 03:14:20PM -0400, [email protected] wrote:
> >
> > Which is why the lawyers need to go over this document and I haven't
> > seen anything posted from them. In the same vein Mauro is concerned
> > that the way this is code is written it is a binding contract in
> > Brazil.
>
> My understanding is that lawyers from the Linux Foundation have gone
> over both the CoC and as well as the changes in this patchset, and
> that this happened before they were sent out.
That is correct.
On Sat, Oct 20 2018, Greg Kroah-Hartman wrote:
> Hi all,
>
> As everyone knows by now, we added a new Code of Conduct to the kernel
> tree a few weeks ago.
I wanted to stay detached from all this, but as remaining (publicly)
silent might be seen (publicly) as acquiescing, I hereby declare that:
I reject, as illegitimate, this Code and the process by
which it is being "developed".
It is clear from the surrounding discussions that this is well outside our
core competencies. It will be flawed, it isn't what we need.
I call on any other community members who reject this process to say so,
not to remain silent.
#Iobject
We don't need a "Code of Conduct" nearly as much as we need "Leadership
in conduct". Without the leadership, any code looks like a joke.
I call on Linus Torvalds to follow up on his confession (which I think
is momentous and worth celebrating - Hurray!!!) with repentance - a clear
demonstration of change of mind.
Linus: I know your intentions are good and am confident that, now that
you see the problem, you will be able to effect a solution. If you
are not so confident, please be aware that there are many in the
community who can see clearly where you were blind, and are willing to
help guide and coach. Please reach out to someone you trust, and ask.
I call on the community to respond to this confession and repentance
from Linus with forgiveness and restoration.
I have no direct hurts to report and little to forgive, so my
forgiveness can only be worth little. However, for what it is worth:
I offer to Linus, and to any who are seeking to improve their
behaviour, my forgiveness for any past hurts, whether direct or
indirect. I hold no grudge, and wish to continue working together as
the need and opportunity arises.
#Iforgive
I call on the community to effect whatever reparation is possible to
those who have been hurt. Sometimes an apology is all that is possible,
sometimes it is all that is needed. If you are ever in a position to do
more, please consider doing so.
On behalf of my community, I apologise to all those who have been hurt
by us, for the lack of respect and care which should have been shown.
Where I have hurt you, whether through action or inaction, I
unreservedly apologise.
#Iapologise (or #Iapologize :-)
I call on you, Greg:
- to abandon this divisive attempt to impose a "Code of Conduct"
- to revert 8a104f8b5867c68
- to return to your core competence of building a great team around
a great kernel
#Isupportreversion
I call on the community to consider what *does* need to be said, about
conduct, to people outside the community and who have recently joined.
What is the document that you would have liked to have read as you were
starting out? It is all too long ago for me to remember clearly, and so
much has changed.
Thanks,
NeilBrown
#Iobject #Iforgive #Iapologise #Isupportreversion
On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> I call on you, Greg:
> - to abandon this divisive attempt to impose a "Code of Conduct"
> - to revert 8a104f8b5867c68
> - to return to your core competence of building a great team around
> a great kernel
>
> #Isupportreversion
>
> I call on the community to consider what *does* need to be said, about
> conduct, to people outside the community and who have recently joined.
> What is the document that you would have liked to have read as you were
> starting out? It is all too long ago for me to remember clearly, and so
> much has changed.
The document I would have liked to have read when starting out is
currently checked into the source tree in
Documentation/process/code-of-conduct.rst .
What is your actual concern? Why does it matter so much to you to push
back against this code of conduct? What does it say that you so
fundamentally object to?
(I personally *do* want to see most of the patch series that started
this particular thread dropped, because half of it undermines the point
of the document. The original commit, however, is a matter of
celebration.)
On 10/21/18 3:33 PM, Joe Perches wrote:
> On Mon, 2018-10-22 at 08:20 +1100, NeilBrown wrote:
>> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote:
>>> As everyone knows by now, we added a new Code of Conduct to the kernel
>>> tree a few weeks ago.
>>
>> I wanted to stay detached from all this, but as remaining (publicly)
>> silent might be seen (publicly) as acquiescing, I hereby declare that:
>> I reject, as illegitimate, this Code and the process by
>> which it is being "developed".
> []
>> I call on any other community members who reject this process to say so,
>> not to remain silent.
>
> The concept of describing a desire for pleasant interactions
> while
> developing the linux kernel is legitimate and useful.
Agree.
> I do reject this process as well and I think the attempt to
> reform it via a private, non-public method is, at best,
> poor form.
and Agree.
> Joe Perches
Thanks.
--
~Randy
On Mon, 2018-10-22 at 08:20 +1100, NeilBrown wrote:
> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote:
> > As everyone knows by now, we added a new Code of Conduct to the kernel
> > tree a few weeks ago.
>
> I wanted to stay detached from all this, but as remaining (publicly)
> silent might be seen (publicly) as acquiescing, I hereby declare that:
> I reject, as illegitimate, this Code and the process by
> which it is being "developed".
[]
> I call on any other community members who reject this process to say so,
> not to remain silent.
The concept of describing a desire for pleasant interactions
while
developing the linux kernel is legitimate and useful.
I do reject this process as well and I think the attempt to
reform it via a private, non-public method is, at best,
poor form.
Joe Perches
On Sun, Oct 21, 2018 at 11:26:08PM +0100, Josh Triplett wrote:
> On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> > I call on you, Greg:
> > - to abandon this divisive attempt to impose a "Code of Conduct"
> > - to revert 8a104f8b5867c68
> > - to return to your core competence of building a great team around
> > a great kernel
I would point out that Greg did not chose to "impose" a Code of
Conduct. That directive came from Linus; the change was signed off by
Linus, and the choice of the timing came from Linus. That's why the
initial commit went in with very minimal review. This series of
patches, especially the first two, have a very large number of
Acked-by sign-offs. That's because there was a *huge* amount of
consultation with the top contributors to the kernel (using git
statistics) before the patch set was posted.
This level of consultation did not take place before Linus took his
break during -rc4, precisely because he didn't want people to think
that Greg did this "behind his back" and so there was no time to do
the sort of consultations which we did with this patch set.
(And when I say we, although the TAB was obviously involved, Greg did
most of the heavy lifting; and this is something that I can say
definitively Greg did out of a sense of duty, and because he was asked
to take on this role. It obviously has *not* been a fun job, and Greg
has taken a lot of flak. I, for one, thank Greg for taking on this
thankless task!)
> (I personally *do* want to see most of the patch series that started
> this particular thread dropped, because half of it undermines the point
> of the document. The original commit, however, is a matter of
> celebration.)
Josh, here I think it's clear a very large number of kernel developers
disagree with you. Part of the concerns that led to creation of the
interpretation document was precisely because there was a lot of fear
mongering from people outside of the kernel development community,
some of them apparently from the Gamergate brigade.
And so while it is certainly true that a huge number of open source
projects use the Contributor's Convenant, and you don't see large
number of people getting "impeached" for stupid stuff from, say, the
GoLang project, there were a lot of people who *were* afraid that
perhaps, some of the insane/silly interpretations that had been flying
around might have actually been true. Perhaps that's what Neil is so
worried about.
For example, it should have been obvious that if code is rejected for
technical reasons, some shadowy, unacountable group would ***not***
second guess the reasons for a maintainer's decision and magically
eject said maintainer from kernel development. Maintainers still can
reject code for any technical reason, and in some cases, for good
non-technical reasons, such as the Netfilter team and code
contributions from someone who had been deemed, by his deeds, to be a
copyright troll. And as always, people who disagree with a
maintainer's decision to reject a patch can always appeal directly to
Linus by sending the change to him.
The Linux kernel adopting the Contributor's Convenant was not going to
change this. And certainly people haven't been using the
Contributor's Convenant to try to force crap ideas or crap code into
the Go language. Unfortunately, because the Code of Conduct was
suddenly dropped in with minimal chance for consultations, that fear
was out there. And that's why IMHO, the interpretation document
became necessary.
Ultimately, what we're after is a cultural change that will hopefully
strengthen the kernel community and make it a better place. Neil is
correct that ultimately what's important is not words in a document,
but how people behave. And so, if the words were causing a lot of
anxiety because were afraid that even accidental microagressions would
cause them to be permanently "impeached", and that failing to nit-pick
every possible microagression might be grounds for "impeaching" a
maintainer --- then making it clear that this is not what anyone had
in mind is a very important thing, since anxiety can lead to people
actively resist the cultural change which most of us are want and are
working towards.
Regards,
- Ted
Greg Kroah-Hartman <[email protected]>:
> This patch series adds this new document to the kernel tree, as well as
> removes a paragraph from the existing Code of Conduct that was
> bothersome to many maintainers.
I think the changes have improved it.
There is still a process issue with how this code was promulgated that
is clearly bothering a lot of people, but I hope that problem is well
enough understood that we don't need to rehash it. More transparency,
more consultation, and more notice of intent to revise would help
head off future problems.
I do have one content recommendation. In the version at
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/code-of-conduct.rst
which I presume is current, I see a paragraph that reads as follows:
>In the interest of fostering an open and welcoming environment, we as
>contributors and maintainers pledge to making participation in our project and
>our community a harassment-free experience for everyone, regardless of age, body
>size, disability, ethnicity, sex characteristics, gender identity and
>expression, level of experience, education, socio-economic status, nationality,
>personal appearance, race, religion, or sexual identity and orientation.
I recommend that all the text from "everyone" on be struck as (a) unnecessary,
and (b) tending to embroil the project in politico-cultural wars that can do
it no good - and replaced by "every individual".
That is, the result would read:
>In the interest of fostering an open and welcoming environment, we as
>contributors and maintainers pledge to making participation in our project and
>our community a harassment-free experience for every individual.
That is all that needs to be said. Listing all those specific
categories of "regardless of" implicitly privileges certain kinds of
identity (those listed) and disfavors others (those not listed).
Further, some of the phrases used fo categories are political
shibboleths that unavoidably drag in American presumptions not
appropriate for an international project.
Best to leave the whole mess out and just pledge to treat individuals well.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown:
> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote:
> > Hi all,
> >
> > As everyone knows by now, we added a new Code of Conduct to the kernel
> > tree a few weeks ago.
>
> I wanted to stay detached from all this, but as remaining (publicly)
And I didn't expect myself to ever post in this matter again, as I had
already given up and relegated it to the "waste of precious lifetime"
category. But your initiative and courage deserve support and so:
+1.
> I call on the community to consider what *does* need to be said, about
> conduct, to people outside the community and who have recently joined.
> What is the document that you would have liked to have read as you were
> starting out? It is all too long ago for me to remember clearly, and so
> much has changed.
On the day the patch came out, I started working on a modified version,
a CoC that I could have lived with. I guess this was my way of dealing
with this unfortunate affair.
So please find below what I would have submitted for discussion.
Thanks and regards!
Rainer Fiebig
Disclosure
==========
My contribution to the Linux kernel is admittedly negligible: I run rc-
kernels, have reported a few problems, helped to fix them and fixed one
myself. To the extent of the time and effort this took me, I dare to give
my opinion in this matter.
---
Code of Conduct
+++++++++++++++
The goal of the Linux kernel development process is to maintain and advance
the most robust operating system kernel ever.
Needless to say, views on how to achieve this will differ at times.
In order to keep arguments civilized and to ensure an open, positive
and constructive environment, we have setup guidelines
that participants are expected to comply with:
No bias
=======
Nobody must be discriminated or favored due to personal traits like
- for example - age, gender or ethnicity. They are irrelevant.
What counts is whether the contribution is in line with a/m goal.
Any such contribution will be carefully reviewed.
Be excellent to each other
==========================
Don't do to others what you don't want others to do to you.
Straightforward talk is fine. But dissent can be communicated in a
non-destructive manner. And keep in mind that at times it may be *you*
who is dead wrong.
Examples of encouraged behavior:
* Being respectful of differing viewpoints
* Criticizing constructively, i. e. showing ways for improvement
* Accepting constructive criticism
* Focusing on what is best for our goal and the community
Examples of unacceptable behavior:
* Comments intended to insult, depreciate or defame a person
* Public or private harassment
* Unwelcome sexual attention or advances
* Fabricating incriminations by quoting out of context
* Publishing others’ private information, such as a physical or electronic
address, without explicit permission
* Promoting political agendas
* Trolling
Responsibilities
================
All participants are responsible for complying with this Code of Conduct.
Maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of obviously unacceptable behavior.
Maintainers have the right to ban temporarily or permanently any contributor
who's behavior is not aligned to this Code of Conduct.
Arbitration
===========
Anyone who feels abused, harassed or affected by otherwise unacceptable
behavior may report this to the Technical Advisory Board (TAB)
at <[email protected]>.
All complaints will be reviewed and investigated and will result in a response
that is deemed necessary and appropriate to the circumstances.
The TAB is obligated to maintain confidentiality with regard to the reporter
of an incident.
Further details of specific arbitration policies may be posted separately.
Attribution
===========
Some elements of this Code of Conduct are derived from the Contributor
Covenant, version 1.4, available at https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
On Mon, 2018-10-22 at 08:20 +1100, NeilBrown wrote:
> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote:
>
> > Hi all,
> >
> > As everyone knows by now, we added a new Code of Conduct to the
> > kernel tree a few weeks ago.
>
> I wanted to stay detached from all this, but as remaining (publicly)
> silent might be seen (publicly) as acquiescing, I hereby declare
> that:
> I reject, as illegitimate, this Code and the process by
> which it is being "developed".
>
> It is clear from the surrounding discussions that this is well
> outside our core competencies. It will be flawed, it isn't what we
> need.
>
> I call on any other community members who reject this process to say
> so, not to remain silent.
> #Iobject
Well, I've got to say we really know how to screw up the process by
ramming this in at the last minute (again):
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8e630c31a3dfc7f4ab1007f95dd507cb2fe1dda5
So yes, I'll certainly object to our inability to follow an open process.
> We don't need a "Code of Conduct" nearly as much as we need
> "Leadership in conduct". Without the leadership, any code looks like
> a joke.
I do think we need something in document form, though. Not least
because we do have a perception problem which having a document helps
allay, mostly for external not internal perceptions. As I've said
several times, we have been steadily getting better thanks mostly to
internal people helping drive more civilised discussions and being more
helpful to new patch submitters.
I've also previously pointed out that I really like the debian code of
conduct:
https://www.debian.org/code_of_conduct
But now that I'm in Edinburgh, I had a conversation with Jeremy
Allison. Apparently the Samba community went through almost exactly
the same thing as were going through now: attempt initially to impose
the contributor covenant followed by an acrimonious argument (done
mostly in private). However, one interesting thing for us might be
their final endpoint:
https://wiki.samba.org/index.php/How_to_do_Samba:_Nicely
Which, like the debian document is a nicely engineered statement of
values which is specifically tailored to their community and needs.
The interesting thing is that eventually everyone in Samba agreed to
this, including the people who initially tried to impose the
contributor covenant.
James
On Sun, Oct 21 2018, Josh Triplett wrote:
> On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
>> I call on you, Greg:
>> - to abandon this divisive attempt to impose a "Code of Conduct"
>> - to revert 8a104f8b5867c68
>> - to return to your core competence of building a great team around
>> a great kernel
>>
>> #Isupportreversion
>>
>> I call on the community to consider what *does* need to be said, about
>> conduct, to people outside the community and who have recently joined.
>> What is the document that you would have liked to have read as you were
>> starting out? It is all too long ago for me to remember clearly, and so
>> much has changed.
>
> The document I would have liked to have read when starting out is
> currently checked into the source tree in
> Documentation/process/code-of-conduct.rst .
I'm curious - what would you have gained by reading that document?
>
> What is your actual concern? Why does it matter so much to you to push
> back against this code of conduct? What does it say that you so
> fundamentally object to?
Thank you for asking. The discipline of focusing on an answer to this
question (rather than being distracted by all the different things that
are wrong here) has helped me to clarify my thoughts very nicely.
The current document is upside down.
The whole point of any document like this is to curtail, bypass, or
redirect the power of the powerful (and thanks to Dave[1] for the "power"
frame). We already have plenty of process documents which attempt to give
power to the weak by explaining how they can be heard. While those
documents might have room for improvement in this process, this document
is quite different - it aims to take power away.
The power that the current document describes is the power of having a
platform on which to speak - through a wiki, through comments, through
code etc. It talks about maintainers curtailing that power when it is
misused.
I argue that regular "participants" in the kernel community have
virtually no power. The only "platforms" for speech are lkml (and other
lists) and bugzilla. lkml is a cacophony (even Mozart would sound
terrible if we played all his works at once!) and bugzilla is a ghost
town. Neither provide a platform where any central control is needed.
Every subscriber already filters content themselves, whether by
unsubscribing, just skimming subject lines, or with more automated
assistance (and that is not something the community can control, whether
it wants to or not).
The only strength that participants have is the value of their
contribution, and this is only turned into power when they are listened
to.
On the other end of the spectrum, Linus has all the power. Patches are
the currency of the realm and all power (popularity, voice, voting
rights) flow from them. Linus ultimately controls patches and has
ultimate power (almost - see below)
In between are maintainers - they received power from Linus through
lines of trust, and sometimes pass it on through other lines of trust -
to sub-maintainers and valued contributors. They also (noblesse oblige)
give some power to the poor who they don't know - accepting bug
reports, giving advice, reviewing patches.
Given the power structure, the document we should be modeling our
thoughts on is the Magna Carte, where the British barons demanded that
the King's power be curtailed.
We don't need a document where the maintainers tell the participants how
they must behave, but we might need one where the maintainers tell Linus
how to behave.
As I said, the current document is upside down.
I would hope that Linus would provide Magna Carte himself, but maybe he
isn't up to it. In which case, our job is to draft a document for Linus
to agree to abide by. He might want to then make changes, and that is
*perfect* *fine*. It is *his* statement to the community on how *he*
will use the power he has - after all, it is ultimately the whole
community (well beyond developers) who give Linus the power he has by
valuing the product he produces (just as farmers ultimately give power
to the king by putting food on his table to feed him and his soldiers).
Once Linus has adopted such a document, we can look to other
maintainers to follow suite. They might choose to use the same
document, or to write something completely different. In either case,
it puts their stance clearly on the table. People who find the need to
work with them can have clear expectations, and can decide on the best
approach, and whether it is worth the effort at all.
In parallel with these promises (willingly adopted, not imposed), we
need clear processes for people to follow if they cannot work with a
maintainer, either because the promise doesn't make them feel safe
enough, or because the maintainer violates their own promise.
This isn't about enforcement and repercussions and punishment exactly.
This is about economics - keeping the patches moving.
If, for example, Linus or Andrew said "if you cannot work with any given
maintainer, I will consider your patch directly, but you need to point
to where you tried, and why you failed - or to where the promise is
inadequate".
Currently if a maintainer is rude to you, there is no where else that
you can go and *that* is why it hurts. It isn't the abuse so much as
the powerlessness associated with it. If you can (metaphorically) say
to that maintainer "I don't care about your toilet mouth, you've just
given me the right to take my petition to caesar" - then the emotional
response will be quite different to pain.
If Linus is not true to his new-found sensitivity, we might need someone
(Greg?) to be a co-maintainer, able to accept patches when Linus has a
relapse. It might be good form to create this channel anyway, but I
doubt it would be needed in practice.
So there you have it. The "Code" is upside down.
We need documents which:
- curtail the power of the strong, starting with Linus
- are adopted willingly by individuals, not imposed on the community.
- provide alternate routes for patch-flow, so that no-one has ultimate
power.
Thanks,
NeilBrown
#Iobject #Iforgive #Iapologize #Isupportreversion
[1] just a random "Dave"
Neil,
I disagree with your framing, and thus your analysis, and thus your
proposed solution.
On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
> If, for example, Linus or Andrew said "if you cannot work with any given
> maintainer, I will consider your patch directly, but you need to point
> to where you tried, and why you failed - or to where the promise is
> inadequate".
>
> Currently if a maintainer is rude to you, there is no where else that
> you can go and *that* is why it hurts. It isn't the abuse so much as
> the powerlessness associated with it. If you can (metaphorically) say
> to that maintainer "I don't care about your toilet mouth, you've just
> given me the right to take my petition to caesar" - then the emotional
> response will be quite different to pain.
No. That's just not how things work. Patches don't get rejected
because maintainers are being rude. Patches don't get accepted
because they are not of a sufficiently high technical quality. And if
you spam a maintainer with bad quality patches, and they tell you what
you should do to make them better, and you actively ignore requests
about how to write better code[1], it is perfectly acceptable for
maintainers to decide to ignore said bad patch committer. Putting bad
patch commiters on a blacklist is not a CoC violation.
[1] And no, this is not a hypothetical example. This particular
kernel newcomer continually spammed maintainers with patches that
wouldn't even compile, and were clearly never tested. And when the
newcomer started giving bad advice to users reporting bugs, he
ultimately got banned from LKML...
After all, we all want to make the kernel to be better. So if someone
submits good quality code, Maintainers are going to want that code to
improve their subsystem. Thinking that people want to go off on power
trips by rejecting perfectly sound code is a complete misdiagnosis of
the problem.
- Ted
On Mon, Oct 22 2018, Theodore Y. Ts'o wrote:
> Neil,
>
> I disagree with your framing, and thus your analysis, and thus your
> proposed solution.
>
> On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
>> If, for example, Linus or Andrew said "if you cannot work with any given
>> maintainer, I will consider your patch directly, but you need to point
>> to where you tried, and why you failed - or to where the promise is
>> inadequate".
>>
>> Currently if a maintainer is rude to you, there is no where else that
>> you can go and *that* is why it hurts. It isn't the abuse so much as
>> the powerlessness associated with it. If you can (metaphorically) say
>> to that maintainer "I don't care about your toilet mouth, you've just
>> given me the right to take my petition to caesar" - then the emotional
>> response will be quite different to pain.
>
> No. That's just not how things work. Patches don't get rejected
> because maintainers are being rude.
Correct. Patches don't get *posted* because maintainers are rude. They
don't get accepted because they weren't posted.
Do you disagree with my claim that the main cause of hurt is
powerlessness?
Without that, we may as well be on different planets.
Thanks,
NeilBrown
On Sun, Oct 21 2018, Theodore Y. Ts'o wrote:
> On Sun, Oct 21, 2018 at 11:26:08PM +0100, Josh Triplett wrote:
>> On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
>> > I call on you, Greg:
>> > - to abandon this divisive attempt to impose a "Code of Conduct"
>> > - to revert 8a104f8b5867c68
>> > - to return to your core competence of building a great team around
>> > a great kernel
>
> I would point out that Greg did not chose to "impose" a Code of
> Conduct. That directive came from Linus; the change was signed off by
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Linus, and the choice of the timing came from Linus. That's why the
> initial commit went in with very minimal review. This series of
> patches, especially the first two, have a very large number of
> Acked-by sign-offs. That's because there was a *huge* amount of
> consultation with the top contributors to the kernel (using git
> statistics) before the patch set was posted.
>
> This level of consultation did not take place before Linus took his
> break during -rc4, precisely because he didn't want people to think
> that Greg did this "behind his back" and so there was no time to do
> the sort of consultations which we did with this patch set.
>
> (And when I say we, although the TAB was obviously involved, Greg did
> most of the heavy lifting; and this is something that I can say
> definitively Greg did out of a sense of duty, and because he was asked
^^^^^^^^^^^^^^^
> to take on this role. It obviously has *not* been a fun job, and Greg
> has taken a lot of flak. I, for one, thank Greg for taking on this
> thankless task!)
"I was told to do it" and "it was my duty" are not excuses for doing
something wrong.
I'm genuinely surprised that you would suggest it is at all relevant.
What am I missing?
NeilBrown
>
>> (I personally *do* want to see most of the patch series that started
>> this particular thread dropped, because half of it undermines the point
>> of the document. The original commit, however, is a matter of
>> celebration.)
>
> Josh, here I think it's clear a very large number of kernel developers
> disagree with you. Part of the concerns that led to creation of the
> interpretation document was precisely because there was a lot of fear
> mongering from people outside of the kernel development community,
> some of them apparently from the Gamergate brigade.
>
> And so while it is certainly true that a huge number of open source
> projects use the Contributor's Convenant, and you don't see large
> number of people getting "impeached" for stupid stuff from, say, the
> GoLang project, there were a lot of people who *were* afraid that
> perhaps, some of the insane/silly interpretations that had been flying
> around might have actually been true. Perhaps that's what Neil is so
> worried about.
>
> For example, it should have been obvious that if code is rejected for
> technical reasons, some shadowy, unacountable group would ***not***
> second guess the reasons for a maintainer's decision and magically
> eject said maintainer from kernel development. Maintainers still can
> reject code for any technical reason, and in some cases, for good
> non-technical reasons, such as the Netfilter team and code
> contributions from someone who had been deemed, by his deeds, to be a
> copyright troll. And as always, people who disagree with a
> maintainer's decision to reject a patch can always appeal directly to
> Linus by sending the change to him.
>
> The Linux kernel adopting the Contributor's Convenant was not going to
> change this. And certainly people haven't been using the
> Contributor's Convenant to try to force crap ideas or crap code into
> the Go language. Unfortunately, because the Code of Conduct was
> suddenly dropped in with minimal chance for consultations, that fear
> was out there. And that's why IMHO, the interpretation document
> became necessary.
>
> Ultimately, what we're after is a cultural change that will hopefully
> strengthen the kernel community and make it a better place. Neil is
> correct that ultimately what's important is not words in a document,
> but how people behave. And so, if the words were causing a lot of
> anxiety because were afraid that even accidental microagressions would
> cause them to be permanently "impeached", and that failing to nit-pick
> every possible microagression might be grounds for "impeaching" a
> maintainer --- then making it clear that this is not what anyone had
> in mind is a very important thing, since anxiety can lead to people
> actively resist the cultural change which most of us are want and are
> working towards.
>
> Regards,
> - Ted
On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
> Currently if a maintainer is rude to you, there is no where else that
> you can go and *that* is why it hurts. It isn't the abuse so much as
> the powerlessness associated with it. If you can (metaphorically) say
> to that maintainer "I don't care about your toilet mouth, you've just
> given me the right to take my petition to caesar" - then the emotional
> response will be quite different to pain.
Bollocks. First of all, you *always* can take patches to Linus, even if
maintainer is being the sodding Miss Manners. Always could. What you
can't (and shouldn't be able to) is to _force_ a piece of shit patch
(pardon the toilet mouth) into the tree on the grounds of maintainer having
been "rude" to your patch.
Again, you can and always could appeal to Linus if your patches are wrongly
rejected, in your opinion. You'd better have good evidence supporting the
"wrongly" bit in that case, but the "right to petition" model implies that
anyway.
If you are talking about the situations when "rude" maintainer makes insufferable
requests to one's precious patches (e.g. demonstrates his or her mental inferiority
by admitting that they are unable to follow contributor's 0.5KLoC of spaghetty in a
single function and has an unspeakable gall to demand to clean it up - instead of
passing that task upon the interns, as they ought to[1])... sure, that would be
something new. Would you care to be the person charged with dealing with such...
valuable contributors? And how good is the coverage of psychiatric treatments
offered by your medical insurance?
[1] no, I'm not making it up
> If Linus is not true to his new-found sensitivity, we might need someone
> (Greg?) to be a co-maintainer, able to accept patches when Linus has a
> relapse. It might be good form to create this channel anyway, but I
> doubt it would be needed in practice.
>
> So there you have it. The "Code" is upside down.
> We need documents which:
> - curtail the power of the strong, starting with Linus
> - are adopted willingly by individuals, not imposed on the community.
> - provide alternate routes for patch-flow, so that no-one has ultimate
> power.
Really? The ultimate power being to say "No" to a patch, and nobody should
have such? Are you fucking serious?
PS: All together, now -
Every Patch is Sacred,
Every Patch is Great,
If a Patch Is Wasted,
Neil Gets Quite Irate
may the filking begin...
On Tue, Oct 23 2018, Al Viro wrote:
> On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
>
>> Currently if a maintainer is rude to you, there is no where else that
>> you can go and *that* is why it hurts. It isn't the abuse so much as
>> the powerlessness associated with it. If you can (metaphorically) say
>> to that maintainer "I don't care about your toilet mouth, you've just
>> given me the right to take my petition to caesar" - then the emotional
>> response will be quite different to pain.
>
> Bollocks. First of all, you *always* can take patches to Linus, even if
> maintainer is being the sodding Miss Manners. Always could. What you
> can't (and shouldn't be able to) is to _force_ a piece of shit patch
> (pardon the toilet mouth) into the tree on the grounds of maintainer having
> been "rude" to your patch.
Yes, you could, and you can. But if it was Linus who was behaving
inappropriately, where did you go then? This is why I think whatever
"code" we have should be overtly a statement Linus makes about his
behaviour, in the first instance.
And of course a bad patch should be rejected. In many cases a bad patch
can then be improved. If the maintainer responds badly to your first (bad)
patch, it can be very hard to try again - once bitten twice shy, as they
say.
The point of being able to circumvent a maintainer is to be able to get
relevant rational review, instead of emotional attacks.
>
> Again, you can and always could appeal to Linus if your patches are wrongly
> rejected, in your opinion. You'd better have good evidence supporting the
> "wrongly" bit in that case, but the "right to petition" model implies that
> anyway.
I wonder how many people know about this right-to-petition, or use it.
Maybe it should be stated in the "Code of conduct".
>
> If you are talking about the situations when "rude" maintainer makes insufferable
> requests to one's precious patches (e.g. demonstrates his or her mental inferiority
> by admitting that they are unable to follow contributor's 0.5KLoC of spaghetty in a
> single function and has an unspeakable gall to demand to clean it up - instead of
> passing that task upon the interns, as they ought to[1])... sure, that would be
> something new. Would you care to be the person charged with dealing with such...
> valuable contributors? And how good is the coverage of psychiatric treatments
> offered by your medical insurance?
>
> [1] no, I'm not making it up
>
>> If Linus is not true to his new-found sensitivity, we might need someone
>> (Greg?) to be a co-maintainer, able to accept patches when Linus has a
>> relapse. It might be good form to create this channel anyway, but I
>> doubt it would be needed in practice.
>>
>> So there you have it. The "Code" is upside down.
>> We need documents which:
>> - curtail the power of the strong, starting with Linus
>> - are adopted willingly by individuals, not imposed on the community.
>> - provide alternate routes for patch-flow, so that no-one has ultimate
>> power.
>
> Really? The ultimate power being to say "No" to a patch, and nobody should
> have such? Are you fucking serious?
I have noticed of late a tendency in all sorts of different people to
hear/read a statement from someone they know, interpret it a particular
way, be surprised about that interpretation, and persist with believing
that interpretation anyway, rather than realizing that the most likely
explanation is a communication failure, and asking for clarification.
The "ultimate power" is the ability to say "no" to a patch, *with no
opportunity for review*. Two people together having that ultimate power
is a totally different thing to one person having it alone.
Thanks
NeilBrown
On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote:
> >> If Linus is not true to his new-found sensitivity, we might need someone
> >> (Greg?) to be a co-maintainer, able to accept patches when Linus has a
> >> relapse. It might be good form to create this channel anyway, but I
> >> doubt it would be needed in practice.
> >>
> >> So there you have it. The "Code" is upside down.
> >> We need documents which:
> >> - curtail the power of the strong, starting with Linus
> >> - are adopted willingly by individuals, not imposed on the community.
> >> - provide alternate routes for patch-flow, so that no-one has ultimate
> >> power.
> >
> > Really? The ultimate power being to say "No" to a patch, and nobody should
> > have such? Are you fucking serious?
>
> I have noticed of late a tendency in all sorts of different people to
> hear/read a statement from someone they know, interpret it a particular
> way, be surprised about that interpretation, and persist with believing
> that interpretation anyway, rather than realizing that the most likely
> explanation is a communication failure, and asking for clarification.
>
> The "ultimate power" is the ability to say "no" to a patch, *with no
> opportunity for review*. Two people together having that ultimate power
> is a totally different thing to one person having it alone.
If that's a clarification, I'm sorry to say that I understand you even less now.
What are you proposing? Duopoly? How do you deal with disagreements? Fork?
Revert wars?
Frankly, CoC as-is is a bloody awful idea wide-open to abuses, but what you
are proposing feels even more incoherent...
On Tue, Oct 23 2018, Al Viro wrote:
> On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote:
>
>> >> If Linus is not true to his new-found sensitivity, we might need someone
>> >> (Greg?) to be a co-maintainer, able to accept patches when Linus has a
>> >> relapse. It might be good form to create this channel anyway, but I
>> >> doubt it would be needed in practice.
>> >>
>> >> So there you have it. The "Code" is upside down.
>> >> We need documents which:
>> >> - curtail the power of the strong, starting with Linus
>> >> - are adopted willingly by individuals, not imposed on the community.
>> >> - provide alternate routes for patch-flow, so that no-one has ultimate
>> >> power.
>> >
>> > Really? The ultimate power being to say "No" to a patch, and nobody should
>> > have such? Are you fucking serious?
>>
>> I have noticed of late a tendency in all sorts of different people to
>> hear/read a statement from someone they know, interpret it a particular
>> way, be surprised about that interpretation, and persist with believing
>> that interpretation anyway, rather than realizing that the most likely
>> explanation is a communication failure, and asking for clarification.
>>
>> The "ultimate power" is the ability to say "no" to a patch, *with no
>> opportunity for review*. Two people together having that ultimate power
>> is a totally different thing to one person having it alone.
>
> If that's a clarification, I'm sorry to say that I understand you even less now.
> What are you proposing? Duopoly? How do you deal with disagreements? Fork?
> Revert wars?
We already have team-maintainership arrangements - doing the same thing
at the top level should not be that hard to imagine.
It really about "saying" no. I suspect all members of a team would come
to much the same decision about any given patch, but they might "say" it
differently. One might say "anyone who wrote this should be
lobotomised", and the other might say "I see what you are trying to do,
but the approach won't work - go look at how we handle XXXX, they have a
similar problem". Neither will accept the patch, and they will probably
both accept it after certain changes. But when one of them is having a
bad day, I would like people to have the explicit opportunity to ignore
them and talk to the other. Yes, they'll still get "no" twice, but they'll
also get something approaching sane review least once.
Just knowing that the person you are ranting at can by-pass you would, I
suspect, encourage a lot of people to reconsider their behavior (though
maybe I'm optomistic there).
Thanks,
NeilBrown
On Tue, Oct 23, 2018 at 04:28:03PM +1100, NeilBrown wrote:
> > If that's a clarification, I'm sorry to say that I understand you even less now.
> > What are you proposing? Duopoly? How do you deal with disagreements? Fork?
> > Revert wars?
>
> We already have team-maintainership arrangements - doing the same thing
> at the top level should not be that hard to imagine.
>
> It really about "saying" no. I suspect all members of a team would come
> to much the same decision about any given patch, but they might "say" it
> differently. One might say "anyone who wrote this should be
> lobotomised", and the other might say "I see what you are trying to do,
> but the approach won't work - go look at how we handle XXXX, they have a
> similar problem". Neither will accept the patch, and they will probably
> both accept it after certain changes. But when one of them is having a
> bad day, I would like people to have the explicit opportunity to ignore
> them and talk to the other. Yes, they'll still get "no" twice, but they'll
> also get something approaching sane review least once.
You still have not answered the question I've asked - what to do in case of
real disagreements, seeing that "pass it to Linus for final decision" obviously
doesn't work here. And while we are at it, what to do in case when "they"
_agree_ that patch is unsalvagable? I'm quite sure that you can think of
examples of such...
BTW, out of curiosity - when has anyone suggested lobotomies[1]? I'd like to see
details - got to be interesting...
[1] on kernel development lists, that is - I can think of examples in e.g.
NANAE circa '98 or so regarding the SGI employees responsible for sendmail
setup they used to ship in IRIX, but that was more of a possible explanation
of the reasons rather than suggested remedy...
On Mon, Oct 22, 2018 at 06:46:04PM -0400, Theodore Y. Ts'o wrote:
> Neil,
>
> I disagree with your framing, and thus your analysis, and thus your
> proposed solution.
>
> On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
> > If, for example, Linus or Andrew said "if you cannot work with any given
> > maintainer, I will consider your patch directly, but you need to point
> > to where you tried, and why you failed - or to where the promise is
> > inadequate".
> >
> > Currently if a maintainer is rude to you, there is no where else that
> > you can go and *that* is why it hurts. It isn't the abuse so much as
> > the powerlessness associated with it. If you can (metaphorically) say
> > to that maintainer "I don't care about your toilet mouth, you've just
> > given me the right to take my petition to caesar" - then the emotional
> > response will be quite different to pain.
>
> No. That's just not how things work. Patches don't get rejected
> because maintainers are being rude. Patches don't get accepted
> because they are not of a sufficiently high technical quality.
I once sent a bugfix and instead of applying it, the maintainer insulted
me and rejected it because the subject wasn't in imperative tense and
because I said "NULL dereference" instead of "NULL pointer dereference."
Ten years back there was a patch rejected because "F*** you, what do
women know about programming?" I can't imagine it happening now, but I
was so shocked by it at the time also...
regards,
dan carpenter
On Tue, Oct 23, 2018 at 09:26:52AM +0300, Dan Carpenter wrote:
> Ten years back there was a patch rejected because "F*** you, what do
> women know about programming?" I can't imagine it happening now, but I
> was so shocked by it at the time also...
URL? I would really, honestly, no kidding, like to know who had that
been (and where had that been, while we are at it). I would expect
a massive (and absolutely deserved) shitstorm if that was on any
public kernel-related lists 10 years ago, but I'm not reading all
of them, obviously...
On Tue, Oct 23, 2018 at 07:40:51AM +0100, Al Viro wrote:
> On Tue, Oct 23, 2018 at 09:26:52AM +0300, Dan Carpenter wrote:
>
> > Ten years back there was a patch rejected because "F*** you, what do
> > women know about programming?" I can't imagine it happening now, but I
> > was so shocked by it at the time also...
>
> URL? I would really, honestly, no kidding, like to know who had that
> been (and where had that been, while we are at it). I would expect
> a massive (and absolutely deserved) shitstorm if that was on any
> public kernel-related lists 10 years ago, but I'm not reading all
> of them, obviously...
It was a private email and I don't know who the maintainer was.
But I heard about it from the woman at a Linux conference and she was
a competent programmer and the bug was still there at the time.
regards,
dan carpenter
On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote:
>
> Yes, you could, and you can. But if it was Linus who was behaving
> inappropriately, where did you go then? This is why I think whatever
> "code" we have should be overtly a statement Linus makes about his
> behaviour, in the first instance.
You're still missing the point, and the problem. The concern was not
*that* a patch was rejected, it was in *how* the patch was rejected.
The "problem" has never been about how Linus was treating anyone other
than core maintainers; i.e., most of the rants that I can think of (a)
happened years of ago, and (b) were directed at the sort of people who
were in the room at the Maintainer's Summit yesterday. Who which, by
the way, didn't have a complaint about Linus's recent behavior; in
fact, there was general agreement that Linus's behavior has been
getting *better* over the last few years.
One of the more important effects of the CoC is that newcomers have a
fear about Linux's reputation of having extremely toxic community.
There is a narrative that has been constructed that because Linus
behaves badly to everyone; and this gives everyone "permission" to
behave badly. Regardless of how true it may have been in the past, I
believe that it is largely obsolete today. And so, the mere existence
of a CoC has caused some newcomers to say that they have "already
noticed a difference" --- which is IMO mostly the effect of CoC easing
fears, as opposed to any real change in Linux community in the past
four weeks.
I think how it will work out in practice is that the CoC will be more
a commitment about what we are holding up as community norms.
Unfortunately, for some poeple the term "CoC" apparently acts as
trigger language and it brings to mind legal proceedings,
unaccountable court-like entities, and hammering people with
punishments for petty issues with no appeal or recourse.
Perhaps this is why other communities have elected to use terms such
as "How to do Samba: Nicely" and "GNU Kind Communication Guidelines".
All of these are trying to solve the same issue, and so my suggestion
is let's just wait and see how things go. If people continue to see
that the community has "changed" for the better, and other people see
that we're not hammering people with sanctions, but rather reminding
each other about the kind of community we aspire to be, it'll all be
good.
- Ted
Am Dienstag, 23. Oktober 2018, 04:11:44 schrieb Theodore Y. Ts'o:
> On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote:
> > Yes, you could, and you can. But if it was Linus who was behaving
> > inappropriately, where did you go then? This is why I think whatever
> > "code" we have should be overtly a statement Linus makes about his
> > behaviour, in the first instance.
>
> You're still missing the point, and the problem. The concern was not
> *that* a patch was rejected, it was in *how* the patch was rejected.
And to solve *this* problem a highly controversial and politically charged
CoC had to be introduced that has already begun to divide the wider
community? Seems like a bit of an overkill to me.
And whether that CoC does come with a political agenda or is just being
*perceived* so, is irrelevant: the perception *is* the reality. And by
embracing this CoC, Linux is now being perceived as also supporting the agenda
that comes with it. But perhaps that was intended?
In my view you now have a new, probably even bigger problem: namely that by
adopting *this* CoC and by unyieldingly clinging to it, you have alienated
many, if not the majority of loyal Linux-users/supporters.
Bad choice and bad timing, now that Linux seemed ready to also take off
in the desktop-area.
> The "problem" has never been about how Linus was treating anyone other
> than core maintainers; i.e., most of the rants that I can think of (a)
> happened years of ago, and (b) were directed at the sort of people who
> were in the room at the Maintainer's Summit yesterday. Who which, by
> the way, didn't have a complaint about Linus's recent behavior; in
> fact, there was general agreement that Linus's behavior has been
> getting *better* over the last few years.
>
> One of the more important effects of the CoC is that newcomers have a
> fear about Linux's reputation of having extremely toxic community.
> There is a narrative that has been constructed that because Linus
> behaves badly to everyone; and this gives everyone "permission" to
> behave badly. Regardless of how true it may have been in the past, I
> believe that it is largely obsolete today. And so, the mere existence
> of a CoC has caused some newcomers to say that they have "already
> noticed a difference" --- which is IMO mostly the effect of CoC easing
> fears, as opposed to any real change in Linux community in the past
> four weeks.
>
> I think how it will work out in practice is that the CoC will be more
> a commitment about what we are holding up as community norms.
> Unfortunately, for some poeple the term "CoC" apparently acts as
> trigger language and it brings to mind legal proceedings,
> unaccountable court-like entities, and hammering people with
> punishments for petty issues with no appeal or recourse.
>
I think you're wrong here. It's not the term "CoC" as such that brings up the
negative associations. It is the specific choice of the CoC and its wording
that does. And quite a few people have pointed this out already. Mitigations
and alternatives had been offered but were ignored.
> Perhaps this is why other communities have elected to use terms such
> as "How to do Samba: Nicely" and "GNU Kind Communication Guidelines".
> All of these are trying to solve the same issue, and so my suggestion
> is let's just wait and see how things go. If people continue to see
> that the community has "changed" for the better, and other people see
> that we're not hammering people with sanctions, but rather reminding
> each other about the kind of community we aspire to be, it'll all be
> good.
>
> - Ted
Those other communities have not just chosen other terms but also chosen other
approaches and wordings.
In my view, the Linux-CoC stands for exactly that sort of extreme "Political
Correctness" that is infesting our societies and has proven its destructive
nature in more than enough instances. For some examples see [1][2][3][4][5].
To me it feels more and more like the dark times of witch-hunts are back or
when it was politically in-correct to say that the earth revolves around the
sun. In those days offenders like Galilei were at least offered the choice
between recanting and the funeral-pile. Today you may recant but you get
publicly burnt anyway.
To see Linux falling for this is a sorry sight.
Rainer Fiebig
***
[1] https://www.ibtimes.co.uk/sacked-nobel-prize-winning-scientist-sir-tim-hunt-gets-backing-eight-fellow-laureates-1507096
[2] https://www.telegraph.co.uk/news/science/science-news/12057365/Sir-Tim-Hunt-to-leave-Britain-for-Japan-after-sexism-row.html
[3] https://en.wikipedia.org/wiki/Tim_Hunt#The_toast
[4] https://www.bbc.com/news/world-europe-45703700
[5] https://www.bbc.com/news/world-us-canada-45789819
--
The truth always turns out to be simpler than you thought.
Richard Feynman
On Tue, Oct 23, 2018 at 04:22:54PM +0200, Rainer Fiebig wrote:
>
> And whether that CoC does come with a political agenda or is just being
> *perceived* so, is irrelevant: the perception *is* the reality. And by
> embracing this CoC, Linux is now being perceived as also supporting the agenda
> that comes with it. But perhaps that was intended?
>
> In my view you now have a new, probably even bigger problem: namely that by
> adopting *this* CoC and by unyieldingly clinging to it, you have alienated
> many, if not the majority of loyal Linux-users/supporters.
Citation Needed: What's your *proof* the majority of Linux
users/supports have been alienated? Many people have actually been
quite supportive of the CoC.
And perception is a funny thing. I have no doubt that there are
people who will claim that some CoC's that might more be acceptable to
you would be "useless" or "means nothing". (Note how simply removing
three lines that troubled ***many*** Maintainers caused Josh to
complain that it ruined the CoC). And there are others for whom the
Contributor's Convenant automatically seems to mean kangaroo courts
and harsh punishments with no accountability for minor issues. I
suspect that both you *and* Josh are unhappy, in opposite directions,
might be a hint that we've mostly gotten things right.
Another example of this is that zero-day testing bot changed its
message in order to be more welcoming to newcomers. ("Thank you for
the patch! Yet something to improve...".) At the Maintainer's Summit,
someone from Germany pointed out that in European and especially
German cultures, being ultra polite is often a signal that the person
is considered stupid/incompetent, and he actually viewed it the change
in the testing bot as making it be *less* welcoming, not *more*. Not
that he cared, because he has a thick skin and after all, it's only a
'bot --- but in his view he thought it was quite funny that the change
was welcomed by some as being an improvement when he viewed it
completely the other way 'round.
Ultimately, we are a world-wide effort, and it's really hard to
predict or control how people from different cultures will perceive an
e-mail or some document. That doesn't mean we shouldn't *try*, and
there may very well be times when someone will file a complaint for
what is perceived to be a Code of Conduct which is really a
misunderstanding due to a cultural mismatch. (And *obviously* that's
not a CoC violation either, despite some people trying to spread FUD
by making the case that it would be.)
> In my view, the Linux-CoC stands for exactly that sort of extreme "Political
> Correctness" that is infesting our societies and has proven its destructive
> nature in more than enough instances. For some examples see [1][2][3][4][5].
>
> To me it feels more and more like the dark times of witch-hunts are back or
> when it was politically in-correct to say that the earth revolves around the
> sun. In those days offenders like Galilei were at least offered the choice
> between recanting and the funeral-pile. Today you may recant but you get
> publicly burnt anyway.
Yeah, and that's precisely the FUD that I'm talking about. I
understand that is your view. Let's see if it's actually true. I
haven't seen any witch trials or burnings in the GoLang community,
which also uses the Contributor hConvenant as their CoC. Can you be
open-minded enough to accept the fact that you might be wrong? And
are you prepared to change your views if we don't see Maintainers
getting "impeached" or otherwise burned at the stake in the next year
or so?
And on the flip side, if we continue to have newcomers saying that
they are feeling more welcomed, I'm hoping that Josh is also open
minded to understand that the changes the we made didn't completely
destroy the whole point of the CoC.
Best regards,
- Ted
Theodore Y. Ts'o schrieb:
> On Tue, Oct 23, 2018 at 04:22:54PM +0200, Rainer Fiebig wrote:
>>
>> And whether that CoC does come with a political agenda or is just being
>> *perceived* so, is irrelevant: the perception *is* the reality. And by
>> embracing this CoC, Linux is now being perceived as also supporting the agenda
>> that comes with it. But perhaps that was intended?
>>
>> In my view you now have a new, probably even bigger problem: namely that by
>> adopting *this* CoC and by unyieldingly clinging to it, you have alienated
>> many, if not the majority of loyal Linux-users/supporters.
>
> Citation Needed: What's your *proof* the majority of Linux
> users/supports have been alienated? Many people have actually been
> quite supportive of the CoC.
>
Ah, come on. Proof? Do you have any hard data to underpin your assertion of
"many"?
That it *may* be the majority is the impression I got from the many
discussions that I have seen, I haven't counted the pro- and con-comments.
But I've found a little poll at "Pro-Linux", small sample, no way
representative but accessible only for registered users.[1]
The question was: "The new Code of Conduct: Good or bad for Linux?"
- Brings Linux sympathies and support: 11%
- Costs linux sympathies and support: 57%
- Will have no impact: 32%
- Nothing of this, but: 0%
I wouldn't call this "proof" but a worrisome indication nevertheless,
especially if you consider the name of the site.
> And perception is a funny thing. I have no doubt that there are
> people who will claim that some CoC's that might more be acceptable to
> you would be "useless" or "means nothing". (Note how simply removing
> three lines that troubled ***many*** Maintainers caused Josh to
> complain that it ruined the CoC). And there are others for whom the
> Contributor's Convenant automatically seems to mean kangaroo courts
> and harsh punishments with no accountability for minor issues. I
> suspect that both you *and* Josh are unhappy, in opposite directions,
> might be a hint that we've mostly gotten things right.
>
I find Josh's position rather extreme - for him it seems to be "All or nothing".
On the other hand, I've already made a proposal that is not too far from what
you have now - without the political sting. Doesn't mean you should use it.
So personally, I would be content already if you modified the first sentence
in the way that has been suggested by others here several times.
Less would be more.
> Another example of this is that zero-day testing bot changed its
> message in order to be more welcoming to newcomers. ("Thank you for
> the patch! Yet something to improve...".) At the Maintainer's Summit,
> someone from Germany pointed out that in European and especially
> German cultures, being ultra polite is often a signal that the person
> is considered stupid/incompetent, and he actually viewed it the change
> in the testing bot as making it be *less* welcoming, not *more*. Not
> that he cared, because he has a thick skin and after all, it's only a
> 'bot --- but in his view he thought it was quite funny that the change
> was welcomed by some as being an improvement when he viewed it
> completely the other way 'round.
>
Perhaps not *less* welcoming but yes, you might get the impression that this
bot wants to take you on a ride. :)
> Ultimately, we are a world-wide effort, and it's really hard to
> predict or control how people from different cultures will perceive an
> e-mail or some document. That doesn't mean we shouldn't *try*, and
> there may very well be times when someone will file a complaint for
> what is perceived to be a Code of Conduct which is really a
> misunderstanding due to a cultural mismatch. (And *obviously* that's
> not a CoC violation either, despite some people trying to spread FUD
> by making the case that it would be.)
>
>> In my view, the Linux-CoC stands for exactly that sort of extreme "Political
>> Correctness" that is infesting our societies and has proven its destructive
>> nature in more than enough instances. For some examples see [1][2][3][4][5].
>>
>> To me it feels more and more like the dark times of witch-hunts are back or
>> when it was politically in-correct to say that the earth revolves around the
>> sun. In those days offenders like Galilei were at least offered the choice
>> between recanting and the funeral-pile. Today you may recant but you get
>> publicly burnt anyway.
>
> Yeah, and that's precisely the FUD that I'm talking about. I
> understand that is your view. Let's see if it's actually true. I
FUD? What happened to those guys and other people is not fiction but reality.
And if a Nobel-laureate can lose his job and even leaves his country because
of a harmless joke which was quoted completely out of context, it's time to be
concerned and alarmed. There's something getting out of hand, imo.
I would have expected Linux to resist this and not invite it.
> haven't seen any witch trials or burnings in the GoLang community,
> which also uses the Contributor hConvenant as their CoC. Can you be
> open-minded enough to accept the fact that you might be wrong? And
> are you prepared to change your views if we don't see Maintainers
> getting "impeached" or otherwise burned at the stake in the next year
> or so?
I think I am. But are you open-minded enough to entertain the idea that
introducing *this* CoC *this* way might have been a ghastly mistake?
> And on the flip side, if we continue to have newcomers saying that
> they are feeling more welcomed, I'm hoping that Josh is also open
> minded to understand that the changes the we made didn't completely
> destroy the whole point of the CoC.
>
Not so long ago I was a newcomer myself. And submitting the patch, discussing
and improving it was a constructive and motivating experience - *no* CoC needed.
What happened in the last few weeks was just the opposite.
We'll see how this pans out.
Thanks and regards!
Rainer Fiebig
---
[1]
https://www.pro-linux.de/umfragen/2/454/der-neue-code-of-conduct-gut-oder-schlecht-f%C3%BCr-linux.html
On Tue, Oct 23 2018, Al Viro wrote:
> On Tue, Oct 23, 2018 at 04:28:03PM +1100, NeilBrown wrote:
>
>> > If that's a clarification, I'm sorry to say that I understand you even less now.
>> > What are you proposing? Duopoly? How do you deal with disagreements? Fork?
>> > Revert wars?
>>
>> We already have team-maintainership arrangements - doing the same thing
>> at the top level should not be that hard to imagine.
>>
>> It really about "saying" no. I suspect all members of a team would come
>> to much the same decision about any given patch, but they might "say" it
>> differently. One might say "anyone who wrote this should be
>> lobotomised", and the other might say "I see what you are trying to do,
>> but the approach won't work - go look at how we handle XXXX, they have a
>> similar problem". Neither will accept the patch, and they will probably
>> both accept it after certain changes. But when one of them is having a
>> bad day, I would like people to have the explicit opportunity to ignore
>> them and talk to the other. Yes, they'll still get "no" twice, but they'll
>> also get something approaching sane review least once.
>
> You still have not answered the question I've asked - what to do in case of
> real disagreements, seeing that "pass it to Linus for final decision" obviously
> doesn't work here. And while we are at it, what to do in case when "they"
> _agree_ that patch is unsalvagable? I'm quite sure that you can think of
> examples of such...
Sorry, things easily get lost in such a wide ranging conversation.
Handling of real disagreements is not my problem, unless I am a member
of the maintainership team. We have maintainership teams which appear
to work, so they provide an existence-proof that something can be
achieved.
Were I to have an opportunity to be part of a maintainership team, I
would probably base any internal agreement necessary on two principles.
1/ People on the team are reasonably competent, and aren't going to
commit anything that all controversial without being quite confident.
I would choose to trust.
2/ We commit bad patches often, and when we realize, we fix them. You
and I have both been on both sides of that. We (the community)
even commit quite large mistakes (devfs, control-groups) and the world
doesn't end. Accepting imperfection is a key part of Linus' pragmatic
approach, and a key part of the success of Linux.
If they agree that the patch is unsalvagable, then they say so -
politely and with reasons. It is a right-of-review, not a
right-of-success.
>
> BTW, out of curiosity - when has anyone suggested lobotomies[1]? I'd like to see
> details - got to be interesting...
Sorry, it was a deliberately ficticious example.
Thanks for showing an interest, it is more than a lot of people are
doing.
NeilBrown
>
> [1] on kernel development lists, that is - I can think of examples in e.g.
> NANAE circa '98 or so regarding the SGI employees responsible for sendmail
> setup they used to ship in IRIX, but that was more of a possible explanation
> of the reasons rather than suggested remedy...
On Tue, Oct 23 2018, Theodore Y. Ts'o wrote:
> On Tue, Oct 23, 2018 at 03:25:08PM +1100, NeilBrown wrote:
>>
>> Yes, you could, and you can. But if it was Linus who was behaving
>> inappropriately, where did you go then? This is why I think whatever
>> "code" we have should be overtly a statement Linus makes about his
>> behaviour, in the first instance.
>
> You're still missing the point, and the problem. The concern was not
> *that* a patch was rejected, it was in *how* the patch was rejected.
That is not a point I am missing. Of course it is about *how*.
One form of rejection shows you a path forward, which might be revising
the patch, and it might be solving your problem in a completely
different way.
The other form or rejection leaves you hurting and confused and not
knowing which way to turn - so you leave.
One way gives you power to move forward, the other denies it to you.
> The "problem" has never been about how Linus was treating anyone other
> than core maintainers; i.e., most of the rants that I can think of (a)
> happened years of ago, and (b) were directed at the sort of people who
> were in the room at the Maintainer's Summit yesterday. Who which, by
> the way, didn't have a complaint about Linus's recent behavior; in
> fact, there was general agreement that Linus's behavior has been
> getting *better* over the last few years.
The fact that Linus' behaviour has improved (with which I agree) is only
part of the story. There is also Linus' reputation which is, I think,
worse than his behaviour has ever been - partly because he has never
(until recently) done anything to correct that reputation.
Also, it is *not* just about how Linus treats core maintainers, as you
seem to agree with below (despite your statements above). To take the
liberty of quoting from an email on a non-public list that you will have
seen:
The unresolved bug was that Linus' conduct, and more importantly the
conduct of people that less artfully and less productively emulated
his blow ups, were getting further and further away from Linus' own
stated ideals on how to treat people.
Linus' example is (apparently) being copied. That makes it important, I
think, for him to set an explicit counter-example.
>
> One of the more important effects of the CoC is that newcomers have a
> fear about Linux's reputation of having extremely toxic community.
> There is a narrative that has been constructed that because Linus
> behaves badly to everyone; and this gives everyone "permission" to
> behave badly. Regardless of how true it may have been in the past, I
> believe that it is largely obsolete today. And so, the mere existence
> of a CoC has caused some newcomers to say that they have "already
> noticed a difference" --- which is IMO mostly the effect of CoC easing
> fears, as opposed to any real change in Linux community in the past
> four weeks.
If the CoC has really eased fears, then that is clearly good news. I
must admit to being a little surprised.
>
> I think how it will work out in practice is that the CoC will be more
> a commitment about what we are holding up as community norms.
> Unfortunately, for some poeple the term "CoC" apparently acts as
> trigger language and it brings to mind legal proceedings,
> unaccountable court-like entities, and hammering people with
> punishments for petty issues with no appeal or recourse.
>
> Perhaps this is why other communities have elected to use terms such
> as "How to do Samba: Nicely" and "GNU Kind Communication Guidelines".
And doesn't our "code", with an "interpretation" two and a half times as
long, look clumsy beside these documents??
> All of these are trying to solve the same issue, and so my suggestion
> is let's just wait and see how things go. If people continue to see
> that the community has "changed" for the better, and other people see
> that we're not hammering people with sanctions, but rather reminding
> each other about the kind of community we aspire to be, it'll all be
> good.
>
Thanks for your time,
NeilBrown
On 10/21/2018 02:20 PM, NeilBrown wrote:
<snip>
> I call on the community to consider what *does* need to be said, about
> conduct, to people outside the community and who have recently joined.
> What is the document that you would have liked to have read as you were
> starting out? It is all too long ago for me to remember clearly, and so
> much has changed.
>
I joined much more recently than many and what I would have wanted
then is an interesting question. I probably would _not_ have wanted
a code of conduct when I first started working in open source. I also
said things in my younger years I regret and probably wouldn't have
said if I was held to a higher standard of conduct. Younger me frequently
put up with behavior I wouldn't tolerate today. Younger me also
greatly benefited from the experience of other kernel developers
giving me firm feedback in a helpful way and saying no to bad approaches.
I don't believe I would have continued if I hadn't been given that
feedback in a useful way.
Today, I think the code of conduct is a very important addition to
the community. It's a stronger assertion that the kernel community
is committed to raising the bar for behavior. I have no concern about
patch review or quality dropping because most maintainers demonstrate
every day that they can give effective feedback. We're all going to
screw that up sometimes and the Code of Conduct reminds us to do our
best. Most issues that arise can be resolved with a private e-mail
going "you might want to rethink your wording there."
What the Code of Conduct also provides is confidence that more serious
community issues such as harassment not related to patch
review can be handled. It spells out certain behaviors that won't
be tolerated and explains how those problems will be dealt with.
Will those problems actually be handled appropriately when the time
comes? I can't actually say for sure, but the kernel community works
on trust so I guess I have to trust that it will. I really hope I never
have to report harassment but I'm glad there's a process in place.
Thanks,
Laura
On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
> On Sun, Oct 21 2018, Josh Triplett wrote:
>
> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> >> I call on you, Greg:
> >> - to abandon this divisive attempt to impose a "Code of Conduct"
> >> - to revert 8a104f8b5867c68
> >> - to return to your core competence of building a great team around
> >> a great kernel
> >>
> >> #Isupportreversion
> >>
> >> I call on the community to consider what *does* need to be said, about
> >> conduct, to people outside the community and who have recently joined.
> >> What is the document that you would have liked to have read as you were
> >> starting out? It is all too long ago for me to remember clearly, and so
> >> much has changed.
> >
> > The document I would have liked to have read when starting out is
> > currently checked into the source tree in
> > Documentation/process/code-of-conduct.rst .
>
> I'm curious - what would you have gained by reading that document?
I would have then had rather less of a pervasive feeling of "if I make
even a single mistake I get made an example of in ways that will feed
people's quotes files for years to come".
See
https://hbr.org/2017/08/high-performing-teams-need-psychological-safety-heres-how-to-create-it
for more on the benefits of that.
The linux devs can rescind their license grant. Why don't they if they
don't like the CoC. They did NOT give their code away. They merely
licensed it to people for nothing. Licenses can be rescinded. The
License text itself doesn't even disclaim the possibility of rescission.
All it says is that those who are down stream of a violator won't have
their license automatically revoked if the violator's is.
(No this was NOT "debunked", it's a complete lie to say that the owner
of the copyright cannot rescind his freely licensed (no consideration
paid) property: yes the free software people ARE LYING - but EVERYONE
now believes their lie even though their debunking was immediately
debunked itself. - Since none of you woman worshiping
anti-marry-little-girls** faggots are lawyers you believe whatever
you're told by "SFConservancy"*)
*(Who even had to bring in outside council themselves, inorder to
conflate clause 4, having so little expertise on the subject in-house)
**(YHWH explicitly allows men to have female children as brides (Devarim
chapter 22, verse 28 (na'ar) (same expressed in the Septuagint (padia))
(including in cases of a forceful taking (taphas)) (Yes, white men
(americans, anglos) are the enemy of YHWH's law, worldwide championing a
system that condemns all men to slavery at women's feet - the position
they themselves naturally gravitate to)
On Mon 2018-10-22 08:20:11, NeilBrown wrote:
> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote:
>
> > Hi all,
> >
> > As everyone knows by now, we added a new Code of Conduct to the kernel
> > tree a few weeks ago.
>
> I wanted to stay detached from all this, but as remaining (publicly)
> silent might be seen (publicly) as acquiescing, I hereby declare that:
> I reject, as illegitimate, this Code and the process by
> which it is being "developed".
>
> It is clear from the surrounding discussions that this is well outside our
> core competencies. It will be flawed, it isn't what we need.
Agreed.
> I call on you, Greg:
> - to abandon this divisive attempt to impose a "Code of Conduct"
> - to revert 8a104f8b5867c68
Agreed.
Plus I actually wish more people would gpg-sign their emails. It is
not that hard, and I actually thought original Linus' rc4 announcement
was fake.
It was not, and it does not look like there are spoofed mails here,
either, but hey, there are few I'd like to verify.
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Thu, Oct 25, 2018 at 07:56:26AM +0000, [email protected] wrote:
> The linux devs can rescind their license grant.
No they can not, please do not keep spreading false information.
greg k-h
Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown:
> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote:
> > Hi all,
> >
> > As everyone knows by now, we added a new Code of Conduct to the kernel
> > tree a few weeks ago.
>
> I wanted to stay detached from all this, but as remaining (publicly)
> silent might be seen (publicly) as acquiescing, I hereby declare that:
> I reject, as illegitimate, this Code and the process by
> which it is being "developed".
>
> It is clear from the surrounding discussions that this is well outside our
> core competencies. It will be flawed, it isn't what we need.
>
> I call on any other community members who reject this process to say so,
> not to remain silent.
> #Iobject
>
> We don't need a "Code of Conduct" nearly as much as we need "Leadership
> in conduct". Without the leadership, any code looks like a joke.
>
[...]
> I call on you, Greg:
> - to abandon this divisive attempt to impose a "Code of Conduct"
> - to revert 8a104f8b5867c68
Yes but this seems increasingly unlikely now. However, there may be an
alternative.
Jugding by the release-message for 4.19, some people here are fans of
Monty Python's. No wonder - as those guys are famous for being unrelenting
supporters of Political Correctness.
So one would be on the safe side if one just supplemented "Our Pledge"
with this:
"Everybody has the right to be offended."
I think, John Cleese would also welcome this.[1]
What do you think?
Regards!
Rainer Fiebig
[1] https://www.dailymail.co.uk/news/article-3427218/Political-correctness-killing-comedy-says-John-Cleese-Monty-Python-star-believes-fear-offending-certain-groups-lead-1984-style-society-free-expression-not-allowed.html
--
The truth always turns out to be simpler than you thought.
Richard Feynman
Greg Kroah-Hartman <[email protected]>:
> On Thu, Oct 25, 2018 at 07:56:26AM +0000, [email protected] wrote:
> > The linux devs can rescind their license grant.
>
> No they can not, please do not keep spreading false information.
I think the confusion about whether applying GPL can be rescinded has
obscured the most serious actual threat vector.
Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of
GPLed software have a specific right to relief (including injunctive
relief) against misappropriation of their software. That ruling (which
was the case of first impression on the binding status of the GPL)
reputational damage is *specifically* recognized as grounds for relief.
The anti-CoC dissidents don't have to rescind their license grant to
cause a great deal of trouble. Instead they can invoke the doctrine
established in Jacobsen vs. Katzer, seeking restraining orders. The
line of argument is so simple that I could probably brief it myself,
and I'm not a lawyer - just somebody who had to become a topic
expert in this area to do my job as the founding president of OSI.
For that matter, I don't think the question of whether the GPL can be
rescinded is settled - nor does my wife Cathy Raymond, Esq., a practicing
attorney who has also studied the relevant law.
Be very skeptical about what the FSF or SFC tells you about this; they
have a very strong institutional/ideological incentive to affirm
irrevocability regardless of what the law actually says. I, on the
other hand, don't have an ideological stake to defend in that
argument; I'm telling you that the doctrine forbidding perpetual
grants may very well have teeth here. There is, at any rate,
significant risk that a court will see it that way.
Between Jacobsen vs. Katzer and the prohibition against perpetual grants
I think you are incurring a grave risk by assuming the dissidents have
no ammunition.
Better for both sides to climb down from a confrontational position
before real damage gets done.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
On Thu, Oct 25, 2018 at 03:39:01PM -0400, Eric S. Raymond wrote:
>
> Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of
> GPLed software have a specific right to relief (including injunctive
> relief) against misappropriation of their software. That ruling (which
> was the case of first impression on the binding status of the GPL)
> reputational damage is *specifically* recognized as grounds for relief.
I've read the legal briefs, and I'm pretty sure they don't say what
you are claiming they say. Yes, I'm not a lawyer --- but that's OK
--- neither are you.
> The anti-CoC dissidents don't have to rescind their license grant to
> cause a great deal of trouble.
The *vast* majority of the "anti-CoC dissidents" who have been
advancing this argument, have, as near as I can tell, little or no
copyright ownership in the kernel. They are external trolls who are
not members of the kernel development community, to the best of my
belief and knowledge.
In short; they are adding noise to the conversation, and have been
presuming that in fact people are going to be regularly and summarily
ejected from the community. In short, they are adding FUD, probably
because they have their own agenda.
I would recommend that before people respond such provocation
messages, that they do a quick "git log" and find out whether they
have in fact contributed code to the kernel at all, and if so, how
long ago it was.
Regards,
- Ted
On Wed, Oct 24 2018, Josh Triplett wrote:
> On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
>> On Sun, Oct 21 2018, Josh Triplett wrote:
>>
>> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
>> >> I call on you, Greg:
>> >> - to abandon this divisive attempt to impose a "Code of Conduct"
>> >> - to revert 8a104f8b5867c68
>> >> - to return to your core competence of building a great team around
>> >> a great kernel
>> >>
>> >> #Isupportreversion
>> >>
>> >> I call on the community to consider what *does* need to be said, about
>> >> conduct, to people outside the community and who have recently joined.
>> >> What is the document that you would have liked to have read as you were
>> >> starting out? It is all too long ago for me to remember clearly, and so
>> >> much has changed.
>> >
>> > The document I would have liked to have read when starting out is
>> > currently checked into the source tree in
>> > Documentation/process/code-of-conduct.rst .
>>
>> I'm curious - what would you have gained by reading that document?
>
> I would have then had rather less of a pervasive feeling of "if I make
> even a single mistake I get made an example of in ways that will feed
> people's quotes files for years to come".
Thanks for your reply. Certainly feeling safe is important, and having
clear statements that the community values and promotes psychological
safety is valuable.
The old "code of conflict" said
If however, anyone feels personally abused, threatened, or otherwise
uncomfortable due to this process, that is not acceptable.
would you have not found this a strong enough statement to ward off that
pervasive feeling?
In the current code, would The "Our Pledge" section have been
sufficient, or do you think the other sections would have actually
helped you?
>
> See
> https://hbr.org/2017/08/high-performing-teams-need-psychological-safety-heres-how-to-create-it
> for more on the benefits of that.
Thanks for the link.
NeilBrown
Theodore Y. Ts'o <[email protected]>:
> On Thu, Oct 25, 2018 at 03:39:01PM -0400, Eric S. Raymond wrote:
> > Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of
> > GPLed software have a specific right to relief (including injunctive
> > relief) against misappropriation of their software. That ruling (which
> > was the case of first impression on the binding status of the GPL)
> > reputational damage is *specifically* recognized as grounds for relief.
>
> I've read the legal briefs, and I'm pretty sure they don't say what
> you are claiming they say. Yes, I'm not a lawyer --- but that's OK
> --- neither are you.
How much are you willing to gamble on not being wrong?
> The *vast* majority of the "anti-CoC dissidents" who have been
> advancing this argument, have, as near as I can tell, little or no
> copyright ownership in the kernel.
I do not have any facts with which to dispute this specific claim.
However, I do notice that a significant number of long-time
contributors have put themselves in the anti-CoC camp. I note Al Viro
as a recent example.
Even supposing you are right about most of the anti-Coc people being
outsiders, a tiny minority of people with a genuine IP stake could do a
lot of damage. I ask again: how much are you willing to gamble on not
being wrong?
I definitely do not want to see the kind of explosion we could witness.
I think you are making it more likely rather than less by appearing
high-handed and dismissive. Because, whatever the merits of the
CoC itself, there has been a process failure here. It doesn't look
good to be defending that failure.
A change like the CoC adoption was not a good thing to do without
proper public notice, discussion, and consensus-building *beforehand*.
This was an unforced error on the part of the leadership group;
please, *please* don't compound it by digging in around the error. Do
you really think you're going to win hearts and minds among insider
dissidents - people with a genuine stake - by dismissing the
opposition as a troll job?
Instead of declaiming about "trolls", how about we fix the process
failure instead?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
On Wed, Oct 24 2018, Laura Abbott wrote:
> On 10/21/2018 02:20 PM, NeilBrown wrote:
>
> <snip>
>
>> I call on the community to consider what *does* need to be said, about
>> conduct, to people outside the community and who have recently joined.
>> What is the document that you would have liked to have read as you were
>> starting out? It is all too long ago for me to remember clearly, and so
>> much has changed.
>>
>
> I joined much more recently than many and what I would have wanted
> then is an interesting question. I probably would _not_ have wanted
> a code of conduct when I first started working in open source. I also
> said things in my younger years I regret and probably wouldn't have
> said if I was held to a higher standard of conduct. Younger me frequently
> put up with behavior I wouldn't tolerate today. Younger me also
> greatly benefited from the experience of other kernel developers
> giving me firm feedback in a helpful way and saying no to bad approaches.
> I don't believe I would have continued if I hadn't been given that
> feedback in a useful way.
Thanks for this thoughtful reply. You seem to make two key points.
Firstly, you repeatedly value feedback - both positive and negative. I
agree. One of the worst things that can happen when I post a patch, is
that it get ignored (no feedback).
This gels with what Linus said recently, as reported in
https://lwn.net/Articles/769117/
To that end, he asked the assembled group to watch his emails and
let him know if things start to get close to the edge.
He explicitly asked for feedback, giving people permission to speak up
when they thought he was out of line. I personally think this is a
very significant statement. Not for what it tells those maintainers
(who probably generally knew that already) so much as for what it tells
the broader community who don't know Linus so well: Feedback about
behaviour is explicitly welcome.
You go on to say, below, that a private e-mail can resolve things. I
don't actually think that a private e-mail is such a good idea because
even though it might resolve things, it doesn't let the broader
community know they are resolved, and doesn't set any example of how
resolution works. Giving feedback in public is hard, but if there was a
clearly established mechanism, that might make it easier. I wouldn't
choose the wording you provided as it focuses on "you" rather than "me",
but that sort of gentleness is definitely appropriate.
Your second point is about more serious issues and particularly how they
will be handled. As I have said elsewhere, and will not belabor here,
I think this is upside down: we can and should give power to the weak,
rather than trying to curb the power of the strong.
Extrapolating from the "feedback" point, I'm imagining having a document
which starts:
In the Linux kernel community we try to be helpful and not hurtful.
The best way to understand how this applies in practice is to give,
receive, and observe feedback.
If someone says/does/writes something that you think is helpful, consider
saying so: "Thank you, I found that to be helpful".
- You can your own words if you wish.
- You might like to add your voice to others if the situation warrants
it.
If someone says/does/writes something that you think is hurtful
(whether to yourself or someone else), please consider saying
something:
"This seems hurtful to me"
- It is best to use exactly this wording. In particular, don't
embellish or explain unless asked.
- Normally just one voice is sufficient. If an individual repeats
the hurtful behavior, one new voice per instance is sufficient.
It might then continue with some specifics, though there seems to be
some debate on whether such specifics are a good idea. I don't have a
firm opinion.
Thanks a lot,
NeilBrown
>
> Today, I think the code of conduct is a very important addition to
> the community. It's a stronger assertion that the kernel community
> is committed to raising the bar for behavior. I have no concern about
> patch review or quality dropping because most maintainers demonstrate
> every day that they can give effective feedback. We're all going to
> screw that up sometimes and the Code of Conduct reminds us to do our
> best. Most issues that arise can be resolved with a private e-mail
> going "you might want to rethink your wording there."
>
> What the Code of Conduct also provides is confidence that more serious
> community issues such as harassment not related to patch
> review can be handled. It spells out certain behaviors that won't
> be tolerated and explains how those problems will be dealt with.
> Will those problems actually be handled appropriately when the time
> comes? I can't actually say for sure, but the kernel community works
> on trust so I guess I have to trust that it will. I really hope I never
> have to report harassment but I'm glad there's a process in place.
>
> Thanks,
> Laura
On Thu, Oct 25 2018, Eric S. Raymond wrote:
> Theodore Y. Ts'o <[email protected]>:
>> On Thu, Oct 25, 2018 at 03:39:01PM -0400, Eric S. Raymond wrote:
>> > Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of
>> > GPLed software have a specific right to relief (including injunctive
>> > relief) against misappropriation of their software. That ruling (which
>> > was the case of first impression on the binding status of the GPL)
>> > reputational damage is *specifically* recognized as grounds for relief.
>>
>> I've read the legal briefs, and I'm pretty sure they don't say what
>> you are claiming they say. Yes, I'm not a lawyer --- but that's OK
>> --- neither are you.
>
> How much are you willing to gamble on not being wrong?
>
>> The *vast* majority of the "anti-CoC dissidents" who have been
>> advancing this argument, have, as near as I can tell, little or no
>> copyright ownership in the kernel.
>
> I do not have any facts with which to dispute this specific claim.
> However, I do notice that a significant number of long-time
> contributors have put themselves in the anti-CoC camp. I note Al Viro
> as a recent example.
I think you are blurring two groups here.
Ted describes "anti-CoC dissidents" as people who are advancing an
argument about rescinding their license. This is a smaller groups than
the "ant-CoC camp" who don't really like the CoC. I suspect is it is a
much smaller group when restricting to actual copyright holders.
I am against the CoC as it stands, but rescinding any license is such an
enormous over-reaction, I find the concept laughable.
NeilBrown
>
> Even supposing you are right about most of the anti-Coc people being
> outsiders, a tiny minority of people with a genuine IP stake could do a
> lot of damage. I ask again: how much are you willing to gamble on not
> being wrong?
>
> I definitely do not want to see the kind of explosion we could witness.
> I think you are making it more likely rather than less by appearing
> high-handed and dismissive. Because, whatever the merits of the
> CoC itself, there has been a process failure here. It doesn't look
> good to be defending that failure.
>
> A change like the CoC adoption was not a good thing to do without
> proper public notice, discussion, and consensus-building *beforehand*.
> This was an unforced error on the part of the leadership group;
> please, *please* don't compound it by digging in around the error. Do
> you really think you're going to win hearts and minds among insider
> dissidents - people with a genuine stake - by dismissing the
> opposition as a troll job?
>
> Instead of declaiming about "trolls", how about we fix the process
> failure instead?
> --
> <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
> My work is funded by the Internet Civil Engineering Institute: https://icei.org
> Please visit their site and donate: the civilization you save might be your own.
On Thu, Oct 25 2018, Rainer Fiebig wrote:
> Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown:
>> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote:
>> > Hi all,
>> >
>> > As everyone knows by now, we added a new Code of Conduct to the kernel
>> > tree a few weeks ago.
>>
>> I wanted to stay detached from all this, but as remaining (publicly)
>> silent might be seen (publicly) as acquiescing, I hereby declare that:
>> I reject, as illegitimate, this Code and the process by
>> which it is being "developed".
>>
>> It is clear from the surrounding discussions that this is well outside our
>> core competencies. It will be flawed, it isn't what we need.
>>
>> I call on any other community members who reject this process to say so,
>> not to remain silent.
>> #Iobject
>>
>> We don't need a "Code of Conduct" nearly as much as we need "Leadership
>> in conduct". Without the leadership, any code looks like a joke.
>>
> [...]
>
>> I call on you, Greg:
>> - to abandon this divisive attempt to impose a "Code of Conduct"
>> - to revert 8a104f8b5867c68
>
> Yes but this seems increasingly unlikely now. However, there may be an
> alternative.
>
> Jugding by the release-message for 4.19, some people here are fans of
> Monty Python's. No wonder - as those guys are famous for being unrelenting
> supporters of Political Correctness.
>
> So one would be on the safe side if one just supplemented "Our Pledge"
> with this:
>
> "Everybody has the right to be offended."
>
> I think, John Cleese would also welcome this.[1]
>
> What do you think?
I do think that giving certain rights to the community is a good thing:
- the right to tell anyone that their speech is hurtful
- the right to (patch) review by a third party.
I don't think the right to be offended really needs to be given.
Yes, I know it is a joke and I do like Monty Python. I just don't think
it is particular helpful in this context. Maybe I missed something.
For myself, I relinquish my right to be offended. I just don't do it.
It doesn't seem to be worth the effort.
Thanks,
NeilBrown
>
> Regards!
>
>
> Rainer Fiebig
>
>
>
> [1] https://www.dailymail.co.uk/news/article-3427218/Political-correctness-killing-comedy-says-John-Cleese-Monty-Python-star-believes-fear-offending-certain-groups-lead-1984-style-society-free-expression-not-allowed.html
>
>
> --
> The truth always turns out to be simpler than you thought.
> Richard Feynman
NeilBrown <[email protected]>:
> I think you are blurring two groups here.
> Ted describes "anti-CoC dissidents" as people who are advancing an
> argument about rescinding their license. This is a smaller groups than
> the "ant-CoC camp" who don't really like the CoC. I suspect is it is a
> much smaller group when restricting to actual copyright holders.
You may be right that these are semi-distinct groups. I don't think
the distinction makes a lot of difference to my argument, though.
Either way, (a) there's been a process failure by the leadership, and
(b) the threat of a massive legal disruption is real.
> I am against the CoC as it stands, but rescinding any license is such an
> enormous over-reaction, I find the concept laughable.
I'm...not sure I do. I was going to agree with you that it's a
massive overreaction, but then a simple question occurred to me: what
else could *I* do if I thought I had a significant stake (I don't; my
kernel contributions are minor and old) and felt my interests were
damaged?
All this could have been avoided so easily. A felt need for a new Code
should not have been followed by the immediate imposition of one,
but by a public RFC process and consensus-building - a process in which
even those who lost arguments about the construction of the code could
know they had been heard.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
On Thu, Oct 25 2018, Eric S. Raymond wrote:
> NeilBrown <[email protected]>:
>> I think you are blurring two groups here.
>> Ted describes "anti-CoC dissidents" as people who are advancing an
>> argument about rescinding their license. This is a smaller groups than
>> the "ant-CoC camp" who don't really like the CoC. I suspect is it is a
>> much smaller group when restricting to actual copyright holders.
>
> You may be right that these are semi-distinct groups. I don't think
> the distinction makes a lot of difference to my argument, though.
> Either way, (a) there's been a process failure by the leadership, and
> (b) the threat of a massive legal disruption is real.
>
>> I am against the CoC as it stands, but rescinding any license is such an
>> enormous over-reaction, I find the concept laughable.
>
> I'm...not sure I do. I was going to agree with you that it's a
> massive overreaction, but then a simple question occurred to me: what
> else could *I* do if I thought I had a significant stake (I don't; my
> kernel contributions are minor and old) and felt my interests were
> damaged?
Reasonable people can certainly see this issue differently.
My perspective is that I have already gained so much benefit in return
for my investment that this is little more than a rounding error. If
something happened that really did threaten the value of my investment,
I'm sure there would be so many others who thought so too, that we would be
able to fork the community.
>
> All this could have been avoided so easily. A felt need for a new Code
> should not have been followed by the immediate imposition of one,
> but by a public RFC process and consensus-building - a process in which
> even those who lost arguments about the construction of the code could
> know they had been heard.
I do agree about the process failure. The "immediate imposition" was
unnecessary and (I think) harmful.
Thanks,
NeilBrown
> --
> <a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
>
> My work is funded by the Internet Civil Engineering Institute: https://icei.org
> Please visit their site and donate: the civilization you save might be your own.
On Thu, Oct 25, 2018 at 05:41:23PM -0400, Eric S. Raymond wrote:
> I do not have any facts with which to dispute this specific claim.
> However, I do notice that a significant number of long-time
> contributors have put themselves in the anti-CoC camp. I note Al Viro
> as a recent example.
*snort*
For the record:
* CoC is a piss-poor match for the structure of community
* Linus had essentially tossed a live grenade into an outhouse on
his way to vacation, with quite predictable results - all kinds of
interesting coprophagous fauna dropping by to feed, including cartooneys
of the sort I hadn't seen since NANAE days.
* As idiotic gambits go, "try and revoke the license on my
contributions, so that they'll have to revoke CoC" is... impressive.
Sadly, my command of English has turned out to be woefully inadequate,
and I can't even blame that on not being a native speaker; I'm just as
incapable of producing a coherent (let alone printable) description of
that cunning plan in any language, Russian included. I've tried. Really.
* in case it needs to be spelled out: I am not at all interested
in that kind of stunts. One of the reasons I thoroughly despise RMS
and his bunch is the leverage game they tried to play with GPLv3;
damned if I'm going to lower myself to their level.
El jue, 25-10-2018 a las 16:47 -0400, Theodore Y. Ts'o escribió:
> On Thu, Oct 25, 2018 at 03:39:01PM -0400, Eric S. Raymond wrote:
> >
> > Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of
> > GPLed software have a specific right to relief (including
> > injunctive
> > relief) against misappropriation of their software. That ruling
> > (which
> > was the case of first impression on the binding status of the GPL)
> > reputational damage is *specifically* recognized as grounds for
> > relief.
>
> I've read the legal briefs, and I'm pretty sure they don't say what
> you are claiming they say. Yes, I'm not a lawyer --- but that's OK
> --- neither are you.
>
> > The anti-CoC dissidents don't have to rescind their license grant
> > to
> > cause a great deal of trouble.
>
> The *vast* majority of the "anti-CoC dissidents" who have been
> advancing this argument, have, as near as I can tell, little or no
> copyright ownership in the kernel. They are external trolls who are
> not members of the kernel development community, to the best of my
> belief and knowledge.
I understand the point, but being an outsider from the kernel
development community, does not mean i should not care about Linux
development and this particular community.
I have been promoting, using, installing, testing and loving Linux for
more than 20 years now. One of the things that got me into it and still
appreciate a lot is the meritocracy: the norm of technical excellence,
the: "it does not matter who you are as long as you contribute good
code".
This CoC "movement" is part of an anti meritocracy "movement" that
should not be influencing a project that thanks to this meritocracy has
become the most important in the world.
I'll take one of the arguments of the CoC promoters and use it on my
favor: The Linux community has grown more than just a bunch of
developers it has: promoters, users, testers, enthusiast, companies,
foundations, etc...
I wouldn't like that a negative code of conduct (yes its languaje is
aggresive and charged with negativity, politics and victimization)
compromise the technical aspects of a critical system like the Linux
kernel.
When it comes to coding, Engineers should be above that stuff.
>
> In short; they are adding noise to the conversation, and have been
> presuming that in fact people are going to be regularly and summarily
> ejected from the community. In short, they are adding FUD, probably
> because they have their own agenda.
I have one agenda: World Domination :P
> I would recommend that before people respond such provocation
> messages, that they do a quick "git log" and find out whether they
> have in fact contributed code to the kernel at all, and if so, how
> long ago it was.
Just want to clarify that this is not a provocation, just got tired of
being a passive member of this discussion.
You're right the people with more merit in this list should have a more
important voice since it shows the commitment to the development.
BTW Thanks for the comment, i will start contributing to the extent of
my capacities.
As i say, the reach of Linux is broader than just the development
community. Too bad you can't git log all the servers that people has
installed and maintaining during the years.
> Regards,
>
> - Ted
Cheers,
Ivan
Al Viro <[email protected]>:
> * in case it needs to be spelled out: I am not at all interested
> in that kind of stunts. One of the reasons I thoroughly despise RMS
> and his bunch is the leverage game they tried to play with GPLv3;
> damned if I'm going to lower myself to their level.
Sorry, I did not mean to imply that you are one with the license-revokers.
More like "if even Al Viro thinks you fucked up your process, it would be
unwise to dismiss the opposition to the CoC as mere trolls".
*I* can't dismiss it, because I read my mail. Apparently lots of people think
that it is *my* job to fix this mess, or at least to give it a good hard
try. I doubt they're trolling; what would be the point?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
On Thu, Oct 25, 2018 at 10:28:36PM -0400, Eric S. Raymond wrote:
> Al Viro <[email protected]>:
> > * in case it needs to be spelled out: I am not at all interested
> > in that kind of stunts. One of the reasons I thoroughly despise RMS
> > and his bunch is the leverage game they tried to play with GPLv3;
> > damned if I'm going to lower myself to their level.
>
> Sorry, I did not mean to imply that you are one with the license-revokers.
> More like "if even Al Viro thinks you fucked up your process, it would be
> unwise to dismiss the opposition to the CoC as mere trolls".
Kindly stop conflating opposition to CoC with that kind of idiocy.
NeilBrown schrieb:
> On Thu, Oct 25 2018, Rainer Fiebig wrote:
>
>> Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown:
>>> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote:
>>>> Hi all,
>>>>
>>>> As everyone knows by now, we added a new Code of Conduct to the kernel
>>>> tree a few weeks ago.
>>>
>>> I wanted to stay detached from all this, but as remaining (publicly)
>>> silent might be seen (publicly) as acquiescing, I hereby declare that:
>>> I reject, as illegitimate, this Code and the process by
>>> which it is being "developed".
>>>
>>> It is clear from the surrounding discussions that this is well outside our
>>> core competencies. It will be flawed, it isn't what we need.
>>>
>>> I call on any other community members who reject this process to say so,
>>> not to remain silent.
>>> #Iobject
>>>
>>> We don't need a "Code of Conduct" nearly as much as we need "Leadership
>>> in conduct". Without the leadership, any code looks like a joke.
>>>
>> [...]
>>
>>> I call on you, Greg:
>>> - to abandon this divisive attempt to impose a "Code of Conduct"
>>> - to revert 8a104f8b5867c68
>>
>> Yes but this seems increasingly unlikely now. However, there may be an
>> alternative.
>>
>> Jugding by the release-message for 4.19, some people here are fans of
>> Monty Python's. No wonder - as those guys are famous for being unrelenting
>> supporters of Political Correctness.
>>
>> So one would be on the safe side if one just supplemented "Our Pledge"
>> with this:
>>
>> "Everybody has the right to be offended."
>>
>> I think, John Cleese would also welcome this.[1]
>>
>> What do you think?
>
> I do think that giving certain rights to the community is a good thing:
> - the right to tell anyone that their speech is hurtful
> - the right to (patch) review by a third party.
>
> I don't think the right to be offended really needs to be given.
> Yes, I know it is a joke and I do like Monty Python. I just don't think
> it is particular helpful in this context. Maybe I missed something.
Of course it's a joke and iirc it was indeed John Cleese who made it. But he
made it for a reason, out of concern. It has a serious core.
The question is: what *is* helpful in this matter?
Just saying "this is not helpful" isn't helpful either. It's a well-known
killer-phrase that has been used ad nauseam in this discussion. But an
alternative is never given. And thus it's just an other way of saying
"Eat it. And shut tf up!"
Not even *constructive* criticism is helpful. AFAIK I'm the only one here who
came up with a *complete* alternative - ignored. Others provided patches for
certain sections - ignored. Data that indicate that this may be detrimental to
Linux - ignored. Almost anything that was provided by me or others - ignored.
What kind of community or attitude is this? This feels more like "The Wall" or
North Korea than an Open-Source-project.
And what beat everything was to misuse famously politically *in*correct Monty
Python to malign criticism of this Political-Correctness-monster. The
"People's Front" - message will forever be a prominent exhibit in "Monty
Python's Hall of Shame". And the author should be banned from laughing about
MP-sketches until he recants. Perhaps one should also report this incident to
the "Ministry of Silly CoCs". ;)
> For myself, I relinquish my right to be offended. I just don't do it.
> It doesn't seem to be worth the effort.
I don't. John Cleese is a smart guy. And he has a point.
OK, thanks for your reply! But I think it's time for me to move on. "Cut your
losses", as they say.
Good luck and regards!
Rainer Fiebig
Yes they can, greg.
The GPL v2, is a bare license. It is not a contract. It lacks
consideration between the licensee and the grantor.
(IE: They didn't pay you, Greg, a thing. YOU, Greg, simply have chosen
to bestow a benefit upon them where they suffer no detriment and you, in
fact, gain no bargained-for benefit)
As a bare license, (read: property license), the standard rules
regarding the alienation of property apply.
Therein: a gratuitous license is revocable at the will of the grantor.
The licensee then may ATTEMPT, as an affirmative defense against your
as-of-right action to claim promissory estoppel in state court, and
"keep you to your word". However you made no such promise disclaiming
your right to rescind the license.
Remeber: There is no utterance disclaiming this right within the GPL
version 2. Linus, furthermore, has chosen both to exclude the "or any
later version" codicil, to reject the GPL version 3, AND to publicly
savage GPL version 3 (he surely has his reasons, perhaps this is one of
them, left unstated). (GPLv3 which has such promises listed (not to say
that they would be effective against the grantor, but it is an attempt
at the least)).
The Software Freedom Conservancy has attempted to mis-construe clause 4
of the GPL version 2 as a "no-revocation by grantor" clause.
However, reading said clause, using plain construction, leads a
reasonable person to understand that said clause is speaking
specifically about the situation where an upstream licensee loses their
permission under the terms due to a violation of the terms; in that case
the down-stream licensee does not in-turn also lose their permission
under the terms.
Additionally, clause 0 makes it crystal clear that "You" is defined as
the licensee, not the grantor. Another issue the SFConservancy's public
service announcement chooses to ignore.
Thirdly, the SFConservancy banks on the ignorance of both the public and
the developers regarding property alienation. A license does not impinge
the rights of the party granting the license in a quid-pro-quo manner
vis a vis the licensee's taking. A license merely grants permission,
extended from the grantor, to the licensee, regarding the article of
property that is being impinged. A license is NOT a full nor is it a
permanent alienation of the article(property) in question. The impinged
property, being under a non bargained-for temporary grant, can be taken
back into the sole dominion of the owner - at his election to do so.
Now as to the 9th circuit appellate court's decision in Jacobsen v.
Katzer . While the court waxes eloquently about opensource licenses,
even mentioning the word "consideration" in it's long dicta, when it
comes time to make the binding decision the court found that the lower
(district) court was in _ERROR_ regarding the application of
contract-law principals to the Artistic License, regarding the case, and
instructed the lower court to instead construe said license as a
Copyright License.
The SFConservancy, and Bruce Perens have chosen to:
1) Rely on the dicta. (non-binding - "some things could be contracts -
opensource is great")
2) Ignore the actual ruling. (Binding - Copyright License - Not
Contract)
3) Ignore that this case was about the AL, not the GPLv2
4) Ignore the existence of different jurisdictions.
(Why file in the roll-the-dice 9th district if you can file in a
district that has personal-juristicion over the defendant and is much
more consistent in it's rulings?)
5) Ignore all established law regard property licensing, contract
formation, meeting of the minds, what consideration is etc.
Which is not surprising considering the desire of people like Bruce
Perens is to rob MEN of EVERY benefit of their Labour and every speck of
happiness in life and to transfer those benefits to WOMEN and those who
support women.
(This is why people who are like Bruce Perens, the SFConservancy
menbers, and the CoC supporters, banned men from taking female children
as brides: in contrivance to the law of YHWH (Devarim chapter 22 - -
verse 28 (na'ar (LXX: padia)), and continue to uphold that ban
world-wide, and seek to destroy ALL cultures that do no bend to their
will.... who are not idolators of Women)
Look, you may love your users, you may love the people who edit your
code in their home or office; but the fact of the matter is...
They have done nothing for you, they have promised nothing to you. They
CANNOT hold YOU.
You have the right to rescind at any time, and remove your work from any
future versions of Linux. And you might consider doing so if YOU are
done harm.
Don't let the insatiable, never-satisfied, public fool you into thinking
otherwise.
And, yes, I am a lawyer.
And, no, unlike the SFConservancy, I did not have to call upon outside
counsel to analyze the fact pattern. (And even then all they could come
up with was statements using weasel words "may" etc: not even wanting to
commit to their clearly-disingenuous publication)
(Note: If you would like to read a nice discussion on the topic, here is
one http://illinoisjltp.com/journal/wp-content/uploads/2013/10/kumar.pdf
)
On 2018-10-25 08:19, Greg Kroah-Hartman wrote:
> On Thu, Oct 25, 2018 at 07:56:26AM +0000, [email protected]
> wrote:
>> The linux devs can rescind their license grant.
>
> No they can not, please do not keep spreading false information.
>
> greg k-h
On Thursday, 25 October 2018, Eric S. Raymond wrote:
Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of
GPLed software have a specific right to relief (including injunctive
relief) against misappropriation of their software. That ruling (which
was the case of first impression on the binding status of the GPL)
No, Eric, _Jacobsen_ v. _Katzer_ has nothing to do with GPL. The
license terms on the software at issue were Artistic 1.0. The GPL is
mentioned in an informational footnote only. The case has little
legal weight, for procedural reasons, and is most certainly not "the
case of first impression on the binding status of the GPL."
reputational damage is *specifically* recognized as grounds for relief.
No. Reputational damage is not mentioned at all, let alone
specifically recognized. The District Court opinion that was
overturned in the Court of Appeals had held that licenses that don't
require payment of royalties are unenforceable, which was not
copyright law of any kind. The CAFC, guessing about the content of
Ninth Circuit law under the jurisdictional rules of the appeal (a
state of affairs which leaves no real precedential weight at all
behind the opinion) rightly discovered that there are "economic
interests" furthered by free licensing. Reputational interests are
not among those mentioned. This is a <a
href="https://caselaw.findlaw.com/us-federal-circuit/1189790.html">public
document</a> anyone can read. I'm a little surprised you didn't check
before asserting.
The anti-CoC dissidents don't have to rescind their license grant to
cause a great deal of trouble. Instead they can invoke the doctrine
established in Jacobsen vs. Katzer, seeking restraining orders.
They can do neither. There is no "doctrine established in Jacobsen."
The license terms of the GPLv2, GPLv3, and all related licenses
provide a mode of termination---for imposition of additional
restrictions or violation of other terms. This termination provision,
being explicit, is therefore the sole form of termination recognized
under the terms of the Copyright Act.
The line of argument is so simple that I could probably brief it
myself, and I'm not a lawyer
Law school exists to give people who are not yet lawyers a healthy
respect for what they cannot do. This discussion has been a riot of
amateur opining, but practicing law without a license is always a bad
idea.
For that matter, I don't think the question of whether the GPL can be
rescinded is settled - nor does my wife Cathy Raymond, Esq., a practicing
attorney who has also studied the relevant law.
It is settled. Indeed, it was never in doubt. When Jerry Cohen made
GPLv2 he was of course asked by Richard to make an irrevocable
license. He did so. The US law provides that this license cannot be
terminated except on its stated terms. But the basis of that rule,
which is statutory, was not reliable under non-US law, so in GPLv3 I
"codified" the US result in the license terms, as we did with various
other features in which GPLv2 assumed the US law background.
What the discussion set off by the present CoC controversy showed me
was that there was no accessible, legally-accurate description of US
copyright license termination law as it affects the various FOSS
licenses in particular. I wrote such an article and began preparing
it for publication, but was interrupted in that work by my mother's
last illness and death.
In the meantime everything said on all sides, for and against, has
been wrong. The correct legal analysis has been offered nowhere. As
I am beginning to return to work, I will publish the article soon.
For now, the headline is that Greg is correct. There is nothing in
the repeated assertions that some form of withdrawal of licensed rights
or attacks on the copyright status of the kernel are a possible
response to disagreement over changes in internal project governance.
It's a small point---and like all the other supposed points raised so
far, irrelevant---but I should say in passing, after years of teaching
the basic Property course at Columbia and Harvard law schools, that
Bruce Perens gave as succinct a description of the "rule against
perpetuities" as I ever hear from a beginner in the classroom. In the
English legal history course that I also teach (almost the only place
in a modern law school in which the law of future interests is
seriously considered), more is said. But the key point is that the
"rule against perpetuities" is not a rule against perpetuities. The
confusion on this point is one of the clearest signs that the writer
or writers using various pseudonyms is/are not, whatever s/he claims,
a US or UK lawyer at all.
Eben
--
Eben Moglen v: 212-461-1901
Professor of Law, Columbia Law School f: 212-854-7946 moglen@
435 West 116th Street, New York City, NY 10027 columbia.edu
Founding Director, Software Freedom Law Center softwarefreedom.org
Eben Moglen <[email protected]>:
> reputational damage is *specifically* recognized as grounds for relief.
>
> No. Reputational damage is not mentioned at all, let alone
> specifically recognized.
I have no difficulty in finding the word "reputation" in the brief in
in proximity with the phrase "increasing [the programmer's] recognition in
his profession". In fact the brief notes " The Eleventh Circuit has
recognized the economic motives inherent in public licenses, *even
where profit is not immediate*" (Emphasis mine.)
And "The attribution and modification transparency requirements
directly serve to drive traffic to the open source incubation page and
to inform downstream users of the project, which is a significant
economic goal of the copyright holder *that the law will enforce.*"
(Emphasis mine.)
You seem to be denying that the brief says what it actually says. It
not only qualifies reputational gain as a kind of economic
gain - and thus losses as damage - but cites the Eleventh Circuit as a
previous authority for the proposition, and affirms that these gains
and losses can be a matter for the law.
This disinclines me to trust the rest of your analysis or assertions.
I think you are advocating for your interest in the perceived
irrevocability of the GPL, and where this implies being less than fully
forthcoming about the actual risks in *this* situation you are committing
something perilously close to suppressio veri. This is not helpful.
I've lived with a practising attorney since about the time she was one
of the first-line legal reviewers for the original GPL back in the
1980s - we probably still have the draft printout with her scribbled
annotations on it somewhere. "Only lawyers can interpret this voodoo"
is not a good line to pull on me when it comes to open-source
licensing; I don't buy it and she wouldn't either.
Here's another sentence from the brief that I had forgotten:
"Copyright holders who engage in open source licensing have the right
to control the modification and distribution of copyrighted material."
- a particularly telling sentence in regard to the current
controversy, and one I had forgotten.
That there could be enough to win the day for the license
revokers - they don't actually have to revoke, just assert that
control. Pretty much equivalent to what the the Berne Convention's
moral-rights provision does in Europe - they could claim that the
CoC is a defacement of their work to which they refuse assent
and have a case.
I am not at all doubtful that the dissidents know these things; some
of the language in the broadsides to lkml so indicates. Which is why
I'm trying to get the kernel leadership to repair its unnecessarily
high-handed behavior before somebody gets pissed off enough to
actually drop a bomb.
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
On Friday, 26 October 2018, Eric S. Raymond wrote:
Eben Moglen <[email protected]>:
> reputational damage is *specifically* recognized as grounds for relief.
>
> No. Reputational damage is not mentioned at all, let alone
> specifically recognized.
I have no difficulty in finding the word "reputation" in the brief in
in proximity with the phrase "increasing [the programmer's]
recognition i
The parties' briefs are not the court opinion, and don't represent
what was decided. Wrong document. I linked to the opinion in my
message.
Eben
On 2018-10-26 13:15, Eben Moglen wrote:
> They can do neither. There is no "doctrine established in Jacobsen."
> The license terms of the GPLv2, GPLv3, and all related licenses
> provide a mode of termination---for imposition of additional
> restrictions or violation of other terms. This termination provision,
> being explicit, is therefore the sole form of termination recognized
> under the terms of the Copyright Act.
Incorrect. This rule is only valid for bargained-for copyright licenses
supported by consideration.
The GPLv2 is not such a situation for most licensees.
You are conflating case law dealing with commercial software and
non-gratuitous licenses with the present situation, which would likely
be a case of first-impression in nearly any jurisdiction.
The rule for gratuitous licenses is that they are revocable at the will
of the grantor.
Raymond Nimmer (God rest his soul) was in agreement on this point,
vis-a-vis the GPL and similar licenses.
On Friday, 26 October 2018, [email protected] wrote:
You are conflating case law dealing with commercial software and
non-gratuitous licenses with the present situation, which would likely
be a case of first-impression in nearly any jurisdiction.
I think the best procedure would be for me to publish my analysis and
for you then to tell me what is wrong with it. What you say here
sounds like what a lawyer might say, but isn't. I have been teaching
this stuff for about thirty years, so if I am conflating or confusing
anything I will be grateful for help in seeing my mistake.
The rule for gratuitous licenses is that they are revocable at the will
of the grantor.
That's not actually "the rule." It sounds like it might be the rule,
but it so happens that it's not. When I have given the explanation as
I have learned, taught and depended on it, you will be able to show me
what I am wrong about.
Raymond Nimmer (God rest his soul) was in agreement on this point,
vis-a-vis the GPL and similar licenses.
You have your Nimmers confused. The primary author of the treatise
Nimmer on Copyright (a book about the law, not in itself an authority)
was Melville Nimmer. The treatise is continued by his son, David, a
fine lawyer with whom I do from time to time politely disagree about
something. Ray Nimmer is quite another person.
Eben
--
Eben Moglen v: 212-461-1901
Professor of Law, Columbia Law School f: 212-854-7946 moglen@
435 West 116th Street, New York City, NY 10027 columbia.edu
Founding Director, Software Freedom Law Center softwarefreedom.org
On Fri, Oct 26 2018, Rainer Fiebig wrote:
> NeilBrown schrieb:
>> On Thu, Oct 25 2018, Rainer Fiebig wrote:
>>
>>> Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown:
>>>> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote:
>>>>> Hi all,
>>>>>
>>>>> As everyone knows by now, we added a new Code of Conduct to the kernel
>>>>> tree a few weeks ago.
>>>>
>>>> I wanted to stay detached from all this, but as remaining (publicly)
>>>> silent might be seen (publicly) as acquiescing, I hereby declare that:
>>>> I reject, as illegitimate, this Code and the process by
>>>> which it is being "developed".
>>>>
>>>> It is clear from the surrounding discussions that this is well outside our
>>>> core competencies. It will be flawed, it isn't what we need.
>>>>
>>>> I call on any other community members who reject this process to say so,
>>>> not to remain silent.
>>>> #Iobject
>>>>
>>>> We don't need a "Code of Conduct" nearly as much as we need "Leadership
>>>> in conduct". Without the leadership, any code looks like a joke.
>>>>
>>> [...]
>>>
>>>> I call on you, Greg:
>>>> - to abandon this divisive attempt to impose a "Code of Conduct"
>>>> - to revert 8a104f8b5867c68
>>>
>>> Yes but this seems increasingly unlikely now. However, there may be an
>>> alternative.
>>>
>>> Jugding by the release-message for 4.19, some people here are fans of
>>> Monty Python's. No wonder - as those guys are famous for being unrelenting
>>> supporters of Political Correctness.
>>>
>>> So one would be on the safe side if one just supplemented "Our Pledge"
>>> with this:
>>>
>>> "Everybody has the right to be offended."
>>>
>>> I think, John Cleese would also welcome this.[1]
>>>
>>> What do you think?
>>
>> I do think that giving certain rights to the community is a good thing:
>> - the right to tell anyone that their speech is hurtful
>> - the right to (patch) review by a third party.
>>
>> I don't think the right to be offended really needs to be given.
>> Yes, I know it is a joke and I do like Monty Python. I just don't think
>> it is particular helpful in this context. Maybe I missed something.
>
> Of course it's a joke and iirc it was indeed John Cleese who made it. But he
> made it for a reason, out of concern. It has a serious core.
>
> The question is: what *is* helpful in this matter?
>
> Just saying "this is not helpful" isn't helpful either. It's a well-known
> killer-phrase that has been used ad nauseam in this discussion. But an
> alternative is never given. And thus it's just an other way of saying
> "Eat it. And shut tf up!"
You asked me what I thought, and I told you what I thought.
If you think differently, you are quite welcome tell us - to explain the
way in which you think the addition would be helpful.
>
> Not even *constructive* criticism is helpful. AFAIK I'm the only one here who
> came up with a *complete* alternative - ignored. Others provided patches for
> certain sections - ignored. Data that indicate that this may be detrimental to
> Linux - ignored. Almost anything that was provided by me or others - ignored.
From my perspective, providing a complete alternative is no better than
what Greg did - provided a "complete" "code of conduct".
Engage in discussion, present your case, make me *want* to read your
document because you've shown me how it relates to me.
>
> What kind of community or attitude is this? This feels more like "The Wall" or
> North Korea than an Open-Source-project.
>
> And what beat everything was to misuse famously politically *in*correct Monty
> Python to malign criticism of this Political-Correctness-monster. The
> "People's Front" - message will forever be a prominent exhibit in "Monty
> Python's Hall of Shame". And the author should be banned from laughing about
> MP-sketches until he recants. Perhaps one should also report this incident to
> the "Ministry of Silly CoCs". ;)
>
>> For myself, I relinquish my right to be offended. I just don't do it.
>> It doesn't seem to be worth the effort.
>
> I don't. John Cleese is a smart guy. And he has a point.
>
>
> OK, thanks for your reply! But I think it's time for me to move on. "Cut your
> losses", as they say.
>
Thanks for participating!
NeilBrown
>
> Good luck and regards!
>
> Rainer Fiebig
On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote:
> On Wed, Oct 24 2018, Josh Triplett wrote:
>
> > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
> >> On Sun, Oct 21 2018, Josh Triplett wrote:
> >>
> >> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> >> >> I call on you, Greg:
> >> >> - to abandon this divisive attempt to impose a "Code of Conduct"
> >> >> - to revert 8a104f8b5867c68
> >> >> - to return to your core competence of building a great team around
> >> >> a great kernel
> >> >>
> >> >> #Isupportreversion
> >> >>
> >> >> I call on the community to consider what *does* need to be said, about
> >> >> conduct, to people outside the community and who have recently joined.
> >> >> What is the document that you would have liked to have read as you were
> >> >> starting out? It is all too long ago for me to remember clearly, and so
> >> >> much has changed.
> >> >
> >> > The document I would have liked to have read when starting out is
> >> > currently checked into the source tree in
> >> > Documentation/process/code-of-conduct.rst .
> >>
> >> I'm curious - what would you have gained by reading that document?
> >
> > I would have then had rather less of a pervasive feeling of "if I make
> > even a single mistake I get made an example of in ways that will feed
> > people's quotes files for years to come".
>
> Thanks for your reply. Certainly feeling safe is important, and having
> clear statements that the community values and promotes psychological
> safety is valuable.
>
> The old "code of conflict" said
> If however, anyone feels personally abused, threatened, or otherwise
> uncomfortable due to this process, that is not acceptable.
>
> would you have not found this a strong enough statement to ward off that
> pervasive feeling?
Not when that document started out effectively saying, in an elaborate
way, "code > people". (Leaving aside that the more important detail
would be the community actually acting consistently with the code of
conduct it espoused.)
> In the current code, would The "Our Pledge" section have been
> sufficient, or do you think the other sections would have actually
> helped you?
"Our Standards" would have been at least as important to me personally,
as would "Enforcement" (and more importantly, examples of that applying
in practice and not just as empty words).
Version 2 of the GPL forbids the incorporation of additional
restrictive terms, relating to the distribution, modification, etc of
the article licensed under the terms.
Those that violate this section are declared, by operation of the
terms, to have their grant automatically revoked.
An additional term need-not be present in the same writing. Such terms
simply need to be present to or made known to the taker(sub-licensee) by
the distributor. They may be proffered in writing, orally, or
implied in the course of doing business dealings. They simply must
relate back or involve the article in question (the licensed code or
product.)
The proffering of additional restrictive terms is a violation of the
text of the license grant in and of itself.
Here we have a situation where an additional writing has been
proffered. The additional writing promises both in it's own text and
by implication consequences against those who violate the terms of
this additional writing.
The additional writing restricts those subject to it from expressing
certain views publicly - promising retribution against those who do.
No consideration is paid to those subject to the additional writing
for their assent; it is simply imposed unilaterally against the
subjects.
The violators of the additional writing are promised:
Additional, unwanted, public scrutiny (to which they were not subject
to prior)
Public ridicule.
Loss of public standing.
as-well as an implied loss of future income.
These are the enforcement mechanisms of the additional writing to
enforce its restrictions against those who publish derivative works of
the kernel.
The additional writing is activated when (with the prerequisite of
being a derivative work of the linux kernel) the work of a rights-holder
is incorporated into the kernel, when such a work is made known to the
kernel-team to exist where any one person on this earth has seen fit
to present it for inclusion, or by simple prior-inclusion into the
kernel.
Thus all current and past rights-holders who have code in, or have
published for distribution, derivative works of the kernel are subject
to the retributive promises made to them in the additional writing,
drafted to restrict their actions and utterances.
This is tantamount to an additional restrictive term regarding the
modification and distribution of works under the linux kernel license
grant.
It is a violation of the license terms of the rights-holders past
incorporated works in much the same way that GRSecurity's
Contributor Access Agreement was and is.
Al: the FSF was so insistent on the adoption of the GPL version 3
because the GPL version 2 is not operative against the grantor.
This deficiency was, in their eyes, so fatal to the purposes that they
envisioned that they, as you have pointed out, elected to employ
enhanced means of converting projects to version 3.
Eben Moglen's contention that the GPL 3 exists to internationalize the
GPL is a lie of omission.
It is true that that is a partial reason-to-be for the GPL version 3
but it is not the main nor most important reason for the insistence on
version 3 or "v2 or any later version".
The very heart of the GPLv3 is the addition of the "irrevocable by
grantor" clause and the "term of years" clause.
Additionally the contention by the FSF and, as I recall, Eben Moglen
that the reason the FSF only accepts code where the copyright is
transferred to the FSF - is so they may have standing to sue - is
another lie by omission.
Yes, standing to sue is vital, if you are going to sue.
But the real beating heart of the copyright assignment policy is to
prevent a programmer from rescinding license-to-use regarding his
freely given code.
Without copyright assignment, any contributor to the GNU project could
elect to rescind the gratis license grant at his pleasure, at any
time, as of right.
Without an "irrevocable by grantor" clause (as seen in the GPL version
3, but omitted in GPL version 2 due to a mis-assumption on the part
of the drafter) there is not even an affirmative defense of promissory
estoppel.
We come to lie number three. (Neccecitated by:)
The incorrect assumption made by the
drafter of version 2 of the GPL and memorandized by Eben Moglen in
this very thread in an attempt to protect the error in drafting.
Lie number three: If terms regarding termination are proffered in a
copyright license they are the only means of termination.
This is true... If those terms are supported by bargained-for
consideration.
That is: the words Eben Moglen wrote were true; as regards to
commercial software, where the licensee has paid valuable
consideration for the terms offered.
The drafter of version 2 of the GPL was familiar with such commercial
licensing agreements. He failed in his due-diligence if RMS did
indeed request an irrevocable-by-grantor license. The drafter stopped
his research at the typical copyright license stage, and did not
research further into what underlays the construction there-of.
And thus we have the lie of omission number 3.
(All, naturally, to protect Eben Moglen's former client and to
discourage litigation where there is, indeed, good and sufficient
cause for such litigation) (Which is all part of an attorney's
duties, I can assure you)
On 2018-10-25 23:06, Al Viro wrote:
> On Thu, Oct 25, 2018 at 05:41:23PM -0400, Eric S. Raymond wrote:
>
>> I do not have any facts with which to dispute this specific claim.
>> However, I do notice that a significant number of long-time
>> contributors have put themselves in the anti-CoC camp. I note Al Viro
>> as a recent example.
>
> *snort*
>
> For the record:
> * CoC is a piss-poor match for the structure of community
> * Linus had essentially tossed a live grenade into an outhouse on
> his way to vacation, with quite predictable results - all kinds of
> interesting coprophagous fauna dropping by to feed, including
> cartooneys
> of the sort I hadn't seen since NANAE days.
> * As idiotic gambits go, "try and revoke the license on my
> contributions, so that they'll have to revoke CoC" is... impressive.
> Sadly, my command of English has turned out to be woefully inadequate,
> and I can't even blame that on not being a native speaker; I'm just as
> incapable of producing a coherent (let alone printable) description of
> that cunning plan in any language, Russian included. I've tried.
> Really.
> * in case it needs to be spelled out: I am not at all interested
> in that kind of stunts. One of the reasons I thoroughly despise RMS
> and his bunch is the leverage game they tried to play with GPLv3;
> damned if I'm going to lower myself to their level.
Lawrence Rosen is also in agreement on this point (regarding the GPL v2
specifically).
It is revocable at the will of the grantor, at any time.
(He writes that if a licensee-contributor was to sue a grantor, then
would be a good time to unilaterally rescind: disposing of the matter
entirely)
The contention that a copyright license is only terminable is
traditionally usually true in practice; but not because such is declared
by the Copyright Statute (such is not). It is because, in practice,
those terms are supported by consideration. Thus the licensee has payed
the grantor for those very terms to be in effect.
In the case of most users and most developers of the linux-kernel this
is not the case.
In-fact The very principal that, in the real world, precipitated the
widespread adoption of linux:
that no consideration is paid for receipt of the program.
The GPL v2 is not supported by consideration.
This is its strength.
And it is not something that can be disclaimed after the fact.
The drafter of version 2 of the GPL did, indeed, make an error in
drafting. He was, perhaps, familiar mostly with commercial copyright
licenses.
The foundation of the GPL does not rest on any contemplation of
quid-pro-quo or contract theories however;
it is on the simple declaration in the Copyright Statute that copyright
is alienable in all ways property is.
The GPL v2 is similar to a property license, and not a traditional
commercial copyright license.
On 2018-10-26 18:31, Eben Moglen wrote:
> On Friday, 26 October 2018, [email protected] wrote:
>
> You are conflating case law dealing with commercial software and
> non-gratuitous licenses with the present situation, which would
> likely
> be a case of first-impression in nearly any jurisdiction.
>
> I think the best procedure would be for me to publish my analysis and
> for you then to tell me what is wrong with it. What you say here
> sounds like what a lawyer might say, but isn't. I have been teaching
> this stuff for about thirty years, so if I am conflating or confusing
> anything I will be grateful for help in seeing my mistake.
>
> The rule for gratuitous licenses is that they are revocable at the
> will
> of the grantor.
>
> That's not actually "the rule." It sounds like it might be the rule,
> but it so happens that it's not. When I have given the explanation as
> I have learned, taught and depended on it, you will be able to show me
> what I am wrong about.
>
> Raymond Nimmer (God rest his soul) was in agreement on this point,
> vis-a-vis the GPL and similar licenses.
>
> You have your Nimmers confused. The primary author of the treatise
> Nimmer on Copyright (a book about the law, not in itself an authority)
> was Melville Nimmer. The treatise is continued by his son, David, a
> fine lawyer with whom I do from time to time politely disagree about
> something. Ray Nimmer is quite another person.
>
> Eben
On Sat, Oct 27, 2018 at 06:52:44AM +0000, [email protected] wrote:
> Al: the FSF was so insistent on the adoption of the GPL version 3
> because the GPL version 2 is not operative against the grantor.
Anonymous wankstain: sod off and learn to troll properly. It *is* an art
form, and the one you are clearly not up to.
D-. For the effort and successful use of spellchecker. The style and
contents are about F to E-, unfortunately, so take that in the spirit
in which it is offered. As a participation award, that is.
*plonk*
NeilBrown schrieb:
> On Fri, Oct 26 2018, Rainer Fiebig wrote:
>
>> NeilBrown schrieb:
>>> On Thu, Oct 25 2018, Rainer Fiebig wrote:
>>>
>>>> Am Montag, 22. Oktober 2018, 08:20:11 schrieb NeilBrown:
>>>>> On Sat, Oct 20 2018, Greg Kroah-Hartman wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> As everyone knows by now, we added a new Code of Conduct to the kernel
>>>>>> tree a few weeks ago.
>>>>>
>>>>> I wanted to stay detached from all this, but as remaining (publicly)
>>>>> silent might be seen (publicly) as acquiescing, I hereby declare that:
>>>>> I reject, as illegitimate, this Code and the process by
>>>>> which it is being "developed".
>>>>>
>>>>> It is clear from the surrounding discussions that this is well outside our
>>>>> core competencies. It will be flawed, it isn't what we need.
>>>>>
>>>>> I call on any other community members who reject this process to say so,
>>>>> not to remain silent.
>>>>> #Iobject
>>>>>
>>>>> We don't need a "Code of Conduct" nearly as much as we need "Leadership
>>>>> in conduct". Without the leadership, any code looks like a joke.
>>>>>
>>>> [...]
>>>>
>>>>> I call on you, Greg:
>>>>> - to abandon this divisive attempt to impose a "Code of Conduct"
>>>>> - to revert 8a104f8b5867c68
>>>>
>>>> Yes but this seems increasingly unlikely now. However, there may be an
>>>> alternative.
>>>>
>>>> Jugding by the release-message for 4.19, some people here are fans of
>>>> Monty Python's. No wonder - as those guys are famous for being unrelenting
>>>> supporters of Political Correctness.
>>>>
>>>> So one would be on the safe side if one just supplemented "Our Pledge"
>>>> with this:
>>>>
>>>> "Everybody has the right to be offended."
>>>>
>>>> I think, John Cleese would also welcome this.[1]
>>>>
>>>> What do you think?
>>>
>>> I do think that giving certain rights to the community is a good thing:
>>> - the right to tell anyone that their speech is hurtful
>>> - the right to (patch) review by a third party.
>>>
>>> I don't think the right to be offended really needs to be given.
>>> Yes, I know it is a joke and I do like Monty Python. I just don't think
>>> it is particular helpful in this context. Maybe I missed something.
>>
>> Of course it's a joke and iirc it was indeed John Cleese who made it. But he
>> made it for a reason, out of concern. It has a serious core.
>>
>> The question is: what *is* helpful in this matter?
>>
>> Just saying "this is not helpful" isn't helpful either. It's a well-known
>> killer-phrase that has been used ad nauseam in this discussion. But an
>> alternative is never given. And thus it's just an other way of saying
>> "Eat it. And shut tf up!"
>
> You asked me what I thought, and I told you what I thought.
> If you think differently, you are quite welcome tell us - to explain the
> way in which you think the addition would be helpful.
>
Neil, this is probably a misunderstanding. I really value your initiative and
dedication in this matter.
My suggestion of adding the "right to be offended" was of course just a
sarcastic joke. I thought this was obvious, especially since I provided the
link to the interview with John Cleese. But it wasn't obvious to you
and I'm sorry for that.
BTW - it just strikes me: perhaps this endless enumeration of
protected/privileged classes was also just a joke and *I* didn't see it? ;)
OK. "Not helpful":
This is indeed a killer-phrase used to suppress critique and to silence
people. I just wanted to expose this.
It was not directed at *you*. That's why I began my critique with
>> "The question is: what *is* helpful in this matter?"
>>
>> Not even *constructive* criticism is helpful. AFAIK I'm the only one here who
>> came up with a *complete* alternative - ignored. Others provided patches for
>> certain sections - ignored. Data that indicate that this may be detrimental to
>> Linux - ignored. Almost anything that was provided by me or others - ignored.
>
> From my perspective, providing a complete alternative is no better than
> what Greg did - provided a "complete" "code of conduct".
>
I think in your message of 10/21/18 you asked for it:
"What is the document that you would have liked to have read as you were
starting out? [...]"
In my reply I also made it clear that my suggestion was just intended as an
example that *of course* would have to be discussed:
"On the day the patch came out, I started working on a modified version,
a CoC that I could have lived with. [...].
So please find below what I would have submitted for discussion."
And if that's not *constructive* criticism, I don't know what is.
> Engage in discussion, present your case, make me *want* to read your
> document because you've shown me how it relates to me.
>
I think, I engaged in this discussion earlier than you did. My first post was
on 10/09/18.
And I have already presented my case several times, including examples for why
I'm opposed to this CoC, concrete proposals for modification and some data
that show that it may be detrimental to Linux. I also suggested to revert the
patch, set up a task-force to come up with an alternate CoC, discuss it etc.
And all of this early enough.
There's no point in repeating it. So - what else could I do?
And why should you *want* to read my document? I don't know. Perhaps because
you asked for it? Or to get some ideas how the same can be achieved without a
political sting? Up to you.
But I will definitely no longer participate in this discussion unless there
are clear indications by those who introduced this stuff that a discussion
is appreciated and its outcome may lead to changes in the CoC.
Because else I know of better ways to waste my time. ;)
Kind regards - and have a good weekend!
Rainer Fiebig
>>
>> What kind of community or attitude is this? This feels more like "The Wall" or
>> North Korea than an Open-Source-project.
>>
>> And what beat everything was to misuse famously politically *in*correct Monty
>> Python to malign criticism of this Political-Correctness-monster. The
>> "People's Front" - message will forever be a prominent exhibit in "Monty
>> Python's Hall of Shame". And the author should be banned from laughing about
>> MP-sketches until he recants. Perhaps one should also report this incident to
>> the "Ministry of Silly CoCs". ;)
>>
>>> For myself, I relinquish my right to be offended. I just don't do it.
>>> It doesn't seem to be worth the effort.
>>
>> I don't. John Cleese is a smart guy. And he has a point.
>>
>>
>> OK, thanks for your reply! But I think it's time for me to move on. "Cut your
>> losses", as they say.
>>
>
> Thanks for participating!
>
> NeilBrown
>
>>
>> Good luck and regards!
>>
>> Rainer Fiebig
> -----Original Message-----
> From: Al Viro
>
> On Sat, Oct 27, 2018 at 06:52:44AM +0000, [email protected] wrote:
> > Al: the FSF was so insistent on the adoption of the GPL version 3
> > because the GPL version 2 is not operative against the grantor.
>
> Anonymous wankstain: sod off and learn to troll properly. It *is* an art
> form, and the one you are clearly not up to.
>
> D-. For the effort and successful use of spellchecker. The style and
> contents are about F to E-, unfortunately, so take that in the spirit
> in which it is offered. As a participation award, that is.
Al,
Can you please, even in the face of comments you find irritating, keep your responses
more civil? Calling someone a "wankstain" is unprofessional, and we're trying
to raise the level of discourse here.
>
> *plonk*
I think this part of the response was sufficient to communicate that you do not
take the suggestions of the other party seriously. And it communicates
to others the right approach. If someone thinks that another person is acting in bad
faith, I think it's better to just stop listening to that person, and let that person know
it, and to let other community members know it. De-escalation is preferable to
engagement when working with someone who is acting in bad faith.
Although I disagree with the approach used in the top portion of this message, I am
grateful that you are committed to protecting Linux and our development community.
Regards,
-- Tim
On Sat, 27 Oct 2018, [email protected] wrote:
> Al,
>
> Can you please, even in the face of comments you find irritating, keep
> your responses more civil? Calling someone a "wankstain" is
> unprofessional
Tim,
to be completely honest, communicating anonymously doesn't really match my
"this is highly professional" standards either, so I don't think we should
be losing too much sleep over this particular e-mail exchange.
CoC explicitly requires us to be reasonably nice to the human being on the
other end of the wire, which I whole-heartedly believe is a very noble and
nice goal. But you really have to know at least a little bit who's there
on the other end. Otherwise failure to communicate might be sort of
inevitable.
--
Jiri Kosina
SUSE Labs
On Sun, Oct 28 2018, Jiri Kosina wrote:
> On Sat, 27 Oct 2018, [email protected] wrote:
>
>> Al,
>>
>> Can you please, even in the face of comments you find irritating, keep
>> your responses more civil? Calling someone a "wankstain" is
>> unprofessional
>
> Tim,
>
> to be completely honest, communicating anonymously doesn't really match my
> "this is highly professional" standards either, so I don't think we should
> be losing too much sleep over this particular e-mail exchange.
I agree with Tim here. It doesn't really matter who (or what) you are
talking to, what matters is the context in which you are talking.
We seem to be trying to raise the standard of communication within the
kernel community. That means all communication.
>
> CoC explicitly requires us to be reasonably nice to the human being on the
> other end of the wire, which I whole-heartedly believe is a very noble and
> nice goal. But you really have to know at least a little bit who's there
> on the other end. Otherwise failure to communicate might be sort of
> inevitable.
As you know, I think the CoC is a mistake and should be removed.
But seeing you to play that game:
1/ code-of-conduct.rst doesn't contain the word "human" at all
2/ code-of-conduect-interpretation.rst explicitly says
We know everyone is human
which could be read as implying that you need to treat the other
person as human, even if they don't act that way.
Do you *really* want to use the CoC to support your position?
Thanks,
NeilBrown
>
> --
> Jiri Kosina
> SUSE Labs
On Sat, Oct 27 2018, Josh Triplett wrote:
> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote:
>> On Wed, Oct 24 2018, Josh Triplett wrote:
>>
>> > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
>> >> On Sun, Oct 21 2018, Josh Triplett wrote:
>> >>
>> >> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
>> >> >> I call on you, Greg:
>> >> >> - to abandon this divisive attempt to impose a "Code of Conduct"
>> >> >> - to revert 8a104f8b5867c68
>> >> >> - to return to your core competence of building a great team around
>> >> >> a great kernel
>> >> >>
>> >> >> #Isupportreversion
>> >> >>
>> >> >> I call on the community to consider what *does* need to be said, about
>> >> >> conduct, to people outside the community and who have recently joined.
>> >> >> What is the document that you would have liked to have read as you were
>> >> >> starting out? It is all too long ago for me to remember clearly, and so
>> >> >> much has changed.
>> >> >
>> >> > The document I would have liked to have read when starting out is
>> >> > currently checked into the source tree in
>> >> > Documentation/process/code-of-conduct.rst .
>> >>
>> >> I'm curious - what would you have gained by reading that document?
>> >
>> > I would have then had rather less of a pervasive feeling of "if I make
>> > even a single mistake I get made an example of in ways that will feed
>> > people's quotes files for years to come".
>>
>> Thanks for your reply. Certainly feeling safe is important, and having
>> clear statements that the community values and promotes psychological
>> safety is valuable.
>>
>> The old "code of conflict" said
>> If however, anyone feels personally abused, threatened, or otherwise
>> uncomfortable due to this process, that is not acceptable.
>>
>> would you have not found this a strong enough statement to ward off that
>> pervasive feeling?
>
> Not when that document started out effectively saying, in an elaborate
> way, "code > people". (Leaving aside that the more important detail
> would be the community actually acting consistently with the code of
> conduct it espoused.)
I certainly cannot argue with that. .... that those starting words have
been preserved in the code-of-conduct-interpretation.rst, so we still
have them.
>
>> In the current code, would The "Our Pledge" section have been
>> sufficient, or do you think the other sections would have actually
>> helped you?
>
> "Our Standards" would have been at least as important to me personally,
> as would "Enforcement" (and more importantly, examples of that applying
> in practice and not just as empty words).
I find it interesting that you appear to particularly value the
Enforcement section, I particularly dislike it.
It is also interesting that you seem to fear that it might be "empty
words", and elsewhere in this thread Laura Abbott wondered
Will those problems actually be handled appropriately when the time
comes? I can't actually say for sure
She goes on to opine that trust is needed, but if we really had trust,
we might not need the code.
None of us, to my knowledge, has credible expertise or demonstrated
experience in this area, so we might easily become the blind misleading
the blind. However I would like to make one more attempt to give
context and meaning to my dislike for that section.
The approach described seem to be combative rather than conciliatory.
The first action-step described is to mark a report - to complain. This
isn't quite as bad as being litigious, but it seems headed in that
direction. I would rather we gave people the power to resolve their own
issues, rather than an avenue to magnify them but involving others.
Think for a moment about how we resolve technical differences. I
acknowledge that we don't always resolve them very well, but when we do
- what techniques seem to work? We don't have any court to which we can
apply to resolve our differences, we need to present our case and garner
support from like-minded people. To help with that, we do have some
standards like "no regressions" and "maintainable" and various
coding-style guidelines. They don't necessarily answer everything but
they help. Over all this, there is a general principle that the person
who writes the code makes the decisions - "code talks". The person who
puts in the effort gets heard more than the person who complains from
the side lines. This isn't all perfect, but it largely works, and we
are familiar with it.
Can we translate any of that experience to the social/harm side of
things?
1/ We can have some standards. We will never all agree on the level
of detail needed (but then, we don't all agree on checkpatch.pl
either), but anything generally in the right direction would help (I
like "Be helpful. Don't be harmful". "Be kind to each other" is in
the interpretation).
2/ We can voice our support when we see a cause the we agree with,
whether it is a revised API, or discomfort with a particular
word-choice.
3/ We can make sure that people who have done valuable work (written a
patch, found a bug, etc) have a place where they can be heard, even if
they find the need to filter all messages from an unrepentant abuser.
I think our practice, in the technical sphere, has generally been
towards conciliation, not combat. I think that is the experience that
we should try to leverage in the more social sphere.
A useful side-node is that "hurting people hurt people". If someone
does hurt you, there is a good chance that they are hurting themselves.
Do you want to increase that hurt by fighting back? Would it not be
better to simply side-step.
Thanks,
NeilBrown
On Thu, Oct 25, 2018 at 07:56:26AM +0000, [email protected] wrote:
> The linux devs can rescind their license grant.
Greg KH responded on Thu, 25 Oct 2018 09:19:11 +0100:
>> No they can not, please do not keep spreading false information.
I was explicitly cc'ed on this thread by visionsofalice. I've read the
whole thread, and the only useful thing I can contribute here is to agree
with Greg and additionally provide some backup research on the point:
https://sfconservancy.org/news/2018/sep/26/GPLv2-irrevocability/
Software Freedom Conservancy engaged our legal counsel to write a new
section for the Copyleft Guide that further explains the irrevocability of
GPLv2. We published this when others raised these specious claims back in
September. Direct link to new section:
https://copyleft.org/guide/comprehensive-gpl-guidech8.html#x11-540007.4
HTH,
--
Bradley M. Kuhn
Distinguished Technologist of Software Freedom Conservancy
========================================================================
Become a Conservancy Supporter today: https://sfconservancy.org/supporter
On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote:
> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote:
> > On Wed, Oct 24 2018, Josh Triplett wrote:
> >
> > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
> > >> On Sun, Oct 21 2018, Josh Triplett wrote:
> > >>
> > >> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> > >> >> I call on you, Greg:
> > >> >> - to abandon this divisive attempt to impose a "Code of Conduct"
> > >> >> - to revert 8a104f8b5867c68
> > >> >> - to return to your core competence of building a great team around
> > >> >> a great kernel
> > >> >>
> > >> >> #Isupportreversion
> > >> >>
> > >> >> I call on the community to consider what *does* need to be said, about
> > >> >> conduct, to people outside the community and who have recently joined.
> > >> >> What is the document that you would have liked to have read as you were
> > >> >> starting out? It is all too long ago for me to remember clearly, and so
> > >> >> much has changed.
> > >> >
> > >> > The document I would have liked to have read when starting out is
> > >> > currently checked into the source tree in
> > >> > Documentation/process/code-of-conduct.rst .
> > >>
> > >> I'm curious - what would you have gained by reading that document?
> > >
> > > I would have then had rather less of a pervasive feeling of "if I make
> > > even a single mistake I get made an example of in ways that will feed
> > > people's quotes files for years to come".
> >
> > Thanks for your reply. Certainly feeling safe is important, and having
> > clear statements that the community values and promotes psychological
> > safety is valuable.
> >
> > The old "code of conflict" said
> > If however, anyone feels personally abused, threatened, or otherwise
> > uncomfortable due to this process, that is not acceptable.
> >
> > would you have not found this a strong enough statement to ward off that
> > pervasive feeling?
>
> Not when that document started out effectively saying, in an elaborate
> way, "code > people".
Interesting.
I am curious what leads you to your "code > people" statement. Of course,
one could argue that this does not really matter given that the code of
conflict is no longer. However, I would like to understand for future
reference, if for no other reason.
One possibility is that you are restricting the "people" to only those
people directly contributing in one way or another. But those using the
kernel (both directly and indirectly) are important as well, and it is
exactly this group that is served by "the most robust operating system
kernel ever", the chest-beating sentiment notwithstanding. Which is in
fact why I must reject (or rework or whatever) any patch that might result
in too-short RCU grace periods: The needs of the patch's submitter are
quite emphatically outweighed by the needs of the kernel's many users,
and many of the various technical requirements and restrictions are in
fact proxies for the needs of these users.
But you knew that already.
Similarly for the Linux kernel's various code-style strictures, which
serve the surprisingly large group of people reading the kernel's code.
Including the stricture that I most love to hate, which is the one
stating that single-line do/for/if/while statements must not be enclosed
in braces, which sometimes causes me trouble when inserting debug code,
but which also makes more code fit into a window of a given size. ;-)
But you knew that already, too.
The maintainability requirements can be argued to mostly serve the
maintainers, but if the code becomes unmaintainable, future users
will be inconvenienced, to say the least. So even the maintainability
requirements serve the kernel's many users.
But you also knew that already.
So what am I missing here?
Thanx, Paul
> (Leaving aside that the more important detail
> would be the community actually acting consistently with the code of
> conduct it espoused.)
>
> > In the current code, would The "Our Pledge" section have been
> > sufficient, or do you think the other sections would have actually
> > helped you?
>
> "Our Standards" would have been at least as important to me personally,
> as would "Enforcement" (and more importantly, examples of that applying
> in practice and not just as empty words).
> _______________________________________________
> Ksummit-discuss mailing list
> [email protected]
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>
On Thu, Nov 01, 2018 at 09:45:44AM -0700, Paul E. McKenney wrote:
> On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote:
> > Not when that document started out effectively saying, in an elaborate
> > way, "code > people".
>
> Interesting.
>
> I am curious what leads you to your "code > people" statement. Of course,
> one could argue that this does not really matter given that the code of
> conflict is no longer. However, I would like to understand for future
> reference, if for no other reason.
>
> One possibility is that you are restricting the "people" to only those
> people directly contributing in one way or another. But those using the
> kernel (both directly and indirectly) are important as well, and it is
> exactly this group that is served by "the most robust operating system
> kernel ever", the chest-beating sentiment notwithstanding. Which is in
> fact why I must reject (or rework or whatever) any patch that might result
> in too-short RCU grace periods: The needs of the patch's submitter are
> quite emphatically outweighed by the needs of the kernel's many users,
> and many of the various technical requirements and restrictions are in
> fact proxies for the needs of these users.
As discussed in many other places as well, nobody is suggesting at all
that the standards for accepting code should change. Reject the patches
you would have rejected, accept the patches you would have accepted. All
of this affects *communication*.
- Josh Triplett
On Thu, Nov 01 2018, Paul E. McKenney wrote:
> On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote:
>> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote:
>> > On Wed, Oct 24 2018, Josh Triplett wrote:
>> >
>> > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
>> > >> On Sun, Oct 21 2018, Josh Triplett wrote:
>> > >>
>> > >> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
>> > >> >> I call on you, Greg:
>> > >> >> - to abandon this divisive attempt to impose a "Code of Conduct"
>> > >> >> - to revert 8a104f8b5867c68
>> > >> >> - to return to your core competence of building a great team around
>> > >> >> a great kernel
>> > >> >>
>> > >> >> #Isupportreversion
>> > >> >>
>> > >> >> I call on the community to consider what *does* need to be said, about
>> > >> >> conduct, to people outside the community and who have recently joined.
>> > >> >> What is the document that you would have liked to have read as you were
>> > >> >> starting out? It is all too long ago for me to remember clearly, and so
>> > >> >> much has changed.
>> > >> >
>> > >> > The document I would have liked to have read when starting out is
>> > >> > currently checked into the source tree in
>> > >> > Documentation/process/code-of-conduct.rst .
>> > >>
>> > >> I'm curious - what would you have gained by reading that document?
>> > >
>> > > I would have then had rather less of a pervasive feeling of "if I make
>> > > even a single mistake I get made an example of in ways that will feed
>> > > people's quotes files for years to come".
>> >
>> > Thanks for your reply. Certainly feeling safe is important, and having
>> > clear statements that the community values and promotes psychological
>> > safety is valuable.
>> >
>> > The old "code of conflict" said
>> > If however, anyone feels personally abused, threatened, or otherwise
>> > uncomfortable due to this process, that is not acceptable.
>> >
>> > would you have not found this a strong enough statement to ward off that
>> > pervasive feeling?
>>
>> Not when that document started out effectively saying, in an elaborate
>> way, "code > people".
>
> Interesting.
>
> I am curious what leads you to your "code > people" statement. Of course,
> one could argue that this does not really matter given that the code of
> conflict is no longer. However, I would like to understand for future
> reference, if for no other reason.
>
> One possibility is that you are restricting the "people" to only those
> people directly contributing in one way or another. But those using the
> kernel (both directly and indirectly) are important as well, and it is
> exactly this group that is served by "the most robust operating system
> kernel ever", the chest-beating sentiment notwithstanding. Which is in
> fact why I must reject (or rework or whatever) any patch that might result
> in too-short RCU grace periods: The needs of the patch's submitter are
> quite emphatically outweighed by the needs of the kernel's many users,
> and many of the various technical requirements and restrictions are in
> fact proxies for the needs of these users.
>
> But you knew that already.
>
> Similarly for the Linux kernel's various code-style strictures, which
> serve the surprisingly large group of people reading the kernel's code.
> Including the stricture that I most love to hate, which is the one
> stating that single-line do/for/if/while statements must not be enclosed
> in braces, which sometimes causes me trouble when inserting debug code,
> but which also makes more code fit into a window of a given size. ;-)
>
> But you knew that already, too.
>
> The maintainability requirements can be argued to mostly serve the
> maintainers, but if the code becomes unmaintainable, future users
> will be inconvenienced, to say the least. So even the maintainability
> requirements serve the kernel's many users.
>
> But you also knew that already.
>
> So what am I missing here?
>
Hi Paul,
thanks for contributing your thoughts. It is nice to have a new voice
in the conversation, it helps me to maintain my illusion that this
issue is relevant to the whole community.
I cannot, of course, speak to why Josh wrote what he did, but I can
give some insight into why I had no disagreement with that part of his
statement.
A key insight, worth your time to consider and unpack I think, is
People won't care what you know, until they know that you care.
I won't dwell on that here, but will make some more obviously relevant
observations.
Firstly, you gave an analytical response to what was, in my view, an
emotional observation. While I agree with your analysis, it is largely
irrelevant. It is not how people *feel* about kernel development.
You say that the code of conflict is gone, but in fact much of it is
preserved in the code-of-conduct-interpretation. If you reflect on the
focus of the second para of that document (which I think was directly
lifted from the code-of-conflict) you will see that value is placed
squarely on the code (kernel code, not code of conduct). The code is
put forward as the thing of primary importance. People (you, me) are
only mentioned in the context of being the authors of code that will be
criticised - because (it almost says this) we care about the code, but
not about you.
So I think it is beyond argument that the value system presented by
this paragraph is
code > people
I think this is particularly unfortunate as it is not really how the
community works, and not really how Linus works, except in those
occasional outbursts that are publicised so much.
I recall two specific events (there were probably others) from early in
my Linux experience where Linus said/did things which said to me that
he valued me, not just the code that I wrote. I think he did that a
lot (and probably still does). As I knew that he "cared", I was much
more interested in what he knew/thought.
I think that the fact that Linus is now acknowledging every "pull"
request is brilliant. It doesn't really help the process much (we all
have plenty of visibility into what Linus has pulled) and doesn't help
the code (directly) at all. But it tells people that Linus can see
them, and has seen them. It also allows people to see that they have
an email from Linus without expecting it to be a criticism. Certainly
he still criticises and is right to do so, and he doesn't say "Pulled,
thanks", which would be my preference, but the fact that he responds at
least says "me responding to you matters" and by implication "you
matter".
(The code-of-conflict only acknowledged that you matter once you feel
personally abused).
Thanks,
NeilBrown
> Thanx, Paul
>
>> (Leaving aside that the more important detail
>> would be the community actually acting consistently with the code of
>> conduct it espoused.)
>>
>> > In the current code, would The "Our Pledge" section have been
>> > sufficient, or do you think the other sections would have actually
>> > helped you?
>>
>> "Our Standards" would have been at least as important to me personally,
>> as would "Enforcement" (and more importantly, examples of that applying
>> in practice and not just as empty words).
>> _______________________________________________
>> Ksummit-discuss mailing list
>> [email protected]
>> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>>
On Thu, Nov 01, 2018 at 02:11:53PM -0700, Josh Triplett wrote:
> On Thu, Nov 01, 2018 at 09:45:44AM -0700, Paul E. McKenney wrote:
> > On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote:
> > > Not when that document started out effectively saying, in an elaborate
> > > way, "code > people".
> >
> > Interesting.
> >
> > I am curious what leads you to your "code > people" statement. Of course,
> > one could argue that this does not really matter given that the code of
> > conflict is no longer. However, I would like to understand for future
> > reference, if for no other reason.
> >
> > One possibility is that you are restricting the "people" to only those
> > people directly contributing in one way or another. But those using the
> > kernel (both directly and indirectly) are important as well, and it is
> > exactly this group that is served by "the most robust operating system
> > kernel ever", the chest-beating sentiment notwithstanding. Which is in
> > fact why I must reject (or rework or whatever) any patch that might result
> > in too-short RCU grace periods: The needs of the patch's submitter are
> > quite emphatically outweighed by the needs of the kernel's many users,
> > and many of the various technical requirements and restrictions are in
> > fact proxies for the needs of these users.
>
> As discussed in many other places as well, nobody is suggesting at all
> that the standards for accepting code should change. Reject the patches
> you would have rejected, accept the patches you would have accepted.
There have been a great many discussions in a great many places expressing
a great many views, but it is good to hear your view on this particular
point. It should come as no surprise that I advise you in the strongest
possible terms to continue with the view that standards for accepting code
into the Linux kernel should not decrease.
> All
> of this affects *communication*.
Communication is inherently difficult. As I suspect the two of us just
demonstrated. ;-)
Thanx, Paul
On Fri, Nov 02, 2018 at 08:50:11AM +1100, NeilBrown wrote:
> On Thu, Nov 01 2018, Paul E. McKenney wrote:
>
> > On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote:
> >> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote:
> >> > On Wed, Oct 24 2018, Josh Triplett wrote:
> >> >
> >> > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
> >> > >> On Sun, Oct 21 2018, Josh Triplett wrote:
> >> > >>
> >> > >> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> >> > >> >> I call on you, Greg:
> >> > >> >> - to abandon this divisive attempt to impose a "Code of Conduct"
> >> > >> >> - to revert 8a104f8b5867c68
> >> > >> >> - to return to your core competence of building a great team around
> >> > >> >> a great kernel
> >> > >> >>
> >> > >> >> #Isupportreversion
> >> > >> >>
> >> > >> >> I call on the community to consider what *does* need to be said, about
> >> > >> >> conduct, to people outside the community and who have recently joined.
> >> > >> >> What is the document that you would have liked to have read as you were
> >> > >> >> starting out? It is all too long ago for me to remember clearly, and so
> >> > >> >> much has changed.
> >> > >> >
> >> > >> > The document I would have liked to have read when starting out is
> >> > >> > currently checked into the source tree in
> >> > >> > Documentation/process/code-of-conduct.rst .
> >> > >>
> >> > >> I'm curious - what would you have gained by reading that document?
> >> > >
> >> > > I would have then had rather less of a pervasive feeling of "if I make
> >> > > even a single mistake I get made an example of in ways that will feed
> >> > > people's quotes files for years to come".
> >> >
> >> > Thanks for your reply. Certainly feeling safe is important, and having
> >> > clear statements that the community values and promotes psychological
> >> > safety is valuable.
> >> >
> >> > The old "code of conflict" said
> >> > If however, anyone feels personally abused, threatened, or otherwise
> >> > uncomfortable due to this process, that is not acceptable.
> >> >
> >> > would you have not found this a strong enough statement to ward off that
> >> > pervasive feeling?
> >>
> >> Not when that document started out effectively saying, in an elaborate
> >> way, "code > people".
> >
> > Interesting.
> >
> > I am curious what leads you to your "code > people" statement. Of course,
> > one could argue that this does not really matter given that the code of
> > conflict is no longer. However, I would like to understand for future
> > reference, if for no other reason.
> >
> > One possibility is that you are restricting the "people" to only those
> > people directly contributing in one way or another. But those using the
> > kernel (both directly and indirectly) are important as well, and it is
> > exactly this group that is served by "the most robust operating system
> > kernel ever", the chest-beating sentiment notwithstanding. Which is in
> > fact why I must reject (or rework or whatever) any patch that might result
> > in too-short RCU grace periods: The needs of the patch's submitter are
> > quite emphatically outweighed by the needs of the kernel's many users,
> > and many of the various technical requirements and restrictions are in
> > fact proxies for the needs of these users.
> >
> > But you knew that already.
> >
> > Similarly for the Linux kernel's various code-style strictures, which
> > serve the surprisingly large group of people reading the kernel's code.
> > Including the stricture that I most love to hate, which is the one
> > stating that single-line do/for/if/while statements must not be enclosed
> > in braces, which sometimes causes me trouble when inserting debug code,
> > but which also makes more code fit into a window of a given size. ;-)
> >
> > But you knew that already, too.
> >
> > The maintainability requirements can be argued to mostly serve the
> > maintainers, but if the code becomes unmaintainable, future users
> > will be inconvenienced, to say the least. So even the maintainability
> > requirements serve the kernel's many users.
> >
> > But you also knew that already.
> >
> > So what am I missing here?
> >
>
> Hi Paul,
> thanks for contributing your thoughts. It is nice to have a new voice
> in the conversation, it helps me to maintain my illusion that this
> issue is relevant to the whole community.
I am not sure whether I should feel Australia-style chastened,
American-style encouraged, or what, but either way, good show on that
paragraph. ;-)
> I cannot, of course, speak to why Josh wrote what he did, but I can
> give some insight into why I had no disagreement with that part of his
> statement.
> A key insight, worth your time to consider and unpack I think, is
>
> People won't care what you know, until they know that you care.
>
> I won't dwell on that here, but will make some more obviously relevant
> observations.
>
> Firstly, you gave an analytical response to what was, in my view, an
> emotional observation. While I agree with your analysis, it is largely
> irrelevant. It is not how people *feel* about kernel development.
>
> You say that the code of conflict is gone, but in fact much of it is
> preserved in the code-of-conduct-interpretation. If you reflect on the
> focus of the second para of that document (which I think was directly
> lifted from the code-of-conflict) you will see that value is placed
> squarely on the code (kernel code, not code of conduct). The code is
> put forward as the thing of primary importance. People (you, me) are
> only mentioned in the context of being the authors of code that will be
> criticised - because (it almost says this) we care about the code, but
> not about you.
>
> So I think it is beyond argument that the value system presented by
> this paragraph is
> code > people
>
> I think this is particularly unfortunate as it is not really how the
> community works, and not really how Linus works, except in those
> occasional outbursts that are publicised so much.
>
> I recall two specific events (there were probably others) from early in
> my Linux experience where Linus said/did things which said to me that
> he valued me, not just the code that I wrote. I think he did that a
> lot (and probably still does). As I knew that he "cared", I was much
> more interested in what he knew/thought.
>
> I think that the fact that Linus is now acknowledging every "pull"
> request is brilliant. It doesn't really help the process much (we all
> have plenty of visibility into what Linus has pulled) and doesn't help
> the code (directly) at all. But it tells people that Linus can see
> them, and has seen them. It also allows people to see that they have
> an email from Linus without expecting it to be a criticism. Certainly
> he still criticises and is right to do so, and he doesn't say "Pulled,
> thanks", which would be my preference, but the fact that he responds at
> least says "me responding to you matters" and by implication "you
> matter".
>
> (The code-of-conflict only acknowledged that you matter once you feel
> personally abused).
I agree that Linus's acknowledging pull requests is a good thing. I have
long appreciated my upstream maintainer doing the same, and I do try to
acknowledge patch submissions myself. And yes, motivating people is an
underappreciated art, and an art made more difficult by the wide variety
of mindsets, even within a relatively like-minded community such as the
Linux kernel community. So I agree that improvements are welcome, and
further believe that there always will be room for improvement.
But I am still not seeing "code > people" in the interpretation document.
For me, it is all about people.
Back to "People won't care what you know, until they know that you care."
Fortunately for me, it is not necessary for all that many people to care
what I know, given that I have the usual human limitations on the number
of individuals that I can directly relate to, and this number is way
less than the billions that have some relationship to the Linux kernel,
unwitting though that relationship is in the common case.
In contrast, back in the late 70s, my software had two users, and I
frequently chatted with both of them. This is clearly not possible in
the case of the Linux kernel. Nor would it be all that helpful, given
that all they really need from me is to keep RCU working properly.
So I instead create an abstraction of those users' needs in the form
of requirements. These requirements might seem dull and uninspiring,
but they are in fact a proxy for the needs of the users.
In short, instead of "code > people", I am seeing "our users need us".
Thanx, Paul
> Thanks,
> NeilBrown
>
>
> > Thanx, Paul
> >
> >> (Leaving aside that the more important detail
> >> would be the community actually acting consistently with the code of
> >> conduct it espoused.)
> >>
> >> > In the current code, would The "Our Pledge" section have been
> >> > sufficient, or do you think the other sections would have actually
> >> > helped you?
> >>
> >> "Our Standards" would have been at least as important to me personally,
> >> as would "Enforcement" (and more importantly, examples of that applying
> >> in practice and not just as empty words).
> >> _______________________________________________
> >> Ksummit-discuss mailing list
> >> [email protected]
> >> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> >>
On Fri, 2018-11-02 at 08:50 +1100, NeilBrown wrote:
> Firstly, you gave an analytical response to what was, in my view, an
> emotional observation. While I agree with your analysis, it is
> largely irrelevant. It is not how people *feel* about kernel
> development.
>
> You say that the code of conflict is gone, but in fact much of it is
> preserved in the code-of-conduct-interpretation. If you reflect on
> the focus of the second para of that document (which I think was
> directly lifted from the code-of-conflict) you will see that value
> is placed squarely on the code (kernel code, not code of
> conduct). The code is put forward as the thing of primary
> importance. People (you, me) are only mentioned in the context of
> being the authors of code that will be criticised - because (it
> almost says this) we care about the code, but not about you.
>
> So I think it is beyond argument that the value system presented by
> this paragraph is
> code > people
Actually, I think this whole code vs people debate is a straw man and
inherently inimical to the discussion. In neither code of conduct (old
or new) is there any statement that allows one to make a value judgment
of people relative to code, so the very premise you're all arguing on
doesn't exist.
The two separate, but related statements present in both systems are
that the technical quality of the code going into the kernel is
paramount and that we should try to be respectful of others in email or
other interactions including code reviews. Code and people aren't
opposites: you can give purely technical reviews with a laser like
focus on quality and still do it respectfully. Or to put it another
way: respecting code doesn't automatically mean you disrespect people,
which seems to be what the '>' was implying.
James
On Fri, Nov 02 2018, Paul E. McKenney wrote:
> On Fri, Nov 02, 2018 at 08:50:11AM +1100, NeilBrown wrote:
>> On Thu, Nov 01 2018, Paul E. McKenney wrote:
>>
>> > On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote:
>> >> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote:
>> >> > On Wed, Oct 24 2018, Josh Triplett wrote:
>> >> >
>> >> > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
>> >> > >> On Sun, Oct 21 2018, Josh Triplett wrote:
>> >> > >>
>> >> > >> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
>> >> > >> >> I call on you, Greg:
>> >> > >> >> - to abandon this divisive attempt to impose a "Code of Conduct"
>> >> > >> >> - to revert 8a104f8b5867c68
>> >> > >> >> - to return to your core competence of building a great team around
>> >> > >> >> a great kernel
>> >> > >> >>
>> >> > >> >> #Isupportreversion
>> >> > >> >>
>> >> > >> >> I call on the community to consider what *does* need to be said, about
>> >> > >> >> conduct, to people outside the community and who have recently joined.
>> >> > >> >> What is the document that you would have liked to have read as you were
>> >> > >> >> starting out? It is all too long ago for me to remember clearly, and so
>> >> > >> >> much has changed.
>> >> > >> >
>> >> > >> > The document I would have liked to have read when starting out is
>> >> > >> > currently checked into the source tree in
>> >> > >> > Documentation/process/code-of-conduct.rst .
>> >> > >>
>> >> > >> I'm curious - what would you have gained by reading that document?
>> >> > >
>> >> > > I would have then had rather less of a pervasive feeling of "if I make
>> >> > > even a single mistake I get made an example of in ways that will feed
>> >> > > people's quotes files for years to come".
>> >> >
>> >> > Thanks for your reply. Certainly feeling safe is important, and having
>> >> > clear statements that the community values and promotes psychological
>> >> > safety is valuable.
>> >> >
>> >> > The old "code of conflict" said
>> >> > If however, anyone feels personally abused, threatened, or otherwise
>> >> > uncomfortable due to this process, that is not acceptable.
>> >> >
>> >> > would you have not found this a strong enough statement to ward off that
>> >> > pervasive feeling?
>> >>
>> >> Not when that document started out effectively saying, in an elaborate
>> >> way, "code > people".
>> >
>> > Interesting.
>> >
>> > I am curious what leads you to your "code > people" statement. Of course,
>> > one could argue that this does not really matter given that the code of
>> > conflict is no longer. However, I would like to understand for future
>> > reference, if for no other reason.
>> >
>> > One possibility is that you are restricting the "people" to only those
>> > people directly contributing in one way or another. But those using the
>> > kernel (both directly and indirectly) are important as well, and it is
>> > exactly this group that is served by "the most robust operating system
>> > kernel ever", the chest-beating sentiment notwithstanding. Which is in
>> > fact why I must reject (or rework or whatever) any patch that might result
>> > in too-short RCU grace periods: The needs of the patch's submitter are
>> > quite emphatically outweighed by the needs of the kernel's many users,
>> > and many of the various technical requirements and restrictions are in
>> > fact proxies for the needs of these users.
>> >
>> > But you knew that already.
>> >
>> > Similarly for the Linux kernel's various code-style strictures, which
>> > serve the surprisingly large group of people reading the kernel's code.
>> > Including the stricture that I most love to hate, which is the one
>> > stating that single-line do/for/if/while statements must not be enclosed
>> > in braces, which sometimes causes me trouble when inserting debug code,
>> > but which also makes more code fit into a window of a given size. ;-)
>> >
>> > But you knew that already, too.
>> >
>> > The maintainability requirements can be argued to mostly serve the
>> > maintainers, but if the code becomes unmaintainable, future users
>> > will be inconvenienced, to say the least. So even the maintainability
>> > requirements serve the kernel's many users.
>> >
>> > But you also knew that already.
>> >
>> > So what am I missing here?
>> >
>>
>> Hi Paul,
>> thanks for contributing your thoughts. It is nice to have a new voice
>> in the conversation, it helps me to maintain my illusion that this
>> issue is relevant to the whole community.
>
> I am not sure whether I should feel Australia-style chastened,
> American-style encouraged, or what, but either way, good show on that
> paragraph. ;-)
>
>> I cannot, of course, speak to why Josh wrote what he did, but I can
>> give some insight into why I had no disagreement with that part of his
>> statement.
>> A key insight, worth your time to consider and unpack I think, is
>>
>> People won't care what you know, until they know that you care.
>>
>> I won't dwell on that here, but will make some more obviously relevant
>> observations.
>>
>> Firstly, you gave an analytical response to what was, in my view, an
>> emotional observation. While I agree with your analysis, it is largely
>> irrelevant. It is not how people *feel* about kernel development.
>>
>> You say that the code of conflict is gone, but in fact much of it is
>> preserved in the code-of-conduct-interpretation. If you reflect on the
>> focus of the second para of that document (which I think was directly
>> lifted from the code-of-conflict) you will see that value is placed
>> squarely on the code (kernel code, not code of conduct). The code is
>> put forward as the thing of primary importance. People (you, me) are
>> only mentioned in the context of being the authors of code that will be
>> criticised - because (it almost says this) we care about the code, but
>> not about you.
>>
>> So I think it is beyond argument that the value system presented by
>> this paragraph is
>> code > people
>>
>> I think this is particularly unfortunate as it is not really how the
>> community works, and not really how Linus works, except in those
>> occasional outbursts that are publicised so much.
>>
>> I recall two specific events (there were probably others) from early in
>> my Linux experience where Linus said/did things which said to me that
>> he valued me, not just the code that I wrote. I think he did that a
>> lot (and probably still does). As I knew that he "cared", I was much
>> more interested in what he knew/thought.
>>
>> I think that the fact that Linus is now acknowledging every "pull"
>> request is brilliant. It doesn't really help the process much (we all
>> have plenty of visibility into what Linus has pulled) and doesn't help
>> the code (directly) at all. But it tells people that Linus can see
>> them, and has seen them. It also allows people to see that they have
>> an email from Linus without expecting it to be a criticism. Certainly
>> he still criticises and is right to do so, and he doesn't say "Pulled,
>> thanks", which would be my preference, but the fact that he responds at
>> least says "me responding to you matters" and by implication "you
>> matter".
>>
>> (The code-of-conflict only acknowledged that you matter once you feel
>> personally abused).
>
> I agree that Linus's acknowledging pull requests is a good thing. I have
> long appreciated my upstream maintainer doing the same, and I do try to
> acknowledge patch submissions myself. And yes, motivating people is an
> underappreciated art, and an art made more difficult by the wide variety
> of mindsets, even within a relatively like-minded community such as the
> Linux kernel community. So I agree that improvements are welcome, and
> further believe that there always will be room for improvement.
>
> But I am still not seeing "code > people" in the interpretation document.
> For me, it is all about people.
>
> Back to "People won't care what you know, until they know that you care."
>
> Fortunately for me, it is not necessary for all that many people to care
> what I know, given that I have the usual human limitations on the number
> of individuals that I can directly relate to, and this number is way
> less than the billions that have some relationship to the Linux kernel,
> unwitting though that relationship is in the common case.
>
> In contrast, back in the late 70s, my software had two users, and I
> frequently chatted with both of them. This is clearly not possible in
> the case of the Linux kernel. Nor would it be all that helpful, given
> that all they really need from me is to keep RCU working properly.
> So I instead create an abstraction of those users' needs in the form
> of requirements. These requirements might seem dull and uninspiring,
> but they are in fact a proxy for the needs of the users.
>
> In short, instead of "code > people", I am seeing "our users need us".
>
Ok, maybe we need to introduce a distinction here.
- our users are affected by our product
- our developers are affected by our process
The para in question talks a lot about meeting the needs of our users,
and says almost nothing about meeting the needs of our developers. In
fact, our developers need to submit their needs to the needs for the
users. So maybe the inequality is "users > developers".
Now you and I and most of the community know that this isn't true, the
developers are actually valued: patches are reviewed, bug reports are
attended to, questions are answered.
On re-reading the text in question, I see that it says:
Your contributions and ideas behind them will be
carefully reviewed, ...
and while that is a good thing, it really doesn't come across as
welcoming to me. ( .... will be *welcomed* and carefully reviewed....)
And I guess this highlights the wisdom of your response to Josh:
Communication is inherently difficult.
This is, in part, why I suggest that we shouldn't have a code of conduct
at all. Whatever we write, different people will understand it
differently. And history suggests that some of us will treat it like a
legal document and try to be lawyers, but without all the training real
lawyers have.
Instead of a code of conduct, we just need good conduct, and to
encourage that conduct when we see it.
This builds on our core competencies as a community: our usual mode of
working is to each work independently on our own areas, and to combine
our skills intermittently as need and opportunity arises. The "Linux
kernel" emerges organically from the work of multiple developers, and
likewise, the only meaningful statement of the conduct of the community is
that conduct with emerges organically from the conduct of the members.
Thanks,
NeilBrown
> Thanx, Paul
>
>> Thanks,
>> NeilBrown
>>
>>
>> > Thanx, Paul
>> >
>> >> (Leaving aside that the more important detail
>> >> would be the community actually acting consistently with the code of
>> >> conduct it espoused.)
>> >>
>> >> > In the current code, would The "Our Pledge" section have been
>> >> > sufficient, or do you think the other sections would have actually
>> >> > helped you?
>> >>
>> >> "Our Standards" would have been at least as important to me personally,
>> >> as would "Enforcement" (and more importantly, examples of that applying
>> >> in practice and not just as empty words).
>> >> _______________________________________________
>> >> Ksummit-discuss mailing list
>> >> [email protected]
>> >> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
>> >>
James Bottomley <[email protected]>:
> Actually, I think this whole code vs people debate is a straw man and
> inherently inimical to the discussion. In neither code of conduct (old
> or new) is there any statement that allows one to make a value judgment
> of people relative to code, so the very premise you're all arguing on
> doesn't exist.
The author's original version of the new CoC is, however, associated
with (and intended by its author to implement) "The Post-Meritocracy
Manifesto".
https://postmeritocracy.org/
Do you think it's a stretch to see "people > code" in that?
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.
On Sat, Nov 03, 2018 at 07:36:19PM +1100, NeilBrown wrote:
> On Fri, Nov 02 2018, Paul E. McKenney wrote:
>
> > On Fri, Nov 02, 2018 at 08:50:11AM +1100, NeilBrown wrote:
> >> On Thu, Nov 01 2018, Paul E. McKenney wrote:
> >>
> >> > On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote:
> >> >> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote:
> >> >> > On Wed, Oct 24 2018, Josh Triplett wrote:
> >> >> >
> >> >> > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
> >> >> > >> On Sun, Oct 21 2018, Josh Triplett wrote:
> >> >> > >>
> >> >> > >> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> >> >> > >> >> I call on you, Greg:
> >> >> > >> >> - to abandon this divisive attempt to impose a "Code of Conduct"
> >> >> > >> >> - to revert 8a104f8b5867c68
> >> >> > >> >> - to return to your core competence of building a great team around
> >> >> > >> >> a great kernel
> >> >> > >> >>
> >> >> > >> >> #Isupportreversion
> >> >> > >> >>
> >> >> > >> >> I call on the community to consider what *does* need to be said, about
> >> >> > >> >> conduct, to people outside the community and who have recently joined.
> >> >> > >> >> What is the document that you would have liked to have read as you were
> >> >> > >> >> starting out? It is all too long ago for me to remember clearly, and so
> >> >> > >> >> much has changed.
> >> >> > >> >
> >> >> > >> > The document I would have liked to have read when starting out is
> >> >> > >> > currently checked into the source tree in
> >> >> > >> > Documentation/process/code-of-conduct.rst .
> >> >> > >>
> >> >> > >> I'm curious - what would you have gained by reading that document?
> >> >> > >
> >> >> > > I would have then had rather less of a pervasive feeling of "if I make
> >> >> > > even a single mistake I get made an example of in ways that will feed
> >> >> > > people's quotes files for years to come".
> >> >> >
> >> >> > Thanks for your reply. Certainly feeling safe is important, and having
> >> >> > clear statements that the community values and promotes psychological
> >> >> > safety is valuable.
> >> >> >
> >> >> > The old "code of conflict" said
> >> >> > If however, anyone feels personally abused, threatened, or otherwise
> >> >> > uncomfortable due to this process, that is not acceptable.
> >> >> >
> >> >> > would you have not found this a strong enough statement to ward off that
> >> >> > pervasive feeling?
> >> >>
> >> >> Not when that document started out effectively saying, in an elaborate
> >> >> way, "code > people".
> >> >
> >> > Interesting.
> >> >
> >> > I am curious what leads you to your "code > people" statement. Of course,
> >> > one could argue that this does not really matter given that the code of
> >> > conflict is no longer. However, I would like to understand for future
> >> > reference, if for no other reason.
> >> >
> >> > One possibility is that you are restricting the "people" to only those
> >> > people directly contributing in one way or another. But those using the
> >> > kernel (both directly and indirectly) are important as well, and it is
> >> > exactly this group that is served by "the most robust operating system
> >> > kernel ever", the chest-beating sentiment notwithstanding. Which is in
> >> > fact why I must reject (or rework or whatever) any patch that might result
> >> > in too-short RCU grace periods: The needs of the patch's submitter are
> >> > quite emphatically outweighed by the needs of the kernel's many users,
> >> > and many of the various technical requirements and restrictions are in
> >> > fact proxies for the needs of these users.
> >> >
> >> > But you knew that already.
> >> >
> >> > Similarly for the Linux kernel's various code-style strictures, which
> >> > serve the surprisingly large group of people reading the kernel's code.
> >> > Including the stricture that I most love to hate, which is the one
> >> > stating that single-line do/for/if/while statements must not be enclosed
> >> > in braces, which sometimes causes me trouble when inserting debug code,
> >> > but which also makes more code fit into a window of a given size. ;-)
> >> >
> >> > But you knew that already, too.
> >> >
> >> > The maintainability requirements can be argued to mostly serve the
> >> > maintainers, but if the code becomes unmaintainable, future users
> >> > will be inconvenienced, to say the least. So even the maintainability
> >> > requirements serve the kernel's many users.
> >> >
> >> > But you also knew that already.
> >> >
> >> > So what am I missing here?
> >> >
> >>
> >> Hi Paul,
> >> thanks for contributing your thoughts. It is nice to have a new voice
> >> in the conversation, it helps me to maintain my illusion that this
> >> issue is relevant to the whole community.
> >
> > I am not sure whether I should feel Australia-style chastened,
> > American-style encouraged, or what, but either way, good show on that
> > paragraph. ;-)
> >
> >> I cannot, of course, speak to why Josh wrote what he did, but I can
> >> give some insight into why I had no disagreement with that part of his
> >> statement.
> >> A key insight, worth your time to consider and unpack I think, is
> >>
> >> People won't care what you know, until they know that you care.
> >>
> >> I won't dwell on that here, but will make some more obviously relevant
> >> observations.
> >>
> >> Firstly, you gave an analytical response to what was, in my view, an
> >> emotional observation. While I agree with your analysis, it is largely
> >> irrelevant. It is not how people *feel* about kernel development.
> >>
> >> You say that the code of conflict is gone, but in fact much of it is
> >> preserved in the code-of-conduct-interpretation. If you reflect on the
> >> focus of the second para of that document (which I think was directly
> >> lifted from the code-of-conflict) you will see that value is placed
> >> squarely on the code (kernel code, not code of conduct). The code is
> >> put forward as the thing of primary importance. People (you, me) are
> >> only mentioned in the context of being the authors of code that will be
> >> criticised - because (it almost says this) we care about the code, but
> >> not about you.
> >>
> >> So I think it is beyond argument that the value system presented by
> >> this paragraph is
> >> code > people
> >>
> >> I think this is particularly unfortunate as it is not really how the
> >> community works, and not really how Linus works, except in those
> >> occasional outbursts that are publicised so much.
> >>
> >> I recall two specific events (there were probably others) from early in
> >> my Linux experience where Linus said/did things which said to me that
> >> he valued me, not just the code that I wrote. I think he did that a
> >> lot (and probably still does). As I knew that he "cared", I was much
> >> more interested in what he knew/thought.
> >>
> >> I think that the fact that Linus is now acknowledging every "pull"
> >> request is brilliant. It doesn't really help the process much (we all
> >> have plenty of visibility into what Linus has pulled) and doesn't help
> >> the code (directly) at all. But it tells people that Linus can see
> >> them, and has seen them. It also allows people to see that they have
> >> an email from Linus without expecting it to be a criticism. Certainly
> >> he still criticises and is right to do so, and he doesn't say "Pulled,
> >> thanks", which would be my preference, but the fact that he responds at
> >> least says "me responding to you matters" and by implication "you
> >> matter".
> >>
> >> (The code-of-conflict only acknowledged that you matter once you feel
> >> personally abused).
> >
> > I agree that Linus's acknowledging pull requests is a good thing. I have
> > long appreciated my upstream maintainer doing the same, and I do try to
> > acknowledge patch submissions myself. And yes, motivating people is an
> > underappreciated art, and an art made more difficult by the wide variety
> > of mindsets, even within a relatively like-minded community such as the
> > Linux kernel community. So I agree that improvements are welcome, and
> > further believe that there always will be room for improvement.
> >
> > But I am still not seeing "code > people" in the interpretation document.
> > For me, it is all about people.
> >
> > Back to "People won't care what you know, until they know that you care."
> >
> > Fortunately for me, it is not necessary for all that many people to care
> > what I know, given that I have the usual human limitations on the number
> > of individuals that I can directly relate to, and this number is way
> > less than the billions that have some relationship to the Linux kernel,
> > unwitting though that relationship is in the common case.
> >
> > In contrast, back in the late 70s, my software had two users, and I
> > frequently chatted with both of them. This is clearly not possible in
> > the case of the Linux kernel. Nor would it be all that helpful, given
> > that all they really need from me is to keep RCU working properly.
> > So I instead create an abstraction of those users' needs in the form
> > of requirements. These requirements might seem dull and uninspiring,
> > but they are in fact a proxy for the needs of the users.
> >
> > In short, instead of "code > people", I am seeing "our users need us".
>
> Ok, maybe we need to introduce a distinction here.
> - our users are affected by our product
> - our developers are affected by our process
>
> The para in question talks a lot about meeting the needs of our users,
> and says almost nothing about meeting the needs of our developers. In
> fact, our developers need to submit their needs to the needs for the
> users. So maybe the inequality is "users > developers".
>
> Now you and I and most of the community know that this isn't true, the
> developers are actually valued: patches are reviewed, bug reports are
> attended to, questions are answered.
I completely and emphatically agree that the reality is quite a bit more
complicated and nuanced than can be captured by sound bites, whether
inequalities or otherwise. For example, one sense in which "users >
developers" might be said to be true is that things usually don't go
at all well for developers when users vote with their feet, abandoning
the project. And one sense in which "developers > users" might be said
to be true is in terms of direct influence over the project itself.
I am quite confident that you could easily come up with a very large
number of additional examples supporting any number of inequalities
between any number of pairs of subgroups within the greater Linux-kernel
community. ;-)
> On re-reading the text in question, I see that it says:
>
> Your contributions and ideas behind them will be
> carefully reviewed, ...
>
> and while that is a good thing, it really doesn't come across as
> welcoming to me. ( .... will be *welcomed* and carefully reviewed....)
Heh! Like many people in my country, there is a mat labeled "Welcome" in
front of my door. And, again like many people in my country, that door
is almost always locked, which is admittedly strange and ironic enough.
But given where the code of conduct is located, it would be more like a
"Welcome" mat hidden in the shrubbery behind my house, now wouldn't it?
Which would be even more strange, though perhaps no more ironic.
Yet putting the code of conduct (say) in all caps in the Linux kernel's
home directory might not be sending all that positive a message, so
it makes no sense to move it from its current location. We therefore
cannot really rely on the code of conduct to serve as the Linux kernel's
"Welcome" mat. Nor should that be its purpose.
> And I guess this highlights the wisdom of your response to Josh:
> Communication is inherently difficult.
Thank you, much though I wish I was wrong on this point.
> This is, in part, why I suggest that we shouldn't have a code of conduct
> at all. Whatever we write, different people will understand it
> differently. And history suggests that some of us will treat it like a
> legal document and try to be lawyers, but without all the training real
> lawyers have.
>
> Instead of a code of conduct, we just need good conduct, and to
> encourage that conduct when we see it.
> This builds on our core competencies as a community: our usual mode of
> working is to each work independently on our own areas, and to combine
> our skills intermittently as need and opportunity arises. The "Linux
> kernel" emerges organically from the work of multiple developers, and
> likewise, the only meaningful statement of the conduct of the community is
> that conduct with emerges organically from the conduct of the members.
If the was a perfect world, we might well not need a code of conduct.
On the other hand, in a perfect world we also just might not need locks
(with or without the ironic "Welcome" mat), passwords, urgent security
patches, fences topped with concertina wire, weapons, and much more
besides.
So rather than randomly mutate the code of conduct further, let alone
remove it completely, let's instead leave it alone for a few years.
We then might have enough experience with it to make any needed
adjustments.
Of course, the optimal outcome would be zero experience with it at all
ever due to overwhelming best behavior on the part of all concerned,
but again, this world is sometimes less than perfect.
Thanx, Paul
On Sat, Nov 03 2018, Paul E. McKenney wrote:
> On Sat, Nov 03, 2018 at 07:36:19PM +1100, NeilBrown wrote:
>> On Fri, Nov 02 2018, Paul E. McKenney wrote:
>>
>> > On Fri, Nov 02, 2018 at 08:50:11AM +1100, NeilBrown wrote:
>> >> On Thu, Nov 01 2018, Paul E. McKenney wrote:
>> >>
>> >> > On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote:
>> >> >> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote:
>> >> >> > On Wed, Oct 24 2018, Josh Triplett wrote:
>> >> >> >
>> >> >> > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
>> >> >> > >> On Sun, Oct 21 2018, Josh Triplett wrote:
>> >> >> > >>
>> >> >> > >> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
>> >> >> > >> >> I call on you, Greg:
>> >> >> > >> >> - to abandon this divisive attempt to impose a "Code of Conduct"
>> >> >> > >> >> - to revert 8a104f8b5867c68
>> >> >> > >> >> - to return to your core competence of building a great team around
>> >> >> > >> >> a great kernel
>> >> >> > >> >>
>> >> >> > >> >> #Isupportreversion
>> >> >> > >> >>
>> >> >> > >> >> I call on the community to consider what *does* need to be said, about
>> >> >> > >> >> conduct, to people outside the community and who have recently joined.
>> >> >> > >> >> What is the document that you would have liked to have read as you were
>> >> >> > >> >> starting out? It is all too long ago for me to remember clearly, and so
>> >> >> > >> >> much has changed.
>> >> >> > >> >
>> >> >> > >> > The document I would have liked to have read when starting out is
>> >> >> > >> > currently checked into the source tree in
>> >> >> > >> > Documentation/process/code-of-conduct.rst .
>> >> >> > >>
>> >> >> > >> I'm curious - what would you have gained by reading that document?
>> >> >> > >
>> >> >> > > I would have then had rather less of a pervasive feeling of "if I make
>> >> >> > > even a single mistake I get made an example of in ways that will feed
>> >> >> > > people's quotes files for years to come".
>> >> >> >
>> >> >> > Thanks for your reply. Certainly feeling safe is important, and having
>> >> >> > clear statements that the community values and promotes psychological
>> >> >> > safety is valuable.
>> >> >> >
>> >> >> > The old "code of conflict" said
>> >> >> > If however, anyone feels personally abused, threatened, or otherwise
>> >> >> > uncomfortable due to this process, that is not acceptable.
>> >> >> >
>> >> >> > would you have not found this a strong enough statement to ward off that
>> >> >> > pervasive feeling?
>> >> >>
>> >> >> Not when that document started out effectively saying, in an elaborate
>> >> >> way, "code > people".
>> >> >
>> >> > Interesting.
>> >> >
>> >> > I am curious what leads you to your "code > people" statement. Of course,
>> >> > one could argue that this does not really matter given that the code of
>> >> > conflict is no longer. However, I would like to understand for future
>> >> > reference, if for no other reason.
>> >> >
>> >> > One possibility is that you are restricting the "people" to only those
>> >> > people directly contributing in one way or another. But those using the
>> >> > kernel (both directly and indirectly) are important as well, and it is
>> >> > exactly this group that is served by "the most robust operating system
>> >> > kernel ever", the chest-beating sentiment notwithstanding. Which is in
>> >> > fact why I must reject (or rework or whatever) any patch that might result
>> >> > in too-short RCU grace periods: The needs of the patch's submitter are
>> >> > quite emphatically outweighed by the needs of the kernel's many users,
>> >> > and many of the various technical requirements and restrictions are in
>> >> > fact proxies for the needs of these users.
>> >> >
>> >> > But you knew that already.
>> >> >
>> >> > Similarly for the Linux kernel's various code-style strictures, which
>> >> > serve the surprisingly large group of people reading the kernel's code.
>> >> > Including the stricture that I most love to hate, which is the one
>> >> > stating that single-line do/for/if/while statements must not be enclosed
>> >> > in braces, which sometimes causes me trouble when inserting debug code,
>> >> > but which also makes more code fit into a window of a given size. ;-)
>> >> >
>> >> > But you knew that already, too.
>> >> >
>> >> > The maintainability requirements can be argued to mostly serve the
>> >> > maintainers, but if the code becomes unmaintainable, future users
>> >> > will be inconvenienced, to say the least. So even the maintainability
>> >> > requirements serve the kernel's many users.
>> >> >
>> >> > But you also knew that already.
>> >> >
>> >> > So what am I missing here?
>> >> >
>> >>
>> >> Hi Paul,
>> >> thanks for contributing your thoughts. It is nice to have a new voice
>> >> in the conversation, it helps me to maintain my illusion that this
>> >> issue is relevant to the whole community.
>> >
>> > I am not sure whether I should feel Australia-style chastened,
>> > American-style encouraged, or what, but either way, good show on that
>> > paragraph. ;-)
>> >
>> >> I cannot, of course, speak to why Josh wrote what he did, but I can
>> >> give some insight into why I had no disagreement with that part of his
>> >> statement.
>> >> A key insight, worth your time to consider and unpack I think, is
>> >>
>> >> People won't care what you know, until they know that you care.
>> >>
>> >> I won't dwell on that here, but will make some more obviously relevant
>> >> observations.
>> >>
>> >> Firstly, you gave an analytical response to what was, in my view, an
>> >> emotional observation. While I agree with your analysis, it is largely
>> >> irrelevant. It is not how people *feel* about kernel development.
>> >>
>> >> You say that the code of conflict is gone, but in fact much of it is
>> >> preserved in the code-of-conduct-interpretation. If you reflect on the
>> >> focus of the second para of that document (which I think was directly
>> >> lifted from the code-of-conflict) you will see that value is placed
>> >> squarely on the code (kernel code, not code of conduct). The code is
>> >> put forward as the thing of primary importance. People (you, me) are
>> >> only mentioned in the context of being the authors of code that will be
>> >> criticised - because (it almost says this) we care about the code, but
>> >> not about you.
>> >>
>> >> So I think it is beyond argument that the value system presented by
>> >> this paragraph is
>> >> code > people
>> >>
>> >> I think this is particularly unfortunate as it is not really how the
>> >> community works, and not really how Linus works, except in those
>> >> occasional outbursts that are publicised so much.
>> >>
>> >> I recall two specific events (there were probably others) from early in
>> >> my Linux experience where Linus said/did things which said to me that
>> >> he valued me, not just the code that I wrote. I think he did that a
>> >> lot (and probably still does). As I knew that he "cared", I was much
>> >> more interested in what he knew/thought.
>> >>
>> >> I think that the fact that Linus is now acknowledging every "pull"
>> >> request is brilliant. It doesn't really help the process much (we all
>> >> have plenty of visibility into what Linus has pulled) and doesn't help
>> >> the code (directly) at all. But it tells people that Linus can see
>> >> them, and has seen them. It also allows people to see that they have
>> >> an email from Linus without expecting it to be a criticism. Certainly
>> >> he still criticises and is right to do so, and he doesn't say "Pulled,
>> >> thanks", which would be my preference, but the fact that he responds at
>> >> least says "me responding to you matters" and by implication "you
>> >> matter".
>> >>
>> >> (The code-of-conflict only acknowledged that you matter once you feel
>> >> personally abused).
>> >
>> > I agree that Linus's acknowledging pull requests is a good thing. I have
>> > long appreciated my upstream maintainer doing the same, and I do try to
>> > acknowledge patch submissions myself. And yes, motivating people is an
>> > underappreciated art, and an art made more difficult by the wide variety
>> > of mindsets, even within a relatively like-minded community such as the
>> > Linux kernel community. So I agree that improvements are welcome, and
>> > further believe that there always will be room for improvement.
>> >
>> > But I am still not seeing "code > people" in the interpretation document.
>> > For me, it is all about people.
>> >
>> > Back to "People won't care what you know, until they know that you care."
>> >
>> > Fortunately for me, it is not necessary for all that many people to care
>> > what I know, given that I have the usual human limitations on the number
>> > of individuals that I can directly relate to, and this number is way
>> > less than the billions that have some relationship to the Linux kernel,
>> > unwitting though that relationship is in the common case.
>> >
>> > In contrast, back in the late 70s, my software had two users, and I
>> > frequently chatted with both of them. This is clearly not possible in
>> > the case of the Linux kernel. Nor would it be all that helpful, given
>> > that all they really need from me is to keep RCU working properly.
>> > So I instead create an abstraction of those users' needs in the form
>> > of requirements. These requirements might seem dull and uninspiring,
>> > but they are in fact a proxy for the needs of the users.
>> >
>> > In short, instead of "code > people", I am seeing "our users need us".
>>
>> Ok, maybe we need to introduce a distinction here.
>> - our users are affected by our product
>> - our developers are affected by our process
>>
>> The para in question talks a lot about meeting the needs of our users,
>> and says almost nothing about meeting the needs of our developers. In
>> fact, our developers need to submit their needs to the needs for the
>> users. So maybe the inequality is "users > developers".
>>
>> Now you and I and most of the community know that this isn't true, the
>> developers are actually valued: patches are reviewed, bug reports are
>> attended to, questions are answered.
>
> I completely and emphatically agree that the reality is quite a bit more
> complicated and nuanced than can be captured by sound bites, whether
> inequalities or otherwise. For example, one sense in which "users >
> developers" might be said to be true is that things usually don't go
> at all well for developers when users vote with their feet, abandoning
> the project. And one sense in which "developers > users" might be said
> to be true is in terms of direct influence over the project itself.
>
> I am quite confident that you could easily come up with a very large
> number of additional examples supporting any number of inequalities
> between any number of pairs of subgroups within the greater Linux-kernel
> community. ;-)
>
>> On re-reading the text in question, I see that it says:
>>
>> Your contributions and ideas behind them will be
>> carefully reviewed, ...
>>
>> and while that is a good thing, it really doesn't come across as
>> welcoming to me. ( .... will be *welcomed* and carefully reviewed....)
>
> Heh! Like many people in my country, there is a mat labeled "Welcome" in
> front of my door. And, again like many people in my country, that door
> is almost always locked, which is admittedly strange and ironic enough.
> But given where the code of conduct is located, it would be more like a
> "Welcome" mat hidden in the shrubbery behind my house, now wouldn't it?
> Which would be even more strange, though perhaps no more ironic.
>
> Yet putting the code of conduct (say) in all caps in the Linux kernel's
> home directory might not be sending all that positive a message, so
> it makes no sense to move it from its current location. We therefore
> cannot really rely on the code of conduct to serve as the Linux kernel's
> "Welcome" mat. Nor should that be its purpose.
>
>> And I guess this highlights the wisdom of your response to Josh:
>> Communication is inherently difficult.
>
> Thank you, much though I wish I was wrong on this point.
>
>> This is, in part, why I suggest that we shouldn't have a code of conduct
>> at all. Whatever we write, different people will understand it
>> differently. And history suggests that some of us will treat it like a
>> legal document and try to be lawyers, but without all the training real
>> lawyers have.
>>
>> Instead of a code of conduct, we just need good conduct, and to
>> encourage that conduct when we see it.
>> This builds on our core competencies as a community: our usual mode of
>> working is to each work independently on our own areas, and to combine
>> our skills intermittently as need and opportunity arises. The "Linux
>> kernel" emerges organically from the work of multiple developers, and
>> likewise, the only meaningful statement of the conduct of the community is
>> that conduct with emerges organically from the conduct of the members.
>
> If the was a perfect world, we might well not need a code of conduct.
> On the other hand, in a perfect world we also just might not need locks
> (with or without the ironic "Welcome" mat), passwords, urgent security
> patches, fences topped with concertina wire, weapons, and much more
> besides.
>
> So rather than randomly mutate the code of conduct further, let alone
> remove it completely, let's instead leave it alone for a few years.
> We then might have enough experience with it to make any needed
> adjustments.
Hi Paul,
thanks for your thoughts, and particularly for the door-mat analogy.
It is a thing of beauty.
I agree that the window of opportunity appears to be closed. Indeed,
it appears now that it was closed before I wrote my "Call to action"
despite the apparent offer of an open discussion. Maybe I was the only
one too blind to see that for what it was.
>
> Of course, the optimal outcome would be zero experience with it at all
> ever due to overwhelming best behavior on the part of all concerned,
> but again, this world is sometimes less than perfect.
I have two concerns (fears??) going forward.
One is that the CoC might be weaponized as has already happened to the
GNU Kind Communication Guidelines - see the thread leading to the recent
LWN QoTD by RMS. In essence, it is being used to attack rather than to
protect (you could argue in this case it is also being used to defend
in a different sense, but the attack is, I think, not healthy).
Maybe I can now say "I told you so" - while that is cold comfort, it is
still better than no comfort.
The second is that people might perceive behavioural improvements in the
community from this time, see the CoC added at this time, and
incorrectly assume causality - the most likely actual cause is
improvement in leadership. I hope that I have made enough noise that
such people will think twice about copying our mistakes.
Thanks,
NeilBrown
On Sun, Nov 04, 2018 at 08:06:41AM +1100, NeilBrown wrote:
> On Sat, Nov 03 2018, Paul E. McKenney wrote:
>
> > On Sat, Nov 03, 2018 at 07:36:19PM +1100, NeilBrown wrote:
> >> On Fri, Nov 02 2018, Paul E. McKenney wrote:
> >>
> >> > On Fri, Nov 02, 2018 at 08:50:11AM +1100, NeilBrown wrote:
> >> >> On Thu, Nov 01 2018, Paul E. McKenney wrote:
> >> >>
> >> >> > On Sat, Oct 27, 2018 at 02:10:10AM +0100, Josh Triplett wrote:
> >> >> >> On Fri, Oct 26, 2018 at 08:14:51AM +1100, NeilBrown wrote:
> >> >> >> > On Wed, Oct 24 2018, Josh Triplett wrote:
> >> >> >> >
> >> >> >> > > On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
> >> >> >> > >> On Sun, Oct 21 2018, Josh Triplett wrote:
> >> >> >> > >>
> >> >> >> > >> > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> >> >> >> > >> >> I call on you, Greg:
> >> >> >> > >> >> - to abandon this divisive attempt to impose a "Code of Conduct"
> >> >> >> > >> >> - to revert 8a104f8b5867c68
> >> >> >> > >> >> - to return to your core competence of building a great team around
> >> >> >> > >> >> a great kernel
> >> >> >> > >> >>
> >> >> >> > >> >> #Isupportreversion
> >> >> >> > >> >>
> >> >> >> > >> >> I call on the community to consider what *does* need to be said, about
> >> >> >> > >> >> conduct, to people outside the community and who have recently joined.
> >> >> >> > >> >> What is the document that you would have liked to have read as you were
> >> >> >> > >> >> starting out? It is all too long ago for me to remember clearly, and so
> >> >> >> > >> >> much has changed.
> >> >> >> > >> >
> >> >> >> > >> > The document I would have liked to have read when starting out is
> >> >> >> > >> > currently checked into the source tree in
> >> >> >> > >> > Documentation/process/code-of-conduct.rst .
> >> >> >> > >>
> >> >> >> > >> I'm curious - what would you have gained by reading that document?
> >> >> >> > >
> >> >> >> > > I would have then had rather less of a pervasive feeling of "if I make
> >> >> >> > > even a single mistake I get made an example of in ways that will feed
> >> >> >> > > people's quotes files for years to come".
> >> >> >> >
> >> >> >> > Thanks for your reply. Certainly feeling safe is important, and having
> >> >> >> > clear statements that the community values and promotes psychological
> >> >> >> > safety is valuable.
> >> >> >> >
> >> >> >> > The old "code of conflict" said
> >> >> >> > If however, anyone feels personally abused, threatened, or otherwise
> >> >> >> > uncomfortable due to this process, that is not acceptable.
> >> >> >> >
> >> >> >> > would you have not found this a strong enough statement to ward off that
> >> >> >> > pervasive feeling?
> >> >> >>
> >> >> >> Not when that document started out effectively saying, in an elaborate
> >> >> >> way, "code > people".
> >> >> >
> >> >> > Interesting.
> >> >> >
> >> >> > I am curious what leads you to your "code > people" statement. Of course,
> >> >> > one could argue that this does not really matter given that the code of
> >> >> > conflict is no longer. However, I would like to understand for future
> >> >> > reference, if for no other reason.
> >> >> >
> >> >> > One possibility is that you are restricting the "people" to only those
> >> >> > people directly contributing in one way or another. But those using the
> >> >> > kernel (both directly and indirectly) are important as well, and it is
> >> >> > exactly this group that is served by "the most robust operating system
> >> >> > kernel ever", the chest-beating sentiment notwithstanding. Which is in
> >> >> > fact why I must reject (or rework or whatever) any patch that might result
> >> >> > in too-short RCU grace periods: The needs of the patch's submitter are
> >> >> > quite emphatically outweighed by the needs of the kernel's many users,
> >> >> > and many of the various technical requirements and restrictions are in
> >> >> > fact proxies for the needs of these users.
> >> >> >
> >> >> > But you knew that already.
> >> >> >
> >> >> > Similarly for the Linux kernel's various code-style strictures, which
> >> >> > serve the surprisingly large group of people reading the kernel's code.
> >> >> > Including the stricture that I most love to hate, which is the one
> >> >> > stating that single-line do/for/if/while statements must not be enclosed
> >> >> > in braces, which sometimes causes me trouble when inserting debug code,
> >> >> > but which also makes more code fit into a window of a given size. ;-)
> >> >> >
> >> >> > But you knew that already, too.
> >> >> >
> >> >> > The maintainability requirements can be argued to mostly serve the
> >> >> > maintainers, but if the code becomes unmaintainable, future users
> >> >> > will be inconvenienced, to say the least. So even the maintainability
> >> >> > requirements serve the kernel's many users.
> >> >> >
> >> >> > But you also knew that already.
> >> >> >
> >> >> > So what am I missing here?
> >> >> >
> >> >>
> >> >> Hi Paul,
> >> >> thanks for contributing your thoughts. It is nice to have a new voice
> >> >> in the conversation, it helps me to maintain my illusion that this
> >> >> issue is relevant to the whole community.
> >> >
> >> > I am not sure whether I should feel Australia-style chastened,
> >> > American-style encouraged, or what, but either way, good show on that
> >> > paragraph. ;-)
> >> >
> >> >> I cannot, of course, speak to why Josh wrote what he did, but I can
> >> >> give some insight into why I had no disagreement with that part of his
> >> >> statement.
> >> >> A key insight, worth your time to consider and unpack I think, is
> >> >>
> >> >> People won't care what you know, until they know that you care.
> >> >>
> >> >> I won't dwell on that here, but will make some more obviously relevant
> >> >> observations.
> >> >>
> >> >> Firstly, you gave an analytical response to what was, in my view, an
> >> >> emotional observation. While I agree with your analysis, it is largely
> >> >> irrelevant. It is not how people *feel* about kernel development.
> >> >>
> >> >> You say that the code of conflict is gone, but in fact much of it is
> >> >> preserved in the code-of-conduct-interpretation. If you reflect on the
> >> >> focus of the second para of that document (which I think was directly
> >> >> lifted from the code-of-conflict) you will see that value is placed
> >> >> squarely on the code (kernel code, not code of conduct). The code is
> >> >> put forward as the thing of primary importance. People (you, me) are
> >> >> only mentioned in the context of being the authors of code that will be
> >> >> criticised - because (it almost says this) we care about the code, but
> >> >> not about you.
> >> >>
> >> >> So I think it is beyond argument that the value system presented by
> >> >> this paragraph is
> >> >> code > people
> >> >>
> >> >> I think this is particularly unfortunate as it is not really how the
> >> >> community works, and not really how Linus works, except in those
> >> >> occasional outbursts that are publicised so much.
> >> >>
> >> >> I recall two specific events (there were probably others) from early in
> >> >> my Linux experience where Linus said/did things which said to me that
> >> >> he valued me, not just the code that I wrote. I think he did that a
> >> >> lot (and probably still does). As I knew that he "cared", I was much
> >> >> more interested in what he knew/thought.
> >> >>
> >> >> I think that the fact that Linus is now acknowledging every "pull"
> >> >> request is brilliant. It doesn't really help the process much (we all
> >> >> have plenty of visibility into what Linus has pulled) and doesn't help
> >> >> the code (directly) at all. But it tells people that Linus can see
> >> >> them, and has seen them. It also allows people to see that they have
> >> >> an email from Linus without expecting it to be a criticism. Certainly
> >> >> he still criticises and is right to do so, and he doesn't say "Pulled,
> >> >> thanks", which would be my preference, but the fact that he responds at
> >> >> least says "me responding to you matters" and by implication "you
> >> >> matter".
> >> >>
> >> >> (The code-of-conflict only acknowledged that you matter once you feel
> >> >> personally abused).
> >> >
> >> > I agree that Linus's acknowledging pull requests is a good thing. I have
> >> > long appreciated my upstream maintainer doing the same, and I do try to
> >> > acknowledge patch submissions myself. And yes, motivating people is an
> >> > underappreciated art, and an art made more difficult by the wide variety
> >> > of mindsets, even within a relatively like-minded community such as the
> >> > Linux kernel community. So I agree that improvements are welcome, and
> >> > further believe that there always will be room for improvement.
> >> >
> >> > But I am still not seeing "code > people" in the interpretation document.
> >> > For me, it is all about people.
> >> >
> >> > Back to "People won't care what you know, until they know that you care."
> >> >
> >> > Fortunately for me, it is not necessary for all that many people to care
> >> > what I know, given that I have the usual human limitations on the number
> >> > of individuals that I can directly relate to, and this number is way
> >> > less than the billions that have some relationship to the Linux kernel,
> >> > unwitting though that relationship is in the common case.
> >> >
> >> > In contrast, back in the late 70s, my software had two users, and I
> >> > frequently chatted with both of them. This is clearly not possible in
> >> > the case of the Linux kernel. Nor would it be all that helpful, given
> >> > that all they really need from me is to keep RCU working properly.
> >> > So I instead create an abstraction of those users' needs in the form
> >> > of requirements. These requirements might seem dull and uninspiring,
> >> > but they are in fact a proxy for the needs of the users.
> >> >
> >> > In short, instead of "code > people", I am seeing "our users need us".
> >>
> >> Ok, maybe we need to introduce a distinction here.
> >> - our users are affected by our product
> >> - our developers are affected by our process
> >>
> >> The para in question talks a lot about meeting the needs of our users,
> >> and says almost nothing about meeting the needs of our developers. In
> >> fact, our developers need to submit their needs to the needs for the
> >> users. So maybe the inequality is "users > developers".
> >>
> >> Now you and I and most of the community know that this isn't true, the
> >> developers are actually valued: patches are reviewed, bug reports are
> >> attended to, questions are answered.
> >
> > I completely and emphatically agree that the reality is quite a bit more
> > complicated and nuanced than can be captured by sound bites, whether
> > inequalities or otherwise. For example, one sense in which "users >
> > developers" might be said to be true is that things usually don't go
> > at all well for developers when users vote with their feet, abandoning
> > the project. And one sense in which "developers > users" might be said
> > to be true is in terms of direct influence over the project itself.
> >
> > I am quite confident that you could easily come up with a very large
> > number of additional examples supporting any number of inequalities
> > between any number of pairs of subgroups within the greater Linux-kernel
> > community. ;-)
> >
> >> On re-reading the text in question, I see that it says:
> >>
> >> Your contributions and ideas behind them will be
> >> carefully reviewed, ...
> >>
> >> and while that is a good thing, it really doesn't come across as
> >> welcoming to me. ( .... will be *welcomed* and carefully reviewed....)
> >
> > Heh! Like many people in my country, there is a mat labeled "Welcome" in
> > front of my door. And, again like many people in my country, that door
> > is almost always locked, which is admittedly strange and ironic enough.
> > But given where the code of conduct is located, it would be more like a
> > "Welcome" mat hidden in the shrubbery behind my house, now wouldn't it?
> > Which would be even more strange, though perhaps no more ironic.
> >
> > Yet putting the code of conduct (say) in all caps in the Linux kernel's
> > home directory might not be sending all that positive a message, so
> > it makes no sense to move it from its current location. We therefore
> > cannot really rely on the code of conduct to serve as the Linux kernel's
> > "Welcome" mat. Nor should that be its purpose.
> >
> >> And I guess this highlights the wisdom of your response to Josh:
> >> Communication is inherently difficult.
> >
> > Thank you, much though I wish I was wrong on this point.
> >
> >> This is, in part, why I suggest that we shouldn't have a code of conduct
> >> at all. Whatever we write, different people will understand it
> >> differently. And history suggests that some of us will treat it like a
> >> legal document and try to be lawyers, but without all the training real
> >> lawyers have.
> >>
> >> Instead of a code of conduct, we just need good conduct, and to
> >> encourage that conduct when we see it.
> >> This builds on our core competencies as a community: our usual mode of
> >> working is to each work independently on our own areas, and to combine
> >> our skills intermittently as need and opportunity arises. The "Linux
> >> kernel" emerges organically from the work of multiple developers, and
> >> likewise, the only meaningful statement of the conduct of the community is
> >> that conduct with emerges organically from the conduct of the members.
> >
> > If the was a perfect world, we might well not need a code of conduct.
> > On the other hand, in a perfect world we also just might not need locks
> > (with or without the ironic "Welcome" mat), passwords, urgent security
> > patches, fences topped with concertina wire, weapons, and much more
> > besides.
> >
> > So rather than randomly mutate the code of conduct further, let alone
> > remove it completely, let's instead leave it alone for a few years.
> > We then might have enough experience with it to make any needed
> > adjustments.
>
> Hi Paul,
> thanks for your thoughts, and particularly for the door-mat analogy.
> It is a thing of beauty.
Glad you liked it. ;-)
> I agree that the window of opportunity appears to be closed. Indeed,
> it appears now that it was closed before I wrote my "Call to action"
> despite the apparent offer of an open discussion. Maybe I was the only
> one too blind to see that for what it was.
If you were to assert that the move to the CoC has not been handled
all that well, I would have a hard time arguing against you. On the
other hand, I would also have a hard time arguing that I would have done
any better.
Life is like that sometimes...
> > Of course, the optimal outcome would be zero experience with it at all
> > ever due to overwhelming best behavior on the part of all concerned,
> > but again, this world is sometimes less than perfect.
>
> I have two concerns (fears??) going forward.
> One is that the CoC might be weaponized as has already happened to the
> GNU Kind Communication Guidelines - see the thread leading to the recent
> LWN QoTD by RMS. In essence, it is being used to attack rather than to
> protect (you could argue in this case it is also being used to defend
> in a different sense, but the attack is, I think, not healthy).
> Maybe I can now say "I told you so" - while that is cold comfort, it is
> still better than no comfort.
I would like to believe that all the various players have good intentions
as well as the intelligence, persistence, and strength of character
required to have a fighting chance of producing good outcomes. If that
turns out not to be the case, for example, if hordes of toxic characters
descend on the Linux kernel community leveraging the CoC to disrupt
and to do disservice to its various members, then this community most
certainly has a good and sufficient number of people skilled in the art
of blacklisting email addresses and, if need be, of "git rm".
Nevertheless, to your point about the GNU Kind Communication Guidelines,
given that RMS reportedly said of the CoC "I myself did not like
the punitive spirit of that approach, and decided against it" [1],
significant vigilance and caution might be warranted. Perhaps deletion
of a certain paragraph from the Linux kernel's version of that CoC has
made the spirit a bit less punitive.
> The second is that people might perceive behavioural improvements in the
> community from this time, see the CoC added at this time, and
> incorrectly assume causality - the most likely actual cause is
> improvement in leadership. I hope that I have made enough noise that
> such people will think twice about copying our mistakes.
My perception is that these behavioral improvements have been accumulating
steadily since I joined almost twenty years ago. But if people claim that
adopting the CoC magically made the Linux kernel community way better,
well, that wouldn't be the strangest statement I have heard this year.
A very low bar, to be sure, but a bar that would be cleared. ;-)
Thanx, Paul
[1] https://lwn.net/Articles/769167/
Hi Josh,
On Wed, Oct 24, 2018 at 2:16 PM Josh Triplett <[email protected]> wrote:
> On Tue, Oct 23, 2018 at 07:26:06AM +1100, NeilBrown wrote:
> > On Sun, Oct 21 2018, Josh Triplett wrote:
> > > On Mon, Oct 22, 2018 at 08:20:11AM +1100, NeilBrown wrote:
> > >> I call on you, Greg:
> > >> - to abandon this divisive attempt to impose a "Code of Conduct"
> > >> - to revert 8a104f8b5867c68
> > >> - to return to your core competence of building a great team around
> > >> a great kernel
> > >>
> > >> #Isupportreversion
> > >>
> > >> I call on the community to consider what *does* need to be said, about
> > >> conduct, to people outside the community and who have recently joined.
> > >> What is the document that you would have liked to have read as you were
> > >> starting out? It is all too long ago for me to remember clearly, and so
> > >> much has changed.
> > >
> > > The document I would have liked to have read when starting out is
> > > currently checked into the source tree in
> > > Documentation/process/code-of-conduct.rst .
> >
> > I'm curious - what would you have gained by reading that document?
>
> I would have then had rather less of a pervasive feeling of "if I make
> even a single mistake I get made an example of in ways that will feed
> people's quotes files for years to come".
>
> See
> https://hbr.org/2017/08/high-performing-teams-need-psychological-safety-heres-how-to-create-it
> for more on the benefits of that.
Funny how you post a link to that article ;-)
Because the psychological safety of the Linux kernel developers and
maintainers is exactly what is being affected, due to the atmosphere
surrounding this particular CoC.
While the addition of the CoC Clarification did improve the general
understanding, the addition of the CoC itself has already caused a
chilling effect. From chatting at the conferences in Edinburgh, people
do have concerns and comments, but many just do not want to express
their thoughts and feelings in public...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Fri, Oct 26, 2018 at 12:12 AM NeilBrown <[email protected]> wrote:
> On Thu, Oct 25 2018, Eric S. Raymond wrote:
> > Theodore Y. Ts'o <[email protected]>:
> >> On Thu, Oct 25, 2018 at 03:39:01PM -0400, Eric S. Raymond wrote:
> >> > Under Jacobsen vs. Katzer (535 f 3d 1373 fed cir 2008) authors of
> >> > GPLed software have a specific right to relief (including injunctive
> >> > relief) against misappropriation of their software. That ruling (which
> >> > was the case of first impression on the binding status of the GPL)
> >> > reputational damage is *specifically* recognized as grounds for relief.
> >>
> >> I've read the legal briefs, and I'm pretty sure they don't say what
> >> you are claiming they say. Yes, I'm not a lawyer --- but that's OK
> >> --- neither are you.
> >
> > How much are you willing to gamble on not being wrong?
> >
> >> The *vast* majority of the "anti-CoC dissidents" who have been
> >> advancing this argument, have, as near as I can tell, little or no
> >> copyright ownership in the kernel.
> >
> > I do not have any facts with which to dispute this specific claim.
> > However, I do notice that a significant number of long-time
> > contributors have put themselves in the anti-CoC camp. I note Al Viro
> > as a recent example.
>
> I think you are blurring two groups here.
> Ted describes "anti-CoC dissidents" as people who are advancing an
> argument about rescinding their license. This is a smaller groups than
> the "ant-CoC camp" who don't really like the CoC. I suspect is it is a
> much smaller group when restricting to actual copyright holders.
>
> I am against the CoC as it stands, but rescinding any license is such an
> enormous over-reaction, I find the concept laughable.
Indeed. While I cannot comment on the legality of the rescinding, this
rescinding is definitely not compatible with "be nice to each other",
which is what all kernel developers who do not like the CoC as it
stands, and who I'm aware of, do like as a general principle.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Has the analysis been published yet?
I have been away on an artistic sabbatical, but I don't see it in the
inbox using searches, this was the last mail I received on the subject.
On 2018-10-26 18:31, Eben Moglen wrote:
> On Friday, 26 October 2018, [email protected] wrote:
>
> You are conflating case law dealing with commercial software and
> non-gratuitous licenses with the present situation, which would
> likely
> be a case of first-impression in nearly any jurisdiction.
>
> I think the best procedure would be for me to publish my analysis and
> for you then to tell me what is wrong with it. What you say here
> sounds like what a lawyer might say, but isn't. I have been teaching
> this stuff for about thirty years, so if I am conflating or confusing
> anything I will be grateful for help in seeing my mistake.
>
> The rule for gratuitous licenses is that they are revocable at the
> will
> of the grantor.
>
> That's not actually "the rule." It sounds like it might be the rule,
> but it so happens that it's not. When I have given the explanation as
> I have learned, taught and depended on it, you will be able to show me
> what I am wrong about.
>
> Raymond Nimmer (God rest his soul) was in agreement on this point,
> vis-a-vis the GPL and similar licenses.
>
> You have your Nimmers confused. The primary author of the treatise
> Nimmer on Copyright (a book about the law, not in itself an authority)
> was Melville Nimmer. The treatise is continued by his son, David, a
> fine lawyer with whom I do from time to time politely disagree about
> something. Ray Nimmer is quite another person.
>
> Eben
Your new explanation was refuted 5 hours after it was published.
---
Yes they can, greg.
The GPL v2, is a bare license. It is not a contract. It lacks
consideration between the licensee and the grantor.
(IE: They didn't pay you, Greg, a thing. YOU, Greg, simply have chosen
to bestow a benefit upon them where they suffer no detriment and you, in
fact, gain no bargained-for benefit)
As a bare license, (read: property license), the standard rules
regarding the alienation of property apply.
Therein: a gratuitous license is revocable at the will of the grantor.
The licensee then may ATTEMPT, as an affirmative defense against your
as-of-right action to claim promissory estoppel in state court, and
"keep you to your word". However you made no such promise disclaiming
your right to rescind the license.
Remeber: There is no utterance disclaiming this right within the GPL
version 2. Linus, furthermore, has chosen both to exclude the "or any
later version" codicil, to reject the GPL version 3, AND to publicly
savage GPL version 3 (he surely has his reasons, perhaps this is one of
them, left unstated). (GPLv3 which has such promises listed (not to say
that they would be effective against the grantor, but it is an attempt
at the least)).
The Software Freedom Conservancy has attempted to mis-construe clause 4
of the GPL version 2 as a "no-revocation by grantor" clause.
However, reading said clause, using plain construction, leads a
reasonable person to understand that said clause is speaking
specifically about the situation where an upstream licensee loses their
permission under the terms due to a violation of the terms; in that case
the down-stream licensee does not in-turn also lose their permission
under the terms.
Additionally, clause 0 makes it crystal clear that "You" is defined as
the licensee, not the grantor. Another issue the SFConservancy's public
service announcement chooses to ignore.
Thirdly, the SFConservancy banks on the ignorance of both the public and
the developers regarding property alienation. A license does not impinge
the rights of the party granting the license in a quid-pro-quo manner
vis a vis the licensee's taking. A license merely grants permission,
extended from the grantor, to the licensee, regarding the article of
property that is being impinged. A license is NOT a full nor is it a
permanent alienation of the article(property) in question. The impinged
property, being under a non bargained-for temporary grant, can be taken
back into the sole dominion of the owner - at his election to do so.
Now as to the 9th circuit appellate court's decision in Jacobsen v.
Katzer . While the court waxes eloquently about opensource licenses,
even mentioning the word "consideration" in it's long dicta, when it
comes time to make the binding decision the court found that the lower
(district) court was in _ERROR_ regarding the application of
contract-law principals to the Artistic License, regarding the case, and
instructed the lower court to instead construe said license as a
Copyright License.
The SFConservancy, and Bruce Perens have chosen to:
1) Rely on the dicta. (non-binding - "some things could be contracts -
opensource is great")
2) Ignore the actual ruling. (Binding - Copyright License - Not
Contract)
3) Ignore that this case was about the AL, not the GPLv2
4) Ignore the existence of different jurisdictions.
(Why file in the roll-the-dice 9th district if you can file in a
district that has personal-juristicion over the defendant and is much
more consistent in it's rulings?)
5) Ignore all established law regard property licensing, contract
formation, meeting of the minds, what consideration is etc.
Which is not surprising considering the desire of people like Bruce
Perens is to rob MEN of EVERY benefit of their Labour and every speck of
happiness in life and to transfer those benefits to WOMEN and those who
support women.
(This is why people who are like Bruce Perens, the SFConservancy
menbers, and the CoC supporters, banned men from taking female children
as brides: in contrivance to the law of YHWH (Devarim chapter 22 - -
verse 28 (na'ar (LXX: padia)), and continue to uphold that ban
world-wide, and seek to destroy ALL cultures that do no bend to their
will.... who are not idolators of Women)
Look, you may love your users, you may love the people who edit your
code in their home or office; but the fact of the matter is...
They have done nothing for you, they have promised nothing to you. They
CANNOT hold YOU.
You have the right to rescind at any time, and remove your work from any
future versions of Linux. And you might consider doing so if YOU are
done harm.
Don't let the insatiable, never-satisfied, public fool you into thinking
otherwise.
And, yes, I am a lawyer.
And, no, unlike the SFConservancy, I did not have to call upon outside
counsel to analyze the fact pattern. (And even then all they could come
up with was statements using weasel words "may" etc: not even wanting to
commit to their clearly-disingenuous publication)
(Note: If you would like to read a nice discussion on the topic, here is
one http://illinoisjltp.com/journal/wp-content/uploads/2013/10/kumar.pdf
)
On 2018-10-25 08:19, Greg Kroah-Hartman wrote:
> On Thu, Oct 25, 2018 at 07:56:26AM +0000, [email protected]
> wrote:
>> The linux devs can rescind their license grant.
>
> No they can not, please do not keep spreading false information.
>
> greg k-h
On 2018-10-29 22:31, Bradley M. Kuhn wrote:
> On Thu, Oct 25, 2018 at 07:56:26AM +0000, [email protected]
> wrote:
>> The linux devs can rescind their license grant.
> Greg KH responded on Thu, 25 Oct 2018 09:19:11 +0100:
>>> No they can not, please do not keep spreading false information.
>
> I was explicitly cc'ed on this thread by visionsofalice. I've read the
> whole thread, and the only useful thing I can contribute here is to
> agree
> with Greg and additionally provide some backup research on the point:
> https://sfconservancy.org/news/2018/sep/26/GPLv2-irrevocability/
>
> Software Freedom Conservancy engaged our legal counsel to write a new
> section for the Copyleft Guide that further explains the irrevocability
> of
> GPLv2. We published this when others raised these specious claims back
> in
> September. Direct link to new section:
> https://copyleft.org/guide/comprehensive-gpl-guidech8.html#x11-540007.4
>
>
> HTH,
Version 2 of the GPL forbids the incorporation of additional
restrictive terms, relating to the distribution, modification, etc of
the article licensed under the terms.
Those that violate this section are declared, by operation of the
terms, to have their grant automatically revoked.
An additional term need-not be present in the same writing. Such terms
simply need to be present to or made known to the taker(sub-licensee) by
the distributor. They may be proffered in writing, orally, or
implied in the course of doing business dealings. They simply must
relate back or involve the article in question (the licensed code or
product.)
The proffering of additional restrictive terms is a violation of the
text of the license grant in and of itself.
Here we have a situation where an additional writing has been
proffered. The additional writing promises both in it's own text and
by implication consequences against those who violate the terms of
this additional writing.
The additional writing restricts those subject to it from expressing
certain views publicly - promising retribution against those who do.
No consideration is paid to those subject to the additional writing
for their assent; it is simply imposed unilaterally against the
subjects.
The violators of the additional writing are promised:
Additional, unwanted, public scrutiny (to which they were not subject
to prior)
Public ridicule.
Loss of public standing.
as-well as an implied loss of future income.
These are the enforcement mechanisms of the additional writing to
enforce its restrictions against those who publish derivative works of
the kernel.
The additional writing is activated when (with the prerequisite of
being a derivative work of the linux kernel) the work of a rights-holder
is incorporated into the kernel, when such a work is made known to the
kernel-team to exist where any one person on this earth has seen fit
to present it for inclusion, or by simple prior-inclusion into the
kernel.
Thus all current and past rights-holders who have code in, or have
published for distribution, derivative works of the kernel are subject
to the retributive promises made to them in the additional writing,
drafted to restrict their actions and utterances.
This is tantamount to an additional restrictive term regarding the
modification and distribution of works under the linux kernel license
grant.
It is a violation of the license terms of the rights-holders past
incorporated works in much the same way that GRSecurity's
Contributor Access Agreement was and is.
Version 2 of the GPL forbids the incorporation of additional
restrictive terms, relating to the distribution, modification, etc of
the article licensed under the terms.
Those that violate this section are declared, by operation of the
terms, to have their grant automatically revoked.
An additional term need-not be present in the same writing. Such terms
simply need to be present to or made known to the taker(sub-licensee) by
the distributor. They may be proffered in writing, orally, or
implied in the course of doing business dealings. They simply must
relate back or involve the article in question (the licensed code or
product.)
The proffering of additional restrictive terms is a violation of the
text of the license grant in and of itself.
Here we have a situation where an additional writing has been
proffered. The additional writing promises both in it's own text and
by implication consequences against those who violate the terms of
this additional writing.
The additional writing restricts those subject to it from expressing
certain views publicly - promising retribution against those who do.
No consideration is paid to those subject to the additional writing
for their assent; it is simply imposed unilaterally against the
subjects.
The violators of the additional writing are promised:
Additional, unwanted, public scrutiny (to which they were not subject
to prior)
Public ridicule.
Loss of public standing.
as-well as an implied loss of future income.
These are the enforcement mechanisms of the additional writing to
enforce its restrictions against those who publish derivative works of
the kernel.
The additional writing is activated when (with the prerequisite of
being a derivative work of the linux kernel) the work of a rights-holder
is incorporated into the kernel, when such a work is made known to the
kernel-team to exist where any one person on this earth has seen fit
to present it for inclusion, or by simple prior-inclusion into the
kernel.
Thus all current and past rights-holders who have code in, or have
published for distribution, derivative works of the kernel are subject
to the retributive promises made to them in the additional writing,
drafted to restrict their actions and utterances.
This is tantamount to an additional restrictive term regarding the
modification and distribution of works under the linux kernel license
grant.
It is a violation of the license terms of the rights-holders past
incorporated works in much the same way that GRSecurity's
Contributor Access Agreement was and is.
Version 2 of the GPL forbids the incorporation of additional
restrictive terms, relating to the distribution, modification, etc of
the article licensed under the terms.
Those that violate this section are declared, by operation of the
terms, to have their grant automatically revoked.
An additional term need-not be present in the same writing. Such terms
simply need to be present to or made known to the taker(sub-licensee) by
the distributor. They may be proffered in writing, orally, or
implied in the course of doing business dealings. They simply must
relate back or involve the article in question (the licensed code or
product.)
The proffering of additional restrictive terms is a violation of the
text of the license grant in and of itself.
Here we have a situation where an additional writing has been
proffered. The additional writing promises both in it's own text and
by implication consequences against those who violate the terms of
this additional writing.
The additional writing restricts those subject to it from expressing
certain views publicly - promising retribution against those who do.
No consideration is paid to those subject to the additional writing
for their assent; it is simply imposed unilaterally against the
subjects.
The violators of the additional writing are promised:
Additional, unwanted, public scrutiny (to which they were not subject
to prior)
Public ridicule.
Loss of public standing.
as-well as an implied loss of future income.
These are the enforcement mechanisms of the additional writing to
enforce its restrictions against those who publish derivative works of
the kernel.
The additional writing is activated when (with the prerequisite of
being a derivative work of the linux kernel) the work of a rights-holder
is incorporated into the kernel, when such a work is made known to the
kernel-team to exist where any one person on this earth has seen fit
to present it for inclusion, or by simple prior-inclusion into the
kernel.
Thus all current and past rights-holders who have code in, or have
published for distribution, derivative works of the kernel are subject
to the retributive promises made to them in the additional writing,
drafted to restrict their actions and utterances.
This is tantamount to an additional restrictive term regarding the
modification and distribution of works under the linux kernel license
grant.
It is a violation of the license terms of the rights-holders past
incorporated works in much the same way that GRSecurity's
Contributor Access Agreement was and is.