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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- J.R. Westmoreland (W7JR) E-mail: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]