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
http://www.theserverside.com/home/thread.jsp?thread_id=22337.
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...
geir
Cheers,
Dion
-----Original Message----- From: Jim Jagielski [mailto:[EMAIL PROTECTED] Sent: Monday, November 10, 2003 2:55 PM To: [EMAIL PROTECTED] 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: http://jakarta.apache.org/log4j/docs/api/org/apache/log4j/NDC.html
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: http://cvs.apache.org/viewcvs/incubator-geronimo/modules/core/ src/java/ org/a pache/geronimo/core/service/InvocationType.java?annotate=HEAD
"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) [EMAIL PROTECTED]
