Saxon

We can only give technical advice here, not legal advice.

GPLv3 does not use the term "bundle", so you need to think about exactly what clause of the GPL or MPL you think you would be violating by doing what you propose. Personally, I cannot find one. There's a lot of secondary literature about what the GPL does and doesn't allow, but very few decisions have been made by the courts and no-one will really know what it means until the courts decide.

GPL and MPL are supposedly "incompatible" in that if you create a work that combines GPL and MPL components, GPL requires you to distribute the MPL parts under a GPL license and MPL does not permit this.

But that's not the actual terminology used.

GPL has a clause that says "The “Corresponding Source” ... does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. In my view when you use Saxon (especially if you use it via JAXP interfaces), then Saxon comes under the definition of of "System Libraries" and failing that it certainly comes under the definition of "generally available free programs which are used unmodified and are not part of the work".

But you may have corporate lawyers with their own views. I find that corporate lawyers tend to take a pessimistic "worst case" view of license conditions.

If your corporate lawyers don't agree with my (non-lawyer's) interpretation, then you can always test your product with Saxon, and distribute it without Saxon, and give the user instructions on how to run it with Saxon: I don't see how that can be in violation of any clause in the GPL, since you are not "conveying" Saxon with your product. Especially if you only call Saxon using JAXP interfaces. And if that's allowed, then it is also allowed to distribute an "aggregate" or "compilation" containing both your software and Saxon, each under separate license conditions.

It is not possible to change the license conditions under which Saxon is issued without either (a) getting the consent of all previous contributors, or (b) removing the code contributed by those contributors. So much water has passed under the bridge since work started in 1998 that neither course of action is practically feasible.

Thank you for your fast response. The situation is the same on my side. The project I am working for started at about the same time and heavily relies XSLT with Xalan and URIResolver and Xalan extensions. XSLTC, which is part of Xalan and also bundled with JDK, does not support (read: use) URIResolver. Saxon seems to fit in providing support for newer standards while also providing support for URIResolver and custom extensions through ExtensionFunctionDefinition. There is no way we can get rid of GPL as no contributor, not even me, would like to change the license.

You see: We cannot provide implementations of ExtensionFunctionDefinition as in the current form the license of Saxon forbids us to do this. If you would keep that issue in mind? Maybe sometime in the future we could use Saxon then.

kind regards,

Thomas

Let's be clear: there's only one thing the Saxon license forbids you from doing, and that is changing the license under which the code is distributed. It's the GPL that is causing your problems, by disallowing coexistence of GPL and non-GPL code. GPL's boast that it offers "the freedom to use the software for any purpose" is pretty hollow: it does precisely the opposite.

It is not true that the Saxon license forbids you to provide implementations of ExtensionFunctionDefinition. It's possible that on some interpretation of the GPL, the GPL forbids you from doing so.

Personally I think that the exemption for "generally available free programs which are used unmodified in performing those activities but which are not part of the work" means that you can use Saxon from a GPLv3 application. Your lawyers may not agree, in which case I suggest you find a lawyer who is trying to help you rather than get in your way.