At 19.34 05/02/03 -0500, you wrote: >[EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote: > >> Anyway, till Freenet remains in java, dropping the Kaffe >> compatibility IMHO is a fundamental mistake, both from >> the point of view of free software and from the security. > >What exactly do you mean by "Kaffe compatibility"? If Matthew & co. >write code which conforms to the specifications of the Java language, >but it crashes Kaffe, then clearly this is a bug in Kaffe. Attempting >to find workarounds which avoid Kaffe bugs might be helpful for you >and me in the short term, but it's a fundamental waste of time for >the project in the long term, if efforts could instead be focused >on improving Freenet itself.
This is not so simple; version specification does matter. Kaffe implement 1.0 java spec with some 1.1 features. So the request "maintain Kaffe compatibility" can be expanded in "use java spec 1.0 with only 1.1 extension Kaffe supports". Oskar .... please ........ Help me ..... >As for the license issue that you mentioned.... The GPL says: > > "Activities other than copying, distribution and modification are not > covered by this License; they are outside its scope." > >Can Freenet be copied? Yes. >Can Freenet be distributed? Yes. >Can Freenet be modified? I believe so. > >Then, the GPL goes on to cover the detailed conditions which apply >to these three fundamental activities. > > "1. You may copy and distribute verbatim copies of the Program's > source code [...]" > >No problem here. > > "2. You may modify your copy or copies of the Program or any portion > of it, thus forming a work based on the Program, and copy and > distribute such modifications [...] provided [...]: > > "a) [statement that you changed the files, and when] > "b) [all third parties are licensed to use it at no charge] > "c) [must print disclaimer of warranty if it's interactive]" > >Again, no problem here, except possibly 2c, but that only applies >to freenet.client.cli.* which most people don't use anyway. And it's >trivial to fix if anyone actually cares. > > "3. You may copy and distribute the Program (or a work based on it, > under Section 2) in object code or executable form [...] provided > that you also do one of the following: > > "a) [provide source code] > "b) [offer to provide source code at minimal cost] > "c) [pass along someone else's offer to provide source code] > >Now here's the important part: > > "The source code for a work means the preferred form of the work for > making modifications to it. For an executable work, complete source > code means all the source code for all modules it contains, plus any > associated interface definition files, plus the scripts used to > control compilation and installation of the executable. However, as a > special exception, the source code distributed need not include > anything that is normally distributed (in either source or binary > form) with the major components (compiler, kernel, and so on) of the > operating system on which the executable runs, unless that component > itself accompanies the executable." > >Whenever I see a discussion of the GPL, this paragraph is the one that >usually causes the most trouble. In the context of placing Freenet >under the GPL, however, it *does not matter whether Freenet can be >run on a free Java virtual machine*, because the GPL does not concern >itself with the use of the program -- only with copying, distributing >and modifying the program. > >The real issue is whether Freenet can be *developed* with free tools. >The answer to this, IMHO, can take a couple different forms: > > 1) If Sun's Java Software Development Kit is considered "the operating > system on which the executable runs", then the non-free javac > (compiler) can be considered a normally distributed major component > of that operating system. This is an open question. > > 2) If Freenet can be developed entirely with alternative tools, which > could (at least in theory) be distributed along with Freenet, then > this paragraph is also satisfied. I compile Freenet using jikes > and ant. Jikes is in Debian's main repository, meaning it's > Free Software according to Debian's guidelines. Ant, however, is > in the "contrib" section, which is a trickier matter. Software > in contrib is free, but depends on something which isn't. I don't > feel like tracking down all of ant's dependencies and license > clauses at the moment. > > I believe (but I may be mistaken) that Freenet can also be developed > without using ant. Jikes and make might be sufficient. If that's > the case, then everything should be fine -- just include a written > offer to provide jikes (since make is clearly a normal component > of every Unix-like system). I can't foresee anyone actually taking > you up on the offer, when they could download jikes directly from > IBM far more quickly -- but even if they did, sending them a copy > of jikes should't drain the Freenet treasury too greatly. (You > can always request a few more donations.) > > FYI, jikes-1.14.tar.gz is 609,341 bytes and is in Freenet at > CHK@2a4yGgZlJv6W7Y1YouvjZr1IT5sUAwI,pbg7cCTk98Zq-1OufU0yew > >I don't believe the remaining clauses of the GPL are relevant to >the current discussion, so I'll spare you any further analysis. As >far as I can see at the moment, Freenet does not contradict the GNU >General Public License. The real fact is "in which way you can run Freenet using only free software in the real world?" The answer is "only using Kaffe 1.0.7" You can guarantee a fully auditable Freenet node only if you don't break the Kaffe ring in the free software chain. For the formal point of using plain GPL for Freenet (I'm not proficient on this) see this excerpt from GPL official FAQ and judge for yourself. For example the Onion lib inclusion require at least the Onion Gpl extension; AFAIK this not exists. The release of Freenet under pure GPL is not a trivial operation. Thx. Marco ========================================= If a programming language interpreter has a license that is incompatible with the GPL, can I run GPL-covered programs on it? When the interpreter just interprets a language, the answer is yes. The interpreted program, to the interpreter, is just data; the GPL doesn't restrict what tools you process the program with. 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. The JNI or Java Native Interface is an example of such a facility; libraries that are accessed in this way are linked dynamically with the Java programs that call them. So if these facilities are released under a GPL- incompatible license, the situation is like linking in any other way with a GPL-incompatible library. Which implies that: If you are writing code and releasing it under the GPL, you can state an explicit exception giving permission to link it with those GPL-incompatible facilities. If you wrote and released the program under the GPL, and you designed it specifically to work with those facilities, people can take that as an implicit exception permitting them to link it with those facilities. But if that is what you intend, it is better to say so explicitly. You can't take someone else's GPL-covered code and use it that way, or add such exceptions to it. Only the copyright holders of that code can add the exception. ======================================== -- + il Progetto Freenet - segui il coniglio bianco + * the Freenet Project - follow the white rabbit * * Marco A. Calamari [EMAIL PROTECTED] www.marcoc.it * * PGP RSA: ED84 3839 6C4D 3FFE 389F 209E 3128 5698 * + DSS/DH: 8F3E 5BAE 906F B416 9242 1C10 8661 24A9 BFCE 822B + _______________________________________________ support mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/support
