Saxon

The difficulty has always been that there are contributors of code in Saxon who would need to provide their consent. No non-Saxonica code has been contributed for a very long time; but the original development was done while I was an employee first of Fujitsu and later of Software AG, and the software is only released under MPL because they formally consented to that at the time. The idea of finding anyone in either company (but Fujitsu especially) who would be prepared to authorise this is rather daunting - the request would most likely be shuffled around and get lost in someone's deep in-tray.

Indeed, there is a danger that the exercise could back-fire, for example not all lawyers accept that a decision to license code as open source is irrevocable.

My personal take on this is that it's all nonsense - the lawyers have invented a problem and are laughing all the way to the bank. With modern mechanisms (such as Maven and nuget) for combining software with its dependent components, there is no "linking" in the sense of the GPL license, which is based on very archaic notions of software construction. Just set things up in Maven so you're not distributing your product "linked" with Saxon, rather have the customer do the linking at installation or invocation time. There's no ban on linking two products with incompatible licenses, the only ban is on distributing the result as a single indivisible component.

Thanks for the quick response Michael! I'll share your response to the others in the community and get their take on this and see what would be our next step.

Michael Kay wrote in #note-1:

I was an employee first of Fujitsu and later of Software AG, and the software is only released under MPL because they formally consented to that at the time. The idea of finding anyone in either company (but Fujitsu especially) who would be prepared to authorise this is rather daunting

Maybe Fujitsu would be the easiest one really. They are a frequent contributor to the GlassFish project (even more so, they lead the GlassFish project), and to the JSP/JSTL and their implementations too.

Indeed, there is a danger that the exercise could back-fire, for example not all lawyers accept that a decision to license code as open source is irrevocable.

It's possible to change the license for a new release of code.

Just set things up in Maven so you're not distributing your product "linked" with Saxon, rather have the customer do the linking at installation or invocation time.

The GlassFish, JSTL, JSP etc projects are already using Maven. It's kinda the default. Unfortunately just using Maven is not enough. I do agree that the originally term linking as was used by C compilers seems different enough from the concept of a class path as used by Java, but generally it seems accepted that for practical purposes these are the same. Hence the concept of the classpath exception in (L)GPL.

I am going to decline this request, for three reasons.

• First, as mentioned, there are logistical difficulties in obtaining the consent of all the people who contributed code to Saxon in its early life. Many of the names are no longer findable on the internet; some of them are big corporations who will struggle to identify someone to take responsibility for taking action; some of them may even be unknown, since in the early days we were happy to take contributions informally without any written agreement. I know of at least one contributor who has died.

• Secondly, I profoundly disagree with the philosophy underlying the GPL license. It states in its preamble that "the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users." but it actually does exactly the opposite; as you are discovering, it aims to prevent you using the software in conjunction with other software components. We have a different philosophy: we believe that developers and users of critical software products should have a long-term relationship in which the value obtained by the user community feeds back into investment in the future of the software. Over nearly 25 years in which Saxon has remained one of the few XML toolkits that has been continuously supported and upgraded, we believe we have proved the value of this model. We believe that if you want free and open software, you should encourage people to use unrestrictive licenses.

• Thirdly, I believe that the GPL's approach to constraining the way software is distributed is technically obsolete in today's world of loosely coupled, repository-based software disttribution and assembly. The "copy-left" provision in GPL boils down to the rule in section 5 that you may "convey a work based on the Program... provided that ... you must license the entire work, as a whole, under this License". My belief (and of course there are lawyers who might disagree...) is that when you upload software to a repository such as Maven or Nuget or Npm, with dependencies on other components in the same repository, then the "entire work" that you convey is what you publish in the repository, and does not include any components that it might declare dependencies on. That's especially (and obviously) true when the dependencies are optional.

Michael Kay