I agree from the scope perspective especially, I assume, as the project is doing this to meet the needs of the TCK project in the first instance.
I assume the project is not going to maintain the fork as a generic signature testing tool as a primary goal.
|
--
|
|
Steve
Millidge
Founder & CEO
|
From: ee4j-pmc <ee4j-pmc-bounces@xxxxxxxxxxx>
On Behalf Of Scott Stark via ee4j-pmc
Sent: Wednesday, January 31, 2024 7:24 AM
To: EE4J PMC Discussions <ee4j-pmc@xxxxxxxxxxx>
Cc: Scott Stark <starksm64@xxxxxxxxx>
Subject: Re: [ee4j-pmc] Fwd: GPL code in Jakarta EE repos
It exactly meets that scope statement from the Red Hat viewpoint as its current usage in the TCKs of Jakarta is the validation of Jakarta APIs included in a compatible implementation with those expected by the
TCK as defined by the signature files produced by the sigtest tool when the TCK distribution was created. The sigtest tool is then run as part of the TCK to verify the compatible implementation APIs in the jakarta.* namespace against the TCK distribution signature
files.
To be clear, the concern that I asked Scott to direct to the PMC is that I am not certain that the content being brought to the project is in scope.
The scope of the Jakarta EE TCK project is this:
Jakarta EE TCK provides the Technology Compatibility Kit (TCK) used for testing Jakarta EE implementations for Jakarta EE specification compliance.
Is this scope inclusive of the development, maintenance, and dissemination of a signature test tool?
Based on what I know about the nature of the library, I'm thinking that the answer is probably yes, but only if you squint.
It would be handy if multiple PMC members could weigh in.
No concerns from my side.
Hello PMC.
There was a discussion on the platform-dev list about forking the
signature test project into the tck-tool project, but then there was a
concern about the GPL nature of the project. This is the email I sent
to the EMO to ask if there were any concerns about being able to fork
this project into a Jakarta project, and their response indicates this
should not be a problem barring any other concerns raised from a
deeper dive.
Does the PMC have any concerns about this?
Thanks,
Scott
---------- Forwarded message ---------
From: Eclipse Management Office EMO <emo@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, Jan 30, 2024 at 3:14 PM
Subject: Re: GPL code in Jakarta EE repos
To: Scott Stark <sstark@xxxxxxxxxx>
Hey Scott.
We have historically had a problem with the GPL, so there may be a few
people from the old guard who are raising flags. We also tend to push
back against creating forks, but that's in a context of it being
better for everybody to push content upstream and that's clearly not
an option here.
Under our current IP Policy, what's important is that the licences of
content are consistent when content is combined and used, and that
they meet the goals of the project and Eclipse Foundation.
Based on what you've described, I believe that it's accurate to state
that this content doesn't actually link with other project content, so
its licence has no impact on the project code.
It may be out of scope for the Jakarta EE TCK project. I recommend
that you reach out to the PMC and get their buy-in and approval before
you proceed. To be clear, I don't think that there should be any need
to change any project configuration (e.g., there is no need change the
scope or the declared license of the project).
I ran the top commit of the repository through IPLab and the licencing
looks pretty consistent. I'll get the IP Team to do a more complete
review, but I don't anticipate any challenge to approve this.
Assuming that my understanding of the relationship between this
content and the rest of the project content is accurate, that the PMC
signs off, and the IP Team doesn't find anything that's particularly
nasty, I believe that it would be okay for the Jakarta EE TCK project
to create and maintain a fork of this project under the current
licence.
If you haven't already done so, please create an issue to track this.
I can state something like the above on the issue.
HTH,
Wayne
On Mon, Jan 29, 2024 at 7:42 PM Scott Stark <sstark@xxxxxxxxxx> wrote:
>
> The Jakarta EE projects have used a signature test artifact as part of
> the TCK since its inception. This originally came from the OpenJDK
> JavaTest framework, but had moved out to the netbeans project under
> this repo:
> https://github.com/jtulach/netbeans-apitest
>
> The project license is GPLv2
> https://github.com/jtulach/netbeans-apitest/blob/master/legal/license.txt
>
> But the output from running the artifact binary maven-plugin to
> produce the signature test files used by and included in the TCKs can
> be licensed however the user wants. Thus they are either EPL or Apache
> licensed.
>
> This repo has no issue support, so there is no way to communicate with
> the project to request changes. There was a discussion about forking
> this project into the tck tools project:
> https://github.com/eclipse-ee4j/jakartaee-tck-tools
>
> but this was before the GPL license was known. The question to the EMO
> is therefore, does the GPLv2 license of the signature test code
> disallow for incorporation into a Jakarta repository?
>
> If it does, we can work around this by continuing to produce the
> artifact from another repository fork and continue to use it in TCK
> projects as a third-party artifact as is currently done.
>
> Thanks,
> Scott
>
--
The Eclipse Management Organization | Eclipse Foundation
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
--
Ivar Grimstad
Jakarta EE Developer Advocate |
Eclipse Foundation
Eclipse Foundation - Community. Code.
Collaboration.
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
--
Wayne Beaton
Director of Open Source Projects |
Eclipse Foundation
My working day may not be your working day! Please don’t feel obliged to read or reply to this e-mail outside of your normal working hours.
_______________________________________________
ee4j-pmc mailing list
ee4j-pmc@xxxxxxxxxxx
To unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/ee4j-pmc
|
