Julian Scheid <address@hidden> writes:
Libxml2 isn't under GPL either - it's released under the MIT
license - so actually the Gjdoc version currently in CVS also
relies on non-GPLed software (at least when it comes to HTML
generation.)
So technically, while Gjdoc works on a 100% "free" toolchain, it
doesn't run on a 100% GPLed toolchain - not in the past, and
obviously not in the near future.
I understand that the ultimate goal is to provide all Cp-tools
with no dependencies on non-GPLed third-party software. But until
this is possible, what's the official GNU policy towards this
end - especially when it comes down to static linking? Who can
give a definitive statement to this issue?
I'd be happy to go along with Xalan for now, but I wonder if we
can (or should) encourage users to download Xalan, and provide a
tailored build file, or usage instructions for it. Something
like "make sure you have Xalan, Saxon or another JAXP-compliant
XSL processor on your CLASSPATH." Or - for the gjc-based build -
"you have to link Xalan-foo.jar into the executable for XSL
processing to work."
I don't like the idea of recommending xalan (which is why I hope to
write this libxslt wrapper).
I know that libxml uses the MIT licence (which one? expat? X11?) but
it's obviously GPL compatible. Since one GNU project is already
relying on it I think it's safe for gjdoc to rely on it.
When I've finished my wrapper I hope it will go into Classpath and
GCJ as a standard part of the build. XML seems to be that important
to java these days (another reason why I want to write the wrapper is
to reduce the amount of work the GNU java community has to do to keep
up with the language: libxml2 will give us schema and so forth - stuff
that aelfred2 is unlikely ever to do).
However, that's all by the by. I haven't written this wrapper yet, I
haven't even started. I am aware it's high priority (it's high
priority to me as well since Paperclips doesn't natively compile with
GCJ right now because of a bug in aelfred2).
Nic