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
