IANAL, but this is what I learned when prepping code donations: 1) Every line of code is owned by some entity (a person or other legal entity) 2) The person who owned it (may be different from the person who wrote it) and added it to the collection of code did so under some terms. 3) If those terms do not explicitly allow for perpetual licensing under AL, then permission must be given by the code owner for perpetual licensing under AL. The SGA is the official form to document that permission. If it were me, I’d accept emails and JIRAs from individual owners as well.
So, if you start up something on GH, I’d make sure each contribution comes with documented permission in a similar way to how the ASF does it now: ICLAs and assumed permission from patch authors in the bug tracker. In an “open-source" code base I prepped for donation, external contributors had to sign a very different ICLA giving up their rights to the $Corp that controlled the code. Then $Corp could donate it via SGA (the code was under MPL). For Groovy, I agree with those that say the SGA doesn’t really add much, although I suppose you could fret about whether everyone who had contributed code by the time of the switch from BSD to AL authorized it via their contributor agreement or some other way. I’d go with whatever is easier: allowing an exception to having an SGA at all, or picking some person or set of people to sign one. -Alex On 3/26/15, 9:42 AM, "P. Taylor Goetz" <ptgo...@gmail.com> wrote: >This seems like an appropriate thread to raise a question that’s been in >the back of my head for a while… > >If a new project is created on github (or elsewhere — i.e. outside of the >ASF), but with the intention that it would be contributed to an existing >ASF project (ALv2 license from day 1), would a Software Grant and/or IP >clearance be required? > >Put another way, what are the best practices to follow when creating a >new project, outside the ASF, with the goal of eventually contributing >that work to an existing ASF project? > >The documentation for the IP clearance template [1] states: > >"Any code that was developed outside of the ASF SVN repository must be >processed like this, even if the external developer is an ASF committer.” > >To me that sounds like any new module, or even a sufficiently large pull >request, requires IP clearance. If that’s the case, I would expect the >clearance document list [2] to be much longer than it is, and have more >ASF projects represented there, especially some of the faster growing >ones. > >-Taylor > >[1] http://incubator.apache.org/ip-clearance/ip-clearance-template.html >[2] http://incubator.apache.org/ip-clearance/index.html > >On Mar 26, 2015, at 11:17 AM, James Carman <ja...@carmanconsulting.com> >wrote: > >> On Thu, Mar 26, 2015 at 10:51 AM, Marvin Humphrey >> <mar...@rectangular.com> wrote: >>> >>> If you have a codebase which was not previously under the ALv2 -- say >>>it was >>> either proprietary or available under a different open source license >>>-- then >>> the Software Grant is hugely important from a legal standpoint. You >>>have to >>> get every last copyright owner to sign it, and if you can't get them >>>all on >>> board you have a mess on your hands that will have to be dealt with. >>> >>> In contrast, from a legal standpoint, a signed Software Grant doesn't >>>change >>> much when the codebase is already under the ALv2. (Quite possibly it >>>has zero >>> effect but I'd need to ask a lawyer about the text of the Software >>>Grant >>> form to confirm that.) >>> >>> Separate from the legal aspect, we have a social tradition at Apache >>>of only >>> accepting "voluntary contributions". This prevents social disharmony >>>if >>> somebody doesn't want their contribution to go to a project hosted at >>>the ASF. >>> >>> For Groovy, I agree with Benson. We already have sufficient informal >>>evidence >>> that the Groovy community at large has granted social approval for the >>>move to >>> Apache. The software grant does not change much about the legal >>>status of the >>> codebase. Let's not get hung up on who has to sign it. >>> >> >> Right, but this thread (renamed) isn't about Groovy. What I was >> trying to do is tease out more information about these sorts of >> situations, so that we can maybe put together some clear >> documentation. If that documentation says "when this situation comes >> up, please ask for help as they need to be evaluated on a case-by-case >> basis", then that's fine. If this were cut and dry, we probably >> wouldn't be 18 messages deep into this thread. >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> >
