geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevan Miller <kevan.mil...@gmail.com>
Subject Re: svn commit: r618102 - /geronimo/server/branches/2.1/plugins/clustering/wadi-clustering/pom.xml
Date Mon, 04 Feb 2008 03:52:00 GMT

On Feb 3, 2008, at 5:34 PM, Gianny Damour wrote:

> Hi Kevan,
>
> concurrent is a WADI runtime dependency. The server starts fine  
> because wadi-clustering is not started by default and, assuming this  
> was the case, this dependency is only used when an invocation is  
> "contextualized".
>
> So, could you please rollback this change?

A bit more info on the problem with the concurrent library. The doc  
that I've found on the concurrent library is here -- http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/concurrent/intro.html

As described there, the concurrent classes have been released to the  
public domain. However, two classes are copyright Sun and appear to be  
covered by the following license agreement:

http://g.oswego.edu/dl/classes/EDU/oswego/cs/dl/util/sun-u.c.license.pdf

The problem with that license is:

"You acknowledge that Software is not designed, licensed or intended  
for use in the design, construction, operation or maintenance of any  
nuclear facility."

This limitation is, I'm pretty sure, going to be against Apache  
Policy. It would be classified as a category x license (i.e. the  
licensed artifacts can't be included in an Apache distribution). See http://people.apache.org/~rubys/3party.html

  for more information on 3rd party licensing.

So, things we can do:

1) validate the above on legal-discuss. I could always be wrong.
2) leave out concurrent jar, but require users to download the jar if  
they want to use wadi
3) update wadi to use JSE 5 concurrent support
4) Remove the CopyOnWriteArrayList and ConcurrentReaderHashMap classes  
from the concurrent jar. If wadi (and internal concurrent  
implementation) doesn't use those classes, everything should be OK.

We included the library in at least our 1.1.1 release (it's not in our  
2.0.x releases). Unfortunately, that doesn't help us. Just means that  
we were wrong back then...

  If anybody has any additional thoughts or ideas, let us know. We'll  
have to resolve this issue prior to a 2.1 release.

--kevan

Mime
View raw message