You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by st...@gmail.com on 2009/03/03 15:32:52 UTC
[OT] POM, licenses and dependency trees
How does a company go about fleshing out the aspects of FOSS without wasting
so many people's time? As FOSS gains in popularity, we are sinking in a
quagmire of manual research, analysis and legal license inspections. It
seems the FOSSology product will unpack compressed files and sniff around
for licenses while on the other side of the planet we have Maven
repositories that understand version dependencies -- but there is a void in
bring them together!
In an attempt to follow a concrete day-in-the-job, let us consider
struts2.1.6 and let's further suppose that we plan to take advantage of all
the downstream dependencies it offers (i.e. optionals).
1. Is there a version specific dependency tree mechanically available?
- Will subsequent versions eventually appear in the same
location.format?
2. What technique to use in determining the stack of licenses gleaned
from this tree?
I see developers struggling to bring together the jars necessary to do a
build, which is time consuming and expensive. I see a legal team in the
other building struggling to ascertain our risk, should this "stack" be
implemented.
P.S. Does anyone here have first hand experience with FOSSology?
Peace,
Scott
Re: [OT] POM, licenses and dependency trees
Posted by Antonio Petrelli <an...@gmail.com>.
FYI here are the Apache guidelines about licensing of Apache projects:
http://www.apache.org/legal/3party.html
Ciao
Antonio
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] POM, licenses and dependency trees
Posted by Wes Wannemacher <we...@wantii.com>.
On Thu, Mar 5, 2009 at 10:26 AM, stanlick <st...@gmail.com> wrote:
>
> 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.
I guess I wasn't considering how you retrieve Struts. If you are
pulling down struts2-all-blahblah.zip, then you will get everything. I
was assuming a build starting from a maven archetype and working up
from there. This might be one way to compromise. Instead of grabbing
struts-all, just learn to start from an archetype and add individual
dependencies as they are needed. Maven will only retrieve what you
tell it to.
As a side note, I too worked at a top-of-the-heap company for a long
while, but our legal team was very well educated about licensing
issues. I think the difference was that we were a *nix shop from the
get-go, so most of us were familiar with the technology and culture.
In fact, one of the projects I worked on
(http://www.atomicmpc.com.au/News/13219,aol-moves-to-linux-and-mozilla.aspx),
I worked close with legal to make sure that we were in license
compliance and it went pretty smooth. Had we been sued, I felt
confident that our attorneys understood FOSS to the extent that they
could rigorously defend it.
>
> 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?
>
I think Maven might be a candidate for your task, but maven is a hard
thing to adopt for just one task... Maven is sort of an all-or-nothing
kind of deal. In your custom build environment, have you considered
trying to jimmy Maven into the mix? I had to do force apache ant into
a custom CI farm (created to automate unix builds with make, make +
java = not fun), it's not fun, but it has benefits.
As far as an all-inclusive pom, there are a few considerations. There
is not likely to be a project that includes *everything* that can be
used with struts2. For instance, I don't think you can have both the
Guice plugin and the Spring plugin in a single project... We only run
a single objectfactory, so plugins like this would clash. (There are
others like plexus that fall under this category).
If you can, I would suggest trying to get maven into the mix as much
as possible. To me, it seems the easiest method would be to create a
maven plugin that tracks which packages have been used within your
company. If the license is not known for a package, then you can
specify the license, then whenever another project uses that package
(directly or as a transitive dependency), it can be considered
blessed. Many poms include their license information (check the
license section here-
http://www.jarvana.com/jarvana/search?search_type=inspect_pom&path_to_pom=/com/opensymphony/xwork/2.1.2/xwork-2.1.2.pom),
which would make it that much easier for you to build a tool around.
You'll have the benefit of only needing to research what you actually
use and automating the process nearly completely. Maven has the
benefit that artifacts will be referred to by identifiers, so you
don't have to worry about ambiguity with jar file names (i.e., how do
you know we didn't rename a jar file before putting it in
struts2-all-blah.zip? Not that we would, but there is ambiguity).
-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
Re: [OT] POM, licenses and dependency trees
Posted by stanlick <st...@gmail.com>.
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 <st...@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-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
>>
>>
>
>
>
> --
> 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-tp22309719p22353822.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
Re: [OT] POM, licenses and dependency trees
Posted by Wes Wannemacher <we...@wantii.com>.
On Tue, Mar 3, 2009 at 11:20 PM, stanlick <st...@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-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
>
>
--
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
Re: [OT] POM, licenses and dependency trees
Posted by stanlick <st...@gmail.com>.
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-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
Re: [OT] POM, licenses and dependency trees
Posted by Wes Wannemacher <we...@wantii.com>.
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-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] POM, licenses and dependency trees
Posted by stanlick <st...@gmail.com>.
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.
Musachy Barroso wrote:
>
> well, for core, that should be it.
>
> On Tue, Mar 3, 2009 at 2:57 PM, stanlick <st...@gmail.com> wrote:
>>
>> Well, since necessity is the mother of all invention and I have been
>> asked
>> for a magic bullet that poops out a stack of licenses, I am becoming more
>> creative. Consider the following simple dependency:
>>
>> <project ...
>> <dependencies>
>> <dependency>
>> <groupId>org.apache.struts</groupId>
>> <artifactId>struts2-core</artifactId>
>> <version>2.1.6</version>
>> </dependency>
>> </dependencies>
>> </project>
>>
>>
>> I am running mvn dependency:tree and expecting a large number of
>> downstream
>> files, when in fact all I get is what you see below. I *know* there are
>> more dependencies than this! Can you help me out with the flags and
>> switches?
>>
>> C:\Users\scott\MavenApps\appStats-app>mvn dependency:tree
>> [INFO] Scanning for projects...
>> [INFO] Searching repository for plugin with prefix: 'dependency'.
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Building appStats-app
>> [INFO] task-segment: [dependency:tree]
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] [dependency:tree]
>> [INFO] com.acme.appStats:appStats-app:jar:1.0-SNAPSHOT
>> [INFO] +- junit:junit:jar:3.8.1:test (scope not updated to compile)
>> [INFO] \- org.apache.struts:struts2-core:jar:2.1.6:compile
>> [INFO] +- com.opensymphony:xwork:jar:2.1.2:compile
>> [INFO] | \- org.springframework:spring-test:jar:2.5.6:compile
>> [INFO] | \- commons-logging:commons-logging:jar:1.1.1:compile
>> [INFO] +- org.freemarker:freemarker:jar:2.3.13:compile
>> [INFO] +- opensymphony:ognl:jar:2.6.11:compile
>> [INFO] +- commons-fileupload:commons-fileupload:jar:1.2.1:compile
>> [INFO] +- commons-io:commons-io:jar:1.3.2:compile
>> [INFO] \- com.sun:tools:jar:1.5.0:system
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] BUILD SUCCESSFUL
>> [INFO]
>> ------------------------------------------------------------------------
>> [INFO] Total time: 6 seconds
>> [INFO] Finished at: Tue Mar 03 12:57:53 CST 2009
>> [INFO] Final Memory: 10M/20M
>> [INFO]
>> ------------------------------------------------------------------------
>> --
>> View this message in context:
>> http://www.nabble.com/-OT--POM%2C-licenses-and-dependency-trees-tp22309719p22316588.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
>>
>>
>
>
>
> --
> "Hey you! Would you help me to carry the stone?" Pink Floyd
>
> ---------------------------------------------------------------------
> 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-tp22309719p22317341.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
Re: [OT] POM, licenses and dependency trees
Posted by Musachy Barroso <mu...@gmail.com>.
well, for core, that should be it.
On Tue, Mar 3, 2009 at 2:57 PM, stanlick <st...@gmail.com> wrote:
>
> Well, since necessity is the mother of all invention and I have been asked
> for a magic bullet that poops out a stack of licenses, I am becoming more
> creative. Consider the following simple dependency:
>
> <project ...
> <dependencies>
> <dependency>
> <groupId>org.apache.struts</groupId>
> <artifactId>struts2-core</artifactId>
> <version>2.1.6</version>
> </dependency>
> </dependencies>
> </project>
>
>
> I am running mvn dependency:tree and expecting a large number of downstream
> files, when in fact all I get is what you see below. I *know* there are
> more dependencies than this! Can you help me out with the flags and
> switches?
>
> C:\Users\scott\MavenApps\appStats-app>mvn dependency:tree
> [INFO] Scanning for projects...
> [INFO] Searching repository for plugin with prefix: 'dependency'.
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Building appStats-app
> [INFO] task-segment: [dependency:tree]
> [INFO]
> ------------------------------------------------------------------------
> [INFO] [dependency:tree]
> [INFO] com.acme.appStats:appStats-app:jar:1.0-SNAPSHOT
> [INFO] +- junit:junit:jar:3.8.1:test (scope not updated to compile)
> [INFO] \- org.apache.struts:struts2-core:jar:2.1.6:compile
> [INFO] +- com.opensymphony:xwork:jar:2.1.2:compile
> [INFO] | \- org.springframework:spring-test:jar:2.5.6:compile
> [INFO] | \- commons-logging:commons-logging:jar:1.1.1:compile
> [INFO] +- org.freemarker:freemarker:jar:2.3.13:compile
> [INFO] +- opensymphony:ognl:jar:2.6.11:compile
> [INFO] +- commons-fileupload:commons-fileupload:jar:1.2.1:compile
> [INFO] +- commons-io:commons-io:jar:1.3.2:compile
> [INFO] \- com.sun:tools:jar:1.5.0:system
> [INFO]
> ------------------------------------------------------------------------
> [INFO] BUILD SUCCESSFUL
> [INFO]
> ------------------------------------------------------------------------
> [INFO] Total time: 6 seconds
> [INFO] Finished at: Tue Mar 03 12:57:53 CST 2009
> [INFO] Final Memory: 10M/20M
> [INFO]
> ------------------------------------------------------------------------
> --
> View this message in context: http://www.nabble.com/-OT--POM%2C-licenses-and-dependency-trees-tp22309719p22316588.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
>
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [OT] POM, licenses and dependency trees
Posted by stanlick <st...@gmail.com>.
Well, since necessity is the mother of all invention and I have been asked
for a magic bullet that poops out a stack of licenses, I am becoming more
creative. Consider the following simple dependency:
<project ...
<dependencies>
<dependency>
<groupId>org.apache.struts</groupId>
<artifactId>struts2-core</artifactId>
<version>2.1.6</version>
</dependency>
</dependencies>
</project>
I am running mvn dependency:tree and expecting a large number of downstream
files, when in fact all I get is what you see below. I *know* there are
more dependencies than this! Can you help me out with the flags and
switches?
C:\Users\scott\MavenApps\appStats-app>mvn dependency:tree
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'dependency'.
[INFO]
------------------------------------------------------------------------
[INFO] Building appStats-app
[INFO] task-segment: [dependency:tree]
[INFO]
------------------------------------------------------------------------
[INFO] [dependency:tree]
[INFO] com.acme.appStats:appStats-app:jar:1.0-SNAPSHOT
[INFO] +- junit:junit:jar:3.8.1:test (scope not updated to compile)
[INFO] \- org.apache.struts:struts2-core:jar:2.1.6:compile
[INFO] +- com.opensymphony:xwork:jar:2.1.2:compile
[INFO] | \- org.springframework:spring-test:jar:2.5.6:compile
[INFO] | \- commons-logging:commons-logging:jar:1.1.1:compile
[INFO] +- org.freemarker:freemarker:jar:2.3.13:compile
[INFO] +- opensymphony:ognl:jar:2.6.11:compile
[INFO] +- commons-fileupload:commons-fileupload:jar:1.2.1:compile
[INFO] +- commons-io:commons-io:jar:1.3.2:compile
[INFO] \- com.sun:tools:jar:1.5.0:system
[INFO]
------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO]
------------------------------------------------------------------------
[INFO] Total time: 6 seconds
[INFO] Finished at: Tue Mar 03 12:57:53 CST 2009
[INFO] Final Memory: 10M/20M
[INFO]
------------------------------------------------------------------------
--
View this message in context: http://www.nabble.com/-OT--POM%2C-licenses-and-dependency-trees-tp22309719p22316588.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
Re: [OT] POM, licenses and dependency trees
Posted by Musachy Barroso <mu...@gmail.com>.
All the dependencies that we have, must have a license that is
compatible with ASL 2. I don't know of any way to compile a list of
licenses used, that would be cool for a maven plugin.
musachy
On Tue, Mar 3, 2009 at 9:32 AM, <st...@gmail.com> wrote:
> How does a company go about fleshing out the aspects of FOSS without wasting
> so many people's time? As FOSS gains in popularity, we are sinking in a
> quagmire of manual research, analysis and legal license inspections. It
> seems the FOSSology product will unpack compressed files and sniff around
> for licenses while on the other side of the planet we have Maven
> repositories that understand version dependencies -- but there is a void in
> bring them together!
>
> In an attempt to follow a concrete day-in-the-job, let us consider
> struts2.1.6 and let's further suppose that we plan to take advantage of all
> the downstream dependencies it offers (i.e. optionals).
>
>
> 1. Is there a version specific dependency tree mechanically available?
> - Will subsequent versions eventually appear in the same
> location.format?
> 2. What technique to use in determining the stack of licenses gleaned
> from this tree?
>
> I see developers struggling to bring together the jars necessary to do a
> build, which is time consuming and expensive. I see a legal team in the
> other building struggling to ascertain our risk, should this "stack" be
> implemented.
>
> P.S. Does anyone here have first hand experience with FOSSology?
>
> Peace,
> Scott
>
--
"Hey you! Would you help me to carry the stone?" Pink Floyd
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org