geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: A Letter from JBoss's lawyers
Date Mon, 10 Nov 2003 21:18:18 GMT
I cannot take credit for the below... As mentioned,
it is based on the input and findings of someone

In any case, it is not my intent, nor should it
be any Geronimo developers intent, to "debate"
issues. Instead, the goal is to accurately
reflect reality and to do so in an open

On Nov 10, 2003, at 4:05 PM, Dion Almaer wrote:

> Jim -
> I really like your reasoning below.  Some Jboss guys have posted on
> Maybe you would like to place your thoughts there too, as I think they 
> speak volumes.
> Cheers,
> Dion
>> -----Original Message-----
>> From: Jim Jagielski []
>> Sent: Monday, November 10, 2003 2:55 PM
>> To:
>> Subject: Re: A Letter from JBoss's lawyers
>> This is a preliminary evaluation of the issue. It is based on
>> the input from a disinterested 3rd party. This does not
>> constitute a formal response of any kind, but is rather part
>> of the required development discussion regarding this.
>> This is posted WITHOUT PREJUDICE.
>> In general, considering that some of the Geronimo developers
>> also contributed code to JBoss, it would be neither
>> surprising nor improper if there were found to be some
>> identical pieces. The requirement should be that authors
>> submit only such code for which they have clear title.
>> Although "former project members cannot avoid the rights of
>> the copyright owner of the collective work that they intend
>> to copy or change", that does not preclude an author from
>> also providing his or her own code to the ASF for licensing
>> under the ASL. As far as is known, there is no code within
>> Geronimo that was exclusively licensed to JBoss, or is
>> included in Geronimo without the author's permission.
>> With respect to the specific exhibits:
>>    Exhibit A: Similarities between two subclasses of
>>               org.apache.lo4j.Level, each of which
>>               implements a TRACE level.
>> The classes in question are
>> org.apache.geronimo.code.log.XLevel and
>> org.jboss.logging.XLevel.  Both of them extend org.apache.log4j.Level,
>> which imposes (and provides) some of the common structure and
>> names.
>> The
>> classes, themselves, are trivial implementations of a new
>> logging level, the structure of which is dictated by Apache
>> Log4J.  The code seems to be as similar, and as different, as
>> one would expect from two authors implementing a Log4J TRACE
>> log level based upon existing Log4J code.
>>    Exhibit B: Similarities between two PatternParser subclasses
>>               in support of the nested diagnostic context pattern.
>> The similarities come from the fact that both code bases
>> implement "nested diagnostic contexts" as described by Neil
>> Harrison in "Patterns for Logging Diagnostic Messages", which
>> can be found in the book "Pattern Languages of Program Design
>> 3", published in 1997 by Addison-Wesley
>> (ISBN:
>> 0201310112). Apache Log4J implements this class in
>> org.apache.log4j.NDC.
>> This class describes how it is to be used, including the use
>> of a "distinctive stamp."
>> The two classes in question,
>> org.apache.geronimo.code.log.PatternParser
>> and org.jboss.logging.layout.PatternParserEx, are both
>> trivial extentions of org.apache.log4j.helpers.PatternParser
>> in support of this documented pattern.  Again, Apache Log4J
>> provides and imposes structure.  I would expect this
>> similarity to morph shortly because both Geronimo and JBoss
>> are using Log4J v1.2.8.  Log4J v1.3, still in development,
>> completely refactors how pattern handling is done within Log4J.
>> ref:
>>    Exhibit C: InvocationType
>> The pattern
>>    public static final TYPE NAME = new TYPE(...);
>> is boilerplate.  It is a well-established Java implementation
>> pattern found in the JDK and many other code bases.  The
>> aforementioned Log4J code base has an almost identical set of
>> lines, differing only in TYPE, NAME and parameters to the
>> TYPE constructor.
>> The class name, InvocationType, is entirely descriptive of
>> what the class represents.  The term "Invocation" is also
>> found in the term RMI -- Remote Method Invocation -- and the
>> class simply represents the type of invocation. The values of
>> the first parameter: "REMOTE", "HOME", "LOCAL"
>> and "LOCALHOME" are defined by a J2EE Specification, not by
>> JBoss.  The second parameter is an ordinal from 0 to 3, and
>> provides its location within a static array.  If "I" were
>> writing the code, "I" might have not had that parameter, but
>> most programmers probably would.  The remaining parameters
>> are unique to Geronimo, not found in JBoss, and define the
>> properties of the invocation.
>> ref:
>> src/java/
>> org/a
>> pache/geronimo/core/service/
>>    "Further, although not reproduced as an exhibit, we direct
>>     your attention to the similarities in the files named
>>     org.apache.geronimo.common.Invocation (Geronimo) and
>>     org.jboss.invocation.Invocation (JBoss).  Both of these files
>>     contain what JBoss believes is highly JBoss-specific payloads,
>>     which are named "AsIs", "Transient," and "Marshalled."
>> Upon investigation, it is seen that Geronimo's Invocation
>> class was entirely rewritten more than two months prior to
>> the communication from Testa, Hurwitz and Thibeault.  The
>> well-established RPC/RMI concepts of transient and marshalled
>> data are implemented completely differently in current Geronimo code.

View raw message