Licensing problem with the transaction component?

Licensing problem with the transaction component?

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?

> 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
>
>
>

Re: Licensing problem with the transaction component?

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...

Re: Licensing problem with the transaction component?

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 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
>

> 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>

Re: Licensing problem with the transaction component?

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

Re: Licensing problem with the transaction component?

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
>>
>>
>>

Re: Licensing problem with the transaction component?

> 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

Re: Licensing problem with the transaction component?

>
> 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
>

Re: Licensing problem with the transaction component?

> 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...

Re: Licensing problem with the transaction component?

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.

Re: Licensing problem with the transaction component?

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
>>>
>>>
>>>
>