Hi, I don't think we should re-instate the old file: that's too complicated from an IP perspective. Retain Remy's new file with it's easy IP handling, and give Jason a nice thank you (but not copyright, as was made clear in the legal-discuss archives) notice in either the file itself or our NOTICE file. Hopefully that way no one's ego is hurt beyond the pain already inflicted by this whole discussion, and we all move on.
Yoav Quoting Remy Maucherat <[EMAIL PROTECTED]>: > Mark Thomas wrote: > > Having raised this in the legal-discuss mailing list, the result was > > that there is actually no issue to worry about here. See > > > http://mail-archives.eu.apache.org/mod_mbox/www-legal-discuss/200501.mbox/[EMAIL PROTECTED] > > > > > for details. > > > > With this in mind we need to consider what, if anything, to do now. I > > see the following options: > > > > TC5 > > - Need to populate o.a.c.util.CharsetMapperDefault.properties > > Options > > 1. Do nothing. Wait for patches to be submitted. > > 2. Re-instate the contents of the properties file based on Jason's > > previous class and include appropriate text in the NOTICE file. > > Something like: > > <notice> > > o.a.c.util.CharsetMapperDefault.properties is based on code originally > > written by Jason Hunter [EMAIL PROTECTED] as part of the book "Java > > Servlet Programming" (O'Reilly). See <a > > href="http://www.servlets.com/book";>http://www.servlets.com/book</a> for > > more information. Used with permission under the Apache 1.1 license. > > </notice> > > > > TC4 > > - Don't need to do anything > > Options > > 1. Do nothing > > 2. Port Remy's enhancements to o.a.c.util.CharsetMapper > > > > TC3 > > - Uses o.a.t.util.http.LocalToCharSetMap which has been deleted > > Options > > 1. Re-instate the file. > > 2. Work around it as suggested in Bill's previous e-mail > > > > My own views are: > > TC 5 - option 2 > > TC 4 - option 2 > > TC 3 - option 1 (less effort for us) > > I think we're going nowhere. If the ASF doesn't make it clear that there > are no redistribution IP issues because of licensing pollution, then I > don't think my company will feel safe continuing contributing to this > project since our customers will no longer feel confident using our > product. This is a problem ;) It's as simple as that. So we would have > to start maintaining our own branch, which basically means forking. I > suppose every vendor does that, of course, but it's still quite > disppointing (as then, the temptation exists to "add value" to our own > tree) ... > > Tomcat will work perfectly well without this code, so I do not see the > point reintroducing it accompanied with ambiguous legal and advertising > statements. This "code" (it's a set of name value pairs, so it's not > really code actually) was improperly sneaked into the Tomcat codebase, > so I think we should get rid of it. > > Rémy > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
