Slashdot Mirror
JBoss Queries Apache Geronimo Code Similarity
Kanagawa writes "This morning, Jim Jagielski, Exec. V.P. and Secretary of the Apache Software Foundation, announced on the geronimo-dev mailing list that 'the ASF received a letter from JBoss's lawyers regarding... the similarity of code between [J2EE implementation] Geronimo and JBoss.' The letter
is available in PDF. According to the letter, similarities were noticed back in July, and haven't been fixed."
...see this post to TheServerSide. A lot of these look like common design patterns and standard Java/J2EE naming conventions.
You can also see Jim Jagielski's response to some questions here about this issue. Sounds pretty reasonable.
The Army reading list
"Good programmer's copy, great programmer's steal!!"
meh.. I got nothing.
I'm not into this case, but at a first glance it seem to me that Geronimo really is just what JBoss is, right ? - So what's the point in remaking it? JBoss is already free? (LGPL!)
henc
The first exhibit seems to be originally derived from:
/ ex amples/customLevel/XLevel.java
http://cvs.apache.org/viewcvs.cgi/jakarta-log4j
which is apache licensed in the first place.
I'm no expert coder, but these don't look the same to me. There are similarities, but one would presume they are doing the similar things.
One of the functions is to convert an integer to a level. How many different ways could you do actually do this? Another function converts a string.
If you assign a class to write functions that would change variable types. All 30 people will come up with different code, but the code is likely to look very similar - especially if you're encouraging them to use proper function/variable naming and comments.
Kudos to JBoss for posting the code, but I don't see much here to be suing over.
Which one is SCO and which is IBM, I'm a little slow on this stuff.
-Tim Louden
Geronimo has requested that all developers confirm that either a) they didn't just submit JBoss code or b) they had the right as the original creators of the JBoss code section to also submit it to Geronimo.
No FUD. No hyperbole in extremis. No crazed threats. Oh, wait: No SCO. Of course. What a breath of fresh air.
Check out the source code on page 8. Since when is the copyright symbol allowable in Java syntax?
In the example on page 8 of the letter you can see they are BOTH attempting to copyright the freaking SWITCH construct!
--
This post (c) 2003, Knights who say Ni, LTD.
-- This post (c) 2003, Knights who say Ni, LTD.
A letter like that is really all everyone has been asking for from SCO. JBoss is doing this to protect their code. It makes you wonder why SCO hasn't done the same already. Unless of course their actions are not at all about protecting their source code and patents. Reminds of that bible story where King Solomon must decide a dispute over a newborn child. JBoss reacted in the interests of protecting their code, SCO has not. From this simple story, we see whose intentions are what they claim to be, and whose are not.
/.ers were on the money.
On a side note, SCO's recent behavior has made it clear as to who the puppetmaster of this debacle really is:
Here are two quotes from the Computer Business Review:
"SCO would probably provide customers with financial incentives and discounts to migrate to SCO Unix, other vendors' Unix, and what he referred to as 'other proprietary operating systems' but probably Windows."
"'We are offering a migration path to other operating systems that have a stronger IP basis than Linux,' the spokesperson said. Incentives will be offered 'in the coming months.'"
If that move doesn't reveal the puppetmaster, nothing will.
I sincerely doubted Microsoft's involvement for a while, this time though, the paranoid
It does sound like there were a few particular instances where a class' design and the set of methods in the class were directly patterned on the JBoss design - not necessarily copied line-by-line, but the solution to a fundamental part of the J2EE specification "problem" was ripped from JBoss and modified to suit the code needs of Geronimo. Whether this is violation of copyright or not is a tough question. Copyright doesn't protect a design pattern, a solution to a problem, the logical organization of a set of objects, or an algorithm. Proving that somebody actually violated copyright in this case seems rather hard to me - though perhaps a bit of credit to the JBoss folks for their thoughts and design work is in order.
C'mon! CamelCase names in Java follow a some simple rules, there's even a documented way of how you're supposed to do it. As for CELLPADDING, since that's how it's named in HTML, it wouldn't surprise me to see it done identically in another place. Better go sue Netscape too.
To see if the code is actually similar you'd have to look at algorithms and innovations. Looking at interfaces and their names isn't going to tell you anything at all.
The first example in the letter is
org.jboss.logging.XLevel vs. org.apache.geronimo.core.log.XLevel
Both seem to be copied from log4j's examples.customLevel.XLevel
However, there are much more substantial allegations made here
more about me
At what level though do you say that source was copied? Obviously the code isn't a 100% match, and for each problem a coder faces there is a shortest distance/most efficient solution, what's not to say that two developers wouldn't reach similar conclusions? Seeing as some of the exhibits were based around logging which is a very common task which I'd figure that a large portion of projects tackle the problem in the same fashion, I fail to see you could point out that someone had copied the solution if it was the best answer and other people could arrive at the same conclusion.
If it was a line for line copy then I can see it being different, but IMHO I think there are sufficient difference between the two portions of code. Personally I think if JBoss doesn't have better things to do with it's time and money it should slash the cost of its ridiculously expensive (and pathetic) documentation and spend some time improving it instead!
Good try, but no, really. First of all, CELLPADDING only appears in the jBoss part of the diff, not in Geronimo. Secondly, that's how you are supposed to specify the padding for cells in an HTML table. So, if Geronimo had decided to use an HTML table in their javadoc with cell padding, they would have had to use CELLPADDING. But all that is irrelevant since they didn't.
No mystery there. ThreadNDCConverter is capitalized *exactly* according to very established java code conventions. See for example http://java.sun.com/docs/codeconv/html/CodeConvent ions.doc8.html
The JBoss code and the Apache code both appear to be copied from an example that was originally created by Apache. Exibit A and B are both logging classes, both use Log4J (Apache's logging utility) and can be expected to be similar. Exibit C looks Almost identical, but not entirely. The similarities are so trivial, Apache is bound to make a few quick changes and be done with this thing before it starts. What sillyness.
TallGreen CMS hosting
Did anyone not see this coming? And if you didn't here's why you should have:
Mark Fleury's original response to Apache Geronimo
As our customers know, we are a business, a serious one and we seriously believe in and defend "professional open source". That includes legal protection of IP. Make no mistakes, JBoss will AGGRESIVELY defend its copyright and LGPL license.
And from the Elba website
Think of Elba as a latticework for Geronimo--and as a shield to buffer the Geronimo codebase and CVS repository from any LGPL code. As Geronimo is built, its code will replace the code from Elba, bit by bit until there's nothing left in Elba at all. At that time, Elba will cease to exist and only Geronimo will remain; we'll have a big party and you're all invited.
So if Geronimo is being developed as outlined at the Elba website then they'd have to have the exact same method signatures....
My Hello World is 512 bytes. But it's also a valid Fat12 boot sector, Fat12 file reader, and Pmode routine.
I respectfull disagree.
a) I don't think anyone would mix up CELLPADDING with PADCELL. What should PADCELL be or mean?
b) Its standard java coding style rules NOT TO USE a "_" in a constant.
Everybody using "cell padding" as a name for a constat wich is used like a enum would write CELLPADDING. Everybody.
The capitalization rules are also well defined. So if you consider to have a class "ThreadNDCConverter" a companay sticking to the original coding style rules will name that class or interface: ThreadNdcConverter. While my company OTOH will name it ThreadNDCConverter, as our rule is to capitalize all abreviations, like FTP, RMI and such.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Looking at the code as a programmer, some things stand out:
- The "copying" JBoss claims doesn't fit. There's differences in braces, keywords and other things that wouldn't be accounted for by automatic reformatting of code. I can't see a programm who's copying code directly going back in and doing that kind of editing. I'd expect braces to be maintained, for example, yet in several places they aren't.
- The similar names are obvious names for types, variables and functions. Given the same spec to start from, without having seen the JBoss code at all, I'd pick the same names.
- The places they cite as having code-structure similarity are very simple. Frankly, it looks to me like there's only one sane way to write that code.
It can't hurt to do a check, but I suspect JBoss is seeing copying where there's just only one obvious way to do something and most programmers, working independently, will make basically the same set of choices for that code.Simone Bordet, David Blevins, David Jencks, Dain Sundstrom, Greg Wilkins, Bruce Snyder, Jan Bartel, Jeremy Boynes , James Strachan, Jules Golsnell, Richard Monson-Haefel and Jason Dillon.
Almost ALL of the Geronimo developers with commit rights have also worked on the same JBoss code base. Thats too many developers in common to provide a fresh perspective nessary to create a non-derivative clone.
Posted By: Jim Jagielski on November 10, 2003 @ 03:49 PM in response to Message #101148.
Just a short note: It is, and has always been, the stated baseline of Geronimo that it not contain any (L)GPL code, whether JBoss derived (in legally specified copyright sense) or not. It's not for any political reasons (and I'm glad to see that this is not degrading into such a forum) but simply because of the letter and spirit of the Apache License. It should also be noted that Geronimo itself is an "project in incubation" within the ASF. It is not (yet) a formal, official ASF project (or subproject under one of the other top level ASF projects). If there is any (L)GPL code within Geronimo, or code that is derived from (L)GPL code (in the legal sense), it will be stripped and replaced. That's just the way it is and it's the way the ASF has always operated.
Also, it should be noted that some exhibits referred to are no longer applicable. For example, Geronimo's Invocation class was entirely rewritten from what was noted in the letter. In other cases, the similarities are due to the fact that they are simple (and trivial) extensions. With XLevel, org.apache.log4j.Level is itself extended, which imposes and provides some of the common structure and names. It has also been noted that for PatternParser, 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."
Running with Linux for over 20 years!