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 <johndam...@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 < > bdelacre...@apache.org> > wrote: > > > Hi, > > > > On Thu, Mar 31, 2016 at 2:29 AM, Alexander Bezzubov <b...@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-disc...@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-unsubscr...@incubator.apache.org > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > >
