From: Alex Elsayed <eternaleye@gmail.com>
To: ceph-devel@vger.kernel.org
Subject: Re: Signed-off-by and aliases
Date: Mon, 17 Aug 2015 13:19:21 -0700 [thread overview]
Message-ID: <mqtfkc$ic7$1@ger.gmane.org> (raw)
In-Reply-To: 55CDC978.20304@dachary.org
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@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2015-08-17 20:19 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-31 19:59 Signed-off-by and aliases Loic Dachary
2015-08-01 8:11 ` Wido den Hollander
2015-08-02 16:19 ` Joao Eduardo Luis
2015-08-03 19:02 ` Wido den Hollander
2015-08-03 19:18 ` John Spray
2015-08-03 20:10 ` Loic Dachary
2015-08-12 10:54 ` Gregory Farnum
2015-08-12 12:51 ` Loic Dachary
2015-08-14 8:49 ` Joao Eduardo Luis
2015-08-14 10:56 ` Loic Dachary
2015-08-17 20:19 ` Alex Elsayed [this message]
2015-08-17 20:44 ` Loic Dachary
2015-08-17 20:58 ` Alex Elsayed
2015-08-17 21:18 ` Loic Dachary
2015-08-17 21:23 ` Alex Elsayed
2015-08-18 13:39 ` Sage Weil
2015-08-18 15:11 ` Alex Elsayed
-- strict thread matches above, loose matches on Subject: below --
2014-05-19 15:13 Loic Dachary
[not found] ` <1400513274.44658.YahooMailNeo@web165002.mail.bf1.yahoo.com>
2014-05-19 16:47 ` Loic Dachary
2014-05-20 4:19 ` Richard Fontana
2014-05-20 5:31 ` Loic Dachary
2014-05-20 13:56 ` Richard Fontana
2014-05-21 17:06 ` Loic Dachary
2014-05-21 17:31 ` Richard Fontana
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='mqtfkc$ic7$1@ger.gmane.org' \
--to=eternaleye@gmail.com \
--cc=ceph-devel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.