You are viewing a plain text version of this content. The canonical link for it is here.
Posted to legal-discuss@apache.org by Henri Yandell <ba...@apache.org> on 2017/10/02 04:25:23 UTC
Podling CLA/Grant advice
Hi Legal list,
One of the Incubator check-list items states:
"Check and make sure that the papers that transfer rights to the ASF been
received. It is only necessary to transfer rights for the package, the core
code, and any new code produced by the project. "
When a project is coming from a single contributor (such as a company),
this is handled by a software grant.
When a project already exists and is relicensing, this is 'fun' and
involves a lot of CLA signing (in essence to get permission to relicense to
the Apache 2.0 licence).
When a project is an already existing project _AND_ is already/has always
been under the Apache 2.0 license, how should this be handled?
Specifically I am looking at Apache MXNet. There are 400+ contributors. The
existing and new committers have all signed ICLAs. Who else among the ~380
remaining contributors need to sign ICLA/grants? And what reason do we give
to them when asking them to sign the ICLA/grant given that the code isn't
being relicensed?
Thanks,
Hen
Re: Podling CLA/Grant advice
Posted by Craig Russell <ap...@gmail.com>.
Hi Roman,
> On Oct 2, 2017, at 8:56 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Sun, Oct 1, 2017 at 9:40 PM, Chris Mattmann <ma...@apache.org> wrote:
>> If the PMC and committers have ICLAs on file, then depending on the size of
>> the contribution, and
>> how it was made will determine how many of those need to have ICLAs on file.
>> The more the merrier,
>> but also within reason. If someone comes along later, and says we don’t want
>> code X, Y or Z in our
>> project b/c I contributed, and didn’t sign an ICLA then we take it out, and
>> move on.
>
> Ok, I must admit I'm confused. The text of the ICLA starts with:
>
> "You accept and agree to the following terms and conditions for Your
> present and future Contributions submitted to the Foundation."
>
> If the contribution wasn't submitted to the foundation, but rather was submitted
> to the GitHub project it seems that a signed ICLA with ASF won't be sufficient
> to cover IP that was developed on the GitHub.
>
> Am I missing something?
I have always interpreted "present and future Contributions" as meaning the contribution to the new podling being "present" and contributions as a committer once the code is being worked on at Apache as "future".
So an ICLA is sufficient for a contributor (in the past) who is presently contributing the code/doc/test to be worked on at Apache.
A software grant covers the case where a contributor does not intend to continue on the project.
Craig
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> 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: Podling CLA/Grant advice
Posted by Chris Mattmann <ma...@apache.org>.
Hey Craig,
FWIW, time (with no response) is a sufficient justification to terminate parental
custody in child adoption cases (many times the adoptive parents work with a social
worker to put an ad in the paper for the potential birth parent and if no response after
15/30/45/60 days depending on the jurisdiction then there is a key piece of removing
someone’s arguably “ownership” rights. Just an analogy to relate…
Cheers
Chris
On 10/3/17, 2:48 PM, "Craig Russell" <ap...@gmail.com> wrote:
Here is where I part company with both Roman and Chris.
> On Oct 3, 2017, at 2:23 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Tue, Oct 3, 2017 at 12:33 PM, Chris Mattmann <ma...@apache.org> wrote:
>>
>> I’m not sure how an ICLA can cover past commits….
>>
>>
>>
>> I worked prior at company X…contributing to software A (not at Apache) and not fully owned by company X.
>> I don’t have an ICLA on file at this point.
>>
>> Company X owns my IP b/c I signed some agreement / transfer of assignment with them
>>
>> Software A donated to Apache (by the originators of software A with or without an SGA)
>>
>> I decide I want to continue contributing to software A
>> I file an ICLA with Apache
>>
>> That ICLA I do not believe licenses my past commits at company X
We usually get ICLAs from folks who are joining project A incubating at Apache. I feel that this case does not require a separate SGA along with the ICLA. We can (and have) treat "present and future" as meaning the current transfer of A to Apache and continuing work at Apache.
>>
>> Do people think that the ICLA *should* in that case? To me…I don’t think it could cover my commits at company X.
>
> FWIW I'm with you on this one -- I don't think ICLA will cover past commits.
>
> It isn't even the temporal aspect, but rather this part of the
> language of the ICLA
> that makes me think so: "submitted to the Foundation". As in:
> You accept and agree to the following terms and conditions for
> Your present and
> future Contributions submitted to the Foundation.
>
> Thanks,
> Roman.
>> 2) SGA for a donation e.g., from a set of contributors
>> a. The person providing or “granting” the SGA would ideally point to
>> some permanent URL or public URL with the decision by the binding
>> set of members of the contributors (at a minimum, within reason e.g.,
>> defined as all those active, or as all contributors ever, or all those
>> that responded to my email with a deadline of 2 weeks, or a month etc.)
>
> This is what I've seen with most existing projects without an active
> corporate sponsor.
I do not feel that this passes the due diligence test.
I found this wallet with this guy's name and phone number and I called him for two weeks but he didn't respond so it's mine. I even posted it on the internet. I tried.
Where ownership is involved we need to have more than "I tried".
???
Craig
>
> ---------------------------------------------------------------------
> 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: Podling CLA/Grant advice
Posted by Craig Russell <ap...@gmail.com>.
Here is where I part company with both Roman and Chris.
> On Oct 3, 2017, at 2:23 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Tue, Oct 3, 2017 at 12:33 PM, Chris Mattmann <ma...@apache.org> wrote:
>>
>> I’m not sure how an ICLA can cover past commits….
>>
>>
>>
>> I worked prior at company X…contributing to software A (not at Apache) and not fully owned by company X.
>> I don’t have an ICLA on file at this point.
>>
>> Company X owns my IP b/c I signed some agreement / transfer of assignment with them
>>
>> Software A donated to Apache (by the originators of software A with or without an SGA)
>>
>> I decide I want to continue contributing to software A
>> I file an ICLA with Apache
>>
>> That ICLA I do not believe licenses my past commits at company X
We usually get ICLAs from folks who are joining project A incubating at Apache. I feel that this case does not require a separate SGA along with the ICLA. We can (and have) treat "present and future" as meaning the current transfer of A to Apache and continuing work at Apache.
>>
>> Do people think that the ICLA *should* in that case? To me…I don’t think it could cover my commits at company X.
>
> FWIW I'm with you on this one -- I don't think ICLA will cover past commits.
>
> It isn't even the temporal aspect, but rather this part of the
> language of the ICLA
> that makes me think so: "submitted to the Foundation". As in:
> You accept and agree to the following terms and conditions for
> Your present and
> future Contributions submitted to the Foundation.
>
> Thanks,
> Roman.
>> 2) SGA for a donation e.g., from a set of contributors
>> a. The person providing or “granting” the SGA would ideally point to
>> some permanent URL or public URL with the decision by the binding
>> set of members of the contributors (at a minimum, within reason e.g.,
>> defined as all those active, or as all contributors ever, or all those
>> that responded to my email with a deadline of 2 weeks, or a month etc.)
>
> This is what I've seen with most existing projects without an active
> corporate sponsor.
I do not feel that this passes the due diligence test.
I found this wallet with this guy's name and phone number and I called him for two weeks but he didn't respond so it's mine. I even posted it on the internet. I tried.
Where ownership is involved we need to have more than "I tried".
???
Craig
>
> ---------------------------------------------------------------------
> 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: Podling CLA/Grant advice
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Tue, Oct 3, 2017 at 12:33 PM, Chris Mattmann <ma...@apache.org> wrote:
>
> I’m not sure how an ICLA can cover past commits….
>
>
>
> I worked prior at company X…contributing to software A (not at Apache) and not fully owned by company X.
> I don’t have an ICLA on file at this point.
>
> Company X owns my IP b/c I signed some agreement / transfer of assignment with them
>
> Software A donated to Apache (by the originators of software A with or without an SGA)
>
> I decide I want to continue contributing to software A
> I file an ICLA with Apache
>
> That ICLA I do not believe licenses my past commits at company X
>
>
>
> Do people think that the ICLA *should* in that case? To me…I don’t think it could cover my commits at company X.
FWIW I'm with you on this one -- I don't think ICLA will cover past commits.
It isn't even the temporal aspect, but rather this part of the
language of the ICLA
that makes me think so: "submitted to the Foundation". As in:
You accept and agree to the following terms and conditions for
Your present and
future Contributions submitted to the Foundation.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Podling CLA/Grant advice
Posted by Henri Yandell <ba...@apache.org>.
I can see an argument that the ICLA covers contributions made to Apache
prior to signing the ICLA, but it seems harder to argue that it covers
contributions made to a third party, which are then subsequently relocated
to Apache. This would seem to be true regardless of whether you have signed
an ICLA with Apache as the contribution to software A was not intentionally
submitted to the Foundation.
I think there is a loophole in our favour there though for incubator
projects. When an incubating project joins, it is being intentionally
submitted to the Foundation by <insert amorphous blob of committers>. By
signing an ICLA when they joined the Incubator, they are intentionally
submitting their historic contributions to the project to Apache. I'm not
sure how tortured that is, but an ICLA would seem to work fine for incoming
committers on an Incubator podling.
It could still work to use an ICLA when we ask someone to sign for
historical contributions to software A, but perhaps we would have to be
clear that the signing is to intentionally submit those old contributions
to Apache. That should be implicit in conversations on the topic, but I
imagine it could be more explicit. Using an SGA would be the alternative
with an Exhibit A saying something like "Contributions to Software A
Between Date1 and Date2".
--
For MXNet I'm going to let my subconcious ruminate on the feedback provided
and propose something in a day or so. Probably related to your opt-out
direction and drafting up an email.
For the 'Copyright Contributors', probably a clarification change to the
Copyright statement so it isn't so vague. Like: "Pre-Apache Copyright
Statement: Copyright 2015 Contributors", and leaving that in the files in
perpetuity.
Hen
On Tue, Oct 3, 2017 at 12:33 PM, Chris Mattmann <ma...@apache.org> wrote:
> I’m not sure how an ICLA can cover past commits….
>
>
>
> I worked prior at company X…contributing to software A (not at Apache) and
> not fully owned by company X.
> I don’t have an ICLA on file at this point.
>
> - Company X owns my IP b/c I signed some agreement / transfer of
> assignment with them
>
> Software A donated to Apache (by the originators of software A with or
> without an SGA)
>
> - I decide I want to continue contributing to software A
> - I file an ICLA with Apache
> - That ICLA I do not believe licenses my past commits at company X
>
>
>
> Do people think that the ICLA **should** in that case? To me…I don’t
> think it could cover my commits at company X.
>
>
>
> Cheers,
>
> Chris
>
>
>
>
>
>
>
>
>
> *From: *<hy...@gmail.com> on behalf of Henri Yandell <henri@yandell.org
> >
> *Reply-To: *"legal-discuss@apache.org" <le...@apache.org>
> *Date: *Tuesday, October 3, 2017 at 11:57 AM
>
> *To: *ASF Legal Discuss <le...@apache.org>
> *Subject: *Re: Podling CLA/Grant advice
>
>
>
> Because you're saying that an ICLA does not cover past commits?
>
>
>
> On Tue, Oct 3, 2017 at 11:45 AM, Chris Mattmann <ma...@apache.org>
> wrote:
>
> Gotcha.
>
>
>
> OK this email came out of order for me.
>
> So if an SGA was obtained, it would likely be important for the people who
> incepted the IP to
> file the SGA, aka the original academic authors of the project. I don’t
> know how many, or if
> they are even willing to sign it, but worth asking.
>
>
>
> If there is no SGA on file, of course it’s not a requirement, but follow
> my advice in the previous
> reply I just sent. Keep the headers intact, identify what NOTICE updates
> if any are required, and
> ICLAs on file cover contributions of the Apache variety going forward.
>
>
>
> Thanks
>
> Chris
>
>
>
>
>
>
>
>
>
> *From: *<hy...@gmail.com> on behalf of Henri Yandell <henri@yandell.org
> >
> *Reply-To: *"legal-discuss@apache.org" <le...@apache.org>
> *Date: *Tuesday, October 3, 2017 at 11:37 AM
>
>
> *To: *ASF Legal Discuss <le...@apache.org>
> *Subject: *Re: Podling CLA/Grant advice
>
>
>
>
> Amazon are not the creators of MXNet, Alex. They are a contributor to the
> project. The project predates Amazon's involvement by 1-2 years and was
> written by academics at various universities iiuc. Amazon got involved when
> it came to Apache (or a month or two before).
>
> Getting an SGA signed would be easy, but an SGA from Amazon is pointless,
> it doesn't cover the contributions in question.
>
> Hen
>
>
>
>
>
> On Tue, Oct 3, 2017 at 11:33 AM, Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> Are you saying that Amazon employees own copyright individually and don't
> have an employee agreement that assigns copyright to Amazon? At Adobe,
> anything I write is owned by Adobe. I signed something to that effect
> which is why an Adobe VP signed the Flex SGA.
>
>
>
> If Amazon employees assign copyright to Amazon, then an Amazon VP probably
> needs to sign an SGA and you don't have to chase down any other Amazon
> employees. And then, if only Amazon employees were making changes before
> before Jan 2017, hopefully the remaining crew is much more manageable.
>
>
>
> I'd be amazed if Amazon employees didn't assign copyright.
>
>
>
> Unless you are enjoying figuring out which committers did "trivial" work,
> it seems simpler for the ASF to not care about making it perfect and err on
> the side of not changing the header until someone has the time to figure
> out that a file can have its header changed. Meanwhile, the project should
> just keep on going. What harm could come to the foundation if there is a
> file who could have its header changed to the ASF header but didn't?
>
>
>
> Thanks,
>
> -Alex
>
>
>
> *From: *Chris Mattmann <ma...@apache.org>
> *Reply-To: *"legal-discuss@apache.org" <le...@apache.org>
> *Date: *Tuesday, October 3, 2017 at 11:19 AM
> *To: *"legal-discuss@apache.org" <le...@apache.org>
>
>
> *Subject: *Re: Podling CLA/Grant advice
>
>
>
> Haha, cool, Hen.
>
>
>
> If Amazon would be amenable having the original author who created the
> repo (is that an Amazon
> employee) submit an SGA would be useful in my mind. Let us know if that
> can be arranged.
>
>
>
> Yes repo & contribution analysis should be ongoing, but not a blocker on
> proceeding obviously since
> MXNet has already made a release (though I know there were some concerns
> with the release perhaps
> procedurally from what I’ve read on the threads).
>
>
>
> Feel free to use my numbers ☺
>
>
>
> Cheers,
>
> Chris
>
>
>
>
>
>
>
>
>
> *From: *<hy...@gmail.com> on behalf of Henri Yandell <henri@yandell.org
> >
> *Reply-To: *"legal-discuss@apache.org" <le...@apache.org>
> *Date: *Tuesday, October 3, 2017 at 11:14 AM
> *To: *ASF Legal Discuss <le...@apache.org>
> *Subject: *Re: Podling CLA/Grant advice
>
>
>
> No, there's no SGA and no one to sign an SFA. Who would the SGA be with?
> Perhaps the original author who created the repository 2 years ago? He's
> already signed an ICLA.
>
> Note that getting all Amazon employees to sign ICLAs (for those who
> havne't) is an easy task and would have limited impact on the numbers here.
> Amazon contributions from non-ICLA signers would have started ~Jan 2017,
> and it's arguable that contributions then were well aware they were a part
> of Apache as the project was reporting itself as having moved to Apache in
> Jan 2017 (though the GitHub change didn't happen until July). Basically
> there's unlikely to be much here unless Amazon happened to hire a
> historical contributor.
>
> Opt-out would be one approach. Still lots of analysis to work out
> contribution triviality so I'd be tempted to simply contact everyone who
> has contributed pre-July, or pre-January.
>
> Having specific numbers of what is trivial, what is major would be useful
> (as always). Your numbers are higher than I would come up with, so I prefer
> yours obviously :)
>
>
>
> Hen
>
>
>
> On Tue, Oct 3, 2017 at 11:05 AM, Chris Mattmann <ma...@apache.org>
> wrote:
>
> Hi Hen,
>
>
>
> While I understand the below, there is no need to make it more complicated
> then it has to be.
>
>
>
> For MXNet, I assume there was an SGA filed, no? There only needs to be 1:1
> on the project level,
> and contributors don’t need to separately submit an SGA. I would assume
> you wouldn’t have to
> email 380 people and that the initial SGA and whomever were specified on
> it in the attachment,
> is sufficient to begin.
>
>
>
> Then we look that we have ICLAs on file for all **major** and non 5-10
> lines of code, or 30+ lines
> of code, or some number N lines of code **contributors**, for commits and
> contributions going
> forward. For those before hand, if there were 380 contributors, I’m
> assuming not all of them
> were Amazon employees. However, perhaps within the 380, many were the 5-10
> lines of code
> variety, a fix here or there variety, etc etc. I know you can adopt an **opt
> out** rather than **opt in**
> there. That is, leave the code in there. We assume good faith and that the
> person will want it there.
> If they **don’t** want it there, and they make that known, we take it out
> (we only want code that
> wants to be here).
>
>
>
> Taking the above into account, I do not think it has to be harder than
> that. And the PMC is responsible
> for IP management in relation to the code, so this is something the PPMC
> needs to decide. Consider the
> above (and below else-thread) advice helping you all to come to your
> decisions ☺
>
>
>
> Cheers,
>
> Chris
>
>
>
>
>
>
>
>
>
> *From: *<hy...@gmail.com> on behalf of Henri Yandell <henri@yandell.org
> >
> *Reply-To: *"legal-discuss@apache.org" <le...@apache.org>
> *Date: *Tuesday, October 3, 2017 at 1:37 AM
> *To: *ASF Legal Discuss <le...@apache.org>
> *Subject: *Re: Podling CLA/Grant advice
>
>
>
>
>
> Here be dragons :)
>
>
>
> In #1, there are two sets:
>
> 1a) The entity are the copyright holder for 100% of the work (ignoring
> clearly decoupled dependencies).
>
> 1b) The entity are a partial copyright holder of the work (ignoring deps),
> have received a license to the rest of the work, and have the rights to
> assign that license to Apache. The latter is probably rare, yet this option
> (1b) is most likely for any codebase that has been public. That is, we rely
> on the entity contributing the project to Apache to have clean IP, we don't
> rely on them to be able to hand over their clean IP to us.
>
> I believe in #2 (below, not 1(b) above) that the git/github model has
> changed how we look at this. Historically we would have looked at the
> commits, but I don't believe we would have analysed the issue tracker. With
> pull requests on GitHub, folk who would have attached a patch to the issue
> tracker are now a part of the commit history and we see the authors
> increase by an order of magnitude.
>
>
>
> Note that MXNet did have a form of IP management. As a user of the Apache
> 2.0 license every contribution to the project (per clause 5) was licensed
> under the Apache 2.0 license ('in/out licensing'). That's the same IP
> management Apache uses for contributions on JIRA/pull requests, both
> trivial and anything up to 'major' (where the occasional major contribution
> requires an SGA, or lazily (in a good way) an ICLA).
>
> Going back to the original email; I'd like to know what to say to 380
> people to explain why we need them to sign something. With a relicence it's
> easy, relicensing needs the copyright owner's permission, they are a
> copyright owner, please can we have permission. With this, not so easy.
> "We don't trust your contribution, please sign this SGA so we can trust
> your contribution"?
>
>
>
> Hen
>
>
>
> On Mon, Oct 2, 2017 at 6:21 PM, Chris Mattmann <ma...@apache.org>
> wrote:
>
> Craig, I share the below opinions.
>
> RE: SGA, let me clarify, I think there are a few situations:
>
>
> 1) SGA for a donation e.g., from a company or gov agency
> a. The person providing or “granting” the SGA may have
> the permission of the institution e.g., a signing authority, that
> represents the IP from the company or agency, fine.
> b. The person may be someone without signing authority but
> designated by the agency as someone who can provide the Grant,
> fine.
> 2) SGA for a donation e.g., from a set of contributors
> a. The person providing or “granting” the SGA would ideally point to
> some permanent URL or public URL with the decision by the binding
> set of members of the contributors (at a minimum, within reason e.g.,
> defined as all those active, or as all contributors ever, or all those
> that responded to my email with a deadline of 2 weeks, or a month etc.)
> b. If the community already uses some form of IP management besides
> having a version repository and headers, etc., then pointing to those
> on file would be useful and welcomed.
>
> I’m sure there are variations on 1ab or 2ab but those are the ones fresh
> in my mind
> with what I was talking about.
>
> Thoughts, Craig? Roman?
>
> Cheers,
> Chris
>
>
>
>
>
> On 10/2/17, 5:51 PM, "Craig Russell" <ap...@gmail.com> wrote:
>
>
> > On Oct 2, 2017, at 5:23 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> >
> > On Mon, Oct 2, 2017 at 3:23 PM, Craig Russell <ap...@gmail.com>
> wrote:
> >> Not to contradict our VP, Legal, just to clarify.
> >>
> >>> On Oct 2, 2017, at 1:17 PM, Chris Mattmann <ma...@apache.org>
> wrote:
> >>>
> >>> Clearly, an SGA is intended for the copyright holder. If that’s an
> individual who as an
> >>> individual represents those copyright holders, OK, but it’s gotta
> be pretty clear.
> >>
> >> That is a pretty high bar, and I've not seen it in practice. In
> order for an individual to own
> >> the rights and grant those rights via an SGA, there would need to
> be some grant document
> >> from the contributor to the individual(s) signing the SGA.
> >
> > +1 to what Craig is saying -- I've also seen a much laxer attitude in
> > the past. The very questions
> > I'm asking is whether we should consider tighten our practices or
> > still allow SGAs that are lax.
> >
> > I'm actually working on a proposal right now for a project that
> > existed on GitHub for sometime.
> > I've assumed that an SGA *on behalf* of the community (but NOT from
> > somebody who is legally
> > speaking a copyright holder) will be a way to go.
>
> Speaking as a non-lawyer, "You cannot grant rights that you do not
> own." And the following is strictly my own opinion.
>
> A project that is licensed under alv2.0 and has existed for so long
> that the contributors cannot be found can still use code with the Apache
> license, but not with the Apache header.
>
> If the project is currently licensed using the alv2.0 as its license,
> then the project can continue to use the license with its original headers
> and NOTICE.
>
> Craig
>
> >
> > Thanks,
> > Roman.
> >
> > ------------------------------------------------------------
> ---------
> > 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
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdb.apache.org%2Fjdo&data=02%7C01%7C%7Cea651c00eb9345f34ac008d50a8b5aa2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636426515993386975&sdata=dLPPfurP0CIC7%2F3x69gH6Tsd4SKvBVzaPkPt51xvhmE%3D&reserved=0>
>
>
> ---------------------------------------------------------------------
> 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: Podling CLA/Grant advice
Posted by Chris Mattmann <ma...@apache.org>.
I’m not sure how an ICLA can cover past commits….
I worked prior at company X…contributing to software A (not at Apache) and not fully owned by company X.
I don’t have an ICLA on file at this point.
Company X owns my IP b/c I signed some agreement / transfer of assignment with them
Software A donated to Apache (by the originators of software A with or without an SGA)
I decide I want to continue contributing to software A
I file an ICLA with Apache
That ICLA I do not believe licenses my past commits at company X
Do people think that the ICLA *should* in that case? To me…I don’t think it could cover my commits at company X.
Cheers,
Chris
From: <hy...@gmail.com> on behalf of Henri Yandell <he...@yandell.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Tuesday, October 3, 2017 at 11:57 AM
To: ASF Legal Discuss <le...@apache.org>
Subject: Re: Podling CLA/Grant advice
Because you're saying that an ICLA does not cover past commits?
On Tue, Oct 3, 2017 at 11:45 AM, Chris Mattmann <ma...@apache.org> wrote:
Gotcha.
OK this email came out of order for me.
So if an SGA was obtained, it would likely be important for the people who incepted the IP to
file the SGA, aka the original academic authors of the project. I don’t know how many, or if
they are even willing to sign it, but worth asking.
If there is no SGA on file, of course it’s not a requirement, but follow my advice in the previous
reply I just sent. Keep the headers intact, identify what NOTICE updates if any are required, and
ICLAs on file cover contributions of the Apache variety going forward.
Thanks
Chris
From: <hy...@gmail.com> on behalf of Henri Yandell <he...@yandell.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Tuesday, October 3, 2017 at 11:37 AM
To: ASF Legal Discuss <le...@apache.org>
Subject: Re: Podling CLA/Grant advice
Amazon are not the creators of MXNet, Alex. They are a contributor to the project. The project predates Amazon's involvement by 1-2 years and was written by academics at various universities iiuc. Amazon got involved when it came to Apache (or a month or two before).
Getting an SGA signed would be easy, but an SGA from Amazon is pointless, it doesn't cover the contributions in question.
Hen
On Tue, Oct 3, 2017 at 11:33 AM, Alex Harui <ah...@adobe.com.invalid> wrote:
Are you saying that Amazon employees own copyright individually and don't have an employee agreement that assigns copyright to Amazon? At Adobe, anything I write is owned by Adobe. I signed something to that effect which is why an Adobe VP signed the Flex SGA.
If Amazon employees assign copyright to Amazon, then an Amazon VP probably needs to sign an SGA and you don't have to chase down any other Amazon employees. And then, if only Amazon employees were making changes before before Jan 2017, hopefully the remaining crew is much more manageable.
I'd be amazed if Amazon employees didn't assign copyright.
Unless you are enjoying figuring out which committers did "trivial" work, it seems simpler for the ASF to not care about making it perfect and err on the side of not changing the header until someone has the time to figure out that a file can have its header changed. Meanwhile, the project should just keep on going. What harm could come to the foundation if there is a file who could have its header changed to the ASF header but didn't?
Thanks,
-Alex
From: Chris Mattmann <ma...@apache.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Tuesday, October 3, 2017 at 11:19 AM
To: "legal-discuss@apache.org" <le...@apache.org>
Subject: Re: Podling CLA/Grant advice
Haha, cool, Hen.
If Amazon would be amenable having the original author who created the repo (is that an Amazon
employee) submit an SGA would be useful in my mind. Let us know if that can be arranged.
Yes repo & contribution analysis should be ongoing, but not a blocker on proceeding obviously since
MXNet has already made a release (though I know there were some concerns with the release perhaps
procedurally from what I’ve read on the threads).
Feel free to use my numbers ☺
Cheers,
Chris
From: <hy...@gmail.com> on behalf of Henri Yandell <he...@yandell.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Tuesday, October 3, 2017 at 11:14 AM
To: ASF Legal Discuss <le...@apache.org>
Subject: Re: Podling CLA/Grant advice
No, there's no SGA and no one to sign an SFA. Who would the SGA be with? Perhaps the original author who created the repository 2 years ago? He's already signed an ICLA.
Note that getting all Amazon employees to sign ICLAs (for those who havne't) is an easy task and would have limited impact on the numbers here. Amazon contributions from non-ICLA signers would have started ~Jan 2017, and it's arguable that contributions then were well aware they were a part of Apache as the project was reporting itself as having moved to Apache in Jan 2017 (though the GitHub change didn't happen until July). Basically there's unlikely to be much here unless Amazon happened to hire a historical contributor.
Opt-out would be one approach. Still lots of analysis to work out contribution triviality so I'd be tempted to simply contact everyone who has contributed pre-July, or pre-January.
Having specific numbers of what is trivial, what is major would be useful (as always). Your numbers are higher than I would come up with, so I prefer yours obviously :)
Hen
On Tue, Oct 3, 2017 at 11:05 AM, Chris Mattmann <ma...@apache.org> wrote:
Hi Hen,
While I understand the below, there is no need to make it more complicated then it has to be.
For MXNet, I assume there was an SGA filed, no? There only needs to be 1:1 on the project level,
and contributors don’t need to separately submit an SGA. I would assume you wouldn’t have to
email 380 people and that the initial SGA and whomever were specified on it in the attachment,
is sufficient to begin.
Then we look that we have ICLAs on file for all *major* and non 5-10 lines of code, or 30+ lines
of code, or some number N lines of code *contributors*, for commits and contributions going
forward. For those before hand, if there were 380 contributors, I’m assuming not all of them
were Amazon employees. However, perhaps within the 380, many were the 5-10 lines of code
variety, a fix here or there variety, etc etc. I know you can adopt an *opt out* rather than *opt in*
there. That is, leave the code in there. We assume good faith and that the person will want it there.
If they *don’t* want it there, and they make that known, we take it out (we only want code that
wants to be here).
Taking the above into account, I do not think it has to be harder than that. And the PMC is responsible
for IP management in relation to the code, so this is something the PPMC needs to decide. Consider the
above (and below else-thread) advice helping you all to come to your decisions ☺
Cheers,
Chris
From: <hy...@gmail.com> on behalf of Henri Yandell <he...@yandell.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Tuesday, October 3, 2017 at 1:37 AM
To: ASF Legal Discuss <le...@apache.org>
Subject: Re: Podling CLA/Grant advice
Here be dragons :)
In #1, there are two sets:
1a) The entity are the copyright holder for 100% of the work (ignoring clearly decoupled dependencies).
1b) The entity are a partial copyright holder of the work (ignoring deps), have received a license to the rest of the work, and have the rights to assign that license to Apache. The latter is probably rare, yet this option (1b) is most likely for any codebase that has been public. That is, we rely on the entity contributing the project to Apache to have clean IP, we don't rely on them to be able to hand over their clean IP to us.
I believe in #2 (below, not 1(b) above) that the git/github model has changed how we look at this. Historically we would have looked at the commits, but I don't believe we would have analysed the issue tracker. With pull requests on GitHub, folk who would have attached a patch to the issue tracker are now a part of the commit history and we see the authors increase by an order of magnitude.
Note that MXNet did have a form of IP management. As a user of the Apache 2.0 license every contribution to the project (per clause 5) was licensed under the Apache 2.0 license ('in/out licensing'). That's the same IP management Apache uses for contributions on JIRA/pull requests, both trivial and anything up to 'major' (where the occasional major contribution requires an SGA, or lazily (in a good way) an ICLA).
Going back to the original email; I'd like to know what to say to 380 people to explain why we need them to sign something. With a relicence it's easy, relicensing needs the copyright owner's permission, they are a copyright owner, please can we have permission. With this, not so easy. "We don't trust your contribution, please sign this SGA so we can trust your contribution"?
Hen
On Mon, Oct 2, 2017 at 6:21 PM, Chris Mattmann <ma...@apache.org> wrote:
Craig, I share the below opinions.
RE: SGA, let me clarify, I think there are a few situations:
1) SGA for a donation e.g., from a company or gov agency
a. The person providing or “granting” the SGA may have
the permission of the institution e.g., a signing authority, that
represents the IP from the company or agency, fine.
b. The person may be someone without signing authority but
designated by the agency as someone who can provide the Grant,
fine.
2) SGA for a donation e.g., from a set of contributors
a. The person providing or “granting” the SGA would ideally point to
some permanent URL or public URL with the decision by the binding
set of members of the contributors (at a minimum, within reason e.g.,
defined as all those active, or as all contributors ever, or all those
that responded to my email with a deadline of 2 weeks, or a month etc.)
b. If the community already uses some form of IP management besides
having a version repository and headers, etc., then pointing to those
on file would be useful and welcomed.
I’m sure there are variations on 1ab or 2ab but those are the ones fresh in my mind
with what I was talking about.
Thoughts, Craig? Roman?
Cheers,
Chris
On 10/2/17, 5:51 PM, "Craig Russell" <ap...@gmail.com> wrote:
> On Oct 2, 2017, at 5:23 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Mon, Oct 2, 2017 at 3:23 PM, Craig Russell <ap...@gmail.com> wrote:
>> Not to contradict our VP, Legal, just to clarify.
>>
>>> On Oct 2, 2017, at 1:17 PM, Chris Mattmann <ma...@apache.org> wrote:
>>>
>>> Clearly, an SGA is intended for the copyright holder. If that’s an individual who as an
>>> individual represents those copyright holders, OK, but it’s gotta be pretty clear.
>>
>> That is a pretty high bar, and I've not seen it in practice. In order for an individual to own
>> the rights and grant those rights via an SGA, there would need to be some grant document
>> from the contributor to the individual(s) signing the SGA.
>
> +1 to what Craig is saying -- I've also seen a much laxer attitude in
> the past. The very questions
> I'm asking is whether we should consider tighten our practices or
> still allow SGAs that are lax.
>
> I'm actually working on a proposal right now for a project that
> existed on GitHub for sometime.
> I've assumed that an SGA *on behalf* of the community (but NOT from
> somebody who is legally
> speaking a copyright holder) will be a way to go.
Speaking as a non-lawyer, "You cannot grant rights that you do not own." And the following is strictly my own opinion.
A project that is licensed under alv2.0 and has existed for so long that the contributors cannot be found can still use code with the Apache license, but not with the Apache header.
If the project is currently licensed using the alv2.0 as its license, then the project can continue to use the license with its original headers and NOTICE.
Craig
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> 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: Podling CLA/Grant advice
Posted by Henri Yandell <he...@yandell.org>.
Because you're saying that an ICLA does not cover past commits?
On Tue, Oct 3, 2017 at 11:45 AM, Chris Mattmann <ma...@apache.org> wrote:
> Gotcha.
>
>
>
> OK this email came out of order for me.
>
> So if an SGA was obtained, it would likely be important for the people who
> incepted the IP to
> file the SGA, aka the original academic authors of the project. I don’t
> know how many, or if
> they are even willing to sign it, but worth asking.
>
>
>
> If there is no SGA on file, of course it’s not a requirement, but follow
> my advice in the previous
> reply I just sent. Keep the headers intact, identify what NOTICE updates
> if any are required, and
> ICLAs on file cover contributions of the Apache variety going forward.
>
>
>
> Thanks
>
> Chris
>
>
>
>
>
>
>
>
>
> *From: *<hy...@gmail.com> on behalf of Henri Yandell <henri@yandell.org
> >
> *Reply-To: *"legal-discuss@apache.org" <le...@apache.org>
> *Date: *Tuesday, October 3, 2017 at 11:37 AM
>
> *To: *ASF Legal Discuss <le...@apache.org>
> *Subject: *Re: Podling CLA/Grant advice
>
>
>
>
> Amazon are not the creators of MXNet, Alex. They are a contributor to the
> project. The project predates Amazon's involvement by 1-2 years and was
> written by academics at various universities iiuc. Amazon got involved when
> it came to Apache (or a month or two before).
>
> Getting an SGA signed would be easy, but an SGA from Amazon is pointless,
> it doesn't cover the contributions in question.
>
> Hen
>
>
>
>
>
> On Tue, Oct 3, 2017 at 11:33 AM, Alex Harui <ah...@adobe.com.invalid>
> wrote:
>
> Are you saying that Amazon employees own copyright individually and don't
> have an employee agreement that assigns copyright to Amazon? At Adobe,
> anything I write is owned by Adobe. I signed something to that effect
> which is why an Adobe VP signed the Flex SGA.
>
>
>
> If Amazon employees assign copyright to Amazon, then an Amazon VP probably
> needs to sign an SGA and you don't have to chase down any other Amazon
> employees. And then, if only Amazon employees were making changes before
> before Jan 2017, hopefully the remaining crew is much more manageable.
>
>
>
> I'd be amazed if Amazon employees didn't assign copyright.
>
>
>
> Unless you are enjoying figuring out which committers did "trivial" work,
> it seems simpler for the ASF to not care about making it perfect and err on
> the side of not changing the header until someone has the time to figure
> out that a file can have its header changed. Meanwhile, the project should
> just keep on going. What harm could come to the foundation if there is a
> file who could have its header changed to the ASF header but didn't?
>
>
>
> Thanks,
>
> -Alex
>
>
>
> *From: *Chris Mattmann <ma...@apache.org>
> *Reply-To: *"legal-discuss@apache.org" <le...@apache.org>
> *Date: *Tuesday, October 3, 2017 at 11:19 AM
> *To: *"legal-discuss@apache.org" <le...@apache.org>
>
>
> *Subject: *Re: Podling CLA/Grant advice
>
>
>
> Haha, cool, Hen.
>
>
>
> If Amazon would be amenable having the original author who created the
> repo (is that an Amazon
> employee) submit an SGA would be useful in my mind. Let us know if that
> can be arranged.
>
>
>
> Yes repo & contribution analysis should be ongoing, but not a blocker on
> proceeding obviously since
> MXNet has already made a release (though I know there were some concerns
> with the release perhaps
> procedurally from what I’ve read on the threads).
>
>
>
> Feel free to use my numbers ☺
>
>
>
> Cheers,
>
> Chris
>
>
>
>
>
>
>
>
>
> *From: *<hy...@gmail.com> on behalf of Henri Yandell <henri@yandell.org
> >
> *Reply-To: *"legal-discuss@apache.org" <le...@apache.org>
> *Date: *Tuesday, October 3, 2017 at 11:14 AM
> *To: *ASF Legal Discuss <le...@apache.org>
> *Subject: *Re: Podling CLA/Grant advice
>
>
>
> No, there's no SGA and no one to sign an SFA. Who would the SGA be with?
> Perhaps the original author who created the repository 2 years ago? He's
> already signed an ICLA.
>
> Note that getting all Amazon employees to sign ICLAs (for those who
> havne't) is an easy task and would have limited impact on the numbers here.
> Amazon contributions from non-ICLA signers would have started ~Jan 2017,
> and it's arguable that contributions then were well aware they were a part
> of Apache as the project was reporting itself as having moved to Apache in
> Jan 2017 (though the GitHub change didn't happen until July). Basically
> there's unlikely to be much here unless Amazon happened to hire a
> historical contributor.
>
> Opt-out would be one approach. Still lots of analysis to work out
> contribution triviality so I'd be tempted to simply contact everyone who
> has contributed pre-July, or pre-January.
>
> Having specific numbers of what is trivial, what is major would be useful
> (as always). Your numbers are higher than I would come up with, so I prefer
> yours obviously :)
>
>
>
> Hen
>
>
>
> On Tue, Oct 3, 2017 at 11:05 AM, Chris Mattmann <ma...@apache.org>
> wrote:
>
> Hi Hen,
>
>
>
> While I understand the below, there is no need to make it more complicated
> then it has to be.
>
>
>
> For MXNet, I assume there was an SGA filed, no? There only needs to be 1:1
> on the project level,
> and contributors don’t need to separately submit an SGA. I would assume
> you wouldn’t have to
> email 380 people and that the initial SGA and whomever were specified on
> it in the attachment,
> is sufficient to begin.
>
>
>
> Then we look that we have ICLAs on file for all **major** and non 5-10
> lines of code, or 30+ lines
> of code, or some number N lines of code **contributors**, for commits and
> contributions going
> forward. For those before hand, if there were 380 contributors, I’m
> assuming not all of them
> were Amazon employees. However, perhaps within the 380, many were the 5-10
> lines of code
> variety, a fix here or there variety, etc etc. I know you can adopt an **opt
> out** rather than **opt in**
> there. That is, leave the code in there. We assume good faith and that the
> person will want it there.
> If they **don’t** want it there, and they make that known, we take it out
> (we only want code that
> wants to be here).
>
>
>
> Taking the above into account, I do not think it has to be harder than
> that. And the PMC is responsible
> for IP management in relation to the code, so this is something the PPMC
> needs to decide. Consider the
> above (and below else-thread) advice helping you all to come to your
> decisions ☺
>
>
>
> Cheers,
>
> Chris
>
>
>
>
>
>
>
>
>
> *From: *<hy...@gmail.com> on behalf of Henri Yandell <henri@yandell.org
> >
> *Reply-To: *"legal-discuss@apache.org" <le...@apache.org>
> *Date: *Tuesday, October 3, 2017 at 1:37 AM
> *To: *ASF Legal Discuss <le...@apache.org>
> *Subject: *Re: Podling CLA/Grant advice
>
>
>
>
>
> Here be dragons :)
>
>
>
> In #1, there are two sets:
>
> 1a) The entity are the copyright holder for 100% of the work (ignoring
> clearly decoupled dependencies).
>
> 1b) The entity are a partial copyright holder of the work (ignoring deps),
> have received a license to the rest of the work, and have the rights to
> assign that license to Apache. The latter is probably rare, yet this option
> (1b) is most likely for any codebase that has been public. That is, we rely
> on the entity contributing the project to Apache to have clean IP, we don't
> rely on them to be able to hand over their clean IP to us.
>
> I believe in #2 (below, not 1(b) above) that the git/github model has
> changed how we look at this. Historically we would have looked at the
> commits, but I don't believe we would have analysed the issue tracker. With
> pull requests on GitHub, folk who would have attached a patch to the issue
> tracker are now a part of the commit history and we see the authors
> increase by an order of magnitude.
>
>
>
> Note that MXNet did have a form of IP management. As a user of the Apache
> 2.0 license every contribution to the project (per clause 5) was licensed
> under the Apache 2.0 license ('in/out licensing'). That's the same IP
> management Apache uses for contributions on JIRA/pull requests, both
> trivial and anything up to 'major' (where the occasional major contribution
> requires an SGA, or lazily (in a good way) an ICLA).
>
> Going back to the original email; I'd like to know what to say to 380
> people to explain why we need them to sign something. With a relicence it's
> easy, relicensing needs the copyright owner's permission, they are a
> copyright owner, please can we have permission. With this, not so easy.
> "We don't trust your contribution, please sign this SGA so we can trust
> your contribution"?
>
>
>
> Hen
>
>
>
> On Mon, Oct 2, 2017 at 6:21 PM, Chris Mattmann <ma...@apache.org>
> wrote:
>
> Craig, I share the below opinions.
>
> RE: SGA, let me clarify, I think there are a few situations:
>
>
> 1) SGA for a donation e.g., from a company or gov agency
> a. The person providing or “granting” the SGA may have
> the permission of the institution e.g., a signing authority, that
> represents the IP from the company or agency, fine.
> b. The person may be someone without signing authority but
> designated by the agency as someone who can provide the Grant,
> fine.
> 2) SGA for a donation e.g., from a set of contributors
> a. The person providing or “granting” the SGA would ideally point to
> some permanent URL or public URL with the decision by the binding
> set of members of the contributors (at a minimum, within reason e.g.,
> defined as all those active, or as all contributors ever, or all those
> that responded to my email with a deadline of 2 weeks, or a month etc.)
> b. If the community already uses some form of IP management besides
> having a version repository and headers, etc., then pointing to those
> on file would be useful and welcomed.
>
> I’m sure there are variations on 1ab or 2ab but those are the ones fresh
> in my mind
> with what I was talking about.
>
> Thoughts, Craig? Roman?
>
> Cheers,
> Chris
>
>
>
>
>
> On 10/2/17, 5:51 PM, "Craig Russell" <ap...@gmail.com> wrote:
>
>
> > On Oct 2, 2017, at 5:23 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> >
> > On Mon, Oct 2, 2017 at 3:23 PM, Craig Russell <ap...@gmail.com>
> wrote:
> >> Not to contradict our VP, Legal, just to clarify.
> >>
> >>> On Oct 2, 2017, at 1:17 PM, Chris Mattmann <ma...@apache.org>
> wrote:
> >>>
> >>> Clearly, an SGA is intended for the copyright holder. If that’s an
> individual who as an
> >>> individual represents those copyright holders, OK, but it’s gotta
> be pretty clear.
> >>
> >> That is a pretty high bar, and I've not seen it in practice. In
> order for an individual to own
> >> the rights and grant those rights via an SGA, there would need to
> be some grant document
> >> from the contributor to the individual(s) signing the SGA.
> >
> > +1 to what Craig is saying -- I've also seen a much laxer attitude in
> > the past. The very questions
> > I'm asking is whether we should consider tighten our practices or
> > still allow SGAs that are lax.
> >
> > I'm actually working on a proposal right now for a project that
> > existed on GitHub for sometime.
> > I've assumed that an SGA *on behalf* of the community (but NOT from
> > somebody who is legally
> > speaking a copyright holder) will be a way to go.
>
> Speaking as a non-lawyer, "You cannot grant rights that you do not
> own." And the following is strictly my own opinion.
>
> A project that is licensed under alv2.0 and has existed for so long
> that the contributors cannot be found can still use code with the Apache
> license, but not with the Apache header.
>
> If the project is currently licensed using the alv2.0 as its license,
> then the project can continue to use the license with its original headers
> and NOTICE.
>
> Craig
>
> >
> > Thanks,
> > Roman.
> >
> > ------------------------------------------------------------
> ---------
> > 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
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdb.apache.org%2Fjdo&data=02%7C01%7C%7Cea651c00eb9345f34ac008d50a8b5aa2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636426515993386975&sdata=dLPPfurP0CIC7%2F3x69gH6Tsd4SKvBVzaPkPt51xvhmE%3D&reserved=0>
>
>
> ---------------------------------------------------------------------
> 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: Podling CLA/Grant advice
Posted by Chris Mattmann <ma...@apache.org>.
Gotcha.
OK this email came out of order for me.
So if an SGA was obtained, it would likely be important for the people who incepted the IP to
file the SGA, aka the original academic authors of the project. I don’t know how many, or if
they are even willing to sign it, but worth asking.
If there is no SGA on file, of course it’s not a requirement, but follow my advice in the previous
reply I just sent. Keep the headers intact, identify what NOTICE updates if any are required, and
ICLAs on file cover contributions of the Apache variety going forward.
Thanks
Chris
From: <hy...@gmail.com> on behalf of Henri Yandell <he...@yandell.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Tuesday, October 3, 2017 at 11:37 AM
To: ASF Legal Discuss <le...@apache.org>
Subject: Re: Podling CLA/Grant advice
Amazon are not the creators of MXNet, Alex. They are a contributor to the project. The project predates Amazon's involvement by 1-2 years and was written by academics at various universities iiuc. Amazon got involved when it came to Apache (or a month or two before).
Getting an SGA signed would be easy, but an SGA from Amazon is pointless, it doesn't cover the contributions in question.
Hen
On Tue, Oct 3, 2017 at 11:33 AM, Alex Harui <ah...@adobe.com.invalid> wrote:
Are you saying that Amazon employees own copyright individually and don't have an employee agreement that assigns copyright to Amazon? At Adobe, anything I write is owned by Adobe. I signed something to that effect which is why an Adobe VP signed the Flex SGA.
If Amazon employees assign copyright to Amazon, then an Amazon VP probably needs to sign an SGA and you don't have to chase down any other Amazon employees. And then, if only Amazon employees were making changes before before Jan 2017, hopefully the remaining crew is much more manageable.
I'd be amazed if Amazon employees didn't assign copyright.
Unless you are enjoying figuring out which committers did "trivial" work, it seems simpler for the ASF to not care about making it perfect and err on the side of not changing the header until someone has the time to figure out that a file can have its header changed. Meanwhile, the project should just keep on going. What harm could come to the foundation if there is a file who could have its header changed to the ASF header but didn't?
Thanks,
-Alex
From: Chris Mattmann <ma...@apache.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Tuesday, October 3, 2017 at 11:19 AM
To: "legal-discuss@apache.org" <le...@apache.org>
Subject: Re: Podling CLA/Grant advice
Haha, cool, Hen.
If Amazon would be amenable having the original author who created the repo (is that an Amazon
employee) submit an SGA would be useful in my mind. Let us know if that can be arranged.
Yes repo & contribution analysis should be ongoing, but not a blocker on proceeding obviously since
MXNet has already made a release (though I know there were some concerns with the release perhaps
procedurally from what I’ve read on the threads).
Feel free to use my numbers ☺
Cheers,
Chris
From: <hy...@gmail.com> on behalf of Henri Yandell <he...@yandell.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Tuesday, October 3, 2017 at 11:14 AM
To: ASF Legal Discuss <le...@apache.org>
Subject: Re: Podling CLA/Grant advice
No, there's no SGA and no one to sign an SFA. Who would the SGA be with? Perhaps the original author who created the repository 2 years ago? He's already signed an ICLA.
Note that getting all Amazon employees to sign ICLAs (for those who havne't) is an easy task and would have limited impact on the numbers here. Amazon contributions from non-ICLA signers would have started ~Jan 2017, and it's arguable that contributions then were well aware they were a part of Apache as the project was reporting itself as having moved to Apache in Jan 2017 (though the GitHub change didn't happen until July). Basically there's unlikely to be much here unless Amazon happened to hire a historical contributor.
Opt-out would be one approach. Still lots of analysis to work out contribution triviality so I'd be tempted to simply contact everyone who has contributed pre-July, or pre-January.
Having specific numbers of what is trivial, what is major would be useful (as always). Your numbers are higher than I would come up with, so I prefer yours obviously :)
Hen
On Tue, Oct 3, 2017 at 11:05 AM, Chris Mattmann <ma...@apache.org> wrote:
Hi Hen,
While I understand the below, there is no need to make it more complicated then it has to be.
For MXNet, I assume there was an SGA filed, no? There only needs to be 1:1 on the project level,
and contributors don’t need to separately submit an SGA. I would assume you wouldn’t have to
email 380 people and that the initial SGA and whomever were specified on it in the attachment,
is sufficient to begin.
Then we look that we have ICLAs on file for all *major* and non 5-10 lines of code, or 30+ lines
of code, or some number N lines of code *contributors*, for commits and contributions going
forward. For those before hand, if there were 380 contributors, I’m assuming not all of them
were Amazon employees. However, perhaps within the 380, many were the 5-10 lines of code
variety, a fix here or there variety, etc etc. I know you can adopt an *opt out* rather than *opt in*
there. That is, leave the code in there. We assume good faith and that the person will want it there.
If they *don’t* want it there, and they make that known, we take it out (we only want code that
wants to be here).
Taking the above into account, I do not think it has to be harder than that. And the PMC is responsible
for IP management in relation to the code, so this is something the PPMC needs to decide. Consider the
above (and below else-thread) advice helping you all to come to your decisions ☺
Cheers,
Chris
From: <hy...@gmail.com> on behalf of Henri Yandell <he...@yandell.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Tuesday, October 3, 2017 at 1:37 AM
To: ASF Legal Discuss <le...@apache.org>
Subject: Re: Podling CLA/Grant advice
Here be dragons :)
In #1, there are two sets:
1a) The entity are the copyright holder for 100% of the work (ignoring clearly decoupled dependencies).
1b) The entity are a partial copyright holder of the work (ignoring deps), have received a license to the rest of the work, and have the rights to assign that license to Apache. The latter is probably rare, yet this option (1b) is most likely for any codebase that has been public. That is, we rely on the entity contributing the project to Apache to have clean IP, we don't rely on them to be able to hand over their clean IP to us.
I believe in #2 (below, not 1(b) above) that the git/github model has changed how we look at this. Historically we would have looked at the commits, but I don't believe we would have analysed the issue tracker. With pull requests on GitHub, folk who would have attached a patch to the issue tracker are now a part of the commit history and we see the authors increase by an order of magnitude.
Note that MXNet did have a form of IP management. As a user of the Apache 2.0 license every contribution to the project (per clause 5) was licensed under the Apache 2.0 license ('in/out licensing'). That's the same IP management Apache uses for contributions on JIRA/pull requests, both trivial and anything up to 'major' (where the occasional major contribution requires an SGA, or lazily (in a good way) an ICLA).
Going back to the original email; I'd like to know what to say to 380 people to explain why we need them to sign something. With a relicence it's easy, relicensing needs the copyright owner's permission, they are a copyright owner, please can we have permission. With this, not so easy. "We don't trust your contribution, please sign this SGA so we can trust your contribution"?
Hen
On Mon, Oct 2, 2017 at 6:21 PM, Chris Mattmann <ma...@apache.org> wrote:
Craig, I share the below opinions.
RE: SGA, let me clarify, I think there are a few situations:
1) SGA for a donation e.g., from a company or gov agency
a. The person providing or “granting” the SGA may have
the permission of the institution e.g., a signing authority, that
represents the IP from the company or agency, fine.
b. The person may be someone without signing authority but
designated by the agency as someone who can provide the Grant,
fine.
2) SGA for a donation e.g., from a set of contributors
a. The person providing or “granting” the SGA would ideally point to
some permanent URL or public URL with the decision by the binding
set of members of the contributors (at a minimum, within reason e.g.,
defined as all those active, or as all contributors ever, or all those
that responded to my email with a deadline of 2 weeks, or a month etc.)
b. If the community already uses some form of IP management besides
having a version repository and headers, etc., then pointing to those
on file would be useful and welcomed.
I’m sure there are variations on 1ab or 2ab but those are the ones fresh in my mind
with what I was talking about.
Thoughts, Craig? Roman?
Cheers,
Chris
On 10/2/17, 5:51 PM, "Craig Russell" <ap...@gmail.com> wrote:
> On Oct 2, 2017, at 5:23 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Mon, Oct 2, 2017 at 3:23 PM, Craig Russell <ap...@gmail.com> wrote:
>> Not to contradict our VP, Legal, just to clarify.
>>
>>> On Oct 2, 2017, at 1:17 PM, Chris Mattmann <ma...@apache.org> wrote:
>>>
>>> Clearly, an SGA is intended for the copyright holder. If that’s an individual who as an
>>> individual represents those copyright holders, OK, but it’s gotta be pretty clear.
>>
>> That is a pretty high bar, and I've not seen it in practice. In order for an individual to own
>> the rights and grant those rights via an SGA, there would need to be some grant document
>> from the contributor to the individual(s) signing the SGA.
>
> +1 to what Craig is saying -- I've also seen a much laxer attitude in
> the past. The very questions
> I'm asking is whether we should consider tighten our practices or
> still allow SGAs that are lax.
>
> I'm actually working on a proposal right now for a project that
> existed on GitHub for sometime.
> I've assumed that an SGA *on behalf* of the community (but NOT from
> somebody who is legally
> speaking a copyright holder) will be a way to go.
Speaking as a non-lawyer, "You cannot grant rights that you do not own." And the following is strictly my own opinion.
A project that is licensed under alv2.0 and has existed for so long that the contributors cannot be found can still use code with the Apache license, but not with the Apache header.
If the project is currently licensed using the alv2.0 as its license, then the project can continue to use the license with its original headers and NOTICE.
Craig
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> 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: Podling CLA/Grant advice
Posted by Alex Harui <ah...@adobe.com.INVALID>.
It might matter. I'm not sure as an employee of Adobe that I can give permission for my work to move. In fact, what copyright ownership did any of the universities have over the people from that university that contributed? Maybe you really need 12 or so universities and Amazon to sign SGAs and that will cover 90% of the code?
If I'm not helping, just let me know and I'll stop posting. I'm just trying to pass on what I learned from the Flex donations.
Thanks,
-Alex
From: <hy...@gmail.com>> on behalf of Henri Yandell <he...@yandell.org>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Tuesday, October 3, 2017 at 11:37 AM
To: ASF Legal Discuss <le...@apache.org>>
Subject: Re: Podling CLA/Grant advice
Amazon are not the creators of MXNet, Alex. They are a contributor to the project. The project predates Amazon's involvement by 1-2 years and was written by academics at various universities iiuc. Amazon got involved when it came to Apache (or a month or two before).
Getting an SGA signed would be easy, but an SGA from Amazon is pointless, it doesn't cover the contributions in question.
Hen
On Tue, Oct 3, 2017 at 11:33 AM, Alex Harui <ah...@adobe.com.invalid>> wrote:
Are you saying that Amazon employees own copyright individually and don't have an employee agreement that assigns copyright to Amazon? At Adobe, anything I write is owned by Adobe. I signed something to that effect which is why an Adobe VP signed the Flex SGA.
If Amazon employees assign copyright to Amazon, then an Amazon VP probably needs to sign an SGA and you don't have to chase down any other Amazon employees. And then, if only Amazon employees were making changes before before Jan 2017, hopefully the remaining crew is much more manageable.
I'd be amazed if Amazon employees didn't assign copyright.
Unless you are enjoying figuring out which committers did "trivial" work, it seems simpler for the ASF to not care about making it perfect and err on the side of not changing the header until someone has the time to figure out that a file can have its header changed. Meanwhile, the project should just keep on going. What harm could come to the foundation if there is a file who could have its header changed to the ASF header but didn't?
Thanks,
-Alex
From: Chris Mattmann <ma...@apache.org>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Tuesday, October 3, 2017 at 11:19 AM
To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Subject: Re: Podling CLA/Grant advice
Haha, cool, Hen.
If Amazon would be amenable having the original author who created the repo (is that an Amazon
employee) submit an SGA would be useful in my mind. Let us know if that can be arranged.
Yes repo & contribution analysis should be ongoing, but not a blocker on proceeding obviously since
MXNet has already made a release (though I know there were some concerns with the release perhaps
procedurally from what I’ve read on the threads).
Feel free to use my numbers ☺
Cheers,
Chris
From: <hy...@gmail.com>> on behalf of Henri Yandell <he...@yandell.org>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Tuesday, October 3, 2017 at 11:14 AM
To: ASF Legal Discuss <le...@apache.org>>
Subject: Re: Podling CLA/Grant advice
No, there's no SGA and no one to sign an SFA. Who would the SGA be with? Perhaps the original author who created the repository 2 years ago? He's already signed an ICLA.
Note that getting all Amazon employees to sign ICLAs (for those who havne't) is an easy task and would have limited impact on the numbers here. Amazon contributions from non-ICLA signers would have started ~Jan 2017, and it's arguable that contributions then were well aware they were a part of Apache as the project was reporting itself as having moved to Apache in Jan 2017 (though the GitHub change didn't happen until July). Basically there's unlikely to be much here unless Amazon happened to hire a historical contributor.
Opt-out would be one approach. Still lots of analysis to work out contribution triviality so I'd be tempted to simply contact everyone who has contributed pre-July, or pre-January.
Having specific numbers of what is trivial, what is major would be useful (as always). Your numbers are higher than I would come up with, so I prefer yours obviously :)
Hen
On Tue, Oct 3, 2017 at 11:05 AM, Chris Mattmann <ma...@apache.org>> wrote:
Hi Hen,
While I understand the below, there is no need to make it more complicated then it has to be.
For MXNet, I assume there was an SGA filed, no? There only needs to be 1:1 on the project level,
and contributors don’t need to separately submit an SGA. I would assume you wouldn’t have to
email 380 people and that the initial SGA and whomever were specified on it in the attachment,
is sufficient to begin.
Then we look that we have ICLAs on file for all *major* and non 5-10 lines of code, or 30+ lines
of code, or some number N lines of code *contributors*, for commits and contributions going
forward. For those before hand, if there were 380 contributors, I’m assuming not all of them
were Amazon employees. However, perhaps within the 380, many were the 5-10 lines of code
variety, a fix here or there variety, etc etc. I know you can adopt an *opt out* rather than *opt in*
there. That is, leave the code in there. We assume good faith and that the person will want it there.
If they *don’t* want it there, and they make that known, we take it out (we only want code that
wants to be here).
Taking the above into account, I do not think it has to be harder than that. And the PMC is responsible
for IP management in relation to the code, so this is something the PPMC needs to decide. Consider the
above (and below else-thread) advice helping you all to come to your decisions ☺
Cheers,
Chris
From: <hy...@gmail.com>> on behalf of Henri Yandell <he...@yandell.org>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Tuesday, October 3, 2017 at 1:37 AM
To: ASF Legal Discuss <le...@apache.org>>
Subject: Re: Podling CLA/Grant advice
Here be dragons :)
In #1, there are two sets:
1a) The entity are the copyright holder for 100% of the work (ignoring clearly decoupled dependencies).
1b) The entity are a partial copyright holder of the work (ignoring deps), have received a license to the rest of the work, and have the rights to assign that license to Apache. The latter is probably rare, yet this option (1b) is most likely for any codebase that has been public. That is, we rely on the entity contributing the project to Apache to have clean IP, we don't rely on them to be able to hand over their clean IP to us.
I believe in #2 (below, not 1(b) above) that the git/github model has changed how we look at this. Historically we would have looked at the commits, but I don't believe we would have analysed the issue tracker. With pull requests on GitHub, folk who would have attached a patch to the issue tracker are now a part of the commit history and we see the authors increase by an order of magnitude.
Note that MXNet did have a form of IP management. As a user of the Apache 2.0 license every contribution to the project (per clause 5) was licensed under the Apache 2.0 license ('in/out licensing'). That's the same IP management Apache uses for contributions on JIRA/pull requests, both trivial and anything up to 'major' (where the occasional major contribution requires an SGA, or lazily (in a good way) an ICLA).
Going back to the original email; I'd like to know what to say to 380 people to explain why we need them to sign something. With a relicence it's easy, relicensing needs the copyright owner's permission, they are a copyright owner, please can we have permission. With this, not so easy. "We don't trust your contribution, please sign this SGA so we can trust your contribution"?
Hen
On Mon, Oct 2, 2017 at 6:21 PM, Chris Mattmann <ma...@apache.org>> wrote:
Craig, I share the below opinions.
RE: SGA, let me clarify, I think there are a few situations:
1) SGA for a donation e.g., from a company or gov agency
a. The person providing or “granting” the SGA may have
the permission of the institution e.g., a signing authority, that
represents the IP from the company or agency, fine.
b. The person may be someone without signing authority but
designated by the agency as someone who can provide the Grant,
fine.
2) SGA for a donation e.g., from a set of contributors
a. The person providing or “granting” the SGA would ideally point to
some permanent URL or public URL with the decision by the binding
set of members of the contributors (at a minimum, within reason e.g.,
defined as all those active, or as all contributors ever, or all those
that responded to my email with a deadline of 2 weeks, or a month etc.)
b. If the community already uses some form of IP management besides
having a version repository and headers, etc., then pointing to those
on file would be useful and welcomed.
I’m sure there are variations on 1ab or 2ab but those are the ones fresh in my mind
with what I was talking about.
Thoughts, Craig? Roman?
Cheers,
Chris
On 10/2/17, 5:51 PM, "Craig Russell" <ap...@gmail.com>> wrote:
> On Oct 2, 2017, at 5:23 PM, Roman Shaposhnik <ro...@shaposhnik.org>> wrote:
>
> On Mon, Oct 2, 2017 at 3:23 PM, Craig Russell <ap...@gmail.com>> wrote:
>> Not to contradict our VP, Legal, just to clarify.
>>
>>> On Oct 2, 2017, at 1:17 PM, Chris Mattmann <ma...@apache.org>> wrote:
>>>
>>> Clearly, an SGA is intended for the copyright holder. If that’s an individual who as an
>>> individual represents those copyright holders, OK, but it’s gotta be pretty clear.
>>
>> That is a pretty high bar, and I've not seen it in practice. In order for an individual to own
>> the rights and grant those rights via an SGA, there would need to be some grant document
>> from the contributor to the individual(s) signing the SGA.
>
> +1 to what Craig is saying -- I've also seen a much laxer attitude in
> the past. The very questions
> I'm asking is whether we should consider tighten our practices or
> still allow SGAs that are lax.
>
> I'm actually working on a proposal right now for a project that
> existed on GitHub for sometime.
> I've assumed that an SGA *on behalf* of the community (but NOT from
> somebody who is legally
> speaking a copyright holder) will be a way to go.
Speaking as a non-lawyer, "You cannot grant rights that you do not own." And the following is strictly my own opinion.
A project that is licensed under alv2.0 and has existed for so long that the contributors cannot be found can still use code with the Apache license, but not with the Apache header.
If the project is currently licensed using the alv2.0 as its license, then the project can continue to use the license with its original headers and NOTICE.
Craig
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org<ma...@apache.org>
> For additional commands, e-mail: legal-discuss-help@apache.org<ma...@apache.org>
>
Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org<ma...@apache.org> http://db.apache.org/jdo<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdb.apache.org%2Fjdo&data=02%7C01%7C%7Cea651c00eb9345f34ac008d50a8b5aa2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636426515993386975&sdata=dLPPfurP0CIC7%2F3x69gH6Tsd4SKvBVzaPkPt51xvhmE%3D&reserved=0>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org<ma...@apache.org>
For additional commands, e-mail: legal-discuss-help@apache.org<ma...@apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org<ma...@apache.org>
For additional commands, e-mail: legal-discuss-help@apache.org<ma...@apache.org>
Re: Podling CLA/Grant advice
Posted by Henri Yandell <he...@yandell.org>.
Amazon are not the creators of MXNet, Alex. They are a contributor to the
project. The project predates Amazon's involvement by 1-2 years and was
written by academics at various universities iiuc. Amazon got involved when
it came to Apache (or a month or two before).
Getting an SGA signed would be easy, but an SGA from Amazon is pointless,
it doesn't cover the contributions in question.
Hen
On Tue, Oct 3, 2017 at 11:33 AM, Alex Harui <ah...@adobe.com.invalid>
wrote:
> Are you saying that Amazon employees own copyright individually and don't
> have an employee agreement that assigns copyright to Amazon? At Adobe,
> anything I write is owned by Adobe. I signed something to that effect
> which is why an Adobe VP signed the Flex SGA.
>
> If Amazon employees assign copyright to Amazon, then an Amazon VP probably
> needs to sign an SGA and you don't have to chase down any other Amazon
> employees. And then, if only Amazon employees were making changes before
> before Jan 2017, hopefully the remaining crew is much more manageable.
>
> I'd be amazed if Amazon employees didn't assign copyright.
>
> Unless you are enjoying figuring out which committers did "trivial" work,
> it seems simpler for the ASF to not care about making it perfect and err on
> the side of not changing the header until someone has the time to figure
> out that a file can have its header changed. Meanwhile, the project should
> just keep on going. What harm could come to the foundation if there is a
> file who could have its header changed to the ASF header but didn't?
>
> Thanks,
> -Alex
>
> From: Chris Mattmann <ma...@apache.org>
> Reply-To: "legal-discuss@apache.org" <le...@apache.org>
> Date: Tuesday, October 3, 2017 at 11:19 AM
> To: "legal-discuss@apache.org" <le...@apache.org>
>
> Subject: Re: Podling CLA/Grant advice
>
> Haha, cool, Hen.
>
>
>
> If Amazon would be amenable having the original author who created the
> repo (is that an Amazon
> employee) submit an SGA would be useful in my mind. Let us know if that
> can be arranged.
>
>
>
> Yes repo & contribution analysis should be ongoing, but not a blocker on
> proceeding obviously since
> MXNet has already made a release (though I know there were some concerns
> with the release perhaps
> procedurally from what I’ve read on the threads).
>
>
>
> Feel free to use my numbers ☺
>
>
>
> Cheers,
>
> Chris
>
>
>
>
>
>
>
>
>
> *From: *<hy...@gmail.com> on behalf of Henri Yandell <henri@yandell.org
> >
> *Reply-To: *"legal-discuss@apache.org" <le...@apache.org>
> *Date: *Tuesday, October 3, 2017 at 11:14 AM
> *To: *ASF Legal Discuss <le...@apache.org>
> *Subject: *Re: Podling CLA/Grant advice
>
>
>
> No, there's no SGA and no one to sign an SFA. Who would the SGA be with?
> Perhaps the original author who created the repository 2 years ago? He's
> already signed an ICLA.
>
> Note that getting all Amazon employees to sign ICLAs (for those who
> havne't) is an easy task and would have limited impact on the numbers here.
> Amazon contributions from non-ICLA signers would have started ~Jan 2017,
> and it's arguable that contributions then were well aware they were a part
> of Apache as the project was reporting itself as having moved to Apache in
> Jan 2017 (though the GitHub change didn't happen until July). Basically
> there's unlikely to be much here unless Amazon happened to hire a
> historical contributor.
>
> Opt-out would be one approach. Still lots of analysis to work out
> contribution triviality so I'd be tempted to simply contact everyone who
> has contributed pre-July, or pre-January.
>
> Having specific numbers of what is trivial, what is major would be useful
> (as always). Your numbers are higher than I would come up with, so I prefer
> yours obviously :)
>
>
>
> Hen
>
>
>
> On Tue, Oct 3, 2017 at 11:05 AM, Chris Mattmann <ma...@apache.org>
> wrote:
>
> Hi Hen,
>
>
>
> While I understand the below, there is no need to make it more complicated
> then it has to be.
>
>
>
> For MXNet, I assume there was an SGA filed, no? There only needs to be 1:1
> on the project level,
> and contributors don’t need to separately submit an SGA. I would assume
> you wouldn’t have to
> email 380 people and that the initial SGA and whomever were specified on
> it in the attachment,
> is sufficient to begin.
>
>
>
> Then we look that we have ICLAs on file for all **major** and non 5-10
> lines of code, or 30+ lines
> of code, or some number N lines of code **contributors**, for commits and
> contributions going
> forward. For those before hand, if there were 380 contributors, I’m
> assuming not all of them
> were Amazon employees. However, perhaps within the 380, many were the 5-10
> lines of code
> variety, a fix here or there variety, etc etc. I know you can adopt an **opt
> out** rather than **opt in**
> there. That is, leave the code in there. We assume good faith and that the
> person will want it there.
> If they **don’t** want it there, and they make that known, we take it out
> (we only want code that
> wants to be here).
>
>
>
> Taking the above into account, I do not think it has to be harder than
> that. And the PMC is responsible
> for IP management in relation to the code, so this is something the PPMC
> needs to decide. Consider the
> above (and below else-thread) advice helping you all to come to your
> decisions ☺
>
>
>
> Cheers,
>
> Chris
>
>
>
>
>
>
>
>
>
> *From: *<hy...@gmail.com> on behalf of Henri Yandell <henri@yandell.org
> >
> *Reply-To: *"legal-discuss@apache.org" <le...@apache.org>
> *Date: *Tuesday, October 3, 2017 at 1:37 AM
> *To: *ASF Legal Discuss <le...@apache.org>
> *Subject: *Re: Podling CLA/Grant advice
>
>
>
>
>
> Here be dragons :)
>
>
>
> In #1, there are two sets:
>
> 1a) The entity are the copyright holder for 100% of the work (ignoring
> clearly decoupled dependencies).
>
> 1b) The entity are a partial copyright holder of the work (ignoring deps),
> have received a license to the rest of the work, and have the rights to
> assign that license to Apache. The latter is probably rare, yet this option
> (1b) is most likely for any codebase that has been public. That is, we rely
> on the entity contributing the project to Apache to have clean IP, we don't
> rely on them to be able to hand over their clean IP to us.
>
> I believe in #2 (below, not 1(b) above) that the git/github model has
> changed how we look at this. Historically we would have looked at the
> commits, but I don't believe we would have analysed the issue tracker. With
> pull requests on GitHub, folk who would have attached a patch to the issue
> tracker are now a part of the commit history and we see the authors
> increase by an order of magnitude.
>
>
>
> Note that MXNet did have a form of IP management. As a user of the Apache
> 2.0 license every contribution to the project (per clause 5) was licensed
> under the Apache 2.0 license ('in/out licensing'). That's the same IP
> management Apache uses for contributions on JIRA/pull requests, both
> trivial and anything up to 'major' (where the occasional major contribution
> requires an SGA, or lazily (in a good way) an ICLA).
>
> Going back to the original email; I'd like to know what to say to 380
> people to explain why we need them to sign something. With a relicence it's
> easy, relicensing needs the copyright owner's permission, they are a
> copyright owner, please can we have permission. With this, not so easy.
> "We don't trust your contribution, please sign this SGA so we can trust
> your contribution"?
>
>
>
> Hen
>
>
>
> On Mon, Oct 2, 2017 at 6:21 PM, Chris Mattmann <ma...@apache.org>
> wrote:
>
> Craig, I share the below opinions.
>
> RE: SGA, let me clarify, I think there are a few situations:
>
>
> 1) SGA for a donation e.g., from a company or gov agency
> a. The person providing or “granting” the SGA may have
> the permission of the institution e.g., a signing authority, that
> represents the IP from the company or agency, fine.
> b. The person may be someone without signing authority but
> designated by the agency as someone who can provide the Grant,
> fine.
> 2) SGA for a donation e.g., from a set of contributors
> a. The person providing or “granting” the SGA would ideally point to
> some permanent URL or public URL with the decision by the binding
> set of members of the contributors (at a minimum, within reason e.g.,
> defined as all those active, or as all contributors ever, or all those
> that responded to my email with a deadline of 2 weeks, or a month etc.)
> b. If the community already uses some form of IP management besides
> having a version repository and headers, etc., then pointing to those
> on file would be useful and welcomed.
>
> I’m sure there are variations on 1ab or 2ab but those are the ones fresh
> in my mind
> with what I was talking about.
>
> Thoughts, Craig? Roman?
>
> Cheers,
> Chris
>
>
>
>
>
> On 10/2/17, 5:51 PM, "Craig Russell" <ap...@gmail.com> wrote:
>
>
> > On Oct 2, 2017, at 5:23 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> >
> > On Mon, Oct 2, 2017 at 3:23 PM, Craig Russell <ap...@gmail.com>
> wrote:
> >> Not to contradict our VP, Legal, just to clarify.
> >>
> >>> On Oct 2, 2017, at 1:17 PM, Chris Mattmann <ma...@apache.org>
> wrote:
> >>>
> >>> Clearly, an SGA is intended for the copyright holder. If that’s an
> individual who as an
> >>> individual represents those copyright holders, OK, but it’s gotta
> be pretty clear.
> >>
> >> That is a pretty high bar, and I've not seen it in practice. In
> order for an individual to own
> >> the rights and grant those rights via an SGA, there would need to
> be some grant document
> >> from the contributor to the individual(s) signing the SGA.
> >
> > +1 to what Craig is saying -- I've also seen a much laxer attitude in
> > the past. The very questions
> > I'm asking is whether we should consider tighten our practices or
> > still allow SGAs that are lax.
> >
> > I'm actually working on a proposal right now for a project that
> > existed on GitHub for sometime.
> > I've assumed that an SGA *on behalf* of the community (but NOT from
> > somebody who is legally
> > speaking a copyright holder) will be a way to go.
>
> Speaking as a non-lawyer, "You cannot grant rights that you do not
> own." And the following is strictly my own opinion.
>
> A project that is licensed under alv2.0 and has existed for so long
> that the contributors cannot be found can still use code with the Apache
> license, but not with the Apache header.
>
> If the project is currently licensed using the alv2.0 as its license,
> then the project can continue to use the license with its original headers
> and NOTICE.
>
> Craig
>
> >
> > Thanks,
> > Roman.
> >
> > ------------------------------------------------------------
> ---------
> > 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
> <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdb.apache.org%2Fjdo&data=02%7C01%7C%7Cea651c00eb9345f34ac008d50a8b5aa2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636426515993386975&sdata=dLPPfurP0CIC7%2F3x69gH6Tsd4SKvBVzaPkPt51xvhmE%3D&reserved=0>
>
>
> ---------------------------------------------------------------------
> 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: Podling CLA/Grant advice
Posted by Alex Harui <ah...@adobe.com.INVALID>.
Are you saying that Amazon employees own copyright individually and don't have an employee agreement that assigns copyright to Amazon? At Adobe, anything I write is owned by Adobe. I signed something to that effect which is why an Adobe VP signed the Flex SGA.
If Amazon employees assign copyright to Amazon, then an Amazon VP probably needs to sign an SGA and you don't have to chase down any other Amazon employees. And then, if only Amazon employees were making changes before before Jan 2017, hopefully the remaining crew is much more manageable.
I'd be amazed if Amazon employees didn't assign copyright.
Unless you are enjoying figuring out which committers did "trivial" work, it seems simpler for the ASF to not care about making it perfect and err on the side of not changing the header until someone has the time to figure out that a file can have its header changed. Meanwhile, the project should just keep on going. What harm could come to the foundation if there is a file who could have its header changed to the ASF header but didn't?
Thanks,
-Alex
From: Chris Mattmann <ma...@apache.org>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Tuesday, October 3, 2017 at 11:19 AM
To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Subject: Re: Podling CLA/Grant advice
Haha, cool, Hen.
If Amazon would be amenable having the original author who created the repo (is that an Amazon
employee) submit an SGA would be useful in my mind. Let us know if that can be arranged.
Yes repo & contribution analysis should be ongoing, but not a blocker on proceeding obviously since
MXNet has already made a release (though I know there were some concerns with the release perhaps
procedurally from what I’ve read on the threads).
Feel free to use my numbers ☺
Cheers,
Chris
From: <hy...@gmail.com>> on behalf of Henri Yandell <he...@yandell.org>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Tuesday, October 3, 2017 at 11:14 AM
To: ASF Legal Discuss <le...@apache.org>>
Subject: Re: Podling CLA/Grant advice
No, there's no SGA and no one to sign an SFA. Who would the SGA be with? Perhaps the original author who created the repository 2 years ago? He's already signed an ICLA.
Note that getting all Amazon employees to sign ICLAs (for those who havne't) is an easy task and would have limited impact on the numbers here. Amazon contributions from non-ICLA signers would have started ~Jan 2017, and it's arguable that contributions then were well aware they were a part of Apache as the project was reporting itself as having moved to Apache in Jan 2017 (though the GitHub change didn't happen until July). Basically there's unlikely to be much here unless Amazon happened to hire a historical contributor.
Opt-out would be one approach. Still lots of analysis to work out contribution triviality so I'd be tempted to simply contact everyone who has contributed pre-July, or pre-January.
Having specific numbers of what is trivial, what is major would be useful (as always). Your numbers are higher than I would come up with, so I prefer yours obviously :)
Hen
On Tue, Oct 3, 2017 at 11:05 AM, Chris Mattmann <ma...@apache.org>> wrote:
Hi Hen,
While I understand the below, there is no need to make it more complicated then it has to be.
For MXNet, I assume there was an SGA filed, no? There only needs to be 1:1 on the project level,
and contributors don’t need to separately submit an SGA. I would assume you wouldn’t have to
email 380 people and that the initial SGA and whomever were specified on it in the attachment,
is sufficient to begin.
Then we look that we have ICLAs on file for all *major* and non 5-10 lines of code, or 30+ lines
of code, or some number N lines of code *contributors*, for commits and contributions going
forward. For those before hand, if there were 380 contributors, I’m assuming not all of them
were Amazon employees. However, perhaps within the 380, many were the 5-10 lines of code
variety, a fix here or there variety, etc etc. I know you can adopt an *opt out* rather than *opt in*
there. That is, leave the code in there. We assume good faith and that the person will want it there.
If they *don’t* want it there, and they make that known, we take it out (we only want code that
wants to be here).
Taking the above into account, I do not think it has to be harder than that. And the PMC is responsible
for IP management in relation to the code, so this is something the PPMC needs to decide. Consider the
above (and below else-thread) advice helping you all to come to your decisions ☺
Cheers,
Chris
From: <hy...@gmail.com>> on behalf of Henri Yandell <he...@yandell.org>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Tuesday, October 3, 2017 at 1:37 AM
To: ASF Legal Discuss <le...@apache.org>>
Subject: Re: Podling CLA/Grant advice
Here be dragons :)
In #1, there are two sets:
1a) The entity are the copyright holder for 100% of the work (ignoring clearly decoupled dependencies).
1b) The entity are a partial copyright holder of the work (ignoring deps), have received a license to the rest of the work, and have the rights to assign that license to Apache. The latter is probably rare, yet this option (1b) is most likely for any codebase that has been public. That is, we rely on the entity contributing the project to Apache to have clean IP, we don't rely on them to be able to hand over their clean IP to us.
I believe in #2 (below, not 1(b) above) that the git/github model has changed how we look at this. Historically we would have looked at the commits, but I don't believe we would have analysed the issue tracker. With pull requests on GitHub, folk who would have attached a patch to the issue tracker are now a part of the commit history and we see the authors increase by an order of magnitude.
Note that MXNet did have a form of IP management. As a user of the Apache 2.0 license every contribution to the project (per clause 5) was licensed under the Apache 2.0 license ('in/out licensing'). That's the same IP management Apache uses for contributions on JIRA/pull requests, both trivial and anything up to 'major' (where the occasional major contribution requires an SGA, or lazily (in a good way) an ICLA).
Going back to the original email; I'd like to know what to say to 380 people to explain why we need them to sign something. With a relicence it's easy, relicensing needs the copyright owner's permission, they are a copyright owner, please can we have permission. With this, not so easy. "We don't trust your contribution, please sign this SGA so we can trust your contribution"?
Hen
On Mon, Oct 2, 2017 at 6:21 PM, Chris Mattmann <ma...@apache.org>> wrote:
Craig, I share the below opinions.
RE: SGA, let me clarify, I think there are a few situations:
1) SGA for a donation e.g., from a company or gov agency
a. The person providing or “granting” the SGA may have
the permission of the institution e.g., a signing authority, that
represents the IP from the company or agency, fine.
b. The person may be someone without signing authority but
designated by the agency as someone who can provide the Grant,
fine.
2) SGA for a donation e.g., from a set of contributors
a. The person providing or “granting” the SGA would ideally point to
some permanent URL or public URL with the decision by the binding
set of members of the contributors (at a minimum, within reason e.g.,
defined as all those active, or as all contributors ever, or all those
that responded to my email with a deadline of 2 weeks, or a month etc.)
b. If the community already uses some form of IP management besides
having a version repository and headers, etc., then pointing to those
on file would be useful and welcomed.
I’m sure there are variations on 1ab or 2ab but those are the ones fresh in my mind
with what I was talking about.
Thoughts, Craig? Roman?
Cheers,
Chris
On 10/2/17, 5:51 PM, "Craig Russell" <ap...@gmail.com>> wrote:
> On Oct 2, 2017, at 5:23 PM, Roman Shaposhnik <ro...@shaposhnik.org>> wrote:
>
> On Mon, Oct 2, 2017 at 3:23 PM, Craig Russell <ap...@gmail.com>> wrote:
>> Not to contradict our VP, Legal, just to clarify.
>>
>>> On Oct 2, 2017, at 1:17 PM, Chris Mattmann <ma...@apache.org>> wrote:
>>>
>>> Clearly, an SGA is intended for the copyright holder. If that’s an individual who as an
>>> individual represents those copyright holders, OK, but it’s gotta be pretty clear.
>>
>> That is a pretty high bar, and I've not seen it in practice. In order for an individual to own
>> the rights and grant those rights via an SGA, there would need to be some grant document
>> from the contributor to the individual(s) signing the SGA.
>
> +1 to what Craig is saying -- I've also seen a much laxer attitude in
> the past. The very questions
> I'm asking is whether we should consider tighten our practices or
> still allow SGAs that are lax.
>
> I'm actually working on a proposal right now for a project that
> existed on GitHub for sometime.
> I've assumed that an SGA *on behalf* of the community (but NOT from
> somebody who is legally
> speaking a copyright holder) will be a way to go.
Speaking as a non-lawyer, "You cannot grant rights that you do not own." And the following is strictly my own opinion.
A project that is licensed under alv2.0 and has existed for so long that the contributors cannot be found can still use code with the Apache license, but not with the Apache header.
If the project is currently licensed using the alv2.0 as its license, then the project can continue to use the license with its original headers and NOTICE.
Craig
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org<ma...@apache.org>
> For additional commands, e-mail: legal-discuss-help@apache.org<ma...@apache.org>
>
Craig L Russell
Secretary, Apache Software Foundation
clr@apache.org<ma...@apache.org> http://db.apache.org/jdo<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdb.apache.org%2Fjdo&data=02%7C01%7C%7Cea651c00eb9345f34ac008d50a8b5aa2%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636426515993386975&sdata=dLPPfurP0CIC7%2F3x69gH6Tsd4SKvBVzaPkPt51xvhmE%3D&reserved=0>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org<ma...@apache.org>
For additional commands, e-mail: legal-discuss-help@apache.org<ma...@apache.org>
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org<ma...@apache.org>
For additional commands, e-mail: legal-discuss-help@apache.org<ma...@apache.org>
Re: Podling CLA/Grant advice
Posted by Chris Mattmann <ma...@apache.org>.
Clarify this for me: did Amazon incept MXNet, and did they “own the IP” prior to coming to Apache?
If so, when the project came to Apache via Incubation, how did the code get transferred over? Did we
have an SGA on file beforehand (I’m guessing no).
Ideally the SGA is signed by the person who can sign it who most fits those options 1a/1b, or 2a/2b
I showed below. Which of the options most fits? As Alex points out, ideally a “signing authority” at
Amazon if the second paragraph is true is who would sign the SGA for the initial code drop. Who is
the right person at Amazon to sign it? (I have no clue, but worth asking)
Although an SGA is not needed, it’s always cleaner than not having one. Of course it should be signed
by the appropriate person. If we don’t have an SGA on file of course the project should proceed, and
the contributions for the project going forward are covered by those ICLAs we have on file for future
contributions and new contributors of the non “small” variety as previously discussed. For contributions
beforehand, without an SGA, yes, don’t modify the file headers, and consider what appropriate NOTICES
If any should be in the file.
YMMV.
Also can people please stop insta replying within 2-10 minutes. Think about what I am writing…and don’t
just instantly reply please.
Cheers,
Chris
From: <hy...@gmail.com> on behalf of Henri Yandell <he...@yandell.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Tuesday, October 3, 2017 at 11:38 AM
To: ASF Legal Discuss <le...@apache.org>
Subject: Re: Podling CLA/Grant advice
So you want an SGA to cover Mu's personal contributions from before 2017, in addition to the ICLA he has personally signed?
I'm sure he'd be okay signing that, but I'm struggling to understand why that has any value.
Hen
On Tue, Oct 3, 2017 at 11:19 AM, Chris Mattmann <ma...@apache.org> wrote:
Haha, cool, Hen.
If Amazon would be amenable having the original author who created the repo (is that an Amazon
employee) submit an SGA would be useful in my mind. Let us know if that can be arranged.
Yes repo & contribution analysis should be ongoing, but not a blocker on proceeding obviously since
MXNet has already made a release (though I know there were some concerns with the release perhaps
procedurally from what I’ve read on the threads).
Feel free to use my numbers ☺
Cheers,
Chris
From: <hy...@gmail.com> on behalf of Henri Yandell <he...@yandell.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Tuesday, October 3, 2017 at 11:14 AM
To: ASF Legal Discuss <le...@apache.org>
Subject: Re: Podling CLA/Grant advice
No, there's no SGA and no one to sign an SFA. Who would the SGA be with? Perhaps the original author who created the repository 2 years ago? He's already signed an ICLA.
Note that getting all Amazon employees to sign ICLAs (for those who havne't) is an easy task and would have limited impact on the numbers here. Amazon contributions from non-ICLA signers would have started ~Jan 2017, and it's arguable that contributions then were well aware they were a part of Apache as the project was reporting itself as having moved to Apache in Jan 2017 (though the GitHub change didn't happen until July). Basically there's unlikely to be much here unless Amazon happened to hire a historical contributor.
Opt-out would be one approach. Still lots of analysis to work out contribution triviality so I'd be tempted to simply contact everyone who has contributed pre-July, or pre-January.
Having specific numbers of what is trivial, what is major would be useful (as always). Your numbers are higher than I would come up with, so I prefer yours obviously :)
Hen
On Tue, Oct 3, 2017 at 11:05 AM, Chris Mattmann <ma...@apache.org> wrote:
Hi Hen,
While I understand the below, there is no need to make it more complicated then it has to be.
For MXNet, I assume there was an SGA filed, no? There only needs to be 1:1 on the project level,
and contributors don’t need to separately submit an SGA. I would assume you wouldn’t have to
email 380 people and that the initial SGA and whomever were specified on it in the attachment,
is sufficient to begin.
Then we look that we have ICLAs on file for all *major* and non 5-10 lines of code, or 30+ lines
of code, or some number N lines of code *contributors*, for commits and contributions going
forward. For those before hand, if there were 380 contributors, I’m assuming not all of them
were Amazon employees. However, perhaps within the 380, many were the 5-10 lines of code
variety, a fix here or there variety, etc etc. I know you can adopt an *opt out* rather than *opt in*
there. That is, leave the code in there. We assume good faith and that the person will want it there.
If they *don’t* want it there, and they make that known, we take it out (we only want code that
wants to be here).
Taking the above into account, I do not think it has to be harder than that. And the PMC is responsible
for IP management in relation to the code, so this is something the PPMC needs to decide. Consider the
above (and below else-thread) advice helping you all to come to your decisions ☺
Cheers,
Chris
From: <hy...@gmail.com> on behalf of Henri Yandell <he...@yandell.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Tuesday, October 3, 2017 at 1:37 AM
To: ASF Legal Discuss <le...@apache.org>
Subject: Re: Podling CLA/Grant advice
Here be dragons :)
In #1, there are two sets:
1a) The entity are the copyright holder for 100% of the work (ignoring clearly decoupled dependencies).
1b) The entity are a partial copyright holder of the work (ignoring deps), have received a license to the rest of the work, and have the rights to assign that license to Apache. The latter is probably rare, yet this option (1b) is most likely for any codebase that has been public. That is, we rely on the entity contributing the project to Apache to have clean IP, we don't rely on them to be able to hand over their clean IP to us.
I believe in #2 (below, not 1(b) above) that the git/github model has changed how we look at this. Historically we would have looked at the commits, but I don't believe we would have analysed the issue tracker. With pull requests on GitHub, folk who would have attached a patch to the issue tracker are now a part of the commit history and we see the authors increase by an order of magnitude.
Note that MXNet did have a form of IP management. As a user of the Apache 2.0 license every contribution to the project (per clause 5) was licensed under the Apache 2.0 license ('in/out licensing'). That's the same IP management Apache uses for contributions on JIRA/pull requests, both trivial and anything up to 'major' (where the occasional major contribution requires an SGA, or lazily (in a good way) an ICLA).
Going back to the original email; I'd like to know what to say to 380 people to explain why we need them to sign something. With a relicence it's easy, relicensing needs the copyright owner's permission, they are a copyright owner, please can we have permission. With this, not so easy. "We don't trust your contribution, please sign this SGA so we can trust your contribution"?
Hen
On Mon, Oct 2, 2017 at 6:21 PM, Chris Mattmann <ma...@apache.org> wrote:
Craig, I share the below opinions.
RE: SGA, let me clarify, I think there are a few situations:
1) SGA for a donation e.g., from a company or gov agency
a. The person providing or “granting” the SGA may have
the permission of the institution e.g., a signing authority, that
represents the IP from the company or agency, fine.
b. The person may be someone without signing authority but
designated by the agency as someone who can provide the Grant,
fine.
2) SGA for a donation e.g., from a set of contributors
a. The person providing or “granting” the SGA would ideally point to
some permanent URL or public URL with the decision by the binding
set of members of the contributors (at a minimum, within reason e.g.,
defined as all those active, or as all contributors ever, or all those
that responded to my email with a deadline of 2 weeks, or a month etc.)
b. If the community already uses some form of IP management besides
having a version repository and headers, etc., then pointing to those
on file would be useful and welcomed.
I’m sure there are variations on 1ab or 2ab but those are the ones fresh in my mind
with what I was talking about.
Thoughts, Craig? Roman?
Cheers,
Chris
On 10/2/17, 5:51 PM, "Craig Russell" <ap...@gmail.com> wrote:
> On Oct 2, 2017, at 5:23 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Mon, Oct 2, 2017 at 3:23 PM, Craig Russell <ap...@gmail.com> wrote:
>> Not to contradict our VP, Legal, just to clarify.
>>
>>> On Oct 2, 2017, at 1:17 PM, Chris Mattmann <ma...@apache.org> wrote:
>>>
>>> Clearly, an SGA is intended for the copyright holder. If that’s an individual who as an
>>> individual represents those copyright holders, OK, but it’s gotta be pretty clear.
>>
>> That is a pretty high bar, and I've not seen it in practice. In order for an individual to own
>> the rights and grant those rights via an SGA, there would need to be some grant document
>> from the contributor to the individual(s) signing the SGA.
>
> +1 to what Craig is saying -- I've also seen a much laxer attitude in
> the past. The very questions
> I'm asking is whether we should consider tighten our practices or
> still allow SGAs that are lax.
>
> I'm actually working on a proposal right now for a project that
> existed on GitHub for sometime.
> I've assumed that an SGA *on behalf* of the community (but NOT from
> somebody who is legally
> speaking a copyright holder) will be a way to go.
Speaking as a non-lawyer, "You cannot grant rights that you do not own." And the following is strictly my own opinion.
A project that is licensed under alv2.0 and has existed for so long that the contributors cannot be found can still use code with the Apache license, but not with the Apache header.
If the project is currently licensed using the alv2.0 as its license, then the project can continue to use the license with its original headers and NOTICE.
Craig
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> 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: Podling CLA/Grant advice
Posted by Henri Yandell <he...@yandell.org>.
So you want an SGA to cover Mu's personal contributions from before 2017,
in addition to the ICLA he has personally signed?
I'm sure he'd be okay signing that, but I'm struggling to understand why
that has any value.
Hen
On Tue, Oct 3, 2017 at 11:19 AM, Chris Mattmann <ma...@apache.org> wrote:
> Haha, cool, Hen.
>
>
>
> If Amazon would be amenable having the original author who created the
> repo (is that an Amazon
> employee) submit an SGA would be useful in my mind. Let us know if that
> can be arranged.
>
>
>
> Yes repo & contribution analysis should be ongoing, but not a blocker on
> proceeding obviously since
> MXNet has already made a release (though I know there were some concerns
> with the release perhaps
> procedurally from what I’ve read on the threads).
>
>
>
> Feel free to use my numbers ☺
>
>
>
> Cheers,
>
> Chris
>
>
>
>
>
>
>
>
>
> *From: *<hy...@gmail.com> on behalf of Henri Yandell <henri@yandell.org
> >
> *Reply-To: *"legal-discuss@apache.org" <le...@apache.org>
> *Date: *Tuesday, October 3, 2017 at 11:14 AM
>
> *To: *ASF Legal Discuss <le...@apache.org>
> *Subject: *Re: Podling CLA/Grant advice
>
>
>
> No, there's no SGA and no one to sign an SFA. Who would the SGA be with?
> Perhaps the original author who created the repository 2 years ago? He's
> already signed an ICLA.
>
> Note that getting all Amazon employees to sign ICLAs (for those who
> havne't) is an easy task and would have limited impact on the numbers here.
> Amazon contributions from non-ICLA signers would have started ~Jan 2017,
> and it's arguable that contributions then were well aware they were a part
> of Apache as the project was reporting itself as having moved to Apache in
> Jan 2017 (though the GitHub change didn't happen until July). Basically
> there's unlikely to be much here unless Amazon happened to hire a
> historical contributor.
>
> Opt-out would be one approach. Still lots of analysis to work out
> contribution triviality so I'd be tempted to simply contact everyone who
> has contributed pre-July, or pre-January.
>
> Having specific numbers of what is trivial, what is major would be useful
> (as always). Your numbers are higher than I would come up with, so I prefer
> yours obviously :)
>
>
>
> Hen
>
>
>
> On Tue, Oct 3, 2017 at 11:05 AM, Chris Mattmann <ma...@apache.org>
> wrote:
>
> Hi Hen,
>
>
>
> While I understand the below, there is no need to make it more complicated
> then it has to be.
>
>
>
> For MXNet, I assume there was an SGA filed, no? There only needs to be 1:1
> on the project level,
> and contributors don’t need to separately submit an SGA. I would assume
> you wouldn’t have to
> email 380 people and that the initial SGA and whomever were specified on
> it in the attachment,
> is sufficient to begin.
>
>
>
> Then we look that we have ICLAs on file for all **major** and non 5-10
> lines of code, or 30+ lines
> of code, or some number N lines of code **contributors**, for commits and
> contributions going
> forward. For those before hand, if there were 380 contributors, I’m
> assuming not all of them
> were Amazon employees. However, perhaps within the 380, many were the 5-10
> lines of code
> variety, a fix here or there variety, etc etc. I know you can adopt an **opt
> out** rather than **opt in**
> there. That is, leave the code in there. We assume good faith and that the
> person will want it there.
> If they **don’t** want it there, and they make that known, we take it out
> (we only want code that
> wants to be here).
>
>
>
> Taking the above into account, I do not think it has to be harder than
> that. And the PMC is responsible
> for IP management in relation to the code, so this is something the PPMC
> needs to decide. Consider the
> above (and below else-thread) advice helping you all to come to your
> decisions ☺
>
>
>
> Cheers,
>
> Chris
>
>
>
>
>
>
>
>
>
> *From: *<hy...@gmail.com> on behalf of Henri Yandell <henri@yandell.org
> >
> *Reply-To: *"legal-discuss@apache.org" <le...@apache.org>
> *Date: *Tuesday, October 3, 2017 at 1:37 AM
> *To: *ASF Legal Discuss <le...@apache.org>
> *Subject: *Re: Podling CLA/Grant advice
>
>
>
>
>
> Here be dragons :)
>
>
>
> In #1, there are two sets:
>
> 1a) The entity are the copyright holder for 100% of the work (ignoring
> clearly decoupled dependencies).
>
> 1b) The entity are a partial copyright holder of the work (ignoring deps),
> have received a license to the rest of the work, and have the rights to
> assign that license to Apache. The latter is probably rare, yet this option
> (1b) is most likely for any codebase that has been public. That is, we rely
> on the entity contributing the project to Apache to have clean IP, we don't
> rely on them to be able to hand over their clean IP to us.
>
> I believe in #2 (below, not 1(b) above) that the git/github model has
> changed how we look at this. Historically we would have looked at the
> commits, but I don't believe we would have analysed the issue tracker. With
> pull requests on GitHub, folk who would have attached a patch to the issue
> tracker are now a part of the commit history and we see the authors
> increase by an order of magnitude.
>
>
>
> Note that MXNet did have a form of IP management. As a user of the Apache
> 2.0 license every contribution to the project (per clause 5) was licensed
> under the Apache 2.0 license ('in/out licensing'). That's the same IP
> management Apache uses for contributions on JIRA/pull requests, both
> trivial and anything up to 'major' (where the occasional major contribution
> requires an SGA, or lazily (in a good way) an ICLA).
>
> Going back to the original email; I'd like to know what to say to 380
> people to explain why we need them to sign something. With a relicence it's
> easy, relicensing needs the copyright owner's permission, they are a
> copyright owner, please can we have permission. With this, not so easy.
> "We don't trust your contribution, please sign this SGA so we can trust
> your contribution"?
>
>
>
> Hen
>
>
>
> On Mon, Oct 2, 2017 at 6:21 PM, Chris Mattmann <ma...@apache.org>
> wrote:
>
> Craig, I share the below opinions.
>
> RE: SGA, let me clarify, I think there are a few situations:
>
>
> 1) SGA for a donation e.g., from a company or gov agency
> a. The person providing or “granting” the SGA may have
> the permission of the institution e.g., a signing authority, that
> represents the IP from the company or agency, fine.
> b. The person may be someone without signing authority but
> designated by the agency as someone who can provide the Grant,
> fine.
> 2) SGA for a donation e.g., from a set of contributors
> a. The person providing or “granting” the SGA would ideally point to
> some permanent URL or public URL with the decision by the binding
> set of members of the contributors (at a minimum, within reason e.g.,
> defined as all those active, or as all contributors ever, or all those
> that responded to my email with a deadline of 2 weeks, or a month etc.)
> b. If the community already uses some form of IP management besides
> having a version repository and headers, etc., then pointing to those
> on file would be useful and welcomed.
>
> I’m sure there are variations on 1ab or 2ab but those are the ones fresh
> in my mind
> with what I was talking about.
>
> Thoughts, Craig? Roman?
>
> Cheers,
> Chris
>
>
>
>
>
> On 10/2/17, 5:51 PM, "Craig Russell" <ap...@gmail.com> wrote:
>
>
> > On Oct 2, 2017, at 5:23 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> >
> > On Mon, Oct 2, 2017 at 3:23 PM, Craig Russell <ap...@gmail.com>
> wrote:
> >> Not to contradict our VP, Legal, just to clarify.
> >>
> >>> On Oct 2, 2017, at 1:17 PM, Chris Mattmann <ma...@apache.org>
> wrote:
> >>>
> >>> Clearly, an SGA is intended for the copyright holder. If that’s an
> individual who as an
> >>> individual represents those copyright holders, OK, but it’s gotta
> be pretty clear.
> >>
> >> That is a pretty high bar, and I've not seen it in practice. In
> order for an individual to own
> >> the rights and grant those rights via an SGA, there would need to
> be some grant document
> >> from the contributor to the individual(s) signing the SGA.
> >
> > +1 to what Craig is saying -- I've also seen a much laxer attitude in
> > the past. The very questions
> > I'm asking is whether we should consider tighten our practices or
> > still allow SGAs that are lax.
> >
> > I'm actually working on a proposal right now for a project that
> > existed on GitHub for sometime.
> > I've assumed that an SGA *on behalf* of the community (but NOT from
> > somebody who is legally
> > speaking a copyright holder) will be a way to go.
>
> Speaking as a non-lawyer, "You cannot grant rights that you do not
> own." And the following is strictly my own opinion.
>
> A project that is licensed under alv2.0 and has existed for so long
> that the contributors cannot be found can still use code with the Apache
> license, but not with the Apache header.
>
> If the project is currently licensed using the alv2.0 as its license,
> then the project can continue to use the license with its original headers
> and NOTICE.
>
> Craig
>
> >
> > Thanks,
> > Roman.
> >
> > ------------------------------------------------------------
> ---------
> > 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: Podling CLA/Grant advice
Posted by Chris Mattmann <ma...@apache.org>.
Haha, cool, Hen.
If Amazon would be amenable having the original author who created the repo (is that an Amazon
employee) submit an SGA would be useful in my mind. Let us know if that can be arranged.
Yes repo & contribution analysis should be ongoing, but not a blocker on proceeding obviously since
MXNet has already made a release (though I know there were some concerns with the release perhaps
procedurally from what I’ve read on the threads).
Feel free to use my numbers ☺
Cheers,
Chris
From: <hy...@gmail.com> on behalf of Henri Yandell <he...@yandell.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Tuesday, October 3, 2017 at 11:14 AM
To: ASF Legal Discuss <le...@apache.org>
Subject: Re: Podling CLA/Grant advice
No, there's no SGA and no one to sign an SFA. Who would the SGA be with? Perhaps the original author who created the repository 2 years ago? He's already signed an ICLA.
Note that getting all Amazon employees to sign ICLAs (for those who havne't) is an easy task and would have limited impact on the numbers here. Amazon contributions from non-ICLA signers would have started ~Jan 2017, and it's arguable that contributions then were well aware they were a part of Apache as the project was reporting itself as having moved to Apache in Jan 2017 (though the GitHub change didn't happen until July). Basically there's unlikely to be much here unless Amazon happened to hire a historical contributor.
Opt-out would be one approach. Still lots of analysis to work out contribution triviality so I'd be tempted to simply contact everyone who has contributed pre-July, or pre-January.
Having specific numbers of what is trivial, what is major would be useful (as always). Your numbers are higher than I would come up with, so I prefer yours obviously :)
Hen
On Tue, Oct 3, 2017 at 11:05 AM, Chris Mattmann <ma...@apache.org> wrote:
Hi Hen,
While I understand the below, there is no need to make it more complicated then it has to be.
For MXNet, I assume there was an SGA filed, no? There only needs to be 1:1 on the project level,
and contributors don’t need to separately submit an SGA. I would assume you wouldn’t have to
email 380 people and that the initial SGA and whomever were specified on it in the attachment,
is sufficient to begin.
Then we look that we have ICLAs on file for all *major* and non 5-10 lines of code, or 30+ lines
of code, or some number N lines of code *contributors*, for commits and contributions going
forward. For those before hand, if there were 380 contributors, I’m assuming not all of them
were Amazon employees. However, perhaps within the 380, many were the 5-10 lines of code
variety, a fix here or there variety, etc etc. I know you can adopt an *opt out* rather than *opt in*
there. That is, leave the code in there. We assume good faith and that the person will want it there.
If they *don’t* want it there, and they make that known, we take it out (we only want code that
wants to be here).
Taking the above into account, I do not think it has to be harder than that. And the PMC is responsible
for IP management in relation to the code, so this is something the PPMC needs to decide. Consider the
above (and below else-thread) advice helping you all to come to your decisions ☺
Cheers,
Chris
From: <hy...@gmail.com> on behalf of Henri Yandell <he...@yandell.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Tuesday, October 3, 2017 at 1:37 AM
To: ASF Legal Discuss <le...@apache.org>
Subject: Re: Podling CLA/Grant advice
Here be dragons :)
In #1, there are two sets:
1a) The entity are the copyright holder for 100% of the work (ignoring clearly decoupled dependencies).
1b) The entity are a partial copyright holder of the work (ignoring deps), have received a license to the rest of the work, and have the rights to assign that license to Apache. The latter is probably rare, yet this option (1b) is most likely for any codebase that has been public. That is, we rely on the entity contributing the project to Apache to have clean IP, we don't rely on them to be able to hand over their clean IP to us.
I believe in #2 (below, not 1(b) above) that the git/github model has changed how we look at this. Historically we would have looked at the commits, but I don't believe we would have analysed the issue tracker. With pull requests on GitHub, folk who would have attached a patch to the issue tracker are now a part of the commit history and we see the authors increase by an order of magnitude.
Note that MXNet did have a form of IP management. As a user of the Apache 2.0 license every contribution to the project (per clause 5) was licensed under the Apache 2.0 license ('in/out licensing'). That's the same IP management Apache uses for contributions on JIRA/pull requests, both trivial and anything up to 'major' (where the occasional major contribution requires an SGA, or lazily (in a good way) an ICLA).
Going back to the original email; I'd like to know what to say to 380 people to explain why we need them to sign something. With a relicence it's easy, relicensing needs the copyright owner's permission, they are a copyright owner, please can we have permission. With this, not so easy. "We don't trust your contribution, please sign this SGA so we can trust your contribution"?
Hen
On Mon, Oct 2, 2017 at 6:21 PM, Chris Mattmann <ma...@apache.org> wrote:
Craig, I share the below opinions.
RE: SGA, let me clarify, I think there are a few situations:
1) SGA for a donation e.g., from a company or gov agency
a. The person providing or “granting” the SGA may have
the permission of the institution e.g., a signing authority, that
represents the IP from the company or agency, fine.
b. The person may be someone without signing authority but
designated by the agency as someone who can provide the Grant,
fine.
2) SGA for a donation e.g., from a set of contributors
a. The person providing or “granting” the SGA would ideally point to
some permanent URL or public URL with the decision by the binding
set of members of the contributors (at a minimum, within reason e.g.,
defined as all those active, or as all contributors ever, or all those
that responded to my email with a deadline of 2 weeks, or a month etc.)
b. If the community already uses some form of IP management besides
having a version repository and headers, etc., then pointing to those
on file would be useful and welcomed.
I’m sure there are variations on 1ab or 2ab but those are the ones fresh in my mind
with what I was talking about.
Thoughts, Craig? Roman?
Cheers,
Chris
On 10/2/17, 5:51 PM, "Craig Russell" <ap...@gmail.com> wrote:
> On Oct 2, 2017, at 5:23 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Mon, Oct 2, 2017 at 3:23 PM, Craig Russell <ap...@gmail.com> wrote:
>> Not to contradict our VP, Legal, just to clarify.
>>
>>> On Oct 2, 2017, at 1:17 PM, Chris Mattmann <ma...@apache.org> wrote:
>>>
>>> Clearly, an SGA is intended for the copyright holder. If that’s an individual who as an
>>> individual represents those copyright holders, OK, but it’s gotta be pretty clear.
>>
>> That is a pretty high bar, and I've not seen it in practice. In order for an individual to own
>> the rights and grant those rights via an SGA, there would need to be some grant document
>> from the contributor to the individual(s) signing the SGA.
>
> +1 to what Craig is saying -- I've also seen a much laxer attitude in
> the past. The very questions
> I'm asking is whether we should consider tighten our practices or
> still allow SGAs that are lax.
>
> I'm actually working on a proposal right now for a project that
> existed on GitHub for sometime.
> I've assumed that an SGA *on behalf* of the community (but NOT from
> somebody who is legally
> speaking a copyright holder) will be a way to go.
Speaking as a non-lawyer, "You cannot grant rights that you do not own." And the following is strictly my own opinion.
A project that is licensed under alv2.0 and has existed for so long that the contributors cannot be found can still use code with the Apache license, but not with the Apache header.
If the project is currently licensed using the alv2.0 as its license, then the project can continue to use the license with its original headers and NOTICE.
Craig
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> 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: Podling CLA/Grant advice
Posted by Henri Yandell <he...@yandell.org>.
No, there's no SGA and no one to sign an SFA. Who would the SGA be with?
Perhaps the original author who created the repository 2 years ago? He's
already signed an ICLA.
Note that getting all Amazon employees to sign ICLAs (for those who
havne't) is an easy task and would have limited impact on the numbers here.
Amazon contributions from non-ICLA signers would have started ~Jan 2017,
and it's arguable that contributions then were well aware they were a part
of Apache as the project was reporting itself as having moved to Apache in
Jan 2017 (though the GitHub change didn't happen until July). Basically
there's unlikely to be much here unless Amazon happened to hire a
historical contributor.
Opt-out would be one approach. Still lots of analysis to work out
contribution triviality so I'd be tempted to simply contact everyone who
has contributed pre-July, or pre-January.
Having specific numbers of what is trivial, what is major would be useful
(as always). Your numbers are higher than I would come up with, so I prefer
yours obviously :)
Hen
On Tue, Oct 3, 2017 at 11:05 AM, Chris Mattmann <ma...@apache.org> wrote:
> Hi Hen,
>
>
>
> While I understand the below, there is no need to make it more complicated
> then it has to be.
>
>
>
> For MXNet, I assume there was an SGA filed, no? There only needs to be 1:1
> on the project level,
> and contributors don’t need to separately submit an SGA. I would assume
> you wouldn’t have to
> email 380 people and that the initial SGA and whomever were specified on
> it in the attachment,
> is sufficient to begin.
>
>
>
> Then we look that we have ICLAs on file for all **major** and non 5-10
> lines of code, or 30+ lines
> of code, or some number N lines of code **contributors**, for commits and
> contributions going
> forward. For those before hand, if there were 380 contributors, I’m
> assuming not all of them
> were Amazon employees. However, perhaps within the 380, many were the 5-10
> lines of code
> variety, a fix here or there variety, etc etc. I know you can adopt an **opt
> out** rather than **opt in**
> there. That is, leave the code in there. We assume good faith and that the
> person will want it there.
> If they **don’t** want it there, and they make that known, we take it out
> (we only want code that
> wants to be here).
>
>
>
> Taking the above into account, I do not think it has to be harder than
> that. And the PMC is responsible
> for IP management in relation to the code, so this is something the PPMC
> needs to decide. Consider the
> above (and below else-thread) advice helping you all to come to your
> decisions ☺
>
>
>
> Cheers,
>
> Chris
>
>
>
>
>
>
>
>
>
> *From: *<hy...@gmail.com> on behalf of Henri Yandell <henri@yandell.org
> >
> *Reply-To: *"legal-discuss@apache.org" <le...@apache.org>
> *Date: *Tuesday, October 3, 2017 at 1:37 AM
> *To: *ASF Legal Discuss <le...@apache.org>
> *Subject: *Re: Podling CLA/Grant advice
>
>
>
>
>
> Here be dragons :)
>
>
>
> In #1, there are two sets:
>
> 1a) The entity are the copyright holder for 100% of the work (ignoring
> clearly decoupled dependencies).
>
> 1b) The entity are a partial copyright holder of the work (ignoring deps),
> have received a license to the rest of the work, and have the rights to
> assign that license to Apache. The latter is probably rare, yet this option
> (1b) is most likely for any codebase that has been public. That is, we rely
> on the entity contributing the project to Apache to have clean IP, we don't
> rely on them to be able to hand over their clean IP to us.
>
> I believe in #2 (below, not 1(b) above) that the git/github model has
> changed how we look at this. Historically we would have looked at the
> commits, but I don't believe we would have analysed the issue tracker. With
> pull requests on GitHub, folk who would have attached a patch to the issue
> tracker are now a part of the commit history and we see the authors
> increase by an order of magnitude.
>
>
>
> Note that MXNet did have a form of IP management. As a user of the Apache
> 2.0 license every contribution to the project (per clause 5) was licensed
> under the Apache 2.0 license ('in/out licensing'). That's the same IP
> management Apache uses for contributions on JIRA/pull requests, both
> trivial and anything up to 'major' (where the occasional major contribution
> requires an SGA, or lazily (in a good way) an ICLA).
>
> Going back to the original email; I'd like to know what to say to 380
> people to explain why we need them to sign something. With a relicence it's
> easy, relicensing needs the copyright owner's permission, they are a
> copyright owner, please can we have permission. With this, not so easy.
> "We don't trust your contribution, please sign this SGA so we can trust
> your contribution"?
>
>
>
> Hen
>
>
>
> On Mon, Oct 2, 2017 at 6:21 PM, Chris Mattmann <ma...@apache.org>
> wrote:
>
> Craig, I share the below opinions.
>
> RE: SGA, let me clarify, I think there are a few situations:
>
>
> 1) SGA for a donation e.g., from a company or gov agency
> a. The person providing or “granting” the SGA may have
> the permission of the institution e.g., a signing authority, that
> represents the IP from the company or agency, fine.
> b. The person may be someone without signing authority but
> designated by the agency as someone who can provide the Grant,
> fine.
> 2) SGA for a donation e.g., from a set of contributors
> a. The person providing or “granting” the SGA would ideally point to
> some permanent URL or public URL with the decision by the binding
> set of members of the contributors (at a minimum, within reason e.g.,
> defined as all those active, or as all contributors ever, or all those
> that responded to my email with a deadline of 2 weeks, or a month etc.)
> b. If the community already uses some form of IP management besides
> having a version repository and headers, etc., then pointing to those
> on file would be useful and welcomed.
>
> I’m sure there are variations on 1ab or 2ab but those are the ones fresh
> in my mind
> with what I was talking about.
>
> Thoughts, Craig? Roman?
>
> Cheers,
> Chris
>
>
>
>
>
> On 10/2/17, 5:51 PM, "Craig Russell" <ap...@gmail.com> wrote:
>
>
> > On Oct 2, 2017, at 5:23 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> >
> > On Mon, Oct 2, 2017 at 3:23 PM, Craig Russell <ap...@gmail.com>
> wrote:
> >> Not to contradict our VP, Legal, just to clarify.
> >>
> >>> On Oct 2, 2017, at 1:17 PM, Chris Mattmann <ma...@apache.org>
> wrote:
> >>>
> >>> Clearly, an SGA is intended for the copyright holder. If that’s an
> individual who as an
> >>> individual represents those copyright holders, OK, but it’s gotta
> be pretty clear.
> >>
> >> That is a pretty high bar, and I've not seen it in practice. In
> order for an individual to own
> >> the rights and grant those rights via an SGA, there would need to
> be some grant document
> >> from the contributor to the individual(s) signing the SGA.
> >
> > +1 to what Craig is saying -- I've also seen a much laxer attitude in
> > the past. The very questions
> > I'm asking is whether we should consider tighten our practices or
> > still allow SGAs that are lax.
> >
> > I'm actually working on a proposal right now for a project that
> > existed on GitHub for sometime.
> > I've assumed that an SGA *on behalf* of the community (but NOT from
> > somebody who is legally
> > speaking a copyright holder) will be a way to go.
>
> Speaking as a non-lawyer, "You cannot grant rights that you do not
> own." And the following is strictly my own opinion.
>
> A project that is licensed under alv2.0 and has existed for so long
> that the contributors cannot be found can still use code with the Apache
> license, but not with the Apache header.
>
> If the project is currently licensed using the alv2.0 as its license,
> then the project can continue to use the license with its original headers
> and NOTICE.
>
> Craig
>
> >
> > Thanks,
> > Roman.
> >
> > ------------------------------------------------------------
> ---------
> > 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: Podling CLA/Grant advice
Posted by Chris Mattmann <ma...@apache.org>.
Hi Hen,
While I understand the below, there is no need to make it more complicated then it has to be.
For MXNet, I assume there was an SGA filed, no? There only needs to be 1:1 on the project level,
and contributors don’t need to separately submit an SGA. I would assume you wouldn’t have to
email 380 people and that the initial SGA and whomever were specified on it in the attachment,
is sufficient to begin.
Then we look that we have ICLAs on file for all *major* and non 5-10 lines of code, or 30+ lines
of code, or some number N lines of code *contributors*, for commits and contributions going
forward. For those before hand, if there were 380 contributors, I’m assuming not all of them
were Amazon employees. However, perhaps within the 380, many were the 5-10 lines of code
variety, a fix here or there variety, etc etc. I know you can adopt an *opt out* rather than *opt in*
there. That is, leave the code in there. We assume good faith and that the person will want it there.
If they *don’t* want it there, and they make that known, we take it out (we only want code that
wants to be here).
Taking the above into account, I do not think it has to be harder than that. And the PMC is responsible
for IP management in relation to the code, so this is something the PPMC needs to decide. Consider the
above (and below else-thread) advice helping you all to come to your decisions ☺
Cheers,
Chris
From: <hy...@gmail.com> on behalf of Henri Yandell <he...@yandell.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Tuesday, October 3, 2017 at 1:37 AM
To: ASF Legal Discuss <le...@apache.org>
Subject: Re: Podling CLA/Grant advice
Here be dragons :)
In #1, there are two sets:
1a) The entity are the copyright holder for 100% of the work (ignoring clearly decoupled dependencies).
1b) The entity are a partial copyright holder of the work (ignoring deps), have received a license to the rest of the work, and have the rights to assign that license to Apache. The latter is probably rare, yet this option (1b) is most likely for any codebase that has been public. That is, we rely on the entity contributing the project to Apache to have clean IP, we don't rely on them to be able to hand over their clean IP to us.
I believe in #2 (below, not 1(b) above) that the git/github model has changed how we look at this. Historically we would have looked at the commits, but I don't believe we would have analysed the issue tracker. With pull requests on GitHub, folk who would have attached a patch to the issue tracker are now a part of the commit history and we see the authors increase by an order of magnitude.
Note that MXNet did have a form of IP management. As a user of the Apache 2.0 license every contribution to the project (per clause 5) was licensed under the Apache 2.0 license ('in/out licensing'). That's the same IP management Apache uses for contributions on JIRA/pull requests, both trivial and anything up to 'major' (where the occasional major contribution requires an SGA, or lazily (in a good way) an ICLA).
Going back to the original email; I'd like to know what to say to 380 people to explain why we need them to sign something. With a relicence it's easy, relicensing needs the copyright owner's permission, they are a copyright owner, please can we have permission. With this, not so easy. "We don't trust your contribution, please sign this SGA so we can trust your contribution"?
Hen
On Mon, Oct 2, 2017 at 6:21 PM, Chris Mattmann <ma...@apache.org> wrote:
Craig, I share the below opinions.
RE: SGA, let me clarify, I think there are a few situations:
1) SGA for a donation e.g., from a company or gov agency
a. The person providing or “granting” the SGA may have
the permission of the institution e.g., a signing authority, that
represents the IP from the company or agency, fine.
b. The person may be someone without signing authority but
designated by the agency as someone who can provide the Grant,
fine.
2) SGA for a donation e.g., from a set of contributors
a. The person providing or “granting” the SGA would ideally point to
some permanent URL or public URL with the decision by the binding
set of members of the contributors (at a minimum, within reason e.g.,
defined as all those active, or as all contributors ever, or all those
that responded to my email with a deadline of 2 weeks, or a month etc.)
b. If the community already uses some form of IP management besides
having a version repository and headers, etc., then pointing to those
on file would be useful and welcomed.
I’m sure there are variations on 1ab or 2ab but those are the ones fresh in my mind
with what I was talking about.
Thoughts, Craig? Roman?
Cheers,
Chris
On 10/2/17, 5:51 PM, "Craig Russell" <ap...@gmail.com> wrote:
> On Oct 2, 2017, at 5:23 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Mon, Oct 2, 2017 at 3:23 PM, Craig Russell <ap...@gmail.com> wrote:
>> Not to contradict our VP, Legal, just to clarify.
>>
>>> On Oct 2, 2017, at 1:17 PM, Chris Mattmann <ma...@apache.org> wrote:
>>>
>>> Clearly, an SGA is intended for the copyright holder. If that’s an individual who as an
>>> individual represents those copyright holders, OK, but it’s gotta be pretty clear.
>>
>> That is a pretty high bar, and I've not seen it in practice. In order for an individual to own
>> the rights and grant those rights via an SGA, there would need to be some grant document
>> from the contributor to the individual(s) signing the SGA.
>
> +1 to what Craig is saying -- I've also seen a much laxer attitude in
> the past. The very questions
> I'm asking is whether we should consider tighten our practices or
> still allow SGAs that are lax.
>
> I'm actually working on a proposal right now for a project that
> existed on GitHub for sometime.
> I've assumed that an SGA *on behalf* of the community (but NOT from
> somebody who is legally
> speaking a copyright holder) will be a way to go.
Speaking as a non-lawyer, "You cannot grant rights that you do not own." And the following is strictly my own opinion.
A project that is licensed under alv2.0 and has existed for so long that the contributors cannot be found can still use code with the Apache license, but not with the Apache header.
If the project is currently licensed using the alv2.0 as its license, then the project can continue to use the license with its original headers and NOTICE.
Craig
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> 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: Podling CLA/Grant advice
Posted by Henri Yandell <he...@yandell.org>.
Here be dragons :)
In #1, there are two sets:
1a) The entity are the copyright holder for 100% of the work (ignoring
clearly decoupled dependencies).
1b) The entity are a partial copyright holder of the work (ignoring deps),
have received a license to the rest of the work, and have the rights to
assign that license to Apache. The latter is probably rare, yet this option
(1b) is most likely for any codebase that has been public. That is, we rely
on the entity contributing the project to Apache to have clean IP, we don't
rely on them to be able to hand over their clean IP to us.
I believe in #2 (below, not 1(b) above) that the git/github model has
changed how we look at this. Historically we would have looked at the
commits, but I don't believe we would have analysed the issue tracker. With
pull requests on GitHub, folk who would have attached a patch to the issue
tracker are now a part of the commit history and we see the authors
increase by an order of magnitude.
Note that MXNet did have a form of IP management. As a user of the Apache
2.0 license every contribution to the project (per clause 5) was licensed
under the Apache 2.0 license ('in/out licensing'). That's the same IP
management Apache uses for contributions on JIRA/pull requests, both
trivial and anything up to 'major' (where the occasional major contribution
requires an SGA, or lazily (in a good way) an ICLA).
Going back to the original email; I'd like to know what to say to 380
people to explain why we need them to sign something. With a relicence it's
easy, relicensing needs the copyright owner's permission, they are a
copyright owner, please can we have permission. With this, not so easy.
"We don't trust your contribution, please sign this SGA so we can trust
your contribution"?
Hen
On Mon, Oct 2, 2017 at 6:21 PM, Chris Mattmann <ma...@apache.org> wrote:
> Craig, I share the below opinions.
>
> RE: SGA, let me clarify, I think there are a few situations:
>
>
> 1) SGA for a donation e.g., from a company or gov agency
> a. The person providing or “granting” the SGA may have
> the permission of the institution e.g., a signing authority, that
> represents the IP from the company or agency, fine.
> b. The person may be someone without signing authority but
> designated by the agency as someone who can provide the Grant,
> fine.
> 2) SGA for a donation e.g., from a set of contributors
> a. The person providing or “granting” the SGA would ideally point to
> some permanent URL or public URL with the decision by the binding
> set of members of the contributors (at a minimum, within reason e.g.,
> defined as all those active, or as all contributors ever, or all those
> that responded to my email with a deadline of 2 weeks, or a month etc.)
> b. If the community already uses some form of IP management besides
> having a version repository and headers, etc., then pointing to those
> on file would be useful and welcomed.
>
> I’m sure there are variations on 1ab or 2ab but those are the ones fresh
> in my mind
> with what I was talking about.
>
> Thoughts, Craig? Roman?
>
> Cheers,
> Chris
>
>
>
>
> On 10/2/17, 5:51 PM, "Craig Russell" <ap...@gmail.com> wrote:
>
>
> > On Oct 2, 2017, at 5:23 PM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> >
> > On Mon, Oct 2, 2017 at 3:23 PM, Craig Russell <ap...@gmail.com>
> wrote:
> >> Not to contradict our VP, Legal, just to clarify.
> >>
> >>> On Oct 2, 2017, at 1:17 PM, Chris Mattmann <ma...@apache.org>
> wrote:
> >>>
> >>> Clearly, an SGA is intended for the copyright holder. If that’s an
> individual who as an
> >>> individual represents those copyright holders, OK, but it’s gotta
> be pretty clear.
> >>
> >> That is a pretty high bar, and I've not seen it in practice. In
> order for an individual to own
> >> the rights and grant those rights via an SGA, there would need to
> be some grant document
> >> from the contributor to the individual(s) signing the SGA.
> >
> > +1 to what Craig is saying -- I've also seen a much laxer attitude in
> > the past. The very questions
> > I'm asking is whether we should consider tighten our practices or
> > still allow SGAs that are lax.
> >
> > I'm actually working on a proposal right now for a project that
> > existed on GitHub for sometime.
> > I've assumed that an SGA *on behalf* of the community (but NOT from
> > somebody who is legally
> > speaking a copyright holder) will be a way to go.
>
> Speaking as a non-lawyer, "You cannot grant rights that you do not
> own." And the following is strictly my own opinion.
>
> A project that is licensed under alv2.0 and has existed for so long
> that the contributors cannot be found can still use code with the Apache
> license, but not with the Apache header.
>
> If the project is currently licensed using the alv2.0 as its license,
> then the project can continue to use the license with its original headers
> and NOTICE.
>
> Craig
>
> >
> > Thanks,
> > Roman.
> >
> > ------------------------------------------------------------
> ---------
> > 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: Podling CLA/Grant advice
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Mon, Oct 2, 2017 at 6:21 PM, Chris Mattmann <ma...@apache.org> wrote:
> Craig, I share the below opinions.
>
> RE: SGA, let me clarify, I think there are a few situations:
>
>
> 1) SGA for a donation e.g., from a company or gov agency
> a. The person providing or “granting” the SGA may have
> the permission of the institution e.g., a signing authority, that
> represents the IP from the company or agency, fine.
> b. The person may be someone without signing authority but
> designated by the agency as someone who can provide the Grant,
> fine.
Correct.
> 2) SGA for a donation e.g., from a set of contributors
> a. The person providing or “granting” the SGA would ideally point to
> some permanent URL or public URL with the decision by the binding
> set of members of the contributors (at a minimum, within reason e.g.,
> defined as all those active, or as all contributors ever, or all those
> that responded to my email with a deadline of 2 weeks, or a month etc.)
This is what I've seen with most existing projects without an active
corporate sponsor.
> b. If the community already uses some form of IP management besides
> having a version repository and headers, etc., then pointing to those
> on file would be useful and welcomed.
This one exists but is rare in my experience. More likely to be a single
corporate sponsor project which will probably get us squarely back to #1.
So yes -- this is the full list of options that come to mind.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Podling CLA/Grant advice
Posted by Chris Mattmann <ma...@apache.org>.
Craig, I share the below opinions.
RE: SGA, let me clarify, I think there are a few situations:
1) SGA for a donation e.g., from a company or gov agency
a. The person providing or “granting” the SGA may have
the permission of the institution e.g., a signing authority, that
represents the IP from the company or agency, fine.
b. The person may be someone without signing authority but
designated by the agency as someone who can provide the Grant,
fine.
2) SGA for a donation e.g., from a set of contributors
a. The person providing or “granting” the SGA would ideally point to
some permanent URL or public URL with the decision by the binding
set of members of the contributors (at a minimum, within reason e.g.,
defined as all those active, or as all contributors ever, or all those
that responded to my email with a deadline of 2 weeks, or a month etc.)
b. If the community already uses some form of IP management besides
having a version repository and headers, etc., then pointing to those
on file would be useful and welcomed.
I’m sure there are variations on 1ab or 2ab but those are the ones fresh in my mind
with what I was talking about.
Thoughts, Craig? Roman?
Cheers,
Chris
On 10/2/17, 5:51 PM, "Craig Russell" <ap...@gmail.com> wrote:
> On Oct 2, 2017, at 5:23 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Mon, Oct 2, 2017 at 3:23 PM, Craig Russell <ap...@gmail.com> wrote:
>> Not to contradict our VP, Legal, just to clarify.
>>
>>> On Oct 2, 2017, at 1:17 PM, Chris Mattmann <ma...@apache.org> wrote:
>>>
>>> Clearly, an SGA is intended for the copyright holder. If that’s an individual who as an
>>> individual represents those copyright holders, OK, but it’s gotta be pretty clear.
>>
>> That is a pretty high bar, and I've not seen it in practice. In order for an individual to own
>> the rights and grant those rights via an SGA, there would need to be some grant document
>> from the contributor to the individual(s) signing the SGA.
>
> +1 to what Craig is saying -- I've also seen a much laxer attitude in
> the past. The very questions
> I'm asking is whether we should consider tighten our practices or
> still allow SGAs that are lax.
>
> I'm actually working on a proposal right now for a project that
> existed on GitHub for sometime.
> I've assumed that an SGA *on behalf* of the community (but NOT from
> somebody who is legally
> speaking a copyright holder) will be a way to go.
Speaking as a non-lawyer, "You cannot grant rights that you do not own." And the following is strictly my own opinion.
A project that is licensed under alv2.0 and has existed for so long that the contributors cannot be found can still use code with the Apache license, but not with the Apache header.
If the project is currently licensed using the alv2.0 as its license, then the project can continue to use the license with its original headers and NOTICE.
Craig
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> 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: Podling CLA/Grant advice
Posted by Craig Russell <ap...@gmail.com>.
> On Oct 2, 2017, at 5:23 PM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> On Mon, Oct 2, 2017 at 3:23 PM, Craig Russell <ap...@gmail.com> wrote:
>> Not to contradict our VP, Legal, just to clarify.
>>
>>> On Oct 2, 2017, at 1:17 PM, Chris Mattmann <ma...@apache.org> wrote:
>>>
>>> Clearly, an SGA is intended for the copyright holder. If that’s an individual who as an
>>> individual represents those copyright holders, OK, but it’s gotta be pretty clear.
>>
>> That is a pretty high bar, and I've not seen it in practice. In order for an individual to own
>> the rights and grant those rights via an SGA, there would need to be some grant document
>> from the contributor to the individual(s) signing the SGA.
>
> +1 to what Craig is saying -- I've also seen a much laxer attitude in
> the past. The very questions
> I'm asking is whether we should consider tighten our practices or
> still allow SGAs that are lax.
>
> I'm actually working on a proposal right now for a project that
> existed on GitHub for sometime.
> I've assumed that an SGA *on behalf* of the community (but NOT from
> somebody who is legally
> speaking a copyright holder) will be a way to go.
Speaking as a non-lawyer, "You cannot grant rights that you do not own." And the following is strictly my own opinion.
A project that is licensed under alv2.0 and has existed for so long that the contributors cannot be found can still use code with the Apache license, but not with the Apache header.
If the project is currently licensed using the alv2.0 as its license, then the project can continue to use the license with its original headers and NOTICE.
Craig
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> 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: Podling CLA/Grant advice
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Mon, Oct 2, 2017 at 3:23 PM, Craig Russell <ap...@gmail.com> wrote:
> Not to contradict our VP, Legal, just to clarify.
>
>> On Oct 2, 2017, at 1:17 PM, Chris Mattmann <ma...@apache.org> wrote:
>>
>> Clearly, an SGA is intended for the copyright holder. If that’s an individual who as an
>> individual represents those copyright holders, OK, but it’s gotta be pretty clear.
>
> That is a pretty high bar, and I've not seen it in practice. In order for an individual to own
> the rights and grant those rights via an SGA, there would need to be some grant document
> from the contributor to the individual(s) signing the SGA.
+1 to what Craig is saying -- I've also seen a much laxer attitude in
the past. The very questions
I'm asking is whether we should consider tighten our practices or
still allow SGAs that are lax.
I'm actually working on a proposal right now for a project that
existed on GitHub for sometime.
I've assumed that an SGA *on behalf* of the community (but NOT from
somebody who is legally
speaking a copyright holder) will be a way to go.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Podling CLA/Grant advice
Posted by Craig Russell <ap...@gmail.com>.
Not to contradict our VP, Legal, just to clarify.
> On Oct 2, 2017, at 1:17 PM, Chris Mattmann <ma...@apache.org> wrote:
>
> Clearly, an SGA is intended for the copyright holder. If that’s an individual who as an
> individual represents those copyright holders, OK, but it’s gotta be pretty clear.
That is a pretty high bar, and I've not seen it in practice. In order for an individual to own the rights and grant those rights via an SGA, there would need to be some grant document from the contributor to the individual(s) signing the SGA.
> A company
> of course has the legal setup in place to represent that IP and copyright and may have a
> clearer case.
>
> Cheers,
> Chris
>
>
>
>
> On 10/2/17, 1:05 PM, "shaposhnik@gmail.com on behalf of Roman Shaposhnik" <shaposhnik@gmail.com on behalf of roman@shaposhnik.org> wrote:
>
> On Mon, Oct 2, 2017 at 12:33 PM, Chris Mattmann <ma...@apache.org> wrote:
>> No every incoming contributor doesn’t need to sign an SGA.
>>
>> It’s great to have an SGA on file for “clean” IP. If we don’t have an SGA on
>> file for the initial code drop, we can live with that, but we could appreciate an
>> SGA for the code drop(s).
>
> Since we're on the subject: what's the guidance of an individual (not affiliated
> with any corporation) signing an SGA *on behalf* of the pre-ASF community?
> I believe that was the case with Groovy, IIRC, but I wanted to know whether
> we'd rather encourage or discourage this practice.
>
> 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
>
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: Podling CLA/Grant advice
Posted by Chris Mattmann <ma...@apache.org>.
Clearly, an SGA is intended for the copyright holder. If that’s an individual who as an
individual represents those copyright holders, OK, but it’s gotta be pretty clear. A company
of course has the legal setup in place to represent that IP and copyright and may have a
clearer case.
Cheers,
Chris
On 10/2/17, 1:05 PM, "shaposhnik@gmail.com on behalf of Roman Shaposhnik" <shaposhnik@gmail.com on behalf of roman@shaposhnik.org> wrote:
On Mon, Oct 2, 2017 at 12:33 PM, Chris Mattmann <ma...@apache.org> wrote:
> No every incoming contributor doesn’t need to sign an SGA.
>
> It’s great to have an SGA on file for “clean” IP. If we don’t have an SGA on
> file for the initial code drop, we can live with that, but we could appreciate an
> SGA for the code drop(s).
Since we're on the subject: what's the guidance of an individual (not affiliated
with any corporation) signing an SGA *on behalf* of the pre-ASF community?
I believe that was the case with Groovy, IIRC, but I wanted to know whether
we'd rather encourage or discourage this practice.
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: Podling CLA/Grant advice
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Mon, Oct 2, 2017 at 12:33 PM, Chris Mattmann <ma...@apache.org> wrote:
> No every incoming contributor doesn’t need to sign an SGA.
>
> It’s great to have an SGA on file for “clean” IP. If we don’t have an SGA on
> file for the initial code drop, we can live with that, but we could appreciate an
> SGA for the code drop(s).
Since we're on the subject: what's the guidance of an individual (not affiliated
with any corporation) signing an SGA *on behalf* of the pre-ASF community?
I believe that was the case with Groovy, IIRC, but I wanted to know whether
we'd rather encourage or discourage this practice.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Podling CLA/Grant advice
Posted by Chris Mattmann <ma...@apache.org>.
No every incoming contributor doesn’t need to sign an SGA.
It’s great to have an SGA on file for “clean” IP. If we don’t have an SGA on file
for the initial code drop, we can live with that, but we could appreciate an SGA
for the code drop(s).
ICLAs for all contributors for anything other than small stuff is required of course.
Thanks,
Chris
From: Alex Harui <ah...@adobe.com.INVALID>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Monday, October 2, 2017 at 11:32 AM
To: "legal-discuss@apache.org" <le...@apache.org>
Subject: Re: Podling CLA/Grant advice
For Flex, the SGA was signed by an Adobe VP, representing the code owner. Each Adobe employee that was going to continue contributing signed an ICLA and an Adobe VP also signed a CCLA for those employees. But lots of folks had contributed to the code donated via the SGA and did not sign an ICLA because they had no plans to contribute further, but also were not code owners.
AIUI, Individuals on GitHub who own code they contributed prior to the code moving to Apache "should", not "must", grant it to the ASF. And not by some legal requirement, but just because the ASF doesn't want to "take" code; the ASF wants willing contributions. I think I've seen the ASF allow CLAs to serve as the SGA in many cases, especially if the incoming code is already Cat-A. I think that may not be perfect, but good enough since you can judge that by continued contributions, the prior contributions are probably not going to be challenged as "not granted". But Flex has held off on accepting donations because the major contributors who wanted to donate could not track down every minor contributor who had left the Github project but couldn't be found, especially if the license is not already ALv2.
So, IMO, the doc doesn't have to say that an incoming contributor who will contribute in the future has to sign both SGA and ICLA. For small stuff, the ICLA should be good enough. IOW, it is about documenting intent to move the home of the code. Cat-A licensing already gives the legal authority to copy code into an ASF repo.
My 2 cents,
-Alex
From: <hy...@gmail.com> on behalf of Henri Yandell <he...@yandell.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Monday, October 2, 2017 at 10:22 AM
To: ASF Legal Discuss <le...@apache.org>
Subject: Re: Podling CLA/Grant advice
Yeah, I'd always viewed that as a bug in the CLA.
Chris: So every contributor to an incoming project must sign both an ICLA and an SGA? I don't think the docs say that currently.
Hen
On Mon, Oct 2, 2017 at 9:02 AM, Mattmann, Chris A (3010) <ch...@jpl.nasa.gov> wrote:
That's what the SGA gives us clean IP on a past code base and combined with ICLAs we are fine
Sent from my iPhone
> On Oct 2, 2017, at 8:56 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
>> On Sun, Oct 1, 2017 at 9:40 PM, Chris Mattmann <ma...@apache.org> wrote:
>> If the PMC and committers have ICLAs on file, then depending on the size of
>> the contribution, and
>> how it was made will determine how many of those need to have ICLAs on file.
>> The more the merrier,
>> but also within reason. If someone comes along later, and says we don’t want
>> code X, Y or Z in our
>> project b/c I contributed, and didn’t sign an ICLA then we take it out, and
>> move on.
>
> Ok, I must admit I'm confused. The text of the ICLA starts with:
>
> "You accept and agree to the following terms and conditions for Your
> present and future Contributions submitted to the Foundation."
>
> If the contribution wasn't submitted to the foundation, but rather was submitted
> to the GitHub project it seems that a signed ICLA with ASF won't be sufficient
> to cover IP that was developed on the GitHub.
>
> Am I missing something?
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
Re: Podling CLA/Grant advice
Posted by Alex Harui <ah...@adobe.com.INVALID>.
For Flex, the SGA was signed by an Adobe VP, representing the code owner. Each Adobe employee that was going to continue contributing signed an ICLA and an Adobe VP also signed a CCLA for those employees. But lots of folks had contributed to the code donated via the SGA and did not sign an ICLA because they had no plans to contribute further, but also were not code owners.
AIUI, Individuals on GitHub who own code they contributed prior to the code moving to Apache "should", not "must", grant it to the ASF. And not by some legal requirement, but just because the ASF doesn't want to "take" code; the ASF wants willing contributions. I think I've seen the ASF allow CLAs to serve as the SGA in many cases, especially if the incoming code is already Cat-A. I think that may not be perfect, but good enough since you can judge that by continued contributions, the prior contributions are probably not going to be challenged as "not granted". But Flex has held off on accepting donations because the major contributors who wanted to donate could not track down every minor contributor who had left the Github project but couldn't be found, especially if the license is not already ALv2.
So, IMO, the doc doesn't have to say that an incoming contributor who will contribute in the future has to sign both SGA and ICLA. For small stuff, the ICLA should be good enough. IOW, it is about documenting intent to move the home of the code. Cat-A licensing already gives the legal authority to copy code into an ASF repo.
My 2 cents,
-Alex
From: <hy...@gmail.com>> on behalf of Henri Yandell <he...@yandell.org>>
Reply-To: "legal-discuss@apache.org<ma...@apache.org>" <le...@apache.org>>
Date: Monday, October 2, 2017 at 10:22 AM
To: ASF Legal Discuss <le...@apache.org>>
Subject: Re: Podling CLA/Grant advice
Yeah, I'd always viewed that as a bug in the CLA.
Chris: So every contributor to an incoming project must sign both an ICLA and an SGA? I don't think the docs say that currently.
Hen
On Mon, Oct 2, 2017 at 9:02 AM, Mattmann, Chris A (3010) <ch...@jpl.nasa.gov>> wrote:
That's what the SGA gives us clean IP on a past code base and combined with ICLAs we are fine
Sent from my iPhone
> On Oct 2, 2017, at 8:56 AM, Roman Shaposhnik <ro...@shaposhnik.org>> wrote:
>
>> On Sun, Oct 1, 2017 at 9:40 PM, Chris Mattmann <ma...@apache.org>> wrote:
>> If the PMC and committers have ICLAs on file, then depending on the size of
>> the contribution, and
>> how it was made will determine how many of those need to have ICLAs on file.
>> The more the merrier,
>> but also within reason. If someone comes along later, and says we don’t want
>> code X, Y or Z in our
>> project b/c I contributed, and didn’t sign an ICLA then we take it out, and
>> move on.
>
> Ok, I must admit I'm confused. The text of the ICLA starts with:
>
> "You accept and agree to the following terms and conditions for Your
> present and future Contributions submitted to the Foundation."
>
> If the contribution wasn't submitted to the foundation, but rather was submitted
> to the GitHub project it seems that a signed ICLA with ASF won't be sufficient
> to cover IP that was developed on the GitHub.
>
> Am I missing something?
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org<ma...@apache.org>
> For additional commands, e-mail: legal-discuss-help@apache.org<ma...@apache.org>
>
Re: Podling CLA/Grant advice
Posted by Henri Yandell <he...@yandell.org>.
Yeah, I'd always viewed that as a bug in the CLA.
Chris: So every contributor to an incoming project must sign both an ICLA
and an SGA? I don't think the docs say that currently.
Hen
On Mon, Oct 2, 2017 at 9:02 AM, Mattmann, Chris A (3010) <
chris.a.mattmann@jpl.nasa.gov> wrote:
> That's what the SGA gives us clean IP on a past code base and combined
> with ICLAs we are fine
>
> Sent from my iPhone
>
> > On Oct 2, 2017, at 8:56 AM, Roman Shaposhnik <ro...@shaposhnik.org>
> wrote:
> >
> >> On Sun, Oct 1, 2017 at 9:40 PM, Chris Mattmann <ma...@apache.org>
> wrote:
> >> If the PMC and committers have ICLAs on file, then depending on the
> size of
> >> the contribution, and
> >> how it was made will determine how many of those need to have ICLAs on
> file.
> >> The more the merrier,
> >> but also within reason. If someone comes along later, and says we don’t
> want
> >> code X, Y or Z in our
> >> project b/c I contributed, and didn’t sign an ICLA then we take it out,
> and
> >> move on.
> >
> > Ok, I must admit I'm confused. The text of the ICLA starts with:
> >
> > "You accept and agree to the following terms and conditions for Your
> > present and future Contributions submitted to the Foundation."
> >
> > If the contribution wasn't submitted to the foundation, but rather was
> submitted
> > to the GitHub project it seems that a signed ICLA with ASF won't be
> sufficient
> > to cover IP that was developed on the GitHub.
> >
> > Am I missing something?
> >
> > Thanks,
> > Roman.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> > For additional commands, e-mail: legal-discuss-help@apache.org
> >
>
Re: Podling CLA/Grant advice
Posted by "Mattmann, Chris A (3010)" <ch...@jpl.nasa.gov>.
That's what the SGA gives us clean IP on a past code base and combined with ICLAs we are fine
Sent from my iPhone
> On Oct 2, 2017, at 8:56 AM, Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
>> On Sun, Oct 1, 2017 at 9:40 PM, Chris Mattmann <ma...@apache.org> wrote:
>> If the PMC and committers have ICLAs on file, then depending on the size of
>> the contribution, and
>> how it was made will determine how many of those need to have ICLAs on file.
>> The more the merrier,
>> but also within reason. If someone comes along later, and says we don’t want
>> code X, Y or Z in our
>> project b/c I contributed, and didn’t sign an ICLA then we take it out, and
>> move on.
>
> Ok, I must admit I'm confused. The text of the ICLA starts with:
>
> "You accept and agree to the following terms and conditions for Your
> present and future Contributions submitted to the Foundation."
>
> If the contribution wasn't submitted to the foundation, but rather was submitted
> to the GitHub project it seems that a signed ICLA with ASF won't be sufficient
> to cover IP that was developed on the GitHub.
>
> Am I missing something?
>
> Thanks,
> Roman.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
>
Re: Podling CLA/Grant advice
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Sun, Oct 1, 2017 at 9:40 PM, Chris Mattmann <ma...@apache.org> wrote:
> If the PMC and committers have ICLAs on file, then depending on the size of
> the contribution, and
> how it was made will determine how many of those need to have ICLAs on file.
> The more the merrier,
> but also within reason. If someone comes along later, and says we don’t want
> code X, Y or Z in our
> project b/c I contributed, and didn’t sign an ICLA then we take it out, and
> move on.
Ok, I must admit I'm confused. The text of the ICLA starts with:
"You accept and agree to the following terms and conditions for Your
present and future Contributions submitted to the Foundation."
If the contribution wasn't submitted to the foundation, but rather was submitted
to the GitHub project it seems that a signed ICLA with ASF won't be sufficient
to cover IP that was developed on the GitHub.
Am I missing something?
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org
Re: Podling CLA/Grant advice
Posted by Henri Yandell <he...@yandell.org>.
Tactical question then is:
* What flags for needing an ICLA? (I suspect the answer is a lot of "I'll
know it when I see it" situations).
And the more strategic question is:
* I suspect we would remove the code even if they had signed an ICLA; so
this is about double-knotting our laces rather than having shoes untied.
My primary intent on MXNet is to identify whether there is anyone who was
acting as a committer, but had gone inactive by the time the project
joined. They seem a valuable individual to get an ICLA from. After that
it's more of a head scratch. I wonder if git blame shows the author rather
than the committer; if that were the case then I could do a big git blame
and sift to see if there are any non-ICLAs with significantly high pieces
of code ownership.
Hen
On Sun, Oct 1, 2017 at 9:40 PM, Chris Mattmann <ma...@apache.org> wrote:
> If the PMC and committers have ICLAs on file, then depending on the size
> of the contribution, and
> how it was made will determine how many of those need to have ICLAs on
> file. The more the merrier,
> but also within reason. If someone comes along later, and says we don’t
> want code X, Y or Z in our
> project b/c I contributed, and didn’t sign an ICLA then we take it out,
> and move on.
>
>
>
> Cheers,
>
> Chris
>
>
>
>
>
>
>
>
>
> *From: *Henri Yandell <ba...@apache.org>
> *Reply-To: *"legal-discuss@apache.org" <le...@apache.org>
> *Date: *Sunday, October 1, 2017 at 9:25 PM
> *To: *ASF Legal Discuss <le...@apache.org>
> *Subject: *Podling CLA/Grant advice
>
>
>
> Hi Legal list,
>
> One of the Incubator check-list items states:
>
> "Check and make sure that the papers that transfer rights to the ASF been
> received. It is only necessary to transfer rights for the package, the core
> code, and any new code produced by the project. "
>
> When a project is coming from a single contributor (such as a company),
> this is handled by a software grant.
>
> When a project already exists and is relicensing, this is 'fun' and
> involves a lot of CLA signing (in essence to get permission to relicense to
> the Apache 2.0 licence).
>
>
>
> When a project is an already existing project _AND_ is already/has always
> been under the Apache 2.0 license, how should this be handled?
>
> Specifically I am looking at Apache MXNet. There are 400+ contributors.
> The existing and new committers have all signed ICLAs. Who else among the
> ~380 remaining contributors need to sign ICLA/grants? And what reason do we
> give to them when asking them to sign the ICLA/grant given that the code
> isn't being relicensed?
>
> Thanks,
>
> Hen
>
Re: Podling CLA/Grant advice
Posted by Chris Mattmann <ma...@apache.org>.
If the PMC and committers have ICLAs on file, then depending on the size of the contribution, and
how it was made will determine how many of those need to have ICLAs on file. The more the merrier,
but also within reason. If someone comes along later, and says we don’t want code X, Y or Z in our
project b/c I contributed, and didn’t sign an ICLA then we take it out, and move on.
Cheers,
Chris
From: Henri Yandell <ba...@apache.org>
Reply-To: "legal-discuss@apache.org" <le...@apache.org>
Date: Sunday, October 1, 2017 at 9:25 PM
To: ASF Legal Discuss <le...@apache.org>
Subject: Podling CLA/Grant advice
Hi Legal list,
One of the Incubator check-list items states:
"Check and make sure that the papers that transfer rights to the ASF been received. It is only necessary to transfer rights for the package, the core code, and any new code produced by the project. "
When a project is coming from a single contributor (such as a company), this is handled by a software grant.
When a project already exists and is relicensing, this is 'fun' and involves a lot of CLA signing (in essence to get permission to relicense to the Apache 2.0 licence).
When a project is an already existing project _AND_ is already/has always been under the Apache 2.0 license, how should this be handled?
Specifically I am looking at Apache MXNet. There are 400+ contributors. The existing and new committers have all signed ICLAs. Who else among the ~380 remaining contributors need to sign ICLA/grants? And what reason do we give to them when asking them to sign the ICLA/grant given that the code isn't being relicensed?
Thanks,
Hen