On Sun, May 16, 2010 at 11:25 PM, Jacob Beard <jbea...@cs.mcgill.ca> 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: > http://github.com/einars/js-beautify/blob/master/license.txt > json2 - Public Domain > <snip/>
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): http://www.apache.org/legal/3party.html#category-a http://www.apache.org/legal/3party.html#category-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): http://svn.apache.org/repos/asf/httpd/httpd/trunk/LICENSE > 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. > <snap/> 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: http://svn.apache.org/repos/asf/struts/struts2/trunk/plugins/dojo/src/main/resources/org/apache/struts2/static/dojo/ Tapestry 5 includes scriptaculous sources (as another JavaScript example): http://svn.apache.org/repos/asf/tapestry/tapestry5/trunk/tapestry-core/src/main/resources/org/apache/tapestry5/scriptaculous_1_8_2/ Here is an example of using Rhino with modifications (Batik 1.7): http://svn.apache.org/repos/asf/xmlgraphics/batik/tags/batik-1_7/lib/ (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. -Rahul > Please let me know what you think. Thanks, > > Jake > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
