On Tue, Mar 3, 2009 at 11:20 PM, stanlick <stanl...@gmail.com> wrote: > > 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,
Who's lifecycle? What if I told you that during compile-time, I would like to use Rational Rose? Will your legal team think that you need to purchase a license for it? Or, the fact that we use Bamboo and JIRA during the dev lifecycle. They are proprietary licenses from Atlassian. You don't need to be licensed on them to use struts. I hate to use the old car analogy, but you don't indemnify yourself against any of Ford's patents just because you drive a car. You really can go too far digging into it. The pom.xml includes things _we_ use to _write_ the software, you as a user should only be concerned with _your_ application's lifecycle. If their concern for dependencies is recursive, how far down the rabbit hole will you go? Struts depends on Java, which depends on OS, which depends on binary blobs to control hardware which was designed most likely using CAD software which runs on an OS which depends (ad nauseum)... I do understand though that they want to review licenses, but I think we'll have to agree to disagree as to the level of review required. Anyhow, I would also suggest pointing them to the OSI website (http://www.opensource.org/licenses/category). They are about as much of a governing body as you can get. Licenses are not considered "Open Source" unless they are approved by the OSI. > 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 > > -- 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
