You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Daniel Kulp <da...@iona.com> on 2006/11/07 01:32:17 UTC
Re: Dependencies and how it's going to affect the release
+1 to maven as well.. :-)
There is also the jbossall-client.jar in the source tree. I believe that
is LGPL or part LGPL, also not allowed as part of a distribution at
apache.
I've been chatting with the Maven folks today about the LICENSE/NOTICE
issues. As of November 1, all apache projects have to have those files,
including Maven releases. Thus, they now have extra incentive to get
that working smoothly. :-)
Seriously, they are writing a plugin that will use the <license> tags
from the maven poms to automatically build up the notice files and such.
Should make things much easier to manage.
Dan
On Monday November 06 2006 6:58 pm, Steve Vinoski wrote:
> +1 to maven, which I've been working on for awhile. So far in doing
> the maven work I've been surprised by both 1) the number of
> dependencies, which is much higher than I expected, and 2) the
> dependencies which aren't really legal. The JMS jar is one. Another
> is the Sun fscontext stuff, which AIUI is used only for testing, but
> is seemingly unavailable from any maven repository as far as I can
> see. As Rajith says, managing these dependencies will be a big part
> of getting M1 right.
>
> The main thing that's been killing me as far as maven goes are the
> test areas. They're not organized well, have dependencies between
> them, and as I've pointed out before, they mix unit tests, system
> tests, and performance tests. I also ran into the junit3 vs. junit4
> issue with the maven surefire plugin, but have managed to get some of
> the tests working with junit4 and the maven antrun plugin. If the
> test areas were in better shape, the maven work would have been
> finished weeks ago.
>
> I've been committing to the maven branch for a few weeks now, but
> obviously it still needs work. Anyone can take a look at it if they
> like, obviously. I'm currently working on ensuring that the maven
> branch has the latest changes from trunk, so that I'm sure I'm not
> chasing test failures that are already fixed. Meanwhile, if anyone
> else wants to pitch in on the maven work, I'd be glad for the help.
>
> --steve
>
> On Nov 6, 2006, at 6:04 PM, Rajith Attapattu wrote:
> > Hi All,
> >
> > AFAIK when we release we will have to package some of the
> > dependcies with
> > our binary distribution.
> > When we do this we need to make sure we supply the license.txt's
> > for those
> > dependencies.
> >
> > Currently we have static dependencies in our lib files scattered
> > over the
> > project.
> > So we need to think about them.
> >
> > For example the jms.jar. Now where did this come from?? where is
> > the license
> > associated with this?
> > Usually in apache we use the geronimo spec project to get the
> > API's, so we
> > can use that for JMS.
> >
> > If I dependencies keeps growing then that will make things even more
> > diffficult to manage, especially at distribtuion/release time.
> >
> > Maybe it's time to get things a bit more organized and move to a
> > maven structure where some of these headache are taken care of.
> >
> > Regards,
> >
> > Rajith
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194 F:781-902-8001
daniel.kulp@iona.com
Re: Dependencies and how it's going to affect the release
Posted by Daniel Kulp <da...@iona.com>.
>
> The sun fscontext is fine to include from Sun's point of view:
> " Sun grants you a non-exclusive,
> non-transferable, limited license to reproduce and
> distribute the Software in binary form only,
> provided that you (i) distribute the Software
> complete and unmodified and only bundled as part
> of your Programs, "
>
> http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId
>=7110-jndi-1.2.1-oth-JPR&SiteId=JSC&TransactionId=noreg
>
> We may not have the source to include under the ASF license but we can
> include the binary.
>
> Are we not allowed to include non ASF-licensed(or equally permissive)
> software in our release, be that source or binary format?
Martin,
Cliff has a draft page of license "information" at:
http://people.apache.org/~cliffs/3party.html
Of note is that the Sun BCL license (that you are quoting from) is
explicitly listed in the section of "excluded" licenses. Thus, you
cannot distribute it with Apache software.
I think the problem with the BCL license is the indemnification clauses.
Not sure though. IANAL
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194 F:781-902-8001
daniel.kulp@iona.com
Re: Dependencies and how it's going to affect the release
Posted by Carl Trieloff <cc...@redhat.com>.
Daniel Kulp wrote:
> +1 to maven as well.. :-)
>
> There is also the jbossall-client.jar in the source tree. I believe that
> is LGPL or part LGPL, also not allowed as part of a distribution at
> apache.
>
I understand that we may have these licenses in the tool chain or test
suite, but they can't be
included in any source or binary distribution.
> I've been chatting with the Maven folks today about the LICENSE/NOTICE
> issues. As of November 1, all apache projects have to have those files,
> including Maven releases. Thus, they now have extra incentive to get
> that working smoothly. :-)
>
> Seriously, they are writing a plugin that will use the <license> tags
> from the maven poms to automatically build up the notice files and such.
> Should make things much easier to manage.
>
Please let us know when this works...
>
> Dan
>
>
>
> On Monday November 06 2006 6:58 pm, Steve Vinoski wrote:
>
>> +1 to maven, which I've been working on for awhile. So far in doing
>> the maven work I've been surprised by both 1) the number of
>> dependencies, which is much higher than I expected, and 2) the
>> dependencies which aren't really legal. The JMS jar is one. Another
>> is the Sun fscontext stuff, which AIUI is used only for testing, but
>> is seemingly unavailable from any maven repository as far as I can
>> see. As Rajith says, managing these dependencies will be a big part
>> of getting M1 right.
>>
>> The main thing that's been killing me as far as maven goes are the
>> test areas. They're not organized well, have dependencies between
>> them, and as I've pointed out before, they mix unit tests, system
>> tests, and performance tests. I also ran into the junit3 vs. junit4
>> issue with the maven surefire plugin, but have managed to get some of
>> the tests working with junit4 and the maven antrun plugin. If the
>> test areas were in better shape, the maven work would have been
>> finished weeks ago.
>>
>> I've been committing to the maven branch for a few weeks now, but
>> obviously it still needs work. Anyone can take a look at it if they
>> like, obviously. I'm currently working on ensuring that the maven
>> branch has the latest changes from trunk, so that I'm sure I'm not
>> chasing test failures that are already fixed. Meanwhile, if anyone
>> else wants to pitch in on the maven work, I'd be glad for the help.
>>
>> --steve
>>
>> On Nov 6, 2006, at 6:04 PM, Rajith Attapattu wrote:
>>
>>> Hi All,
>>>
>>> AFAIK when we release we will have to package some of the
>>> dependcies with
>>> our binary distribution.
>>> When we do this we need to make sure we supply the license.txt's
>>> for those
>>> dependencies.
>>>
>>> Currently we have static dependencies in our lib files scattered
>>> over the
>>> project.
>>> So we need to think about them.
>>>
>>> For example the jms.jar. Now where did this come from?? where is
>>> the license
>>> associated with this?
>>> Usually in apache we use the geronimo spec project to get the
>>> API's, so we
>>> can use that for JMS.
>>>
>>> If I dependencies keeps growing then that will make things even more
>>> diffficult to manage, especially at distribtuion/release time.
>>>
>>> Maybe it's time to get things a bit more organized and move to a
>>> maven structure where some of these headache are taken care of.
>>>
>>> Regards,
>>>
>>> Rajith
>>>
>
>
Re: Dependencies and how it's going to affect the release
Posted by Rajith Attapattu <ra...@gmail.com>.
Martin,
We can only include ASF compatible licenses (and thats decided by Apache
Legal).
I am sure the sun license are not covered.
If you are not sure, you can talk to Cliff as he handles legal stuff.
If we submit with this one we are going to have a time with the incubator
PMC.
I suggest we clean up and work on the dependencies.
Regards,
Rajith
On 11/7/06, Martin Ritchie <ri...@apache.org> wrote:
>
> On 07/11/06, Daniel Kulp <da...@iona.com> wrote:
> >
> > +1 to maven as well.. :-)
> >
> > There is also the jbossall-client.jar in the source tree. I believe
> that
> > is LGPL or part LGPL, also not allowed as part of a distribution at
> > apache.
> >
> > I've been chatting with the Maven folks today about the LICENSE/NOTICE
> > issues. As of November 1, all apache projects have to have those
> files,
> > including Maven releases. Thus, they now have extra incentive to get
> > that working smoothly. :-)
> >
> > Seriously, they are writing a plugin that will use the <license> tags
> > from the maven poms to automatically build up the notice files and such.
> > Should make things much easier to manage.
> >
> >
> > Dan
> >
> >
> >
> > On Monday November 06 2006 6:58 pm, Steve Vinoski wrote:
> > > +1 to maven, which I've been working on for awhile. So far in doing
> > > the maven work I've been surprised by both 1) the number of
> > > dependencies, which is much higher than I expected, and 2) the
> > > dependencies which aren't really legal. The JMS jar is one. Another
> > > is the Sun fscontext stuff, which AIUI is used only for testing, but
> > > is seemingly unavailable from any maven repository as far as I can
> > > see. As Rajith says, managing these dependencies will be a big part
> > > of getting M1 right.
> > >
> > > The main thing that's been killing me as far as maven goes are the
> > > test areas. They're not organized well, have dependencies between
> > > them, and as I've pointed out before, they mix unit tests, system
> > > tests, and performance tests. I also ran into the junit3 vs. junit4
> > > issue with the maven surefire plugin, but have managed to get some of
> > > the tests working with junit4 and the maven antrun plugin. If the
> > > test areas were in better shape, the maven work would have been
> > > finished weeks ago.
> > >
> > > I've been committing to the maven branch for a few weeks now, but
> > > obviously it still needs work. Anyone can take a look at it if they
> > > like, obviously. I'm currently working on ensuring that the maven
> > > branch has the latest changes from trunk, so that I'm sure I'm not
> > > chasing test failures that are already fixed. Meanwhile, if anyone
> > > else wants to pitch in on the maven work, I'd be glad for the help.
> > >
> > > --steve
> > >
> > > On Nov 6, 2006, at 6:04 PM, Rajith Attapattu wrote:
> > > > Hi All,
> > > >
> > > > AFAIK when we release we will have to package some of the
> > > > dependcies with
> > > > our binary distribution.
> > > > When we do this we need to make sure we supply the license.txt's
> > > > for those
> > > > dependencies.
> > > >
> > > > Currently we have static dependencies in our lib files scattered
> > > > over the
> > > > project.
> > > > So we need to think about them.
> > > >
> > > > For example the jms.jar. Now where did this come from?? where is
> > > > the license
> > > > associated with this?
> > > > Usually in apache we use the geronimo spec project to get the
> > > > API's, so we
> > > > can use that for JMS.
> > > >
> > > > If I dependencies keeps growing then that will make things even more
> > > > diffficult to manage, especially at distribtuion/release time.
> > > >
> > > > Maybe it's time to get things a bit more organized and move to a
> > > > maven structure where some of these headache are taken care of.
> > > >
> > > > Regards,
> > > >
> > > > Rajith
> >
> > --
> > J. Daniel Kulp
> > Principal Engineer
> > IONA
> > P: 781-902-8727 C: 508-380-7194 F:781-902-8001
> > daniel.kulp@iona.com
> >
>
> The sun fscontext is fine to include from Sun's point of view:
> " Sun grants you a non-exclusive,
> non-transferable, limited license to reproduce and
> distribute the Software in binary form only,
> provided that you (i) distribute the Software
> complete and unmodified and only bundled as part
> of your Programs, "
>
>
> http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=7110-jndi-1.2.1-oth-JPR&SiteId=JSC&TransactionId=noreg
>
> We may not have the source to include under the ASF license but we can
> include the binary.
>
> Are we not allowed to include non ASF-licensed(or equally permissive)
> software in our release, be that source or binary format?
>
>
> --
> Martin Ritchie
>
Re: Dependencies and how it's going to affect the release
Posted by Martin Ritchie <ri...@apache.org>.
On 07/11/06, Daniel Kulp <da...@iona.com> wrote:
>
> +1 to maven as well.. :-)
>
> There is also the jbossall-client.jar in the source tree. I believe that
> is LGPL or part LGPL, also not allowed as part of a distribution at
> apache.
>
> I've been chatting with the Maven folks today about the LICENSE/NOTICE
> issues. As of November 1, all apache projects have to have those files,
> including Maven releases. Thus, they now have extra incentive to get
> that working smoothly. :-)
>
> Seriously, they are writing a plugin that will use the <license> tags
> from the maven poms to automatically build up the notice files and such.
> Should make things much easier to manage.
>
>
> Dan
>
>
>
> On Monday November 06 2006 6:58 pm, Steve Vinoski wrote:
> > +1 to maven, which I've been working on for awhile. So far in doing
> > the maven work I've been surprised by both 1) the number of
> > dependencies, which is much higher than I expected, and 2) the
> > dependencies which aren't really legal. The JMS jar is one. Another
> > is the Sun fscontext stuff, which AIUI is used only for testing, but
> > is seemingly unavailable from any maven repository as far as I can
> > see. As Rajith says, managing these dependencies will be a big part
> > of getting M1 right.
> >
> > The main thing that's been killing me as far as maven goes are the
> > test areas. They're not organized well, have dependencies between
> > them, and as I've pointed out before, they mix unit tests, system
> > tests, and performance tests. I also ran into the junit3 vs. junit4
> > issue with the maven surefire plugin, but have managed to get some of
> > the tests working with junit4 and the maven antrun plugin. If the
> > test areas were in better shape, the maven work would have been
> > finished weeks ago.
> >
> > I've been committing to the maven branch for a few weeks now, but
> > obviously it still needs work. Anyone can take a look at it if they
> > like, obviously. I'm currently working on ensuring that the maven
> > branch has the latest changes from trunk, so that I'm sure I'm not
> > chasing test failures that are already fixed. Meanwhile, if anyone
> > else wants to pitch in on the maven work, I'd be glad for the help.
> >
> > --steve
> >
> > On Nov 6, 2006, at 6:04 PM, Rajith Attapattu wrote:
> > > Hi All,
> > >
> > > AFAIK when we release we will have to package some of the
> > > dependcies with
> > > our binary distribution.
> > > When we do this we need to make sure we supply the license.txt's
> > > for those
> > > dependencies.
> > >
> > > Currently we have static dependencies in our lib files scattered
> > > over the
> > > project.
> > > So we need to think about them.
> > >
> > > For example the jms.jar. Now where did this come from?? where is
> > > the license
> > > associated with this?
> > > Usually in apache we use the geronimo spec project to get the
> > > API's, so we
> > > can use that for JMS.
> > >
> > > If I dependencies keeps growing then that will make things even more
> > > diffficult to manage, especially at distribtuion/release time.
> > >
> > > Maybe it's time to get things a bit more organized and move to a
> > > maven structure where some of these headache are taken care of.
> > >
> > > Regards,
> > >
> > > Rajith
>
> --
> J. Daniel Kulp
> Principal Engineer
> IONA
> P: 781-902-8727 C: 508-380-7194 F:781-902-8001
> daniel.kulp@iona.com
>
The sun fscontext is fine to include from Sun's point of view:
" Sun grants you a non-exclusive,
non-transferable, limited license to reproduce and
distribute the Software in binary form only,
provided that you (i) distribute the Software
complete and unmodified and only bundled as part
of your Programs, "
http://javashoplm.sun.com/ECom/docs/Welcome.jsp?StoreId=22&PartDetailId=7110-jndi-1.2.1-oth-JPR&SiteId=JSC&TransactionId=noreg
We may not have the source to include under the ASF license but we can
include the binary.
Are we not allowed to include non ASF-licensed(or equally permissive)
software in our release, be that source or binary format?
--
Martin Ritchie