Remove LICENSE_EFTL.md and ensure that only the Specification Committee promotion script is used to add EFTL license to TCK archives.

[scottmarlow]

As per https://www.eclipse.org/lists/jakartaee-tck-dev/msg02011.html discussion and full context of the entire mail thread:

Unfortunately, the process we are under (at least as outlined here) recommend that only a Proposed Final TCK include the EFTL and this will almost certainly require the archive be rebuilt on anything published earlier than a proposed final release.

I think it makes sense to just remove the EFTL license as the Specification Committee promotion script should be the only way to add the EFTL license. Basically going forward, the Platform TCK team will only release TCKs with the https://github.com/jakartaee/platform-tck/blob/tckrefactor/LICENSE.md project license for EE 11.

[gurunrao]

@scottmarlow - build shell scripts are being used in Ant/Java Test TCK generation. should we make changes to tckrefactor branch shell scripts, since tckrefactor branch has maven.
As per my current understanding of https://www.eclipse.org/lists/jakartaee-tck-dev/msg02011.html final TCK must be available in both TCK license[EFTL] and project license[EPL], should we remove EFTL license?

[scottmarlow]

@scottmarlow - build shell scripts are being used in Ant/Java Test TCK generation. should we make changes to tckrefactor branch shell scripts, since tckrefactor branch has maven.

I agree that we don't need to update build shell scripts used in Ant/Java Test TCK generation.

As per my current understanding of https://www.eclipse.org/lists/jakartaee-tck-dev/msg02011.html final TCK must be available in both TCK license[EFTL] and project license[EPL], should we remove EFTL license?

The Platform TCK project should only maintain the project license (EPL + other licenses used as secondary licenses). Yes, we should remove the EFTL license as only the Jakarta EE Specification Committee https://ci.eclipse.org/jakartaee-spec-committee/job/promote-release job should release a final TCK currently.

[gurunrao]

@scottmarlow - build shell scripts are being used in Ant/Java Test TCK generation. should we make changes to tckrefactor branch shell scripts, since tckrefactor branch has maven.

I agree that we don't need to update build shell scripts used in Ant/Java Test TCK generation.

As per my current understanding of https://www.eclipse.org/lists/jakartaee-tck-dev/msg02011.html final TCK must be available in both TCK license[EFTL] and project license[EPL], should we remove EFTL license?

The Platform TCK project should only maintain the project license (EPL + other licenses used as secondary licenses). Yes, we should remove the EFTL license as only the Jakarta EE Specification Committee https://ci.eclipse.org/jakartaee-spec-committee/job/promote-release job should release a final TCK currently.

Based on console output at https://ci.eclipse.org/jakartaee-spec-committee/job/promote-release/304/console Specification committee Job doesn't update TCK with license, the job creates sha256 and sig files for TCK based on staged TCK.

1. Does the specification committee plan to update the job to include license within TCK bundle near future?
2. I am planning to remove EFTL license from staged WebSocket and Persistence TCK at https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee11/staged/eftl/ and add EPL license. Please refer to release review comment at WebSocket 2.2.0 release specifications#713 (review) on adding EFTL 1.1 license to Websocket TCK.

[scottmarlow]

@scottmarlow - build shell scripts are being used in Ant/Java Test TCK generation. should we make changes to tckrefactor branch shell scripts, since tckrefactor branch has maven.

I agree that we don't need to update build shell scripts used in Ant/Java Test TCK generation.

As per my current understanding of https://www.eclipse.org/lists/jakartaee-tck-dev/msg02011.html final TCK must be available in both TCK license[EFTL] and project license[EPL], should we remove EFTL license?

The Platform TCK project should only maintain the project license (EPL + other licenses used as secondary licenses). Yes, we should remove the EFTL license as only the Jakarta EE Specification Committee https://ci.eclipse.org/jakartaee-spec-committee/job/promote-release job should release a final TCK currently.

Based on console output at https://ci.eclipse.org/jakartaee-spec-committee/job/promote-release/304/console Specification committee Job doesn't update TCK with license, the job creates sha256 and sig files for TCK based on staged TCK.

Good point as https://github.com/jakartaee/specification-tools/blob/master/promotion/promote-release.sh#L58 doesn't seem to update the license which is different than I heard previously.

1. Does the specification committee plan to update the job to include license within TCK bundle near future?

2. I am planning to remove EFTL license from staged WebSocket and Persistence TCK at https://download.eclipse.org/ee4j/jakartaee-tck/jakartaee11/staged/eftl/ and add EPL license. Please refer to release review comment at [WebSocket 2.2.0 release specifications#713 (review)](https://github.com/jakartaee/specifications/pull/713#pullrequestreview-1962310692) on adding EFTL 1.1 license to Websocket TCK.

[scottmarlow]

Converting to draft so that we can keep the EFTL license around at least until a https://github.com/jakartaee/specification-tools/blob/master/promotion/promote-release.sh change could ensure that the correct TCK license is used.

[scottmarlow]

I think until the ^ promote-release.sh script can update TCKs with EPL license to EFTL, we will need to manually stage EPL TCKs to maven sonatype (or maven central) repos. When we are ready to build a final TCK for release, we will need to build with the EFTL license and copy the eftl zip to an Eclipse downloads EE 11 folder for the promotion script to copy from.