Re: Tomcat 4.0.1 in Debian?
Rick Lutowski <rick@jreality.com> wrote:
> Arnaud Vandyck wrote:
>
> > especially when you (i think) argue that jakarta is not
> > responsible to provide a full distribution and it's user or
> > package maintainer responsability to download the different jars
> > needed by the application (in our case tomcat4).
>
> By 'package maintainer' I assume you mean 'debian dselect package
> maintainer', and not just someone who creates a custom tarball or
> jar containing the non-free stuff required by Tomcat. Yes?
I meant the man who will make the Debian package of Tomcat. According
to the Debian philosophy, it means making different packages and
dependencies. The packages with license problems will not be IN a
package but an installer package may be a good solution (the
[end-]user will be prompted by DebConf to download the package from
the Sun site (login and/or accepting license terms) and then place the
downloaded zip file in /tmp, the installer package will extract the
zip file and place it in /usr/share/java).
> > ...
> > you), how about an installer package? Users will download all the
> > needed packages and the installer package will unzip and move them
> > to /usr/share/java with all the rest of the jars in the Debian
> > distribution.
>
> If deselect package is what you mean, then your statement about it's
> user responsibility to download [non-free] jars makes sense, but
> saying "or [deselect] package maintainer's responsibility" may not
> make sense, depending on the reason _why_ this responsibility gets
> pushed off jakarta onto the debian team or user:
>
> Could it be the reason the user has this responsibility is due to
> Sun's (or other vendor) license restrictions on redistribution? If
> so, then creating non-free deselect packages might be useless, even
> if a volunteer is found to do it, because these too might violate
> the vendor's license. I say 'mignt' because this depends entirely
> on which vendor jars are involved -- in the case of Sun, their
> license differs with each product, as we know. Things would be
> clarified if someone could please list the non-free packages
> involved.
I think Tomcat4 only need packages from Sun except the Tyrex package
but I haven't been able to download it today.
> <place list here>
I did make a list of all the jars files Tomcat4 needs to compile,
based on the BUILDING.txt file from the Jakarta-Tomcat 4.0.1 sources
from the apache site (# $Id: BUILDING.txt,v 1.5.2.3 2001/10/04
19:29:30 remm Exp $). There are 4 sections: 1) packages needed by
Tomcat4 but already exist in Debian; [A note about the BUILDING.txt
file]; 2) packages needed by Tomcat4 and do *not* exist in Debian; 3)
optional package that exists in Debian; 4) optional package that does
*not* exists in Debian.
1) Existing packages:
JDK >=1.2 (?)
Ant-1.4
+ jakarta-ant-1.4-optional.jar
(is this in the package?)
Jaxp-1.1 (Crimson package)
Xalan
Xerces-1
Servlet-API-2.3
NOTE about the BUILDING.txt file:
# (6) Steps (7) - (17) are optional, but are necessary to build a
# complete binary distribution of Tomcat 4.0. Set the "full.dist"
# property to "on" in the build.properties file (see step (17)) to
# build a complete distribution. Regular contributors to Tomcat
# are encouraged to use the complete build option.
Steps 7 - 17 specify the other packages "needed" by Tomcat4 to compile
the sources.
Reading this, is it possible to make a "minimal" Tomcat4 distribution?
2) Non-existing packages for a full distribution of Tomcat4:
JDBC Optional Package API (version 2.0)
http://java.sun.com/products/jdbc/download.html
LICENSE: Binary Code License Agreement
JMX 1.0 Reference Implementation AND Agent Reference Impl >=1.0
http://java.sun.com/products/JavaManagement/download.html
LICENSE: SUN COMMUNITY SOURCE LICENSE
JNDI 1.2.1 Reference Implementation >=1.2.1
http://java.sun.com/products/jndi/
LICENSE: Binary Code License Agreement
LDAP Provider (ldap.jar)
http://java.sun.com/products/jndi/
LICENSE: Binary Code License Agreement
Java Activation Framework 1.0.1 >=1.0.1
http://java.sun.com/products/javabeans/glasgow/jaf.html
LICENSE: Binary Code License Agreement
JavaMail package >=1.2
http://java.sun.com/products/javamail/index.html
LICENSE: Binary Code License Agreement
Java Secure Sockets Extension (JSSE) package >=1.0.2
http://java.sun.com/products/jsse/
NOTE: The user will have to be registred!
LICENSE: Binary Code License Agreement
Java Transaction API (JTA) package =1.0.1
http://java.sun.com/products/jta/
LICENSE: Binary Code License Agreement
Optional packages:
3) Existing packages:
JUnit unit test package >=3.7
http://www.junit.org/
NOTE: This step is only required if you wish to build and execute
the unit tests that are part of the Tomcat 4.0 source base.
4) Non-existing packages:
Tyrex JAR or release =0.9.7
http://tyrex.exolab.org/download.html
NOTE: This step is only required if you wish to build the Tyrex
connection pool implementation for JNDI-accessed data
sources.
> If the above list includes Sun (or other vendor) code with licensing
> that restricts redistribution, then the only solution other than
> give up (which makes life hard on the Tomcat 4 user, esp non-Java
> user who thinks jars hold pickles but still wants to use Tomcat) is
> to try to get permission from the vendor. Maybe jakarta has tried,
> I don't know. Even if they have and were turned down, a lobby
> effort from a large number of users might be successful where a
> single request from jakarta was not. But this is jumping ahead.
> First, it would help to know exactly what the real problem is.
>
> Is the problem that vendor licensing prohibits redistribution, and
> if so, for exactly which vendor/jar packages?
I think Henri Gomez has a very good knowledge of the license
problems. I'll try to read the two licenses involved (binary code
license agreement and Sun community source license)...
-- Arnaud
http://vbstefi60.fapse.ulg.ac.be/
Reply to: