><I-am-not-a-lawyer> >Although there's no technical challenge to doing this, the licensing >permission becomes much more murky. The standard "permission to >redistribute" paragraph on the other JAR files talks about packaging >inside something with which you are adding value -- and it's >not obvious >that your proposed approach would qualify, where it's pretty >obvious that >the value add in the single-download approach is a complete application >that includes functionality requiring those JARs. ></I-am-not-a-lawyer> The whole problem is there is just too many non OSS packages in TC 4.0 and that brake RPM policies. And we're speaking about packaging an Apache Product, not a M$ tool and people used to see Apache 110% OSS. >In general, though, how would making two RPMs rather than one >satisfy the >"RPM packing requirements" rules any better? If the JARs are >not supposed >to be packaged in the primary RPM, why is having them in a separate RPM >OK? We were speaking about the possibility to have the required jars outside TC 4.0 in an unique tarball which could be used in primary TC 4.0 RPM or build into a second. Having a second RPM, will clearly indicate to users that this stuff IS MANDATORY and a PRE-REQUISITE to build or use TC 4.0 >Personally, I'd lean a little further on the side of the poor >user whom we >force to go through incredible machinations to install and use a binary >distribution ... That's why some people works on packaging, allowing poor users to have just to type rpm -Uvh tomcat-xxx.noarch.rpm and have all the stuff magically installed and working. Personally, I'd like to see a more modular approach of TC 4.0 build, allowing a diet TC 4.0 without any requirements on non OSS software. If JSSE is still required for native HTTP/SSL in TC 3.2/3.3/4.0 but users could still Apache + mod_ssl + mod_jk/webapp to have a 100% OSS SSL solutions and that one could be dropped. BTW, till we find a solution to the externals jars problems, having for example a tomcat-4.0-supplimental.tar.gz located at jakarta.apache.org, we'll have to wait for the RPM. I'm sure you could find a Sun Layer which will find an acceptable solution ;)
