You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Roman Shaposhnik <ro...@shaposhnik.org> on 2017/10/23 23:32:58 UTC
Replacing CLA with DCO+ALv2
Hi!
my understanding has always been that while CLAs may be a bit
cumbersome they are are basically the most robust mechanism
for taking care of IP provenance. That's why ASF still uses them.
This thinking was challenged today by a recent example of Chef
moving from a CLA model to a DCO based one for an overall
ALv2 licensed project.
Here are the details:
https://blog.chef.io/2016/09/19/introducing-developer-certificate-of-origin/
but the punch line is this (and I quote): "However, the DCO in conjunction
with the Apache License may be considered an alternate CLA"
Has the thinking around this somehow shifted? Is Chef alone in thinking
that DCO + ALv2 gives you all you need from a CLA?
Personally I still feel that CLA is justified (even if it is a bit clunky to
administer) but at the same time I'd love to know if somebody really
took the time to do this kind of risk/benefit analysis lately.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: Replacing CLA with DCO+ALv2
Posted by "Wheeler, David A" <dw...@ida.org>.
Roman Shaposhnik:
> my understanding has always been that while CLAs may be a bit
> cumbersome they are are basically the most robust mechanism for taking
> care of IP provenance. That's why ASF still uses them.
>
> This thinking was challenged today by a recent example of Chef moving
> from a CLA model to a DCO based one for an overall
> ALv2 licensed project...
In a 2015 paper I wrote, I *do* classify the DCO as a kind of "contributor agreement", since after all, it *is* something that contributors directly assert that they agree to. (See: "Using an Open Source Software Approach for Cybersecurity Technology Transition", David A. Wheeler, IDA Paper P-5279, November 24, 2015, https://www.ida.org/idamedia/Corporate/Files/Publications/IDA_Documents/ITSD/2016/P-5279.ashx ).
The DCO is not a separately-physically-signed CLA, of course, which is what I presume that you mean by a CLA. There's been controversy about those kinds of CLAs, because while *some* believe physically-signed CLAs provide more *legal* protection, physically-signed CLAs also create a higher risk that the entire project will fail due to lack of contributions. Per that document:
"Some projects choose to require other kinds of contributor agreements, including those signed by an employer (if one exists) and/or physically signed contributor agreements. ... . A physically signed contributor agreement is considered by some to be stronger evidence that the agreement was valid. ... [But] they can still have a significantly detrimental effect on contributions because obtaining them can be time-consuming and can either cause the contributor to not contribute (even if they legally could) or can cause a significant delay. If a signature must be from someone authorized to speak for a company (typically an employer), this can impose significant delays on a contribution, and if an employer is too busy this mechanism can inhibit perfectly legal contributions. Physical signatures require mailing and tracking, creating an extra processing burden. [These] kinds of contributor agreements inhibit or delay some contributions and can increase the risk that the OSS project will not receive enough contributions to continue. What’s more, it is not clear that agreements actually provide significantly more legal protection; organizations generally cannot verify that the signer in another organization is authorized to do so, or is even the person they claim to be, and generally cannot verify a physical signature before the fact. Thus, the legal protection assignments these approaches are supposed to provide may prove elusive. Others who have looked into the issues also argue against using contributor agreements beyond DCOs in most cases [Kuhn2014]."
The ASF can require whatever it wants to, of course, and I suspect there *are* cases where physically-signed contributor agreements could make sense. In most cases, I recommend DCOs; they provide a little more legal protection while still being low friction. Just like anything else, there are trade-offs. Physically signed CLAs may reduce legal risks slightly, while increasing the risk that the entire project will fail, so weighing the trade-offs is something organizations should do carefully. You should always weigh *all* risks, not just legal ones. But again, the ASF decides what is & is not acceptable for the ASF.
--- David A. Wheeler
Re: Replacing CLA with DCO+ALv2
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi
I doubt that a DCO makes a valid legal document at least for german, since a signature has to be done by hand or has to be a digitally signature.
a somewhat weak point: for apache the committer has to check that the contributor is not forged and has signed an icla. with dco in place the committer has to check the whole signoff chain whether it is actually genuine, since it may contain other contributors as well which may be forged by the contributor.
anyone can add a signoff oflebbe@apache.org without my consent.
Does a submission of a dev with a company email address in sign-off has the same legal binding as a CCLA signed by an company official ? sorry, i doubt this as well.
olaf
> Am 24.10.2017 um 01:39 schrieb Manfred Moser <ma...@simpligility.com>:
>
> In terms of making it easy to administrate and use I can recommend CLA assistant...
>
> https://cla-assistant.io/
>
> Manfred
>
> Roman Shaposhnik wrote on 2017-10-23 16:32:
>
>> Hi!
>>
>> my understanding has always been that while CLAs may be a bit
>> cumbersome they are are basically the most robust mechanism
>> for taking care of IP provenance. That's why ASF still uses them.
>>
>> This thinking was challenged today by a recent example of Chef
>> moving from a CLA model to a DCO based one for an overall
>> ALv2 licensed project.
>>
>> Here are the details:
>> https://blog.chef.io/2016/09/19/introducing-developer-certificate-of-origin/
>> but the punch line is this (and I quote): "However, the DCO in conjunction
>> with the Apache License may be considered an alternate CLA"
>>
>> Has the thinking around this somehow shifted? Is Chef alone in thinking
>> that DCO + ALv2 gives you all you need from a CLA?
>>
>> Personally I still feel that CLA is justified (even if it is a bit clunky to
>> administer) but at the same time I'd love to know if somebody really
>> took the time to do this kind of risk/benefit analysis lately.
>>
>> Thanks,
>> Roman.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Replacing CLA with DCO+ALv2
Posted by Manfred Moser <ma...@simpligility.com>.
In terms of making it easy to administrate and use I can recommend CLA assistant...
https://cla-assistant.io/
Manfred
Roman Shaposhnik wrote on 2017-10-23 16:32:
> Hi!
>
> my understanding has always been that while CLAs may be a bit
> cumbersome they are are basically the most robust mechanism
> for taking care of IP provenance. That's why ASF still uses them.
>
> This thinking was challenged today by a recent example of Chef
> moving from a CLA model to a DCO based one for an overall
> ALv2 licensed project.
>
> Here are the details:
> https://blog.chef.io/2016/09/19/introducing-developer-certificate-of-origin/
> but the punch line is this (and I quote): "However, the DCO in conjunction
> with the Apache License may be considered an alternate CLA"
>
> Has the thinking around this somehow shifted? Is Chef alone in thinking
> that DCO + ALv2 gives you all you need from a CLA?
>
> Personally I still feel that CLA is justified (even if it is a bit clunky to
> administer) but at the same time I'd love to know if somebody really
> took the time to do this kind of risk/benefit analysis lately.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
RE: Replacing CLA with DCO+ALv2
Posted by "Wheeler, David A" <dw...@ida.org>.
Rob Vesse:
> I think that there is in part a confusion about a hard requirement for CLAs.
> ... projects under the Apache license are free to accept contributions
> without any CLA in-place.
> The use of CLAs is mostly a policy decision to provide an extra degree of
> legal assurance around the provenance of the contributions...
> Maybe a discussion on this topic would make a good foundation blog
> post?
I agree. I think many confuse "policies of the Apache Software Foundation for its own projects" with "requirements of the Apache software license". Clarifying things is always a good idea. An FAQ entry might also be good, so that people Googling in the future are more likely to find it.
Roman Shaposhnik:
> There's a constant argument being made that CLA significantly decreases
> the likelihood of getting developers to contribute to CLA-upfront
> projects.
> Personally, I don't subscribe to this view, but it is quite prevalent:
> https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/
> https://blog.docker.com/2014/01/docker-code-contributions-require- developer-certificate-of-origin/
I have *personally* experienced this difficulty (leading to decreased contributions), and I've seen it in others. This is not a potential result, it is a reality.
As I noted, there is a trade-off between requiring and not requiring a CLA beyond a DCO. Different groups may make different decisions about this trade-off, depending on what they think is the bigger risk. That's fine! But it *is* a trade-off.
--- David A. Wheeler
Re: Replacing CLA with DCO+ALv2
Posted by Chris Mattmann <ma...@apache.org>.
I was going to chime in here – if you ever intend for someone to gain commit privileges
- kinda important here in the ASF communities – and a big community issue for someone who
say keeps contributing but b/c no ICLA is never able to get the reward – then an ICLA would be
an important thing to have on file.
Cheers,
Chris
On 10/26/17, 7:08 AM, "Jim Jagielski" <ji...@jaguNET.com> wrote:
We *require* CLAs only for those who have commit privs.
> On Oct 26, 2017, at 5:24 AM, Rob Vesse <rv...@dotnetrdf.org> wrote:
>
> I think that there is in part a confusion about a hard requirement for CLAs. People have a convenient habit of forgetting clause 5 of the Apache license:
>
> http://www.apache.org/licenses/LICENSE-2.0.html#contributions
>
> “Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.”
>
> So, projects under the Apache license are free to accept contributions without any CLA in-place.
>
> The use of CLAs is mostly a policy decision to provide an extra degree of legal assurance around the provenance of the contributions. We at Apache require that all committers have a CLA on file but there is no requirement that other organisations licensing code under the Apache license follow suit.
>
> Maybe a discussion on this topic would make a good foundation blog post?
>
> Rob
>
> On 26/10/2017 01:53, "Roman Shaposhnik" <shaposhnik@gmail.com on behalf of roman@shaposhnik.org> wrote:
>
> On Wed, Oct 25, 2017 at 4:53 PM, Shane Curcuru <as...@shanecurcuru.org> wrote:
>> What specific purpose would changing our long-held incoming licensing
>> scheme fulfill?
>
> There's a constant argument being made that CLA significantly decreases
> the likelihood of getting developers to contribute to CLA-upfront projects.
> Personally, I don't subscribe to this view, but it is quite prevalent:
> https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/
> https://blog.docker.com/2014/01/docker-code-contributions-require-developer-certificate-of-origin/
> and there are numerous others (including the one that started this thread)
> calming the same.
>
> Just this week I had to vigorously defend our position in front of developers
> seeking where to put their new OS project and I'm sure these conversations
> come up every Open Source Summit, etc.
>
>> Until we have a specific reason, and a thorough legal review, I'd be -1
>> from my perspective on changing any of our CLA process.
>
> Given our "community over code" mantra I'd expect that we'd be very vigilant
> for everything that may stand in the way of that community growth. If one
> subscribes to the views I quoted that may be a concern.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Replacing CLA with DCO+ALv2
Posted by Jim Jagielski <ji...@jaguNET.com>.
> On Oct 26, 2017, at 10:23 AM, Craig Russell <ap...@gmail.com> wrote:
>
>>
>> On Oct 26, 2017, at 7:08 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>>
>> We *require* CLAs only for those who have commit privy.
>
> It's up to each PMC whether they *require* CLA to cover contributions. I would expect that a *large* contribution would *require* a CLA even if the PMC has no intention to make the contributor a committer.
>
True, although an SGA might be the more logical legal
vehicle for that.
I would suggest that, from a foundation PoV, an
iCLA is only required for committers; as you said,
PMCs can also require it for other things as well.
The issue is that we don't want to require the iCLA
for drive-thru contributions... (IMO)
> Craig
>>
>>> On Oct 26, 2017, at 5:24 AM, Rob Vesse <rv...@dotnetrdf.org> wrote:
>>>
>>> I think that there is in part a confusion about a hard requirement for CLAs. People have a convenient habit of forgetting clause 5 of the Apache license:
>>>
>>> http://www.apache.org/licenses/LICENSE-2.0.html#contributions
>>>
>>> “Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.”
>>>
>>> So, projects under the Apache license are free to accept contributions without any CLA in-place.
>>>
>>> The use of CLAs is mostly a policy decision to provide an extra degree of legal assurance around the provenance of the contributions. We at Apache require that all committers have a CLA on file but there is no requirement that other organisations licensing code under the Apache license follow suit.
>>>
>>> Maybe a discussion on this topic would make a good foundation blog post?
>>>
>>> Rob
>>>
>>> On 26/10/2017 01:53, "Roman Shaposhnik" <shaposhnik@gmail.com on behalf of roman@shaposhnik.org> wrote:
>>>
>>> On Wed, Oct 25, 2017 at 4:53 PM, Shane Curcuru <as...@shanecurcuru.org> wrote:
>>>> What specific purpose would changing our long-held incoming licensing
>>>> scheme fulfill?
>>>
>>> There's a constant argument being made that CLA significantly decreases
>>> the likelihood of getting developers to contribute to CLA-upfront projects.
>>> Personally, I don't subscribe to this view, but it is quite prevalent:
>>> https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/
>>> https://blog.docker.com/2014/01/docker-code-contributions-require-developer-certificate-of-origin/
>>> and there are numerous others (including the one that started this thread)
>>> calming the same.
>>>
>>> Just this week I had to vigorously defend our position in front of developers
>>> seeking where to put their new OS project and I'm sure these conversations
>>> come up every Open Source Summit, etc.
>>>
>>>> Until we have a specific reason, and a thorough legal review, I'd be -1
>>>> from my perspective on changing any of our CLA process.
>>>
>>> Given our "community over code" mantra I'd expect that we'd be very vigilant
>>> for everything that may stand in the way of that community growth. If one
>>> subscribes to the views I quoted that may be a concern.
>>>
>>> Thanks,
>>> Roman.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>>> For additional commands, e-mail: legal-discuss-help@apache.org
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
> Craig L Russell
> Secretary, Apache Software Foundation
> clr@apache.org http://db.apache.org/jdo
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Replacing CLA with DCO+ALv2
Posted by Craig Russell <ap...@gmail.com>.
> On Oct 26, 2017, at 7:08 AM, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> We *require* CLAs only for those who have commit privy.
It's up to each PMC whether they *require* CLA to cover contributions. I would expect that a *large* contribution would *require* a CLA even if the PMC has no intention to make the contributor a committer.
Craig
>
>> On Oct 26, 2017, at 5:24 AM, Rob Vesse <rv...@dotnetrdf.org> wrote:
>>
>> I think that there is in part a confusion about a hard requirement for CLAs. People have a convenient habit of forgetting clause 5 of the Apache license:
>>
>> http://www.apache.org/licenses/LICENSE-2.0.html#contributions
>>
>> “Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.”
>>
>> So, projects under the Apache license are free to accept contributions without any CLA in-place.
>>
>> The use of CLAs is mostly a policy decision to provide an extra degree of legal assurance around the provenance of the contributions. We at Apache require that all committers have a CLA on file but there is no requirement that other organisations licensing code under the Apache license follow suit.
>>
>> Maybe a discussion on this topic would make a good foundation blog post?
>>
>> Rob
>>
>> On 26/10/2017 01:53, "Roman Shaposhnik" <shaposhnik@gmail.com on behalf of roman@shaposhnik.org> wrote:
>>
>> On Wed, Oct 25, 2017 at 4:53 PM, Shane Curcuru <as...@shanecurcuru.org> wrote:
>>> What specific purpose would changing our long-held incoming licensing
>>> scheme fulfill?
>>
>> There's a constant argument being made that CLA significantly decreases
>> the likelihood of getting developers to contribute to CLA-upfront projects.
>> Personally, I don't subscribe to this view, but it is quite prevalent:
>> https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/
>> https://blog.docker.com/2014/01/docker-code-contributions-require-developer-certificate-of-origin/
>> and there are numerous others (including the one that started this thread)
>> calming the same.
>>
>> Just this week I had to vigorously defend our position in front of developers
>> seeking where to put their new OS project and I'm sure these conversations
>> come up every Open Source Summit, etc.
>>
>>> Until we have a specific reason, and a thorough legal review, I'd be -1
>>> from my perspective on changing any of our CLA process.
>>
>> Given our "community over code" mantra I'd expect that we'd be very vigilant
>> for everything that may stand in the way of that community growth. If one
>> subscribes to the views I quoted that may be a concern.
>>
>> Thanks,
>> Roman.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org http://db.apache.org/jdo
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Replacing CLA with DCO+ALv2
Posted by Jim Jagielski <ji...@jaguNET.com>.
We *require* CLAs only for those who have commit privs.
> On Oct 26, 2017, at 5:24 AM, Rob Vesse <rv...@dotnetrdf.org> wrote:
>
> I think that there is in part a confusion about a hard requirement for CLAs. People have a convenient habit of forgetting clause 5 of the Apache license:
>
> http://www.apache.org/licenses/LICENSE-2.0.html#contributions
>
> “Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.”
>
> So, projects under the Apache license are free to accept contributions without any CLA in-place.
>
> The use of CLAs is mostly a policy decision to provide an extra degree of legal assurance around the provenance of the contributions. We at Apache require that all committers have a CLA on file but there is no requirement that other organisations licensing code under the Apache license follow suit.
>
> Maybe a discussion on this topic would make a good foundation blog post?
>
> Rob
>
> On 26/10/2017 01:53, "Roman Shaposhnik" <shaposhnik@gmail.com on behalf of roman@shaposhnik.org> wrote:
>
> On Wed, Oct 25, 2017 at 4:53 PM, Shane Curcuru <as...@shanecurcuru.org> wrote:
>> What specific purpose would changing our long-held incoming licensing
>> scheme fulfill?
>
> There's a constant argument being made that CLA significantly decreases
> the likelihood of getting developers to contribute to CLA-upfront projects.
> Personally, I don't subscribe to this view, but it is quite prevalent:
> https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/
> https://blog.docker.com/2014/01/docker-code-contributions-require-developer-certificate-of-origin/
> and there are numerous others (including the one that started this thread)
> calming the same.
>
> Just this week I had to vigorously defend our position in front of developers
> seeking where to put their new OS project and I'm sure these conversations
> come up every Open Source Summit, etc.
>
>> Until we have a specific reason, and a thorough legal review, I'd be -1
>> from my perspective on changing any of our CLA process.
>
> Given our "community over code" mantra I'd expect that we'd be very vigilant
> for everything that may stand in the way of that community growth. If one
> subscribes to the views I quoted that may be a concern.
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Replacing CLA with DCO+ALv2
Posted by Rob Vesse <rv...@dotnetrdf.org>.
I think that there is in part a confusion about a hard requirement for CLAs. People have a convenient habit of forgetting clause 5 of the Apache license:
http://www.apache.org/licenses/LICENSE-2.0.html#contributions
“Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.”
So, projects under the Apache license are free to accept contributions without any CLA in-place.
The use of CLAs is mostly a policy decision to provide an extra degree of legal assurance around the provenance of the contributions. We at Apache require that all committers have a CLA on file but there is no requirement that other organisations licensing code under the Apache license follow suit.
Maybe a discussion on this topic would make a good foundation blog post?
Rob
On 26/10/2017 01:53, "Roman Shaposhnik" <shaposhnik@gmail.com on behalf of roman@shaposhnik.org> wrote:
On Wed, Oct 25, 2017 at 4:53 PM, Shane Curcuru <as...@shanecurcuru.org> wrote:
> What specific purpose would changing our long-held incoming licensing
> scheme fulfill?
There's a constant argument being made that CLA significantly decreases
the likelihood of getting developers to contribute to CLA-upfront projects.
Personally, I don't subscribe to this view, but it is quite prevalent:
https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/
https://blog.docker.com/2014/01/docker-code-contributions-require-developer-certificate-of-origin/
and there are numerous others (including the one that started this thread)
calming the same.
Just this week I had to vigorously defend our position in front of developers
seeking where to put their new OS project and I'm sure these conversations
come up every Open Source Summit, etc.
> Until we have a specific reason, and a thorough legal review, I'd be -1
> from my perspective on changing any of our CLA process.
Given our "community over code" mantra I'd expect that we'd be very vigilant
for everything that may stand in the way of that community growth. If one
subscribes to the views I quoted that may be a concern.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Replacing CLA with DCO+ALv2
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Wed, Oct 25, 2017 at 4:53 PM, Shane Curcuru <as...@shanecurcuru.org> wrote:
> What specific purpose would changing our long-held incoming licensing
> scheme fulfill?
There's a constant argument being made that CLA significantly decreases
the likelihood of getting developers to contribute to CLA-upfront projects.
Personally, I don't subscribe to this view, but it is quite prevalent:
https://sfconservancy.org/blog/2014/jun/09/do-not-need-cla/
https://blog.docker.com/2014/01/docker-code-contributions-require-developer-certificate-of-origin/
and there are numerous others (including the one that started this thread)
calming the same.
Just this week I had to vigorously defend our position in front of developers
seeking where to put their new OS project and I'm sure these conversations
come up every Open Source Summit, etc.
> Until we have a specific reason, and a thorough legal review, I'd be -1
> from my perspective on changing any of our CLA process.
Given our "community over code" mantra I'd expect that we'd be very vigilant
for everything that may stand in the way of that community growth. If one
subscribes to the views I quoted that may be a concern.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Replacing CLA with DCO+ALv2
Posted by Shane Curcuru <as...@shanecurcuru.org>.
What specific purpose would changing our long-held incoming licensing
scheme fulfill?
Until we have a specific reason, and a thorough legal review, I'd be -1
from my perspective on changing any of our CLA process.
--
- Shane
https://www.apache.org/foundation/marks/resources
Roman Shaposhnik wrote on 10/23/17 7:32 PM:
> Hi!
>
> my understanding has always been that while CLAs may be a bit
> cumbersome they are are basically the most robust mechanism
> for taking care of IP provenance. That's why ASF still uses them.
>
> This thinking was challenged today by a recent example of Chef
> moving from a CLA model to a DCO based one for an overall
> ALv2 licensed project.
>
> Here are the details:
> https://blog.chef.io/2016/09/19/introducing-developer-certificate-of-origin/
> but the punch line is this (and I quote): "However, the DCO in conjunction
> with the Apache License may be considered an alternate CLA"
>
> Has the thinking around this somehow shifted? Is Chef alone in thinking
> that DCO + ALv2 gives you all you need from a CLA?
>
> Personally I still feel that CLA is justified (even if it is a bit clunky to
> administer) but at the same time I'd love to know if somebody really
> took the time to do this kind of risk/benefit analysis lately.
>
> Thanks,
> Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org