September 20, 2018
Related Material:
Additional Participants: Arnaldo Carvalho de Melo, Daniel Vetter, David Woodhouse, Eric W. Biederman, Geert Uytterhoeven, James Bottomley, Jani Nikula, Joe Perches, Josh Triplett, Laurent Pinchart, Luck, Tony, Mark Brown, Mauro Carvalho Chehab, Rafael J. Wysocki, Stephen Hemminger, Steven Rostedt, Takashi Iwai, and Tim Bird.
Dave would like a report by the people who signed off on the CoC for the benefit of those not involved in the thoughts/process of updating it. Dave notes that a public talk might quickly descend into farce, but suggests something like a Chatham House Rule meeting, or perhaps just a non-public non-recorded session (as has been done for sensitive topics in the past). Dave also suggests that Linus Torvalds videotape a statement for those who, like Dave, cannot make Edinburgh but might make Vancouver BC. Dave is not concerned about the CoC itself, having worked under its strictures on the FreeDesktop project for more than a year. Steven Rostedt volunteered to lead the discussion. Daniel Vetter welcomed the CoC, but expressed surprise at the haste with which this appeared (stating that the normal timeframe was measured in years rather than days) and expressed concern about conspiracy theories and ugly unintended consequences. [ Ed. note: Daniel is not the only one surprised and concerned. ] Geert Uytterhoeven seconded Daniel's surprise, also noting that Commit ddbd2b7ad99a418c (“Code of Conflict”) was acked by 66 developers as opposed to only 7 Signed-off-by tags for Commit 8a104f8b5867 (“Code of Conduct: Let's revamp it.”), including Linus's Signed-off-by.
James Bottomley expressed a strong preference for a root canal over debating a CoC, suggesting that Linux-kernel developers and maintainers might have better things to do than wrangle over a widely-accepted CoC such as this one. In contrast, Daniel argued that the insistence on not discussing these topics is what brought us to this point, suggesting that such insistence might not constitute an effective strategy going forward.
Mauro Carvalho Chehab called out the following excerpts of the CoC:
"Examples of unacceptable behavior by participants include:
...
- Publishing others’ private information, such as a physical or electronic address, without explicit permission"
Mauro suggested that publishing a patch with Reviewed-by, Acked-by, Requested-by, Suggested-by, etc. entails publishing an electronic address, potentially in conflict with the CoC. Mauro speculated that Signed-off-by was covered by clause (d) of DCO 1.1, and thus not in conflict with the CoC. Josh Triplett argued that the posting of public emails addresses would avoid the CoC's “private information” stricture, but agreed that adding an otherwise unpublished email address on an Acked-by (for example) would be problematic, suggesting that this situation be documented somewhere (Steven Rostedt said that he asks permission in such cases). Mauro wasn't so sure, given that the CoC explicitly calls out “electronic address without explicit permission”, and argued that the CoC itself should explicitly address this point (Josh reasserted his preference for outside-of-CoC guidance), noting further that it is not uncommon for maintainers to add Requested-by, Suggested-by, and Tested-by for someone who has not publicly posted. Takashi Iwai agreed that this is a common practice that is used to give credit for various types of contributions. Takashi suggested keeping the name but dropping the email address in such cases. James argued that DCO 1.1 clause (d) contains “including all personal information I submit with it”, which he believes covers all the other tags, not just Signed-off-by. James also agrees that already-public email addresses are not prohibited by the current CoC wording, suspecting that the examples in the CoC are holdovers from github-style environments where email addresses are not necessarily part of the workflow, and thus might reasonably remain private.
Mauro saw James's point, but argued that if the examples don't generally apply, then they should be removed from the CoC, further stating that he believes that the CoC is a legal document, albeit in his opinion a very poorly written one. Mauro added that he waiting for legal advice on the CoC's relation to US laws. He strongly believes that the CoC is a legal document under Brazilian law, but cannot say whether it would be deemed valid or void. James in turn saw Mauro's point about the CoC potentially being a legal contract, but noted that this CoC is not the worst that he has seen. However, James then gave a more detailed argument that the current CoC should not be construed as prohibiting the use of tags containing email addresses that have already been made public. Mauro countered that solvable problems in the current CoC wording should be fixed, or, failing that, the Linux kernel community should revert the patch and go back to the old CoC. Mauro further believes that this email-address issue is but the tip of the iceberg of issues with the new CoC. Mauro also acknowledged James's point regarding already-public email addresses, but argued that these terms should be explicitly defined, especially given that these concepts can vary from jurisdiction to jurisdiction. Mauro adds that he is fine with the idea of having a CoC, but that it should be prepared by someone who understands the legal impacts.
Mauro then re-read the CoC, reverting to his initial opinion that publishing email addresses could reasonably be construed to violate the CoC. Tony Luck responded by proposing a patch to the new CoC that explicitly states that using public email addresses is OK, to which Mauro gave his Reviewed-by, and which Tim Bird agreed with. For his part, Arnaldo Carvalho de Melo suggested clarifying Acked-by:
Acked-by: is not as formal as Signed-off-by:. It is a record that the acker has at least reviewed the patch and has indicated acceptance. Hence patch mergers will sometimes manually convert an acker's “yep, looks good to me” into an Acked-by: (but note that it is usually better to ask for an explicit ack).
Laurent Pinchart suggested focusing on the intent, which he believes is to avoid disclosing only that information that is not already public. Laurent also advocates clearly stating that accidental disclosure of private information that could reasonably be interpreted as non-private by the disclosure should not result in immediate retaliation on the first occurrence. Laurent further states:
The goal of the code of conduct, as I interpret it, is to define the generally accepted an unaccepted behaviour, not to be used as an excuse to punish anyone.
Dave Airlie argued against the notion of the CoC being a legal contract, noting that this could entail legal (as opposed to community) repercussions from violating it. Dave also noted that the drm subsystem avoids the private-email-disclosure problem by requiring that non-security-related private emails be resent publicly. Finally, although Dave has no objection to clarifying the CoC, he does not believe that turning it into something resembling a legal employment contract is going to be helpful. Mauro argued that the new CoC is already a legal contract, and offered a patch to remove the legalese (and Stephen Hemminger asked that the Oxford comma be retained). Joe Perches asked that the entire second paragraph of the “Our Responsibilities” section be removed, arguing that maintainer are responsible for code and the community for behavior. Laurent asked who the community was, and suggested that whatever it is, maintainers are part of it. Joe agreed that maintainers are part of the community, but argued that nominal policing of inappropriate behaviors should not be restricted to the maintainers.
Tim was not convinced that the new CoC is a legal contract, noting that it is already in use by a lot of projects, and suggesting checking with some of these projects to see what the experience has been. Jani Nikula agreed with Tim, and questioned the wisdom of tweaking the new CoC, suggesting that any such changes be submitted to the upstream version of the CoC, a sentiment seconded by Josh and Daniel. David Woodhouse noted that Linus did in fact edit the GPL by prepending text, and suggested that the same be done with the new CoC (and Daniel agreed that this is a reasonable approach). Laurent Pinchart suggested adding a FAQ next to the new CoC providing any needed clarifications. Although Mauro agreed that these might be reasonable approaches for the github-based projects in which the new CoC has been used, he believes that the large size, high change rate, and email-based workflow of the Linux kernel requires someething quite different. Mauro suggests the following alternatives:
Mauro further said that he will wait until either the CoC changes appropriately or until after the upcoming Maintainer's summit before sending any pull requests upstream. Jani called “FUD” citing experience with the new CoC by the drm subsystem. Mauro reiterated his concerns, including ASCII-art diagrams for emphasis. Tim suggested that Mauro's concerns were blown out of proportion, further suggesting that Mauro continue submitting pull requests as usual. Tim also believes that the roll-out of CoC enforcement will be a long and slow process with plenty of opportunities for community input, and that the vast majority of the kernel community are respectful and well-meaning individuals on whom no negative repercussions will be inflicted. Mauro reiterated that he likes the idea of having a CoC and being respectful, but noted that making the rollout process explicit up front would have been preferable. Nevertheless, Mauro looks forward to participaing in roll-out discussions.
Laurent suggested a public forum where concerns could be posted, noting that discussing the terms of the new CoC and/or FAQ could be difficult. Tim Bird liked the idea of discussion before Maintainers Summit, and hopes that a FAQ would provide LF TAB members a list of “hot issues” with this change. Tim also stated that he found this discussion to be quite valuable. Laurent Pinchart agreed that this thread is useful, but found the silence on LKML to be deafening given the importance of the announcement. Laurent is concerned that this indicates that there have been a lot of private conversations. Laurent agrees that a FAQ would be useful to help LF TAB understand which questions are most important to the community, and asked his question:
Since Linus' announcement that took many people by surprise (obviously not everybody as the code of conduct patch was signed by several TAB members, but by no means by a vast majority of the community), all sort of discussions took place in private, and rumours have started spreading regarding the events that led to this situation. I believe I'm not the only one who would like to be informed about the history of this unusual development. While I understand that not all information can (or should) always be disclosed, this isn't a case of voyeurism, some sort of official story would in my opinion help giving cohesion to the Linux kernel community.
Mauro noted that the old CoC does not “turn maintainers into baby sitters, making them accountable for any bad behavior on every place where a member of the community misbehaves.” [ Ed. note: See the comment that Mauro posted in response to the LWN article called out above. ] Rafael J. Wysocki aired similar concerns, and also wondered if the new CoC requires him to reject correct code changes (including security-critical bug fixes) from a person whose behaviors are deemed “inappropriate, threatening, offensive, or harmful”. Daniel replied “Ultimately, yes”, but noted that this has not yet been necessary on dri-devel (Mark called out a case where he rejected a bug fix due to abusive language in the commit message). Instead, commit rights have been temporarily suspended and people have been removed from maintainership positions. However, the first offense gets a public reply detailing the problematic behaviors. Daniel also stated that CoC enforcement is a skill that requires learning and practice, and that there are a lot of people offering training.
Eric W. Biederman also reported concerns on the speedy acceptance and lack of public debate. Eric also noted that the normal rules would include this patch in a merge window, not in -rc4. Eric pointed out that the old-CoC remedy for issues was escalation to the LF TAB, which is the same remedy for the new CoC. Eric further stated that the only real power that Linux-kernel maintainers have is to reject patches, and that maintainers cannot be expected to maintain mailing lists, an added duty for which they simply do not have time. Eric agrees with Mauro that the CoC acts as a legal document, and further suggested that the added requirements might be on the edge of a GPL violation. Eric said that the concept of an official Linux-kernel anything is strange, stating that kernel.org exists but is not official. Eric also said that the function of the LF TAB is to keep the LF in line, not the various developers and maintainers, and believes that the new CoC has not been well explained or well thought through. Eric listed the types of abuses he does see:
Dmitry Torokhov echoed Eric's concerns on speedy acceptance, noting that the old CoC was at least somewhat circulated among maintainers.
Jonathan Corbet, after first noting that he was speaking only for himself, noted that he had taken a fair amount of criticism for saying that people have reasons to be worried about a change done in this manner. Jon also said that communication is crucial, and that the community should not rely solely on the LF TAB or the Maintainers Summit to come up with all the right answers, noting that there are some seriously irrational discussions going on over the wider net, and expressing a preference for rational discussion by the broader Linux kernel community. Finally, Jon stated that he does not know of anyone who has a complete picture (himself included), but that he would try to bring the complete picture out in the open. However, he expects that this might take some time.