Jaxp and crimson are built from xml-commons and xml-crimson
( both are
Apache packages ). We do check in binaries - which is consistent with
apache licence, but anyone can built them from sources as well.
In the RPM case, we use dependencies to have them included from allready
installed RPM. But it's not the case in the CURRENT version of RPM where
we install crimson which is allready present in sources.
Should I change to make xerces/crimson (jaxp requirement) required
for both build and runtime (easy to do) ? I'm sure that some of my
friend in RPM packaging (hello Guillaume) will prefer this method.
The only problem is JSSE - it's clear the official RPM
can't include JSSE, nor the classes that depend on it ( since that
would mean the source RPM couldn't be distributed ). We can
distribute a separate RPM with JSSE-dependent classes. That's not
a major problem for linux - since Henri is already building mod_jk,
Yep, JSSE is of course the most restrictive license of them
all, because of the goofy crypto laws. :(
Why couldn't we use the today JSSE as we use OpenSSL. I was told that
some legals aspect on RSA has been relaxed this year.
so SSL will be supported via Apache, which is the best (and fastest)
solution anyway.
Arrggg! Why does Standalone + SSL get no respect? It performs
quite well, in my
(extensive) experience. Also, I've never hit a single real
bug in it, in
either tree. Whether Apache is slightly better at SSL than
Tomcat standalone
isn't even a relevant comparison. If you're running TC behind
another web
server, then that web server needs to handle it. If you're
running standalone,
then Tomcat needs to handle it. Installing Apache to run in
front of TC *just*
to handle SSL is compeltely unnecessary.
You know that my friend, crypto is a hog cpu task and having it
handled by Java code will be more expensive that the native
(even asm) code in OpenSSL for example. But you're rigth when
you tell we could use SSL in 100% java mode...
Anyway, I'm trying very hard to build confidence in standalone
SSL, write
extensive docs for it, enhance it, patch it, and work out what
I see as its
weak points. Please don't impune it :)
Never ;)
Regarding the jars included in 4.0 - I do have few issues.
First, how in the world did we got to depend on mail.jar and
activation.jar and the other ?
Dunno, I'll let someone else answer that one.
I believe including such features could be decided by vote,
I don't have a problem with that. Technically, of course, it
would only be a
vote for what kind of RPM can be officially hosted on the
download site. Anyone
can package an RPM however they like, they just have to distribute it
themselves.
Yes even Sun could do such packaging :)
More seriously the problem here is all the requirement and I'll
be to have a Tomcat 4.0 ligth, with less external dependencies.
Or may be we must mark that TC 4.0 is for J2EE 1.3 only !
and only
after the PMC and ASF clearly posts the policy that allow
such things.
If ASF has any rule that allow us to take any package we want that is
redistributable and use it - that's great news.
If ASF has a list of 'aproved' licences that we can include - that's
even
better ( and I hope LGPL makes it to the list - at least it
has source
code available :-).
It would be nice to have this posted somewhere - so we all know the
rules.
Agreed. But in the absence of an official policy, I'll go by
what that one PMC
dude said in response to Jon's concerns: By and large, and
code checked into
the tree by Sun employees falls under the Sun-Apache
agreement. I don't think
it's unreasonable to accept that at face value until there
*is* an official
policy posted.
Without a specific policy disallowing it, I operate under the
assumption that
it is left up to the discretion of the particular community,
and good old-
fashioned common sense.
I'm -1 on including any non-apache binary unless the ASF/PMC
explicitely allows it. That's my vote in case this is put to a vote
on tomcat-dev
I'm -1 making anything bad for ASF in general and will wait
for Craig validation for my packaging proposal :
- Get jar in tomcat binary
- Get source in tomcat source
= provide tomcat RPM
Because if Craig's interpretation of the licenses is correct,
then I don't see
a licensing problem at all. It just becomes a matter of
packaging philosophies.
Incidentally, there are only about 500 people in here from
Sun. Can't somone
just run it down to Legal ;-)
Yes some lobbying should be nice and many people in PMC
ask Sun to OpenSource Java. May be Sun could start by
OpenSource more external libs, as they do for servlet/JSP
API
