I think that puts this one to bed.

Thanks

On Thursday, November 13, 2003, at 12:03 PM, Dain Sundstrom wrote:

On Thursday, November 13, 2003, at 07:24 AM, Geir Magnusson Jr. wrote:

Be cautious about this assumption as according to
http://theserverside.com/home/thread.jsp?thread_id=22337#101159
and
http://cvs.sourceforge.net/viewcvs.py/*checkout*/jboss/jboss/src/ main/org/jboss/ejb/entity/Attic/EntityInvocationRegistry.java
the commit log for the initial import is


"Tracks the entities and contexts associated with a transaction. This
functionality was merged from GlobalTxMap, TxEntityMap, and
EntitySynchronizationInterceptor."


Which to my mind suggests that at best Dain 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 unless Dain was the sole author of all of the code from
which this was merged, or unless the it is apparent that the "merge" was a
new work which merged the ideas, but not the code itself.



My conclusion was only analyzing the file mentioned in the specific claim. Do we start a new thread for this ?

(Yes, moved to new thread)

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. I do believe that the code represents the only way to determine dirty entities (short of byte code engineering) but there are many ways that idea could be realized.

In the end, the commit message was simply notice to the other developers that the reason I was deleting those critical files was that they were no longer needed (and a kick for them to go take a look at the new code).

-dain


--
Geir Magnusson Jr                                   203-247-1713(m)
[EMAIL PROTECTED]



Reply via email to