Hi Glyn! > I'm a bit concerned about the license implications. I haven't > read the BSD > license, but presumably its terms and conditions are different to the > Apache license that applies to the other jars which are > checked in. This > could affect people who want to reuse Axis. At the very > least, you need to > check in a license file alongside the tt-bytecode jar file.
Yep, I realized that as I was going to bed last night. Since tt-bytecode doesn't come with an explicit license file, I've sent mail to the developer asking for one. The BSD-style license is, I'm 99% sure, one of the acceptable ones to Apache. > Also, I guess Gump won't have access to the latest level of > the tt-bytecode > jar file, so problems may arise if people combine Axis with > newer levels of > tt-bytecode . I don't think this is any worse a problem with tt-bytecode than anything else. We can still track the development and interact with the developers to get everything working just like we do with Apache projects. Also, I note that we use JUnit, which has the same issue. > Would a better strategy perhaps be to get bcel improved and > possibly back > off to using javap (or whatever preceded the user of bcel in > Axis) for any > missing features until then? We can't back off to javap, since a) I would -1 it because it's gross :), and b) we have an internal Macromedia team who needs to operate in environments where javap is not available. Getting bcel improved is a possibility, but the only real purpose it would serve in this case is to "keep things in the family" as it were. Since tt-bytecode is distributed under a "good" license, I'd rather stick with it (especially since we save ~200K vs. BCEL). > Having said all this, I know you will consider the above > issues and I trust > your judgement, so I vote +0. Okee! Thanks, Glyn. --Glen
