geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dion Almaer" <d...@theserverside.com>
Subject RE: A Letter from JBoss's lawyers
Date Mon, 10 Nov 2003 21:05:35 GMT
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:jim@jagunet.com] 
> Sent: Monday, November 10, 2003 2:55 PM
> To: geronimo-dev@incubator.apache.org
> 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.
> 


Mime
View raw message