Mailing-List: contact user-help@struts.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Struts Users Mailing List" <user@struts.apache.org>
Received-SPF: neutral (nike.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <22323404.post@talk.nabble.com>
References: <fadcf8240903030632w6437cc25w1168dfb188f8a534@mail.gmail.com>
	 <d8bdeb6f0903031054v64ea35b6qb94e8ebb49fa3c3a@mail.gmail.com>
	 <22316588.post@talk.nabble.com>
	 <d8bdeb6f0903031201h6e09da87i7516270da56e3c2e@mail.gmail.com>
	 <22317341.post@talk.nabble.com> <200903031859.09498.wesw@wantii.com>
	 <22323404.post@talk.nabble.com>
Date: Wed, 4 Mar 2009 09:37:45 -0500
Message-ID: <e34c19110903040637y1d292fc1k7875d3e16b2f7747@mail.gmail.com>
Subject: Re: [OT] POM, licenses and dependency trees
From: Wes Wannemacher <wesw@wantii.com>
To: Struts Users Mailing List <user@struts.apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 3, 2009 at 11:20 PM, stanlick <stanlick@gmail.com> wrote:
>
> Java !=3D C?
>
> I realize the strength and duration of dependencies varies, and I underst=
and
> the issues concerning use vs. redistribution. =A0This 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 c=
an
> be adopted into the corporation. =A0Some people explain away dependencies=
 as
> being only necessary for testing or compiling, thereby resulting in only =
a
> small list of "real" dependencies. =A0The 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. =A0The procedure today is tedious and ma=
nual
> and I am looking for a mechanical solution. =A0FOSSology 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 dependencie=
s
>>> than what show up running
>>> dependency:resolve. =A0I verifies the default for scope because several=
 of
>>> the dependencies are "test." =A0 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. I=
f
>> 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 i=
s
>> 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 uni=
t-
>> 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 writi=
ng
>> 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. Mos=
t
>> 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 th=
e
>> 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-unsubscribe@struts.apache.org
>> For additional commands, e-mail: user-help@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-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>


--=20
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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org