Re: Advice on a legal aspect of code contribution

[Alexander Bezzubov <bz...@apache.org>]

Thank you very much for the kind guidance and the detailed explanation.

It helps and makes perfect sense for me.

One thing though, on 1 - it looks like I have unintentionally confuse
people with the word "complex code contribution", which I referred to the
structure of the patch received, rather than the code.

It was created and sent as a patch by an individual contributor who owns
the IP on 1 (not a committer) and I was under impression that it should be
treated as a regular patch (includes few new files) as we did with similar
contributions before, rather than a full code donation (as it's not really
an external or substantial code base) which should require an IP
clearance/SGA.

Does this make sense?


Thank you again.

--
Alex



On Thu, Mar 31, 2016 at 8:20 PM, John D. Ament <jo...@apache.org>
wrote:

> Ideally, you would also seek out an SGA from all companies involved in the
> contribution.  If its all Lightbend, they should be able to provide an SGA
> to move the code into an Apache donation, including the license.
>
> John
>
> On Thu, Mar 31, 2016 at 4:09 AM Bertrand Delacretaz <
> bdelacretaz@apache.org>
> wrote:
>
> > Hi,
> >
> > On Thu, Mar 31, 2016 at 2:29 AM, Alexander Bezzubov <bz...@apache.org>
> > wrote:
> > > ...The contribution consists of many files that are going to be part of
> > the
> > > release:...
> >
> > As you have 3 categories of source code files in this contribution I
> > suggest handling all 3 separately, creating a ticket in your issue
> > tracker for each of them so you keep a trace of how they were handled.
> >
> > >  1. some are original author's code under Apach2.0...
> >
> > Unless that author is a committer to your project you'll need an IP
> > clearance for those as per
> > http://incubator.apache.org/ip-clearance/index.html
> >
> > >  2. some are files copied from one third-party project - Scala [1],
> > > distributed under BSD...
> >
> > For those the recommendations at [5] apply.
> >
> > Do not change the copyright headers in those files, and ideally put
> > them all under a common source code folder or module so that LICENSE
> > can clearly point to them.
> >
> > (that's assuming it makes sense to copy that source code in your
> > project as opposed to using it as an external library)
> >
> > >  3. some are files copied from another third-party project, rscala [2],
> > > distributed under License: GPL-2 | GPL-3 | BSD_3_clause + file
> LICENSE...
> >
> > I have no idea what that license notation means, for those you might
> > need to ask on legal-discuss@apache.org specifically, and maybe create
> > a http://issues.apache.org/jira/browse/LEGAL to keep track of the
> > clarification of the above notation.
> >
> > > ... - What is the best practise for Java RAT checks in case of such
> > > contributions under ASF? Should such files be just added to RAT
> > <ignore>?...
> >
> > Yes, with comments around that rat config to explain what's going on.
> >
> > Hope this helps,
> > -Bertrand
> >
> > [5]
> >
> http://incubator.apache.org/guides/releasemanagement.html#best-practice-license
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > For additional commands, e-mail: general-help@incubator.apache.org
> >
> >
>

Re: Advice on a legal aspect of code contribution

[Bertrand Delacretaz <bd...@apache.org>]

Hi,

On Fri, Apr 1, 2016 at 4:02 AM, Alexander Bezzubov <bz...@apache.org> wrote:
> ...It was created and sent as a patch by an individual contributor who owns
> the IP on 1 (not a committer) and I was under impression that it should be
> treated as a regular patch (includes few new files) as we did with similar
> contributions before, rather than a full code donation...

Yes that makes sense if it's "just" a patch.

I think the best is to create tickets for the others parts that enable
this patch, and have those tickets managed by the PMC as things on
which the incoming patch depends.

-Bertrand

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org