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<
[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
--
Regards,
Heshan Suriyaarachchi
http://heshans.blogspot.com/
