[PATCH] Developer policy amendment re. non-disclosure

Fri Oct 18 05:20:26 PDT 2013

Hi,
Again a personal view:

On 18/10/2013 10:11, David Tweed wrote:
> Hi,
>
> a personal comment: while I can understand the sentiment, I think the
> wording might be a bit ambiguous. I'm tempted to read "... may result in
your
> contribution being excluded" as "If you send a patch in a mail with an
> objectionable footer, that patch may end up being excluded from being
> committed to LLVM forever". I'm sure the meaning is supposed to be more

Hello David,

Below are my personal thoughts in response to yours:

It's sensible to reserve the option to exclude contributions where the
material submitted may be confidential, IP-encumbered or otherwise
non-public. This option has always been there and is nothing new.

| The present wording is intentional and sends a clear message that
| notices waste people's time and resources. So it's not an ambiguity.

Arguably the fact my reaction was "Well this means X, except it
can't possibly be intended to mean that from what I've seen in my
interactions with the
community in the past" is evidence that there's ambiguity in the language.

| That said, this has always been handled with discretion and I doubt a
| few sentences will suddenly change the project ethos or get people
| turned away at the door.

Just to be clear, the ambiguity that I see in the wording is that, at least
in most of the uses of "excluded" I see exclusion as denoting a _permanent_
effect.
(I'm in the UK and maybe other varieties of English have different
connotations.)
Using some wording that makes it clear that this is a _big_ problem but that
the
patch is not "blacklisted forever" would make things clearer. It's not
people getting turned
away at the door I've a concern about because by definition in the act of
turning
people away you _know_ that you've done that, it's people who believe that
what
you've written is what you will actually do and after they make such a
mistake decide to go and work with some other community, and don't feel any
obligation
to send an email informing the list of this decision. In that case you won't
know how many people this has affected, and OSS projects which have some
aspect
which turns off new contributors often end up beached if they don't attract
new
contributors to compensate for the existing contributors leaving.

Again, I'm not necessarily disagreeing with the _actions_ (assuming I have
indeed got the right idea about what the actions are) that I think are
being proposed, it's that the wording may easily be interpreted to mean
something
different from that.

[snip]

| My point is that contributing to the LLVM project with a confidentiality
| footer is no different to breaking the build, then going AWOL for the
| weekend. It's not gospel, but it is inconsiderate -- especially in the
| LLVM community where almost every organisation is a licensee of the
| other, complete with actual obligations of non-disclosure.

To be clear, when I say I post stuff I'm referring to commentary/reviews
rather
than patches (which have to be submitted in certain ways that prevent
footers). However, it
really is a case of what is believed to give the best overall result
for the LLVM project as a whole. Living in a different timezone to the
US and for a fast moving project where initial-post to commit often
happens within a day, I've got to ask myself a question: is giving review
feedback outside hours from home via webmail (and not being able to
switch off the footer) better or worse than not giving review feedback
until I get an opportunity at work the next day, after the patch has gone
in? It's
clearly something the community could either leave to individuals or codify
explicitly a group consensus, but I suspect if the attitude becomes
different
from "if you're overall making the effort to be a good OSS citizen we'll
try to be reasonable about the odd slip" then you may a lot of the extra
work that people at various companies do outside their direct company
mandate stop,
and again I'm not sure that's in the interests of anyone in the LLVM
ecosystem.

[snip]

| My personal view is that this isn't about right and wrong, or some
| gospel as you mentioned, or even about legality. It's simply about being
| considerate to others on the project -- and the wording is finely
| crafted to get that across.

I think I may have used the ambiguous terms: when I said "taken as gospel" I
meant in the colloquial sense as "taken as a description of exactly what
will happen" taking no view
whatsoever about whether the action described by that description is good
or bad. Apologies for the imprecision.

Again, it's possible the natural interpretation of the sentence is different
in different
regions of the world, and it's the language that I'm thinking about.

Cheers,
Dave

>
> Cheers,
> Dave
>
> -----Original Message-----
> From: llvm-commits-bounces at cs.uiuc.edu
[mailto:llvm-commits-bounces at cs.uiuc.edu] On Behalf Of Daniel Berlin
> Sent: 18 October 2013 08:25
> To: Alp Toker
> Cc: llvm-commits
> Subject: Re: [PATCH] Developer policy amendment re. non-disclosure
>
> On Thu, Oct 17, 2013 at 11:02 AM, Alp Toker <alp at nuanti.com> wrote:
>> I've incorporated Daniel's suggested changes with line spacing and a
>> typo fixed, plus the internal link in the original patch restored.
>>
>> Am not particularly keen on the "to the patches themselves"
>> qualification but I understand Nadav feels strongly about this so have
>> kept it in the final patch as a compromise.
>>
> Ignoring any optional "policy-based requirements" (that in practice,
> nobody contributing to LLVM can possibly control), the reality is
> there are sometimes fairly immutable requirements around certain
> disclaimers/etc depending on job function and country.  They should
> never appear on patches, however.
>
> Honestly, if it was reasonable to blanket ban disclaimers on the
> mailing list, i'd be first in line (on principle alone).  But it's
> really not clear what it will achieve past making it more difficult
> for some people to contribute.   If the concern is the possible effect
> they have, the wording i proposed should take care of that[1].  If the
> concern is just that they are annoying, I don't think they reach that
> level yet.  Maybe someday they will (try joining a mailing list with
> lawyers sometime), and we should deal with it then.  If there is some
> other concern here i'm missing, I'd certainly like to hear what it is
> :)
>
>
>> Will appreciate one further review of the final patch from a third party
>> and explicit OK-to-commit before landing this.
> LGTM.
>
>> Alp.
>>
> [1] Caselaw in the US is a little mixed, but basically "unenforceable"
> in general, maybe helpful when it comes to preserving attorney-client
> privilege. They also have interesting side effects.  As one lawyer
> wrote, "it's very hard to argue to a judge you have an appropriate
> system for marking only privileged communications in place when you
> are marking your late night pizza orders with 500 word privilege
> notices".
>
>
>> On 17/10/2013 18:31, Nadav Rotem wrote:
>>> LGTM.  Thank you :)
>>>
>>> On Oct 17, 2013, at 10:30 AM, Daniel Berlin <dberlin at dberlin.org> wrote:
>>>
>>>> Here is an updated patch, which also takes into account an issue Nadav
>>>> kindly pointed out offline.
>>>>
>>>> On Thu, Oct 17, 2013 at 10:11 AM, Daniel Berlin <dberlin at dberlin.org>
wrote:
>>>>> How about this wording for patches:
>>>>>
>>>>> When submitting patches, please do not add confidentiality or
>>>>> non-disclosure notices.  These notices conflict
>>>>> with the LLVM license, and may result in your contribution being
excluded.
>>>>>
>>>>>
>>>>> and this for mailing lists:
>>>>>
>>>>> Please be aware that all public LLVM mailing lists are public and
>>>>> archived, and that notices of confidentially or non-disclosure cannot
>>>>> be respected.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Oct 17, 2013 at 10:06 AM, Nadav Rotem <nrotem at apple.com>
wrote:
>>>>>> Alp,
>>>>>>
>>>>>> I am against it. Your email does not match the clause that you want
to add to the LLVM docs.  In your email you mentioned patches (which is
fine), but in your patch you mentioned email clients, etc.
>>>>>>
>>>>>> Thanks,
>>>>>> Nadav
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Oct 17, 2013, at 9:57 AM, Alp Toker <alp at nuanti.com> wrote:
>>>>>>
>>>>>>> This patch amends the developer policy to discourage corporate
>>>>>>> non-disclosure or confidentiality signatures on patches intended for
>>>>>>> review, which would be at odds with the LLVM license.
>>>>>>>
>>>>>>> OK to commit?
>>>>>>>
>>>>>>> --
>>>>>>> http://www.nuanti.com
>>>>>>> the browser experts
>>>>>>>
>>>>>>>
<llvm-signature-policy.patch>_______________________________________________
>>>>>>> llvm-commits mailing list
>>>>>>> llvm-commits at cs.uiuc.edu
>>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>>>> _______________________________________________
>>>>>> llvm-commits mailing list
>>>>>> llvm-commits at cs.uiuc.edu
>>>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>>> <llvm-signature-policy.patch>
>> --
>> http://www.nuanti.com
>> the browser experts
>>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium.  Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No:  2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
Registered in England & Wales, Company No:  2548782
>

-- 
http://www.nuanti.com
the browser experts