www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@gmail.com>
Subject Re: mx4j jar including javax.management... classes; activemq jar containing javax.management and javax.jms... classes - license question
Date Thu, 03 Dec 2009 15:40:00 GMT
On Wed, Dec 2, 2009 at 11:46 PM, Paul Libbrecht <paul@activemath.org> wrote:
> I'm sorry Craig,
>
> I still do not understand.
> Do you mean the Geronimo team or the MX4j team would have (re-)written the
> classes (mostly java interfaces) in the package javax.* and shipped them
> along?

Yes.

> Isn't this really confusing according to the expectation (at least
> mine) that package naming defines origin?
>

Well, the JCP rules for implementing specifications *require* that an
implementation provides these API classes.  There are even tests in
the TCK to verify that you are not changing the public API (such as
adding additional public/protected methods or fields) from what the
specification defines.

>
> This is striking compared to W3C specs which do include properly licensed
> method names.

*Names* or *implementations"?  They are two different things.

>
> paul

Craig

>
>
> Le 03-déc.-09 à 03:04, Craig McClanahan a écrit :
>
>> On Wed, Dec 2, 2009 at 1:09 PM, Paul Libbrecht <paul@activemath.org>
>> wrote:
>>>
>>> Le 02-déc.-09 à 20:19, Mark Thomas a écrit :
>>>>
>>>> In summary:
>>>> - use of mx4j is not an issue for any ASF project
>>>> - that gfact that a project implements a JSR does not require any
>>>> entries in a project's LICENSE or NOTICE file
>>>
>>> I feel this summary is only true as long as the distribution does not
>>> include any specification classes which is, I thought, the issue we're
>>> discussing and not at all the redistribution of the reference
>>> implementation.
>>>
>>
>> You are missing a key point ... the specification classes jar in
>> question was *not* part of the spec or the reference implementation
>> (although the description of the API they implement *is* defined by
>> the spec).  The jar was provided by the MX4J team.
>>
>>>
>>> I've seen many tomcats distribute servlet.jar. That's ok if it is
>>> properly
>>> explained that servlet.jar is from another source and is distributed with
>>> another license. I've seen this broken many times.
>>>
>>
>> Tomcat's servlet.jar is not from another source (although technically,
>> because Tomcat was contributed to Apache before there was a JCP, these
>> classes were originally contributed to Apache rather than created
>> here).  As a more modern example, all the API jar files in Geronimo
>> were created at Apache, by Apache committers, and licensed under the
>> Apache License.
>>
>>>
>>> Claiming the mx4j.jar was covered by APL is, I believe we all agree, the
>>> wrong and disputed thing. Or?
>>>
>>
>> "Or" indeed.  That is not how it works.
>>
>>> And the Apache projects that use it, as I
>>> understand, should not distribute a jar that is wrongly licensed and
>>> should
>>> split.
>>>
>>
>> They should indeed not distribute jars from other parties with
>> incompatible licenses.  However, the MX4J implementation includes API
>> classes provided by the MX4J team, just as Geronimo provides all the
>> javax.* APIs that are part of Java EE.  The sources for these files
>> were authored by the respective teams, not copied from the
>> specification or the reference implementation.
>>
>>>
>>> paul
>>>
>>>
>>>
>>>
>>
>> Craig McClanahan
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org


Mime
View raw message