On Fri, Feb 3, 2012 at 4:17 PM, Ate Douma <[email protected]> wrote: > On 02/03/2012 10:01 PM, Heshan Suriyaarachchi wrote: > >> Hi Ate, >> >> Thanks for the clarification. >> >> I included the licenses for following jars. >> >> Bounty castle license is similar to MIT license according to [1]. >> Therefore, according to [3], including it's license to the license file. >> >> YFilter is release under the BSD [2] license. Therefore, according to [3], >> including it's license to the license file. >> >> Please correct me if I am wrong. >> > You've got it right :) > > Just make sure to not just include the standard (new) BSD license, but > actually best simply copy the exact text from each of the license pages for > [1] and [2] which ensures their copyright header (which is specific) also > is included. > > Note: [1] points to the overall page, the license (and copyright) to copy > of course is here: > http://yfilter.cs.umass.edu/**COPYRIGHT.htm<http://yfilter.cs.umass.edu/COPYRIGHT.htm> > > Yes. I included the license in http://yfilter.cs.umass.edu/COPYRIGHT.htm.
Thanks, Heshan. > Ate > > >> [1] - >> http://www.bouncycastle.org/**fr/licence.html<http://www.bouncycastle.org/fr/licence.html> >> [2] - >> http://yfilter.cs.umass.edu/**code_release.htm<http://yfilter.cs.umass.edu/code_release.htm> >> [3] - >> http://www.apache.org/legal/**resolved.html#category-a<http://www.apache.org/legal/resolved.html#category-a> >> >> On Fri, Feb 3, 2012 at 11:16 AM, Ate Douma<[email protected]> wrote: >> >> On 02/03/2012 04:52 PM, Heshan Suriyaarachchi wrote: >>> >>> Airavata registry-api jar is having a dependency to jackrabbit-core jar >>>> 2.2.7. In this jar they have shipped a file called DEPENDENCY.txt and it >>>> contains the transitive dependencies of jackrabbit. So, information >>>> contained in this file should go to NOTICE file of the Airavata >>>> registry-api jar, right? Please correct me if I am wrong. >>>> >>>> >>> No, not in this case. >>> >>> A LICENSE and NOTICE file of a module (registry-api in this case) *only* >>> need (and should) cover what's actually released as artifact. >>> As I presume the registry-api doesn't 'embed' the jackrabbit-core but >>> only >>> depends on it, you don't need to cover jackrabbit-core or any other >>> dependency. >>> Typically, a normal jar (not a uber jar though) only needs to cover the >>> license and copyright notices of the sources building up the jar. >>> >>> So, usually you actually don't need to do anything at all for those type >>> of modules, presuming you're using maven-remote-resources plugin which >>> will >>> add the required Apache LICENSE and base NOTICE automatically. >>> >>> For aggregating modules though, like wars, or uber jars, as well as >>> assembly based archives, you'll need to add/merge the copyright notices >>> and >>> licenses for all bundled 'artifacts' within. So if you bundle >>> jackrabbit-core somewhere, *there* you'll need to append the notices and >>> licenses applicable for using jackrabbit-core. Which isn't the same as >>> copying the contents from some DEPENDENCY.txt: you need only cover the >>> requirements for jackrabbit-core itself. Of course, if *all* its >>> dependencies end up in your aggregate module, those probably then >>> overlap, >>> but even then beware that maven might bundle other (newer) versions of >>> some >>> of those dependencies, either directly (as defined in your pom) or >>> transitively. You really need to review the *effective* bundled >>> dependencies of your build, and cover (only) those. >>> >>> The easiest way to technically do this is by providing appendable NOTICE >>> and LICENSE file *fragments* under src/main/appended-resources/**** >>> META-INF >>> >>> in your module source. The maven-remote-resources plugin will then use >>> those to append to the default NOTICE and LICENSE files. >>> Benefit of that is: >>> a) No need to copy the full AL License 2.0 everywhere >>> b) The default NOTICE file will automatically have the correct header, >>> derived from your module name and (important) the correct Copyright >>> period. >>> Otherwise you'll have to update that one manually after each year >>> turnover. >>> >>> Beware: for assembly build modules you'll probably need separate and full >>> NOTICE and LICENSE files and AFAIK the maven-remote-resources plugin >>> won't >>> execute during assembly builds. >>> >>> Ate >>> >>> >>> >>> On Fri, Feb 3, 2012 at 10:24 AM, Heshan Suriyaarachchi< >>>> heshan.suriyaarachchi@gmail.****com<heshan.suriyaarachchi@**gmail.com<[email protected]> >>>> >> >>>> wrote: >>>> >>>> Hi Devs, >>>> >>>>> >>>>> I am in the process of going through the dependency tree of airavata >>>>> and >>>>> adding missing licenses to the LICENSE file. I am opening up this >>>>> thread >>>>> to >>>>> discuss any concerns that I come across while doing $subject. >>>>> >>>>> Airavata is having a dependency to javax.jcr jar. It's licensed >>>>> under[1]. >>>>> Is it Apache compatible? >>>>> >>>>> >>>>> [1] - >>>>> http://www.day.com/specs/jcr/****2.0/license.html<http://www.day.com/specs/jcr/**2.0/license.html> >>>>> <http://www.**day.com/specs/jcr/2.0/license.**html<http://www.day.com/specs/jcr/2.0/license.html> >>>>> > >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> Heshan Suriyaarachchi >>>>> >>>>> http://heshans.blogspot.com/ >>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >> >> > -- Regards, Heshan Suriyaarachchi http://heshans.blogspot.com/
