Licensing problem with the transaction component?

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Licensing problem with the transaction component?

Rick McGuire
I was looking at how the transaction component was building to figure
out how the javax.transaction classes.  If I understand what the build
is doing, then it appears that the bundle is getting built by directly
embedding the javax.transaction and javax.transaction.xa from the jvm
used to build the bundle.  I'm nervous that this would cause copyright
issues since these classes are Sun copyrighted IP and I'm not sure that
Apache is in the clear with redistributing those classes that way.  
We've got a similar issue in Geronimo right now, and I was trying to
figure out how this had been solved here when I discovered this.  Am I
interpreting what's going on with the build correctly?

Rick


Reply | Threaded
Open this post in threaded view
|

Re: Licensing problem with the transaction component?

Guillaume Nodet
I wasn't aware that there was any problem with redistributing those
classes.   You're right, we embed those classes from the geronimo spec
jar, so I guess the problem is the same as in geronimo.

On Wed, Oct 21, 2009 at 16:50, Rick McGuire <[hidden email]> wrote:

> I was looking at how the transaction component was building to figure out
> how the javax.transaction classes.  If I understand what the build is doing,
> then it appears that the bundle is getting built by directly embedding the
> javax.transaction and javax.transaction.xa from the jvm used to build the
> bundle.  I'm nervous that this would cause copyright issues since these
> classes are Sun copyrighted IP and I'm not sure that Apache is in the clear
> with redistributing those classes that way.  We've got a similar issue in
> Geronimo right now, and I was trying to figure out how this had been solved
> here when I discovered this.  Am I interpreting what's going on with the
> build correctly?
>
> Rick
>
>
>



--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

Re: Licensing problem with the transaction component?

kevan

On Oct 21, 2009, at 11:57 AM, Guillaume Nodet wrote:

> I wasn't aware that there was any problem with redistributing those
> classes.   You're right, we embed those classes from the geronimo spec
> jar, so I guess the problem is the same as in geronimo.
>
> On Wed, Oct 21, 2009 at 16:50, Rick McGuire <[hidden email]> wrote:
>> I was looking at how the transaction component was building to  
>> figure out
>> how the javax.transaction classes.  If I understand what the build  
>> is doing,
>> then it appears that the bundle is getting built by directly  
>> embedding the
>> javax.transaction and javax.transaction.xa from the jvm used to  
>> build the
>> bundle.  I'm nervous that this would cause copyright issues since  
>> these
>> classes are Sun copyrighted IP and I'm not sure that Apache is in  
>> the clear
>> with redistributing those classes that way.  We've got a similar  
>> issue in
>> Geronimo right now, and I was trying to figure out how this had  
>> been solved
>> here when I discovered this.  Am I interpreting what's going on  
>> with the
>> build correctly?

Not sure I completely understand. So, let me replay...

At buildtime, the transaction component is copying classes from the  
JDK/JSE  libraries into the transaction bundle. If that's the case,  
then I'd agree that's a problem.

I don't know of any instances where this occurs in Geronimo. I think  
you're referring to a ClassLoading issue involving javax.transaction  
classes...

Geronimo has a JTA spec implementation. The transaction component  
should use that instead -- http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-jta_1.1_spec/1.1.1/geronimo-jta_1.1_spec-1.1.1.jar

--kevan
Reply | Threaded
Open this post in threaded view
|

Re: Licensing problem with the transaction component?

Guillaume Nodet
I don't follow.  We use the ones from the geronimo jta jar.  We would
not be able to grab those from the JRE as it only contains a few
classes (and not the TransactionManager interface for example), so
that would obviously not work for the transaction component.

On Wed, Oct 21, 2009 at 18:23, Kevan Miller <[hidden email]> wrote:

>
> On Oct 21, 2009, at 11:57 AM, Guillaume Nodet wrote:
>
>> I wasn't aware that there was any problem with redistributing those
>> classes.   You're right, we embed those classes from the geronimo spec
>> jar, so I guess the problem is the same as in geronimo.
>>
>> On Wed, Oct 21, 2009 at 16:50, Rick McGuire <[hidden email]> wrote:
>>>
>>> I was looking at how the transaction component was building to figure out
>>> how the javax.transaction classes.  If I understand what the build is
>>> doing,
>>> then it appears that the bundle is getting built by directly embedding
>>> the
>>> javax.transaction and javax.transaction.xa from the jvm used to build the
>>> bundle.  I'm nervous that this would cause copyright issues since these
>>> classes are Sun copyrighted IP and I'm not sure that Apache is in the
>>> clear
>>> with redistributing those classes that way.  We've got a similar issue in
>>> Geronimo right now, and I was trying to figure out how this had been
>>> solved
>>> here when I discovered this.  Am I interpreting what's going on with the
>>> build correctly?
>
> Not sure I completely understand. So, let me replay...
>
> At buildtime, the transaction component is copying classes from the JDK/JSE
>  libraries into the transaction bundle. If that's the case, then I'd agree
> that's a problem.
>
> I don't know of any instances where this occurs in Geronimo. I think you're
> referring to a ClassLoading issue involving javax.transaction classes...
>
> Geronimo has a JTA spec implementation. The transaction component should use
> that instead --
> http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-jta_1.1_spec/1.1.1/geronimo-jta_1.1_spec-1.1.1.jar
>
> --kevan
>



--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

Re: Licensing problem with the transaction component?

Guillaume Nodet
FWIW, i include the following output of maven.  You'll clearly see
that we use the geronimo jta spec jar.

gnodet:(svn)aries[aries:824258]/trunk/transaction$ mvn dependency:tree -o
[INFO]
NOTE: Maven is executing in offline mode. Any artifacts not already in
your local
repository will be inaccessible.

[INFO] Scanning for projects...
[INFO] ------------------------------------------------------------------------
[INFO] Building Apache Aries Transaction
[INFO]    task-segment: [dependency:tree]
[INFO] ------------------------------------------------------------------------
[INFO] [dependency:tree {execution: default-cli}]
[INFO] org.apache.aries.transaction:aries-transaction:bundle:1.0.0-incubating-SNAPSHOT
[INFO] +- org.osgi:org.osgi.core:jar:4.1.0:provided
[INFO] +- org.osgi:org.osgi.compendium:jar:4.1.0:provided
[INFO] +- org.apache.geronimo.components:geronimo-transaction:jar:2.1.2:compile
[INFO] |  +- org.slf4j:slf4j-api:jar:1.4.3:compile
[INFO] |  +- org.apache.geronimo.specs:geronimo-jta_1.1_spec:jar:1.1.1:compile
[INFO] |  \- org.apache.geronimo.specs:geronimo-j2ee-connector_1.5_spec:jar:2.0.0:compile
[INFO] +- org.objectweb.howl:howl:jar:1.0.1-1:compile
[INFO] \- org.springframework:spring-tx:jar:2.5.6:compile
[INFO]    +- commons-logging:commons-logging:jar:1.1.1:compile
[INFO]    +- org.springframework:spring-beans:jar:2.5.6:compile
[INFO]    +- org.springframework:spring-context:jar:2.5.6:compile
[INFO]    |  \- aopalliance:aopalliance:jar:1.0:compile
[INFO]    \- org.springframework:spring-core:jar:2.5.6:compile
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7 seconds
[INFO] Finished at: Wed Oct 21 20:09:08 CEST 2009
[INFO] Final Memory: 29M/80M
[INFO] ------------------------------------------------------------------------


On Wed, Oct 21, 2009 at 20:00, Guillaume Nodet <[hidden email]> wrote:

> I don't follow.  We use the ones from the geronimo jta jar.  We would
> not be able to grab those from the JRE as it only contains a few
> classes (and not the TransactionManager interface for example), so
> that would obviously not work for the transaction component.
>
> On Wed, Oct 21, 2009 at 18:23, Kevan Miller <[hidden email]> wrote:
>>
>> On Oct 21, 2009, at 11:57 AM, Guillaume Nodet wrote:
>>
>>> I wasn't aware that there was any problem with redistributing those
>>> classes.   You're right, we embed those classes from the geronimo spec
>>> jar, so I guess the problem is the same as in geronimo.
>>>
>>> On Wed, Oct 21, 2009 at 16:50, Rick McGuire <[hidden email]> wrote:
>>>>
>>>> I was looking at how the transaction component was building to figure out
>>>> how the javax.transaction classes.  If I understand what the build is
>>>> doing,
>>>> then it appears that the bundle is getting built by directly embedding
>>>> the
>>>> javax.transaction and javax.transaction.xa from the jvm used to build the
>>>> bundle.  I'm nervous that this would cause copyright issues since these
>>>> classes are Sun copyrighted IP and I'm not sure that Apache is in the
>>>> clear
>>>> with redistributing those classes that way.  We've got a similar issue in
>>>> Geronimo right now, and I was trying to figure out how this had been
>>>> solved
>>>> here when I discovered this.  Am I interpreting what's going on with the
>>>> build correctly?
>>
>> Not sure I completely understand. So, let me replay...
>>
>> At buildtime, the transaction component is copying classes from the JDK/JSE
>>  libraries into the transaction bundle. If that's the case, then I'd agree
>> that's a problem.
>>
>> I don't know of any instances where this occurs in Geronimo. I think you're
>> referring to a ClassLoading issue involving javax.transaction classes...
>>
>> Geronimo has a JTA spec implementation. The transaction component should use
>> that instead --
>> http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-jta_1.1_spec/1.1.1/geronimo-jta_1.1_spec-1.1.1.jar
>>
>> --kevan
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>



--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Reply | Threaded
Open this post in threaded view
|

Re: Licensing problem with the transaction component?

David Jencks
In reply to this post by kevan
Can someone point to the svn?  Based on Guillaume's comment and all  
the servicemix spec and bundle repackaging this would be repackaging  
the geronimo classes, not the jdk classes.

thanks
david jencks

On Oct 21, 2009, at 9:23 AM, Kevan Miller wrote:

>
> On Oct 21, 2009, at 11:57 AM, Guillaume Nodet wrote:
>
>> I wasn't aware that there was any problem with redistributing those
>> classes.   You're right, we embed those classes from the geronimo  
>> spec
>> jar, so I guess the problem is the same as in geronimo.
>>
>> On Wed, Oct 21, 2009 at 16:50, Rick McGuire <[hidden email]>  
>> wrote:
>>> I was looking at how the transaction component was building to  
>>> figure out
>>> how the javax.transaction classes.  If I understand what the build  
>>> is doing,
>>> then it appears that the bundle is getting built by directly  
>>> embedding the
>>> javax.transaction and javax.transaction.xa from the jvm used to  
>>> build the
>>> bundle.  I'm nervous that this would cause copyright issues since  
>>> these
>>> classes are Sun copyrighted IP and I'm not sure that Apache is in  
>>> the clear
>>> with redistributing those classes that way.  We've got a similar  
>>> issue in
>>> Geronimo right now, and I was trying to figure out how this had  
>>> been solved
>>> here when I discovered this.  Am I interpreting what's going on  
>>> with the
>>> build correctly?
>
> Not sure I completely understand. So, let me replay...
>
> At buildtime, the transaction component is copying classes from the  
> JDK/JSE  libraries into the transaction bundle. If that's the case,  
> then I'd agree that's a problem.
>
> I don't know of any instances where this occurs in Geronimo. I think  
> you're referring to a ClassLoading issue involving javax.transaction  
> classes...
>
> Geronimo has a JTA spec implementation. The transaction component  
> should use that instead -- http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-jta_1.1_spec/1.1.1/geronimo-jta_1.1_spec-1.1.1.jar
>
> --kevan

Reply | Threaded
Open this post in threaded view
|

Re: Licensing problem with the transaction component?

Joe Bohn
In reply to this post by Guillaume Nodet
It seems to me that classes included match those in the geronimo jta
spec.  However, I'm not sure how these are getting included the
aries/transaction bundle.  The pom in aries/transaction only includes a
dependency on geronimo-transaction 2.1.2.  Perhaps the dependency on
geronimo-transactions results in a transitive dependency on the geronimo
jta spec that is including the javax.transaction classes.

Joe


Guillaume Nodet wrote:

> I wasn't aware that there was any problem with redistributing those
> classes.   You're right, we embed those classes from the geronimo spec
> jar, so I guess the problem is the same as in geronimo.
>
> On Wed, Oct 21, 2009 at 16:50, Rick McGuire <[hidden email]> wrote:
>> I was looking at how the transaction component was building to figure out
>> how the javax.transaction classes.  If I understand what the build is doing,
>> then it appears that the bundle is getting built by directly embedding the
>> javax.transaction and javax.transaction.xa from the jvm used to build the
>> bundle.  I'm nervous that this would cause copyright issues since these
>> classes are Sun copyrighted IP and I'm not sure that Apache is in the clear
>> with redistributing those classes that way.  We've got a similar issue in
>> Geronimo right now, and I was trying to figure out how this had been solved
>> here when I discovered this.  Am I interpreting what's going on with the
>> build correctly?
>>
>> Rick
>>
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Licensing problem with the transaction component?

Joe Bohn
In reply to this post by David Jencks

  https://svn.apache.org/repos/asf

David Jencks wrote:

> Can someone point to the svn?  Based on Guillaume's comment and all the
> servicemix spec and bundle repackaging this would be repackaging the
> geronimo classes, not the jdk classes.
>
> thanks
> david jencks
>
> On Oct 21, 2009, at 9:23 AM, Kevan Miller wrote:
>
>>
>> On Oct 21, 2009, at 11:57 AM, Guillaume Nodet wrote:
>>
>>> I wasn't aware that there was any problem with redistributing those
>>> classes.   You're right, we embed those classes from the geronimo spec
>>> jar, so I guess the problem is the same as in geronimo.
>>>
>>> On Wed, Oct 21, 2009 at 16:50, Rick McGuire <[hidden email]> wrote:
>>>> I was looking at how the transaction component was building to
>>>> figure out
>>>> how the javax.transaction classes.  If I understand what the build
>>>> is doing,
>>>> then it appears that the bundle is getting built by directly
>>>> embedding the
>>>> javax.transaction and javax.transaction.xa from the jvm used to
>>>> build the
>>>> bundle.  I'm nervous that this would cause copyright issues since these
>>>> classes are Sun copyrighted IP and I'm not sure that Apache is in
>>>> the clear
>>>> with redistributing those classes that way.  We've got a similar
>>>> issue in
>>>> Geronimo right now, and I was trying to figure out how this had been
>>>> solved
>>>> here when I discovered this.  Am I interpreting what's going on with
>>>> the
>>>> build correctly?
>>
>> Not sure I completely understand. So, let me replay...
>>
>> At buildtime, the transaction component is copying classes from the
>> JDK/JSE  libraries into the transaction bundle. If that's the case,
>> then I'd agree that's a problem.
>>
>> I don't know of any instances where this occurs in Geronimo. I think
>> you're referring to a ClassLoading issue involving javax.transaction
>> classes...
>>
>> Geronimo has a JTA spec implementation. The transaction component
>> should use that instead --
>> http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-jta_1.1_spec/1.1.1/geronimo-jta_1.1_spec-1.1.1.jar 
>>
>>
>> --kevan
Reply | Threaded
Open this post in threaded view
|

Re: Licensing problem with the transaction component?

Joe Bohn
cut/paste error ... let's try again:

https://svn.apache.org/repos/asf/incubator/aries/trunk/transaction

Joe Bohn wrote:

>
>  https://svn.apache.org/repos/asf
>
> David Jencks wrote:
>> Can someone point to the svn?  Based on Guillaume's comment and all
>> the servicemix spec and bundle repackaging this would be repackaging
>> the geronimo classes, not the jdk classes.
>>
>> thanks
>> david jencks
>>
>> On Oct 21, 2009, at 9:23 AM, Kevan Miller wrote:
>>
>>>
>>> On Oct 21, 2009, at 11:57 AM, Guillaume Nodet wrote:
>>>
>>>> I wasn't aware that there was any problem with redistributing those
>>>> classes.   You're right, we embed those classes from the geronimo spec
>>>> jar, so I guess the problem is the same as in geronimo.
>>>>
>>>> On Wed, Oct 21, 2009 at 16:50, Rick McGuire <[hidden email]> wrote:
>>>>> I was looking at how the transaction component was building to
>>>>> figure out
>>>>> how the javax.transaction classes.  If I understand what the build
>>>>> is doing,
>>>>> then it appears that the bundle is getting built by directly
>>>>> embedding the
>>>>> javax.transaction and javax.transaction.xa from the jvm used to
>>>>> build the
>>>>> bundle.  I'm nervous that this would cause copyright issues since
>>>>> these
>>>>> classes are Sun copyrighted IP and I'm not sure that Apache is in
>>>>> the clear
>>>>> with redistributing those classes that way.  We've got a similar
>>>>> issue in
>>>>> Geronimo right now, and I was trying to figure out how this had
>>>>> been solved
>>>>> here when I discovered this.  Am I interpreting what's going on
>>>>> with the
>>>>> build correctly?
>>>
>>> Not sure I completely understand. So, let me replay...
>>>
>>> At buildtime, the transaction component is copying classes from the
>>> JDK/JSE  libraries into the transaction bundle. If that's the case,
>>> then I'd agree that's a problem.
>>>
>>> I don't know of any instances where this occurs in Geronimo. I think
>>> you're referring to a ClassLoading issue involving javax.transaction
>>> classes...
>>>
>>> Geronimo has a JTA spec implementation. The transaction component
>>> should use that instead --
>>> http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-jta_1.1_spec/1.1.1/geronimo-jta_1.1_spec-1.1.1.jar 
>>>
>>>
>>> --kevan
>


--
Joe
Reply | Threaded
Open this post in threaded view
|

Re: Licensing problem with the transaction component?

kevan
In reply to this post by Guillaume Nodet

On Oct 21, 2009, at 2:00 PM, Guillaume Nodet wrote:

> I don't follow.  We use the ones from the geronimo jta jar.  We would
> not be able to grab those from the JRE as it only contains a few
> classes (and not the TransactionManager interface for example), so
> that would obviously not work for the transaction component.

Cool. I haven't looked at code or parts of the build. Merely trying to  
interpret Rick's concern. It doesn't sound like there's a problem.  
Rick can enlighten us, if there is...

--kevan

Reply | Threaded
Open this post in threaded view
|

Re: Licensing problem with the transaction component?

Lin Sun
In reply to this post by Guillaume Nodet
I agree, that there isn't a prob. I believe that the geronimo
transaction jar is using the javax.transaction and
javax.transaction.xa from the geronimo jta spec jar, at least that was
the case when I looked at it earlier this year.  Also, if we had been
using the jars from Sun's JDK/JRE which doesn't contain the JTA 1.1
interfaces, we wouldn't even be able to compile the geronimo
transaction jar.

Lin

On Wed, Oct 21, 2009 at 2:09 PM, Guillaume Nodet <[hidden email]> wrote:

> FWIW, i include the following output of maven.  You'll clearly see
> that we use the geronimo jta spec jar.
>
> gnodet:(svn)aries[aries:824258]/trunk/transaction$ mvn dependency:tree -o
> [INFO]
> NOTE: Maven is executing in offline mode. Any artifacts not already in
> your local
> repository will be inaccessible.
>
> [INFO] Scanning for projects...
> [INFO] ------------------------------------------------------------------------
> [INFO] Building Apache Aries Transaction
> [INFO]    task-segment: [dependency:tree]
> [INFO] ------------------------------------------------------------------------
> [INFO] [dependency:tree {execution: default-cli}]
> [INFO] org.apache.aries.transaction:aries-transaction:bundle:1.0.0-incubating-SNAPSHOT
> [INFO] +- org.osgi:org.osgi.core:jar:4.1.0:provided
> [INFO] +- org.osgi:org.osgi.compendium:jar:4.1.0:provided
> [INFO] +- org.apache.geronimo.components:geronimo-transaction:jar:2.1.2:compile
> [INFO] |  +- org.slf4j:slf4j-api:jar:1.4.3:compile
> [INFO] |  +- org.apache.geronimo.specs:geronimo-jta_1.1_spec:jar:1.1.1:compile
> [INFO] |  \- org.apache.geronimo.specs:geronimo-j2ee-connector_1.5_spec:jar:2.0.0:compile
> [INFO] +- org.objectweb.howl:howl:jar:1.0.1-1:compile
> [INFO] \- org.springframework:spring-tx:jar:2.5.6:compile
> [INFO]    +- commons-logging:commons-logging:jar:1.1.1:compile
> [INFO]    +- org.springframework:spring-beans:jar:2.5.6:compile
> [INFO]    +- org.springframework:spring-context:jar:2.5.6:compile
> [INFO]    |  \- aopalliance:aopalliance:jar:1.0:compile
> [INFO]    \- org.springframework:spring-core:jar:2.5.6:compile
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD SUCCESSFUL
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 7 seconds
> [INFO] Finished at: Wed Oct 21 20:09:08 CEST 2009
> [INFO] Final Memory: 29M/80M
> [INFO] ------------------------------------------------------------------------
>
>
> On Wed, Oct 21, 2009 at 20:00, Guillaume Nodet <[hidden email]> wrote:
>> I don't follow.  We use the ones from the geronimo jta jar.  We would
>> not be able to grab those from the JRE as it only contains a few
>> classes (and not the TransactionManager interface for example), so
>> that would obviously not work for the transaction component.
>>
>> On Wed, Oct 21, 2009 at 18:23, Kevan Miller <[hidden email]> wrote:
>>>
>>> On Oct 21, 2009, at 11:57 AM, Guillaume Nodet wrote:
>>>
>>>> I wasn't aware that there was any problem with redistributing those
>>>> classes.   You're right, we embed those classes from the geronimo spec
>>>> jar, so I guess the problem is the same as in geronimo.
>>>>
>>>> On Wed, Oct 21, 2009 at 16:50, Rick McGuire <[hidden email]> wrote:
>>>>>
>>>>> I was looking at how the transaction component was building to figure out
>>>>> how the javax.transaction classes.  If I understand what the build is
>>>>> doing,
>>>>> then it appears that the bundle is getting built by directly embedding
>>>>> the
>>>>> javax.transaction and javax.transaction.xa from the jvm used to build the
>>>>> bundle.  I'm nervous that this would cause copyright issues since these
>>>>> classes are Sun copyrighted IP and I'm not sure that Apache is in the
>>>>> clear
>>>>> with redistributing those classes that way.  We've got a similar issue in
>>>>> Geronimo right now, and I was trying to figure out how this had been
>>>>> solved
>>>>> here when I discovered this.  Am I interpreting what's going on with the
>>>>> build correctly?
>>>
>>> Not sure I completely understand. So, let me replay...
>>>
>>> At buildtime, the transaction component is copying classes from the JDK/JSE
>>>  libraries into the transaction bundle. If that's the case, then I'd agree
>>> that's a problem.
>>>
>>> I don't know of any instances where this occurs in Geronimo. I think you're
>>> referring to a ClassLoading issue involving javax.transaction classes...
>>>
>>> Geronimo has a JTA spec implementation. The transaction component should use
>>> that instead --
>>> http://repo1.maven.org/maven2/org/apache/geronimo/specs/geronimo-jta_1.1_spec/1.1.1/geronimo-jta_1.1_spec-1.1.1.jar
>>>
>>> --kevan
>>>
>>
>>
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>> ------------------------
>> Open Source SOA
>> http://fusesource.com
>>
>
>
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
Reply | Threaded
Open this post in threaded view
|

Re: Licensing problem with the transaction component?

Rick McGuire
In reply to this post by Joe Bohn
Sorry about the false alarm.  I had the same problem Joe did....since I
didn't see a dependency on a spec jar in the build, I falsely concluded
it had to be picking up the JRE versions.  I was also sent down a wrong
path by the change in naming with the spec jar.  All of the projects I
had looked at were named "*-transaction", so when I checked to see if
Geronimo even had a spec version of these classes, I didn't think to
check for "*-jta" in the name.  It is good to be certain though that the
correct classes are getting picked up :-)

Rick

Joe Bohn wrote:

> It seems to me that classes included match those in the geronimo jta
> spec.  However, I'm not sure how these are getting included the
> aries/transaction bundle.  The pom in aries/transaction only includes
> a dependency on geronimo-transaction 2.1.2.  Perhaps the dependency on
> geronimo-transactions results in a transitive dependency on the
> geronimo jta spec that is including the javax.transaction classes.
>
> Joe
>
>
> Guillaume Nodet wrote:
>> I wasn't aware that there was any problem with redistributing those
>> classes.   You're right, we embed those classes from the geronimo spec
>> jar, so I guess the problem is the same as in geronimo.
>>
>> On Wed, Oct 21, 2009 at 16:50, Rick McGuire <[hidden email]> wrote:
>>> I was looking at how the transaction component was building to
>>> figure out
>>> how the javax.transaction classes.  If I understand what the build
>>> is doing,
>>> then it appears that the bundle is getting built by directly
>>> embedding the
>>> javax.transaction and javax.transaction.xa from the jvm used to
>>> build the
>>> bundle.  I'm nervous that this would cause copyright issues since these
>>> classes are Sun copyrighted IP and I'm not sure that Apache is in
>>> the clear
>>> with redistributing those classes that way.  We've got a similar
>>> issue in
>>> Geronimo right now, and I was trying to figure out how this had been
>>> solved
>>> here when I discovered this.  Am I interpreting what's going on with
>>> the
>>> build correctly?
>>>
>>> Rick
>>>
>>>
>>>
>