Project

Profile

Help

Feature #5757

closed

Regarding Saxon open-source license

Added by Isaac Rivera Rivas about 2 months ago. Updated about 1 month ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
Build and release
Sprint/Milestone:
-
Start date:
2022-11-29
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:

Description

Hey there!

I'm working on the JSTL open source project https://github.com/eclipse-ee4j/jstl-api. We're looking for alternatives as a replacement of the Xalan library due to the recent CVE that was discovered some months back and the high probability of the project being archived in the near future. In this search, we discovered Saxon and having such an active community and continued development it would be a great alternative for us to use. With this in mind we built a prototype as a replacement for Xalan using Saxon in JSTL https://github.com/eclipse-ee4j/jstl-api/pull/238. After some discussions with the community we saw that the licenses between JSTL (EPL-2.0 OR GPL-2.0-only with Classpath-exception-2.0) and Saxon (MPL-2.0-no-copyleft-exception) are incompatible as discussed here https://gitlab.eclipse.org/eclipsefdn/emo-team/iplab/-/issues/3760. The changes done for overlaying Saxon in JSTL are due to the discussions here https://saxonica.plan.io/issues/5687. I'm sure there are specifics that led to the decision of using the MPL-2.0-no-copyleft-exception license. Is there any way this could be reconsidered or an exception be provided? Maybe just plain MPL-2.0 instead of MPL-2.0-no-copyleft-exception?

Thanks in advance!

Actions #1

Updated by Michael Kay about 2 months ago

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.

Actions #2

Updated by Isaac Rivera Rivas about 2 months ago

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.

Actions #3

Updated by Michael Kay about 2 months ago

  • Subject changed from Regarding Saxon license to Regarding Saxon open-source license
  • Category set to Build and release
  • Assignee set to Michael Kay
Actions #4

Updated by Arjan Tijms about 2 months ago

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.

Actions #5

Updated by Michael Kay about 1 month ago

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

Actions #6

Updated by Michael Kay about 1 month ago

  • Status changed from New to Closed

Please register to edit this issue

Also available in: Atom PDF