| Re: [ee4j-pmc] Fwd: GPL code in Jakarta EE repos |
Jakarta EE TCK provides the Technology Compatibility Kit (TCK) used for testing Jakarta EE implementations for Jakarta EE specification compliance.
_______________________________________________No concerns from my side.+1IvarOn Tue, Jan 30, 2024 at 2:25 PM Scott Stark via ee4j-pmc <ee4j-pmc@xxxxxxxxxxx> wrote: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.