geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <>
Subject Re: More allegations from JBoss on TheServerSide
Date Mon, 10 Nov 2003 22:03:17 GMT
Not only that but the ASF has stated (again and again) that
the inclusion and use of (L)GPL code is not acceptable.
If it exists, we strip it out.

If there are *true* instances of such code within the
code base, then we will deal with them. But code that
is "similar" simply because of common derivation from
NON GPL code, or because of similar functionality
is really muddying the waters.

On Nov 10, 2003, at 4:54 PM, Noel J. Bergman wrote:

> Vic Cekvenich wrote:
>>>>> The Geronimo developers represent that the code
>>>>> contributed for Geronimo does not contain any code
>>>>> belonging to JBoss.
>>>> I just wanted to underline above.
>>> Are you claiming that the Geromino developers are falsely
>>> representing their rights and the origin of the code?  Is
>>> it your claim that they are violating their CLA?
>> This was posted on the Server Side TODAY, I had nothing to do with it:
>> Shame on the developers that steal code!
> I trust that you apply that sentiment both ways, Vic.
> Did you read the letter in question?  Did you read the replies to the
> letter?  Did you know that two of the three exhibits provided by JBoss 
> to
> their lawyer for reporting to the ASF are actually modified examples 
> from
> Log4J?  To quote from the page you referenced:
>   "Both classes appear to be heavily inspired by code examples
>    contained in the log4J distribution (package examples.customLevel,
>    class XLevel), so I would not count this as a very convincing
>    exhibit. Same with PatternParser."
> All IP claims will need to be reviewed, and if there are any real 
> issues,
> they will have to be corrected.  Some claims posted by Bill Burke seem 
> a bit
> of a stretch, e.g., that a Service interface with start() and stop() 
> methods
> is proprietary, implying an exclusive right to use boilerplate 
> patterns from
> the JDK, suggesting that an object pool is tainted because it 
> implements a
> pool, or that an mutator method is tainted because the first thing it 
> does
> it check its arguments and throw an exception if they are bad.  But
> specifics to which to respond are better than unsubstantiated 
> allegations.
> The obligation is to create new code, not to forget best practices 
> that have
> been learned, or to be different solely for the sake of being 
> different.
> 	--- Noel

View raw message