<div dir="ltr">This of course, has it's own set of issues for both the person and the project.<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>

<div class="gmail_extra">Then there is no ambiguity, and no need to set policy.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In the absence of this, it's a bit hard to strike a balance.</div><div class="gmail_extra">
As I said, i am not personally opposed to banning/ignoring disclaimer'd mails.</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">I say this mainly because not everyone is going to be comfortable expressing the various issues on a public mailing list :)</div><div class="gmail_extra"><br></div>
<div class="gmail_extra"><div class="gmail_quote">On Sat, Oct 19, 2013 at 2:12 AM, Yaron Keren <span dir="ltr"><<a href="mailto:yaron.keren@gmail.com" target="_blank">yaron.keren@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="rtl"><div dir="ltr">Hi,</div><div dir="ltr"><br></div><div dir="ltr">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. </div>



<div dir="ltr"><br></div><div dir="ltr">Yaron</div><div dir="ltr"><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div dir="ltr">2013/10/19 Tobias Grosser <span dir="ltr"><<a href="mailto:tobias@grosser.es" target="_blank">tobias@grosser.es</a>></span></div>



<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On 10/18/2013 06:05 PM, Daniel Berlin wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Oct 18, 2013 at 7:38 AM, Rafael Espíndola <<br>
<br>
If everyone really feels they are annoying as all get out, the general<br>
consensus is that this calculus comes out the other way, fine by me :)<br>
</blockquote>
<br>
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.<br>




<br>
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.<br>
<br>
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.<br>




<br>
Given the small amount of non-disclosure patches, it we probably do not<br>
loose that many contributions if we ask people to remove those footers.<br>
In fact, if an official statement is part of the developer policy, such<br>
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.<br>




<br>
Cheers,<br>
Tobias<br>
<br>
<br></div></div><div>
______________________________<u></u>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
</div></blockquote></div><br></div>
</blockquote></div><br></div></div>