You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rajith Attapattu <ra...@gmail.com> on 2006/11/07 00:04:49 UTC
Re : Dependencies and how it's going to affect the release
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: Re : Dependencies and how it's going to affect the release
Posted by Marnie McCormack <ma...@googlemail.com>.
Hi All,
I just wanted to highlight a couple of points about M1, and my view of why
we're doing it now.
The key motivator for M1 is that we have users out there who have deployed
onto Qpid (Java). For that reason alone, we need to get an M1 of the java
broker/client out to support them going forward - before the major M2
changes planned.
In terms of dependencies - we should not be releasing the tests are part of
a release distribution imho. Seems like omeone has erroneously committed a
build script with tests included so we can switch this off and make things
simpler.
I don't think we can wait for maven - I know Steve has been working hard on
it, but unless it is realistically going to be complete by code freeze (i.e.
tonight) we'll have to get by without it until M2. We've also got a lot of
coding to complete (see the list of M2 JIRAs) and need to focus our
collective effort carefully so that the project moves forward as well as
possible.
Rajith - have you managed to pull a list of tasks together yet please ? We
could add the liencese item to the list and get it resolved for the release.
I don't think we have any major obstacles to M1, though I can see we might
have items to create JIRAs for and progress separately to make future
releases easier.
I'm happy to help out with all release tasks to help us get M1 out, annoying
or otherwise. I think it's really important that we get it released as soon
as we can.
Bfn,
Marnie
On 11/6/06, Rajith Attapattu <ra...@gmail.com> 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 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
Re: Dependencies and how it's going to affect the release
Posted by Daniel Kulp <da...@iona.com>.
+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: Re : Dependencies and how it's going to affect the release
Posted by Rajith Attapattu <ra...@gmail.com>.
We can confirm from Cliff, but AFIK we need to include license.txt for all
jars.
I guess Dan just mentioned that on the list.
-Rajith
On 11/7/06, Martin Ritchie <ri...@apache.org> wrote:
>
> I've included the full text of the license with the jms.jar and the
> slf4j, backport and junit. The Saxon website says there code is open
> source but not what license. I found an RPM of saxon that claimed to
> be MPL, so we could include that. The rest of the libs are all apache.
> Do we really need a license file for them?
>
> On 07/11/06, Robert Greig <ro...@gmail.com> wrote:
> > On 06/11/06, Steve Vinoski <vi...@iona.com> 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.
> >
> > Here is the redistribution clause from the licence for JMS.jar:
> >
> > 2. License to Distribute Software. In addition to
> > the license granted in Section 1 (Software
> > Internal Use and Development License Grant) of
> > these Supplemental Terms, subject to the terms and
> > conditions of this Agreement, including but not
> > limited to Section 3 (Java Technology
> > Restrictions), 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, (ii) do not distribute
> > additional software intended to replace any
> > component(s) of the Software, (iii) do not remove
> > or alter any proprietary legends or notices
> > contained in the Software, (iv) only distribute
> > the Software subject to a license agreement that
> > protects Sun's interests consistent with the terms
> > contained in this Agreement, and (v) agree to
> > defend and indemnify Sun and its licensors from
> > and against any damages, costs, liabilities,
> > settlement amounts and/or expenses (including
> > attorneys' fees) incurred in connection with any
> > claim, lawsuit or action by any third party that
> > arises or results from the use or distribution of
> > any and all Programs and/or Software.
> >
> > Does the Apache licence violate (iv)?
> >
> > RG
> >
>
>
> --
> Martin Ritchie
>
Re: Re : Dependencies and how it's going to affect the release
Posted by Rajith Attapattu <ra...@gmail.com>.
We don't need to hand write code.
The Geronimo spec project allready has done that.
We can use the following release by them
<dependency>
<groupId>geronimo-spec</groupId>
<artifactId>geronimo-spec-jms</artifactId>
<version>1.1-rc4</version>
<scope>compile</scope>
</dependency>
As john points out we need to follow the legal stuff righ to the dot.
Rajith
On 11/7/06, John O'Hara <jo...@gmail.com> wrote:
> Getting license details correct is critical.
> It may be that we have to ship a build without these files and provide the
> end user with an ANT or Maven task that fetches them.
> That way it is the user doing the getting and complying with the license
> concerned and its not our issue.
>
> Does ActiveMQ ship JMS.jar from the Apache distribution?
> It looks like they don't.
>
> If this is the case, we may have to hand write those files again from the
> published documentation on JMS.
>
> The published documentation license would allow us to re-create the files
> manually - or indeed just get the necessary interfaces from ActiveMQ,
since
> we're all part of the family.
>
> This is a pain, but legal is legal is legal, no matter how stupid it
seems.
>
> But we need to be squeeky clean on this.
> John
>
> On 07/11/06, Martin Ritchie <ri...@apache.org> wrote:
> >
> > I've included the full text of the license with the jms.jar and the
> > slf4j, backport and junit. The Saxon website says there code is open
> > source but not what license. I found an RPM of saxon that claimed to
> > be MPL, so we could include that. The rest of the libs are all apache.
> > Do we really need a license file for them?
> >
> > On 07/11/06, Robert Greig <ro...@gmail.com> wrote:
> > > On 06/11/06, Steve Vinoski <vi...@iona.com> 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.
> > >
> > > Here is the redistribution clause from the licence for JMS.jar:
> > >
> > > 2. License to Distribute Software. In addition to
> > > the license granted in Section 1 (Software
> > > Internal Use and Development License Grant) of
> > > these Supplemental Terms, subject to the terms and
> > > conditions of this Agreement, including but not
> > > limited to Section 3 (Java Technology
> > > Restrictions), 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, (ii) do not distribute
> > > additional software intended to replace any
> > > component(s) of the Software, (iii) do not remove
> > > or alter any proprietary legends or notices
> > > contained in the Software, (iv) only distribute
> > > the Software subject to a license agreement that
> > > protects Sun's interests consistent with the terms
> > > contained in this Agreement, and (v) agree to
> > > defend and indemnify Sun and its licensors from
> > > and against any damages, costs, liabilities,
> > > settlement amounts and/or expenses (including
> > > attorneys' fees) incurred in connection with any
> > > claim, lawsuit or action by any third party that
> > > arises or results from the use or distribution of
> > > any and all Programs and/or Software.
> > >
> > > Does the Apache licence violate (iv)?
> > >
> > > RG
> > >
> >
> >
> > --
> > Martin Ritchie
> >
>
>
Re: Re : Dependencies and how it's going to affect the release
Posted by John O'Hara <jo...@gmail.com>.
Getting license details correct is critical.
It may be that we have to ship a build without these files and provide the
end user with an ANT or Maven task that fetches them.
That way it is the user doing the getting and complying with the license
concerned and its not our issue.
Does ActiveMQ ship JMS.jar from the Apache distribution?
It looks like they don't.
If this is the case, we may have to hand write those files again from the
published documentation on JMS.
The published documentation license would allow us to re-create the files
manually - or indeed just get the necessary interfaces from ActiveMQ, since
we're all part of the family.
This is a pain, but legal is legal is legal, no matter how stupid it seems.
But we need to be squeeky clean on this.
John
On 07/11/06, Martin Ritchie <ri...@apache.org> wrote:
>
> I've included the full text of the license with the jms.jar and the
> slf4j, backport and junit. The Saxon website says there code is open
> source but not what license. I found an RPM of saxon that claimed to
> be MPL, so we could include that. The rest of the libs are all apache.
> Do we really need a license file for them?
>
> On 07/11/06, Robert Greig <ro...@gmail.com> wrote:
> > On 06/11/06, Steve Vinoski <vi...@iona.com> 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.
> >
> > Here is the redistribution clause from the licence for JMS.jar:
> >
> > 2. License to Distribute Software. In addition to
> > the license granted in Section 1 (Software
> > Internal Use and Development License Grant) of
> > these Supplemental Terms, subject to the terms and
> > conditions of this Agreement, including but not
> > limited to Section 3 (Java Technology
> > Restrictions), 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, (ii) do not distribute
> > additional software intended to replace any
> > component(s) of the Software, (iii) do not remove
> > or alter any proprietary legends or notices
> > contained in the Software, (iv) only distribute
> > the Software subject to a license agreement that
> > protects Sun's interests consistent with the terms
> > contained in this Agreement, and (v) agree to
> > defend and indemnify Sun and its licensors from
> > and against any damages, costs, liabilities,
> > settlement amounts and/or expenses (including
> > attorneys' fees) incurred in connection with any
> > claim, lawsuit or action by any third party that
> > arises or results from the use or distribution of
> > any and all Programs and/or Software.
> >
> > Does the Apache licence violate (iv)?
> >
> > RG
> >
>
>
> --
> Martin Ritchie
>
Re: Re : Dependencies and how it's going to affect the release
Posted by Martin Ritchie <ri...@apache.org>.
I've included the full text of the license with the jms.jar and the
slf4j, backport and junit. The Saxon website says there code is open
source but not what license. I found an RPM of saxon that claimed to
be MPL, so we could include that. The rest of the libs are all apache.
Do we really need a license file for them?
On 07/11/06, Robert Greig <ro...@gmail.com> wrote:
> On 06/11/06, Steve Vinoski <vi...@iona.com> 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.
>
> Here is the redistribution clause from the licence for JMS.jar:
>
> 2. License to Distribute Software. In addition to
> the license granted in Section 1 (Software
> Internal Use and Development License Grant) of
> these Supplemental Terms, subject to the terms and
> conditions of this Agreement, including but not
> limited to Section 3 (Java Technology
> Restrictions), 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, (ii) do not distribute
> additional software intended to replace any
> component(s) of the Software, (iii) do not remove
> or alter any proprietary legends or notices
> contained in the Software, (iv) only distribute
> the Software subject to a license agreement that
> protects Sun's interests consistent with the terms
> contained in this Agreement, and (v) agree to
> defend and indemnify Sun and its licensors from
> and against any damages, costs, liabilities,
> settlement amounts and/or expenses (including
> attorneys' fees) incurred in connection with any
> claim, lawsuit or action by any third party that
> arises or results from the use or distribution of
> any and all Programs and/or Software.
>
> Does the Apache licence violate (iv)?
>
> RG
>
--
Martin Ritchie
Re: Dependencies and how it's going to affect the release
Posted by Daniel Kulp <da...@iona.com>.
On Tuesday November 07 2006 3:58 am, Robert Greig wrote:
> On 06/11/06, Steve Vinoski <vi...@iona.com> 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.
>
> Here is the redistribution clause from the licence for JMS.jar:
>
> 2. License to Distribute Software. In addition to
> the license granted in Section 1 (Software
> Internal Use and Development License Grant) of
> these Supplemental Terms, subject to the terms and
> conditions of this Agreement, including but not
> limited to Section 3 (Java Technology
> Restrictions), 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, (ii) do not distribute
> additional software intended to replace any
> component(s) of the Software, (iii) do not remove
> or alter any proprietary legends or notices
> contained in the Software, (iv) only distribute
> the Software subject to a license agreement that
> protects Sun's interests consistent with the terms
> contained in this Agreement, and (v) agree to
> defend and indemnify Sun and its licensors from
> and against any damages, costs, liabilities,
> settlement amounts and/or expenses (including
> attorneys' fees) incurred in connection with any
> claim, lawsuit or action by any third party that
> arises or results from the use or distribution of
> any and all Programs and/or Software.
>
> Does the Apache licence violate (iv)?
>
> RG
Yes. That's the Sun BCL license. Explicitly not allowed:
http://people.apache.org/~cliffs/3party.html
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194 F:781-902-8001
daniel.kulp@iona.com
Re: Re : Dependencies and how it's going to affect the release
Posted by Robert Greig <ro...@gmail.com>.
On 06/11/06, Steve Vinoski <vi...@iona.com> 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.
Here is the redistribution clause from the licence for JMS.jar:
2. License to Distribute Software. In addition to
the license granted in Section 1 (Software
Internal Use and Development License Grant) of
these Supplemental Terms, subject to the terms and
conditions of this Agreement, including but not
limited to Section 3 (Java Technology
Restrictions), 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, (ii) do not distribute
additional software intended to replace any
component(s) of the Software, (iii) do not remove
or alter any proprietary legends or notices
contained in the Software, (iv) only distribute
the Software subject to a license agreement that
protects Sun's interests consistent with the terms
contained in this Agreement, and (v) agree to
defend and indemnify Sun and its licensors from
and against any damages, costs, liabilities,
settlement amounts and/or expenses (including
attorneys' fees) incurred in connection with any
claim, lawsuit or action by any third party that
arises or results from the use or distribution of
any and all Programs and/or Software.
Does the Apache licence violate (iv)?
RG
Re: Re : Dependencies and how it's going to affect the release
Posted by Steve Vinoski <vi...@iona.com>.
+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