Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Wednesday September 26 2018, @01:12PM   Printer-friendly
from the don-asbestos-garments dept.

[Updated 2018-09-26 20:30:00 to show the CoC is already in effect. --martyb]

[Ed Note: Given Linus Torvalds' recent decision to step down as head of Linux development for a while, and news of an attempt to install a a new CoC (Code of Conduct) on Linux development, I believe it important to communicate this to our community. It does, however, offer an opportunity for more, ummm, fire, flame, and feelings than the usual stories posted here. Let's try and keep things civil and discuss the merits (or lack of same). To quote Sergeant Joe Friday "All we're interested in is the facts, ma'am."

If you are not interested in this, another story will be along before too long... just ignore this one.

As for the code of conduct itself, take a look at: code of conduct and the kernel commit.]

Eric S. Raymond speaks in regards to the Linux CoC:

From(Eric S. Raymond)
SubjectOn holy wars, and a plea for peace
DateSun, 23 Sep 2018 16:50:52 -0400 (EDT)

Most of you know that I have spent more than a quarter century analyzing the folkways of the hacker culture as a historian, ethnographer, and game theorist. That analysis has had large consequences, including a degree of business and mainstream acceptance of the open source way that was difficult to even imagine when I first presented "The Cathedral and the Bazaar" back in 1997.

I'm writing now, from all of that experience and with all that perspective, about the recent flap over the new CoC and the attempt to organize a mass withdrawal of creator permissions from the kernel.

I'm going to try to keep my personal feelings about this dispute off the table, not because I don't have any but because I think I serve us all better by speaking as neutrally as I can.

First, let me confirm that this threat has teeth. I researched the relevant law when I was founding the Open Source Initiative. In the U.S. there is case law confirming that reputational losses relating to conversion of the rights of a contributor to a GPLed project are judicable in law. I do not know the case law outside the U.S., but in countries observing the Berne Convention without the U.S.'s opt-out of the "moral rights" clause, that clause probably gives the objectors an even stronger case.

I urge that we all step back from the edge of this cliff, and I weant[sic] to suggest a basis of principle on which settlement can be negotiated.

Before I go further, let me say that I unequivocally support Linus's decision to step aside and work on cleaning up his part of the process. If for no other reason than that the man has earned a rest.

But this leaves us with a governance crisis on top of a conflict of principles. That is a difficult combination. Fortunately, there is lots of precedent about how to solve such problems in human history. We can look back on both tragic failures and epic successes and take lessons from them that apply here.

To explain those lessons, I'm going to invite everybody to think like a game theorist for a bit.

Every group of humans trying to sustain cooperation develops an ethos, set of norms. It may be written down. More usually it is a web of agreements that one has to learn by observing the behavior of others. The norms may not even be conscious; there's a famous result from experimental psychology that young children can play cooperative games without being able to articulate what their rules are...

Every group of cooperating humans has a telos, a mutually understood purpose towards which they are working (or playing). Again, this purpose may be unwritten and is not necessarily even conscious. But one thing is always true: the ethos derives from the telos, not the other way around. The goal precedes the instrument.

It is normal for the group ethos to evolve. It will get pulled in one direction or another as the goals of individuals and coalitions inside the group shift. In a well-functioning group the ethos tends to evolve to reward behaviors that achieve the telos more efficiently, and punish behaviors that retard progess towards it.

It is not normal for the group's telos - which holds the whole cooperation together and underpins the ethos - to change in a significant way. Attempts to change the telos tend to be profoundly disruptive to the group, often terminally so.

Now I want you to imagine that the group can adopt any of a set of ethoi ranked by normativeness - how much behavior they require and prohibit. If the normativeness slider is set low, the group as a whole will tolerate behavior that some people in it will consider negative and offensive. If the normativeness level is set high, many effects are less visible; contributors who chafe under restriction will defect (usually quietly) and potential contributors will be deterred from joining.

If the normativeness slider starts low and is pushed high, the consequences are much more visible; you can get internal revolt against the change from people who consider the ethos to no longer serve their interests. This is especially likely if, bundled with a change in rules of procedure, there seems to be an attempt to change the telos of the group.

What can we say about where to set the slider? In general, the most successful - most inclusive - cooperations have a minimal ethos. That is, they are just as normative as they must be to achieve the telos, *and no more so*. It's easy to see why this is. Pushing the slider too high risks internal factional strife over value conflicts. This is worse than having it set too low, where consensus is easier to maintain but you get too little control of conflict between *individuals*.

None of this is breaking news. We cooperate best when we live and let live, respecting that others may make different choices and invoking the group against bad behavior only when it disrupts cooperative success. Inclusiveness demands tolerance.

Strict ethoi are typically functional glue only for small groups at the margins of society; minority regious groups are the best-studied case. The larger and more varied your group is, the more penalty there is for trying to be too normative.

What we have now is a situation in which a subgroup within the Linux kernel's subculture threatens destructive revolt because not only do they think the slider been pushed too high in a normative direction, but because they think the CoC is an attempt to change the group's telos.

The first important thing to get is that this revolt is not really about any of the surface issues the CoC was written to address. It would be maximally unhelpful to accuse the anti-CoC people of being pro-sexism, or anti-minority, or whatever. Doing that can only inflame their sense that the group telos is being hijacked. They make it clear; they signed on to participate in a meritocracy with reputation rewards, and they think that is being taken way from them.

One way to process this complaint is to assert that the CoC's new concerns are so important that the anti-CoC faction can be and should be fought to the point where they withdraw or surrender. The trouble with this way of responding is that it *is* in fact a hijacking of the group's telos - an assertion that we ought to have new terminal values replacing old ones that the objectors think they're defending.

So a really major question here is: what is the telos of this subculture? Does the new CoC express it? Have the objectors expressed it?

The question *not* to get hung up on is what any individual's choice in this matter says about their attitude towards, say, historically underepresented minorities. It is perfectly consistent to be pro-tolerance and pro-inclusion while believing *this* subculture ought to be all about producing good code without regard to who is offended by the process. Not every kind of good work has to be done everywhere. Nobody demands that social-justice causes demonstrate their ability to write C.

That last paragraph may sound like I have strayed from neutrality into making a value claim, but not really. It's just another way of saying that different groups have different teloi, and different ethoi proceeding from them. Generally speaking (that is, unless it commits actual crimes) you can only judge a group by how it fulfills its own telos, not those of others.

So we come back to two questions:

  1. What is our telos?
  2. Given our telos, do we have the most inclusive (least normative) ethos possible to achieve it?

When you have an answer to that question, you will know what we need to do about the CoC and the "killswitch" revolt.
--
                Eric S. Raymond

The spirit of resistance to government is so valuable on certain occasions, that I wish it always to be kept alive. It will often be exercised when wrong, but better so than not to be exercised at all. I like a little rebellion now and then. -- Thomas Jefferson, letter to Abigail Adams, 1787

LKML URL: http://lkml.org/lkml/2018/9/23/212

Possibly in reference to: http://lkml.org/lkml/2018/9/20/444


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by exaeta on Wednesday September 26 2018, @05:41PM (1 child)

    by exaeta (6957) on Wednesday September 26 2018, @05:41PM (#740334) Homepage Journal

    Under U.S. Law, it's possible though difficult to withdraw copyright.

    In part, it requires at least 35 years after the grant to pass before it can be revoked. Also, there's a delay between when the notice of termination is served and when the grant actually terminates. This delay can be used to remove offending code from the kernel and file a lawsuit against the revoker. Not only that, but they can't revoke the Linux kernel license under GPLv2 easily because of the following:

    In the case of a grant executed by two or more authors of a joint work, termination of the grant may be effected by a majority of the authors who executed it

    17 U.S. Code ยง 203. (https://www.law.cornell.edu/uscode/text/17/203)

    They wont get a majority. So it seems this idea is dead as I'd consider the Linux kernel a very good example of a "joint work". I think there are too many contributors for this to be practical under U.S. Law.

    Second, revoking a grant under GPLv2 would be a GPLv2 violation, even if it's allowed under statute. That would mean that any code which has ever been combined with code which the license has been revoked, would become a license violation if the person who revoked the license tried to modify or distribute it. Thusly, they would permanently lose license to the rest of the code. So even if the revoked code is replaced, since GPLv2 doens't have an automatic restoration clause, they'd be forbidden from using it.

    I'd also argue each instance of distributing the code is a "grant" under the license.

    --
    The Government is a Bird
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by choose another one on Wednesday September 26 2018, @07:52PM

    by choose another one (515) on Wednesday September 26 2018, @07:52PM (#740424)

    In part, it requires at least 35 years after the grant to pass before it can be revoked.

    Correct, so no GPLv2 code can be revoked until 2026 (since GPLv2 didn't exist till 1991). However, notice can be given up to ten years before revocation, so early Linux contributors could be able to give notice now. Such notice would have major chilling effect on development because no one knows where the next notice is coming from or how big the next replace-code-with-new-cleanroom-code job will be.

    In the case of a grant executed by two or more authors of a joint work, termination of the grant may be effected by a majority of the authors who executed it

    Except Linux is not a joint work, software is interdependent / derivative work. This is good, because any owner of a joint work can re-licence it under any terms without permission of the other owners (although they have a duty to account - i.e. pay the other joint owners their share of what they make). This is emphatically what you don't want in a GPL project. Essentially if open source GPL projects were joint works then any contributor could re-licence the whole project as proprietary, making GPL more like BSD. A joint work also requires the joint authors to have the intent of creating a joint work - and use of the GPL clearly demonstrates that that is not the intent (because of the right of joint owners to re-licence the entire work).

    See e.g. https://scholarship.law.upenn.edu/cgi/viewcontent.cgi?article=3845&context=penn_law_review [upenn.edu] page 1269 onwards for more details.