We were unable to reach any conclusions in the
Specification committee meeting today. It turns out
there is a rather complex list of license documents and
processes that need to be examined to make sure that we
don't inadvertently impact one or the other.
Thanks Ed for initiating the discussion!
I believe the conversation consensus was, essentially
-- keep doing what we have been doing in previous
releases and, common library components are not
"special" and should just be published under the project
license.
+1
More details:
For binary artifacts in a common library, so long as
there are no specification assertions that are somehow
contained within these components, these artifacts
should be published under the project license (for
Jakarta EE TCK project, I think that is dual-license,
EPL and GPL v2+CPE but you are welcome to confirm that).
There is nothing in the process that I am aware of, that
prevents publishing (and subsequently retrieving) these
to a Maven repository.
We created https://github.com/jakartaee/platform-tck/issues/1263
for checking if any other licenses should be added. The
output from the scancode tool that can be used to aid
updating the project license list is attached to the issue
(in the form of a html file in a zip).
For the TCKs, the Spec. committee would recommend
following the existing process -- all publications of
the TCKs (continuous build, milestone, pre-final, even
final) should be made using the project license.
+1
The TCK license should only be applied to the proposed
final release. The Spec. Committee will track the
SHA-SUM of the proposed final TCK. Finally, the Spec.
committee will compute a SIG-SUM, only after the
specification is accepted final. The project license
TCKs may be published to any location that is within the
project charter and it is my belief that the complete
TCK may be published to a Sonatype Maven repository.
+1
The Spec. committee was unable to reach any conclusion
regarding publication of Final specification TCKs to a
public Maven repository, though there was speculation
that there are specifications that may do this already.
I am not aware of any requirement, nor even any
desirability for publishing any TCK that is not proposed
final with a TCK license. Furthermore, the hash tracking
that the specification process provides has no facility
for ensuring that the archive has been obtained from one
location or another so if a final TCK were obtained from
maven central, that TCK would pass via all the HASH
checks (There may be a process requirement about
download location and that is one of the things that
needs further research by the Spec. committee).
Additionally, any pre-final TCK release that is promoted
to final (i.e. CI build, Milestone build, whatever,
promoted without rebuilding) will pass the HASH sum
checks. 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 realize this may force rerunning tests that have been
performed on pre-final releases but, until we are able
to work out additional details of the process and
license, we cannot make other recommendations.
CI, Milestone Release TCK -- any TCK build that is
published for early access and testing
+1
Proposed Final TCK -- TCK that is built with the intent
that this TCK will become a final release. SHA SUMs are
used to track these TCKs in CCRs that are created for
the purposes of the release ballot. Once a ballot has
started, a proposed final TCK may not be altered in any
way without invalidating the the current ballot for that
specification. We do not do this but we could designate
Accepted CCRs using TCKs with this SHA SUM as
provisional until the Specification is promoted to final
status. So far, this has not seemed necessary.
Final TCK -- A TCK that has been successfully ratified
and is part of a Final Specification. SHA SUM is tracked
and a when the ballot is successful, a SIG SUM is
computed for this TCK archive. CCRs with matching SHA
SUMs are now final complete (if we used the provisional
tag, we could remove that, but this is not currently
part of the process) -- We generally do not use the SIG
SUM but it is available as an additional check, if there
ever was any question about a specific TCK. It is my
understanding that Final TCK archives must be made
available under both the project license (since that is
the license the work was performed under) AND the TCK
license.
If you could, please reply with some specific problem
cases that you are encountering so that we can be sure
that the Spec. committee properly addresses the problems
you are experiencing.
There have been two problems in past EE releases:
1. Specification teams not having a consistent way to
know if the current staged TCK is the same one that they
already tested against. We applied a creative solution to
maintain a history of the past N staged TCKs but still, the
problem was not completely solved (e.g. we just published a
new 4.0.1 JAX-WS TCK that I thought was
already solved in the JAX-WS 4.0.0 TCK (issue link) which is a sign
that our current way of staging TCKs needs improvement).
Any TCKs that we publish to a Maven repository should have a
consistent name and not be a Maven snapshot release to
ensure consistency in the testing experience.
2. The other general problem with consistency in the
(Specification) testing experience is that not all pre-final
specification api releases are pushed to a public Maven
repository. This is a problem that impacts EE spec
implementations that want to participate (pre-final) in the
EE 11 development process but cannot since some pre-final
specification api releases are only pushed to the Jakarta staging repo which
leaves community projects out of the game. In a small way,
the Platform TCK team pushing pre-final TCK releases to a
public Maven repository should help some of the community
projects but time will tell if that really helps with
ensuring consistent access to pre-final TCKs.
3. For Jakarta EE 8/9/10/11 we have not emptied the TCK test
exclude lists which I think implies we are missing that in a
for-each-ee-release-review step. To be fair, I don't think we
have had the bandwidth as of yet to effectively empty TCK test
exclude lists. I echoed this via a pull
request comment here.
Thanks Ed!
Thank you.
-- Ed
On 3/20/2024 8:36 AM, Ed Bratt via jakartaee-tck-dev
wrote:
OK. I will raise the question about publishing
pre-final TCKs AS WELL AS the question about common
binary artifacts.
In the EE Platform meeting yesterday I had
thought that the question
being asked was: what license should be applied
to pre-final (e.g.
Milestone) releases of TCKs. It has been
suggested that there is a
question about how to publish common binary
artifacts that each
component TCK test system may need to consume to
perform the tests.
It is true that we also want to publish
common binary (Platform TCK) artifacts that may
be used by each Component TCK system for which
we intend to release milestone releases for if
allowed to do so.
Could you please clarify -- are you asking about
the requirements for
publication of a pre-final TCK, or are you
asking about requirements
implied for a set common utility artifacts?
I did mean to ask about publication of a
pre-final TCK but good point to ask about
requirements for a set of community utility
artifacts.
If you could describe the problem or potential
problem you have, today,
that would also be helpful.
Today or soon, I planned to complete a
milestone release of common (Platform TCK)
artifacts that may be used by Component TCK
system found in the Platform TCK.
I ask because, I believe that the TCK license
just applies to tests. Not
to the machinery used to run those tests. My
initial reaction would be
-- common binary artifacts should be licensed
under the TCKs 'project
license' only.
+100
If you can, please try to clarify within the
next hour since the Spec.
committee begins a 9 AM pacific daylight time
(65 minutes from now).