tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
Subject Re: Fedora "tomcat"
Date Mon, 17 May 2004 05:03:48 GMT
It's not a "derivative" - it's the same tomcat code, just placed in 
weird directories and using a different VM ( which is a bit 
"experimental"), and it seems less stable because of how it is compiled.

They do the same for apache itself ( probably not as bad ) - every 
distribution has its own "FHS-standard" way of placing the config files 
and modules and its own variations to make it incompatible with other 
distros.

It is a common practice for all distributions to do this for almost all 
packages ( kde, apache, sendmail, etc ).

IMO it's not a problem with fedora - but with tomcat ( and with many 
other open source projects ). We can at least provide a standard layout
and some basic requirements ( like passing the unit tests and some load 
tests ), and have some official RPM distribution for rpm-based linux.
We do it for windows - why not for linux ?


Costin


Steve Raeburn wrote:
> Excuse me for pitching in. I thought it was worth pointing out that the
> Apache 1.1 License specifically prohibits distributing derivative works
> using the name Tomcat.
> 
>  * 4. The names  "The  Jakarta  Project",  "Tomcat",  and  "Apache
> Software *
>  *    Foundation"  must not be used  to endorse or promote  products
> derived *
>  *    from this  software without  prior  written  permission.  For
> written *
>  *    permission, please contact <apache@apache.org>.
> *
> 
> If Fedora is distributing a derivative work and calling it Tomcat, then
> they are in breach of the license (IMHO, IANAL).
> 
> If the Fedora guys are doing something you're unhappy with, then I hope
> they would respond to a friendly, informal approach. If they are
> unresponsive, then I would consider kicking this up to the board for a
> more formal approach.
> 
> Of course, if you can also make it easier for Fedora to use the official
> TC releases, then that would be great too.
> 
> I'll go back to lurking now :-)
> 
> Steve
> 
> 
> 
> 
>>-----Original Message-----
>>From: news [mailto:news@sea.gmane.org]On Behalf Of Costin Manolache
>>Sent: May 16, 2004 5:14 PM
>>To: tomcat-dev@jakarta.apache.org
>>Subject: Re: Fedora "tomcat"
>>
>>
>>Remy Maucherat wrote:
>>
>>>>It is very nice they are bundling java tools and tomcat -
>>
>>but I thing
>>
>>>>it is a big problem ( for tomcat developers, fedora users
>>
>>and  tomcat
>>
>>>>users ) that they distribute such a badly modified tomcat
>>
>>( and call
>>
>>>>it tomcat)
>>>
>>>
>>>But for a daemon, which is often more complex and needs to
>>
>>be really
>>
>>>reliable, it would need more time to mature :(
>>
>>People using Fedora and Tomcat 4.1.27 will not know that what they're
>>using is an imature technology because of GCJ and because
>>fedora messed
>>up the layout of tomcat. They'll think it's tomcat that is a problem.
>>
>>
>>
>>>>I don't think it's a RedHat or Fedora issue - they are
>>
>>probably trying
>>
>>>>to do what's best for their project ( fedora ). I don't
>>
>>know of they
>>
>>>>are intentionally trying to create "lockin" by having their own
>>>>variation or just thing they know better how tomcat layout
>>
>>should look
>>
>>>>like - but the real question is if we should care about it and do
>>>>anything about it.
>>>>
>>>>I have no doubt that other distributions will follow
>>
>>RedHat example and
>>
>>>>start to include their own layouts and changes - look at
>>
>>httpd example
>>
>>>>( you can hardly find 2 distributions to place the conf or htdocs
>>>>files in the same place ). Well, that's probably more rant for my
>>>>weblog..
>>>
>>>
>>>Good point.
>>>
>>>
>>>>If the release manager could take this extra work and
>>
>>include an RPM -
>>
>>>>or at least we could point to Henri's RPMs - and then we
>>
>>could make it
>>
>>>>clear that if a distribution wants to bundle tomcat, they
>>
>>should use
>>
>>>>the official RPM or something that is equivalent in layout, file
>>>>permission, scripts, etc.
>>>
>>>
>>>How hard would it be to automate it ?
>>>The problem is that the script must be run from Windows to
>>
>>generate the
>>
>>>installer.
>>
>>Long back we had something part of the build.xml to generate both RPM
>>and solaris PKG ( don't know if this was before or after
>>having tomcat
>>in apache ). It's not very hard - if you have cygwin I think
>>it's doable
>>even on windows.
>>
>>
>>The real hard part is agreeing on a layout and pushing for this to
>>happen - i.e. making it clear in the web site that a distro
>>that doesn't
>>follow the layout shouldn't be used, and providing
>>alternative RPMs for
>>people.
>>
>>Any standard layout is ok for me - I allways preffered the
>>/opt model (
>>Apple is using something similar AFAIK for applications, so
>>is windows),
>>   but linux distros have this stupid FHS standard that
>>allows them to
>>put files in almost any place - but excludes /opt model.
>>
>>I think any layout is good - as long as we can tell people "look in
>>/etc/tomcat/jk2.properties" instead of "try to find where your
>>distribution installed tomcat config files". Or "place your webapps
>>files in /var/tomcat/webapps/XXX". Or write additional RPMs
>>that install
>>different modules automatically.
>>
>>
>>
>>
>>
>>
>>>>Probably this can't be enforced ( we don't have any
>>
>>trademark on the
>>
>>>>name ), but we can at least mention somewhere that what they
>>>>distribute is not actually tomcat. I see this as a fork
>>
>>using the same
>>
>>>>name as the original product.
>>>
>>>
>>>Yes, I think the ASF has very little control of the usage
>>
>>in most cases.
>>
>>We do control the website and it can be used to inform people and
>>distribute the "right thing". I know we give up control over the code
>>and apparently the name ( I am not very sure how they call their
>>modified version "tomcat", but I assume we have no trademark ).
>>
>>
>>Apache ( and many other open source projects ) don't seem to have the
>>will or care about how their software is distributed or about the
>>resulting fragmentation and support problems.
>>
>>
>>
>>
>>>>Sun does provide a RPM and .tgz that works on all distributions I
>>>>tried. If the JDK itself can be made cross-distribution, I
>>
>>don't see
>>
>>>>why we couldn't have a binary package that could be
>>
>>installed on all
>>
>>>>distributions. I think there are even tools to convert
>>
>>from .rpm to
>>
>>>>.deb and .tgz - to support the other package formats.
>>>
>>>
>>>True, their stuff works on every distribution.
>>>
>>>
>>>>It is absurd to have one package for each variant using RPM, with
>>>>different layouts and content.
>>>
>>>
>>>Indeed :(
>>>
>>>The issue has been around forever, which means that the
>>
>>vendors haven't
>>
>>>done much to solve the issue. And since all Linus cares
>>
>>about is the
>>
>>>kernel ;)
>>>(good thing some unifying has been going on in the UI department,
>>>otherwise, I can't imagine the mess it would be ;) )
>>
>>
>>Linus cares about the kernel - we should care about tomcat :-)
>>
>>On all distributions I know, the kernel is in /boot, modules in
>>/lib/modules/VERSION, the start sequence is the same, etc.
>>
>>But what you are saying is the essence of the problem and
>>missunderstanding - the "vendor" for tomcat is ASF, not Fedora.
>>All commercial vendors I know distribute their own packages ( RPM or
>>install shield or whatever ) - they don't let re-distributors sell a
>>completely modified package with the same name as the original.
>>If security or stability problems are found - they'll be
>>attributed to
>>tomcat and apache.
>>
>>People confuse what "vendor" means - it should be the author of the
>>software, not agregators that take many packages and sell
>>them togheter.
>>
>>
>>Costin
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
>>
>>
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org


Mime
View raw message