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