2009/2/26 Mark Hindess <mark.hind...@googlemail.com>: > > In message <17c6771e0902260513g17883e6dsc710a8e4aee30...@mail.gmail.com>, > Andrew John Hughes writes: >> >> 2009/2/24 Nathan Beyer <ndbe...@apache.org>: >> > >> > On Mon, Feb 23, 2009 at 1:52 PM, Andrew John Hughes >> > <gnu_and...@member.fsf.org> wrote: >> > >> >> 2009/2/23 Nathan Beyer <nbe...@gmail.com>: >> >> >> >>> How about a javadoc tool baseline implementation? >> >> >> >> There are already at least three such tools under FOSS licenses. Why >> >> would we need another? >> > >> > Are any under an ALv2 compatible license that we can package? >> >> I believe gjdoc and Sun's javadoc are under the GPL. If Apache >> Harmony can't be used to run Java programs licensed under the GPL, you >> may as well give up now. > > I think you missed the point of Nathan's question. The key terms > were 'ALv2 compatible' and 'package'. Running programs and > packaging/distributing them are entirely separate issues. >
No, I didn't. The GPLv3 is compatible with the ALv2 and, while gjdoc, is currently under GPLv2, it has the option of using a later version. If the Apache project wished to contribute to it, I don't see there being any problem upgrading to GPLv3. > Nathan was trying to determine if any of the implementations you mention > might help in meeting the goals of this project. As stated on the > project homepage, a goal of the Apache Harmony Project is to create: > > A compatible, independent implementation of the Java SE 5 JDK under > the Apache License v2 > > If there was a suitable javadoc under a compatible license[0] that we > could include in an ALv2 distribution then we certainly would consider > it over re-inventing the wheel. But I don't believe there is one? > Given your list is more restrictive than is actually required, and completely rules out all versions of the GPL for no apparent reason, then I guess the only thing that would be compatible under your requirements is little more than the ALv2 and very similar licenses... Of course, if you do come up with a useful tool, I'm sure we can likewise look at including it. As Classpath already depends on ecj, I don't see an ALed javadoc tool being an issue. > When the license is compatible, we are just as happy to reuse existing > components from other projects - such as Xerces, Xalan, BCEL, and > concurrent. Other Java projects with different goals may be pragmatic > about what they decide is compatible with their choice of license. > I don't know the history of the first three, but the JSR166 code was public domain and so didn't have a license. > Getting back to the topic of GSoC 2009, javadoc would not be top of my > priority list for tools to implement for Harmony. A jdb implementation > would probably be my most-wanted tool (probably built on the eclipse > jdi). The reasons for this is that I think that jdb is a tool where > there is quite a lot of room of improvement/adding-value (such as adding > JSR-45 support). I expect this would be more satisfying for a student > than implementing javadoc. I agree with that reasoning. You will need a javadoc for a complete 1.5 JDK though. > > Regards, > Mark. > > [0] There is some discussion of what is classed as compatible at: > http://www.apache.org/legal/resolved.html > > > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8