Thanks Wes -- First off, you are preaching to the choir bro. My question stems from the fact we have a small army of lawyers who stake their careers on looking in these rabbit holes and they are now asking me to help them dig! Telling them not to concern themselves with this and that archive for whatever reason, only makes them want to dig deeper. Again, lawyers! Funny thing is when you are at the top of the mountain with piles of assets, you become a target. Do you think if the woman had spilled her hot coffee at Joe's Java Drive-thru that she would have been awarded $1,000,000?
I'm not interested in what version of Rose you used unless you include Rose in the distribution. If you dump the struts-2.1.6 archive out on the table, you will find it contains fifty-seven archives of its own. You and I realize why testng-5.1.jar is there and that it might not even be touched in-house -- but that does not mean that it will not once struts-2.1.6 is accepted. So here is what I would like to do. 1) Build a comprehensive list of the jars included in say, struts-2.1.6 and those dependent downstream jars 2) Feed this list of archives to FOSSology where it is prepared to sniff out the stack of respective licenses 3) Hand the comprehensive stack of licenses to the legal team 4) Repeat for next requested FOSS offering Is Maven a candidate for this task? We have our own build system and do not use Maven, however, I think we could use it for this legal request. I have experimented with its dependency:tree, but it seems to build only a partial tree. Suppose *I did* want to do a maven build that touched all fifty-seven files for the express purpose of building this comprehensive dependency tree. Is there such a POM? Would creating such a POM produce the comprehensive tree? Peace, Scott Wes Wannemacher wrote: > > 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 > > > -- View this message in context: http://www.nabble.com/-OT--POM%2C-licenses-and-dependency-trees-tp22309719p22353822.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
