[PATCH] Developer policy amendment re. non-disclosure

[Daniel Berlin]

This of course, has it's own set of issues for both the person and the
project.

In any case, the practical problems Tobias presents are real problems.  The
normal way they are taken care of is not necessarily through mailing list
policy but through contributor agreements of various sorts that explicitly
define contributions as "stuff sent on mailing lists, unless marked 'not a
contribution'", and then license them.
Then there is no ambiguity, and no need to set policy.

In the absence of this, it's a bit hard to strike a balance.
As I said, i am not personally opposed to banning/ignoring disclaimer'd
mails.

If this is a real concern for a lot of people, it almost sounds like it may
be better to discuss it in person at some point at the upcoming developer
meeting, and come to some conclusion there.

I say this mainly because not everyone is going to be comfortable
expressing the various issues on a public mailing list :)

On Sat, Oct 19, 2013 at 2:12 AM, Yaron Keren <yaron.keren at gmail.com> wrote:

> Hi,
>
> As a practical solution, rather than having to change company policies
> (hard and time wasting), people can simply open a gmail (or else) account
> for the purpose of submitting patches or LLVM-related correspondence. It's
> easy and free.
>
> Yaron
>
>
>
> 2013/10/19 Tobias Grosser <tobias at grosser.es>
>
>> On 10/18/2013 06:05 PM, Daniel Berlin wrote:
>>
>>> On Fri, Oct 18, 2013 at 7:38 AM, Rafael Espíndola <
>>>
>>> If everyone really feels they are annoying as all get out, the general
>>> consensus is that this calculus comes out the other way, fine by me :)
>>>
>>
>> They are not really annoying to me, but I have a practical problem with
>> them. As I am not a lawyer, I have no idea how to handle such emails. Can I
>> use information mentioned in them, can I use code snippets discussed in
>> those mails, can I commit contained patches? I currently judge this by
>> myself in a very conservative way (no patches, no code snippets, no ideas).
>> I basically ignore these mails to not get into trouble.
>>
>> The example given by David where he sends patch reviews with
>> non-disclosure agreement is a great example. I would be personally very
>> concerned, as I have no idea if I can include those in my commit.
>>
>> So, for me having reliably defined how to handle such emails in the
>> developer policy is important. Right now, I understand this such as that we
>> can not commit patches, but that in-line code snippets and reviews with
>> non-disclosure statements are OK to commit? Up to which size of code
>> snippets? I have just the feeling this is again a judgement call I would
>> not like to take by myself. Just completely forbidding those footers would
>> make it a lot clearer for me.
>>
>> Given the small amount of non-disclosure patches, it we probably do not
>> loose that many contributions if we ask people to remove those footers.
>> In fact, if an official statement is part of the developer policy, such
>> people could internally make a case why they need to be able to send
>> emails without such a footer. If a company is interested in committing
>> their patches upstream, removing an email footer that should not be
>> enforced anyway does not seem to much to be asked.
>>
>> Cheers,
>> Tobias
>>
>>
>> ______________________________**_________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/**mailman/listinfo/llvm-commits<http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131019/d13cfc7b/attachment.html>