Loic Dachary wrote: > Hi Joao, <snipping quite a bit> > It is quite impossible for us (non lawyers) to draw the line that > separates paranoïa and common sense. Reason why most discussions on these > topics turn short. I cannot dismiss the scenario you describe and I'm > quite sure asking a lawyer would not clarify anything. Mostly because > whatever the question, the lawyer answer will always be : "maybe" and > never "yes" or "no" ;-) There are cases where lawyer's will say "yes" or "no" - it's just that those tend to be "Yes, this will cost a lot of effort to succeed against" and "No, I don't think we can successfully argue that" :P > Yet, we are to decide what makes sense and what does not. If you ask the > OpenStack community, the majority agree that it is necessary to have a > CLA. If you ask the Linux kernel community, the consensus seems to be that > there is no need for a CLA. etc. I think part of the issue here is that "CLA" is a very overloaded term (in the C++ sense). Some use it to refer to copyright assignment, which is a portion of some CLAs. Some use it to refer to "thick" CLAs, like the Project Harmony ones, which may or may not have copyright assignment depending on the individual CLA. Others use it to refer to _any_ formal agreement regarding licensing between the code author and some entity responsible for the overall body of code - under which definition the kernel DCO qualifies. Personally, I fall into the camp that says that a DCO-like system, which ensures that input = output and attests to the right to submit, is sufficient: Whethern the person submits the DCO under an alias or not, they have asserted that *submissions under this name (even if it's an alias) will abide by the DCO* - and thus people accepting those patches have a reason to believe that the submissions are "clean" and in good faith. Also, if that model came under fire, various groups involved in the kernel would have a vested interest in helping defend it. That's not a small thing to backstop on. > So, how can one make an opinion on a topic (s)he does not fully understand > ? I chose to decide based on facts I have and favor what give us (the Ceph > project community) more flexibility. I don't think anyone has any fact > regarding legal troubles related to contributor using aliases. And since > we don't verify contributor backgrounds anyway, acknowledging that we > already accept aliases makes sense to me. This is where I see a subtle, but meaningful distinction: Accepting from aliases *which have submitted a DCO* means that the person behind the alias, even if we don't know their name, has bound themselves to a standard ov behavior. Accepting from arbitrary aliases does _not_ carry that meaning. > The value of this thread is more about how we collectively form a > consensus on a topic that has legal implications than the question of > accepting aliases or not. As Greg mentioned, all developers/organizations > holding a significant part of the Ceph copyright know each other. Whatever > is decided regarding aliases, it is not going to have any actual legal > impact. But it would be great if we can somehow come up with a consensus. > Ultimately the decision is not for us to make anyway: we're not a > democracy. But it's not because a community has no power to decide that it > must not have an opinion ;-) Entirely agreed. -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
