You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Greg Stein <gs...@gmail.com> on 2019/03/01 03:31:45 UTC
R.Fontana argues to toss CLAs
Richard just posted an article today about CLAs:
https://opensource.com/article/19/2/cla-problems
Seems like a pretty fair treatment of CLAs in the F/OSS ecosystem.
Cheers,
-g
Re: R.Fontana argues to toss CLAs
Posted by Jim Jagielski <ji...@jaguNET.com>.
Yeah... it's a position that he has held for quite a long time and he and I have chatted quite a bit about it over the years.
I've always explained that our "requirement" for an iCLA is only for those w/ commit bit and is a "belt and braces" situation.
About the article, I am disappointed that the main distinction between various types of CLAs and whether they are copyright *assignments* is not more detailed. He off-handedly refers to it, but it really is a major point that is the crux of the CLA debate, IMO at least.
> On Feb 28, 2019, at 10:31 PM, Greg Stein <gs...@gmail.com> wrote:
>
> Richard just posted an article today about CLAs:
> https://opensource.com/article/19/2/cla-problems <https://opensource.com/article/19/2/cla-problems>
>
> Seems like a pretty fair treatment of CLAs in the F/OSS ecosystem.
>
> Cheers,
> -g
>
Re: R.Fontana argues to toss CLAs
Posted by Ted Dunning <te...@gmail.com>.
Hen,
I can't even see any disagreement on details except possibly what the
cutoff point is. I gave the example of a trivial change that was obviously
below the line. I don't know exactly how significant a contribution needs
to be to require an ICLA or SGA, but I do know that there is a level of big
that requires such. Where the line might be is fuzzy to me.
As such, I can't tell how we disagree. Which is good by me since you
generally make a lot of sense.
On Thu, Feb 28, 2019 at 9:22 PM Hen <ba...@apache.org> wrote:
> I disagree on details.
>
> Your position implies we need to get a signed agreement on most
> contributions. It's the same position that Richard is pointing out as a
> problem.
>
> In reality, we only get non-committers to sign a software grant of
> license, or an ICLA/CCLA, for the largest contributions. There's a large
> amount of copyrightable expression which is not covered by ICLA.
>
> ---
>
> We receive an Apache License 2.0 on contributions. When it comes to
> relicensing we have three classes of 'copyright' within the code:
>
> 1) Non-copyright. Things that were truly public domain, fair use, not
> expressive etc.
> 2) Things that are licensed to the ASF under Apache License 2.0.
> 3) Things that are licensed to the ASF under ICLA (or software grant of
> license, or CCLA).
>
> There's nothing to license in #1. #3 gives us more scope to relicense. #2
> is such that if anyone objects to our having relicensed, we can adjust back
> to AL 2.0.
>
> Hen
>
> On Thu, Feb 28, 2019 at 9:13 PM Ted Dunning <te...@gmail.com> wrote:
>
>> If the contribution is large enough to cause questions of authorship and
>> credit and copyright, then we should ask for a software Grant or a cla from
>> the contributor.
>>
>> On the other hand if the contribution is trivial, such as a spelling
>> correction, the no license of any sort is really needed.
>>
>> On Thu, Feb 28, 2019, 8:40 PM Alex Harui <ah...@adobe.com.invalid>
>> wrote:
>>
>>> Greg,
>>>
>>>
>>>
>>> I know the ASF won’t create a committer account without an ICLA, but for
>>> patches and pull requests, while some committer who signed an ICLA actually
>>> does the commit, it seems soft how the actual author of the PR granted
>>> license and permission to re-license.
>>>
>>>
>>>
>>> My 2 cents,
>>>
>>> -Alex
>>>
>>>
>>>
>>> *From: *Greg Stein <gs...@gmail.com>
>>> *Reply-To: *"legal-discuss@apache.org" <le...@apache.org>
>>> *Date: *Thursday, February 28, 2019 at 8:28 PM
>>> *To: *"legal-discuss@apache.org" <le...@apache.org>
>>> *Subject: *Re: R.Fontana argues to toss CLAs
>>>
>>>
>>>
>>> On Thu, Feb 28, 2019 at 9:31 PM Greg Stein <gs...@gmail.com> wrote:
>>>
>>> Richard just posted an article today about CLAs:
>>>
>>> https://opensource.com/article/19/2/cla-problems
>>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopensource.com%2Farticle%2F19%2F2%2Fcla-problems&data=02%7C01%7Caharui%40adobe.com%7C60e967f8a400409984ea08d69dfe614a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636870113231362749&sdata=049VC%2BBU3P%2FJnH2T6JqYYIHAm25OAWGIZeL6wW161ow%3D&reserved=0>
>>>
>>>
>>>
>>> Seems like a pretty fair treatment of CLAs in the F/OSS ecosystem.
>>>
>>>
>>>
>>> And I also read the linked articles about Harmony, CLA proliferation,
>>> and OpenStack's use of CLAs. Somewhere in there was an acknowledgement that
>>> the ASF has its charitable mission, which nicely constrains us from doing
>>> something evil with the CLAs' license grants. Thanks for highlighting that.
>>>
>>>
>>>
>>> In my mind, I think the CLA is most important for relicensing. Recall
>>> that we imposed the CLA requirement right around our release of ALv2 and
>>> subsequent relicensing of all of code distributions/releases under that new
>>> license. Yeah, that was near 15 years ago. But I foresee an ALv2.1 in the
>>> next decade, and we won't have to contact 10k committers to switch over to
>>> it.
>>>
>>>
>>>
>>> I think the second benefit is part of our legal shield. Now, maybe the
>>> shield doesn't work this way, but it seems the Foundation can make this
>>> argument: "Thanks for your contribution. Some time later, we will choose to
>>> put together a release, and the *Foundation* will take responsibility for
>>> everything included in that release." ... Sort of a cut-out, to shield the
>>> contributor from downstream liabilities. A lot of our structure (Board ->
>>> PMCs -> communities) is intended to create that cut-out, to shield
>>> committers. It seems that a license grant for the *Foundation* to make
>>> choices aids in that shield.
>>>
>>>
>>>
>>> The ALv2 kinda assumes inbound=outbound, and you [Richard] are right in
>>> that that is the most common community model. No argument there. I'm not
>>> sure if we could "return" to that model, given how I think we arrived at
>>> CLAs.
>>>
>>>
>>>
>>> And one small correction to, I think it was the OpenStack CLA wiki page.
>>> We require an ICLA from *all* people who wish to commit. We won't create an
>>> account without one. The CCLA is an *augment* to the ICLA, rather than a
>>> substitute. "Yes, they were allowed to sign the ICLA". That article states
>>> one or the other, but not both. We require one, optional for the other.
>>>
>>>
>>>
>>> Cheers,
>>>
>>> -g
>>>
>>>
>>>
>>
Re: R.Fontana argues to toss CLAs
Posted by Hen <ba...@apache.org>.
I disagree on details.
Your position implies we need to get a signed agreement on most
contributions. It's the same position that Richard is pointing out as a
problem.
In reality, we only get non-committers to sign a software grant of license,
or an ICLA/CCLA, for the largest contributions. There's a large amount of
copyrightable expression which is not covered by ICLA.
---
We receive an Apache License 2.0 on contributions. When it comes to
relicensing we have three classes of 'copyright' within the code:
1) Non-copyright. Things that were truly public domain, fair use, not
expressive etc.
2) Things that are licensed to the ASF under Apache License 2.0.
3) Things that are licensed to the ASF under ICLA (or software grant of
license, or CCLA).
There's nothing to license in #1. #3 gives us more scope to relicense. #2
is such that if anyone objects to our having relicensed, we can adjust back
to AL 2.0.
Hen
On Thu, Feb 28, 2019 at 9:13 PM Ted Dunning <te...@gmail.com> wrote:
> If the contribution is large enough to cause questions of authorship and
> credit and copyright, then we should ask for a software Grant or a cla from
> the contributor.
>
> On the other hand if the contribution is trivial, such as a spelling
> correction, the no license of any sort is really needed.
>
> On Thu, Feb 28, 2019, 8:40 PM Alex Harui <ah...@adobe.com.invalid> wrote:
>
>> Greg,
>>
>>
>>
>> I know the ASF won’t create a committer account without an ICLA, but for
>> patches and pull requests, while some committer who signed an ICLA actually
>> does the commit, it seems soft how the actual author of the PR granted
>> license and permission to re-license.
>>
>>
>>
>> My 2 cents,
>>
>> -Alex
>>
>>
>>
>> *From: *Greg Stein <gs...@gmail.com>
>> *Reply-To: *"legal-discuss@apache.org" <le...@apache.org>
>> *Date: *Thursday, February 28, 2019 at 8:28 PM
>> *To: *"legal-discuss@apache.org" <le...@apache.org>
>> *Subject: *Re: R.Fontana argues to toss CLAs
>>
>>
>>
>> On Thu, Feb 28, 2019 at 9:31 PM Greg Stein <gs...@gmail.com> wrote:
>>
>> Richard just posted an article today about CLAs:
>>
>> https://opensource.com/article/19/2/cla-problems
>> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopensource.com%2Farticle%2F19%2F2%2Fcla-problems&data=02%7C01%7Caharui%40adobe.com%7C60e967f8a400409984ea08d69dfe614a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636870113231362749&sdata=049VC%2BBU3P%2FJnH2T6JqYYIHAm25OAWGIZeL6wW161ow%3D&reserved=0>
>>
>>
>>
>> Seems like a pretty fair treatment of CLAs in the F/OSS ecosystem.
>>
>>
>>
>> And I also read the linked articles about Harmony, CLA proliferation, and
>> OpenStack's use of CLAs. Somewhere in there was an acknowledgement that the
>> ASF has its charitable mission, which nicely constrains us from doing
>> something evil with the CLAs' license grants. Thanks for highlighting that.
>>
>>
>>
>> In my mind, I think the CLA is most important for relicensing. Recall
>> that we imposed the CLA requirement right around our release of ALv2 and
>> subsequent relicensing of all of code distributions/releases under that new
>> license. Yeah, that was near 15 years ago. But I foresee an ALv2.1 in the
>> next decade, and we won't have to contact 10k committers to switch over to
>> it.
>>
>>
>>
>> I think the second benefit is part of our legal shield. Now, maybe the
>> shield doesn't work this way, but it seems the Foundation can make this
>> argument: "Thanks for your contribution. Some time later, we will choose to
>> put together a release, and the *Foundation* will take responsibility for
>> everything included in that release." ... Sort of a cut-out, to shield the
>> contributor from downstream liabilities. A lot of our structure (Board ->
>> PMCs -> communities) is intended to create that cut-out, to shield
>> committers. It seems that a license grant for the *Foundation* to make
>> choices aids in that shield.
>>
>>
>>
>> The ALv2 kinda assumes inbound=outbound, and you [Richard] are right in
>> that that is the most common community model. No argument there. I'm not
>> sure if we could "return" to that model, given how I think we arrived at
>> CLAs.
>>
>>
>>
>> And one small correction to, I think it was the OpenStack CLA wiki page.
>> We require an ICLA from *all* people who wish to commit. We won't create an
>> account without one. The CCLA is an *augment* to the ICLA, rather than a
>> substitute. "Yes, they were allowed to sign the ICLA". That article states
>> one or the other, but not both. We require one, optional for the other.
>>
>>
>>
>> Cheers,
>>
>> -g
>>
>>
>>
>
Re: R.Fontana argues to toss CLAs
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
Catching up (btw, I'm back from 30 days of business travel and
*really* planning to stay put for quite some time -- so you'll see
more of me starting from now ;-))
We've had this discussion multiple times in the past (on at least two
occasions me bing the originator of them). We seem to be coming up
with exactly the same kind of legal analysis every time, but the real
issue is always cultural.
At the same time, personally, I've sort of come around to appreciate
that cultural resistance myself. It basically is "if it ain't broken
-- don't fix it". And today I am hardpressed to see what the forcing
function here is that would make us go -- no it actually *is* broken.
The argument of how easy it is for developers to contribute gets
thrown around all the time -- but frankly, once you become a committer
in any of the ASF projects -- it never really comes up that much. And
for drive-by contributions -- you're not really required to do it.
Thanks,
Roman.
On Fri, Mar 1, 2019 at 10:23 AM Ted Dunning <te...@gmail.com> wrote:
>
>
> The linked text of the sample DCO from the article looks like a very nice form of CLA, frankly. Requiring that on every commit is very nice from the risk point of view unless there is an issue of committer fatigue (i.e. that people start auto-clicking on the form and forget the point).
>
>
>
> On Fri, Mar 1, 2019 at 12:54 AM Greg Stein <gs...@gmail.com> wrote:
>>
>> If that's your concern, then I'd point out that the DCO on each commit reinforces that *very* well.
>>
>> On Fri, Mar 1, 2019 at 2:52 AM Mark Thomas <ma...@apache.org> wrote:
>>>
>>> I'd argue that from a purely legal perspective, the ALv2 gives us
>>> everything we need - particularly section 5.
>>>
>>> I view the main purpose of the ICLA to make folks (more) aware that they
>>> have a responsibility to ensure that they are legally entitled to make
>>> each contribution. I don't think the ICLA changes the legal
>>> responsibility but I do think it highlights to new committers that the
>>> responsibility exists.
>>>
>>> Mark
>>>
>>>
>>> On 01/03/2019 05:13, Ted Dunning wrote:
>>> > If the contribution is large enough to cause questions of authorship and
>>> > credit and copyright, then we should ask for a software Grant or a cla
>>> > from the contributor.
>>> >
>>> > On the other hand if the contribution is trivial, such as a spelling
>>> > correction, the no license of any sort is really needed.
>>> >
>>> > On Thu, Feb 28, 2019, 8:40 PM Alex Harui <ah...@adobe.com.invalid> wrote:
>>> >
>>> > Greg,____
>>> >
>>> > __ __
>>> >
>>> > I know the ASF won’t create a committer account without an ICLA, but
>>> > for patches and pull requests, while some committer who signed an
>>> > ICLA actually does the commit, it seems soft how the actual author
>>> > of the PR granted license and permission to re-license.____
>>> >
>>> > __ __
>>> >
>>> > My 2 cents,____
>>> >
>>> > -Alex____
>>> >
>>> > __ __
>>> >
>>> > *From: *Greg Stein <gstein@gmail.com <ma...@gmail.com>>
>>> > *Reply-To: *"legal-discuss@apache.org
>>> > <ma...@apache.org>" <legal-discuss@apache.org
>>> > <ma...@apache.org>>
>>> > *Date: *Thursday, February 28, 2019 at 8:28 PM
>>> > *To: *"legal-discuss@apache.org <ma...@apache.org>"
>>> > <legal-discuss@apache.org <ma...@apache.org>>
>>> > *Subject: *Re: R.Fontana argues to toss CLAs____
>>> >
>>> > __ __
>>> >
>>> > On Thu, Feb 28, 2019 at 9:31 PM Greg Stein <gstein@gmail.com
>>> > <ma...@gmail.com>> wrote:____
>>> >
>>> > Richard just posted an article today about CLAs: ____
>>> >
>>> > https://opensource.com/article/19/2/cla-problems
>>> > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopensource.com%2Farticle%2F19%2F2%2Fcla-problems&data=02%7C01%7Caharui%40adobe.com%7C60e967f8a400409984ea08d69dfe614a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636870113231362749&sdata=049VC%2BBU3P%2FJnH2T6JqYYIHAm25OAWGIZeL6wW161ow%3D&reserved=0>____
>>> >
>>> > __ __
>>> >
>>> > Seems like a pretty fair treatment of CLAs in the F/OSS
>>> > ecosystem.____
>>> >
>>> > __ __
>>> >
>>> > And I also read the linked articles about Harmony, CLA
>>> > proliferation, and OpenStack's use of CLAs. Somewhere in there was
>>> > an acknowledgement that the ASF has its charitable mission, which
>>> > nicely constrains us from doing something evil with the CLAs'
>>> > license grants. Thanks for highlighting that.____
>>> >
>>> > __ __
>>> >
>>> > In my mind, I think the CLA is most important for relicensing.
>>> > Recall that we imposed the CLA requirement right around our release
>>> > of ALv2 and subsequent relicensing of all of code
>>> > distributions/releases under that new license. Yeah, that was near
>>> > 15 years ago. But I foresee an ALv2.1 in the next decade, and we
>>> > won't have to contact 10k committers to switch over to it.____
>>> >
>>> > __ __
>>> >
>>> > I think the second benefit is part of our legal shield. Now, maybe
>>> > the shield doesn't work this way, but it seems the Foundation can
>>> > make this argument: "Thanks for your contribution. Some time later,
>>> > we will choose to put together a release, and the *Foundation* will
>>> > take responsibility for everything included in that release." ...
>>> > Sort of a cut-out, to shield the contributor from downstream
>>> > liabilities. A lot of our structure (Board -> PMCs -> communities)
>>> > is intended to create that cut-out, to shield committers. It seems
>>> > that a license grant for the *Foundation* to make choices aids in
>>> > that shield.____
>>> >
>>> > __ __
>>> >
>>> > The ALv2 kinda assumes inbound=outbound, and you [Richard] are right
>>> > in that that is the most common community model. No argument there.
>>> > I'm not sure if we could "return" to that model, given how I think
>>> > we arrived at CLAs.____
>>> >
>>> > __ __
>>> >
>>> > And one small correction to, I think it was the OpenStack CLA wiki
>>> > page. We require an ICLA from *all* people who wish to commit. We
>>> > won't create an account without one. The CCLA is an *augment* to the
>>> > ICLA, rather than a substitute. "Yes, they were allowed to sign the
>>> > ICLA". That article states one or the other, but not both. We
>>> > require one, optional for the other.____
>>> >
>>> > __ __
>>> >
>>> > Cheers,____
>>> >
>>> > -g____
>>> >
>>> > __ __
>>> >
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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: R.Fontana argues to toss CLAs
Posted by Ted Dunning <te...@gmail.com>.
The linked text of the sample DCO from the article looks like a very nice
form of CLA, frankly. Requiring that on every commit is very nice from the
risk point of view unless there is an issue of committer fatigue (i.e. that
people start auto-clicking on the form and forget the point).
On Fri, Mar 1, 2019 at 12:54 AM Greg Stein <gs...@gmail.com> wrote:
> If that's your concern, then I'd point out that the DCO on each commit
> reinforces that *very* well.
>
> On Fri, Mar 1, 2019 at 2:52 AM Mark Thomas <ma...@apache.org> wrote:
>
>> I'd argue that from a purely legal perspective, the ALv2 gives us
>> everything we need - particularly section 5.
>>
>> I view the main purpose of the ICLA to make folks (more) aware that they
>> have a responsibility to ensure that they are legally entitled to make
>> each contribution. I don't think the ICLA changes the legal
>> responsibility but I do think it highlights to new committers that the
>> responsibility exists.
>>
>> Mark
>>
>>
>> On 01/03/2019 05:13, Ted Dunning wrote:
>> > If the contribution is large enough to cause questions of authorship and
>> > credit and copyright, then we should ask for a software Grant or a cla
>> > from the contributor.
>> >
>> > On the other hand if the contribution is trivial, such as a spelling
>> > correction, the no license of any sort is really needed.
>> >
>> > On Thu, Feb 28, 2019, 8:40 PM Alex Harui <ah...@adobe.com.invalid>
>> wrote:
>> >
>> > Greg,____
>> >
>> > __ __
>> >
>> > I know the ASF won’t create a committer account without an ICLA, but
>> > for patches and pull requests, while some committer who signed an
>> > ICLA actually does the commit, it seems soft how the actual author
>> > of the PR granted license and permission to re-license.____
>> >
>> > __ __
>> >
>> > My 2 cents,____
>> >
>> > -Alex____
>> >
>> > __ __
>> >
>> > *From: *Greg Stein <gstein@gmail.com <ma...@gmail.com>>
>> > *Reply-To: *"legal-discuss@apache.org
>> > <ma...@apache.org>" <legal-discuss@apache.org
>> > <ma...@apache.org>>
>> > *Date: *Thursday, February 28, 2019 at 8:28 PM
>> > *To: *"legal-discuss@apache.org <ma...@apache.org>"
>> > <legal-discuss@apache.org <ma...@apache.org>>
>> > *Subject: *Re: R.Fontana argues to toss CLAs____
>> >
>> > __ __
>> >
>> > On Thu, Feb 28, 2019 at 9:31 PM Greg Stein <gstein@gmail.com
>> > <ma...@gmail.com>> wrote:____
>> >
>> > Richard just posted an article today about CLAs: ____
>> >
>> > https://opensource.com/article/19/2/cla-problems
>> > <
>> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopensource.com%2Farticle%2F19%2F2%2Fcla-problems&data=02%7C01%7Caharui%40adobe.com%7C60e967f8a400409984ea08d69dfe614a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636870113231362749&sdata=049VC%2BBU3P%2FJnH2T6JqYYIHAm25OAWGIZeL6wW161ow%3D&reserved=0
>> >____
>> >
>> > __ __
>> >
>> > Seems like a pretty fair treatment of CLAs in the F/OSS
>> > ecosystem.____
>> >
>> > __ __
>> >
>> > And I also read the linked articles about Harmony, CLA
>> > proliferation, and OpenStack's use of CLAs. Somewhere in there was
>> > an acknowledgement that the ASF has its charitable mission, which
>> > nicely constrains us from doing something evil with the CLAs'
>> > license grants. Thanks for highlighting that.____
>> >
>> > __ __
>> >
>> > In my mind, I think the CLA is most important for relicensing.
>> > Recall that we imposed the CLA requirement right around our release
>> > of ALv2 and subsequent relicensing of all of code
>> > distributions/releases under that new license. Yeah, that was near
>> > 15 years ago. But I foresee an ALv2.1 in the next decade, and we
>> > won't have to contact 10k committers to switch over to it.____
>> >
>> > __ __
>> >
>> > I think the second benefit is part of our legal shield. Now, maybe
>> > the shield doesn't work this way, but it seems the Foundation can
>> > make this argument: "Thanks for your contribution. Some time later,
>> > we will choose to put together a release, and the *Foundation* will
>> > take responsibility for everything included in that release." ...
>> > Sort of a cut-out, to shield the contributor from downstream
>> > liabilities. A lot of our structure (Board -> PMCs -> communities)
>> > is intended to create that cut-out, to shield committers. It seems
>> > that a license grant for the *Foundation* to make choices aids in
>> > that shield.____
>> >
>> > __ __
>> >
>> > The ALv2 kinda assumes inbound=outbound, and you [Richard] are right
>> > in that that is the most common community model. No argument there.
>> > I'm not sure if we could "return" to that model, given how I think
>> > we arrived at CLAs.____
>> >
>> > __ __
>> >
>> > And one small correction to, I think it was the OpenStack CLA wiki
>> > page. We require an ICLA from *all* people who wish to commit. We
>> > won't create an account without one. The CCLA is an *augment* to the
>> > ICLA, rather than a substitute. "Yes, they were allowed to sign the
>> > ICLA". That article states one or the other, but not both. We
>> > require one, optional for the other.____
>> >
>> > __ __
>> >
>> > Cheers,____
>> >
>> > -g____
>> >
>> > __ __
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>>
Re: R.Fontana argues to toss CLAs
Posted by Greg Stein <gs...@gmail.com>.
If that's your concern, then I'd point out that the DCO on each commit
reinforces that *very* well.
On Fri, Mar 1, 2019 at 2:52 AM Mark Thomas <ma...@apache.org> wrote:
> I'd argue that from a purely legal perspective, the ALv2 gives us
> everything we need - particularly section 5.
>
> I view the main purpose of the ICLA to make folks (more) aware that they
> have a responsibility to ensure that they are legally entitled to make
> each contribution. I don't think the ICLA changes the legal
> responsibility but I do think it highlights to new committers that the
> responsibility exists.
>
> Mark
>
>
> On 01/03/2019 05:13, Ted Dunning wrote:
> > If the contribution is large enough to cause questions of authorship and
> > credit and copyright, then we should ask for a software Grant or a cla
> > from the contributor.
> >
> > On the other hand if the contribution is trivial, such as a spelling
> > correction, the no license of any sort is really needed.
> >
> > On Thu, Feb 28, 2019, 8:40 PM Alex Harui <ah...@adobe.com.invalid>
> wrote:
> >
> > Greg,____
> >
> > __ __
> >
> > I know the ASF won’t create a committer account without an ICLA, but
> > for patches and pull requests, while some committer who signed an
> > ICLA actually does the commit, it seems soft how the actual author
> > of the PR granted license and permission to re-license.____
> >
> > __ __
> >
> > My 2 cents,____
> >
> > -Alex____
> >
> > __ __
> >
> > *From: *Greg Stein <gstein@gmail.com <ma...@gmail.com>>
> > *Reply-To: *"legal-discuss@apache.org
> > <ma...@apache.org>" <legal-discuss@apache.org
> > <ma...@apache.org>>
> > *Date: *Thursday, February 28, 2019 at 8:28 PM
> > *To: *"legal-discuss@apache.org <ma...@apache.org>"
> > <legal-discuss@apache.org <ma...@apache.org>>
> > *Subject: *Re: R.Fontana argues to toss CLAs____
> >
> > __ __
> >
> > On Thu, Feb 28, 2019 at 9:31 PM Greg Stein <gstein@gmail.com
> > <ma...@gmail.com>> wrote:____
> >
> > Richard just posted an article today about CLAs: ____
> >
> > https://opensource.com/article/19/2/cla-problems
> > <
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopensource.com%2Farticle%2F19%2F2%2Fcla-problems&data=02%7C01%7Caharui%40adobe.com%7C60e967f8a400409984ea08d69dfe614a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636870113231362749&sdata=049VC%2BBU3P%2FJnH2T6JqYYIHAm25OAWGIZeL6wW161ow%3D&reserved=0
> >____
> >
> > __ __
> >
> > Seems like a pretty fair treatment of CLAs in the F/OSS
> > ecosystem.____
> >
> > __ __
> >
> > And I also read the linked articles about Harmony, CLA
> > proliferation, and OpenStack's use of CLAs. Somewhere in there was
> > an acknowledgement that the ASF has its charitable mission, which
> > nicely constrains us from doing something evil with the CLAs'
> > license grants. Thanks for highlighting that.____
> >
> > __ __
> >
> > In my mind, I think the CLA is most important for relicensing.
> > Recall that we imposed the CLA requirement right around our release
> > of ALv2 and subsequent relicensing of all of code
> > distributions/releases under that new license. Yeah, that was near
> > 15 years ago. But I foresee an ALv2.1 in the next decade, and we
> > won't have to contact 10k committers to switch over to it.____
> >
> > __ __
> >
> > I think the second benefit is part of our legal shield. Now, maybe
> > the shield doesn't work this way, but it seems the Foundation can
> > make this argument: "Thanks for your contribution. Some time later,
> > we will choose to put together a release, and the *Foundation* will
> > take responsibility for everything included in that release." ...
> > Sort of a cut-out, to shield the contributor from downstream
> > liabilities. A lot of our structure (Board -> PMCs -> communities)
> > is intended to create that cut-out, to shield committers. It seems
> > that a license grant for the *Foundation* to make choices aids in
> > that shield.____
> >
> > __ __
> >
> > The ALv2 kinda assumes inbound=outbound, and you [Richard] are right
> > in that that is the most common community model. No argument there.
> > I'm not sure if we could "return" to that model, given how I think
> > we arrived at CLAs.____
> >
> > __ __
> >
> > And one small correction to, I think it was the OpenStack CLA wiki
> > page. We require an ICLA from *all* people who wish to commit. We
> > won't create an account without one. The CCLA is an *augment* to the
> > ICLA, rather than a substitute. "Yes, they were allowed to sign the
> > ICLA". That article states one or the other, but not both. We
> > require one, optional for the other.____
> >
> > __ __
> >
> > Cheers,____
> >
> > -g____
> >
> > __ __
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
>
Re: R.Fontana argues to toss CLAs
Posted by Mark Thomas <ma...@apache.org>.
I'd argue that from a purely legal perspective, the ALv2 gives us
everything we need - particularly section 5.
I view the main purpose of the ICLA to make folks (more) aware that they
have a responsibility to ensure that they are legally entitled to make
each contribution. I don't think the ICLA changes the legal
responsibility but I do think it highlights to new committers that the
responsibility exists.
Mark
On 01/03/2019 05:13, Ted Dunning wrote:
> If the contribution is large enough to cause questions of authorship and
> credit and copyright, then we should ask for a software Grant or a cla
> from the contributor.
>
> On the other hand if the contribution is trivial, such as a spelling
> correction, the no license of any sort is really needed.
>
> On Thu, Feb 28, 2019, 8:40 PM Alex Harui <ah...@adobe.com.invalid> wrote:
>
> Greg,____
>
> __ __
>
> I know the ASF won’t create a committer account without an ICLA, but
> for patches and pull requests, while some committer who signed an
> ICLA actually does the commit, it seems soft how the actual author
> of the PR granted license and permission to re-license.____
>
> __ __
>
> My 2 cents,____
>
> -Alex____
>
> __ __
>
> *From: *Greg Stein <gstein@gmail.com <ma...@gmail.com>>
> *Reply-To: *"legal-discuss@apache.org
> <ma...@apache.org>" <legal-discuss@apache.org
> <ma...@apache.org>>
> *Date: *Thursday, February 28, 2019 at 8:28 PM
> *To: *"legal-discuss@apache.org <ma...@apache.org>"
> <legal-discuss@apache.org <ma...@apache.org>>
> *Subject: *Re: R.Fontana argues to toss CLAs____
>
> __ __
>
> On Thu, Feb 28, 2019 at 9:31 PM Greg Stein <gstein@gmail.com
> <ma...@gmail.com>> wrote:____
>
> Richard just posted an article today about CLAs: ____
>
> https://opensource.com/article/19/2/cla-problems
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopensource.com%2Farticle%2F19%2F2%2Fcla-problems&data=02%7C01%7Caharui%40adobe.com%7C60e967f8a400409984ea08d69dfe614a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636870113231362749&sdata=049VC%2BBU3P%2FJnH2T6JqYYIHAm25OAWGIZeL6wW161ow%3D&reserved=0>____
>
> __ __
>
> Seems like a pretty fair treatment of CLAs in the F/OSS
> ecosystem.____
>
> __ __
>
> And I also read the linked articles about Harmony, CLA
> proliferation, and OpenStack's use of CLAs. Somewhere in there was
> an acknowledgement that the ASF has its charitable mission, which
> nicely constrains us from doing something evil with the CLAs'
> license grants. Thanks for highlighting that.____
>
> __ __
>
> In my mind, I think the CLA is most important for relicensing.
> Recall that we imposed the CLA requirement right around our release
> of ALv2 and subsequent relicensing of all of code
> distributions/releases under that new license. Yeah, that was near
> 15 years ago. But I foresee an ALv2.1 in the next decade, and we
> won't have to contact 10k committers to switch over to it.____
>
> __ __
>
> I think the second benefit is part of our legal shield. Now, maybe
> the shield doesn't work this way, but it seems the Foundation can
> make this argument: "Thanks for your contribution. Some time later,
> we will choose to put together a release, and the *Foundation* will
> take responsibility for everything included in that release." ...
> Sort of a cut-out, to shield the contributor from downstream
> liabilities. A lot of our structure (Board -> PMCs -> communities)
> is intended to create that cut-out, to shield committers. It seems
> that a license grant for the *Foundation* to make choices aids in
> that shield.____
>
> __ __
>
> The ALv2 kinda assumes inbound=outbound, and you [Richard] are right
> in that that is the most common community model. No argument there.
> I'm not sure if we could "return" to that model, given how I think
> we arrived at CLAs.____
>
> __ __
>
> And one small correction to, I think it was the OpenStack CLA wiki
> page. We require an ICLA from *all* people who wish to commit. We
> won't create an account without one. The CCLA is an *augment* to the
> ICLA, rather than a substitute. "Yes, they were allowed to sign the
> ICLA". That article states one or the other, but not both. We
> require one, optional for the other.____
>
> __ __
>
> Cheers,____
>
> -g____
>
> __ __
>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: R.Fontana argues to toss CLAs
Posted by Ted Dunning <te...@gmail.com>.
If the contribution is large enough to cause questions of authorship and
credit and copyright, then we should ask for a software Grant or a cla from
the contributor.
On the other hand if the contribution is trivial, such as a spelling
correction, the no license of any sort is really needed.
On Thu, Feb 28, 2019, 8:40 PM Alex Harui <ah...@adobe.com.invalid> wrote:
> Greg,
>
>
>
> I know the ASF won’t create a committer account without an ICLA, but for
> patches and pull requests, while some committer who signed an ICLA actually
> does the commit, it seems soft how the actual author of the PR granted
> license and permission to re-license.
>
>
>
> My 2 cents,
>
> -Alex
>
>
>
> *From: *Greg Stein <gs...@gmail.com>
> *Reply-To: *"legal-discuss@apache.org" <le...@apache.org>
> *Date: *Thursday, February 28, 2019 at 8:28 PM
> *To: *"legal-discuss@apache.org" <le...@apache.org>
> *Subject: *Re: R.Fontana argues to toss CLAs
>
>
>
> On Thu, Feb 28, 2019 at 9:31 PM Greg Stein <gs...@gmail.com> wrote:
>
> Richard just posted an article today about CLAs:
>
> https://opensource.com/article/19/2/cla-problems
> <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopensource.com%2Farticle%2F19%2F2%2Fcla-problems&data=02%7C01%7Caharui%40adobe.com%7C60e967f8a400409984ea08d69dfe614a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636870113231362749&sdata=049VC%2BBU3P%2FJnH2T6JqYYIHAm25OAWGIZeL6wW161ow%3D&reserved=0>
>
>
>
> Seems like a pretty fair treatment of CLAs in the F/OSS ecosystem.
>
>
>
> And I also read the linked articles about Harmony, CLA proliferation, and
> OpenStack's use of CLAs. Somewhere in there was an acknowledgement that the
> ASF has its charitable mission, which nicely constrains us from doing
> something evil with the CLAs' license grants. Thanks for highlighting that.
>
>
>
> In my mind, I think the CLA is most important for relicensing. Recall that
> we imposed the CLA requirement right around our release of ALv2 and
> subsequent relicensing of all of code distributions/releases under that new
> license. Yeah, that was near 15 years ago. But I foresee an ALv2.1 in the
> next decade, and we won't have to contact 10k committers to switch over to
> it.
>
>
>
> I think the second benefit is part of our legal shield. Now, maybe the
> shield doesn't work this way, but it seems the Foundation can make this
> argument: "Thanks for your contribution. Some time later, we will choose to
> put together a release, and the *Foundation* will take responsibility for
> everything included in that release." ... Sort of a cut-out, to shield the
> contributor from downstream liabilities. A lot of our structure (Board ->
> PMCs -> communities) is intended to create that cut-out, to shield
> committers. It seems that a license grant for the *Foundation* to make
> choices aids in that shield.
>
>
>
> The ALv2 kinda assumes inbound=outbound, and you [Richard] are right in
> that that is the most common community model. No argument there. I'm not
> sure if we could "return" to that model, given how I think we arrived at
> CLAs.
>
>
>
> And one small correction to, I think it was the OpenStack CLA wiki page.
> We require an ICLA from *all* people who wish to commit. We won't create an
> account without one. The CCLA is an *augment* to the ICLA, rather than a
> substitute. "Yes, they were allowed to sign the ICLA". That article states
> one or the other, but not both. We require one, optional for the other.
>
>
>
> Cheers,
>
> -g
>
>
>
Re: R.Fontana argues to toss CLAs
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Greg,
I know the ASF won’t create a committer account without an ICLA, but for patches and pull requests, while some committer who signed an ICLA actually does the commit, it seems soft how the actual author of the PR granted license and permission to re-license.
My 2 cents,
-Alex
From: Greg Stein <gs...@gmail.com>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Thursday, February 28, 2019 at 8:28 PM
To: "legal-discuss@apache.org" <le...@apache.org>
Subject: Re: R.Fontana argues to toss CLAs
On Thu, Feb 28, 2019 at 9:31 PM Greg Stein <gs...@gmail.com>> wrote:
Richard just posted an article today about CLAs:
https://opensource.com/article/19/2/cla-problems<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopensource.com%2Farticle%2F19%2F2%2Fcla-problems&data=02%7C01%7Caharui%40adobe.com%7C60e967f8a400409984ea08d69dfe614a%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636870113231362749&sdata=049VC%2BBU3P%2FJnH2T6JqYYIHAm25OAWGIZeL6wW161ow%3D&reserved=0>
Seems like a pretty fair treatment of CLAs in the F/OSS ecosystem.
And I also read the linked articles about Harmony, CLA proliferation, and OpenStack's use of CLAs. Somewhere in there was an acknowledgement that the ASF has its charitable mission, which nicely constrains us from doing something evil with the CLAs' license grants. Thanks for highlighting that.
In my mind, I think the CLA is most important for relicensing. Recall that we imposed the CLA requirement right around our release of ALv2 and subsequent relicensing of all of code distributions/releases under that new license. Yeah, that was near 15 years ago. But I foresee an ALv2.1 in the next decade, and we won't have to contact 10k committers to switch over to it.
I think the second benefit is part of our legal shield. Now, maybe the shield doesn't work this way, but it seems the Foundation can make this argument: "Thanks for your contribution. Some time later, we will choose to put together a release, and the *Foundation* will take responsibility for everything included in that release." ... Sort of a cut-out, to shield the contributor from downstream liabilities. A lot of our structure (Board -> PMCs -> communities) is intended to create that cut-out, to shield committers. It seems that a license grant for the *Foundation* to make choices aids in that shield.
The ALv2 kinda assumes inbound=outbound, and you [Richard] are right in that that is the most common community model. No argument there. I'm not sure if we could "return" to that model, given how I think we arrived at CLAs.
And one small correction to, I think it was the OpenStack CLA wiki page. We require an ICLA from *all* people who wish to commit. We won't create an account without one. The CCLA is an *augment* to the ICLA, rather than a substitute. "Yes, they were allowed to sign the ICLA". That article states one or the other, but not both. We require one, optional for the other.
Cheers,
-g
Re: R.Fontana argues to toss CLAs
Posted by Hen <ba...@apache.org>.
Sidenote:
I always find it curious that becoming a committer involves signing an
agreement solely to do with IP, and one that wasn't needed for the previous
'year' of contributions; yet we don't sign any agreement related to the
part we play in acting on behalf of the foundation. No agreement for PMC
Members, no agreement for Members, nothing for VPs or Directors.
Hen
On Thu, Feb 28, 2019 at 9:32 PM Hen <ba...@apache.org> wrote:
>
>
> On Thu, Feb 28, 2019 at 8:28 PM Greg Stein <gs...@gmail.com> wrote:
>
>> On Thu, Feb 28, 2019 at 9:31 PM Greg Stein <gs...@gmail.com> wrote:
>>
>>> Richard just posted an article today about CLAs:
>>> https://opensource.com/article/19/2/cla-problems
>>>
>>> Seems like a pretty fair treatment of CLAs in the F/OSS ecosystem.
>>>
>>
>> And I also read the linked articles about Harmony, CLA proliferation, and
>> OpenStack's use of CLAs. Somewhere in there was an acknowledgement that the
>> ASF has its charitable mission, which nicely constrains us from doing
>> something evil with the CLAs' license grants. Thanks for highlighting that.
>>
>> In my mind, I think the CLA is most important for relicensing. Recall
>> that we imposed the CLA requirement right around our release of ALv2 and
>> subsequent relicensing of all of code distributions/releases under that new
>> license. Yeah, that was near 15 years ago. But I foresee an ALv2.1 in the
>> next decade, and we won't have to contact 10k committers to switch over to
>> it.
>>
>
> I'm going to somewhat agree.
>
> A 'condition-free-inbound-agreement' is needed for relicensing. A signed
> agreement isn't.
>
> The ICLA is basically Apache 2.0 without the licensing conditions. I think
> we can ditch CLAs by fixing section 5 of AL 2.0.
>
> Let's imagine that Apache 2.1 looks like this:
>
> Part 1. Outbound copyright and patent grants.
> Part 2. Conditions.
> Part 3. 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 __PART_ONE__ of
> this License, without any additional terms or conditions. "
>
> Then we can do away with the CLAs with respect to relicensing.
>
> We might go DCO (though without the weak cultural-assumption of Signed-by)
> inasmuch as we could have statements in patches/contributions of "I confirm
> I contribute this under Part 3 of the Apache License 2.1", however that's a
> pain to implement in every arena (email lists?) and we'd have to think it
> was required. I guess it's possible that someone can contribute to a
> project without ever having accepted the agreement, so more active
> confirmations could avoid a convoluted poison attempt.
>
>
>>
>> I think the second benefit is part of our legal shield. Now, maybe the
>> shield doesn't work this way, but it seems the Foundation can make this
>> argument: "Thanks for your contribution. Some time later, we will choose to
>> put together a release, and the *Foundation* will take responsibility for
>> everything included in that release." ... Sort of a cut-out, to shield the
>> contributor from downstream liabilities. A lot of our structure (Board ->
>> PMCs -> communities) is intended to create that cut-out, to shield
>> committers. It seems that a license grant for the *Foundation* to make
>> choices aids in that shield.
>>
>
> Great statement; I don't think the CLA adds to that. I think we shield
> contributors and committers equally; the only unequal part is that the
> committer commits more and thus is shielded more often.
>
>
>>
>> The ALv2 kinda assumes inbound=outbound,
>>
>
> Outright states it :)
>
>
>> and you [Richard] are right in that that is the most common community
>> model.
>>
>
> Most models were unstated; at least until GitHub baked inbound/outbound
> into their terms.
>
>
>> No argument there. I'm not sure if we could "return" to that model, given
>> how I think we arrived at CLAs.
>>
>
> I think the greatest thing blocking us is probably the inertia of a
> culture bred on CLAs. It'll be heresy to consider ripping them up.
>
> Hen
>
Re: R.Fontana argues to toss CLAs
Posted by Hen <ba...@apache.org>.
On Thu, Feb 28, 2019 at 8:28 PM Greg Stein <gs...@gmail.com> wrote:
> On Thu, Feb 28, 2019 at 9:31 PM Greg Stein <gs...@gmail.com> wrote:
>
>> Richard just posted an article today about CLAs:
>> https://opensource.com/article/19/2/cla-problems
>>
>> Seems like a pretty fair treatment of CLAs in the F/OSS ecosystem.
>>
>
> And I also read the linked articles about Harmony, CLA proliferation, and
> OpenStack's use of CLAs. Somewhere in there was an acknowledgement that the
> ASF has its charitable mission, which nicely constrains us from doing
> something evil with the CLAs' license grants. Thanks for highlighting that.
>
> In my mind, I think the CLA is most important for relicensing. Recall that
> we imposed the CLA requirement right around our release of ALv2 and
> subsequent relicensing of all of code distributions/releases under that new
> license. Yeah, that was near 15 years ago. But I foresee an ALv2.1 in the
> next decade, and we won't have to contact 10k committers to switch over to
> it.
>
I'm going to somewhat agree.
A 'condition-free-inbound-agreement' is needed for relicensing. A signed
agreement isn't.
The ICLA is basically Apache 2.0 without the licensing conditions. I think
we can ditch CLAs by fixing section 5 of AL 2.0.
Let's imagine that Apache 2.1 looks like this:
Part 1. Outbound copyright and patent grants.
Part 2. Conditions.
Part 3. 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 __PART_ONE__ of
this License, without any additional terms or conditions. "
Then we can do away with the CLAs with respect to relicensing.
We might go DCO (though without the weak cultural-assumption of Signed-by)
inasmuch as we could have statements in patches/contributions of "I confirm
I contribute this under Part 3 of the Apache License 2.1", however that's a
pain to implement in every arena (email lists?) and we'd have to think it
was required. I guess it's possible that someone can contribute to a
project without ever having accepted the agreement, so more active
confirmations could avoid a convoluted poison attempt.
>
> I think the second benefit is part of our legal shield. Now, maybe the
> shield doesn't work this way, but it seems the Foundation can make this
> argument: "Thanks for your contribution. Some time later, we will choose to
> put together a release, and the *Foundation* will take responsibility for
> everything included in that release." ... Sort of a cut-out, to shield the
> contributor from downstream liabilities. A lot of our structure (Board ->
> PMCs -> communities) is intended to create that cut-out, to shield
> committers. It seems that a license grant for the *Foundation* to make
> choices aids in that shield.
>
Great statement; I don't think the CLA adds to that. I think we shield
contributors and committers equally; the only unequal part is that the
committer commits more and thus is shielded more often.
>
> The ALv2 kinda assumes inbound=outbound,
>
Outright states it :)
> and you [Richard] are right in that that is the most common community
> model.
>
Most models were unstated; at least until GitHub baked inbound/outbound
into their terms.
> No argument there. I'm not sure if we could "return" to that model, given
> how I think we arrived at CLAs.
>
I think the greatest thing blocking us is probably the inertia of a culture
bred on CLAs. It'll be heresy to consider ripping them up.
Hen
Re: R.Fontana argues to toss CLAs
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Feb 28, 2019 at 9:31 PM Greg Stein <gs...@gmail.com> wrote:
> Richard just posted an article today about CLAs:
> https://opensource.com/article/19/2/cla-problems
>
> Seems like a pretty fair treatment of CLAs in the F/OSS ecosystem.
>
And I also read the linked articles about Harmony, CLA proliferation, and
OpenStack's use of CLAs. Somewhere in there was an acknowledgement that the
ASF has its charitable mission, which nicely constrains us from doing
something evil with the CLAs' license grants. Thanks for highlighting that.
In my mind, I think the CLA is most important for relicensing. Recall that
we imposed the CLA requirement right around our release of ALv2 and
subsequent relicensing of all of code distributions/releases under that new
license. Yeah, that was near 15 years ago. But I foresee an ALv2.1 in the
next decade, and we won't have to contact 10k committers to switch over to
it.
I think the second benefit is part of our legal shield. Now, maybe the
shield doesn't work this way, but it seems the Foundation can make this
argument: "Thanks for your contribution. Some time later, we will choose to
put together a release, and the *Foundation* will take responsibility for
everything included in that release." ... Sort of a cut-out, to shield the
contributor from downstream liabilities. A lot of our structure (Board ->
PMCs -> communities) is intended to create that cut-out, to shield
committers. It seems that a license grant for the *Foundation* to make
choices aids in that shield.
The ALv2 kinda assumes inbound=outbound, and you [Richard] are right in
that that is the most common community model. No argument there. I'm not
sure if we could "return" to that model, given how I think we arrived at
CLAs.
And one small correction to, I think it was the OpenStack CLA wiki page. We
require an ICLA from *all* people who wish to commit. We won't create an
account without one. The CCLA is an *augment* to the ICLA, rather than a
substitute. "Yes, they were allowed to sign the ICLA". That article states
one or the other, but not both. We require one, optional for the other.
Cheers,
-g