Re: Tomcat 4.0.1 in Debian?
Two quick observations... Please correct me if I'm wrong...
If memory serves, the JSSE problem will solve itself at the release of JDK-1.4.
I recall reading that this package should be included as part of this java release.
Second, is the LDAP you are referring to the same as the libldap-java package already in Debian?
J.R. Westmoreland
On Fri, Feb 08, 2002 at 06:12:53PM +0100, Arnaud Vandyck wrote:
> 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/
>
>
> --
> To UNSUBSCRIBE, email to debian-java-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
--
J.R. Westmoreland (W7JR)
E-mail: jr@jrw.org
Reply to: