Re: [kaffe] Build system for kjc / external jars + Jetty/JSP success
Hi Mark, --- Mark Wielaard [EMAIL PROTECTED] wrote: Maybe we should lobby the Apache Foundation to finally add the one word to the Apache License that would make it compatible with the GPL as I pointed out somewhere in the thread of that old email that Rob mentioned. Given that usually the licensing threads break out when ant and kaffe are mentioned in the same mail, and that a lot of intersting developement now takes place under the umbrella of apache foundation, 'fixing' the ASL to be GPL compatible (or releasing a GPL 3 that's ASL 1.1 compatible) would be the best way to handle this legal issues. cheers, dalibor topic __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Build system for kjc / external jars + Jetty/JSP success
hi Jim, --- Jim Pick [EMAIL PROTECTED] wrote: I played around a bit on the weekend with Jetty, and trying to get it working on top of Kaffe with JSPs. Out of the box, Jetty works with the latest CVS, but not the JSPs. I really wanted to get JSPs working with something that supports the Servlet 2.3 spec, since I've been playing around with doing some really cool stuff using JSTL. I want to switch Kaffe.org over to something that runs on Kaffe. :-) yeah, sounds quite cool to me ;) Having kaffe.org run on kaffe would be a nice way to show that the project is alive and kicking. It took me all weekend to figure out what was going wrong, and to come up with a fix. Jetty uses Jasper (from Tomcat) to generate the Java code, which then gets turned into a class file using the javac task from ant.jar (using -Dbuild.compiler=kjc). It turns out that, by default, kjc likes to stick the compiled .class files in the current directory, instead of in the same directory as the source .java file, as javac does. I cooked up a crude patch against kjc which seems to work. Unfortunately, it's a big mangled since I rearranged the kjc source dirs so I could get it to fit into Eclipse (which expects the sources to be laid out javac-style). I need to clean it up. When it's finished, please send it over to Martin Lackner and Thomas Graf from kjc to get it in their next release. Do you have any information if/when there is going to be a new release of kjc? What we're currently lacking is a build system for rebuilding kjc.jar. I'd like to propose a new top level module in CVS where we can check in a build system for generating external jars that get shipped along with Kaffe. Kjc is on such external jar. For documentation purposes, I'd also like to ship some additional jars, eg. an XSLT engine, docbook stylesheets, a cut-down version of ant (with needed Kaffe hacks), etc. There might be additional jars we might want to pack into the shipping tarball. I'd propose adding BCEL, jasmin (needed for some regression tests in JanosVM, and eventually in kaffe) and DNSjava (optional pure java DNS implementation). I'm proposing we call it kaffe-external-jars. Having only spent 30 seconds thinking of the right name for it, I'm open to a less wordy name for the module. I'd like to avoid checking in binaries. Instead, we could do something more along the lines of a BSD-style ports system, where we'd have scripts that would download the pristine source tarballs, and apply patches against them, and build our jar files, which could then be checked into the main Kaffe tree, as needed. What do people think of that? I'm open to alternate ideas. I like the idea. I think we should somewhere, somehow, be able to build the java tools we rely (or will rely on) for creating kaffe using kaffe. You way of doing it sounds quite cool, and I liked the approach you used with the libtool patches. I'm not sure how it will affect kaffe's status in debian though. Didn't they have that weird policy that if we used ant anywhere, kaffe would have to be removed from debian-free? Or am I just misremembering last year's big licensing thread? cheers, dalibor topic __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Build system for kjc / external jars + Jetty/JSP success
Hi guys, --- Jim Pick [EMAIL PROTECTED] wrote: I'm proposing we call it kaffe-external-jars. Having only spent 30 seconds thinking of the right name for it, I'm open to a less wordy name for the module. I'd like to avoid checking in binaries. Instead, we could do something more along the lines of a BSD-style ports system, where we'd have scripts that would download the pristine source tarballs, and apply patches against them, and build our jar files, which could then be checked into the main Kaffe tree, as needed. What do people think of that? I'm open to alternate ideas. I like the idea. I think we should somewhere, somehow, be able to build the java tools we rely (or will rely on) for creating kaffe using kaffe. You way of doing it sounds quite cool, and I liked the approach you used with the libtool patches. I'm not sure how it will affect kaffe's status in debian though. Didn't they have that weird policy that if we used ant anywhere, kaffe would have to be removed from debian-free? Or am I just misremembering last year's big licensing thread? cheers, dalibor topic I did some googling about the licensing issues, and it does seem that if we ship kaffe with a copy of Ant then we would not be included in debian-free anymore...the Apache license is not GPL-compatible. We can clearly use Ant all we want for developing, we just can't ship a copy with our software and remain on debian-free. Alternatively we could include non-essential external jars (such as Ant) in a separate package not on debian-free. That way kaffe itself stays on debian-free but the supplementary package does not. Of course, then the users need to snag two packages... As an aside, it would be awesome to have kaffe.org running on kaffe :) ~~Rob For the curious, this is from the Debian archives regarding the Apache 1.1 License, which is the one Ant is published under. http://lists.debian.org/debian-legal/2000/debian-legal-26/msg00116.html ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Build system for kjc / external jars + Jetty/JSP success
On 26 Jun 2003 18:56:37 +0200 Mark Wielaard [EMAIL PROTECTED] wrote: Hi, On Thu, 2003-06-26 at 18:04, Jim Pick wrote: Actually, distributing some non-GPL compatible apps along with the VM sources is not a bad way to help people understand how we interpret the licensing issues. Are you sure all copyright holders of the VM and the class libraries interpret the GPL this way? What happened to the copyright that Transvirtual held on large parts of the source code? The reason I ask is because the SCO mess reminds me of the fact that there will always be people/laywers who will interpret legal language in creative ways. I think all the IP is probably sitting in a cardboard box somewhere in some VC's closet in Japan. :-) In the wrong hands (eg. lawyer's like SCO's), I think that the IP could possibly come back to haunt somebody who incorporated Kaffe into a commercial product, and was making lots of money, even if the legal claims were baseless (eg. what SCO's claims appear to be). Let's not even start thinking about all the submarine patents out there held by various parties... Still, I personally think that saying the GPL contaminates the applications running across the virtual machine boundary is a stretch legally. Of course, I am not a lawyer, and I don't own all of the IP, so my interpretation isn't worth that much. :-) One of the reasons that the GNU Classpath and Kaffe projects worked on their own core library implementations in the past was precisely because they disagreed about this point. I'm pretty good friends with Paul Fisher, and he's talked to me extensively about GPL vs. GPL+Exception, and some of the back room deals that went on between Transvirtual and the FSF back in the day that led to the present situation. It's a real mess... I think GPL+Exception is the way to go for the class libraries - the exception is more of a clarification than anything, and helps remove the threat posed by crazed IP lawyers. I see Kaffe moving towards using Classpath for the core libraries eventually, and dropping most of the current class library implementation. Still, I don't think Kaffe can ever totally shake the GPL. I don't think that's necessarily a bad thing, as I don't think it poses any real barrier for using Kaffe as a basis for free software projects -- except we may have difficulty getting projects like Debian to distribute it. I don't believe that the GPL, when used as a license on a virtual machine, is so super viral that it contaminates applications run on top of the machine, or bundled alongside it. Granted, it's a matter of interpretation, but I've had discussions with a number of free software luminaries that basically agree with that interpretation. There are limits on how much the GPL infects other software - it doesn't cross all boundaries. The FSF will tell you so. The only people who will tell you that the GPL infects absolutely everything it comes in contact with is Microsoft, as part of their FUD campaign. The FSF indeed says that it doesn't cross all boundaries (though they use the terms derived work or work based on the program, not infect and boundary, since those are more common when used when talking about copyrights), but they do also say: http://www.gnu.org/licenses/gpl-faq.html#OOPLang In an object-oriented language such as Java, if I use a class that is GPL'ed without modifying, and subclass it, in what way does the GPL affect the larger program? Subclassing is creating a derivative work. Therefore, the terms of the GPL affect the whole program where you create a subclass of a GPL'ed class. I think that point could be argued. When I subclass java.lang.Thread, I don't feel like I'm creating a derived work of the Java Class Libraries. Instead, I feel like I'm using the API. http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL If a programming language interpreter is released under the GPL, does that mean programs written to be interpreted by it must be under GPL-compatible licenses? When the interpreter just interprets a language, the answer is no. The interpreted program, to the interpreter, is just data; a free software license like the GPL, based on copyright law, cannot limit what data you use the interpreter on. You can run it on any data (interpreted program), any way you like, and there are no requirements about licensing that data to anyone. However, when the interpreter is extended to provide bindings to other facilities (often, but not necessarily, libraries), the interpreted program is effectively linked to the facilities it uses through these bindings. So if these facilities are released under the GPL, the interpreted program that uses them must be released in a GPL-compatible way. The JNI or Java Native Interface is an example
Re: [kaffe] Build system for kjc / external jars + Jetty/JSP success
Jim Pick wrote: If Debian and the FSF still have issues, we can produce an additional tarball without the Apache stuff. The additional stuff is primarily a convenience for the end users to help satisfy build-time dependencies, and distributing it is really optional. Isn't the problem that Ant itself relies on GPL libraries but is Apache licensed, so Debian won't include *that* in main? If so, I don't see how either including OR not including the tarballs helps: Debian will *still* not include Kaffe if it build-depends on something that can't be in main, regardless of whether that something is part of Kaffe's tarball or an external dependency. It's KDE's dark ages all over again :( Stuart. PS I'm guessing, but don't know for sure, that the reason why Ant is in debian/contrib while KDE couldn't be shipped at all is that Ant can actually be legally shipped by using *non-free* components instead of the GPL ones, while there was no non-conflicting alternative for KDE's Qt requirement. -- Stuart Ballard, Senior Web Developer FASTNET - Web Solutions (215) 283-2300, ext. 126 www.fast.net ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
