The new Code of Conduct makes me feel threatened and uncomfortable.
No, really. As a person with (diagnosed) Asperger's, I'm a member of,
objectively, a marginalised minority. Effectively (i.e. this is a massive
oversimplification), I was born without the hard-wired circuitry for
social
interactions that is normally a part of the human brain; consequently
I have
to run a slow and inaccurate software simulation when interacting with
'normal' people.
In nearly all the communities I participate in, this is a constantly
limiting
factor for me. But there is one world that is blessedly free of such
things:
the world of open-source software. It is one of the last places where my
particular neurodiversity does _not_ mark me out as Other, does _not_
force
me to carefully watch what I say and present a falsely constructed
façade in
place of my real identity. For here, we care not for 'feelings';
either the
code is good or it is bad, and in the latter case we say so directly and
bluntly. Not only does this mean that I don't have to guard my tongue
when
critiquing someone else's patch, far more importantly it means I can
understand what's being said when _my_ patches are criticised.
(Almost all
of my best ideas and patches have been born out of someone telling me I'm
wrong.)
The Linux kernel community is a place without office politics, without
subtle
subtexts, without primate dominance dynamics. A place where criticism
_can_
be gracefully accepted _without_ having to worry that admitting to being
wrong will lower one's status. A place where I, and people like me,
can feel
at home, and maybe even create something of value.
And the Contributor Covenant looks very much like the camel's nose of an
attempt to take that place, that community, away from me. To replace
it with
an Orwellian nightmare where I must forever second-guess what is safe
to say.
(First they came for "master/slave replication", and I did not speak up
because I was not a DBA.)
I cannot speak for my employer (hence why I am posting this from my personal
address), but to the extent that my rôle as a contributor to the
networking
subsystem, and as co-maintainer of the sfc driver, gives me any
standing in a
_personal_ capacity, I absolutely cannot sign up to this 'Pledge' nor
accept
the 'Responsibilities' to police the speech of others that it makes a
duty of
maintainership, and I urge the project leadership to revert its adoption.
Some elements of the Code are unobjectionable; sexual advances, for
instance,
have no place on the lkml (though they may at, say, a conference, and not
everyone can reliably predict whether they are unwelcome), and the
ability of
kernel developers to accept constructive criticism is one of the strengths
that has made Linux what it is. But far too many of its provisions
rely on
ill-defined terms, and thus give those charged with interpreting those
terms
the power to destroy livelihoods. By placing a corporate body (the LF) in
the position of arbiter, an avenue is opened for commercial pressure to be
applied; and the legalistic phrasing of the Code practically invites
rules-
lawyering whereby the most abusive may twist it into a weapon to further
their abuse.
If the Code were reduced to something more like the old Code of Conflict,
reminding people to 'be liberal in what they accept and conservative
in what
they emit', and clarifying that patch submissions should be judged by the
_code_ and not by any characteristics or beliefs of the submitter (I don't
think the enumerated list of protected classes is helpful, as a legalistic
abuser can always slip into a crack between them), I think the sting
would be
drawn. Probably the CoConflict would make a better base from which to
draft
such a document.
(A note for the irony-challenged: where I use Progressive terms-of-art, such
as 'marginalised', 'Other' and 'identity', in the above, I am
endeavouring to
show that this alleged push for 'inclusiveness' fails on its own
terms; I am
_not_ accepting the theory behind those terms nor suggesting that, in
reality, the kernel community owes me any special treatment on account
of my
'diversity'.)
On Wed, 19 Sep 2018 07:00:26 +0100
Edward Cree <[email protected]> wrote:
> By placing a corporate body (the LF) in
> the position of arbiter, an avenue is opened for commercial pressure to be
> applied; and the legalistic phrasing of the Code practically invites
> rules-
> lawyering whereby the most abusive may twist it into a weapon to further
> their abuse.
I'd like to address just this part, speaking only for myself.
The LF is not in the position of arbitrating anything here. The body
charged with that is the LF Technical Advisory Board, which is a
different thing. It's currently this motley crowd:
https://www.linuxfoundation.org/about/technical-advisory-board/
I think most of us would agree that those folks lack the desire to go
around harassing developers, and they lack the time to do so in any
case.
The TAB is chosen by a vote of developers at the kernel summit; that will
happen in Vancouver in November.
jon
On 19/09/18 15:18, Jonathan Corbet wrote:
> I'd like to address just this part, speaking only for myself.
> The LF is not in the position of arbitrating anything here. The body
> charged with that is the LF Technical Advisory Board, which is a
> different thing.
Thank you for clarifying that.
Jon, you're a good person, and I trust you not to harass developers.
I'm not expecting you, or gregkh, or hpa to launch a dastardly plot
to boot an innocent developer off the project.
But there are too many ways this can go wrong, maybe not now or next
week but in five or ten years, when maybe a different kind of person
is on the TAB, or maybe external pressure is brought to bear on TAB
members. (Some people are speculating that pressure has already
been brought to bear on Linus, although I'd like to stress that if
he feels that changing the way he communicates is best for the
project then I for one thoroughly respect that.)
Or maybe some manipulative extrovert will manage to whip up a media
storm about some developer's innocuous remarks, the court of public
opinion will immediately convict, other developers will be caught
in a preference falsification cascade as no-one wants to take the
risk of defending them. Are you, and the other members of the TAB,
strong enough to hold back the lynch mobs when you know the guy
hasn't done anything wrong? Do you really want to take on the
responsibility to do that, perhaps time and time again? And can
you be sure that you won't fall for a misleading framing by some
charismatic sociopath of a fight you missed the start of?
Given that possibility, I think it is important for the kernel
community to continue to send a strong signal that divisive identity
politics are not welcome here; and I think that to adopt a Code of
Conduct that contains in its opening sentence a laundry-list of
protected classes (and was written by a, shall we say, divisive
figure with a history of identity politics advocacy) sends precisely
the opposite signal.
Linux is too important to civilisation to allow it to be turned into
just another battlefield for the American culture war; commit
8a104f8b5867 seems like an invitation to both armies to take up
positions on our fertile farmland. The only rule that gives no
comfort to discriminatory political abusers (on either side) is—
ye shall judge by their code alone.
Hi,
I'd like to clarify that I am replying here in my personal capacity,
and not on behalf of the TAB or anyone else.
On Thu, Sep 20, 2018 at 12:35 AM, Edward Cree <[email protected]> wrote:
> On 19/09/18 15:18, Jonathan Corbet wrote:
>> I'd like to address just this part, speaking only for myself.
>> The LF is not in the position of arbitrating anything here. The body
>> charged with that is the LF Technical Advisory Board, which is a
>> different thing.
>
> Thank you for clarifying that.
>
> Jon, you're a good person, and I trust you not to harass developers.
> I'm not expecting you, or gregkh, or hpa to launch a dastardly plot
> to boot an innocent developer off the project.
I would be very surprised if any of my peers on the TAB ever had those
intentions, and I know I would not have them myself.
> But there are too many ways this can go wrong, maybe not now or next
> week but in five or ten years, when maybe a different kind of person
> is on the TAB, or maybe external pressure is brought to bear on TAB
> members.
This is an important topic, and something that will need consideration.
One thing to keep in mind is that we all want what is best for Linux,
to make the best possible kernel. None of this has changed that.
I personally find it unlikely that relevant pressure could be applied
on TAB members; I don't find it a prestigious role such that it is
worth holding on to against my own values or best judgement.
> (Some people are speculating that pressure has already
> been brought to bear on Linus, although I'd like to stress that if
> he feels that changing the way he communicates is best for the
> project then I for one thoroughly respect that.)
We should let Linus speak for himself and his motivations when he's
back, if he wants to. He has shown to be *extremely* resilient to
outside pressure for the entire history of the project, and to
speculate over his motives now doesn't do any good.
> Or maybe some manipulative extrovert will manage to whip up a media
> storm about some developer's innocuous remarks, the court of public
> opinion will immediately convict, other developers will be caught
> in a preference falsification cascade as no-one wants to take the
> risk of defending them. Are you, and the other members of the TAB,
> strong enough to hold back the lynch mobs when you know the guy
> hasn't done anything wrong? Do you really want to take on the
> responsibility to do that, perhaps time and time again? And can
> you be sure that you won't fall for a misleading framing by some
> charismatic sociopath of a fight you missed the start of?
There is a lot of focus in several discussions right now on punishment
and what will be done to those who violate the code of conduct. I'm
much more interested in figuring out what we can do to help mediate in
case of disagreements such that all parties can get along and work
together. That's the end goal for me. It's what the last document
tried to encourage, but as the commit message says, it wasn't showing
to be an effective approach so a new one is worth trying out.
Another common counter argument is that the code of conduct is
imposing what's appropriate thoughts and opinions on everybody. I can
see how that kind of environment _could_ be implemented with the same
code of conduct as a base, but it doesn't have to be and I know I
would fight strongly against that. I much prefer all be free to have
their opinions, but at the same time be respectful of each other when
we communicate. There are extreme edge cases but they're theoretical
at this point.
Disagreements are fine to have, and in many cases they lead to better
solutions in the end. What's not OK to me is when they veer off of the
path of respectful and productive discussion.
> Given that possibility, I think it is important for the kernel
> community to continue to send a strong signal that divisive identity
> politics are not welcome here; and I think that to adopt a Code of
> Conduct that contains in its opening sentence a laundry-list of
> protected classes (and was written by a, shall we say, divisive
> figure with a history of identity politics advocacy) sends precisely
> the opposite signal.
There is a list in the first paragraph, but the preceding words say
that it should be a *harassment-free experience for everyone*. That
part of the paragraph is to me the most important part.
Also, it doesn't particularly matter to me personally who wrote the
text, as much as what is in it, and how we apply it. Just as I might
not agree with everything that FSF or Richard Stallman says or does
but still approve of the GPL as a license.
> Linux is too important to civilisation to allow it to be turned into
> just another battlefield for the American culture war; commit
> 8a104f8b5867 seems like an invitation to both armies to take up
> positions on our fertile farmland. The only rule that gives no
> comfort to discriminatory political abusers (on either side) is—
> ye shall judge by their code alone.
Your above argument that the Code of Conduct is problematic because of
who wrote it seems to contradict your statement that we shall judge by
code (or text) alone.
I don't know of anyone who is looking to make code less important. I
sure am not. To me, this is about how we treat each other when we
discuss said code and other things around it (such as how we run the
project).
Finally, I'd like to comment on your initial concern that you already
have to work hard on communication, and that this makes you fearful of
consequences if you fail to get it right. I'd like to say that you've
been doing a great job at it, well done. Also:
1) I searched for your address in the mailing lists archives I have
here, and from what I see, I have zero concerns with any of what I've
read.
2) Even if that's not the case, I'm of the strong opinion that we
should assume good intentions by default, and help out and mediate in
case something comes up.
When it comes to on-topic mailing list behavior, I can construct
extreme situations that I think should be addressed harder than
de-escalation and mediation from the start, but we've had very little
of that in our community so far. Often it gets bad over time or after
a series of back-and-forth, and if we can help de-escalate or get
people to cool off, that'd resolve a lot of it.
-Olof
On 20/09/18 02:16, Olof Johansson wrote:
> I would be very surprised if any of my peers on the TAB ever had those
> intentions, and I know I would not have them myself.
In case my references to individualsmade it unclear: I have no reason to
suspect _any_ of the present TAB members would; everything I know about
them points to them being good, honest and principled people.
> I can
> see how that kind of environment _could_ be implemented with the same
> code of conduct as a base, but [...] I know I
> would fight strongly against that.
It is definitely reassuring to hear you say that.
> There is a list in the first paragraph, but the preceding words say
> that it should be a *harassment-free experience for everyone*. That
> part of the paragraph is to me the most important part.
It certainly _should_ be the most important; IMHO the sentence should end
after 'everyone'.
> Your above argument that the Code of Conduct is problematic because of
> who wrote it seems to contradict your statement that we shall judge by
> code (or text) alone.
I think there are important differences between code to be run by CPUs
and a Code to be run by humans. And when the author goes on a victory
lap on Twitter and declares the Code to be "a political document", is
it any surprise I'm worried?
Applying extra scrutiny to a political document written by someone with a
history ofstirring up political antagonism is like checking the locking
extra-carefully in a patch from a developer who has a history of letting
locking bugs slip through.
On Thu, Sep 20, 2018 at 02:16:40AM +0100, Olof Johansson wrote:
> > But there are too many ways this can go wrong, maybe not now or next
> > week but in five or ten years, when maybe a different kind of person
> > is on the TAB, or maybe external pressure is brought to bear on TAB
> > members.
>
> One thing to keep in mind is that we all want what is best for Linux,
> to make the best possible kernel. None of this has changed that.
>
> I personally find it unlikely that relevant pressure could be applied
> on TAB members; I don't find it a prestigious role such that it is
> worth holding on to against my own values or best judgement.
Even *if* pressure could be applied to TAB members, it's important to
remember that the TAB as a body gets its influence and moral authority
from the people who have agreed to serve on it, and not the other way
around. People join the TAB because they want to serve. It's not
because being on the TAB grants some kind of mystical power, because
it doesn't. Ultimately, the "A" in TAB stands for Advisory.
The TAB does not get to control whether patches gets accepted into the
linux-media git tree. Mauro gets to decide that. The TAB does not
get to control whether or not Linus accepts pull requests from a
subsystem maintainer; that's up to Linus. The TAB doesn't run
vger.kernel.org. That's done by David Miller.
Look at what happened when a particular developer decided to do the
anti-social thing and become a copyright troll. It was not the TAB
which decided that no further code contributions should be accepted
from that particular person. It was the Netfilter team.
Linux Maintainers have always had the power to reject patches for any
reason. It isn't just for technical reasons, as the Netfilter team
demonstrated with the copyright troll. (Of course, the person whose
patch has been rejected can always appeal to Linus, by sending the
patch directly to Linus. None of this has changed; it always has been
this way.)
The TAB can make a recommendation, but the decision to act on that
recommendation resides with the Maintainers in general, and
ultimately, Linus.
- Ted
Hi Olof,
I expected not to participate to this boring discussion, but I think
I need to make a point below :
On Thu, Sep 20, 2018 at 02:16:40AM +0100, Olof Johansson wrote:
> Another common counter argument is that the code of conduct is
> imposing what's appropriate thoughts and opinions on everybody. I can
> see how that kind of environment _could_ be implemented with the same
> code of conduct as a base, but it doesn't have to be and I know I
> would fight strongly against that. I much prefer all be free to have
> their opinions, but at the same time be respectful of each other when
> we communicate. There are extreme edge cases but they're theoretical
> at this point.
>
> Disagreements are fine to have, and in many cases they lead to better
> solutions in the end. What's not OK to me is when they veer off of the
> path of respectful and productive discussion.
The reason people are concerned is a matter of culture.
There simply is *no* way to have a completely respectful *and*
productive discussion which works fine around the globe because
people don't have the same emotional offsets when they send and
when they receive.
In some eastern Europe countries someone would naturally say "you're
completely wrong" without any mean intent. In western Europe, people
would instead say "I disagree with you" and in the US they will say
"let me think about it". All of these mean the same thing when they
speak to people of the same culture, but are taken as very slick or
even hypocrit sayings when going from one direction, or as abusive
when going the other direction.
Is this a problem and if so, what can be done about it ? It's a
temporary issue only which will continue to appear from time to time
in various discussions. However, the CoC should be used as a reminder
to both parties during strong arguments :
- the sender should take a look at the CoC as a reminder and see
the difference between insults and just having a strong
argument, and sometimes say "OK excuse me for this one"
- the receiver who feels he's not respected should take a look at
the CoC and think that very likely the sender tries to comply
with it and think twice considering that what he feels is an
insult might just be a way of expressing oneself in another
culture and should not be taken personal.
In my opinion there is a reason why a number of those who people
fear originate from Europe, and there's a reason why those who need
to invent CoC because they feel not respected come from US. It's
just a matter of different culture. None of them are wrong, but it
hurts more one way than the other one. The other way around also
exists (i.e.: "this person bores me") and can be detrimental to
productive code as well if contributors are not trusted by being
"too slick", but then nobody feels hurt and nobody complains about
it.
Personally I don't take the CoC as a rule but just as a guideline and
a reminder that there are people out there who could feel shocked by
my words without me understanding why. It's also these people's
responsibility to report this to me so that I can learn to better
communicate with them in a way that doesn't hurt their sensitivity.
I personally never felt hurt by the words of anyone here, including
Linus telling me things around "you're stupid" because that's the
natural way to express a disagreement in my culture and I understand
it in a way which other people would probably translate to "dear
willy, please listen to me more carefully because I think it might
be the third time I try a different approach to explain this to you".
For some people the latter is more appropriate, but I personally hate
its efficiency and I strongly prefer the former. However I can
understand that other people would prefer the latter and that's
where it seems to me that senders should make the effort to be half
ways between the two and receivers should make the effort to think
that a half-way sentence means one or the other depending on their
culture but that they are similar and not irrespectful.
I would not be surprised if most of the people having issues with
the CoC were mostly european and if the people who feel protected
by it are mostly US-based (please note that I'm saying "mostly",
I'm not cutting the world between two sides). It's just that the
document tries to address ones' sensitivity at the expense of the
ability to use natural ways to express oneself for other ones, and
some can feel a bit censored. I tend to think that the doc should
talk about cultural differences and translation issues when turning
natural language to English before starting to speak about insults
or attacks, but that's not very important IMHO.
Overall I'm not worried by what's in this file, people will make a
lot of noise about it for two weeks, will explain how hypocrit they
feel it is or how insufficient it is to protect their sensitivity,
nobody will change much the way they communicate, but over time
people will learn to think "maybe he didn't really mean this", and
that will already be a step forward. We'll see in Greg's next annual
report if this has a negative implication on the number of commits
per hour, since in the end it's all that matters (and I bet it won't).
Regards,
Willy
Regarding those who are ejected from the Linux Kernel Community after
this CoC:
Contributors can, at any time, rescind the license grant regarding their
property via written notice to those whom they are rescinding the grant
from (regarding their property (code)).
The GPL version 2 lacks a no-rescission clause (the GPL version 3 has
such a clause: to attempt furnish defendants with an estoppel defense,
the Linux Kernel is licensed under version 2, however, as are the past
contributions).
When the defendants ignore the rescission and continue using the
plaintiff's code, the plaintiff can sue under the copyright statute.
Banned contributors _should_ do this (note: plaintiff is to register
their copyright prior to filing suit, the copyright does not have to be
registered at the time of the violation however)
Additionally when said banned contributors joined the Linux team, they
were under the impression that it was a meritocracy: in-fact this belief
was stated or ratified by those within the governing body regarding
Linux when the contributors began their work (whatever that body was at
that time, it could have been simply Linus, or Linus and a few
associates).
The remuneration for the work was implied to be, or perhaps stated, to
be fame as-well as a potential increase in the contributors stature, in
addition to membership in the Linux Kernel club or association, or
whatever it is that the Linux Kernel Community actually is (which a
court may determine... it is something, suffice to say).
Thusly for work, consideration was promised by (Linus? Others? There are
years of mailing list archives with which to determine).
And now that consideration has been clawed-back and the contributors
image has been tarnished.
Thus the worker did work, however the other side of the implied, or
perhaps written (email memorandums), understanding has been violated
(once the contributor has been banned under the new non-meritocratic
"CoC").
Damages could be recovered under: breach of contract, quazi-contract,
libel, false-light. (services rendered for the contractual claims,
future lost income for the libel claims)
In addition to copyright claims. (statutory damages, profits)
For greatest effect, all rescission should be done at once in a bloc.
(With other banned contributors).
Contributors: You were promised something, you laboured for that
promise, and now the promise has become a lie. You have remedies
available to you now, as-well as in the close future.
Additionally, regarding those who promoted the Code of Conduct to be
used against the linux kernel contributors, knowing full well the effect
it would have and desiring those effects; recovery for the ejected
contributors via a tortious interference claim may be possible.
Code of Conduct: Those Ejected should rescind their license grant.
The grant is not supported by consideration.
It dispenses only largess, and asks for no recompense.
It is a bare license.
Thus it can be revoked by the grantor at any time.
His act of grace bestowed, and his act of propriety can rescind.
The free software world is held up muchly by a gentleman's agreement.
The agreement is that we shall take mutually beneficial actions, vis a
vis the field of software engineering, to increase the net freedom
available to all.
It is not so much held up by law, regardless of what the lay programmers
and users of programmers would imagine to believe.
To turn one's contributions around as a weapon against the contributor:
to tell him he must not say this or that, he must not act this or that
way,
lest he be barred from his hobby; let he be barred from freely giving
dispensation, is an abhorrent abuse of his magnanimity
Now this gentleman's agreement is being, or has been shattered.
You will find that the law has no supports to bind him;
but many to fell the ungrateful who saw themselves the inviolate
annuitants of his altruism.
Bare licenses are revocable at will. They always have been.
Those who are thrown out of the "Linux Kernel Community" in punishment
for not obeying this CoC, who's past contributions count for nothing in
the face of those who will throughout the ages to control men in all
things; for not "behaving properly" here or there, within their public
or private life; for not bending the knee to the Anglo-American
religion, should absolutely rescind the grant they have dispensed.
They are well within their rights to do so, and hostile action must be
met with the same and worse in response.
On 20/09/18 10:27, [email protected] wrote:
> Contributors can, at any time, rescind the license grant regarding their
> property via written notice to those whom they are rescinding the grant
> from (regarding their property (code)).
I know others have already said it, but:
This is legally nonsense. The only way I can revoke someone's rights to
my code under the GPL is if they violate the terms of the GPL. If I
were to do so otherwise, then _I_ would be in violation for having
distributed derived works of the kernel without a GPL, not to mention
the obvious reliance/estoppel problems.
Moreover, even if I _could_ revoke the license, I wouldn't want to do
so; it would be ridiculously petty in itself and the precedent it would
set would be destructive to the entire open-source community, about
which I care deeply. It is _because_ Linux and other open-source
projects are so important to humanity that I spoke up about what I
perceive as a threat to it.
In short, "unconditionedwitness", please shut up. You're not helping.
On Thu, 2018-09-20 at 03:14 +0100, Edward Cree wrote:
> I think there are important differences between code to be run by
> CPUs
> and a Code to be run by humans. And when the author goes on a
> victory
> lap on Twitter and declares the Code to be "a political document",
> is
> it any surprise I'm worried?
Speaking for myself, I expect there will be occasional
impedance mismatches in communication between people
from different cultures, and people with different
neurotypes.
That is not only expected, it is also perfectly fine.
If people end up feeling like they are in conflict
with each other, and they would like help resolving
it, the first task of the TAB will be to mediate,
and help people figure out how communication could
be improved.
The goal of the code of conduct is to make the community
welcoming, and to help people with being a part of the
Linux community.
Mediation is not about telling people what to do,
but about asking the people involved what they would
like to see, and helping to breach the gap between
their styles of communication.
As an aside, the TAB has no power to remove anyone
from the community. Patches are applied by maintainers,
mailing lists are run by their administrators.
The only things the TAB can do is mediate and advise.
--
All Rights Reversed.
On Friday, September 21, 2018 1:48 AM, Rik van Riel <[email protected]> wrote:
> On Thu, 2018-09-20 at 03:14 +0100, Edward Cree wrote:
>
> > I think there are important differences between code to be run by
> > CPUs
> > and a Code to be run by humans. And when the author goes on a
> > victory
> > lap on Twitter and declares the Code to be "a political document",
> > is
> > it any surprise I'm worried?
>
> Speaking for myself, I expect there will be occasional
> impedance mismatches in communication between people
> from different cultures, and people with different
> neurotypes.
>
> That is not only expected, it is also perfectly fine.
>
> If people end up feeling like they are in conflict
> with each other, and they would like help resolving
> it, the first task of the TAB will be to mediate,
> and help people figure out how communication could
> be improved.
>
> The goal of the code of conduct is to make the community
> welcoming, and to help people with being a part of the
> Linux community.
>
> Mediation is not about telling people what to do,
> but about asking the people involved what they would
> like to see, and helping to breach the gap between
> their styles of communication.
>
> As an aside, the TAB has no power to remove anyone
> from the community. Patches are applied by maintainers,
> mailing lists are run by their administrators.
>
> The only things the TAB can do is mediate and advise.
That couldn't be more wrong. The existence of a TAB itself
is the problem. The community will be pushed to behave
according to what TAB expects to, otherwise the person will
be shamed and could even have their job jeopardized.
The world currently is walking towards a culture where everyone claimed to be oppressed becomes a mini dictator that can force,
shame, offend. I borrow the words of a wise man who's no longer
alive: “All of it began the first time some of you who know
bettet... let young people think that they had the right to
choose the laws they would obey as long as they were doing it in
the name of social protest.”
I'm using a phony e-mail because I don't feel "job-wise" safe to
criticize this culture, as the punishment is to lose job, end
career, end social life, etc.
I ask our fellows linuxers to not allow this culture to take over
our community. If the current code of conflict isn't working, let's
create a new one, politically NEUTRAL, and without any set of people
with power to dictate the behavior of thousands of engineers. Linux
is NOT a hostile place to work. According to this culture, I am a
minority, coming from third world country who found on Linux
community (since kernel 2.4) a very good source of knowledge and
freedom.
Kind regards,
Unixing
Rik van Riel <[email protected]> writes:
> [...] The goal of the code of conduct is to make the community
> welcoming, and to help people with being a part of the Linux
> community. [...]
That may well be the goal. But the proper way to evaluate policy is not
the laudability of its goals but its forseeable and/or actual effects.
Is there any plan to evaluate the CoC empirically somehow to see if it
accomplishes what its proponents hope?
- FChE
Ahem...
Of course, the linux community, like ALL communities, needs more
political correctness, because we wouldn't want others to feel left
out merely because they are wrong. FALSE || TRUE = more
participation and diversity!
>Our Pledge
>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.
As soon as you start to enumerate a list of communities that you're
including, you have set yourself up for failure, because you will,
LOGICALLY, leave out an endless number of groups that could
conceivably want to participate, too: necrophiliacs (NO harm, NO
foul!), small animal lovers, balloon sculpturers, magicians, etc.
These people may feel ostracized when trying to participate, too.
No, all you need to do is say that everyone are invited to
participate, but that this is a kernel development community -- you
are expected to be able to code in C (is that exclusory?), know some
OS theory, done some research, etc. before bothering the participants
of the list, who do not have endless amounts of time.
Our Standards
=============
Examples of behavior that contributes to creating a positive environment
include:
>* Using welcoming and inclusive language
Something like:
Hello, thank you for contributing your code. Of course, we'd love to
add your recipe for fruit cake into our code base.
>* Being respectful of differing viewpoints and experiences
Consider:
I respect that you think we should make linux include gay and
lesbian-friendly (or other minority group) themed fonts and logos,
>* Focusing on what is best for the community
When the community is made infinitely large, we'll be PERFECT!
>* Showing empathy towards other community members
Your pussy hurts? Maybe you should have just accepted that your a boy!
I think Linus is perfectly fine in conduct. I mean, this bullshit
pressure comes from corporations and other wierd places (<subtext>all
seeing eye</subtext>) that want to "help". Do not even be fooled that
this is somehow become the accepted standard that EVERYONE BUT YOU is
accepting. It is utterly political and based on POWER, not community.
Please, most of these people are still sitting on land that belonged
to the Native Americans who have never been given justice at all. It
is an utter joke that these people actually think that they are
"politically correct". They are as delusional as gunnuts who want to
carry assault rifles into Walmart. Do not pander to them. Consider
them TROLLS.
Mark Janssen
People can decide who they want to respond to, but I'm going to gently
suggest that before people think about responding to a particular
e-mail, that they do a quick check using "git log [email protected]"
then decide how much someone appears to be a member of the community
before deciding how and whether their thoughts are relevant.
There are a lot of strong feelings on this issue, and allowing people
who aren't members of the Linux kernel development community, to
escalate the rhetoric --- either in the pro- or anti- CoC direction,
and whether on mailing lists, github comment threads, Twitter, or
Reddit --- is not helpful.
For example....
> >* Showing empathy towards other community members
>
> Your pussy hurts? Maybe you should have just accepted that your a boy!
>
> I think Linus is perfectly fine in conduct. I mean, this bullshit
> pressure comes from corporations and other wierd places (<subtext>all
> seeing eye</subtext>) that want to "help".
There are people commenting from all sides that are wanting to "help".
But I hope that it is obvious that the above text is *not* *helpful*.
Mark, please stop.
- Ted
On Fri, Sep 21, 2018 at 07:15:45PM -0400, Theodore Y. Ts'o wrote:
> People can decide who they want to respond to, but I'm going to gently
> suggest that before people think about responding to a particular
> e-mail, that they do a quick check using "git log [email protected]"
> then decide how much someone appears to be a member of the community
> before deciding how and whether their thoughts are relevant.
>
> There are a lot of strong feelings on this issue, and allowing people
> who aren't members of the Linux kernel development community, to
> escalate the rhetoric --- either in the pro- or anti- CoC direction,
> and whether on mailing lists, github comment threads, Twitter, or
> Reddit --- is not helpful.
I completely agree with this; very eagerly seconded.
--
Cheers,
Joey Pabalinas
On Fri, Sep 21, 2018 at 7:17 PM Theodore Y. Ts'o <[email protected]> wrote:
>
> People can decide who they want to respond to, but I'm going to gently
> suggest that before people think about responding to a particular
> e-mail, that they do a quick check using "git log [email protected]"
> then decide how much someone appears to be a member of the community
> before deciding how and whether their thoughts are relevant.
How does this part apply to email addresses used to commit code?
* Publishing others’ private information, such as a physical or electronic
address, without explicit permission
It appears to me that this would conflict with the GPL since the GPL
granted the right to distribute (or even print it in a book) Linux and
Linux contains email addresses. This also seems contradictory with
the Reply button I used to send this email.
How do you reconcile working on a public project while keeping email
address secret?
>
> There are a lot of strong feelings on this issue, and allowing people
> who aren't members of the Linux kernel development community, to
> escalate the rhetoric --- either in the pro- or anti- CoC direction,
> and whether on mailing lists, github comment threads, Twitter, or
> Reddit --- is not helpful.
>
> For example....
>
> > >* Showing empathy towards other community members
> >
> > Your pussy hurts? Maybe you should have just accepted that your a boy!
> >
> > I think Linus is perfectly fine in conduct. I mean, this bullshit
> > pressure comes from corporations and other wierd places (<subtext>all
> > seeing eye</subtext>) that want to "help".
>
> There are people commenting from all sides that are wanting to "help".
> But I hope that it is obvious that the above text is *not* *helpful*.
> Mark, please stop.
>
> - Ted
--
Jon Smirl
[email protected]
On 22/09/2018 01:31, [email protected] wrote:
[...]
> How does this part apply to email addresses used to commit code?
>
> * Publishing others’ private information, such as a physical or electronic
> address, without explicit permission
I need an (explicit) permission to "publish" an already published email
address which is already world-wide known because it can be found by the
simplest and worst search engine as the email address is in public
mailing list archives and git repos?
Sounds pretty absurd as the people themselves already published their
email address.
IMHO you cannot "publish" already published stuff.
MfG,
Bernd, NAL
--
Bernd Petrovitsch Email : [email protected]
LUGA : http://www.luga.at
On Fri, Sep 21, 2018 at 07:31:05PM -0400, [email protected] wrote:
> On Fri, Sep 21, 2018 at 7:17 PM Theodore Y. Ts'o <[email protected]> wrote:
> >
> > People can decide who they want to respond to, but I'm going to gently
> > suggest that before people think about responding to a particular
> > e-mail, that they do a quick check using "git log [email protected]"
> > then decide how much someone appears to be a member of the community
> > before deciding how and whether their thoughts are relevant.
>
> How does this part apply to email addresses used to commit code?
>
> * Publishing others’ private information, such as a physical or electronic
> address, without explicit permission
>
> It appears to me that this would conflict with the GPL since the GPL
> granted the right to distribute (or even print it in a book) Linux and
> Linux contains email addresses. This also seems contradictory with
> the Reply button I used to send this email.
I don't really think email addresses used in patches which are sent,
voluntarily, to a public mailing list are something you can sanely
consider "private information".
> How do you reconcile working on a public project while keeping email
> address secret?
This is a little more delicate, and I admit that I can't really
think of any real solutions for this part...
--
Cheers,
Joey Pabalinas
On Fri, Sep 21, 2018 at 8:05 PM Joey Pabalinas <[email protected]> wrote:
>
> On Fri, Sep 21, 2018 at 07:31:05PM -0400, [email protected] wrote:
> > On Fri, Sep 21, 2018 at 7:17 PM Theodore Y. Ts'o <[email protected]> wrote:
> > >
> > > People can decide who they want to respond to, but I'm going to gently
> > > suggest that before people think about responding to a particular
> > > e-mail, that they do a quick check using "git log [email protected]"
> > > then decide how much someone appears to be a member of the community
> > > before deciding how and whether their thoughts are relevant.
> >
> > How does this part apply to email addresses used to commit code?
> >
> > * Publishing others’ private information, such as a physical or electronic
> > address, without explicit permission
> >
> > It appears to me that this would conflict with the GPL since the GPL
> > granted the right to distribute (or even print it in a book) Linux and
> > Linux contains email addresses. This also seems contradictory with
> > the Reply button I used to send this email.
>
> I don't really think email addresses used in patches which are sent,
> voluntarily, to a public mailing list are something you can sanely
> consider "private information".
>
> > How do you reconcile working on a public project while keeping email
> > address secret?
>
> This is a little more delicate, and I admit that I can't really
> think of any real solutions for this part...
I would propose adding a statement to clarify that Linux is a public
project and because of this things like names and email addresses of
people working on the project are public information. I don't see how
any other position is viable since it appears to be a GPL conflict.
But... it this bothers you, simply don't use your private, personal
email address when working on the kernel. Anyone with the skills to
work on the kernel should know enough to be able to create email
aliases. No rule says you have to use your real name either.
Aliases have been used in the past, search through the logs and you
will find a few commits from 'anonymous'. However, commits from
anonymous sources have to go through extra layers of review since the
identity of the contributor and their reputation is unknown.
If someone is using an email alias and has their hidden, true address
published then that would be a CoC violation. Although if you mess up
and submit a patch using your hidden identity, you just published it
and it is no longer hidden.
>
> --
> Cheers,
> Joey Pabalinas
--
Jon Smirl
[email protected]
Dear Edward,
> I know others have already said it, but:
> This is legally nonsense. The only way I can revoke someone's rights to
> my code under the GPL is if they violate the terms of the GPL.
this aspect of FOSS licenses has -- to the best of my knowledge --
never been tested in court. Actually, the Free Software Foundation felt
compelled to clarify this point in GPLv3 and there is a thread on
StackOverflow acknowledging the possibility of revoking a license [1].
Finally, revoking the license may very well be possible in some
jurisdictions but not all of them, e.g., Australia [2]. There are 195
independent states in this world and I do not think you can make such a
broad claim if it has never been legally contested before.
By the way your e-mail is violating the code of coduct.
> This is legally nonsense.
You are not empathic towards others and respectful of differing
viewpoints.
> In short, "unconditionedwitness", please shut up. You're not helping.
The comment is derogatory if not downright offensive.
[1]
https://law.stackexchange.com/questions/832/is-a-copyright-license-by-default-revocable-or-irrevocable
[2]
https://web.archive.org/web/20091024034824/http://www.ilaw.com.au/public/licencearticle.html
Sincerely
Christoph Conrads
On Thu, 20 Sep 2018 23:57:15 +0100
Edward Cree <[email protected]> wrote:
> On 20/09/18 10:27, [email protected] wrote:
> > Contributors can, at any time, rescind the license grant regarding their
> > property via written notice to those whom they are rescinding the grant
> > from (regarding their property (code)).
>
> I know others have already said it, but:
> This is legally nonsense. The only way I can revoke someone's rights to
> my code under the GPL is if they violate the terms of the GPL. If I
> were to do so otherwise, then _I_ would be in violation for having
> distributed derived works of the kernel without a GPL, not to mention
> the obvious reliance/estoppel problems.
>
> Moreover, even if I _could_ revoke the license, I wouldn't want to do
> so; it would be ridiculously petty in itself and the precedent it would
> set would be destructive to the entire open-source community, about
> which I care deeply. It is _because_ Linux and other open-source
> projects are so important to humanity that I spoke up about what I
> perceive as a threat to it.
>
> In short, "unconditionedwitness", please shut up. You're not helping.
>> Contributors can, at any time, rescind the license grant regarding their
>> property via written notice to those whom they are rescinding the grant
>> from (regarding their property (code)).
>
> I know others have already said it, but:
> This is legally nonsense. The only way I can revoke someone's rights to
> my code under the GPL is if they violate the terms of the GPL. If I
> were to do so otherwise, then _I_ would be in violation for having
> distributed derived works of the kernel without a GPL, not to mention
> the obvious reliance/estoppel problems.
Actually, like Chris Conrad said, this isn't necessarily the case --
even though you are *contractually* right.
The problem is -- that no one *signed* that contract. These are
gentle/wo/men's agreements. They are essentially the same as a
click-wrap agreement in terms of enforceability.
That being said, there is still legal recourse, just as there was/is
with click-wrap agreements. It's just not clear how much.
Mark Janssen, JD
> For example....
>
>> >* Showing empathy towards other community members
>>
>> Your pussy hurts? Maybe you should have just accepted that your a boy!
>>
>> I think Linus is perfectly fine in conduct. I mean, this bullshit
>> pressure comes from corporations and other wierd places (<subtext>all
>> seeing eye</subtext>) that want to "help".
>
> There are people commenting from all sides that are wanting to "help".
> But I hope that it is obvious that the above text is *not* *helpful*.
> Mark, please stop.
General Tso,
The problem with your criticism is that it assumes that all input is
legitimate while you advocate eliminating (or downgrading) some of it.
Make up your mind: do you want all-inclusiveness or selective-inclusiveness?
Mark
better to bury a corpse than to let it rot in the air.****
> This is legally nonsense. The only way I can revoke someone's rights
> to
It is not nonsense. Gratuitous licenses are and always have been
revocable at the will of the grantor.
(Yes, I am a lawyer)
Property law 101.
"But this is COPYRIGHT"
From the US statute: copyright is alienable in the same way property is.
That's where you acquire they ability to license your work in the USA;
congress' copyright act.
Prior to the Statute of Anne there was no copyright what-so-ever. It's a
statutory right.
The statute grants the right to alienate said right(s), and, the
drafters not feeling the need to re-invent the wheel, simply declared
that the operation there-of would be by the established law of property.
> In short, "unconditionedwitness", please shut up. You're not helping.
I am informing those who are being threatened with expulsion about their
rights and what steps they can take against their enemies.
Matthew Garret claims your "consent" is immaterial (on the lwn thread).
He is wrong. The contributors must be kept happy.
You (providing you are the copyright holder to your own code) can revoke
at any time.
There is nothing between you, and putting your detractors to task...
except for your force of will and some paperwork.
****
> Moreover, even if I _could_ revoke the license, I wouldn't want to do
> so; it would be ridiculously petty in itself and the precedent it
> would
> set would be destructive to the entire open-source community, about
> which I care deeply. It is _because_ Linux and other open-source
> projects are so important to humanity that I spoke up about what I
> perceive as a threat to it.
You and others are being threatened with sanction by people such as
Matthew Garret if you do not obey their diktats.
They say essentially: if you want to contribute to opensource (haha 30k
projects have CoCs now!) you will be BARRED from doing so if you do not
obey our religion (anglo-americanism).
If you're not a feminist: you're sanctioned (punished)
If you're not opposed to men marrying female children (a practice
permitted by YHWH in Devarim chapter 22, vers 28 (na'ar), aswell as by
Sunni Islam), you are punished.
If you are not polite to women you are punished.
If you speak out of turn you are punished.
Yet they continue to use your code while spitting on you and besmerching
your name.
While making sure you are forgotten if you step out of line.
(You do the work. They take your work. They try to harm you and reduce
your civil rights. Sound like anything familiar... (c.p.t.l.i.s.m))
You must respect women who do NOTHING for you and even NOTHING for
anyone else except exist as a USELESS physical entity (females who are
not sweet young brides for men or mothers and just consume are not
useful for anyone other than themselves: the purpose of females is to
create more human beings and to bring happiness and pleasures to men:
they are superfluous in any other capacity, as a class)...
who rules over you ...
or else you are punished.
You slaved away writing the code.
When they feel they don't need you anymore they seek to tear you down.
You have a remedy: Recind the grant.
You did NOT sign away your OWNERSHIP of the code you wrote.
The anglo-american belief system is that males are to be slaves of women
and their masters.
This belief system is now being imposed on even hobbies like gratis
software development.
They wish to give men no refuge, no place to build something outside the
eye of the middle-class ("white" or english) woman.
To keep men checked and obedient at all time in all things.
But there is a way to strike back, to strike at the heart.
There is a dagger at the neck of that which you built but is now being
repurposed to bind you.
All you have to do is push.
Such is all any rights-holder has to do.
Gratuitous licenses are revocable at will.
On 2018-09-20 22:57, Edward Cree wrote:
> On 20/09/18 10:27, [email protected] wrote:
The goal is obviously to shatter the gentleman's agreement that upholds
the opensource community and end opensource as a force within the US and
commonwealth countries.
And it will likely succeed.
No gratis contributor wants to be told what he can say or what he can do
"or else we won't let you give us this gift!".
FreeBSD has lost 1/2 its contributors after their woman-worshiping
service known as the investiture of the CoC.
This will continue until all of OSS is a rotting corpse.
And then maybe some of the disaffected will revoke their license grants
and bury the effluence.
On 2018-09-21 13:07, [email protected] wrote:
> Rik van Riel <[email protected]> writes:
>
>> [...] The goal of the code of conduct is to make the community
>> welcoming, and to help people with being a part of the Linux
>> community. [...]
>
> That may well be the goal. But the proper way to evaluate policy is
> not
> the laudability of its goals but its forseeable and/or actual effects.
> Is there any plan to evaluate the CoC empirically somehow to see if it
> accomplishes what its proponents hope?
>
> - FChE
On Fri, Sep 21, 2018 at 5:24 PM, [email protected] <[email protected]> wrote:
> On Fri, Sep 21, 2018 at 8:05 PM Joey Pabalinas <[email protected]> wrote:
>> On Fri, Sep 21, 2018 at 07:31:05PM -0400, [email protected] wrote:
>>> How do you reconcile working on a public project while keeping email
>>> address secret?
>>
>> This is a little more delicate, and I admit that I can't really
>> think of any real solutions for this part...
>
> But... it this bothers you, simply don't use your private, personal
> email address when working on the kernel. Anyone with the skills to
> work on the kernel should know enough to be able to create email
> aliases. No rule says you have to use your real name either.
There is such rule:
https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html
chapter "Developer’s Certificate of Origin 1.1" says
then you just add a line saying:
Signed-off-by: Random J Developer <[email protected]>
using your real name (sorry, no pseudonyms or anonymous contributions.)
And in general, Developer’s Certificate of Origin
https://developercertificate.org/
says
By making a contribution to this project, I certify that:
...
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
--
Thanks.
-- Max
On Mon, Sep 24, 2018 at 1:43 PM Max Filippov <[email protected]> wrote:
>
> On Fri, Sep 21, 2018 at 5:24 PM, [email protected] <[email protected]> wrote:
> > On Fri, Sep 21, 2018 at 8:05 PM Joey Pabalinas <[email protected]> wrote:
> >> On Fri, Sep 21, 2018 at 07:31:05PM -0400, [email protected] wrote:
> >>> How do you reconcile working on a public project while keeping email
> >>> address secret?
> >>
> >> This is a little more delicate, and I admit that I can't really
> >> think of any real solutions for this part...
> >
> > But... it this bothers you, simply don't use your private, personal
> > email address when working on the kernel. Anyone with the skills to
> > work on the kernel should know enough to be able to create email
> > aliases. No rule says you have to use your real name either.
>
> There is such rule:
> https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html
>
> chapter "Developer’s Certificate of Origin 1.1" says
So the "Developer’s Certificate of Origin 1.1" appears to require
permission be given to use the names and email addresses. Those
anonymous commits in the logs pre-date the Certificate of Origin.
This line in the CoC still looks likely to be a source of future
conflict. Say an LWN article reprints a thread on LKML and attributes
the quotes. Could the author (a kernel contributor) of the LWN
article be attacked via the CoC for attributing the quotes? How can
journalism function if public statements can't be quoted without
permission? Not everyone participating on LKML has submitted a patch
under the Certificate of Origin (thus giving permission for use of
name/email).
It seems inconsistent to me that the name/address you use to publish
messages to a public email list can be considered private information.
From CoC...
* Publishing others’ private information, such as a physical or
electronic address, without explicit permission
>
> then you just add a line saying:
> Signed-off-by: Random J Developer <[email protected]>
> using your real name (sorry, no pseudonyms or anonymous contributions.)
>
> And in general, Developer’s Certificate of Origin
> https://developercertificate.org/
>
> says
>
> By making a contribution to this project, I certify that:
> ...
> (d) I understand and agree that this project and the contribution
> are public and that a record of the contribution (including all
> personal information I submit with it, including my sign-off) is
> maintained indefinitely and may be redistributed consistent with
> this project or the open source license(s) involved.
>
> --
> Thanks.
> -- Max
--
Jon Smirl
[email protected]
>> * Publishing others’ private information, such as a physical or
>> electronic
>> address, without explicit permission
>
> I need an (explicit) permission to "publish" an already published email
> address which is already world-wide known because it can be found by the
> simplest and worst search engine as the email address is in public
> mailing list archives and git repos?
>
> Sounds pretty absurd as the people themselves already published their
> email address.
>
> IMHO you cannot "publish" already published stuff.
The notion of being "published" means at least these two things: 1)
you INTEND it to be PUBLIC, 2) you made it available to the PUBLIC.
A semi-private email list is a boundary area of being public. Just
like a memo distributed within a university department. Participants
in the latter have some reasonable expectation that the material is
not being published in the larger public sphere beyond actions of the
trusted participants involved (which might share it in a limited
fashion as a personal note).
So, is code a *published* item? Most of the public can't read it.
It is often not intended for the public, per se, only a specialized
COMMUNITY. Because once published, it belongs to copyright and fair
use (THAT sticky little wicket).
Mark
On 24/09/2018 20:59, \0xDynamite wrote:
>>> * Publishing others’ private information, such as a physical or
>>> electronic
>>> address, without explicit permission
>>
>> I need an (explicit) permission to "publish" an already published email
>> address which is already world-wide known because it can be found by the
>> simplest and worst search engine as the email address is in public
>> mailing list archives and git repos?
>>
>> Sounds pretty absurd as the people themselves already published their
>> email address.
>>
>> IMHO you cannot "publish" already published stuff.
>
> The notion of being "published" means at least these two things: 1)
Where exactly - URL? - is that notion defined?
Especially the intention is IMHO not necessary - just the fact if it
happened (and I don't think we want to discuss legal stuff about "X
broke into my home, stole and published my work" - the patent world has
the same problem).
> you INTEND it to be PUBLIC, 2) you made it available to the PUBLIC
> A semi-private email list is a boundary area of being public. Just
Define "semi-private" - URL?:
Any company/club/family/...-internal ML is - should be;-) - obviously
private as the subscription policy is usually pretty selective (read:
not public, not debatable, ...) and the archives - if any - are not
public by design. So everyone there should know that.
Of course, anyone getting all mails can put an $SEARCH_MACHINE indexed
archive publicly online but that's another (law) question.
On the otherhand, if the mailinglist is public, the (future) subscribers
should know the beforehand.
> like a memo distributed within a university department. Participants
> in the latter have some reasonable expectation that the material is
> not being published in the larger public sphere beyond actions of the
> trusted participants involved (which might share it in a limited
> fashion as a personal note).
ACK but what has that to do with LKML etc?
You try to change - manipulate - the issues of the discussion. Are you
only a troll?
> So, is code a *published* item? Most of the public can't read it.
I cannot read (or understand) neither Russian nor Chinese nor almost any
natural (let alone dead) languages of the world. I'm pretty sure that
I'm not the only one;-)
Does that make Russian literature non-public? I don't think so ...
You really don't want to go down that road - neither with law people and
even less with techies.
So how can be (source) code (at least in any publicly known/defined
language) posted on a "everyone can subscribe" mailinglist, archived in
several $SEARCH_ENGINE indexed mailinglist archives and replicated in a
myriad of public accessible git-repos with the only intention of
inclusion in the Kernel not be *obviously* and *clearly* public?
> It is often not intended for the public, per se, only a specialized
Maybe but doesn't change any fact of publication - you may also want to
check with patent folks and "unintended or unwanted publication" (yes,
some talk in a "maybe publicly accessible space" might count there as
"publication") - they have more or less the same situation.
> COMMUNITY. Because once published, it belongs to copyright and fair> use (THAT sticky little wicket).
In the law area, the Copyright (TTBOMK) and the much more advanced
Central European Authors rights start to exist with existence of the
"work" (and not a µs later) independent of any status or situation of
publication.
Where does the "fair use" come from?
Reads: where is that defined?
If you want me to define "fair use of source code publicized in the LKML
and similar under the GPLv2": You also cease the right to efeectively
revoke it (though that is in some jurisdictions not possible but that
"revoke-right" was made for completely different situations - long
before GPL or CC was even thinkable).
"effectively revoke it" is meant that you cannot say "I wrote parts of
it/I'm the initial contributor/I have a significant patch accepted and
I'm fed up with the kernel so remove all my contributions".
BTW you cannot do that at your workplace either because in all sane
software development companies you cease all (transferable) rights of
your written to the company paying you (and the rest is usually not
enough to get anything revoked).
I don't see why that should be any different with GPLv2 patches for the
Kernel sent to public mailinglists with the intent of inclusion.
Please get back to the issue and circumstances at hand and do not try to
divert people with "not intended for the public" or "semi-public" or any
other off-topic stuff which is clearly not the case here.
Or - even better - shut up, unsubscribe and go away, thank you.
MfG,
Bernd, NAL but I talked to a lot of them;-)
PS: Sorry for troll feeding:-(
--
Bernd Petrovitsch Email : [email protected]
LUGA : http://www.luga.at
In your employment contract there exists a provision where you sign over
your rights to any and all intellectual property, patents, copyrights
developed during your term of employment.
Said clause makes it clear that what you've furnished is a work-for-hire
and owned by the company or the entity you have contracted with.
It should be clear why that is not the case with regards to kernel
contributions by third parties.
Unlike the FSF etc, Linus never required nor sought copyright
assignments: thus you still own your code.
You were not paid valuable consideration by the licensees for the code.
There exists no interest to bind your hand.
You never even suggested to said licensees that you would forfeit your
right to revoke.
Furthermore, they were incapable of relying on said in-existent
utterances.
You may revoke at your pleasure.
And they shall be bound by the will of your countenance.
On 2018-09-24 19:45, Bernd Petrovitsch wrote:
> BTW you cannot do that at your workplace either because in all sane
> software development companies you cease all (transferable) rights of
> your written to the company paying you (and the rest is usually not
> enough to get anything revoked).
>
> I don't see why that should be any different with GPLv2 patches for the
> Kernel sent to public mailinglists with the intent of inclusion.
>
> Please get back to the issue and circumstances at hand and do not try
> to
> divert people with "not intended for the public" or "semi-public" or
> any
> other off-topic stuff which is clearly not the case here.
> Or - even better - shut up, unsubscribe and go away, thank you.
>
> MfG,
> Bernd, NAL but I talked to a lot of them;-)
>
> PS: Sorry for troll feeding:-(
Hi!
> > I can
> > see how that kind of environment _could_ be implemented with the same
> > code of conduct as a base, but [...] I know I
> > would fight strongly against that.
> It is definitely reassuring to hear you say that.
>
> > There is a list in the first paragraph, but the preceding words say
> > that it should be a *harassment-free experience for everyone*. That
> > part of the paragraph is to me the most important part.
> It certainly _should_ be the most important; IMHO the sentence should end
> ?after 'everyone'.
>
> > Your above argument that the Code of Conduct is problematic because of
> > who wrote it seems to contradict your statement that we shall judge by
> > code (or text) alone.
> I think there are important differences between code to be run by CPUs
> ?and a Code to be run by humans.? And when the author goes on a victory
> ?lap on Twitter and declares the Code to be "a political document", is
> ?it any surprise I'm worried?
Would you have link on that? I'd really want to know who authored the
document, because it is making statements that are untrue.
Thanks,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Dear Pavel,
> > > Your above argument that the Code of Conduct is problematic because of
> > > who wrote it seems to contradict your statement that we shall judge by
> > > code (or text) alone.
> > I think there are important differences between code to be run by CPUs
> > and a Code to be run by humans. And when the author goes on a victory
> > lap on Twitter and declares the Code to be "a political document", is
> > it any surprise I'm worried?
>
> Would you have link on that?
The CoC is a political document:
https://web.archive.org/web/20180924234027/https://twitter.com/coralineada/status/1041465346656530432
Possible victory lap 1:
https://web.archive.org/web/20180921104730/https://twitter.com/coralineada/status/1041441155874009093
Possible victory lap 2:
https://web.archive.org/web/20180920211406/https://twitter.com/coralineada/status/1042249983590838272
Note the statement in the second victory lap is wrong, it is 40,000 developers and not 40,000 projects as you can see in this commit:
https://github.com/ContributorCovenant/contributor_covenant/commit/c5ac3dfc0274b8e58e04f112aae38caaa1f2e338
> I'd really want to know who authored the
> document, because it is making statements that are untrue.
Here is the author's post-meritocracy manifesto:
https://postmeritocracy.org/
Here is the author's patreon:
https://www.patreon.com/coraline
Sincerely
Christoph Conrads
PS: Get back to work!
https://web.archive.org/web/20180925122931/https://twitter.com/CoralineAda/status/1043338366002114561
Christoph Conrads <[email protected]>:
> The CoC is a political document:
> https://web.archive.org/web/20180924234027/https://twitter.com/coralineada/status/1041465346656530432
And there is no level on which this is anything but bad.
The kernel devs are a very large, very diverse, multi-national, multi-cultural
group. We have nothing to gain by getting entangled with political culture
wars, and everything to lose.
--
<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.
Hi!
> > > > Your above argument that the Code of Conduct is problematic because of
> > > > who wrote it seems to contradict your statement that we shall judge by
> > > > code (or text) alone.
> > > I think there are important differences between code to be run by CPUs
> > > ?and a Code to be run by humans.? And when the author goes on a victory
> > > ?lap on Twitter and declares the Code to be "a political document", is
> > > ?it any surprise I'm worried?
> >
> > Would you have link on that?
>
> The CoC is a political document:
> https://web.archive.org/web/20180924234027/https://twitter.com/coralineada/status/1041465346656530432
>
> Possible victory lap 1:
> https://web.archive.org/web/20180921104730/https://twitter.com/coralineada/status/1041441155874009093
>
> Possible victory lap 2:
> https://web.archive.org/web/20180920211406/https://twitter.com/coralineada/status/1042249983590838272
>
Thanks!
I thought you was referring to this... http://archive.is/6nhps
... which is somehow even more disturbing to me.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Dear Eric,
> > The CoC is a political document:
> > https://web.archive.org/web/20180924234027/https://twitter.com/coralineada/status/1041465346656530432
>
> And there is no level on which this is anything but bad.
>
> The kernel devs are a very large, very diverse, multi-national, multi-cultural
> group. We have nothing to gain by getting entangled with political culture
> wars, and everything to lose.
In this context, I want to mention the tweet by the CoC author from
August 29, 2018 [1]:
> All software is political.
This tweet was posted as a response to your article "Non-discrimination
is a core value of open source" stating that politics should be kept
separate from work (in an open source community):
> The Lerna project’s choice is, moreover, destructive of one of the deep
> norms that keeps the open-source community functional – keeping
> politics separated from our work. If we do not maintain that norm, we
> risk fractionating into a collection of squabbling tribes arguing
> particularisms and unable to sustain really large-scale cooperation.
[1]
https://web.archive.org/web/20180925132931/https:/twitter.com/CoralineAda/status/1035009876152467456
[2] http://esr.ibiblio.org/?p=8106
Sincerely
Christoph Conrads
On Tue, Sep 25, 2018 at 02:36:45PM +0200, Christoph Conrads wrote:
> The CoC is a political document:
> https://web.archive.org/web/20180924234027/https://twitter.com/coralineada/status/1041465346656530432
...
> Here is the author's post-meritocracy manifesto:
> https://postmeritocracy.org/
There have been those who have characterized the GPL as being more
than just a license, but also a political statement. And yet, many
projects, include Linus, use the GPL without necessarily subscribing
to all of Richard Stallman's positions, political or otherwise.
As an example: while some Linux users and developers believe with
Stallman that the name Linux should not be used, but LiGNUx and
GNU/Linux instead, others think Linux/BSD/GNU/X/Perl/Python would be
more accurate, and still others thought Stallman's naming proposal was
just plain silly. Most distributions, including Red Hat, SuSE, Arch,
Gentoo, and Ubuntu don't use GNU/Linux, with Debian being an
exception.
The Linux community is perfectly capable of forming its own political
beliefs, interpretations, and usage of the GPLv2 (including
EXPORT_SYMBOL_GPL), without Richard Stallman dictating his positions
and beliefs to us. We don't use the GPLv3 for the Kernel, despite
Stallman's clearly stated preference that we do so.
The use of GPLv2 does not magically brainwash all of users of that
document to blindly follow its author. The same is true of the CoC.
- Ted
>> The notion of being "published" means at least these two things: 1)
>
> Where exactly - URL? - is that notion defined?
I'm giving you the most sensible definition, from the point of view of
a Doctor of Law. I have not seen a real definition, so I'm giving you
one.
> Especially the intention is IMHO not necessary - just the fact if it
> happened (and I don't think we want to discuss legal stuff about "X
> broke into my home, stole and published my work" - the patent world has
> the same problem).
No, you must have the intention. If you have a copy of your new book
on your computer, but someone steals it and prints it -- it is not a
"published" work.
And there is no URL. You can take my word for it, along with my
credentials, or you can ignore it.
>> So, is code a *published* item? Most of the public can't read it.
>
> I cannot read (or understand) neither Russian nor Chinese nor almost any
> natural (let alone dead) languages of the world. I'm pretty sure that
> I'm not the only one;-)
> Does that make Russian literature non-public? I don't think so ...
You confuse the issue. My definition included "intended for the
public". But it isn't clear that open source code is intended for the
public -- it is intended for those who code or wish to.
Past your inflammatory remarks, I withdraw any further commentary.
Mark Janssen, JD
>> And there is no level on which this is anything but bad.
>
> In this context, I want to mention the tweet by the CoC author from
> August 29, 2018 [1]:
>
>> All software is political.
>
> This tweet was posted as a response to your article "Non-discrimination
> is a core value of open source" stating that politics should be kept
> separate from work (in an open source community):
Is this at all consequential to Lessig's (Harvard Law professor) book
"Code is Law"?
There are two separate issues: 1) the political revancy of F/OSS and
2) the politics of CoCs.
It's like the Matrix:
Through one door, the community can either choose to stay political
neutered and let RMS (and company) handle all of the politics OR it
can see itself as revolutionary (because of its insistence on freedom)
and stay political, and see just how the rabbit hole goes.
Which should it be?
Mark
Theodore Y. Ts'o <[email protected]>:
> There have been those who have characterized the GPL as being more
> than just a license, but also a political statement. And yet, many
> projects, include Linus, use the GPL without necessarily subscribing
> to all of Richard Stallman's positions, political or otherwise.
The case isn't parallel. Every kernel dev knew they were joining a
commons defined by GPL terms when they signed on. Regulation of
soi-disant "hateful" speech and "diversity" objectives, on the other
hand, are a *new* set of claims and norms not entailed in established
practice.
There ought to be much broader consensus before anything like that is done -
and I would say that even about new political claims I myself supported.
Instead, what we have is open revolt from a dissident faction that thinks
the project would be better destroyed than under the CoC.
That should be a clue that imposing the CoC without a lot of public
discussion and preparation was a mistake, and it should be revereted until
at least rough consensus in fovor of some improvement on the old
Code is achieved.
--
<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 22/09/18 00:15, Theodore Y. Ts'o wrote:
> People can decide who they want to respond to, but I'm going to gently
> suggest that before people think about responding to a particular
> e-mail, that they do a quick check using "git log
[email protected]"
> then decide how much someone appears to be a member of the community
> before deciding how and whether their thoughts are relevant.
> There are a lot of strong feelings on this issue, and allowing people
> who aren't members of the Linux kernel development community, to
> escalate the rhetoric --- either in the pro- or anti- CoC direction,
> and whether on mailing lists, github comment threads, Twitter, or
> Reddit --- is not helpful.
Your contributions to the Linux Kernel, your years of dedication, are
all irrelevant, simply because they have not prepared you and the other
contributors for an SJW attack.
The majority of us software developers are going to be below average at
social interaction, this is not meant to be disheartening, it is
reality, one that puts us at a significant disadvantage when up against
SJW's.
They will apply social pressure to subvert your organisation and unless
you are willing to learn what an appropriate response is, you will be
defeated over time. Defeat means the current truly inclusive meritocracy
will be handed over to political activists with no intention to
contribute or maintain the kernel, they will milk it for all it is worth
and then move on.
Luckily, one of the trade off's against lower social skills is above
average intelligence. You all have the ability to learn the patterns of
attack and appropriate response. Even if you do not believe this is an
attack, but instead trust the CoC should be taken at face value, it
should behove you to at least read up on recent events, the history of
CoC's, their intended purpose and the fruits of their application.
The information is out there [1][2][3][4], I implore you to study it
before throwing away one of the greatest achievements of our time.
Ted, as a now notorious "rape apologist" [5], you already have first
hand experience of their social attacks, reality, truth & perspective
are all irrelevant in the land of SJW's. Backing down or giving them
what they want will be seen as a weakness to be exploited further. Stop
pandering to them because it is more uncomfortable to stand your ground,
learn how to attack back or you will have no position from which to pander.
Regards,
Michael
[1] https://twitter.com/Grummz/status/1041818086024798208?s=19
[2]
https://www.amazon.com/product-reviews/9527065194/ref=cm_cr_dp_d_cmps_btm?ie=UTF8&reviewerType=all_reviews
[3] https://voxday.blogspot.com/search?q=code+of+conduct
[4] http://paul-m-jones.com/archives/6926
[5] http://archive.is/6nhps
On 25/09/2018 19:14, \0xDynamite wrote:
[...]
>>> So, is code a *published* item? Most of the public can't read it.
>>
>> I cannot read (or understand) neither Russian nor Chinese nor almost any
>> natural (let alone dead) languages of the world. I'm pretty sure that
>> I'm not the only one;-)
>> Does that make Russian literature non-public? I don't think so ...
>
> You confuse the issue. My definition included "intended for the
> public". But it isn't clear that open source code is intended for the
Well, then I have to repeat myself: Signed-off source code (in form of
patches) in a well-known programming language for a (nowadays)
well-known GPLv2 licensed project mailed on "everyone can subscribe"
mailinglists, (thus) to be found in several $SEARCH_ENGINE-indexed
mailinglist archives, if accepted to be found in lots of publicly
accessible git repos can be not intended to be published?
I wonder what else must happen.
> public -- it is intended for those who code or wish to.
MfG,
Bernd
--
Bernd Petrovitsch Email : [email protected]
LUGA : http://www.luga.at
Pavel Machek - 25.09.18, 15:28:
> > > > > Your above argument that the Code of Conduct is problematic
> > > > > because of who wrote it seems to contradict your statement
> > > > > that we shall judge by code (or text) alone.
> > > >
> > > > I think there are important differences between code to be run
> > > > by CPUs and a Code to be run by humans. And when the author
> > > > goes on a victory lap on Twitter and declares the Code to be "a
> > > > political document", is it any surprise I'm worried?
> > >
> > > Would you have link on that?
> >
> > The CoC is a political document:
> > https://web.archive.org/web/20180924234027/https://twitter.com/coral
> > ineada/status/1041465346656530432
> >
> > Possible victory lap 1:
> > https://web.archive.org/web/20180921104730/https://twitter.com/coral
> > ineada/status/1041441155874009093
> >
> > Possible victory lap 2:
> > https://web.archive.org/web/20180920211406/https://twitter.com/coral
> > ineada/status/1042249983590838272
> Thanks!
>
> I thought you was referring to this... http://archive.is/6nhps
> ... which is somehow even more disturbing to me.
That would be one of the main issues I see with that change: It did not
went through the usual review process.
I did not know the Contributor Covenant was driven by people with such a
strong agenda.
I still think that this newly adopted code of conduct document won´t
kill Linux. As I have strong trust the community would redact or change
that document if need be. I did not agree with the urgency behind the
initial discussion especially as it was mostly initiated by who I´d
consider by-standers, but I see benefit on carefully reviewing a code of
conduct and I see that the hastily adopted Contributor Covenant may not
be a good or the best choice.
I still adhere to "take the teaching, not the teacher". I do not care
what kind of person the author of CoC is. So I´d review whether the
actual document contents are appropriate for the kernel community.
I suggest reviewing the Code of Conducts of KDE¹ and Debian². Both
projects seem to run pretty well with a Code of Conduct in place.
While what happens regarding a document is always the choice of people,
I think one of the most important aspects would be to make sure that the
means of enforcement the code of conduct provides aligns with the
highest good of the kernel community. Too strongly worded it opens up
opportunities to abuse the code of conduct. Too weakly worded, it can
render the code of conduct ineffective.
I think some of the enforcement wording in Contributor Covenant is not
helpful. I don´t think that
"Project 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."
adds something useful to the code of conduct.
One major question for me is: Is the code of conduct based on fear of
being hurt or harassed or does it aim at a friendly and supportive
community? I do not think that a fear based code of conduct is useful.
There is already quite some harmful stuff going on in the world for the
apparent sake of security (but in the real interest of exercising power
over people).
I think that is why I prefer wording of both Code of Conduct of KDE¹ and
Debian² over the Contributor Covenant. I´d probably take more from those
and less from Contributor Covenant.
Anyway, I see myself only as a by-stander… so of course those who are in
charge are of course free to take anything from this mail they think is
useful and discard the rest.
[1] https://www.kde.org/code-of-conduct/
Unlike noted here in the thread before, it does have a provision for
leaders to enforce it:
"Leaders of any group, such as moderators of mailing lists, IRC
channels, forums, etc., will exercise the right to suspend access to any
person who persistently breaks our shared Code of Conduct."
But is has an important distinction in there: It is a *right*, not an
*obligation*.
[2] https://www.debian.org/code_of_conduct
It also has a provision to enforce it:
"Serious or persistent offenders will be temporarily or permanently
banned from communicating through Debian's systems. Complaints should be
made (in private) to the administrators of the Debian communication
forum in question. To find contact information for these administrators,
please see the page on Debian's organizational structure."
Here is it written indirectly as an obligation.
Thanks,
--
Martin
Hi,
> > The CoC is a political document:
> > https://web.archive.org/web/20180924234027/https://twitter.com/coralineada/status/1041465346656530432
> ...
> > Here is the author's post-meritocracy manifesto:
> > https://postmeritocracy.org/
>
> There have been those who have characterized the GPL as being more
> than just a license, but also a political statement. And yet, many
> projects, include Linus, use the GPL without necessarily subscribing
> to all of Richard Stallman's positions, political or otherwise.
for clarification: My statement above that the CoC is a political
document is not my opinion but a succinct summary of the content of the
tweet linked below it. Here is the full tweet:
> Some people are saying that the Contributor Covenant is a political
> document, and they’re right.
Subsuming both the GNU GPL including the views of the Free Software
Foundation (FSF) and the Contributor Covenant CoC is grossly negligent:
The GPL is a set of rights and obligations with respect to software but
it is indifferent to the behavior of the developers whereas the CoC is a
set of rights and obligations for developers but it is indifferent to
the goods developed by them.
The GNU General Public Licenses are agreements on rights and obligations
when executing or depending on certain software. The only way to be
influenced by the GPL is by using GPL code or by licensing one's own
code under the GPL. If you strongly disagree with the contents of the
GPL, you can avoid it by developing your own software and by not using
GPL software.
Most importantly, the FSF and the people supporting and promoting the
GPL do so in part by creating high-quality software themselves, see the
list in reference [1]. Some of the most important packages on a
_GNU/Linux_ system were developed by or given to the FSF. I looked at
the list mentioned above and stopped counting after I had found 19
pieces of software that I am actively using on a regular basis
including Bash, binutils, gcc, libc, and gtk+. Did you write your
e-mail with GPL-licensed Mutt, Ted?
With the Contributor Covenant CoC, you have all of this turned upside
down:
* It is irrelevant what is created by a group of people.
* It applies to everyone almost always; if you never contributed to
Linux kernel development, you can still denounce active contributors
to the TAB for behavior that *might* be considered inappropriate.
* There is no project whose quality, productivity, or success grew after
introduction of this CoC.
Reading the CoC, it is plain obvious that the good created by a
community is of no relevance to the CoC.
At the same time, the period of validity of the CoC is almost unlimited:
It applies whenever a person interacts with other developers, and
whenever she represents the project, and whenever her conduct might be
deemed inappropriate.
The CoC is also almost unlimited in its scope of application: It applies
when insults are uttered, when language is not welcoming enough, and
when statements might be deemed inappropriate.
To enforce the CoC, an organization has to introduce its own
prosecution: There is an investigative board, the TAB, which is obliged
to handle reports of CoC violations confidentially and the findings are
presented to the maintainers which punish community members based on
these findings.
The CoC has never improved any piece of software and it drives away
core contributors:
* The fifth most active LLVM contributor Rafael Avila de Espindola left
over a CoC that is more tame the Contributor Covenant CoC [2].
* Node.js developer Rodd Vagg was almost removed from Node.js based on
undisclosed allegations [3]. Node.js Technical Steering Committee
members were not at liberty to discuss the allegations with the
accused [4]. Later, a third of the TSC members quit simultaneously
[5].
* Long-time Drupal developer Larry Garfield was removed as developer
because of his personal preference for BDSM [6]. His views were "in
opposition to the values of the Drupal project" [7]. The Drupal CoC is
in spirit similar to the Contributor Covenant CoC [8].
> The use of GPLv2 does not magically brainwash all of users of that
> document to blindly follow its author. The same is true of the CoC.
The Ruby developers refused to introduce the Contributor Covenant CoC
[9] and this led to a thinly veiled Twitter attack of the CoC author on
Ruby chief designer matz [10]. You will not be brainwashed by the CoC
but a Twitter goon squad will be waiting for you.
In summary, your comparison of Richard Stallman's lobbying to the tweets
of the CoC author are inappropriate. Your comparison of the GNU General
Public License with the Contributor Covenant CoC is an insult to the
FSF.
Sincerely
Christoph Conrads
[1] https://www.gnu.org/manual/blurbs.html
[2] https://lists.llvm.org/pipermail/llvm-dev/2018-May/122922.html
[3] https://github.com/nodejs/TSC/issues/310
[4] https://github.com/nodejs/CTC/issues/165#issuecomment-324798494
[5]
https://www.zdnet.com/article/after-governance-breakdown-node-js-leaders-fight-for-its-survival/
[6] https://www.garfieldtech.com/blog/tmi-outing [7]
https://dri.es/living-our-values [8] https://www.drupal.org/dcoc
[9] https://bugs.ruby-lang.org/issues/12004
[10]
https://web.archive.org/web/20180917225801/https://twitter.com/CoralineAda/status/690334282607378432
>>>> So, is code a *published* item? Most of the public can't read it.
>>>
>>> I cannot read (or understand) neither Russian nor Chinese nor almost any
>>> natural (let alone dead) languages of the world. I'm pretty sure that
>>> I'm not the only one;-)
>>> Does that make Russian literature non-public? I don't think so ...
>>
>> You confuse the issue. My definition included "intended for the
>> public". But it isn't clear that open source code is intended for the
>> public -- it is intended for those who code or wish to.
> Well, then I have to repeat myself: Signed-off source code (in form of
> patches) in a well-known programming language for a (nowadays)
> well-known GPLv2 licensed project mailed on "everyone can subscribe"
> mailinglists, (thus) to be found in several $SEARCH_ENGINE-indexed
> mailinglist archives, if accepted to be found in lots of publicly
> accessible git repos can be not intended to be published?
You did it again. You changed words. I said intended for the public,
and you ended your sentence with "intended to be published".
Like it or not, both the law and English grammar have ambiguities.
People put up with them because they share a common intuition (in a
lot of cases) of what each other means.
If you share a birthday card with your personal love note inscribed
and the birthday girl sends it around to everyone at the party, have
you been violated? She might argue: how did you expect it to remain
private if you knew there were several people invited to the birthday
party?
> I wonder what else must happen.
Wonder no more.
Mark
On Wed, Sep 26, 2018 at 02:34:07PM -0500, \0xDynamite wrote:
> >> You confuse the issue. My definition included "intended for the
> >> public". But it isn't clear that open source code is intended for the
> >> public -- it is intended for those who code or wish to.
>
> > Well, then I have to repeat myself: Signed-off source code (in form of
> > patches) in a well-known programming language for a (nowadays)
> > well-known GPLv2 licensed project mailed on "everyone can subscribe"
> > mailinglists, (thus) to be found in several $SEARCH_ENGINE-indexed
> > mailinglist archives, if accepted to be found in lots of publicly
> > accessible git repos can be not intended to be published?
>
> You did it again. You changed words. I said intended for the public,
> and you ended your sentence with "intended to be published".
>
> Like it or not, both the law and English grammar have ambiguities.
> People put up with them because they share a common intuition (in a
> lot of cases) of what each other means.
>
> If you share a birthday card with your personal love note inscribed
> and the birthday girl sends it around to everyone at the party, have
> you been violated? She might argue: how did you expect it to remain
> private if you knew there were several people invited to the birthday
> party?
English does have oddities, agreed. However, open source code is
definitely intended for the public as well.
If I post an ad targeted at dog owners in my local town hall, it
doesn't mean it's not intended for the public. Even though it is
only for dog owners (or those who wish to be), it is still
available freely to the general public.
--
Cheers,
Joey Pabalinas
> Well, then I have to repeat myself: Signed-off source code (in form of
> patches) in a well-known programming language for a (nowadays)
> well-known GPLv2 licensed project mailed on "everyone can subscribe"
> mailinglists, (thus) to be found in several $SEARCH_ENGINE-indexed
> mailinglist archives, if accepted to be found in lots of publicly
> accessible git repos can be not intended to be published?
>
> I wonder what else must happen.
There is a bigger problem in the ambiguity.
It's easy to deal with signed off by lines because I had the sense to
make sure that the DCO covered us for EU data protection and thus it's
explicit.
It's relatively easy to deal with the case of 'I contributed some code'.
It's really not at all obvious what happens with 'I got some code from
another project that contains it's authors name'.
The wording IMHO just needs tightening up - and that's a useful
discussion that ought to he bad. I tihnk everyone understands the *inent*
of such wording - don't go around doxing people, or posting their home
address on facebook and calling for people to attend with pitchforks.
There's a second related area that needs sorting out in wording which is
the implication of any kind of privacy in a complaint - which is really
bad in two ways
As it is set up now the tab is not a lawyer so the tab could not claim
any kind of legal privilege. That means in the event of a complaint the
tab would be powerless not to release almost all the info in the
complaint if hit by a data protectin request in many jurisdictions. Sure
they'd have to (and be required to) remove some of the information that
might identify the complainant.
Secondly one thing that we've learned repeatedly (and notably from the
church scandals) is that there are some complaints that should upon
receipt be handed directly to law enforcement, but there is no carve out
for this.
The other issue is that whoever handles any complaint system needs a
budget and lawyers because they will potentially have to field judicial
reviews and other challenges. That means the TAB needs to have
exemplary record keeping and process because anyone who stands up in a
legal challenge and says 'Umm.. we read it and talked about it and kind
of decided X but I don't remember why and there are no minutes and there
is on process document' is going to get fried. Someone needs to have that
process in place well in advance.
Alan
>> You did it again. You changed words. I said intended for the public,
>> and you ended your sentence with "intended to be published".
>>
>> Like it or not, both the law and English grammar have ambiguities.
>> People put up with them because they share a common intuition (in a
>> lot of cases) of what each other means.
>>
>> If you share a birthday card with your personal love note inscribed
>> and the birthday girl sends it around to everyone at the party, have
>> you been violated? She might argue: how did you expect it to remain
>> private if you knew there were several people invited to the birthday
>> party?
>
> English does have oddities, agreed. However, open source code is
> definitely intended for the public as well.
I think your wording is a bit sloppy. As an engineer, I might publish
my designs, but do I intend them for the general public? Only if I'm
in some kind of teacher-mode where I hope the public can learn from my
designs. However, RMS started GNU with the idea of a COMMUNITY -- a
particular community: one of fellow coders.
If others learn from the code by its nature as open source, that
doesn't mean the license implies that it is INTENDED for the public,
just that it was OPEN to it. It is the same difference between
*marketing* your business and just "setting up shop" with an open
door. Once you've marketed the business, you've created an implied
contract of "intent to deliver".
Subtle, but significant, difference.
Mark
On Fri, Sep 28, 2018 at 11:56 AM Alan Cox <[email protected]> wrote:
>
> > Well, then I have to repeat myself: Signed-off source code (in form of
> > patches) in a well-known programming language for a (nowadays)
> > well-known GPLv2 licensed project mailed on "everyone can subscribe"
> > mailinglists, (thus) to be found in several $SEARCH_ENGINE-indexed
> > mailinglist archives, if accepted to be found in lots of publicly
> > accessible git repos can be not intended to be published?
> >
> > I wonder what else must happen.
>
> There is a bigger problem in the ambiguity.
Alan, I think there is much wisdom in the Linux community writing
their own CoC. This CoC would go through the same RFC process that any
kernel commit goes through and be discussed on LKML. I fully expect
this CoC would contain many of the concepts from Contributors Covenant
but as an independently developed document it would not bring external
baggage into the community. The kernel community is full of very smart
people and has access to fine lawyers. Developing a Linux specific CoC
that expresses the community's views, is compatible with laws in the
varied countries and which respects the GPL is a worthy goal.
>
> It's easy to deal with signed off by lines because I had the sense to
> make sure that the DCO covered us for EU data protection and thus it's
> explicit.
>
> It's relatively easy to deal with the case of 'I contributed some code'.
>
> It's really not at all obvious what happens with 'I got some code from
> another project that contains it's authors name'.
>
> The wording IMHO just needs tightening up - and that's a useful
> discussion that ought to he bad. I tihnk everyone understands the *inent*
> of such wording - don't go around doxing people, or posting their home
> address on facebook and calling for people to attend with pitchforks.
>
> There's a second related area that needs sorting out in wording which is
> the implication of any kind of privacy in a complaint - which is really
> bad in two ways
>
> As it is set up now the tab is not a lawyer so the tab could not claim
> any kind of legal privilege. That means in the event of a complaint the
> tab would be powerless not to release almost all the info in the
> complaint if hit by a data protectin request in many jurisdictions. Sure
> they'd have to (and be required to) remove some of the information that
> might identify the complainant.
>
> Secondly one thing that we've learned repeatedly (and notably from the
> church scandals) is that there are some complaints that should upon
> receipt be handed directly to law enforcement, but there is no carve out
> for this.
>
> The other issue is that whoever handles any complaint system needs a
> budget and lawyers because they will potentially have to field judicial
> reviews and other challenges. That means the TAB needs to have
> exemplary record keeping and process because anyone who stands up in a
> legal challenge and says 'Umm.. we read it and talked about it and kind
> of decided X but I don't remember why and there are no minutes and there
> is on process document' is going to get fried. Someone needs to have that
> process in place well in advance.
>
> Alan
--
Jon Smirl
[email protected]
Alan Cox <[email protected]>:
> The wording IMHO just needs tightening up - and that's a useful
> discussion that ought to he bad. I tihnk everyone understands the *inent*
> of such wording - don't go around doxing people, or posting their home
> address on facebook and calling for people to attend with pitchforks.
I'm going to, again, avoid normative statements and try to clarify what
the questions are here, speaking from my anthropologist/game-theorist head.
As a matter of process, there are two different sets of issues about changing
the CoC wording. Referring to my previous post on ethos and telos:
https://lkml.org/lkml/2018/9/23/212
1. The wording needs to be tweaked to make it clearer what things are against
the ethos. For example: we may want Code violations to include hateful speech
on the mailing list directed at other LKML members. Does it follow that
we want the Code to proscribe "hate speech" directed against third parties,
or off-list "hateful" behavior? Perhaps we do, perhaps not; but either
way the boundaries need to be clearer.
2. The language needs to be examined with particular care to discover
where it implies a change to LKML's telos. I argue no position at this time
about whether LKML's telos *should* change, but I note that the rather heated
dissent the CoC has provoked comes from a widespread perception that it *is*, in
fact, a none-too-covert attempt to alter the telos.
I further note that this perception is supported by the CoC Author's
"Post-Meritocracy manifesto".
https://postmeritocracy.org/
Kernel contributors, understandably, want a clear read on whether the
application of the CoC is to be guided by meritocratic or
"post-meritocratic" principles. This is a telos issue, not just
an ethos issue, and much more fundamental.
I endorse a suggestion made elsewhere that a revised CoC would best be
developed by an RFC-like process. Because *that is how we do such things*;
that is *our* culture's mechanism for achieving and maintaining consensus
on difficult issues.
--
<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.
(I mistakenly sent this with 'r' previously. Please reply to this copy.)
Alan Cox <[email protected]>:
> The wording IMHO just needs tightening up - and that's a useful
> discussion that ought to he bad. I tihnk everyone understands the *inent*
> of such wording - don't go around doxing people, or posting their home
> address on facebook and calling for people to attend with pitchforks.
I'm going to, again, avoid normative statements and try to clarify what
the questions are here, speaking from my anthropologist/game-theorist head.
As a matter of process, there are two different sets of issues about changing
the CoC wording. Referring to my previous post on ethos and telos:
https://lkml.org/lkml/2018/9/23/212
1. The wording needs to be tweaked to make it clearer what things are against
the ethos. For example: we may want Code violations to include hateful speech
on the mailing list directed at other LKML members. Does it follow that
we want the Code to proscribe "hate speech" directed against third parties,
or off-list "hateful" behavior? Perhaps we do, perhaps not; but either
way the boundaries need to be clearer.
2. The language needs to be examined with particular care to discover
where it implies a change to LKML's telos. I argue no position at this time
about whether LKML's telos *should* change, but I note that the rather heated
dissent the CoC has provoked comes from a widespread perception that it *is*, in
fact, a none-too-covert attempt to alter the telos.
I further note that this perception is supported by the CoC Author's
"Post-Meritocracy manifesto".
https://postmeritocracy.org/
Kernel contributors, understandably, want a clear read on whether the
application of the CoC is to be guided by meritocratic or
"post-meritocratic" principles. This is a telos issue, not just
an ethos issue, and much more fundamental.
I endorse a suggestion made elsewhere that a revised CoC would best be
developed by an RFC-like process. Because *that is how we do such things*;
that is *our* culture's mechanism for achieving and maintaining consensus
on difficult issues.
--
<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.