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
Ate
[1] - http://www.bouncycastle.org/fr/licence.html
[2] - http://yfilter.cs.umass.edu/code_release.htm
[3] - 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<[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>
--
Regards,
Heshan Suriyaarachchi
http://heshans.blogspot.com/
