Discussions

News: Alleged Code Copying in Apache Geronimo spurs JBoss response

  1. JBoss' lawyers have sent a letter to Apache regarding similarities between code in JBoss Server, and the upcoming Geronimo server. The ASF received a letter which cites a few examples of Geronimo code which "appear to be virtually identical or substantially similar to JBoss program source code".

    The Geronimo team has said in the past that this isn't the case. They call on all of their developers again:

    "This a CALL for ALL Geronimo developers to ensure that any code is not copied from JBoss. Recall, also, that if someone is the original author of the code and donated that code to JBoss, they can *still* donate the original code to the ASF (unless they signed some sort of exclusivity agreement). Original authors maintain ownership."

    It is important to note their point that if someone is the original author they can donate their code. Thus, the code that is shown in the letter has to come from a developer who hasn't authorized it.

    View the letter from JBoss to the Apache Software Foundation

    (includes the claims, and the example source code allegedly showing the copied code)

    It will be interesting to see Apache's response to these claims

    Threaded Messages (136)

  2. After reading the letter, I looked up the restrictions placed on derivative works placed on the LGPL:

        a) The modified work must itself be a software library.

        b) You must cause the files modified to carry prominent notices
        stating that you changed the files and the date of any change.

        c) You must cause the whole of the work to be licensed at no
        charge to all third parties under the terms of this License.

    So it does dictate the type of license - it can only be LGPL (it can also be GPL, apparently). Personally, I think Geronimo would be better off using the GPL/LGPL, since projects usually fare better (cf. Linux v. BSD) because they cannot be locked and developers cannot be exploited. And I think in practice it may be very close to a fork of jboss, so they might as well. There is nothing illegal in forking a free project.
  3. After looking at the exhibits[ Go to top ]

    I wonder if the fact that the 1st exhibit is a Log4J Wrappers has anything to do with the fact that it is similiar.

    -- Rob
  4. After looking at the exhibits[ Go to top ]

    I wonder if the fact that the 1st exhibit is a Log4J Wrappers has anything to do with the fact that it is similiar.


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

    BTW: log4J is licensed under the Apache license ;-)
  5. The JBoss code in question was not code originally written by anybody of the current Geronimo committers. It was code copyrighted to Scott Stark and myself.

    marcf
  6. Marc,

     Looking at following three files:
    1) examples.customLevel.XLevel from log4j
    2) org.jboss.logging.XLevel from JBoss
    3) org.apache.geronimo.core.log.XLevel

    It appears that both 2 and 3 are derivatives of 1. Can you explain why JBoss group copied log4j example and modified the licesing agreement?

    (Disc: I am associated with ASF)
  7. Disc: I am associated with ASF)

    I mean to say I am **NOT** associated with ASF :-)
  8. derived from agent smith[ Go to top ]

    Jboss code is not here because it is free;
    Jboss code is here because it is not free

    BSD is free, no strings attached.
  9. A flaw in the Apache License[ Go to top ]

    The Apache License grants the right to copy the code and release it under a different (more restrictive) license. The LGPL does not.

    This could be considered a flaw in the Apache Software License, also most BSD derived licenses, *if* the intent of the copyright holder was to restrict others from freely using the code.

    Essentially, BSD-style licenses allow someone to fork the code and GPL or LGPL the derivative work. While this doesn't restrict the original BSD code from being closed sourced, it does prevent the GPL licensed forked code from being similarly closed sourced.
  10. ASF! Welcome into the mfleury's MUD.
    to mfleury: do you feel threatened somehow ? You scared that the real profesionals at the core developers network (and others, by the way. I hear that Suse will bundle JOnAS with the Linux platform they distribute) will take away all the OS J2EE market share ? I think you do.

    And I think, as a previous poster, that you should have solved the similarities problem w/o trying to spread FUD about ASF. Everybody agrees that there are similarities and that they must be removed. And they will be removed. And every problem solved. The JBOSS developers will keep all their rights and IP on the code they contributed, as it should be. You don't need lawyers. ASF gave alot to the open source. There is no need for you to do that.

    Now somebody will start to look into Jboss code for code stealed from ASF. Nut because it uses to something (as your letter is not of any use) but because some people are like that. And here we are: 2 big OS players fighting in the mud in front of all the world. And OS credibility goes away. And you loose. We all loose.

    Do you JBOSS developers need this ?

    I must mention that JBOSS is fine, is a good product. Also I think that it's developers are great. I just don't agree how mfleury through Jboss LLC is guiding the image of the JBOSS server and through it the image of 'professional open source'. OS can, through this, become the fight arena for BIG BUCKS players instead of a source of innovation. mfleury you allways should think twice.
  11. Dorel wrote:
    [i]And I think, as a previous poster, that you should have solved the similarities problem w/o trying to spread FUD about ASF.[/i]

    Is it just me, or was it not ASF that made this whole thing public?! But still it is somehow Mr. Fleury who is spreading "FUD". This was a letter privately sent to Chairman, President and VP of Apache. [b]They[/b] decided to make the notification that there might be a license violation a public issue.

    Stop and think for a second before you spout out...?
  12. Ok you've got me on that one. mfleury is a saint. He doesn't spread FUD at all. I wonder if what I said now or before will ever change the people's perception of him/his position. My opinion is that while he did a great job by leading all actvity behind JBOSS app server (would that be true now ?) he's now turning against the mere ones that he started with.
  13. Dorel wrote:

    > Is it just me, or was it not ASF that made this whole thing public?! But still it is somehow Mr. Fleury who is spreading "FUD". This was a letter privately sent to Chairman, President and VP of Apache. [b]They[/b] decided to make the notification that there might be a license violation a public issue.

    Geronimo is an open open source project. The mailing lists are open, the CVS is open, the wiki, etc... Notice was sent to the PMC and the Geronimo development list. After all, this is where the discussion should take place. That's how the ASF "made this whole thing public", by involving the project and developers associated with it.

    How is that bad?
  14. Right spelling: _ALLEGED_ Code Copying etc...
  15. no lawsuit[ Go to top ]

    Dorel wrote:

    > > Is it just me, or was it not ASF that made this whole thing public?! But still it is somehow Mr. Fleury who is spreading "FUD". This was a letter privately sent to Chairman, President and VP of Apache. [b]They[/b] decided to make the notification that there might be a license violation a public issue.
    >
    > Geronimo is an open open source project. The mailing lists are open, the CVS is open, the wiki, etc... Notice was sent to the PMC and the Geronimo development list. After all, this is where the discussion should take place. That's how the ASF "made this whole thing public", by involving the project and developers associated with it.
    >
    > How is that bad?

    As Dorel wrote, this letter was sent privately. We are not suing anybody, just officially calling attention to various concerns we have about following copyright and LGPL.

    Whether the ASL/BSD license is a better license than LGPL. Whether or not BSD is "more free" than LGPL, is not the issue. The issue is that we hope that our choice of the LGPL license is being respected.

    Based on CVS comments of merged functionality, the Elba fork and unclear relationship of this project to Geronimo, comments of Geronimo developers on public mailing lists saying they are merging JBoss code with OpenEJB, and the similarities in codebases, structure, file names, and patterns that I pointed out with only 1 hour of research, I think we are in our right to ask the ASF to look into the concerns we are worried about. We were hoping that this could be resolved privately, but like it or not, it is now public and we hope that you all can respect our worries.

    Again no lawsuit.

    Best regards,

    Bill
  16. no lawsuit[ Go to top ]

    Based on [...] the similarities in codebases, structure, file names, and patterns that I pointed out with only 1 hour of research [...]


    Well, the 3 "exhibits" that ended up in the letter are not very convincing (e.g. common ancestor code, see message #101182). It makes me wonder why no stronger evidence has been chosen to represent the case here.
  17. no lawsuit[ Go to top ]

    Bill Burke wrote:
    > Whether the ASL/BSD license is a better license than LGPL. Whether or not BSD is "more free" than LGPL, is not the issue. The issue is that we hope that our choice of the LGPL license is being respected.

    If you have read *any* of our responses, you will see that this is indeed the case. Please don't imply otherwise.

    >
    > We were hoping that this could be resolved privately, but like it or not, it is now public and we hope that you all can respect our worries.

    Again, you should note that we did *not* "make it public." We simply informed the geronimo-dev development team of the issue. Also, if you read any of our responses you should see that one of our goals is to *avoid* this becoming a "public" issue, or a debate of licenses or any of that crud. When development is done in the open, when mailing lists are open, when the CVS is open, then it makes sense that a review of the code with respect to issues will likely be open as well. But that was a simple by-product of our desire to address the concerns due to the nature of it being an open development environment. Nothing more.
  18. no lawsuit[ Go to top ]


    > > We were hoping that this could be resolved privately, but like it or not, it is now public and we hope that you all can respect our worries.
    >
    > Again, you should note that we did *not* "make it public." We simply informed the geronimo-dev development team of the issue. Also, if you read any of our responses you should see that one of our goals is to *avoid* this becoming a "public" issue, or a debate of licenses or any of that crud. When development is done in the open, when mailing lists are open, when the CVS is open, then it makes sense that a review of the code with respect to issues will likely be open as well. But that was a simple by-product of our desire to address the concerns due to the nature of it being an open development environment. Nothing more.

    I wasn't accusing you of making it public. Just expressing that it is unfortunate that this has been brought to the public eye.

    Bill
  19. no lawsuit[ Go to top ]

    Again, you should note that we did *not* "make it public." We simply informed the >geronimo-dev development team of the issue.


    How exactly is putting a letter on a *public* mailing list not making it public? I am not following your logic here.
  20. Thomas Mattson wrote:
    > How exactly is putting a letter on a *public* mailing list not making it public? I am not following your logic here.

    The geronimo-dev mailing list, as are the other various ASF -dev lists, are *the* development instruments. It is via these mailing lists that development takes place. It is *the* communication vehicle among and to developers. This was a geronimo development issue regarding geronimo code by geronimo developers.
  21. lawsuit[ Go to top ]

    Is it not true that the real gist of your errm "letter" was to distract the Geronimo project from writing a competing J2EE solution ? So people would spend a week looking through codebases instead of doing anything productive ?


    Admit it :-)
  22. JBoss Position[ Go to top ]

    Just to add a little background to this.

    The JBoss developers have had concerns about some of the code in Apache and their perspective that it was derived from JBoss. The concern comes from the fact that they have written their code under LGPL for a specific reason – they did not want it becoming closed source. The LGPL protects a developer from having his/her code taken out of open source and made proprietary. The real problem with Geronimo taking this code is that the Apache license allows anyone to take this code and make it proprietary.

    We had involved our lawyers to get a read on the issue of derivative works. The decision was to make a formal request to Apache to assure that there are not derivative works from JBoss in Geronimo.

    We appreciate the fact that Apache has made an initial step to make sure derivative works do not happen in the Geronimo project. Just to be clear, LGPL involves both copying and deriving from someone else's source code.

    Bob Bickel
    JBoss Group
    bob@jboss.org
  23. Stupid move, JBoss[ Go to top ]

    We had involved our lawyers to get a read on the issue of derivative works.

    > The decision was to make a formal request to Apache to assure that there are > not derivative works from JBoss in Geronimo.

    Have you guys learned nothing from history, e.g. arc vs. zip compression, or more recently, the SCO mess? The bad publicity you have unleashed by this stupid move will dog JBoss forever, and I think that's a shame. Did JBoss make a good faith effort to resolve this without lawyers and get stonewalled by the ASF in response? That doesn't appear to be the case, although I haven't read every word that's been posted on this issue.

    Sending letters from your lawyers over code that is arguably not derivative, and at worst, might be derivative but is trivial and easily fixed, makes you guys look like hamfisted bullies. To me, it also suggests that you see Geronimo as a serious threat to your marketshare and you'd rather meet that threat with lawyers than with a superior product.
  24. XLevel class[ Go to top ]

    http://cvs.sourceforge.net/viewcvs.py/jboss/jboss-common/src/main/org/jboss/logging/XLevel.java

    http://cvs.sourceforge.net/viewcvs.py/jboss/common-jboss/src/main/org/jboss/logging/XLevel.java

    http://cvs.apache.org/viewcvs.cgi/incubator-geronimo/modules/core/src/java/org/apache/geronimo/core/log/Attic/XLevel.java?hideattic=0

    http://cvs.apache.org/viewcvs.cgi/incubator-geronimo/modules/common/src/java/org/apache/geronimo/common/log/log4j/XLevel.java
  25. XLevel class[ Go to top ]

    Log4j's XLevel class

    http://cvs.apache.org/viewcvs.cgi/jakarta-log4j/examples/customLevel/XLevel.java
  26. log4j is now part of the Apache logging project. Here is the new link to the file:

    http://cvs.apache.org/viewcvs.cgi/logging-log4j/examples/src/customLevel/XLevel.java
  27. Violations?[ Go to top ]

    As an open source developer I choose to submit my code under LGPL because it ensures me that this code will remain open source, yet the license is flexible enough to allow for embedding. When I first became aware of Geronimo, I took a look through the codebase just for kicks and was deeply concerned that some of my code was derived from or distributed under the ASL license.
     
    As an example, below is a comment from the JBoss CVS from Dain Sundstrom. Dain contributed EntityInvocationRegistry to the JBoss project back in March of 2003. He clearly states in his commit message to the JBoss CVS that this file is a derivative of certain files that I wrote "This functionality was merged from ....". This file was moved to and renamed to the Geronimo project. As I believe in the integrity of the LGPL, I was greatly disturbed by this.

    Date : 2003/3/23 4:28:42
    Author : 'dsundstrom'
    State : 'Exp'
    Lines : +0 0
    Description :
    Tracks the entities and contexts associated with a transaction.This
    functionality was merged from GlobalTxMap, TxEntityMap, and
    EntitySynchronizationInterceptor.


    http://cvs.apache.org/viewcvs.cgi/incubator-geronimo/modules/core/src/java/org/apache/geronimo/ejb/SynchronizationRegistry.java?rev=1.1&content-type=text/vnd.viewcvs-markup

    http://cvs.sourceforge.net/viewcvs.py/*checkout*/jboss/jboss/src/main/org/jboss/ejb/entity/Attic/EntityInvocationRegistry.java?content-type=text%2Fplain&rev=1.1
    ======================

    Add to this is comments on the Geronimo mail list stating that they are taking JBoss code concerned me even more. Here's a comment from David Blevins:

    http://nagoya.apache.org/eyebrowse/ReadMsg?listName=geronimo-dev at incubator dot apache dot org&msgId=998128

    And Elba == JBoss 3.2.

    "We're taking the Elba/OpenEJB JAAS code, merging it together ...."

    So I spent an hour or two looking through the Geronimo codebase back in August of this year....Here are some of my findings.

    =============================================================================

    Same base file names:
    org.apache.geronimo.cache.InstanceCache --> org.jboss.ejb.InstanceCache
    org.apache.geronimo.cache.InstancePool --> org.jboss.ejb.InstancePool
    org.apache.geronimo.common.Interceptor --> org.jboss.ejb.Interceptor
    org.apache.geronimo.common.Invocation --> org.jboss.invocation.Invocation
    org.apache.geronimo.common.InvocationType --> org.jboss.invocation.InvocationType
    org.apache.geronimo.core.log.XLevel --> org.jboss.logging.XLevel
    org.apache.geronimo.core.log.PatternLayout --> org.jboss.logging.layout.PatternLayout
    org.apache.geronimo.deployment.DeploymentInfo --> org.jboss.system.deployment.DeploymentInfo
    org.apache.geronimo.deployment.scanner.DeploymentScanner --> org.jboss.system.deployment.scanner.DeploymentScanner
    org.apache.geronimo.ejb.EJBProxyFactory --> org.jboss.ejb.EJBProxyFactory
    org.apache.geronimo.ejb.EnterpriseContext --> org.jboss.ejb.EnterpriseContext
    org.apache.geronimo.ejb.cache.EntitySynchronizationInterceptor --> org.jboss.ejb.plugins.EntitySynchronizationInterceptor
    org.apache.geronimo.ejb.cache.EntityCreationInterceptor --> org.jboss.ejb.plugins.EntityCreationInterceptor
    org.apache.geronimo.ejb.metadata.Methodmetadata --> org.jboss.metadata.MethodMetaData
    org.apache.geronimo.web.AbstractWebContainer --> org.jboss.web.AbstractWebContainer

    ========================================================================
    org.apache.geronimo.core.log.PatternLayout --> org.jboss.logging.layout.PatternLayout

    PatternLayout was originally written by Scott Stark.

    1. These files are almost exactly the same, except one allocates PatterParserEx the other PatterParser. But these file are almost exactly the same too!!!! (see next)


    ========================================================================
    org.apache.geronimo.core.log.XLevel org.jboss.logging.XLevel

    XLevel was originally written by Scott Stark.

    1. These files are almost exactly the same

    ========================================================================
    org.apache.geronimo.core.log.PatternParser --> org.jboss.logging.layout.PatternParserEx

    PatternParserEx was originally written by Scott Stark

    These files are very very similar. Both allocate an NDC object (which are similar too! We'll show later.) driven by a switch. The code is exactly the same in most areas.

    ========================================================================
    org.apache.geronimo.core.log.NamedNDCConverter --> org.jboss.logging.layout.ThreadNDCConverter

    ThreadNDCConverter was originally written by Scott Stark

    1. Both of these classes' purpose is to "uses the current thread NDC rather than the
     * LoggingEvent NDC value."
    2. The code is very similar and it is clear that the code is an attempt at refactoring



    ========================================================================
    org.apache.geronimo.common.StateManageable org.jboss.system.Service

    Service was written by Marc Fleury

    1. Both have a start method
    2. Both have a stop method

    ========================================================================
    org.apache.geronimo.common.Component org.jboss.ejb.ContainerPlugin

    ContainerPlugin written by Rickard Oberg

    0. Both implement a similar class StateManageable vs. Service
    1. Both classes are implemented by similar classes (Interceptor, etc...) and used in similar ways
    2. Both have a setContainer method.


    ========================================================================
    org.apache.geronimo.common.Interceptor org.jboss.ejb.Interceptor

    Interceptor was written by Rickard Oberg and Marc Fleury

    1. Both have a getNext method. Even comments are similar
    Geronimo:
        /**
         * Gets the next interceptor in the chain of command.
         *
         * @return the next interceptor in the chain or null if it is the last interceptor
         */
        Interceptor getNext();
    JBoss:

    2. Both have a setNext method. Even comments are similar (1st sentence).

    JBoss:
       /**
        * Set the next interceptor in the chain.
        *
        * @param interceptor The next interceptor in the chain.
        */
       void setNext(Interceptor interceptor);

    Geronimo:
        /**
         * Sets the next interceptor in the chain. This command can not be called
         * after the interceptor has transitioned into the created state.
         *
         * @param interceptor the next interceptor in the chain
         * @throws IllegalStateException if this interceptor is not in the not-create state
         */
        void setNext(Interceptor interceptor) throws IllegalStateException;

    3. The invoke methods both return a response Object although the names are different


    =============================================
    org.apache.geronimo.common.Invocation --> org.jboss.invocation.Invocation

    Invocation was written by Marc Fleury with contributions by Scott Stark, Bill Burke, and others.

    1. Even though Geronimo's Invocation is an interface, notice that they both have an AS IS, Transient, and MARSHALLED payload. This shows definate derivation


    =============================================
    org.apache.geronimo.ejb.SimpleEnterpriseContext --> org.jboss.ejb.EnterpriseContext

    Written by Rickard Oberg with contributions from: Marc Fleury, Sebastien Alborini, Juha Lindfors, Ole Husgaard

    These classes are used for the exact same thing. They also have exact method names:

    getId
    setId
    getInstance
    setContainer
    getContainer
    discard
    clear

    Same as methods in child class org.jboss.ejb.EntityEnterpriseContext
    setValid
    isValid


    =============================================
    org.apache.geronimo.ejb.metadata.MethodmetadataImpl --> org.jboss.metadata.MethodMetaData

    MethodMetaData was written by Sebastien Alborini with contributions from Marc Fleury, Scott Stark, Bill Burke, etc....

    These classes perform the same exact function. To provide EJB metadata about a method.

    Same methods that are same in code as well:

    - isExcluded
    GERONIMO:
        public boolean isExcluded() {
            return excluded;
        }
    JBOSS:
       public boolean isExcluded()
       { return excluded; }

    - setExcluded
    GERONIMO:
        public void setExcluded(boolean excluded) {
            this.excluded = excluded;
        }
    JBOSS:
       public void setExcluded()
       { excluded = true; }
    - isUnchecked
    GERONIMO:
        public boolean isUnchecked() {
            return unchecked;
        }
    JBOSS:
       public boolean isUnchecked()
       { return unchecked; }

    - setUnchecked
    GERONIMO:
        public void setUnchecked(boolean unchecked) {
            this.unchecked = unchecked;
        }

    Same fields:
    JBOSS:
       private boolean unchecked = false;
       private boolean excluded = false;
    GERONIMO:
        private boolean excluded;
        private boolean unchecked;



    =============================================
    java.geronimo.cache.EntitySynchronizationInterceptor == server/src/main/org/jboss/ejb/plugins.EntitySynchronizationInterceptor

    - same class name
    - both delegate to a Registry. SynchronizationRegistry and EntityInvocationRegistry are very very similar. This is Dain's rewrite although I added some code at a later date.

    =============================================

    java.geronimo.ejb.SynchronizationRegistry == EntityInvocationRegistry
    Date : 2003/3/23 4:28:42
    Author : 'dsundstrom'
    State : 'Exp'
    Lines : +0 0
    Description :
    Tracks the entities and contexts associated with a transaction.This
    functionality was merged from GlobalTxMap, TxEntityMap, and
    EntitySynchronizationInterceptor.

    They are exactly the same. So we now look into copyright infringement in the old files GlobalTxMap, TxEntitymap(written by Bill Burke), and EntitySynchronizationInterceptor, (written by Bill Burke, Marc Fleury, and Scott Stark).

    SynchronizationRegistry.EJBSynchronization is similar to GlobalTxEntityMap.GlobalTxEntityMapCleanup.
    GlobalTxEntityMap ownership:

    Bill Burke
    Scott Stark
    David Jencks
    Dain Sundstrom

    - Both inherit from Synchronization
    - the method beforeCompletion is pratically the same
    GERONIMO:
            public void beforeCompletion() {
                if (log.isTraceEnabled()) {
                    log.trace("beforeCompletion called");
                }

                // let the runtime exceptions fall out, so the committer can determine
                // the root cause of a rollback
                synchronizeEntities();
            }
    JBOSS:
          public void beforeCompletion()
          {
             if (log.isTraceEnabled())
             {
                log.trace("beforeCompletion called for tx " + tx);
             }

             // let the runtime exceptions fall out, so the committer can determine
             // the root cause of a rollback
             synchronizeEntities(tx);
          }

    As you can see, even the comments are the same. The only difference is that synchronizeEntities takes a transaction parameter.
    The problem with this is that Dain did this particular fix



    SynchronizationRegistry.disassociateEntity is similar to JBoss 3.2, EntitySynchronizationInterceptor.InstanceSynchronization.afterCompletion
    This code was written by:

    EntitySynchronizationInterceptor authors:
    Bill Burke
    Scott Stark
    Marc Fleury
    other contributions:
    Dain, David

    - The reseting of classloaders is the same
    - The switch statement in JBoss follows the same if statement pattern on the commit option.
    - ctx.setValid is the same method name.


    =============================================

    java.geronimo.container.PersistenceManager == JBoss 3.2 server/src/main/org/jboss/ejb/EntityPersistenceManager

    EntityPersistenceManager was written by Rickard Oberg.

    The exact same method names exact signatures, except for Classnames (EntityEnterpriseContext == EnterpriseContext):
    - createBeanClassInstance
    - isModified

    Almost renamed method names with exact signatures:
    - remove == removeEntity
    - passivate == passivateEntity
    - store == storeEntity
    - load == loadEntity
    - activate == activateEntity
    - postCreateEntity == postCreate
    - create = createEntity

    ==============================================
    DAIN IS THE AUTHOR OF THIS FILE EVEN THOUGH Scott is listed as an author
    java.geronimo.common.InvocationType == Head server/src/main/org/jboss/invocation/InvocationType

    - both of same name and same functionality
    - both implement Serializable
    - same constants with same name and almost exact signature of initialization

    JBOSS:
       public static final InvocationType REMOTE =
             new InvocationType("REMOTE", 0);
       public static final InvocationType LOCAL =
             new InvocationType("LOCAL", 1);
       public static final InvocationType HOME =
             new InvocationType("HOME", 2);
       public static final InvocationType LOCALHOME =
             new InvocationType("LOCALHOME", 3);

    GERONIMO:
        public static final InvocationType REMOTE = new InvocationType("REMOTE", 0, false, false);
        public static final InvocationType HOME = new InvocationType("HOME", 1, false, true);
        public static final InvocationType LOCAL = new InvocationType("LOCAL", 2, true, false);
        public static final InvocationType LOCALHOME = new InvocationType("LOCALHOME", 3, false, false);

    - same variables:
    JBOSS:
       private final transient String name;
       private final int ordinal;

    GERONIMO:
        private final transient String name;
        private final int ordinal;

    - same methods:
    JBOSS:
        public String toString()
        {
            return name;
        }

    GERONIMO:
        public String toString() {
            return name;
        }


    ======================================

    java.geronimo.cache.EnterpriseContextInstanceCache == server/src/main/org/jboss/ejb/plugins.AbstractInstanceCache
    AbstractInstanceCache was written by:
    Simone Bordet

    So this may not be an infringement because Simone put in most of the logic around this piece.

    Contributing authors:
    Bill Burke
    Marc Fleury
    Juha Lindfors
    Biorn Steedom

    - both implement InstanceCache
    - Both have a member variable that points to the real cache. Both delegate to a cache.

    geronimo: Line 14
    LRUInstanceCache cache

    JBoss: line 65
    private CachePolicy m_cache;

    Variable names similar too

    - Both have a passivator thread that passivates beans in background. JBoss removed this thread in recent CVS version.

    - get methods very similar in algorithm. Notice that both handle interaction with a PersistenceManager to activate the bean. Both delegate to a cache to see if bean already exists.

    - Both have a get, remove, and isActive method.

    - putActive is similar to insert in that they both throw an IllegalArgumentException at the beginning of the function.

    ======================================

    java.geronimo.cache.EnterpriseContextInstancePool == server/src/main/org/jboss/ejb/plugins.AbstractInstancePool

    - both implement InstancePool

    ======================================

    org.apache.geronimo.core.log.Log4jLog org.jboss.logger.Logger

    Logger was written by Scott Stark

    1. Both classes wrap Apache's log4j implementation.
  28. Violations?[ Go to top ]

    Note: I pulled out a few selected items as I did'nt want to repeate the entire thing. Overall my comment is "Come on boys is this the best you can come up with!!!!" Most of these are superficial at best and probably would come from common J2EE terminology or common Java programming techniques. After I read this I hoped that it was someone spoofing as Bill because this is just too dumb for someone that claims such deep level of knowledge. If this this the best you can come up with then you are just so much "sound and fury".

    These file names (a subset of the original list) seem like names that might be used by any J2EE server. For example InstanceCache, Wow! How did anyone think of that?!?!? In any case, the names of files by itself are not especially damning nor does it imply any copying. It could have just seemed like a good name based on previous experience.
    > org.apache.geronimo.cache.InstanceCache --> org.jboss.ejb.InstanceCache
    > org.apache.geronimo.cache.InstancePool --> org.jboss.ejb.InstancePool
    > org.apache.geronimo.common.Invocation --> org.jboss.invocation.Invocation
    > org.apache.geronimo.common.InvocationType --> org.jboss.invocation.InvocationType
    > org.apache.geronimo.deployment.DeploymentInfo --> org.jboss.system.deployment.DeploymentInfo
    > org.apache.geronimo.ejb.EJBProxyFactory --> org.jboss.ejb.EJBProxyFactory
    > org.apache.geronimo.web.AbstractWebContainer --> org.jboss.web.AbstractWebContainer

    I think this one has been addressed since both files obviously derviced from log4j examples. Shame on you for FUD in this case!
    > org.apache.geronimo.core.log.XLevel org.jboss.logging.XLevel

    Wow ... a "Service" that has both a Start and a Stop method. I would have never thought of that!! How do you come up with these fastastic ideas.
    > org.apache.geronimo.common.StateManageable org.jboss.system.Service
    > 1. Both have a start method
    > 2. Both have a stop method

    Again, Wow!!!! Who would have thought of a method names getNext or even setNext. Also, it's just "too scary" that they are both commented with the same inane comments like "gets the next ..." and "sets the next ...". What are the odd that two developer would put this deeply thought out comment in code!
    > org.apache.geronimo.common.Interceptor org.jboss.ejb.Interceptor
    > 1. Both have a getNext method. Even comments are similar
    > Geronimo:
    >     /**
    >      * Gets the next interceptor in the chain of command.
    >      *
    >      * @return the next interceptor in the chain or null if it is the last interceptor
    >      */
    >     Interceptor getNext();
    > JBoss:
    >
    > JBoss:
    >    /**
    >     * Set the next interceptor in the chain.
    >     *
    >     * @param interceptor The next interceptor in the chain.
    >     */
    >    void setNext(Interceptor interceptor);
    >
    > Geronimo:
    >     /**
    >      * Sets the next interceptor in the chain. This command can not be called
    >      * after the interceptor has transitioned into the created state.
    >      *
    >      * @param interceptor the next interceptor in the chain
    >      * @throws IllegalStateException if this interceptor is not in the not-create state
    >      */
    >     void setNext(Interceptor interceptor) throws IllegalStateException;

    This is where I really thought you were being spoofed. This is so dumb it is beyond belief. Boolean set/get methods that look similar! Wow, who'd a thunk it. Come on guys, how else would one write a set/get method? Tell me you haven't hung your future on kind of drivel.
    > org.apache.geronimo.ejb.metadata.MethodmetadataImpl --> org.jboss.metadata.MethodMetaData
    > Same methods that are same in code as well:
    >
    > - isExcluded
    > GERONIMO:
    >     public boolean isExcluded() {
    >         return excluded;
    >     }
    > JBOSS:
    >    public boolean isExcluded()
    >    { return excluded; }
    >
    > - setExcluded
    > GERONIMO:
    >     public void setExcluded(boolean excluded) {
    >         this.excluded = excluded;
    >     }
    > JBOSS:
    >    public void setExcluded()
    >    { excluded = true; }
    > - isUnchecked
    > GERONIMO:
    >     public boolean isUnchecked() {
    >         return unchecked;
    >     }
    > JBOSS:
    >    public boolean isUnchecked()
    >    { return unchecked; }
    >
    > - setUnchecked
    > GERONIMO:
    >     public void setUnchecked(boolean unchecked) {
    >         this.unchecked = unchecked;
    >     }
    >
    > Same fields:
    > JBOSS:
    >    private boolean unchecked = false;
    >    private boolean excluded = false;
    > GERONIMO:
    >     private boolean excluded;
    >     private boolean unchecked;

    How many of these names are obvious given the J2EE lifecycle. I mean passivate ... wouldn't that be an obvious name?
    > =============================================
    > java.geronimo.container.PersistenceManager == JBoss 3.2 server/src/main/org/jboss/ejb/EntityPersistenceManager
    >
    > EntityPersistenceManager was written by Rickard Oberg.
    >
    > The exact same method names exact signatures, except for Classnames (EntityEnterpriseContext == EnterpriseContext):
    > - createBeanClassInstance
    > - isModified
    >
    > Almost renamed method names with exact signatures:
    > - remove == removeEntity
    > - passivate == passivateEntity
    > - store == storeEntity
    > - load == loadEntity
    > - activate == activateEntity
    > - postCreateEntity == postCreate
    > - create = createEntity

    Other than the class InvocationType (which isn't that suspicious either) ... wouldn't logical names for a J2EE server be Remote and Local and .... and how else would static inialization look? Come on ... come with something substancial.
    > ==============================================
    > DAIN IS THE AUTHOR OF THIS FILE EVEN THOUGH Scott is listed as an author
    > java.geronimo.common.InvocationType == Head server/src/main/org/jboss/invocation/InvocationType
    >
    > - both of same name and same functionality
    > - both implement Serializable
    > - same constants with same name and almost exact signature of initialization
    >
    > JBOSS:
    >    public static final InvocationType REMOTE =
    >          new InvocationType("REMOTE", 0);
    >    public static final InvocationType LOCAL =
    >          new InvocationType("LOCAL", 1);
    >    public static final InvocationType HOME =
    >          new InvocationType("HOME", 2);
    >    public static final InvocationType LOCALHOME =
    >          new InvocationType("LOCALHOME", 3);
    >
    > GERONIMO:
    >     public static final InvocationType REMOTE = new InvocationType("REMOTE", 0, false, false);
    >     public static final InvocationType HOME = new InvocationType("HOME", 1, false, true);
    >     public static final InvocationType LOCAL = new InvocationType("LOCAL", 2, true, false);
    >     public static final InvocationType LOCALHOME = new InvocationType("LOCALHOME", 3, false, false);
    >
    > - same variables:
    > JBOSS:
    >    private final transient String name;
    >    private final int ordinal;
    >
    > GERONIMO:
    >     private final transient String name;
    >     private final int ordinal;

    Wow ... a similar use of "cache" in a veriable name that point to a cache ... who's eve do that?
    > java.geronimo.cache.EnterpriseContextInstanceCache == server/src/main/org/jboss/ejb/plugins.AbstractInstanceCache
    > - Both have a member variable that points to the real cache. Both delegate to a cache.
    > geronimo: Line 14
    > LRUInstanceCache cache
    > JBoss: line 65
    > private CachePolicy m_cache;
  29. Violations?[ Go to top ]

    Note: I pulled out a few selected items as I did'nt want to repeate the

    > entire thing. Overall my comment is "Come on boys is this the best you can
    > come up with!!!!" Most of these are superficial at best and probably would
    > come from common J2EE terminology or common Java programming techniques.
    > After I read this I hoped that it was someone spoofing as Bill because this
    > is just too dumb for someone that claims such deep level of knowledge. If
    > this this the best you can come up with then you are just so much "sound and
    > fury".

    While I agree that any of these examples on their own would be unconvincing, and some of them are probably due to common J2EE terminology, taken together they do seem a bit too similar to be just a co-incidence. Taken together, it does indeed look like Geronimo has copied code from the JBoss project, in violation of the JBoss license. The similarities are sufficient that no textual critic would hesitate to claim derivation, or at least common descent.

    But let's have some moderation in this discussion, Kent. JBoss Group has not sued ASF, or even threatened to. They have sent a letter, through their lawyers, explaining their concerns and asking ASF to do something about it. There is no threat, no ultimatum, no deadline to reply. This seems to be just JBoss group giving a fellow open-source group a reminder that licensing issues are important to the open source movement and care should be taken to maintain the integrity of those licenses.

    Licensing *is* important to open source. If open source groups don't take care over their licenses between each other, why should they expect to be able to enforce them against closed-source organisations? If ASF can copy JBoss code, why not BEA or IBM or Oracle? And if ASF flaunts JBoss' license, why should they expect to be able to enforce their own license? This game can't be played both ways.
  30. Violations?[ Go to top ]


    > And if ASF flaunts JBoss' license, why should they expect to be able to enforce their own license? This game can't be played both ways.

    Who says that the ASF is attempting any such thing? In fact, it's quite the opposite. It's been stated time and time again that honoring (L)GPL by not including any such derived code in Geronimo is a baseline condition of Geronimo as well as its graduation from an ASF incubator "podling" to a formal ASF project.
  31. Violations?[ Go to top ]

    While I agree that any of these examples on their own would be unconvincing, and some of them are probably due to common J2EE terminology, taken together they do seem a bit too similar to be just a co-incidence. Taken together, it does indeed look like Geronimo has copied code from the JBoss project, in violation of the JBoss license. The similarities are sufficient that no textual critic would hesitate to claim derivation, or at least common descent.


    Derivation is one thing; common descent is another. The former is bad, the latter most likely is not. For example, if both are derived from public domain or BSD-licensed code, the there is no conflict. Or if the original author donated the same code to both JBoss and Geronimo, there would be common descent (and common code) but no conflict.

    So "just" looking for similarities does not fully address the issue nor imply conflict nor does it imply that B copied from C.
  32. Violations?[ Go to top ]

    But let's have some moderation in this discussion, Kent. JBoss Group has not >sued ASF, or even threatened to.


    JBoss Group and Marc Fleury has announced that they will defend their IP "AGGRESSIVELY". That is not how a reminder to a fellow OS project.

    --
    Jon Martin Solaas
    jonmartin.solaas@mail.link.no
  33. Violations?[ Go to top ]

    While I agree that any of these examples on their own would be unconvincing, and some of them are probably due to common J2EE terminology, taken together they do seem a bit too similar to be just a co-incidence.

    *** But *all* that was given was useless triviality like names and javabean model setter getters, etc. If the JBoss group wants to provide real code snippets with real logic that could be compared I might actually bleave there was something.

    >Taken together, it does indeed look like Geronimo has copied code from the JBoss project, in violation of the JBoss license. The similarities are sufficient that no textual critic would hesitate to claim derivation, or at least common descent.
    *** This is a big streach given the data that was shown. If there is more then maybee but ....

    > But let's have some moderation in this discussion, Kent. JBoss Group has not sued ASF, or even threatened to.
    *** And I never siad they did or implied anything. All I said was let' se some real meat!


    > Licensing *is* important to open source. If open source groups don't take care over their licenses between each other, why should they expect to be able to enforce them against closed-source organisations? If ASF can copy JBoss code, why not BEA or IBM or Oracle? And if ASF flaunts JBoss' license, why should they expect to be able to enforce their own license? This game can't be played both ways.
    *** Show a violation and I'd agree with you 100%. Keep using tirvial examples to justify it and you just weaken any case.
  34. Violations?[ Go to top ]

    Licensing *is* important to open source. If open source groups don't take

    > > care over their licenses between each other, why should they expect to be
    > > able to enforce them against closed-source organisations? If ASF can copy
    > > JBoss code, why not BEA or IBM or Oracle? And if ASF flaunts JBoss'
    > > license, why should they expect to be able to enforce their own license?
    > > This game can't be played both ways.
    > *** Show a violation and I'd agree with you 100%. Keep using tirvial
    > examples to justify it and you just weaken any case.

    Any similarity can always be reduced to trivial examples by only considering small enough stretches of text. Your so-called 'real meat' would, in the end, be a collection of trivial examples strung together... which is roughly what Bill has posted further up this thread. Most of those examples are trivial, although one or two I think show definite signs of distinct, non-trivial commonality. When put together, they add up to a distinct impression of copied code. Does it matter whether complex logic is involved? I don't think it does. It would certainly be the first step on a very slippery path to say that it's okay to copy trivial code, but not complex code.
  35. Violations?[ Go to top ]

    org.apache.geronimo.common.StateManageable org.jboss.system.Service

    >
    >Service was written by Marc Fleury
    >
    >1. Both have a start method
    >2. Both have a stop method

    <sarcasm>OMG -- I bet Sun ripped off JBoss when designing java.lang.Thread too.</sarcasm>

    Also, the examples like:
    void setChecked( boolean checked ) { this.checked = checked; }

    Come on, that's probably how most JavaBean style methods are written.

    -- Rob
  36. Violations?[ Go to top ]

    org.apache.geronimo.common.StateManageable org.jboss.system.Service

    > >
    > >Service was written by Marc Fleury
    > >
    > >1. Both have a start method
    > >2. Both have a stop method
    >
    > <sarcasm>OMG -- I bet Sun ripped off JBoss when designing java.lang.Thread too.</sarcasm>
    >

    I agree that start and stop methods are common. Bill released some of the reviews of similarity he dug, it was the raw document, it doesn't make judgements on legality. It is not a legal document, the letter from our lawyers is the legal document.

    Obviously in the list from bill you can argue that some of the code could have been invented (or re-invented) without prior knowledge of JBoss. The excercise the lawyers went through is "what is derivative, imagine there was NO JBOSS, would you still arrive at the same result?". I concluded as you do that "start/stop" is not JBoss specific. The body of the invocation is JBoss specific.

    That it comes with an "invocation" is generic (it is common to all request/response constructs), the name is not even the point. The point is that both Invocations store data in 3 maps called "TRANSIENT, AS-IS, and MARSHALLED" which represent the payload. I WROTE THESE IN JBOSS, THEY ARE NON_GENERIC. THERE IS NO LOGICAL WAY SOMEONE TO COME UP WITH THE 3 SAME MAPS, AND WITH THE 3 SAME NAMES. It is one example of derivation (albeit a core one) among many.

    Go and make your own opinion about the derivative nature of the JBoss work, it is easy to do as developers and that is what we want you to do.

    marcf
  37. Violations?[ Go to top ]

    If there are any concerns about specific pieces of code, you are invited to submit them to the Geronimo developer mailing list, so that they can be investigated. It is the stated intention to ensure that there is no (L)GPL, regardless of origin, in the code base.

    Please be sure to refer to the current code in CVS, since that is what we would be wanting to correct as necessary.
  38. Violations?[ Go to top ]

    If there are any concerns about specific pieces of code, you are invited to submit them to the Geronimo developer mailing list, so that they can be investigated. It is the stated intention to ensure that there is no (L)GPL, regardless of origin, in the code base.

    I imagine that the point of this exercise is to recognize that it is not JBoss Group's responsibility going forward to monitor every CVS code commit, and file requests each time they spot an IP violation.

    Rather, the Geronimo team needs to clean up their act, and recognize it is their responsibility to keep derivative works out of the codebase. That should end all of the unpleasant legal stuff.
  39. Violations?[ Go to top ]

    it is not JBoss Group's responsibility going forward to monitor

    > every CVS code commit, and file requests each time they spot an
    > IP violation.

    > the Geronimo team needs to clean up their act, and recognize it is
    > their responsibility to keep derivative works out of the codebase.

    Please keep in mind that so far the cases chosen to represent a problem appear to consist of two pieces of modified ASF code, a boilerplate JavaBean enum whose values in common are taken from the J2EE Specification, and code that was removed from CVS over two months ago.

    Regardless, the Germonimo team has had reiterated what they have always been told: that (L)GPL code is not permitted, and they are expected to contribute only clean code.
  40. Violations?[ Go to top ]

    it is not JBoss Group's responsibility going forward to monitor

    > > every CVS code commit, and file requests each time they spot an
    > > IP violation.
    >
    > > the Geronimo team needs to clean up their act, and recognize it is
    > > their responsibility to keep derivative works out of the codebase.
    >
    > Please keep in mind that so far the cases chosen to represent a problem appear to consist of two pieces of modified ASF code, a boilerplate JavaBean enum whose values in common are taken from the J2EE Specification, and code that was removed from CVS over two months ago.
    >

    I'll admit I am a bit biased towards JBoss as I am a user of it and have received a lot of help on the JBoss website, but what about the EntityInvocationRegistry file that Bill talks about and its equivalent file in Geronimo CVS, SynchronizationRegistry? Seems like derivation to me, but what do I know.

    Seems to me that taken one by one, the violations aren't so bad, but when you look at them all together it is very suspicious to me. Also what happened to the FAQ that used to be on Geronimo at apache.org? The Elba (JBoss fork) site states
    "Why Elba?

    Because we have learned from the lessons of OpenOffice and Mozilla that a project must have running code from day one.

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

    Hmmmmm, how can you bootstrap Elba with Geronimo code unless you get Geronimo to follow the same microkernel architecture as JBoss?




    Hans
  41. Elba?[ Go to top ]

    what happened to the FAQ that used to be on Geronimo at apache.org?

    > The Elba (JBoss fork) site states "Why Elba?"

    Elba is not an ASF project. Elba is a fork of JBoss v3. Whatever intention(s) the Elba developers may have had or even have, Elba is not something that the ASF has any interest or involvement in.

    Consider ... if (L)GPL (Elba) code were permitted into Geronimo, why would Geronimo and Elba be separate? :-) The reason is because the predicate is false. (L)GPL code is not permitted in Geronimo. Any such code would be accidental and necessary to replace.
  42. Re: Violations[ Go to top ]

    Marc,

    Things look similar, but a lot looks like classic java-standard code terminology, probably created with IDEA. Some are derivatives of Log4J examples, and then there is an enum using the standard java-enum-pattern that we will all be glad to be rid of come java 1.4. But given that geronimo contains people who have seen your code, and worked on it, could they have just retained the 'ideas' without cutting and pasting a line of code. And if you want to be sure about names, you have to be thorough and give them unique and obscure names like, say, 'happyaxis'. That way when it crops up in say, jboss-net.war, I can look at it and check that it complies with the license (which it does).

    Rather than escalate a situation, I want to observe that JBoss does benefit strongly from Apache -there are many apache libraries in use there, and Apache were also nicely ruthless with Sun and the JCP regarding licensing. They may not have made sun offer J2EE testing for free, but they did get them to split out testing from Reference Impl licensing, which will make JBoss getting J2ee certified possible. If the apache group hadn't threatened to break off all JCP involvement, Sun would not have been forced to do that.

    Similarly, I think if you want to keep those component developers on board, you are going to have to come up with a strategy of getting them to use jboss more than tomcat or geronimo-such as giving apache committers free access to all the docs, and providing help to the Apache projects where appropriate, where help is support/code/defects etc. Apache Axis, for example, denies all knowledge of JBoss.NET's use of axis because we do not have a clue what you did with our code. Not a bit. No do we know what bugs (if any) were found using Axis on Jboss as nobody with a jboss.org email addr ever files bugs against Axis. Maybe it all works perfectly, but since IBM and Borland happily complain to us and submit patches, that surprises me.

    Please, collaborate more with Apache in places where it makes tactical sense, rather than letting everything degrade to letters between laywers.

    -Steve
  43. Re: Violations[ Go to top ]

    Things look similar, but a lot looks like classic java-standard code

    > terminology, probably created with IDEA. Some are derivatives of Log4J
    > examples, and then there is an enum using the standard java-enum-pattern that
    > we will all be glad to be rid of come java 1.4. But given that geronimo
    > contains people who have seen your code, and worked on it, could they have just
    > retained the 'ideas' without cutting and pasting a line of code. And if you
    > want to be sure about names, you have to be thorough and give them unique and
    > obscure names like, say, 'happyaxis'. That way when it crops up in say,
    > jboss-net.war, I can look at it and check that it complies with the license
    > (which it does).

    I think that is on of the biggest points of it. All those who haved worked actively on JBoss development have surely gained a lot of knowledge, which is not simply vanishing when commit rights were revoked. So if the thre map solution is the result of a learning process it would be silly not to take advantage of it. But how will one judge such portions of code?

    And regarding the Bill Burke examples: while I may congratulate the JBoss people having code being clear and close to concepts, how will you prevent others from doing so, too? Naming classes and methods after conceptual entities of your domain is not really a secret art of mastery.

    Best regards,
    Robert
  44. Violations?[ Go to top ]

    It is one example of derivation (albeit a core one) among many.


    If it is a core one, why wasn't it the one used in the lawyer letter????
    Everyone (including you, by not opposing here) seems to agree the exhibit are not convincing at all. Why didn't you guys include some real stuff??

    This is intriguing.

    Not sure I understand the approach here, especially when JBoss did benefit from ASF a lot. This looks weird at best.
  45. Looking at Invocation.java[ Go to top ]

    (Replying to myself.)
    The "letter" does mention Invocation.java (" [...] We direct your attention to the similarities in the files named org.jboss.invocation.Invocation.java and org.apache.geronimo.Invocation. [...]"). Still I think the exhibits were a pretty poor choice.

    Links to CVS for Invocation.java:

    JBOSS:

    http://cvs.apache.org/viewcvs.cgi/incubator-geronimo/modules/core/src/java/org/apache/geronimo/common/Attic/Invocation.java

    GERONIMO:

    http://cvs.sourceforge.net/viewcvs.py/jboss/jboss/src/main/org/jboss/invocation/Invocation.java?rev=1.19&view=markup

    The latest version (1.4) from geronimo is not in that package anymore and doesn't contain "the 3 maps design". It may have moved elsewhere.

    The version 1.1 and 1.2 do contain an interface with methods hinting to "the 3 maps design" Marc is talking about.

    I don't know enough about copyright and J2ee internals design to know if this is a copyright violation or not.

    I think the 2 groups should cooperate to solve this in good faith.
  46. Looking at Invocation.java[ Go to top ]

    Matheir said:
    >The version 1.1 and 1.2 do contain an interface with methods hinting to "the 3 maps design" Marc is talking about.

    That is fine proof for me that some old developers of jBoss, and now new developers at took the code and are now refactoring it.
    Shame.

    This was faciliated by Greg Stein of ASF, who was for some reason eager to start Geronimo, and did not follow incubator procedures.

    Removing code is not sufficent. Developers should be baned from ASF, and Geronimo should be parked. They can do it on sf.net, everyone is happy.

    Later ASF could try another J2EE w/o the developers and the code.

    .V
  47. incubation[ Go to top ]

    This was faciliated by Greg Stein of ASF


    Facilitated: To make easy or less difficult

    > who was for some reason eager to start Geronimo

    Lots of people have been eager to do a J2EE project. Changes to the JCP process made it possible. The developer mailing list for Geronimo has more participants than even Tomcat.

    > and did not follow incubator procedures.

    The project IS in the Incubator. Note the following:

      mailing list: geronimo-dev at INCUBATOR dot apache dot org
      CVS: INCUBATOR-geronimo

    One purpose for the Incubator is to help teach new people how to do an ASF project properly. If people make mistakes, the mistakes get corrected, and people learn.
  48. Violations?[ Go to top ]

    [Marc Fleury]The excercise the lawyers went through is "what is derivative, imagine there was NO JBOSS, would you still arrive at the same result?".

    If thats the criteria, for every entry of 'weblogic' in JBoss-dev mailing list, JBoss Group has explaining to do. In JBoss-dev list, you would find frequent entries from jboss group about how jboss behaviour is similar to weblogic. If weblogic doesn't exist many of the JBoss features wouldn't be the way they are today. Does this mean BEA lawyers should be knocking your door right now?
  49. Derivation in Open Source[ Go to top ]

    Identifying derivative code in open source is even more complex than described above, given that you must consider mailing list discussion as well as code.

    Imagine this scenario:

    - Oscar identifies a feature in Project A that needs to be implemented
    - Susan describes a great way of doing it to John, a committer
    - John checks in code following Susan's design
    - Susan joins Project B
    - Susan and Joe from the new project discuss the same feature
    - Joe commits some code that's very similar to what's now in Project A
    - John cries foul and says that Joe's code is derivative

    In truth, both sets of code were derived from Susan's ideas. Furthermore, you can extend "Susan" to be the Internet at large and see that it's next to impossible to prove that two developers didn't each get an idea from some third source, which they then implemented in code.

    As much as I hate patents, they exist to help people get around this, so that the first developer can show his stuff to the world and be assured of a monopoly on that implementation, even if someone else figures it out in the same way he did, using the same resources he used. If similarities were enough to invoke copyright, patents would be meaningless (since copyrights are cheaper and have a much longer term).

    It's fine to go after outright copying, but trying to argue ownership of implementation designs in the open source world destroys the whole collaborative spirit. Most GPL developers also develop non-free software for pay. Are they to leave all GPL'd *ideas* at the door during their day-to-day development? This is good how?
  50. Live and Let Live[ Go to top ]

    Well, I can see that the code appears very similar- although the remark that no one else could logically come up with the same mappings and naming schemas seems to imply that there was not anything logical to it in the first place! Many great scientific achievements occur concurrently, and naming conventions that one may view as unique may in reality not be that unique....it would be very hard to determine given the many ambiguities involved in creativity and imagination- and hard for anyone to state unequivicably that no one could possibly come up with the same ideas.
    And even if it was "plagerized"- who cares? As a developer, and I imagine most developers, when stuck on an issue will do a quick Google search for a great code snippit to overcome a hurdle- look at the Sun forums, expert exchange, Code Guru, etc... And please do not tell me you never "lifted" an idea off of some other site- all good programmers do :) That's how we get things done.
    Now, rather than take this copying (if we admit that point) as a form of flattery (as I tell my oldest son- that the younger siblings are just flattering him when they try to "copy" him- rather than him getting mad and hitting them for it!) and instead getting mad and filing lawsuits - this has no positive effect overall I believe but leads down a spiral of negative energy- as most parents know. Instead I bet much more positive developments would come about by taking it as either a common conclusion of great minds or perhaps as a form of flattery. I am sure JBoss will continue to survive and continue along without many problems from Geronimo-
    Live and let live- it will make the world a happier place-
    Just some random thoughts.
    Jim
  51. Live and Let Live[ Go to top ]

    Jim Otte wrote:
    > And even if it was "plagerized"- who cares?

    The answer is We Do. We respect each others' licenses. Although we may have disagreements about them and reasons that we think one is "better" than the other, the simple fact is that we extend the respect for Licenses that we expect in return.

    I can assure you (and anyone else) that if "any" GPL code is within Geronimo, then it was not done on purpose or with malice or with total disregard. Elba was designed to prevent such a thing.

    The reason why the word any about is in quotes is because just because code exists in GPL code does not, ALL BY ITSELF, mean in cannot exist in non-GPL code. For example, code that was in the public domain, or code that was under Apache or BSD originally, or code that the developer donated to both projects.
  52. Live and Let Live[ Go to top ]

    Jim Jagielski wrote:

    > I can assure you (and anyone else) that if "any" GPL code is within Geronimo, then it was not done on purpose or with malice or with total disregard. Elba was designed to prevent such a thing.
    >

    Just to clear up any perceptions here. ELba is a fork of JBoss 3.2.2RC2 code of which at least 95-99% of the code is NOT solely authored by Geronimo developers when they were contributors to the JBoss project. What I'm saying is that even the parts of JBoss 3.2 that were contributions by Geronimo developers were either derived from existing JBoss code that they did not write, or is code that they wrote that has been extended, bug fixed, and/or refactored by OTHER non-Geronimo developers through the open source process and licensed as LGPL. So, to say that "Elba was designed to prevent [LGPL polution]." is not as accurate as you've been lead to believe.

    Bill
  53. Live and Let Live[ Go to top ]

    [...] ELba is a fork of JBoss 3.2.2RC2 code of which at least 95-99% of the code is NOT solely authored by Geronimo developers when they were contributors to the JBoss project. [...] So, to say that "Elba was designed to prevent [LGPL polution]." is not as accurate as you've been lead to believe.


    Bill, you still seem to not fully understand what Elba's purpose is. Go, educate yourself and read the faq (http://elba.sourceforge.net/).
  54. Live and Let Live[ Go to top ]

    ELba is a fork of JBoss 3.2.2RC2


    Does anyone dispute that? Elba is not part of Geronimo.

    > to say that "Elba was designed to prevent [LGPL polution]."
    > is not as accurate as you've been lead to believe.

    Nor is that as statement being made by the ASF. I, personally, agree that the Elba web site does seem confuse matters.

    I liked your message title. I hope that you don't mind that I kept it. :-)
  55. Live and Let Live[ Go to top ]

    Here's something that may help you to be a better parent:

    Your younger children started it. They aren't "copying" him because the want to be like him. The downward spiral of negative energy started with the younger siblings mocking the older one out of pure malice. Just like Geronimo.

    Your older son is older, so it is up to him to be more mature and break the cycle. Lying to him won't help anything. It may be too late for Marc Fluery, but you can make a difference.
  56. Violations?[ Go to top ]

    "As an open source developer I choose to submit my code under LGPL because it ensures me that this code will remain open source, yet the license is flexible enough to allow for embedding. "

    I'm curious. I have no agenda. I'm not trying to be a wise guy. Why, as a developer, do you care if your code remains "open"? Something in my feeble mind has yet to click on the mindset. I can understand making code freely available for money or for free with no strings attached. And I can understand you not wanting your code to be licensed by others as is. But what do you care if they extend it and they keep the extensions proprietary?

    Again, I'm just curious. And I believe that you have the right to do whatever the heck you want with your code.
  57. My take on it...[ Go to top ]

    These developers have every right to enforce their chosen license.

    It is a touchy situation, a lot of personal feelings flying around, but cut through that and you will see nothing more than developers ensuring their wishes are met. Remember, they OWN this code. Period. Telling them what they should or should not do license wise is ludicrous. I wonder how many of you saying this is a waste of time would be up in arms if Jboss stole Apache-licensed code and claimed it was LGPL only?

    I perfectly understand what they are doing and I completely agree. I would do the same in their situation and I suspect many of those crying foul would do so as well...
  58. My take on it...[ Go to top ]

    I don't disagree one bit with what you say. I'm just trying to understand the mindset of opensource developers who don't want anyone extending their work for profit.

    I don't contribute code because I won't give away my work for nothing. If I did give away code I would give it with no strings attached.
  59. Violations?[ Go to top ]

    I'm not convinced by any of the examples given. Rather than something substantial, they all look like the application of similar patterns. Who would have thought that a class would contain a method called getId? Or start and stop? If that's stealing code, then I've been stealing JBoss' code since 1997. But I think that the prize goes to:

    > 2. Both have a setNext method. Even comments are similar (1st sentence).
    >
    > JBoss:
    > /**
    > * Set the next interceptor in the chain.
    > *
    > * @param interceptor The next interceptor in the chain.
    > */
    > void setNext(Interceptor interceptor);
    >
    > Geronimo:
    > /**
    > * Sets the next interceptor in the chain. This command can not be called
    > * after the interceptor has transitioned into the created state.
    > *
    > * @param interceptor the next interceptor in the chain
    > * @throws IllegalStateException if this interceptor is not in the not-create state
    > */
    > void setNext(Interceptor interceptor) throws IllegalStateException;

    Quite apart from the question of how many ways are there to say "Sets the next interceptor in the chain." note that one has a full stop at the end of the parameter description and one doesn't. That's a very assiduous Java developer who goes to all the trouble of removing a full-stop.
  60. I even didn't know that JBoss had lawyers... By the way, were there any cases in the past when somebody filed a lawsuit on violation of LGPL and won?

    Regards,

    Slava Imeshev
  61. Hi Slava,

    I even didn't know that JBoss had lawyers...

    JBoss Group LLC is a company. They had better have lawyers -- although hopefully they just rent them from a firm.

    By the way, were there any cases in the past when somebody filed a lawsuit on violation of LGPL and won?

    Yes. Although I'm not sure if any went fully through the court system. The FSF has been settling a number of cases out of court for some time, so there is probably precedent.

    The important thing to remember is that, as copyright holders, the people that submitted works to the JBoss project have just as much right to legal protection of their copyright (and thus their choice of how to license) as any commercial product would. Just because JBoss and Apache software is "free" (dollars) does not allow anyone to misappropriate any of its pieces in a way that violates the respective licenses. Apache (ASF) is obviously very cognizant of this, and is clearly trying to avoid any appearance of impropriety, which given the "dual project contributors" and potentially "derived works" will be very tricky, as Bill tried to point out.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  62. Hmm. Not convinced[ Go to top ]

    A and B look like implementations of interfaces that would be substantially the same, whoever wrote them.

    C is trickier, but this is a standard design pattern being expressed - check any pattern textbook and you'll see code like this.

    If Geronimo is pinching implementation details, they'll need better examples than the ones expressed.
  63. Yes. Although I'm not sure if any went fully through the court system. The FSF has been settling a number of cases out of court for some time, so there is probably precedent.
    <br><br>
    Uh, precedents are set by court decisions made by judges and juries. Cases that are settled out of court do not set any precedents.
    <br><br>
      - jonathan.
  64. Uh, precedents are set by court decisions made by judges and juries. Cases that are settled out of court do not set any precedents.

    They don't set judicial precedents. They do, nonetheless, set precedents.

    I think it very foolish at this point to purposefully break any of the xGPL licenses; my guess is that the FSF has quite a bit of experience by now defending the licenses. I am not suggesting that Geronimo has broken the license; I'm just being clear that the JBoss developers do have rights as copyright holders and those rights should be respected.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  65. By the way, were there any cases in the past when somebody filed a lawsuit on violation of LGPL and won?


    I remember that mysql brought a boston company to court. The result was:
    1. The Boston company can not use mysql's tradmark.
    2. Mysql can not show any damage, because the orignal is free of charge, so the Boston company do not pay anything.

    If some company "violates" mysql's copyright (not the trademark), will mysql spend money and time to bring it to court again?
  66. Shame on developers that steal code or IP! I hope ASF does the right thing and cancells Geronimo and permamently bans the developers. If there is a case to be filed with the courts against individials that stole IP, then I am for that. This is much like Mutual Funds stealing from the little guy. Wond anyone hire a consultant that steals code?

    ASF gave us Tomcat, Struts, etc. and is a great organization.

    This is what SCO is saying, that Linux leaked code.
    Open Source is done by software engineers of highest ethical standards!

    Add I hope thatjBoss to get J2EE certified, Sun should not be playing games. Everyone play by same fair rules.

    Respect the FREE licenses.

    .V
  67. Ban?[ Go to top ]

    ASF gave us Tomcat, Struts, etc. and is a great organization.


    And has said that any (L)GPL code will be removed. Based upon your comments, you should trust that to happen. Feel free to participate.

    > I hope ASF does the right thing and cancells Geronimo
    > and permamently bans the developers.

    The ASF is about Communities of developers. Any incoming project, of which Geronimo is one, goes into the Apache Incubator while any issues are vetted *and* while its community develops. It doesn't get let out until all issues are resolved, which includes having a healthy ASF community. Members of that community are taught, not discarded. The end result are more people who are aware of the right way to develop a project.
  68. Waste of Time and Resources![ Go to top ]

    Personally, I think that JBoss (LLC) is really wasting their time when it comes to this action. I've been using JBoss for years now, and quite like it. They have every right to make money from it in any way they can, but at this point Geronimo isn't a threat to that, and likely won't be for some time. The implementation of a full J2EE server suite can take years, as evidenced by the length of time JBoss took to get to the state it is currently in.

    That said, however, Geronimo may indeed get to that point. The current, and recent tactics, taken by JBoss (LLC) could be interpreted in a negative enough manner that many people will seek to join the Geronimo project instead of hinder it. I'm basically saying that these actions are very similar to negative publicity.

    While I think it's too late for a statement such as 'Why can't everyone just get along?' I think the J2EE world could do with a little more collaboration, and a lot less posturing.
  69. 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."
  70. <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.
    >>>

    Did you do the rewrite because you found the original was in violation of the LGPL license?

    Also, what guarantee is there that once the Geronimo project has been released there won't be more of these violations? Who is monitoring the committers who added the initial violation (the 'Invocation') in the first place? What is the Apache Software Foundation doing to guarantee I don't find myself using a product the violates the LGPL license and exposing my self legally?

    I believe this puts serious doubt on Apache if nothing is done when these violations are found/there's no procedure to handle developers who have been shown to ignore licensing issues.
  71. I believe this puts serious doubt on Apache if nothing is done when these violations are found/there's no procedure to handle developers who have been shown to ignore licensing issues.


    This is extreme FUD.

    All that has happened is that an, as yet unofficial, apache project checked some LGPL into a CVS tree. Unless you are going to argue that every time you check something into a pre-alpha open source CVS tree you are making a distribution (a very harmful precedent indeed in light of SCO), this is consistent with the letter of the LGPL. In any even it is certainly in keeping with the spirit of the LGPL.

    There is absolutely no reason to believe that Apache ever would have had an official release of a product that contained LGPLed code, and there are a great many reasons to believe otherwise. Clearly the most significant pieces of JBOSS code to make it into the Geronimo CVS (for example Invocation) were removed months ago. I doubt very much that the Geronimo team needed to be reminded of the need to keep LGPLed code out of the final product, considering that the whole point of Geronimo is to have Apache license J2EE app server.

    We certainly should not be condeming the Apache project for something that they MIGHT have done in the future. I also don't think we should condem JBOSS for giving their lawyers a few thousand dollars to send the Apache Foundation a reminder (At least not on moral grounds. One would think that a strategic email sent above the heads of the Geronimo group could have set in motion the same discussion that is going inside of Apache now, without the expense).

  72. This is extreme FUD.
    <
    Given the problematic situation Geronimo is in due to its main contributors exposure to a non-compatible license, I feel these are legitimate concerns.
     
    >>>
    There is absolutely no reason to believe that Apache ever would have had an official release of a product that contained LGPLed code [...] Clearly the most significant pieces of JBOSS code to make it into the Geronimo CVS (for example Invocation) were removed months ago.
    <
    Since we have established that such cross-pollutination indeed occurs during development phase it would be helpful if we can hear from the Apache Software Foundation answers to the questions:

    What are the steps ASF is taking to ensure that no LGPL code "leaks" from development stage to an actual release? Is there going to be an audit of the codebase before the release? Who would perform such an audit? What are the steps I, as the end-user, can do to protect myself if ASF fails to perform such an audit?

    I think we can agree Geronimo is in a special situation here from the legal point of view due to its history and the fact that there indeed seems to be unauthorized "borrowing" of code during the development phase.
  73. Since we have established ....

    > I think we can agree Geronimo ...
    > ... and the fact that there indeed seems to be unauthorized "borrowing"

    Nobody established anything yet. No, we, if you mean all with we, can not agree and until yet there indeed seems to be nothing than fud.
  74. Things getting ugly?[ Go to top ]

    I can completely understand the JBoss peoples concerns regarding this issue. However I am a bit worried that things could get ugly when lawyers are involved, have there been any contact to try to resolve and discuss these issues WITHOUT lawyers?
    What the open source movement DOES NOT need is another legal story played out in the media, it would be extremely detrimental to the open source movement as a whole, and in particular to the JBoss Group and ASF. I dont believe there will be any winners on a thing like this going to court if it can be resolved quickly and painlessly by talking and changing the code.

    So please, for the sake of the Open source movement, try to resolve this without a conflict. I dont believe that the JBoss group wants to win a Pyrrhus victory in court loosing more than they would win even if they are victorious in court, and I hardly believe that the ASF wants to live under the shadow of suggestions of potential copied code, even if there are arguments that would suggest it is there legally.

    Dont make this an ugly affair, just resolve it smoothly and diplomatically.
  75. Things getting ugly?[ Go to top ]

    If you are anti-jboss, then surely it coincides with your opinion that a letter from Marc Fluery's lawyer may be a more civil and contructive method of resolving the issue than a letter from Marc himself.

    Personally, I think it shows restraint to pay someone else as an intermediary to help resolve a sensitive issue when your personal feelings are involved and you feel your livelihood may be threatened.
  76. We need Oliver Stone for this[ Go to top ]

    There is certainly a bunch of covert actions, cover-ups, conspiracies, and flat-out bad behavior on all sides.

    We need to call Oliver Stone to make a cool 4 hour long conspiracy style movie out of this (ala JKF).

    Who do we cast as marcf? I would guess Edward Norton.

    Regards,
    Tom
  77. Things getting ugly?[ Go to top ]

    So I am anti JBoss because I do not think a conflict will further the interests of JBoss or the open source movement? Get a grip! Not everything is about "pro" or "anti" something.

    I happen to think that the JBoss people are doing a great job with their app server and hope they will continue to do so. This has nothing to do with me wanting to se a quick and painless resolution to this difference of opinion or whatever it is.
  78. Mahatma Gandhi[ Go to top ]

    "First they ignore you, then they laugh at you, then they fight you, then you win." - Mahatma Gandhi (1869-1948)
  79. This is bad for the Java community[ Go to top ]

    It's good that JBoss sent just a letter through their lawyer. A lawsuit between Geronimo and JBoss would be really bad news for the Java community and ammo for the enemy
  80. This is bad for the Java community[ Go to top ]

    I would not call them enemies, but rather competitors: IBM and BEA will be the winners of the situation!
    In big companies like the one I work for, sad decisions might be taken based on the fact that the OpenSource Community, often perceived as one big group of persons (which in fact it is not), not as distinct teams or companies, is carrying out some sort of "Civil War". And these decisions might imply a weakened position of open source products.
    Please act wisely!
  81. This is bad for the Java community[ Go to top ]

    I totally agree. Isnt the whole stance on open source that we share in order to improve the quality of our projects and in the end all software. Here we have the beginning of something that will be very damaging to open source and it's software licencing practices.

    JBoss has been out in front with their product and Geronimo has the potential to challenge if it is good enough, but what I say is...please play fair...innovate not immitate and dont go looking to bury a competitor if they look to challenge you position (general comment..not aimed at any of the companies in question here)

    The common goal is the software...not the full on commercial nature of selling products or services. Open source is still a great movement but it is getting a bit clouded now that it has gained popularity. And with this popularity comes the commercial aspect, that in the end real spells the end for free and open source code.
  82. This is bad for the Java community[ Go to top ]

    Geronimo is not an altruistic open source project. It has two stated purposes:

    1. To destroy JBoss.
    2. To make a competing product and profit from it.

    There is personal animosity between most of the Geronimo developers and many of the prominent JBoss developers. The Geronimo developers are former JBoss developers and they "forked" their project because of their personal dislike of Marc Fluery and other individuals, both within JBoss LLC, and outside it, who continue to contribute to JBoss. The also disagree with the principles which JBoss stands for; namely, the LGPL, as well as the JBoss LLC making a profit from the code. This is quite contradictory on the part of the Geronimo developers because of 2. Geronimo has already received substantial investment funding, and many of the developers are being paid directly to work on it. The Apache license permits a closed source fork, and this is a definite motive for at least some of those involved with the project, either developers or investors, to have an Apache licensed alternative to LGPL JBoss.

    This isn't a civil war in the open source community, Geronimo is a personal vendetta against Marc Fluery and others at JBoss group motivated by money
  83. This is bad for the Java community[ Go to top ]

    aaron: Geronimo is not an altruistic open source project.

    Are you a spokesperson for the Geronimo project? Or is this just
    your opinion? I just want to make sure that I understand where you
    are coming from.

    aaron: It has two stated purposes:
    1. To destroy JBoss.
    2. To make a competing product and profit from it.


    I have not seen that "stated"; could you please cite a reference?
    If you are the spokesperson for the Geronimo project, please make
    sure to add that information to the Geronimo project page so that
    people wishing to be involved will be aware of what they are signing
    up for. In fact, I couldn't find any reference to JBoss at all on
    that page.

    aaron: There is personal animosity between most of the Geronimo
    developers and many of the prominent JBoss developers.


    From what I've read there is personal animosity between some (not
    "most") from these two projects. If you are not one of those people,
    then I'd suggest that their personal animosity is none of your (or
    my) business. Why would you want to get in the middle of someone's
    personal squabble? That doesn't make sense to me. Further, what
    right do you have to interject yourself into it?

    aaron: The Geronimo developers are former JBoss developers ...

    All of them? Or most of them? Or some of them? Or a few of them?

    James Strachan, for example, was not a JBoss developer to the best of
    my knowledge.

    aaron: ... and they "forked" their project because of their personal
    dislike of Marc Fluery and other individuals, both within JBoss LLC,
    and outside it, who continue to contribute to JBoss.


    From what I witnessed, there appears to be some truth in this, but
    surely you are not suggesting that this is the only motivating
    factor for the entire project? That claim seems to be textbook
    paranoid-delusional.

    aaron: The (sic) also disagree with the principles which JBoss
    stands for; namely, the LGPL, as well as the JBoss LLC making a profit
    from the code.


    If you are not one of "them", then how can you be so sure? CDN,
    for example, teaches JBoss classes, so they obviously believe in
    making a profit from it.

    aaron: Geronimo has already received substantial investment funding,
    and many of the developers are being paid directly to work on it.
    The Apache license permits a closed source fork, and this is a
    definite motive for at least some of those involved with the
    project, either developers or investors, to have an Apache
    licensed alternative to LGPL JBoss.


    While this is an interesting possibility, I have two questions:

    1. What facts do you have to back up these assertions?
    2. Why would it matter? The same appears to be true of various
    Apache projects.

    aaron: Geronimo is a personal vendetta against Marc Fluery and
    others at JBoss group motivated by money


    In the nicest way possible, I would suggest that you are making
    irrational claims. You cannot claim that it is both solely personal
    and solely motivated by money. Is it personal? Or is motivated by
    money? It is simply too convenient to have such an evil group of
    people as the project could be purely motivated by both as if they
    were a single reason.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  84. This is bad for the Java community[ Go to top ]

    aaron: Geronimo is a personal vendetta against Marc Fluery and

    > others at JBoss group motivated by money

    >
    > In the nicest way possible, I would suggest that you are making
    > irrational claims. You cannot claim that it is both solely personal
    > and solely motivated by money. Is it personal? Or is motivated by
    > money? It is simply too convenient to have such an evil group of
    > people as the project could be purely motivated by both as if they
    > were a single reason.
    >
    > Peace,
    >
    > Cameron Purdy
    > Tangosol, Inc.
    > Coherence: Clustered JCache for Grid Computing!

    I do not think his claims are irrational as I believe it can be both personal and about the money as well. Why not?

    It isn't personal? Do you know the historical reference to Elba? It is the island that Napoleon was banished to. Hmmmm.... Not personal?

    Not about the money? Hmmmm....Isn't that what the CDN split from JBG was all about anyways? If they are not making money off of JBoss, then the perfect alternative is to ride the coattails of the Apache brand and create Geronimo. Makes perfect sense to me.

    I find it very unfair that JBoss and JBoss Group has been labeled as such an EVIL entity when the disgustings things that have been revealed on this thread have been going on behind the scenes. Although they are abrasive at times, At least the JBoss folks are straightforward and blunt. They don't hide.

    Hans
  85. This is bad for the Java community[ Go to top ]

    That's all good and well but what I find really disturbing is that the people in this topic seem to be making a bigger deal out of this issue than either JBoss or ASF.
  86. This is bad for the Java community[ Go to top ]

    That's all good and well but what I find really disturbing is that the people in this topic seem to be making a bigger deal out of this issue than either JBoss or ASF.


    LOL, you may be right. Ha ha!
  87. This is bad for the Java community[ Go to top ]

    Hans: "I do not think his claims are irrational..."

    Hans, aaron said (scroll up to see):

    "It has two stated purposes:
    1. To destroy JBoss.
    2. To make a competing product and profit from it."


    The latter is obvious. I suggest that the former qualifies as irrational.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  88. Good thoughts, Cameron. Right on all points. Allow me to contribute some thoughts of my own.

    aaron: Geronimo has already received substantial investment funding,
    and many of the developers are being paid directly to work on it.

    This assertion has no basis in reality. Noone is being compensated monetarily for contributing to Geronimo. Besides, what's wrong with getting paid to write Open Source software? Look at JBoss Group LLC--their developers get paid to write Open Source, by the company's admission. That's great!

    aaron: The Apache license permits a closed source fork, and this is a
    definite motive for at least some of those involved with the
    project, either developers or investors, to have an Apache
    licensed alternative to LGPL JBoss.

    Thereby enforcing Free Market conditions through investment in a commonly available intellectual capital infrastructure while leaving the door open for private involvement and preventing the possibility of technological monopoly.

    That's what you were going to say, right?

    I oppose monopolization in all its forms and welcome competition in the market. Increased investment of intellectual capital into common infrastructure like Geronimo could help this market explode. I don't know why people like Burke oppose that notion other than that they fail to understand the laws of Production or don't understand the distinction between "capitalists" and "monopolists".

    In either case they should bone up on the Austrian school of economic theory and try not to be so irrational in public. The Lefevre archives at Mises.org would be a good place to start. Easy listening while you code ;)

    --
    N. Alex Rupp (n_alex_rupp at users dot sf dot net)



    "You asked if I believe that we'll see the end of licenses for infrastructure. The answer is yes. I also believe there's a monopolistic opportunity in open source infrastructure, just like Microsoft has a monopoly on the desktop. Free software will create a market that is much more open than that, but we see ourselves becoming a standard, used everywhere, while other application server vendors are struggline (sic). That's our end goal, to become a monopolistic but responsible provider of Web infrastructure." -- Dr. Marc Fleury
    (http://www.theopenenterprise.com/story/TOE20021120S0001)

    The above statement is the nucleus of the JBoss ideology, all their florid rhetoric aside. It is the reason why I am dedicated to helping provide an alternative infrastructure beyond The JBoss Group's control. Nobody will ever that much power. Not Microsoft, not JBoss, not anyone. And the ASLv2.0, which explicity grants a license of copyright authority, prevents the possibility of such a monopoly from ever occuring. Even the ASF will be unable to control the software.

    So there you go. Anarcho-Capitalism 101. And I, unlike Aaron, can even quote my sources!
  89. Good thoughts, Cameron. Right on all points. Allow me to contribute some thoughts of my own.

    >
    > aaron: Geronimo has already received substantial investment funding,
    > and many of the developers are being paid directly to work on it.
    >
    > This assertion has no basis in reality. Noone is being compensated monetarily for contributing to Geronimo. Besides, what's wrong with getting paid to write Open Source software? Look at JBoss Group LLC--their developers get paid to write Open Source, by the company's admission. That's great!
    >
    > aaron: The Apache license permits a closed source fork, and this is a
    > definite motive for at least some of those involved with the
    > project, either developers or investors, to have an Apache
    > licensed alternative to LGPL JBoss.
    >
    > Thereby enforcing Free Market conditions through investment in a commonly available intellectual capital infrastructure while leaving the door open for private involvement and preventing the possibility of technological monopoly.
    >
    > That's what you were going to say, right?
    >
    > I oppose monopolization in all its forms and welcome competition in the market. Increased investment of intellectual capital into common infrastructure like Geronimo could help this market explode. I don't know why people like Burke oppose that notion other than that they fail to understand the laws of Production or don't understand the distinction between "capitalists" and "monopolists".
    >
    > In either case they should bone up on the Austrian school of economic theory and try not to be so irrational in public. The Lefevre archives at Mises.org would be a good place to start. Easy listening while you code ;)
    >
    > --
    > N. Alex Rupp (n_alex_rupp at users dot sf dot net)
    >
    >
    >
    > "You asked if I believe that we'll see the end of licenses for infrastructure. The answer is yes. I also believe there's a monopolistic opportunity in open source infrastructure, just like Microsoft has a monopoly on the desktop. Free software will create a market that is much more open than that, but we see ourselves becoming a standard, used everywhere, while other application server vendors are struggline (sic). That's our end goal, to become a monopolistic but responsible provider of Web infrastructure." -- Dr. Marc Fleury
    > (http://www.theopenenterprise.com/story/TOE20021120S0001)
    >
    > The above statement is the nucleus of the JBoss ideology, all their florid rhetoric aside. It is the reason why I am dedicated to helping provide an alternative infrastructure beyond The JBoss Group's control. Nobody will ever that much power. Not Microsoft, not JBoss, not anyone. And the ASLv2.0, which explicity grants a license of copyright authority, prevents the possibility of such a monopoly from ever occuring. Even the ASF will be unable to control the software.
    >
    > So there you go. Anarcho-Capitalism 101. And I, unlike Aaron, can even quote my sources!

    I think your portrayal of us and Marc is quite unfair. Why are you creating this false illusion that we have such negative power over the JBoss codebase? We could never ever change the LGPL license. We could never change the license as over the past 4 years hundreds of people have contributed code under the LGPL license. It would take hundreds of signatures including those of your colleagues. JBoss Group or the JBoss project DOES NOT REQUIRE OR ASK anybody to sign any legal document granting JBoss Group a license of copyright authority. Everybody that contributes retains their SOLE copyright in our codebase. As the Elba project shows, it is quite easy and possible to fork the JBoss codebase UNDER THE LGPL LICENSE.

    As you portrayed correctly in a recent article, what JBoss Group has control over is the brand. Unlike the ASL, LGPL will guarantee that the JBoss codebase and derivatives will remain open source and free of charge. We are passionate in our support of the LGPL for this very reason.


    Bill
  90. ASF[ Go to top ]

    Just wanted to add that I personally thank the ASF for taking our concerns very seriously and looking into this issue.

    Bill
  91. Perfectly fair.[ Go to top ]

    I think your portrayal of us and Marc is quite unfair.


    The only unfair advantage I have over you and Dr. Fleury is distance. I have nothing to risk emotionally or financially by the success or failure of your company.

    > Why are you creating this false illusion that we have such negative power over the JBoss codebase?

    I do not need to characterize your power. Power is not "negative" or "positive". It simply "is". And it is the nature of all forms of social power (capital, money, government, whatever) to expand and concentrate into the hands of a few people. I'm sorry to have to tell you this, but the individuals involved are inconsequential--power operates without regard to the individual, it's a macrobehavioral byproduct of human interaction. I'm concerned only with preventing power from concentrating into the hands of a few people, and the best way to do that is to advance Free Markets. Not the global economy we see developing in the twentieth century, but the uncontrollable mercanilism and proto-capitalism of the late 18th century. You're a patriots fan, you should know all about this :)

    > We could never ever change the LGPL license. We could never change the license as over the past 4 years hundreds of people have contributed code under the LGPL license.

    And so you are locked in and unable to change. How "Free" is your software, Bill? How "Free" are you? You have no control, and only one option.

    > It would take hundreds of signatures including those of your colleagues.

    I know. I've been through this line of reasoning before. I hope for your sake the LGPL remains a valid license.

    > JBoss Group or the JBoss project DOES NOT REQUIRE OR ASK anybody to sign any legal document granting JBoss Group a license of copyright authority.

    That's too bad. If they did, there would have been no misunderstandings about the nature of different people's involvement and authority over the software, and your company would be able to relicense the project if the needs of the company or the project were ever to change. But you're locked in. It's your single greatest disadvantage as a company that you do not own your product.

    > Everybody that contributes retains their SOLE copyright in our codebase.

    Until they create derivative works of the source or engage in cooperative development. At that point, NOBODY has complete copyright authority over the file (property), and you're locked into collective ownership. When you contribute to the ASF, they make you sign a contract granting them a license to copyright authority over your contributed work, but the Apache Software License does not (yet) explicitly re-grant that copyright license to the end users. The developer retains sole copyright authority IF and only if they are the sole contributor to that file over the course of its development. That's why I use the Academic Free License (at least until Apache License 2.0 comes out, then I'll reconsider). It guarantees that I can do whatever I want with everyone's contributions, use any license, and that they can do the same. And we all have complete copyright authority over copies of the software, so there is NO collective ownership.

    From my point of view, I'm sitting pretty. Worst case, someone takes my ideas and does a better job implementing them. More power to them, I say :) Good ideas are a dime a dozen--good implementations are quite rare.

    > As the Elba project shows, it is quite easy and possible to fork the JBoss codebase UNDER THE LGPL LICENSE.

    I think that was the primary motivation behind the fork, just to prove it could be done. But I'm only speculating here. I actually wasn't privy to the inside discussions on that one. I actually don't like the Elba project because it's confusing and people place way too much stock in its existence. (on the other hand, I've designed a really cool icon for it :)

    > As you portrayed correctly in a recent article, what JBoss Group has control over is the brand. Unlike the ASL, LGPL will guarantee that the JBoss codebase and derivatives will remain open source and free of charge. We are passionate in our support of the LGPL for this very reason.

    And that's great. I appreciate your level of commitment to your beliefs. The Geronimo project ensures that support in our area of the market cannot be monopolized by any one company by leveraging their ownership of the brand and access to the developers, which was Dr. Fleury's strategy. After all, we know the services surrounding the product are more critical and profitable than the product itself (I think everyone's starting to realize that. ;)

    Also, anyone will be able to fork the release versions of Geronimo and relicense them as LGPL or even GPL, change the names and distribute them at SF if they want to (or need to). JBoss could do this, but they can no longer claim that they're the last bastion of Open Source :) And we're leaving the door wide open to plug in nonstandard, proprietary or custom components (such as Hibernate) if J2EE is too "vanilla" for the end users. Users will be able to select them from a list, install and configure them on the fly at runtime, which should open up the services market to a broad spectrum of proprietary and Open Source competition.

    Rickard used to say that it was the Open Source development process--open access to the code, inclusive community involvement, automated testing, constant refactoring, all the principles of "agile development" or "extreme programming" that led to the early success and rise of JBoss. And I believe him, which is why I believe Open Source teams will always write better software than corporate teams.

    In the case of JBoss, it doesn't matter anymore if the product is Open Source, because the process is closed. If that offends you or you think it's unfair of me to say it, it only proves my point further that your ideals are out of sync with the ideals of the man you work for.

    I hope this helps describe our differences and dispels the idea that I bear some grudge against you guys or (more ridiculously) that I'm some "stooge". I'm investing my time and energy because I know I'll profit from everyone else's success. That's my strategy, and I intend to help a lot of people out before I'm done. Keep up the good work with AOP--it's pretty cool stuff.

    And by all means let us know if you find any conflicts with the code as it matures. I'm positive the matter will be dealt with quickly and efficiently. There are more people in the ASF than your former coworkers and the PMC take their job VERY seriously ;)

    Cheers,
    --
    N. Alex Rupp (n_alex_rupp at users dot sf dot net)
  92. Perfectly fair.[ Go to top ]

    In the case of JBoss, it doesn't matter anymore if the product is Open Source, because the process is closed. If that offends you or you think it's unfair of me to say it, it only proves my point further that your ideals are out of sync with the ideals of the man you work for.

    >

    Anybody who has ever been a JBoss contributor knows that our developers have great leeway in submitting and developing code. Yes, anybody who chooses to fork the JBoss project or submit refactored pieces of JBoss under a difference license other than (L)GPL, we do not tolerate, and that's where our liniency stops. These behaviors are just too detrimental to the overall adoption to the JBoss platform and are just not tolerated. Period.

    JBoss contributors continue to be a strong, talented mix of developers from all parts of the software industry: those that work on JBoss 100%(JBossGroup), academia, and also the corporate world. Web Services (Dr. Jung), Laurent Entiemble on JBoss IDE, Ricarod Arguelo and Spyridon Samothraki on Enterprise Media Beans, IIOP/CORBA integration Francisco Reverbel, XDoclet, Andy Godwin, JBoss Remoting (another key piece of 4.0) Tom Elrod and Jeff Haynie, to name a few. Our task lists are on SourceForge. We are still one of the most active projects on sourceforge. We have over 84 developers with CVS access. We still recruit the best and the brightest.

    JBossGroup recruits heavily from our contributor base for hirings as we believe strongly in our vision of Professional Open Source where developers spend a minimum of 50% on open source development and the rest in the field consulting. We feel this gives our project a distinct advantage over our competitors as we get to see directly how our product is being used in the field.

    Bill
  93. Perfectly fair.[ Go to top ]

    \Bill Burke\
    Yes, anybody who chooses to fork the JBoss project or submit refactored pieces of JBoss under a difference license other than (L)GPL, we do not tolerate, and that's where our liniency stops. These behaviors are just too detrimental to the overall adoption to the JBoss platform and are just not tolerated. Period.
    \Bill Burke\

    On forking...the LGPL explicitly allows for forks. Anyone in the world can
    fork the JBoss code without any legal repurcussions. You might even say that
    the LGPL encourages this behavior.

    On "submit refactored pieces of JBoss under a difference license other than (L)GPL, we do not tolerate..." - there is no "we" here. The copyright is not held by JBoss Group LLC, and the license is not offered by JBoss Group LLC. The copyright is held by the individual authors, and the license granted by those authors. JBoss Group LLC has no say in this. All that that corporate entity controls is the JBoss(tm) Trademark.

    If JBoss Group, the company, wants to succeed, I would think it would be in their best interests to distinguish between JBoss, the code base, and JBoss, the company. One you control - the company - the codebase you most explicitly do _not_ control. This is what others in this thread have tried to explain to you - the company JBoss Group LLC has no control over the source to its primary asset, JBoss-the-code. You or Bela or Gavin or any number of JBoss Group employees could quit tomorrow and change the license on all of the code you own to be ASF, BSD, or completely closed if you so desired. And JBoss Group LLC would have no say in that. Rickard could choose to revoke his LGPL license on code he authored tomorrow. The only fuzzy areas are where multiple authors have written code - and even there, an accord could be reached by those multiple authors, and in many cases there are only 2 or 3 who would have to agree.

    And, again, JBoss Group LLC would have no legal recourse.

    And, of course, anybody could always just take the source and keep it (L)GPL and start modifying the heck out of it, and there would be nothing you can do. Your tolerance has nothing to do with it.

        -Mike
  94. Perfectly fair.[ Go to top ]

    \Bill Burke\

    > Yes, anybody who chooses to fork the JBoss project or submit refactored pieces of JBoss under a difference license other than (L)GPL, we do not tolerate, and that's where our liniency stops. These behaviors are just too detrimental to the overall adoption to the JBoss platform and are just not tolerated. Period.
    > \Bill Burke\
    >
    > On forking...the LGPL explicitly allows for forks. Anyone in the world can
    > fork the JBoss code without any legal repurcussions. You might even say that
    > the LGPL encourages this behavior.
    >
    > On "submit refactored pieces of JBoss under a difference license other than (L)GPL, we do not tolerate..." - there is no "we" here. The copyright is not held by JBoss Group LLC, and the license is not offered by JBoss Group LLC. The copyright is held by the individual authors, and the license granted by those authors. JBoss Group LLC has no say in this. All that that corporate entity controls is the JBoss(tm) Trademark.
    >

    I have learned from previous TSS threads that it is quite pointless to argue with you, but I must correct some of your untrue remarks to set the record straight.

    I was hinting that you will not retain CVS rights for the JBoss project if you engage in such activities. Although JBoss Group does not control the right to distribute the software, we do control the SourceForge distribution as Juha Lindfors, Scott Stark, Marc Fleury, and I are the admins(as well as the brand and the website). I don't think you've read any of my posts very carefully here as I've continually stated that the LGPL allows for forks or anything else anybody wants to do under the terms of the LGPL. You are also very incorrect that the LGPL is revokable. Once you have licensed somebody the right to use your work, they have the right to use it. There is no clause in the LGPL that it is revokable by the copyright holder and there is also no expiration date on the license.

    I also want to dispell this perception that you and others are trying to paint that the members of JBoss Group are not the main contributors to the project. The members of JBG have solely authored, refactored, or change code to fix bugs for over 95% of the current codebase. We are the most active contributors both past and present. All you have to do is query our public CVS history to verify this.

    EOD

    Bill

    > If JBoss Group, the company, wants to succeed, I would think it would be in their best interests to distinguish between JBoss, the code base, and JBoss, the company. One you control - the company - the codebase you most explicitly do _not_ control. This is what others in this thread have tried to explain to you - the company JBoss Group LLC has no control over the source to its primary asset, JBoss-the-code. You or Bela or Gavin or any number of JBoss Group employees could quit tomorrow and change the license on all of the code you own to be ASF, BSD, or completely closed if you so desired.

    We could relicense, but not revoke the license we have already granted.

    And JBoss Group LLC would have no say in that. Rickard could choose to revoke his LGPL license on code he authored tomorrow. The only fuzzy areas are where multiple authors have written code - and even there, an accord could be reached by those multiple authors, and in many cases there are only 2 or 3 who would have to agree.
    >
    > And, again, JBoss Group LLC would have no legal recourse.
    >
    > And, of course, anybody could always just take the source and keep it (L)GPL and start modifying the heck out of it, and there would be nothing you can do. Your tolerance has nothing to do with it.
    >
    > -Mike
  95. re: Perfectly fair.[ Go to top ]

    [QUOTE]
    > > Everybody that contributes retains their SOLE copyright in our codebase.
    >
    Until they create derivative works of the source or engage in cooperative development. At that point, NOBODY has complete copyright authority over the file (property), and you're locked into collective ownership. When you contribute to the ASF, they make you sign a contract granting them a license to copyright authority over your contributed work, but the Apache Software License does not (yet) explicitly re-grant that copyright license to the end users. The developer retains sole copyright authority IF and only if they are the sole contributor to that file over the course of its development. That's why I use the Academic Free License (at least until Apache License 2.0 comes out, then I'll reconsider). It guarantees that I can do whatever I want with everyone's contributions, use any license, and that they can do the same. And we all have complete copyright authority over copies of the software, so there is NO collective ownership.
    [/QUOTE]

    The first part of your statement is entirely untrue. I've contributed heavily to Apache Turbine and Jyve and there is *no* contract to be signed whatsoever. You're contributing under a BSD-style license, that's enough.

    Also, internationally the following interpretation seems to be the most accepted:

    I license *this particular instance* of my code under *this particular license*. I can take another instance and put it under another license *at any time*. You can still use the first instance, as most open-source licenses are not revokable. If this assumption did not hold, schemes like MySQL's AB GPL/Commercial License package wouldn't work.

    If you take *an instance* of my code that I placed under a *particular license* and modify it under the terms of *this particular license*, you retain the copyright of your modifications. In combination with the first instance of *my code* this provides a "derived work". I can't change the license of the *new combined code*, but *you can't as well*.

    I can however, in the case of most open-source licenses, take our combined work and rewrite all portions that have been contributed by you. Then *I can* change the license. That, of course, works the other way as well. The concept of open-source in general relies on the fact that all instances of your and my code are (and stay) available under their respective licenses.

    In the case of what is generally called the BSD*-license-family the above process is a lot simpler, because with using a BSD-type license you've already granted me the right to *relicense* your modifications.

    If I find all the authors of a GPLed project and get them to relicense their code to me, I can still create a closed-source project from the code. There would be, of course, an instance of the GPLed code in the net. This code could still be used under the GPL.

    Now here's a disclaimer: We're talking international law here, anyway. As JBoss and Geronimo are developed by individuals from all over the world, my interpretation outlined above may not hold true in all cases. It works for german law and most likely for US copyright law. These two already are *completely* different, because in Germany you cannot sell copyright. The term "copyright" (the right to copy) does not exactly fit the German term "Urheberrecht" (author's rights). There is no guarantee that any license *at all* would hold up in German courts as far as I know... that might be the case only if you using my code implies that there exists a contract between us. Then the license might be considered an addendum to this contract ("AGBs" in German law).

    It gets really ugly when I don't care about your copyright, or even worse if you hold a patent on code that I contribute without your permission.

    So my personal take is that it's virtually impossible to "relicense" JBoss code. Refactoring the code and putting it under a different license is something else. It's built into the permission of me *seeing* your code in the first place. If you want to hold the right on an abstract idea, go and get a patent. That's what they're for.

    I think many people here don't understand the difference between copyright and patents.

    * John
  96. re: Perfectly fair.[ Go to top ]

    [QUOTE]

    > > > Everybody that contributes retains their SOLE copyright in our codebase.
    > >
    > Until they create derivative works of the source or engage in cooperative development. At that point, NOBODY has complete copyright authority over the file (property), and you're locked into collective ownership. When you contribute to the ASF, they make you sign a contract granting them a license to copyright authority over your contributed work, but the Apache Software License does not (yet) explicitly re-grant that copyright license to the end users. The developer retains sole copyright authority IF and only if they are the sole contributor to that file over the course of its development. That's why I use the Academic Free License (at least until Apache License 2.0 comes out, then I'll reconsider). It guarantees that I can do whatever I want with everyone's contributions, use any license, and that they can do the same. And we all have complete copyright authority over copies of the software, so there is NO collective ownership.
    > [/QUOTE]
    >
    > The first part of your statement is entirely untrue. I've contributed heavily to Apache Turbine and Jyve and there is *no* contract to be signed whatsoever. You're contributing under a BSD-style license, that's enough.
    >
    > Also, internationally the following interpretation seems to be the most accepted:
    >
    > I license *this particular instance* of my code under *this particular license*. I can take another instance and put it under another license *at any time*. You can still use the first instance, as most open-source licenses are not revokable. If this assumption did not hold, schemes like MySQL's AB GPL/Commercial License package wouldn't work.
    >
    > If you take *an instance* of my code that I placed under a *particular license* and modify it under the terms of *this particular license*, you retain the copyright of your modifications. In combination with the first instance of *my code* this provides a "derived work". I can't change the license of the *new combined code*, but *you can't as well*.
    >
    > I can however, in the case of most open-source licenses, take our combined work and rewrite all portions that have been contributed by you. Then *I can* change the license. That, of course, works the other way as well. The concept of open-source in general relies on the fact that all instances of your and my code are (and stay) available under their respective licenses.
    >
    > In the case of what is generally called the BSD*-license-family the above process is a lot simpler, because with using a BSD-type license you've already granted me the right to *relicense* your modifications.
    >
    > If I find all the authors of a GPLed project and get them to relicense their code to me, I can still create a closed-source project from the code. There would be, of course, an instance of the GPLed code in the net. This code could still be used under the GPL.
    >
    > Now here's a disclaimer: We're talking international law here, anyway. As JBoss and Geronimo are developed by individuals from all over the world, my interpretation outlined above may not hold true in all cases. It works for german law and most likely for US copyright law. These two already are *completely* different, because in Germany you cannot sell copyright. The term "copyright" (the right to copy) does not exactly fit the German term "Urheberrecht" (author's rights). There is no guarantee that any license *at all* would hold up in German courts as far as I know... that might be the case only if you using my code implies that there exists a contract between us. Then the license might be considered an addendum to this contract ("AGBs" in German law).
    >
    > It gets really ugly when I don't care about your copyright, or even worse if you hold a patent on code that I contribute without your permission.
    >
    > So my personal take is that it's virtually impossible to "relicense" JBoss code. Refactoring the code and putting it under a different license is something else. It's built into the permission of me *seeing* your code in the first place. If you want to hold the right on an abstract idea, go and get a patent. That's what they're for.
    >
    > I think many people here don't understand the difference between copyright and patents.
    >
    > * John

    Great post John. One question nobody has answered though is what determines a derivative? If you refactor somebody's code, is it your own? Can you relicense? Derivative work is covered under GPL.

    Hans
  97. Spokesmen[ Go to top ]

    Aaron wrote: Geronimo is not an altruistic open source project.
    Cameron replied: Are you a spokesperson for the Geronimo project?

    Please note: no one is authorized to speak on behalf of the Apache Software Foundation except for its Officers, and those should be taken to be doing so ONLY when they so indicate. In other words, they may also speak personally, which is why you should assume unless they specifically state they they are speaking on behalf of the Foundation.

    Aaron Evans, not being an ASF Officer, cannot speak for anyone save himself. For that matter, I see no record of an Aaron Evans having participated on any mailing list related to the Geronimo project.
  98. This is bad for the Java community[ Go to top ]

    I dont agree on BEA and IBM being the winners. The Java community as a whole is strongly associated with the open source movement, and in particular IBM has betted strongly on other open source products, such as Apache web server and most notably Linux.
    The winners will be Microsoft and closed source zealots (theres a lot of zealotry going on in both "camps"!) who can point at the java/open source community and say: "I told you so! Nothing but two timing code thiefs and copy-pasters" (regardless of facts).

    BEA and IBM in particular dont stand to win anything from this, Microsoft and the anti open source camp do however.

    If this escalates, it will be a sure lose-lose-lose-lose scenario for JBoss, ASF and others involved in Java and open source.
  99. Geronimo on Codehaus?[ Go to top ]

    I noticed on Apache.org that the Geronimo project is hosted on codehaus.org? Is this ASF distancing themselves from Geronimo? Or is this regular practice? I could not find another apache project hosted on a different website.

    Hans
  100. Geronimo on Codehaus?[ Go to top ]

    I noticed on Apache.org that the Geronimo project is hosted on codehaus.org?

    > Is this ASF distancing themselves from Geronimo?

    No. The Geronimo project is hosted on the Apache server(s). They, and other projects, are currently using the codehaus wiki and jira installation while similar software is installed on the ASF infrastructure. Many thanks to Bob McWhirter of The Werken Company for helping by providing interim resources and migration help. :-) As they say in Maine, Bob is finest kind.
  101. Beginning of the end[ Go to top ]

    Lawyers! Blackmail! Theft ! "Aggresive protection of IP" !

    Is this the beginning of the end for Open source?
  102. This is what happens when open-source is used to make money. I blame JBoss for poisoning the beautiful world of open-source. The model where developers work part-time on opensource selflessly works, when you try to work full time, you have to worry about putting food on the table. If you do choose to work fulltime, that is your choice. Nobody is forcing you too.
  103. "I blame JBoss for poisoning the beautiful world of open-source"

    Man, melodramatic junk like this cracks me up.

    People are so evil for trying to make money off their talents and ideas.

    I don't know why everyone is getting so worked up over this. It isn't a lawsuit, but rather an official reminder to ASF to make sure Geronimo is respecting intellectual property rights.

    This is in the best interests of the ASF and JBoss. Honestly, it says a lot about JBoss because a lot of companies would probably have just sued outright. This has got to be one of the most civil "disputes" I've seen.
  104. Yep, it sure was better when we had no currencies and had to barter for everything.. You wouldnt happen to have a cow to trade for a hammer would you? :)

    If people dont like others making money of theirs (and refined ideas of others) I am sure Cuba and North Korea would love the PR involved in westerners "jumping" to their way of life (in Cuba or N Korea of course)..
  105. Regarding "exact signatures", have people forgotten the Java SDK license agreement which states:

    under SUPPLEMENTAL LICENSE TERMS section D:

    "In the event that you create an additional class and associated API(s) which (i) extends the functionality of the Java platform, and (ii) is exposed to third party software developers for the purpose of developing additional software which invokes such additional API, you must promptly publish broadly an accurate specification for such API for free use by all developers."

    Claiming ASF violated JBOSS copyright because of EXACT SIGNATURES is in violation of the J2SE license.
  106. Apache's rummored answer:[ Go to top ]

    Here is a what an Apache answer is rumored to be so far:

    Some background rumor context, to give appropriate level of credibility:
    jBoss was trying to get a J2EE certification, which would be a problem for the commercial J2EE vendors, as in why pay $,… when you can have better for free/cheap, so one possibility is that Sun used it’s “control” of ASF to … go after them ... legally. How do I know this? National Enquirer magazine had it next to "the Aliens Invade, led by Elvis". It just makes sense.

    So we have:
    http://elba.sourceforge.net

    The “joint” plan above supported by ASF, is to *copy the design* and re-implement that design, in essence refactor it, taking advantage of some jBoss OSS developer discontent.

    I am not sure if jBoss patented the design. ASF I guess feels that there is no legal precedents on copying a design. So ASF would take jBoss trough the legal system (I said legal system, not justice system).

    The ASF response would be… Yes, it is our intention to take jBoss code, and refactor it module by module. if you show us duplicate code, we will refactor it, to make it harder for you to prove it a * legal * problem, because there is a lot of gray area * legally *.

    The ASF gave the jBoss letter to Geronimo developers, the same people that wrote this on sf.net:
    “
    Think of Elba as a latticework for Geronimo--and as a shield to buffer the Geronimo codebase …. As Geronimo is built, its code will replace the code from Elba, bit by bit until there's nothing left in Elba at all. ...

    Will code from Elba be used in Geronimo?

    Don't worry--this is not a big deal, as the goal is to have this project quickly die as features are added to Geronimo.”

    So one can see that this is the plan all along, rob jBoss!
    Are you still reading this crap? OK:

    So the plan is proceeding and ASF is digging in. The likely the response will be from Geroniomo developers to jBoss… "show us the code, and we will refactor it." And I dare you to take us to court, this is legal for us to do, we have a loophole.

    More?
    ASF used to be “code you can use at work”.
    In the end… Open Source Developers will NOW have to _ expunge _ references to open source software in their resumes. What company is suicidal to hire an OS developer?
    Yes, at day time I design and you pay me, at night I refactor and put in Open Source (or wrose things) so that companie’s competitors can use it.

    Appache would then be “code you refactor from work”, something many have suspected.

    The work for hire contract means nothing, it’s a re-implementation, you see.

    You can take any jar file, de-compile, refactor… and it’s yours! Ah.. the possibilities. Let’s see, what is the first project I will “re-implenet via a latticework”.

    OS developers even steal from other OS projects, let alone commercial.
    A clean resume should only have references to commercial software, you can’t have Apache, you should have IIS, and no Tomcat, put iPlanet, remove Linux/ put Solaris, less you be a suspect of… "hey, you are one of those people that takes the design and refactor".
  107. Apache's rummored answer:[ Go to top ]

    Your great conspiracy theory has a couple of fatal flaws, especially with regards to the "Apache would then be “code you refactor from work”, something many have suspected.":
    * Most proprietary licenses expressively forbid decompilation of code, you are in deep barney if someone catches you doing this and chooses to take legal action.
    * Most employers make you sign NDA:s that expressively forbid you to work, reveal or spread information and know-how of what you are working on for them while employed. Some even go to the lengths to claim that any and all code you write while employed during working hours or in your own spare time belongs to them, and thus cannot be redistributed without their prior written consent. After your employment is terminated for some reason (by you or your employer) using their proprietary code for ANYTHING will account to copyright infringement and theft (you shouldnt have access to it if you are not employed by them, should you?).

    With theories like this, you should put your tin-foil hat back on and hang with your buddies at slashdot. :)
    But I guess your whole post was just a joke, considering you wrote "are you still reading this crap?". :)
  108. Apache's rummored answer:[ Go to top ]

    What a Conspiracy theory. You need to start publishing :)
  109. Kiss and make up[ Go to top ]

    As a user of both JBoss and Apache project software, I would like to see JBoss and Apache kiss and make up. This kind of stuff is not worth fighting about. It drains everybody's resources and reduces general confidence in open source. Let's all just agree to do our best to be fair to everybody and to respect the intentions and contributions of all the developers. JBoss depends a lot on Apache subprojects and should recognize that and be flexible. Apache and Geronimo, if they want to use some JBoss code (which is not to allege that they did) should do it openly and with agreement from JBoss Group.

    OK. Now everybody hug and kiss -- and remember: we love you.
  110. Apache's rummored answer:[ Go to top ]

    Com Soft wrote:
    > Here is a what an Apache answer is rumored to be so far:
    >
    > Some background rumor context, to give appropriate level of credibility:
    > jBoss was trying to get a J2EE certification, which would be a problem for the commercial J2EE vendors, as in why pay $,… when you can have better for free/cheap, so one possibility is that Sun used it’s “control” of ASF to … go after them ... legally. How do I know this? National Enquirer magazine had it next to "the Aliens Invade, led by Elvis". It just makes sense.
    >
    > So we have:
    > http://elba.sourceforge.net
    >
    > The “joint” plan above supported by ASF, is to *copy the design* and re-implement that design, in essence refactor it, taking advantage of some jBoss OSS developer discontent.
    >
    > I am not sure if jBoss patented the design. ASF I guess feels that there is no legal precedents on copying a design. So ASF would take jBoss trough the legal system (I said legal system, not justice system).
    >
    > The ASF response would be… Yes, it is our intention to take jBoss code, and refactor it module by module. if you show us duplicate code, we will refactor it, to make it harder for you to prove it a * legal * problem, because there is a lot of gray area * legally *.
    >
    > The ASF gave the jBoss letter to Geronimo developers, the same people that wrote this on sf.net:
    > “
    > Think of Elba as a latticework for Geronimo--and as a shield to buffer the Geronimo codebase …. As Geronimo is built, its code will replace the code from Elba, bit by bit until there's nothing left in Elba at all. ...
    >
    > Will code from Elba be used in Geronimo?
    >
    > Don't worry--this is not a big deal, as the goal is to have this project quickly die as features are added to Geronimo.”
    >
    > So one can see that this is the plan all along, rob jBoss!
    > Are you still reading this crap? OK:
    >
    > So the plan is proceeding and ASF is digging in. The likely the response will be from Geroniomo developers to jBoss… "show us the code, and we will refactor it." And I dare you to take us to court, this is legal for us to do, we have a loophole.
    >
    > More?
    > ASF used to be “code you can use at work”.
    > In the end… Open Source Developers will NOW have to _ expunge _ references to open source software in their resumes. What company is suicidal to hire an OS developer?
    > Yes, at day time I design and you pay me, at night I refactor and put in Open Source (or wrose things) so that companie’s competitors can use it.
    >
    > Appache would then be “code you refactor from work”, something many have suspected.
    >
    > The work for hire contract means nothing, it’s a re-implementation, you see.
    >
    > You can take any jar file, de-compile, refactor… and it’s yours! Ah.. the possibilities. Let’s see, what is the first project I will “re-implenet via a latticework”.
    >
    > OS developers even steal from other OS projects, let alone commercial.
    > A clean resume should only have references to commercial software, you can’t have Apache, you should have IIS, and no Tomcat, put iPlanet, remove Linux/ put Solaris, less you be a suspect of… "hey, you are one of those people that takes the design and refactor".

    Com Soft, I think that your conspiracy theory is very close to the truth. BUT, I do not think that the Apache Foundation is behind it. The real people behind this disgusting display of lack of integrity is the Core Developers Network as they are the ones behind the Elba fork. Apache.org has put out so much good software over the years with integrity and quality that I refuse to believe that they are behind any of this.

    Hans
  111. Apache's rummored answer:[ Go to top ]

    I agree with Hans Helmut. I found the "Integrity" mantra from Core Developers Network a little laughable, considering they must have been planning to screw their colleagues at JBoss for at least six months (domain registration and JavaOne booth planning time) before they announced their separate venture. The probable personality conflicts and disagreement over business model that led them to go their own separate way seem pretty understandable--the way they went about it made them look every bit as immature as the JBoss Group lot, if not more due to the added distinction of being buddyfuckers. This incident makes them look even more like damaged goods.
  112. Apache's rummored answer:[ Go to top ]

    Enough with the finger pointing and conspiracies.

    JBoss Group did the right thing to highlight possible misappropriation of their work.

    ASF / Geronimo group will do the right thing to make sure they do not misappropriate.

    Forget the personal squabbles; of course they exist, but that's not any of our business.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  113. Apache's rummored answer:[ Go to top ]

    Enough with the finger pointing and conspiracies.

    >
    > JBoss Group did the right thing to highlight possible misappropriation of their work.
    >
    > ASF / Geronimo group will do the right thing to make sure they do not misappropriate.
    >
    > Forget the personal squabbles; of course they exist, but that's not any of our business.
    >
    > Peace,
    >
    > Cameron Purdy
    > Tangosol, Inc.
    > Coherence: Clustered JCache for Grid Computing!

    In my opinion, what I was getting at is that there must be somebody held accountable for such actions if they in fact did happen. To hold somebody accountable you must point a finger. As I said, I do not believe ASF or JBG should be held accountable for these actions but rather the CDN folks.

    Hans
  114. Who gives a Fork?[ Go to top ]

    I just don't get why all the fuss about Elba?

    The whole idea of Open Source make it possible to fork code in situations
    that require it. Agreed it is not the healthiest thing that can happen to
    a project, but then neither is pissing off a significant number of
    contributors.

    You should be glad that forks like Elba can be created as it shows
    that an OS code base can survive scisms in it's community - even
    if there are trademarc restrictions.

    Elba also shows us that an OS project is more than just code - it is
    a community. Elba has no community and is a dead project.
    This is due to the great community that has rapidly grown around
    geronimo, making amazing progress which has removed the need
    to use Elba as a base for ongoing OS J2EE development.

    If progress had been slower, Elba may have been used to allow
    provide a platform for continued OS J2EE development outside
    of JBoss. This is called standing on the shoulders of giants,
    and this is a good thing! Open Source is meant to allow others
    to use the code to build bigger better things with. There is no
    problem, so long as the license and IP are respected.

    JBoss also has an active community and I'm glad that their commercial
    guardian shows concerned about their intellectual property and will
    take action to protect it.
  115. Who gives a Fork?[ Go to top ]

    I just don't get why all the fuss about Elba?

    >
    > The whole idea of Open Source make it possible to fork code in situations
    > that require it. Agreed it is not the healthiest thing that can happen to
    > a project, but then neither is pissing off a significant number of
    > contributors.
    >
    > You should be glad that forks like Elba can be created as it shows
    > that an OS code base can survive scisms in it's community - even
    > if there are trademarc restrictions.
    >
    > Elba also shows us that an OS project is more than just code - it is
    > a community. Elba has no community and is a dead project.
    > This is due to the great community that has rapidly grown around
    > geronimo, making amazing progress which has removed the need
    > to use Elba as a base for ongoing OS J2EE development.
    >
    > If progress had been slower, Elba may have been used to allow
    > provide a platform for continued OS J2EE development outside
    > of JBoss. This is called standing on the shoulders of giants,
    > and this is a good thing! Open Source is meant to allow others
    > to use the code to build bigger better things with. There is no
    > problem, so long as the license and IP are respected.
    >
    > JBoss also has an active community and I'm glad that their commercial
    > guardian shows concerned about their intellectual property and will
    > take action to protect it.

    Forking is perfectly fine and sometimes desirable. Sharing and copying code between open source projects is fine and dandy. So is "standing on the shoulders of giants". But changing the license from LGPL to Apache is not. Deriving from LGPL code and putting it under ASL is NOT FINE and disrespects the wishes of those who wish to publish under LGPL. The FSF licenses were designed to ensure that code written for open source remains open source while the ASL licenses do not. Many OSS developers are religious about their licenses and I hope you respect it.

    All and all please stop the bullshit and answer the allegations. Specifically

    - The legal letter points
    - The emails on geronimo mailing lists stating the attention to merge parts of JBoss code into Geronimo
    - The unclear relationship and intentions of the Elba project stated prominently on the Elba web pages
    - The additional posting of Bill Burke on this forum. I would especially like to receive explanation of the Dain Sundstrum CVS comment with JBoss CVS posted above as this is a direct admitance by one of your esteemed colleagues of derivative work.
    - The suspicious removal of any mention of Elba from the Geronimo Apache Incubator page (remember the FAQ "What is Elba?")

    The behavior of you CDN folks from the beginning has smacked of a lack of integrity. It is sad that your apparent jealousy and contempt for Mr. Fleury and the JBoss Group has tainted the image of the Apache Foundation. Shame on you! Come clean. State your real intentions like:

    - You could not steal, or gain business from your split with JBoss Group so you...

    - Decided to fork JBoss with the ELba project...You realized that brand was king (a la your stoog Mr. Rupp in his brand is king article) so you...

    - Decided to ride the coat tails of the Apache brand to build your business and create Geronimo, but....

    - you realized that it would take to long so you decided to rip off JBoss by creating a derivative work, but...

    - found out that Apache doesn't allow (L)GPL code so....

    - You decided to be real careful as you could....Sneaky Sneaky...

    Integrity my ass.

    Hans

    P.S. I can't believe I just wrote this as I rarely get very upset about anything. I admit I am a bit biased...But I have watched the soap opera from the beginning. Mainly because it has been quite entertaining and really hasn't hurt anybody, but when your actions tarnish the name of Apache, it really machs me angry.
  116. Who gives a Fork?[ Go to top ]

    <Quote>
    The suspicious removal of any mention of Elba from the Geronimo Apache Incubator page </Quote>

    The mention of Elba or the project Incubator page was not removed intentionally but accidentally during a upgradation of the main incubator website.It happened to the other incubator projects like FTPServer,altRmi and so on.It has got nothing to do with these allegations.
  117. "disgusting display of lack of integrity "[ Go to top ]

    Hans said:>
    > The real people behind this disgusting display of lack of integrity is ...
    >


    http://marc.theaimsgroup.com/?l=geronimo-dev&m=106873140521473&w=2

    Above Gier of ASF says today: "commited not his own IP but a "derivative work" of IP already owned by JBOSS commiters, and thus already covered by the LGPL, and that therefore this file should indeed be licenced under the LGPL "


    http://marc.theaimsgroup.com/?l=geronimo-dev&m=106875482022176&w=2

    Above Jim of ASF says today:
    "I'm not sure, but I think even having it in the Attic is still not sufficient.
    ...
    It also must be deleted from mail archives, if it was ever there."
    Oops. This archive is not on ASF.

    What else:
    Elba.sf.net used to say (and you can still see this in cache on Google or Yahoo:
    "Think of Elba (jBoss code) 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."
    What does this mean to you? What does it say tonight? Well, you can just go to
    elba.sf.net, the text is gone.

    "If there is a precedent that Apache open source developers are capable or inclined to use a legal loophole, and that they could/would refractor a design of a client’s application, it would make it harder for ALL of us in the open source community to get gigs."

    +1
  118. Exhibits A & B[ Go to top ]

    The following is an excerpt by Ceki Gülcü at http://www.qos.ch/logging/jboss.html

    (begin transcript)

    "Comments on JBoss' claims against the ASF
    by Ceki Gülcü, November 12th 2003
    The text below is my personal opinion on the allegation leveled by JBoss LLC against the Apache Software Foundation. I am not an officer of the ASF. The opinons expressed here represent my personal views on the matter.

    "On October 31st, 2003, an attorney representing JBoss LLC has sent a letter to the Apache Software foundation.

    "As the founder of the log4j project, I have been involved with log4j since 1999. Given that certain parts of JBoss claims against the Geronimo project of the Apache Software Foundation (ASF) are related to log4j, I decided to have a closer look at the charges leveled against the ASF.

    "It is very clear to me that the source code that the JBoss group claims as its own, is actually based on source code developed within the log4j project. Thus, in my opinion, the ASF has intellectual property rights on the source code mentioned in Exhibits A and B of the said letter.

    "Regarding Exhibit A: XLevel
    XLevel stands for eXtended Level. The XLevel class, which I wrote, is intended as an example of how to extend existing log4j levels. I did not want to name the class ExtendedLevel because that seemed too long.

    "The capability to customize core log4j classes, in particular the Priority class, has existed for a long time.
    ==================
    "Version 1.0.4 of log4j, a copy of which is readily obtainable was released on January 12th, 2001. This release contained the following file

    jakarta-log4j-1.0.4/org/apache/log4j/xml/examples/XPriority.java

    "On September 2nd 2001, the Level class replaced Priority class. The Priority class was kept around for compatibility reasons. It still exists today (as of 2003-11-12). As such, the XPriority class was appropriately renamed as XLevel. This was done on September 2nd, 2001, as attested by the records of the log4j source code repository.

    "I now list further evidence demonstrating that the code base in dispute originates from the log4j project.

    "org.apache.log4j.xml.test.TPriority earliest version dated December 14, 2000
    org.apache.log4j.xml.examples.XPriority earliest version dated December 14, 2000
    org.apache.log4j.xml.examples.XLevel earliest version dated September 2, 2001

    "Please note that these classes are part of a whole. They integrate with various other classes, such as XCategory and XLogger. They are part of test suites testing their functionality. Only the original author would go to the pain of writing test suites to check the correctness of his code.

    "Please note that the TPriority class which stands for TestPriority is a cut-and-paste copy of XPriority. The same code was duplicated in org.apache.log4j.xml.test because I did not want to have test cases depend on code intended as examples.

    "In contrast, and as far as I can tell, the earliest mention of a subclass of Priority or Level in JBoss code dates to June 20th 2001 as attested by the JBoss source code repository.

    "org.jboss.logging.log4j.TracePriority earliest version dated June 20, 2001
    org.jboss.logging.XPriority earliest version dated Feb 24, 2002
    org.jboss.logging.XLevel earliest version dated May 23, 2002

    "In summary, the source code incriminated by Exhibit A existed at the Apache Software Foundation at least 6 months before it made its first appearance at JBoss. Thus, in relation to this exhibit, I cannot see how JBoss LLC has any valid claims against the ASF for this particular code. In fact, it appears that by neglecting to attribute the code and follow the Apache License for this example, the violation of copyright would be the exact reverse.

    "Regarding Exhibit B: PatternParser
    The case for Exhibit B is similar. Customizations of PatternLayout via PatternParser extensions has been available for several years in log4j code.

    "The initial contribution allowing the extension of PatternLayout behavior was made by Anders Kristensen on 2000-08-27. Anders was granted committer access for this contribution. This extension was documented by Paul Glezen on January 2001. The description of the AppServerPatternParser.java class in the same document is particularly relevant. As further evidence, the file AppServerPatternParser.java is part of log4j version 1.1.3 released on June 19, 2001. Moreover, records of the log4j source code repository also attest for the existence of PatternParser extension on December 14th, 2000.

    "The PatternParserEx class, cited in Mr. David J. Byer's letter to the ASF, very closely follows the pattern established MyPatternParser and AppServerPatternParser classes. The earliest record of this class in Jboss source code repository dates to September 15th, 2002. Unless JBoss LLC claims that PatternParserEx predates MyPatternParser or AppServerPatternParser classes found in log4j, it looks like the JBoss LLC removed the existing Apache copyright when it based PatternParserEx class on modified versions of PatternParserEx and AppServerPatternParser. This is prohibited by the first clause of the Apache Software License.

    "I hope you find the above convincing. When someone writes as much code as some of the JBoss developers, it is possible to forget the origin of the code. Notwithstanding the great respect and admiration I have for the JBoss project and its developers, I cannot let the name of the ASF to be falsely tarnished, especially if the attacking party is basing its accusation against the ASF on software which originated at ... the ASF. Talk about irony.

    "If any JBoss code is, in fact, in Geronimo, the ASF will without doubt remove it. I equally hope that the JBoss project will also take the time to correctly attribute those sections of JBoss software derived from ASF code.
     
    (end of transcript)
    ==================

    More discussion about this on the Geronimo development mailing list.
    --
    N. Alex Rupp (n_alex_rupp at users dot sf dot net)
  119. Exhibit C[ Go to top ]

    The following is an excerpt by Richard Monson-Haefel, taken from the Geronimo development mailing list.

    (begin transcript)

    Hi,

    I read the posting about JBoss and copyright infringement. I noticed that
    one of the exhibits was the Invocation class. In October of 1999 I created
    and contributed the first version of that class (or one like it) to JBoss
    (at that time EJBoss). Perhaps this will help address that specific
    copyright infringement issue. If its helpful let me know.

    Attached is an e-mail I sent to Marc Flurry back in 1999. I'll forward
    another e-mail right after this one which was sent a few days later. The one
    sent on October 27th (attached to this e-mail) is the original submission of
    MethodInvocation class, the ancestor of the Invocation type. The e-mail
    from November 4, 1999 (see my next posting) is when I resubmitted the class
    with some updates - at this point both Marc and I were working on it.

    A bit of History: This all took place immediately after Rickard Oberg
    proposed the idea of using the invoke( ) style container system in JBoss
    (then EJBoss). It was a very cool idea and is the basis for much of what
    you see in JBoss, OpenEJB and Geronimo today. Anyway, there was a very
    minor flaw in Rickard's proposal. He was passing the index of the method
    across the wire so that it could easily be relocated on the server.
    Unfortunately, this didn't work so well because different VMs will index
    methods in a class differently, so for example: If methodX on ClassB is
    index 8 on your machine, it might be index 13 on my machine. To overcome
    this problem, I came up with the MethodInvocation class which passes the
    name of the method, arguments, and the class type across the network rather
    than the methods index. MethodInvocation also allowed us to pass other
    information like security and transaction contexts and the like. A lot of
    what we were concerned about back them was the efficiency if serialization -
    which is why so much attention is paid to that topic. That aside, however,
    if you examine the source code for MethodInvocation in the first and second
    e-mails (November 4th, 1999) which I'll send next, you'll see a striking
    similarity in purpose and design to modern constructs like the Invocation
    type used in JBoss. That's because MethodInvocation was the basis for the
    Invocation class.

    I won't pretend to understand all the legal things being discussed. To be
    honest it doesn't interest me very much. I think JBoss has every right to
    protect their LGPL code - In fact I think its the right thing for them to
    do. Having said that, however, I don't think every bit of code in JBoss is
    realistically the property of that entity alone - there have been a lot of
    people involved with the JBoss project over the years.

    Richard
    --
    Richard Monson-Haefel
    Co-Founder\Developer, Apache Geronimo
    Author of:
      J2EE Web Services (AW 2003)
      Enterprise JavaBeans, 4ed (O'Reilly 2004)
      Java Message Service (O'Reilly 2000)
    http://www.Monson-Haefel.com

    ------ Forwarded Message
    From: Richard Monson-Haefel
    <Richard dot Monson-Haefel-AF6Uqb0kbJUAvxtiuMwx3w at public dot gmane dot org>
    Reply-To: Richard dot Monson-Haefel-AF6Uqb0kbJUAvxtiuMwx3w at public dot gmane dot org
    Date: Wed, 27 Oct 1999 09:28:57 -0500
    To: Marc Fleury <marc.fleury-fKBx6/CGY7Mdnm+yROfE0A at public dot gmane dot org>
    Subject: MethodInvocation

    Hi Marc,

    I was going to add the MethodInvocation code to the container but the
    ejboss code seems to be in a wild flux right now, so I didn't add it. I
    don't understand the code. Everything is commented out, stuff doesnt
    compile, there is package missing (org.ejboss.server), etc. I only have
    a limited amount of time to contribute (about 2 hours a day) so rather
    then waste time tring to wad through code in transition I'm sending you
    Rickard's test rewritten to leverage the MethodInvocation class. Please
    add it to the ejboss code. I recommend using a java.util.Hashtable as
    the context object as shown below:

    MethodInvocaiton mi = new MethodInvocation(method, args);
    Hashtable methodContext = new Hashtable( );
    methodContext.put("label",someObject);
    methodContext.put("lebel2,someOtherObject);
    mi.setContext(methodContext);

    You could alternatively use any collection or any serializable object
    for the context.

    Obviously the MethodInvocation needs to be assigned to a different
    package and needs to be commented (I plan to do this when you have it in
    place).

    Thanks,

    Richard

    --
    Richard Monson-Haefel
    EJB Expert for jGuru.com
    ( http://www.jguru.com )

    Author of Enterprise JavaBeans
    Published by O'Reilly & Associates
    ( http://www.ejbnow.com )
     
     
    (end of transcript)
    ==================

    More discussion about this on the Geronimo development mailing list.
    --
    N. Alex Rupp (n_alex_rupp at users dot sf dot net)
  120. Exhibit C ( . . . continued)[ Go to top ]

    The following is another excerpt by Richard Monson-Haefel, taken from the Geronimo development mailing list.

    (begin transcript)

    And this too ...

    ------ Forwarded Message
    From: Richard Monson-Haefel
    <Richard-K9gYsmD0wPF070ds/RsdfQC/G2K4zDHf at public dot gmane dot org>
    Reply-To: geronimo-dev-d1GL8uUpDdXTxqt0kkDzDmD2FQJk+8+b at public dot gmane dot org
    Newsgroups: gmane.comp.java.geronimo.devel
    Date: Tue, 11 Nov 2003 22:36:01 -0600
    Subject: I contributed the original version of the Invocation object to
    JBoss: 2nd part

    Here is the second e-mail sent on Novermber 4th, 1999.

    ------ Forwarded Message
    From: Richard Monson-Haefel
    <Richard dot Monson-Haefel-AF6Uqb0kbJUAvxtiuMwx3w at public dot gmane dot org>
    Reply-To: Richard dot Monson-Haefel-AF6Uqb0kbJUAvxtiuMwx3w at public dot gmane dot org
    Date: Thu, 04 Nov 1999 14:07:08 -0600
    To: Marc Fleury <marc.fleury-fKBx6/CGY7Mdnm+yROfE0A at public dot gmane dot org>
    Subject: MethodInvocation

    Hi,

    Just took a look at MethodInvocaiton. I like what you did with the
    invoke method. Its much better that way. Thanks for putting all the
    comments in also.

    I figured out how to lighten the class up so less is cycles are needed
    to realize a method invocation and less data is needed to serialize it.
    The new and improved MethodInvocation is attached for your approval.
    Also I attached a MethodContext class. I think its better to put the
    Principal and TX in a context object then to include it in the
    definition of the MethodInvocation. Please consider removing those
    properties from the MethodInvocaiton and using the MethodContext
    instead.

    I'll be jumping into EJBoss with a huge commitment starting last next
    week (as much as 20 hours in a week). Unfortunately, until then I'm
    busy with other things and can not contribute much.

    Richard

    --
    Richard Monson-Haefel
    EJB Expert for jGuru.com
    ( http://www.jguru.com )

    Author of Enterprise JavaBeans
    Published by O'Reilly & Associates
    ( http://www.ejbnow.com )
     
    (end of transcript)
    ==================

    That takes care of all three accusations from the letter. Bill Burke's concerns are also being addressed on the mailing list. You guys might want to carry on this discussion there, so you can get some more details.

    Hope this helps,
    --
    N. Alex Rupp (n_alex_rupp at users dot sf dot net)
  121. Exhibit C ( . . . continued)[ Go to top ]

    The following is another excerpt by Richard Monson-Haefel, taken from the Geronimo development mailing list.

    >
    > (begin transcript)
    >
    > And this too ...
    >
    > ------ Forwarded Message
    > From: Richard Monson-Haefel
    > <Richard-K9gYsmD0wPF070ds/RsdfQC/G2K4zDHf at public dot gmane dot org>
    > Reply-To: geronimo-dev-d1GL8uUpDdXTxqt0kkDzDmD2FQJk+8+b at public dot gmane dot org
    > Newsgroups: gmane.comp.java.geronimo.devel
    > Date: Tue, 11 Nov 2003 22:36:01 -0600
    > Subject: I contributed the original version of the Invocation object to
    > JBoss: 2nd part
    >
    > Here is the second e-mail sent on Novermber 4th, 1999.
    >
    > ------ Forwarded Message
    > From: Richard Monson-Haefel
    > <Richard dot Monson-Haefel-AF6Uqb0kbJUAvxtiuMwx3w at public dot gmane dot org>
    > Reply-To: Richard dot Monson-Haefel-AF6Uqb0kbJUAvxtiuMwx3w at public dot gmane dot org
    > Date: Thu, 04 Nov 1999 14:07:08 -0600
    > To: Marc Fleury <marc.fleury-fKBx6/CGY7Mdnm+yROfE0A at public dot gmane dot org>
    > Subject: MethodInvocation
    >
    > Hi,
    >
    > Just took a look at MethodInvocaiton. I like what you did with the
    > invoke method. Its much better that way. Thanks for putting all the
    > comments in also.
    >
    > I figured out how to lighten the class up so less is cycles are needed
    > to realize a method invocation and less data is needed to serialize it.
    > The new and improved MethodInvocation is attached for your approval.
    > Also I attached a MethodContext class. I think its better to put the
    > Principal and TX in a context object then to include it in the
    > definition of the MethodInvocation. Please consider removing those
    > properties from the MethodInvocaiton and using the MethodContext
    > instead.
    >
    > I'll be jumping into EJBoss with a huge commitment starting last next
    > week (as much as 20 hours in a week). Unfortunately, until then I'm
    > busy with other things and can not contribute much.
    >
    > Richard
    >
    > --
    > Richard Monson-Haefel
    > EJB Expert for jGuru.com
    > ( http://www.jguru.com )
    >
    > Author of Enterprise JavaBeans
    > Published by O'Reilly & Associates
    > ( http://www.ejbnow.com )
    >
    > (end of transcript)
    > ==================
    >
    > That takes care of all three accusations from the letter. Bill Burke's concerns are also being addressed on the mailing list. You guys might want to carry on this discussion there, so you can get some more details.
    >
    > Hope this helps,
    > --
    > N. Alex Rupp (n_alex_rupp at users dot sf dot net)

    Well, the particular Invocation class in question was totally refactored by Marc Fleury. Marc added three types of payloads to an Invocation, Transient, As Is, and Payload. These three payload types showed up in the Geronimo code. Marc split up the payloads for various technical reasons related to classloading and classloading isolation.

    The fact that RMH was the original author has no relevance here as multiple authors (including myself) contributed significant dramatic changes to this particular class over the years and licensed it under the LGPL license.

    As for Dain's SynchronizationRegistry, IMNSHO, you could interpret this refactoring as a derivative work since a lot of this refactoring he did in the JBoss codebase months ago was work with JBosss, not Geronimo. I actually fixed a few bugs in this class. Is he sure that those did not get in there?

    What about InvocationType, although Dain is the author of this file, his checkin comment clearly states that it is a derivative work from other JBoss code.

    The CVS log on InvocationType states:
    >
    > File: [cvs] / jboss / jboss / src / main / org / jboss / invocation /
    > InvocationType.java (download)
    > Revision: 1.1, Fri Jun 14 01:32:40 2002 UTC (17 months ago) by dsundstrom
    > CVS Tags: JBoss_3_1_0_1
    >
    > Converted Invocation constants into type safe enumerations.
    > Moved all constants used for the invocation setValue method to
    > InvocationKey.
    > Moved the payload identifier constants to PayloadKey.
    > Moved the constants used in setType to InvocationType.
    >
    > Remove lame log message comments.
    > Cleaned up some code formatting.
    >

    Clearly states a refactoring from other JBoss code.

    Invocation, InvocationType, GlobalTxMap, TxEntityMap are all core functions of the JBoss invocation flow and entity bean architecture. We haven't even talked yet about the Deployment stuff within Geronimo/JBoss.

    The exhibits in the legal letter were chosen because of their close relationship to copyright violation.

    So the question remains, what constitutes a derivative work?

    All and all, I strongly stand by our decision to request the ASF to research copyright and LGPL infringements. Base on similar code, coding structure, files with exact names, comments in JBoss CVS(all this with only 2 hours of research on my part), emails on the Geronimo mailing list stating Geronimo developers are merging JBoss code, and the unclear purpose of the Elba project, we are perfectly in our rights to question the Geronimo project. We tried to question ASF privately, through private channels, but unfortunately this has been brought to the public eye. We are not suing ASF, merely just officially voicing our concerns.

    Bill
  122. Farce![ Go to top ]

    Well, I've broken my self-imposed silence here because this is just gotten too ridiculous. Mr. Burke, here's Geronimo Invocation.java:

       public interface Invocation {

           Object get(InvocationKey key);
           void put(InvocationKey key, Object value);
        
       }

    Here's JBoss original Invocation.java, with comments stripped for clarity:

      public class Invocation
      {
       public Transaction tx;

       public Principal identity;

       public Object credential;

       public String[] mbeans;

       public Map payload;

       [MWS - etc etc etc removed because its pointless ]
      }

    As anyone with eyes can see, the current Geronimo Invocation is completely different from JBoss Invocation. If we go way back into the Geronimo attic,
    we can see:

      public interface Invocation {
          Object getMarshal(Object key);

          void putMarshal(Object key, Object value);

          Object getAsIs(Object key);

          void putAsIs(Object key, Object value);

          Object getTransient(Object key);

         void putTransient(Object key, Object value);
      }

    The above bears little relationship to the JBoss one as well - and for added measure, it was removed over 60 days ago. The newer slimmed down Geronimo version CVS comment says:

        Thu Aug 28 04:12:10 2003 UTC (2 months, 2 weeks ago) by chirino

    So any slight similarities were nuked around 74 days or so ago.

    ........

    On SynchronizationRegistry, Dain has commented on and addressed this on the Geronimo dev mailing list in detail.

    ........

    On InvocationType, Geronimo developers have already commented that the code
    matches the J2EE spec - due to the spec there's no other sane way to do it.

    ........

    JBossers in general - I don't know if you guys are comparing ancient source that
    was long ago changed, and so you're beating on subjects that were closed long ago; or if your mind has blocked out code that was copied from
    j2ee books and specs and ASF sources (and hence isn't owned by JBoss); or if
    you're having eye problems and can't see how different a 4 line interface is in Geronimo compared to a giant class in JBoss; or if you just like generating FUD.

    Or C), all of the above. I don't know what the intent behind this really is,
    but in the end Geronimo is coming out as quite professional about all this, and
    incidentally not in violation of any copyrights. And JBoss is coming out as being just plain wrong on every count I've seen mentioned so far.

    Please Mr. Burke - Please tell us that you have something more than code ripped off from Log4J. Please show us code that a non-Geronimo person owns the copyright for which has made it into Geronimo. So far, all of you accusations have boiled down to a) the Geronimo code looks nothing like the JBoss code, or b) the code in question is copyrighted by a Geronimo author, or c) the code in question was originally licensed under the ASF license.

        -Mike
  123. Farce![ Go to top ]

    Well, I've broken my self-imposed silence here because this is just gotten too ridiculous. Mr. Burke, here's Geronimo Invocation.java:

    >
    > public interface Invocation {
    >
    > Object get(InvocationKey key);
    > void put(InvocationKey key, Object value);
    >
    > }
    >
    > Here's JBoss original Invocation.java, with comments stripped for clarity:
    >
    > public class Invocation
    > {
    > public Transaction tx;
    >
    > public Principal identity;
    >
    > public Object credential;
    >
    > public String[] mbeans;
    >
    > public Map payload;
    >
    > [MWS - etc etc etc removed because its pointless ]
    > }
    >
    > As anyone with eyes can see, the current Geronimo Invocation is completely different from JBoss Invocation. If we go way back into the Geronimo attic,
    > we can see:
    >
    > public interface Invocation {
    > Object getMarshal(Object key);
    >
    > void putMarshal(Object key, Object value);
    >
    > Object getAsIs(Object key);
    >
    > void putAsIs(Object key, Object value);
    >
    > Object getTransient(Object key);
    >
    > void putTransient(Object key, Object value);
    > }
    >
    > The above bears little relationship to the JBoss one as well - and for added measure, it was removed over 60 days ago. The newer slimmed down Geronimo version CVS comment says:
    >
    > Thu Aug 28 04:12:10 2003 UTC (2 months, 2 weeks ago) by chirino
    >
    > So any slight similarities were nuked around 74 days or so ago.
    >
    > ........
    >
    > On SynchronizationRegistry, Dain has commented on and addressed this on the Geronimo dev mailing list in detail.
    >
    > ........
    >
    > On InvocationType, Geronimo developers have already commented that the code
    > matches the J2EE spec - due to the spec there's no other sane way to do it.
    >
    > ........
    >
    > JBossers in general - I don't know if you guys are comparing ancient source that
    > was long ago changed, and so you're beating on subjects that were closed long ago; or if your mind has blocked out code that was copied from
    > j2ee books and specs and ASF sources (and hence isn't owned by JBoss); or if
    > you're having eye problems and can't see how different a 4 line interface is in Geronimo compared to a giant class in JBoss; or if you just like generating FUD.
    >
    > Or C), all of the above. I don't know what the intent behind this really is,
    > but in the end Geronimo is coming out as quite professional about all this, and
    > incidentally not in violation of any copyrights. And JBoss is coming out as being just plain wrong on every count I've seen mentioned so far.
    >
    > Please Mr. Burke - Please tell us that you have something more than code ripped off from Log4J. Please show us code that a non-Geronimo person owns the copyright for which has made it into Geronimo. So far, all of you accusations have boiled down to a) the Geronimo code looks nothing like the JBoss code, or b) the code in question is copyrighted by a Geronimo author, or c) the code in question was originally licensed under the ASF license.
    >
    > -Mike


    I think the problem here is that we have two different interpretations of what is derivative work. Does refactor == derivative work? JBoss seems to think so. ASF seems to not. It is clear to me that given these accusations as a whole, the whole picture, that parts of Geronimo are a refactor of JBoss. Does this mean that refactor is the same as derivative? I do not know. In my opinion, even though the Geronimo Invocation object has been rewritten, there is clear evidence and history of derivation with both JBoss and Geronimo CVS's.

    This is end of discussion for me. Good luck all in resolving your differences!

    Best wishes,


    Hans Helmut
  124. Farce![ Go to top ]

    \Hans Helmut\
    I think the problem here is that we have two different interpretations of what is derivative work. Does refactor == derivative work?
    \Hans Helmut\

    IANAL, but some things are pretty to understand and basic with regards to
    copyright. Fundamentally, you can't copyright ideas, only concrete expressions
    of ideas. E.g. you can't copyright love, or hate, or yearning for the cowboys
    of yesteryear, but you can copyright the lyrics and music for songs about these
    ideas.

    With code, it's the same. You can't copyright a design or an architecture.
    At best, you can only copyright your artifacts - the text of design documents,
    the source code, specific graphics.

    So, to start, you have to look at the specific source code - forget about ideas and "my design is based on..." crap. All that matters to copyright is the code and other concrete artifacts. So, you look at chunks of code, and you say:

       1) who owns this code? Who's the copyright holder. This right here blows many of JBoss' arguments away - in some cases they're bitching about code whose copyright is held by the Geronimo developers. And, sorry, but adding an "@author" tag and checking it into CVS does not revoke the original author's copyright. If you copied the code from Log4j, or from a book, or from a published spec - sorry, you don't own the copyright.

       2) Second, if you actually hold the copyright, and find code that looks similar, you have to determine just how similar. This is where it can get murky
    : just how similar is it? :-)

       3) If you don't own the copyright, you really have no business bitching about potential misuse. _The code isn't yours_, so you have no rights that aren't granted by the copyright holder.

       4) If two or more people make substantial mods to a given source file, things get really murky indeed. Do they all own it? Do they own only their own piece? Are they all considered "derived works" of the original author (and hence the original author holds sway)? I don't know.

    Many of JBoss' arguments disolve because of #1 and #3 above - the code wasn't
    originally "theirs", it's owned by a Geronimo person, or a log4j person, or a
    book author, or the like. In the very few cases presented that pass #1 and #3,
    #2 hasn't applied because the code isn't even close to being similar. I'm sorry, but the 4-line Invocation.java looks nothing like the JBoss equivalent. Refactoring is a red herring here - no one is ever going to look at the 4 line interface and say it was derived from the big Jboss class.

    For #4, as I said, I don't know. So far, from where I sit I don't see where
    JBoss has presented any evidence where it applies. They've tried - but so far those attempts have been shot down by #1, #2, and #3 - e.g. the code wasn't owned by JBoss people, or the code in fact looks nothing like the JBoss code.

    In summary, using a word like "Refactor" just confuses the arguments and doesn't
    help resolve anything.

        -Mike
  125. Farce![ Go to top ]

       4) If two or more people make substantial mods to a given source file,

    > things get really murky indeed. Do they all own it? Do they own only
    > their own piece? Are they all considered "derived works" of the original
    > author (and hence the original author holds sway)? I don't know.

    #4 should be clear. No matter how much refactoring I do on Linux kernel, it still does not allow me to claim ownership on those pieces of kernel code and change the license on it. The fact that I am refactoring means I'm working with an existing codebase which in turn means I'm under the original authors granted license.

    It seems pretty clear with these examples here that there's quite a few pieces of code that ended up in Geronimo that are mere refactorings, they were originally created from a codebase that someone else was working on. Therefore it is not only the person who last refactored the code that has a say to how to use it but should require the permission from the original authors as well.

    This means that the bare minimum geronimo developers should have done is ask permission to "refactor" JBoss code into their codebase. The fact is that their codebase would NOT look the way it does today had they not spent so much time working with JBoss code base.

    And I don't buy for a second the claims that their work was so isolated that they never at any point benefitted on someone else's code or contribution in an LGPL'd codebase.

    From ASF I would hope to see something more conclusive presented as an argument that the geronimo developers are not just copying JBoss sources. Show that a similar classes or implementations exists SOMEWHERE ELSE apart from JBoss. At the moment, it seems a claim from a random developer stating they didn't do something is being taken as "proof". It is not very convincing counter-argument.
  126. Farce![ Go to top ]

    \C R\
    It seems pretty clear with these examples here that there's quite a few pieces of code that ended up in Geronimo that are mere refactorings, they were originally created from a codebase that someone else was working on.
    \C R\

    OK then - provide examples, and if in fact you find infringing examples the Geronimo folks will undoubtedly promptly remove them. You do have actual
    examples where Geronimo people took code from a copyright holder without their permission - right? Right?

    \C R\
    The fact is that their codebase would NOT look the way it does today had they not spent so much time working with JBoss code base.
    \C R\

    You can't copyright ideas, patterns, or thoughts. Only the code.

    Incidentally - have you actually compared the two code bases? I have, and the
    majority of similiarities I've found have been very superficial. The few that run deeper is code that's owned by Geronimo people, or other ASF people, or has been published before being used in JBoss.

    \C R\
    And I don't buy for a second the claims that their work was so isolated that they never at any point benefitted on someone else's code or contribution in an LGPL'd codebase.
    \C R\

    No one's claimed that.

    \C R\
    From ASF I would hope to see something more conclusive presented as an argument that the geronimo developers are not just copying JBoss sources. Show that a similar classes or implementations exists SOMEWHERE ELSE apart from JBoss. At the moment, it seems a claim from a random developer stating they didn't do something is being taken as "proof". It is not very convincing counter-argument.
    \C R\
    Read the Geronimo developer's mailing list. They have extensively documented the geneaology of the code in question. In fact, their research is much, much more in-depth than that provided by either JBoss in general, or Bill Burke specifically. They've referenced the specific books code came from, found the original authors from CVS commits (as opposed to code comments), with extensive tracking of the CVS history. They've referenced specific ASF code which got copied into JBoss - and hence isn't owned by any JBoss person. In short, they
    have shown in great detail exactly what you asked for above.

        -Mike
  127. Farce![ Go to top ]

    Read the Geronimo developer's mailing list. They have extensively documented

    > the geneaology of the code in question.

    No they haven't. The Synchronization example for instance, there's one developer claiming he spent a week "researching" the matter and then came up with a new solution. It's obvious from the CVS log that what he was researching was JBoss source code. And his implementation still looks much like the original one -- he even has the same line of source comment there!

    In the end, to quote the FSF website, it is a judge who decides what "derivation" means. Therefore I would hope the ASF would step up the plate and actually show this is not derivation. I don't much want to find myself in legal hot-water years later over some issues just because ASF took some developer's claim at face-value and never bothered to verify the claims!

    So if this indeed is not derivative work, show how that same code existed somewhere outside JBoss prior.

    > have you actually compared the two code bases? I have

    And I'm supposed to take a word from some wanna-be developer as a fact on this. Great.

    My 2 cents.
  128. Farce![ Go to top ]

    \C R\
    No they haven't. The Synchronization example for instance, there's one developer claiming he spent a week "researching" the matter and then came up with a new solution. It's obvious from the CVS log that what he was researching was JBoss source code. And his implementation still looks much like the original one -- he even has the same line of source comment there!
    \C R\

    Here's what the author, Dain Sundstrom, had to say on the list:

    /Dain Sundstrom/
    The key word in the commit message is "functionality", not "merge".
    This was a completely new algorithm and implementation for handling
    synchronization of entity beans with the backend datastore. All
    previous synchronization implementations in JBoss (of which there were
    at least 2) had been plagued by various subtle problems. The new
    system used a completely different scheme which divides entities into
    dirty and clean sets but keeps record of the entities in the invocation
    stack. It did take me almost a week to figure out the rules for
    determining which entities are dirty and this work reflects that
    research.
    /Dain Sundstrom/

    That's his position - he wrote the code, it's original, it's his.

    For your comment "It's obvious from the CVS log that what he was researching was JBoss source code." - that _does not matter_. We are not talking about
    clean room implementations or trade secrets here, we're talking copyright.
    ASF people can read all the GPL code they want - even write GPL if they feel like it. And they can write original ASF code after doing that. Merely reading GPL stuff doesn't "taint" you, which is what you appear to be implying.

    \C R\
    In the end, to quote the FSF website, it is a judge who decides what "derivation" means. Therefore I would hope the ASF would step up the plate and actually show this is not derivation. I don't much want to find myself in legal hot-water years later over some issues just because ASF took some developer's claim at face-value and never bothered to verify the claims!
    \C R\

    The ASF is going to extraordinary effort to ensure the Geronimo code base is clean. But, ultimately, it's the copyright holder who would have to lodge an
    actual complaint. So, CR - who is the copyright holder on the Synchronization stuff? From my view of looking through the codes in question, and the evidence presented, that copyright holder sure looks like Dain to me. If Fleury or Burke want to dispute this, then they have an ownership dispute, and I have a feeling Sundstrom would win that particular sqabble hands down based on the
    evidence.

    \C R\
    So if this indeed is not derivative work, show how that same code existed somewhere outside JBoss prior.
    \C R\

    You have quite backwards in this instance. The original author of the code
    (not the ideas, the code) has to show that they wrote it. Then they have to show that someone took it and violated their license. Dain claims to own it - if JBoss people disagree, they have to prove that they're the copyright holders.


    > have you actually compared the two code bases? I have
    \C R\
    And I'm supposed to take a word from some wanna-be developer as a fact on this. Great.
    \C R\

    Ah - does this mean that, in fact, you haven't looked at the two codebases?

        -Mike
  129. Exhibit C ( . . . continued)[ Go to top ]

    Bill Burke wrote:
    > All and all, I strongly stand by our decision to request the ASF to
    > research copyright and LGPL infringements. Base on similar code,
    > coding structure, files with exact names, comments in JBoss CVS
    > (all this with only 2 hours of research on my part), emails on the
    > Geronimo mailing list stating Geronimo developers are merging JBoss
    > code, and the unclear purpose of the Elba project, we are perfectly
    > in our rights to question the Geronimo project. We tried to question
    > ASF privately, through private channels, but unfortunately this has
    > been brought to the public eye. We are not suing ASF, merely just
    > officially voicing our concerns.

    Bill,

    Good answer. I am continuosly impressed by your ability to provide concise and professional answers to these questions. One could only hope everyone had the same trait and the Spille's and other trolls of the world would restrain themselves to their private (useless) blogs.

    It is clear why your contributions to the Open Source J2EE are important and worthwhile -- while some others on this forum can make their name only by excessive trolling and bad-mouthing and contributing nothing of use back to the community.

    Thank you for your work on JBoss.
  130. Com Soft :

    > Hans said:>
    > > The real people behind this disgusting display of lack of integrity is ...
    > >
    >
    >
    > http://marc.theaimsgroup.com/?l=geronimo-dev&m=106873140521473&w=2
    >
    > Above Gier of ASF says today: "commited not his own IP but a "derivative work" of IP already owned by JBOSS commiters, and thus already covered by the LGPL, and that therefore this file should indeed be licenced under the LGPL "
    >

    That's not what I said. If you could figure out how to read an attributed response, you would see that I said

      "Dain contributed the same code to Geronimo that he contributed to JBoss."

    If you looked at what Danny was quoting http://marc.theaimsgroup.com/?l=geronimo-dev&m=106872723316884&w=2 I then go on to say

    "The only difference between his JBoss contributions, for which he has
    complete rights to contribute and relicense elsehwere, is that he
    changed the Geronimo implementation to use an array of rather than an
    ArrayList to hold the InvocationType objects, and a static final int
    'constant' to keep the size of that array rather than a static int
    field."
     
    Go look at the code. I traced though all versions to find the any copyrighted code or intellectual property violations, and that was my conclusion. I invite everyone to watch the traffic on the geronimo-dev list - we are taking the JBoss Group LLCs claims very seriously, and going through each claim independently.

    With regard to what Danny was talking about, "This functionality was merged from GlobalTxMap, TxEntityMap, and EntitySynchronizationInterceptor", if you read the thread you will see the response from Dain saying that the remark in that commit was mis-interpreted - that his commit was merged functionality, not merged code from somewhere else.

    Please, read the threads and follow what we're doing. This is serious stuff.
  131. Ceki Gülcü of log4j replies[ Go to top ]

    Ceki Gülcü(Founder of log4j) discusses about the validity of the exhibits A & B
    submitted by JBOSS LLC,at http://apache.org/~ceki/jboss.html
  132. Apache should modify it's license[ Go to top ]

    They should have a banned list of projects and companies (such as JBoss) just the way most licenses have a banned list of countries.
    That would make it even.
  133. Billy laughs himself to death[ Go to top ]

    What a great idea: Two Open Source communities beating each other...

    No better way to proof what Microsoft always said: "Open Source is no serious business model for software development!"

    Stop this!
  134. Billy laughs himself to death[ Go to top ]

    What a great idea: Two Open Source communities beating each other...

    >
    > No better way to proof what Microsoft always said: "Open Source is no serious business model for software development!"
    >
    > Stop this!

    The ASF has no business model. It's a 501(c)(3) non-profit. The foundation doesn't make any money from the projects that it supports, and exists entirely on donations to cover it's small operating costs. There are no paid employees - we are all volunteers. Go read about the ASF :

    http://www.apache.org/foundation/

    The code is there for you to use - take it and build a business around it. Our license won't prevent that - actually, the license is carefully designed to be pro-business. Take the code and change it. Keep the changes to yourself or contribute them back to the project. It's entirely up to you.

    Many people *do* create a business model around open source software via consulting or providing support. From independent consultants to larger companies, such as Red Hat and Covalent. JBoss Group LLC is one example of an orgainzation doing that, building a business on the code base contributed by others. And I think that's great.

    This is what scares the willies out of MSFT, and drives their FUD.
  135. Read art 3 of LGPL[ Go to top ]

    Please everyone would you please read the art 3 of the LGPL it states that code that is entered as code under said license cannot be relicensed except under GPL..

    We can debate how much code copying there is all day long..but last time I checked JBOss code is LGPL and ASF code is not..

    this is the crux of the issue before us.. and by statments from the project leads of Gerinimo during the launch of said proejct implies they knew about this issue and had enacted actions to take JBoss code out of Gerinimo based on reading article 3 of the LGPL..

    and from what I read in the LGPL I see no other article that disuptes article 3..
  136. Read art 3 of LGPL[ Go to top ]

    Stop reading the LGPL license, and start reading copyright law. In case you were not aware, the license applies to the user of the code, not the author.

    You might also note that several open source projects have changed their license from (L)GPL to something loser (like Apache or BSD) without difficulty.

        -Mike
  137. I agree with Bill & Marc[ Go to top ]

    Hi All,

    I totally agree with Bill and Marc. We all have to respect their worry in this regard. When you got an Open Source, using it for good boosts the development of open sources more and more. If people started copying and claim that it is belongs to them, it is a kind of setback to source and discourage in further development.

    regards
    Babu