Upgrade licenses to EPL v2
Closed this issue · 12 comments
Deliverables
- Update license in root directory to EPL v2
- Remove license files in sub-directories
Projects Already Using EPL v2
- junit5-gradle-consumer
- junit5-maven-consumer
- junit5-mockito-extension
- junit5-vanilla-gradle
- junit5-vanilla-maven
- junit5-vanilla-modules
- junit5-java9-engine
Would the JUnit team consider designating GPL-2.0-or-later as a secondary license for the JUnit 5 samples as part of the EPL-2.0 upgrade process? Unlike JUnit 5 proper, this seems more realistic for the samples because there are a fewer number of more-recently-active contributors who would have to be consulted to sign-off on the addition of the secondary license.
Context: My team would like to use junit5-mockito-extension in a GPL-2.0 project. Since this extension is not available in binary form, we'll have to include the extension sources directly in our codebase. IANAL, but I don't think the GPL mechanism for adding exceptions when calling GPL-incompatible libraries extends to the scenario of including GPL-incompatible sources. Therefore, it would make us more comfortable if the sample extensions (or at least junit5-mockito-extension) were also licensed under GPL-2.0-or-later, as EPL-2.0 permits.
Since this extension is not available in binary form
If that's the only issue for you, we could start tagging the samples which would allow you to use JitPack to depend directly on a built binary.
Would that work for you?
@sbrannen Thanks for pointing out JitPack. We could have used a service like that several times in the past year. 👍
I created a spike branch to test your proposal. It appears JitPack is getting a bit confused with the layout of this repo when I use the coordinates com.github.junit-team:junit5-samples:f9af028f (I suspect it's the multiple sub-project roots that exist under the repo root). The resulting jar that JitPack creates only contains the classes from the junit5-gradle-consumer sub-project:
ssoloff@localhost ~/.gradle/caches/modules-2/files-2.1/com.github.junit-team/junit5-samples/f9af028f/80ca55def03ed9a3ee6a68a38b40bcdecbb011d0
$ unzip -l junit5-samples-f9af028f.jar
Archive: junit5-samples-f9af028f.jar
Length Date Time Name
--------- ---------- ----- ----
0 01-15-2018 14:55 META-INF/
25 01-15-2018 14:55 META-INF/MANIFEST.MF
0 01-15-2018 14:55 com/
0 01-15-2018 14:55 com/example/
0 01-15-2018 14:55 com/example/project/
401 01-15-2018 14:55 com/example/project/Calculator.class
--------- -------
426 6 files
I couldn't find any information in the JitPack docs about sub-projects. However, I came across an open issue related to this problem. I tried the coordinates com.github.junit-team.junit5-samples:junit5-mockito-extension:f9af028f, but as the OP in the above issue noted, JitPack does not successfully resolve them.
Are you aware of any additional configuration I can provide to JitPack to get it to address a specific sub-project within the repo?
Are you aware of any additional configuration I can provide to JitPack to get it to address a specific sub-project within the repo?
No. To be honest, I've never tried JitPack with a subproject.
If you can't get it to work, just let us know.
I'm sure we'll find a solution.
For example, I'd be willing to publish (and tag) the MockitoExtension in my personal GitHub repository as a stand-alone project if necessary. 😉
@ssoloff, I just added apply plugin: 'maven' to the build.gradle file for the Mockito extension project, which JitPack team says is required.
What happens if you use JitPack now?
All you need is to "maven install" the jars in jitpack's workspace. See for example here: https://github.com/sormuras/bach/blob/master/jitpack.yml
Edit: might not help here, as jitpack does not know into which sub-directory it has to dive in.
Theses sample projects are not meant to be released in binary form, anyway.
https://github.com/junit-pioneer/junit-pioneer should really lift off some day in the near future ... @nicolaiparlog ;)
@sbrannen Unfortunately, no joy with the new coordinates com.github.junit-team:junit5-samples:3991514:
ssoloff@localhost ~/.gradle/caches/modules-2/files-2.1/com.github.junit-team/junit5-samples/3991514/e11f9aeb1d602912db87555f1290e672ff24623b
$ unzip -l junit5-samples-3991514.jar
Archive: junit5-samples-3991514.jar
Length Date Time Name
--------- ---------- ----- ----
0 01-15-2018 18:20 META-INF/
25 01-15-2018 18:20 META-INF/MANIFEST.MF
0 01-15-2018 18:20 com/
0 01-15-2018 18:20 com/example/
0 01-15-2018 18:20 com/example/project/
401 01-15-2018 18:20 com/example/project/Calculator.class
--------- -------
426 6 files
I'm assuming @sormuras's comment was directed at a change that would have to be applied to the junit5-mockito-extension project for JitPack to "see" the artifacts you want published after JitPack builds the project locally. Let me fork this repo and see if I can get that to work. If I'm successful, I'll submit a PR back here.
FWIW there's mockito/mockito#445 for an official Mockito extension.
@sbrannen Ok, following @sormuras's hint, I was able to get JitPack to publish junit5-mockito-extension at the expected coordinates from my fork. (If applied to this repo, the group ID would be com.github.junit-team.junit5-samples, and the artifact ID would be junit5-mockito-extension.) Once I had a published artifact, I confirmed my project's build was able to make use of MockitoExtension successfully. So, the answer to your original question is yes, using a binary dependency via JitPack will work for my project. (We'll probably need to add an exception for this GPL-incompatible library to our license, but I think that will be ok.)
I ran into one limitation with JitPack that may sour you on my solution. If one doesn't publish at least two artifacts during a JitPack build, it won't recognize it as a multi-module project, and will publish the single artifact using the coordinates of the repo itself. (If applied to this repo, the group ID would be com.github.junit-team, and the artifact ID would be junit5-samples. Even though the resulting artifact would contain only the content of the junit5-mockito-extension subproject.) So I had to publish at least one other subproject to get my spike to work; I chose junit5-gradle-consumer for no particular reason.
You can review my proposed changes here. Please let me know if you think it's worth opening a PR for this particular solution. It does have an additional smell, though... I believe this would make the third copy-paste of the subproject build commands (Jenkins, Travis, and now JitPack).
@ssoloff Thanks for finding a solution! I think the maintenance burden for the build commands should be manageable. I think there are other users who might benefit from it. So, a pull request would be appreciated! 🙂
👍 for GPLv2-or-later secondary license please