You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@incubator.apache.org by "John D. Ament" <jo...@apache.org> on 2015/02/09 03:04:44 UTC
CCLA's and SGA's
All,
Just wanted to confirm with others. If a company is donating a new project
to the ASF, a CCLA (or multiple ICLAs) are required to allow contributors
from that project to continue on in Apache, as well as an SGA to allow the
company to transfer the existing software to the ASF.
Basically, the CLA is for future work, SGA is for existing work.
Let me know if this is a better question for legal.
John
Re: CCLA's and SGA's
Posted by Rob Vesse <rv...@dotnetrdf.org>.
There is a case where an CCLA can cover for an SGA
If a company donates code to an existing project where the developers of
the incoming contributions already have ICLAs and the company has signed
CCLA for those contributors that were already in effect at the time the
contributions were originally developed then in one previous case I've
seen it be agreed that an SGA was unnecessary. For example see this
legal-discuss thread:
http://s.apache.org/YPe
Rob
On 08/02/2015 18:10, "Roman Shaposhnik" <ro...@shaposhnik.org> wrote:
>On Sun, Feb 8, 2015 at 6:09 PM, John D. Ament <jo...@apache.org>
>wrote:
>> And specifically, is there ever a case where a CCLA can cover for a SGA?
>
>I would seriously doubt it.
>
>Thanks,
>Roman.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: CCLA's and SGA's
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Sun, Feb 8, 2015 at 6:09 PM, John D. Ament <jo...@apache.org> wrote:
> And specifically, is there ever a case where a CCLA can cover for a SGA?
I would seriously doubt it.
Thanks,
Roman.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: CCLA's and SGA's
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> On 09 Feb 2015, at 15:08, Jim Jagielski <ji...@jaguNET.com> wrote:
>
> These are all different vehicles for different things.
>
> The SGA is basically a formal code-donation to the ASF. It
> provides deep IP provenance.
>
> A CCLA is a document that sez that a company is aware that its
> employee(s) is/are working on Apache projects and that they
> (the company) is OK with that. Usually this is in direct response
> to those employee agreements that claim that any IP created
> by an employee (at any time) is the property of the employer.
> A CCLA is not usually required, but if it is, it's up to the
> employer to determine when/if it is.
>
> An iCLA is required once someone gets commit privs and provides
> a belts-and-braces provenance history, ensuring that all code
> that comes into Apache has history and can be included.
I would refine this into
A CCLA is not required unless either 1) the company prefers to have such in place on its own accord or 2) an individual with an iCLA has determined (e.g. in consultation with his employer or customers) that in his or her specific situation a CCLA is needed in addition to his own iCLA.
So start with gating the code we (ultimately) distribute and have to have good governance over to have the release ‘stick’ to the license by gating what goes into SVN.
- That we do with the Software Grant
- Or with the iCLA of the individual committing.
and provide companies and individuals the ability to clarify their (relative or absolute) position with a CCLA if they feel so inclined.
Dw
>
> NOTE: Apache only accepts voluntary code donations; no matter
> what the license, if the copyright holder does not want the
> code to be included in Apache projects, Apache will honor that
> request. So the above agreements also align with that policy.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: CCLA's and SGA's
Posted by Jim Jagielski <ji...@jaguNET.com>.
These are all different vehicles for different things.
The SGA is basically a formal code-donation to the ASF. It
provides deep IP provenance.
A CCLA is a document that sez that a company is aware that its
employee(s) is/are working on Apache projects and that they
(the company) is OK with that. Usually this is in direct response
to those employee agreements that claim that any IP created
by an employee (at any time) is the property of the employer.
A CCLA is not usually required, but if it is, it's up to the
employer to determine when/if it is.
An iCLA is required once someone gets commit privs and provides
a belts-and-braces provenance history, ensuring that all code
that comes into Apache has history and can be included.
NOTE: Apache only accepts voluntary code donations; no matter
what the license, if the copyright holder does not want the
code to be included in Apache projects, Apache will honor that
request. So the above agreements also align with that policy.
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org
Re: CCLA's and SGA's
Posted by "John D. Ament" <jo...@apache.org>.
On Sun Feb 08 2015 at 9:04:43 PM John D. Ament <jo...@apache.org>
wrote:
> All,
>
> Just wanted to confirm with others. If a company is donating a new
> project to the ASF, a CCLA (or multiple ICLAs) are required to allow
> contributors from that project to continue on in Apache, as well as an SGA
> to allow the company to transfer the existing software to the ASF.
>
> Basically, the CLA is for future work, SGA is for existing work.
>
And specifically, is there ever a case where a CCLA can cover for a SGA?
>
> Let me know if this is a better question for legal.
>
> John
>
Re: CCLA's and SGA's
Posted by James Carman <ja...@carmanconsulting.com>.
The foundation doesn't require CCLAs (they're a good CYA for the employees
though) but we do require ICLAs.
On Sunday, February 8, 2015, John D. Ament <jo...@apache.org> wrote:
> All,
>
> Just wanted to confirm with others. If a company is donating a new project
> to the ASF, a CCLA (or multiple ICLAs) are required to allow contributors
> from that project to continue on in Apache, as well as an SGA to allow the
> company to transfer the existing software to the ASF.
>
> Basically, the CLA is for future work, SGA is for existing work.
>
> Let me know if this is a better question for legal.
>
> John
>
Re: CCLA's and SGA's
Posted by David Nalley <da...@gnsa.us>.
On Sun, Feb 8, 2015 at 9:04 PM, John D. Ament <jo...@apache.org> wrote:
> All,
>
> Just wanted to confirm with others. If a company is donating a new project
> to the ASF, a CCLA (or multiple ICLAs) are required to allow contributors
> from that project to continue on in Apache, as well as an SGA to allow the
> company to transfer the existing software to the ASF.
>
> Basically, the CLA is for future work, SGA is for existing work.
>
> Let me know if this is a better question for legal.
>
> John
So a CCLA in itself to permit a new contributor to be a committer.
An ICLA is required of all committers.
Strictly speaking a non-committer contributor ICLA isn't required in
most cases.
A CCLA with a Schedule B identifying software to be granted can be
used in lieu of a SGA.
--David
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org