commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rahul Akolkar <>
Subject Re: [all] preparing initial commit
Date Mon, 17 May 2010 18:21:29 GMT
On Sun, May 16, 2010 at 11:25 PM, Jacob Beard <> wrote:
> Hi,
> I'm currently working to prepare the initial commit for my Google
> Summer of Code project. I have a quick question regarding external
> libraries. My project currently uses a few libraries which are
> licensed under liberal, non-copyleft licenses. A list of these
> libraries and their associated licenses is as follows:
> Mozilla Rhino - MPL
> Dojo JavaScript toolkit - BSD/AFL dual license
> Selenium - Apache 2.0 License
> js-beautify - something a bit non-standard:
> json2 - Public Domain

I'll first address the licenses and then get to the how to include the
libraries bit.

You may have seen the following categorization of licenses we use
(Category A is generally easier to incorporate than B):

Given that, the above list you have looks OK:
 * Assuming we'll only depend on Rhino binaries
 * The js-beautify license seems reasonable, we may have to ping the
ASF Legal Affairs committee for a definite answer

Based on what actually gets included, the LICENSE (and perhaps the
NOTICE) in your project trunk will need to be updated. For an example
of how this is done, see the part of the httpd LICENSE (scroll down
below the AL 2.0 text):

> Is it possible to include these libraries in the source tree of my project?
> Also, for a library like dojo, which is large (about 100MB,
> uncompressed), and composed of many small files, would it be better to
> include a compressed zip file in the library directory, with
> instructions in the README for the user to unzip it, or would it be
> better to use an svn:externals svn property to point to the dojo
> source tree, so that it is automatically checked out (probably from a
> specific tag), when the source tree is checked out.

To recap what others have said, the guiding principles we use are
along these lines:

 * Do not add dependencies to SVN, have the build retrieve a fixed version
   - The version may be binaries from a Maven repo or source from
svn:externals via a tag (a SVN location that is immutable in practice)
 * Use the standard Maven layout and build as far as possible
   - Obviously, what this means for a JavaScript project remains to be
seen, maybe you can say whether or not you think Maven adds value for
your project and what build system you intend to use

Obviously, if there is a need to make modifications to any of the
dependencies, the above is not sufficient. In those cases where there
is merit in having a source copy in SVN, dependency code can be
checked in if its an amicable license. Indeed, we already include some
of the above dependency sources elsewhere at the ASF.

Struts 2 includes Dojo sources:

Tapestry 5 includes scriptaculous sources (as another JavaScript example):

Here is an example of using Rhino with modifications (Batik 1.7):
  (in particular, see LICENSE.js.txt and README.js.txt)

To summarize, if you can make a strong case to including sources in
SVN, it may be possible. If you are simply intending to use these as
runtime dependencies, its best to pull them down with the build rather
than check anything into SVN.


> Please let me know what you think. Thanks,
> Jake

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message