Java != C? I realize the strength and duration of dependencies varies, and I understand the issues concerning use vs. redistribution. This notwithstanding, I am looking to satisfy the legal team and this requires collecting the sum of licenses from all the dependent archives before anything large or small can be adopted into the corporation. Some people explain away dependencies as being only necessary for testing or compiling, thereby resulting in only a small list of "real" dependencies. The legal folks are saying if a dependency is necessary for any phase in the life cycle, they need to inspect the respective licenses. The procedure today is tedious and manual and I am looking for a mechanical solution. FOSSology appears to do a nice job of scraping anything that resembles a license; I am trying to build a dependency tree of jars to feed the FOSSology sniffer.
Ideally, I will give the script the three key Maven elements and it will cache out a tree. Peace, Scott Wes Wannemacher wrote: > > On Tuesday 03 March 2009 15:40:43 stanlick wrote: >> If you look at the POM for Struts 2.1.6 there are many more dependencies >> than what show up running >> dependency:resolve. I verifies the default for scope because several of >> the dependencies are "test." It appears the default is all scopes, so I >> am wondering why I don't see them all when I run dependency:resolve. >> > > There are a few things to keep in mind here Scott, Java is not like C. If > you > have a compiled binary, the executable is linked to it's required > libraries, > whether you use them or not. Then, if you try to run the executable and > one of > the libraries is not available, the program will crash. In Java, there is > a > difference between compile-time and run-time dependencies. Java programs > will > only seek out it's required classes when they are used. Because of this > behavior, libraries like Struts typically have many compile-time and unit- > test-time dependencies that do not need to be satisfied at run-time. If > you > are using struts2-core w/o any plugins, the list of dependencies is > (purposely) small. Add the spring plugin and the dependencies grow, add > hibernate, etc. etc. > > On licensing, it is messy, but here are a few thoughts - > > 1. Nearly all of the (F)(L)OSS licenses are more concerned with > distribution > than usage. I've used GPL licensed software in many commercial projects, > but > the software was used, rather than distributed. This is perfectly > acceptable, > you only have to become concerned when you want to distribute (i.e. sell) > the > software. Since we are mostly web-app developers, we are generally writing > software that our customers use, but we are rarely concerned about the > distribution of the software. > > 2. To keep things straight, there are different families of license. Most > OSS > licenses fall into one of only a few categories. There is the GPL which > basically states that if you plan to use it in a distributable project, > you > need to plan on making your source GPL licensed as well. The ASF style > license > is much less restrictive, IMO, this is why you often see things like > Apache > HTTPD distributed with commercially licensed software like Solaris. The > Apache > license really only has a few requirements... You have to include a copy > of > the Apache license if you distribute Apache licensed software, you can't > use > the Apache trademarks, you have to attribute apache - > > http://www.apache.org/foundation/licence-FAQ.html#WhatDoesItMEAN > > There is also the BSD family of licenses which basically allow you to do > as > you please. You can sell it if you'd like, but you have to retain > copyright > notices and the warranty clause. > > There are a few other popular licenses, the Mozilla license and Eclipse > license come to mind. > > The big thing is to consider what you plan to do. If you want to sell the > software you are creating, you want to make sure that your dependencies' > licenses allow it. > > If you don't plan to distribute your source, then you are usually safe. > > -Wes > -- > > Wes Wannemacher > Author - Struts 2 In Practice > Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more > http://www.manning.com/wannemacher > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscr...@struts.apache.org > For additional commands, e-mail: user-h...@struts.apache.org > > > -- View this message in context: http://www.nabble.com/-OT--POM%2C-licenses-and-dependency-trees-tp22309719p22323404.html Sent from the Struts - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscr...@struts.apache.org For additional commands, e-mail: user-h...@struts.apache.org
