geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr. <>
Subject Re: A Letter from JBoss's lawyers
Date Mon, 10 Nov 2003 21:35:00 GMT

On Monday, November 10, 2003, at 04: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.

And by my score, the community is turning this into a farce -- this 
seems to be backfiring for Dr Fleury and his lawyers...

Still - lets get a response together.  Maybe simply inviting the 
discussion here would help.  I hate TSS forums...


> 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.
Geir Magnusson Jr                                   203-247-1713(m)

View raw message