search

jakartaee / tags

Other
25 stars 28 forks source link

WIP: Saxon alternative for transformation support #238

Closed isaacrivriv closed 5 months ago

isaacrivriv commented 2 years ago
arjantijms commented 2 years ago

@isaacrivriv thanks for starting this effort! Note though that the /impl folder will move to the WaSP project soon (https://github.com/eclipse-ee4j/wasp)

isaacrivriv commented 2 years ago

Oh wasn't aware of that, thanks for letting me know. I'll keep my eye out on that and when the move happens, I'll open a PR for the changes over there and continue testing

waynebeaton commented 2 years ago

I have some bad news... AFAICT, the license for Saxon-HE is incompatible with the project license. Note that this isn't an "Eclipse thing", it's a "the way that open source licenses (don't) work together thing".

JSTL is licensed under EPL-2.0 with GPL-2.0-only with Classpath-exception-2.0 as a secondary license. Saxon-HE is licensed under MPL-2.0 with provisions for secondary licenses revoked. Basically that means that if this content is included in the project, the secondary license cannot be invoked (effectively changing the project license). The Mozilla Foundation's FAQ provides some further insight.

I created IPLab issue 3760 to review the content. If the project team wants to pursue this further, please engage there and the IP Team can dig a little deeper.

arjantijms commented 2 years ago

That's a shame indeed. Maybe an alternative is some kind of plug-in structure, so it's ultimately the end-user who may choose to add Saxon in some way.

waynebeaton commented 2 years ago

I created IPLab issue 3760 to review the content.

There's some additional discussion on the IP issue for consideration. Based on the lack of response there, I'm assuming that we either have a notification problem on that repository's issue tracker (for which evidence is starting to mount) or that there is no interest in pursing this further.

I've closed the issue and have marked it as "Rejected". We can reopen if you want to pursue this further, but I, frankly, don't see a path forward other than a plug-in structure along the lines of what @arjantijms suggests.

arjantijms commented 2 years ago

@waynebeaton I did get the notification for IPLab issue 3760. It seems there's little we can do indeed. Maybe contact the author of the Saxon library, but I guess it will be an extremely slim chance they are willing to update the license just for us.

arjantijms commented 1 year ago

@isaacrivriv As you have been in contact wit the Saxon community, could you ask if they might consider a license update to accommodate us?

isaacrivriv commented 1 year ago

Sounds good, I'll start a conversation there see what the community thinks.

Edit: Forgot to ask, update the license in what sense? Ask Saxon to consider moving to the EPL-2.0 license or something else? What would be best to update to?

arjantijms commented 1 year ago

Forgot to ask, update the license in what sense?

@waynebeaton mentioned the primary issue is in forbidding a secondary license, which GlassFish uses. Maybe an exception for this can be granted in some way?

waynebeaton commented 1 year ago

Edit: Forgot to ask, update the license in what sense? Ask Saxon to consider moving to the EPL-2.0 license or something else? What would be best to update to?

The fundamental problem is that the license that they've selected specifically forbids linking with GPL-2.0 content.

As I've explained above (and in the IP due diligence record), the license is actually compatible with the project license EPL-2.0 OR GPL-2.0-only with Classpath-exception-2.0, because the project license offers a choice. In the compatible case, the adopter chooses EPL-2.0. But with the license of this content, the adopter cannot choose GPL-2.0-only with Classpath-exception-2.0. This impacts the practical licensing of JSTL and everything downstream.

In order to make this work, we either need the entire downstream from JSTL to decide that this is fine, or we need the good folks that produce Saxon HE to change their license so that it is compatible with both EPL-2.0 and GPL-2.0-only with Classpath-exception-2.0. One option is for them to change their license from MPL-2.0-no-copyleft-exception to MPL-2.0. Changing to another license might also work, depending on what they choose.

My expectation is that they very specifically chose this license for some strategic reason. Frankly, we don't see the MPL-2.0-no-copyleft-exception in the wild very often.

isaacrivriv commented 1 year ago

Sorry for the delay, here's a draft for creating the issue. If there are any other things I should ask or consider let me know.

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!

arjantijms commented 1 year ago

That sounds like an excellent way to ask for it indeed. Hope we'll get some response.

isaacrivriv commented 1 year ago

Saxon issue created https://saxonica.plan.io/issues/5757

waynebeaton commented 1 year ago

Before you get too excited, the response that suggests that you can avoid the GPL "linking problem" by using Maven does not match the Eclipse Foundation's interpretation of the license terms. Nor -- to the best of my knowledge -- does it match the FSF's interpretation.

I'd have a hard time arguing with the bit about lawyers.

isaacrivriv commented 1 year ago

So with Michael's response, what would be the best next step to take?

waynebeaton commented 1 year ago

So with Michael's response, what would be the best next step to take?

With apologies for the glib response... get used to disappointment.

Or this:

Maybe an alternative is some kind of plug-in structure, so it's ultimately the end-user who may choose to add Saxon in some way.

volosied commented 5 months ago

Saxon licensing is incompatible -- Tags Impl also moved to WaSP.

Closing this PR.