Triplea: Some dependencies are incompatible with GPLv2

[ssoloff]

(As suggested, this issue is being repurposed to track all dependencies that are not compatible with GPLv2.)

We've discovered a few dependencies that use licenses that are incompatible with GPLv2. The table below is a compatibility matrix for all of our production and test dependencies. Transitive dependencies are not considered; it is assumed the license of each dependency is compatible with their own dependencies. I included a separate column for GPLv3 because some licenses are compatible with GPLv3 but not compatible with GPLv2

Binary dependencies

Dependency | License | GPLv2 | GPLv3 | Notes
:-- | :-- | :-- | :-- | :--
com.github.junit-team.junit5-samples:junit5-mockito-extension | EPL-1.0 | 🚫 | 🚫 |
com.github.openjson:openjson | Apache-2.0 | 🚫 | ✔️ |
com.google.code.findbugs:jsr305 | Apache-2.0 | 🚫 | ✔️ |
com.google.guava:guava | Apache-2.0 | 🚫 | ✔️ |
com.googlecode.soundlibs:jlayer | LGPL-2.1-or-later | ✔️ | ✔️ |
com.sun.mail:javax.mail | GPL-2.0-only | ✔️ | 🚫 |
com.yuvimasory:orange-extensions | BSD-3-Clause | ✔️ | ✔️ |
commons-cli:commons-cli | Apache-2.0 | 🚫 | ✔️ |
commons-codec:commons-codec | Apache-2.0 | 🚫 | ✔️ |
commons-io:commons-io | Apache-2.0 | 🚫 | ✔️ |
nl.jqno.equalsverifier:equalsverifier | Apache-2.0 | 🚫 | ✔️ |
org.apache.commons:commons-math3 | Apache-2.0 | 🚫 | ✔️ |
org.apache.httpcomponents:httpclient | Apache-2.0 | 🚫 | ✔️ |
org.apache.httpcomponents:httpmime | Apache-2.0 | 🚫 | ✔️ |
org.apiguardian:apiguardian-api | Apache-2.0 | 🚫 | ✔️ |
org.hamcrest:java-hamcrest | BSD-3-Clause | ✔️ | ✔️ |
org.junit.jupiter:junit-jupiter-api | EPL-2.0 | 🚫 | 🚫 | See (1) below
org.junit.jupiter:junit-jupiter-engine |EPL-2.0 | 🚫 | 🚫 | See (1) below
org.junit.platform:junit-platform-launcher | EPL-2.0 | 🚫 | 🚫 | See (1) below
org.mindrot:jbcrypt | ISC | ✔️ | ✔️ |
org.mockito:mockito-core | MIT | ✔️ | ✔️ |
org.postgresql:postgresql | BSD-3-Clause | ✔️ | ✔️ |
org.slf4j:slf4j-nop | MIT | ✔️ | ✔️ |
org.sonatype.goodies:goodies-prefs | Apache-2.0 | 🚫 | ✔️ |
org.yaml:snakeyaml | Apache-2.0 | 🚫 | ✔️ |
Substance | BSD-3-Clause | ✔️ | ✔️ |
Trident | BSD-2-Clause | ✔️ | ✔️ |

Source dependencies

Dependency | License | GPLv2 | GPLv3 | Notes
:-- | :-- | :-- | :-- | :--
JUnit 5 Experiments | EPL-2.0 or GPL-2.0-or-later | ✔️ | ✔️ | See (2) below

Notes

1. The JUnit EPL-2.0 is _not_ customized to specifically designate GPL-2.0-or-later as a secondary license, and therefore remains incompatible.
2. This is source code we have copied into the org.junit.experimental.extensions package and subsequently modified.
3. This is source code we have copied into the games.strategy.util package. It's not clear if this code was licensed under GPLv1 or GPLv2, but it definitely does not include the "or later" clause.

---

Tasks

• [x] Change the source dependency on MockitoExtension to a binary dependency.
• [x] Replace MD5Crypt with Apache Commons Md5Crypt.
• [x] Upgrade _LICENSE_ to GPL-3.0-or-later.
• [x] Add exceptions for the remaining binary dependencies that are incompatible with GPL-3.0.
• [x] Update license badge in README.
• [x] Change license text in About dialog.
• [x] Change license text on website.

---

Original issue description

The classes in the org.junit.experimental.extensions package that we copied into the codebase several weeks ago are licensed under the terms of the Eclipse Public License v1.0, which is incompatible with GPLv2.

We need to either find GPLv2-friendly alternatives or write equivalent extensions ourselves.

[ssoloff]

Annnnnd include TemporaryFolder and TemporaryFolderExtension, which are also licensed under EPLv1 (https://github.com/rherrmann/junit5-experiments/blob/master/LICENSE). I'll update the description.

[RoiEXLab]

Just an idea, that just came to my mind.
We're pretty much stuck with the GPL license on the main codebase, but we should be able to change the license for the test code only.
Thoughts?

[ssoloff]

Interesting idea. It would be great if we could find another OSS project that has such a dual-licensing model for test and production code to use as an exemplar.

[ssoloff]

After a bit of research, I'm not sure the dual-license model will work simply because the unit and integration test code is effectively a _derivative work_ of the production code (the magic phrase in the GPL).

The way the unit and integration tests are built seems to be equivalent to statically linking in the production code (a bunch of class [object] files linked together into the same process). Even if we were to use the equivalent to dynamic linking in the Java world (i.e. jar files), there's still some argument as to whether dynamically linking to a library creates a derivative work.

The only clear case of a non-derivative work were if our tests communicated with the production code via some kind of IPC mechanism, such as sockets, pipes, or the command line. That is, more akin to system-level tests. In that case, it seems straightforward to conclude that the test code could be released under a license other than the GPL.

[RoiEXLab]

@ssoloff You might want to increase the scope of this issue to adress all code we depend on.
Like guava.

[RoiEXLab]

I just got an ad showing me this
Seems promising to me, and might help to fix this issue in the future.

[ssoloff]

@RoiEXLab Good suggestion. I repurposed the issue to track all incompatible dependencies. I added a table to the description where we can track the compatibility of each dependency. It currently consists of mostly placeholders. I'll try to complete it in the next few days (or anyone can feel free to fill in a few rows if they like). The license identifiers come from the canonical list at SPDX.

[ssoloff]

@DanVanAtta @RoiEXLab @ron-murhammer The license compatibility table in the description is complete. Please review when it's convenient.

It should be obvious if we move to GPLv3, then almost all the compatibility issues go away.

The only remaining problem is still the JUnit 5 extensions that we copied into our codebase. Since all this code is licensed under EPL-1.0, another possible solution to those proposed above could be to ask the authors to upgrade to EPL-2.0 and designate GPLv2+ as a secondary license.

[ssoloff]

@RoiEXLab Did you consider using the JUnit 4 Rule adapters when you were upgrading JUnit to v5? It looks like that could be another alternative, at least for TemporaryFolderExtension.

[RoiEXLab]

@ssoloff Heard about those, but I didn't consider this option, simply because I wanted to get rid of the JUnit 4 dependency entirely.
I think it would be easier to rewrite such a utility class on out own, if that's too complicated we can just write a small utility class with a single static method that creates a temporary file...
The "solution" to the MockitoExtension problem would be to use Mockito#mock instead of the annotation, not that pretty, but it would work.

[RoiEXLab]

About this issue in general:
Given that there are more "incompatible" dependencies than I though, we should perhaps at least try to contact the original authors?
If that fails I guess we can debate whether or not TripleA is still the same code it used to be when the project originally started, just like you can debate whether a broom is still the same broom after you switched the handle and the bristles at 2 different points in time, git blame could potentially act as a proof? 😅
I really have no idea on how to handle this issue otherwhise

[ssoloff]

As IANAL, I made a rookie mistake reviewing the JUnit 5 EPL-2.0 license. They never explicitly opted-in to GPL-2.0-or-later, as required by EPL-2.0:

Exhibit A - Form of Secondary Licenses Notice

“This Source Code may also be made available under the following Secondary Licenses when the conditions for such availability set forth in the Eclipse Public License, v. 2.0 are satisfied: {name license(s), version(s), and exceptions or additional permissions here}.”

Simply including a copy of this Agreement, including this Exhibit A is not sufficient to license the Source Code under Secondary Licenses.

If it is not possible or desirable to put the notice in a particular file, then You may include the notice in a location (such as a LICENSE file in a relevant directory) where a recipient would be likely to look for such a notice.

You may add additional accurate notices of copyright ownership.

The key part here is _Simply including a copy of this Agreement, including this Exhibit A is not sufficient to license the Source Code under Secondary Licenses._ I searched for an explicit grant of secondary license in their repo but came up empty. So, in light of this, I'm going to update the table to state that EPL-2.0, as used by JUnit, is not compatible with the GPL.

---

This got me re-thinking this issue, specifically the point @RoiEXLab brought up above about dual-licensing and the test code. I kind of dismissed that using the _derivative work_ argument. However, as this SO question discusses, the GPL allows authors to provide exceptions for calling non-GPL code in their GPL-based work. I've quoted the key paragraphs below:

Can GPL-licensed code call the EPL-licensed JUnit library? The case 2. applies and this very similar to using OpenSSL. Therefore technically, you could/should not apply the bare GPL to your test code. And you should provide your test code calling JUnit under the GPL with some exception in the same way GPL-licensed code using OpenSSL typically uses such an exception.

Now practically (unless you are building a test framework based on JUnit) none may really cares about the licensing of your test code: JUnit is open source and may not be GPL-compatible. Its license requirements do not flow backward. So every GPL project that may call JUnit does that without much ceremony even if technically they should.

I guess we could reasonably make an argument that including an exception, as described above, would work for JUnit since we are using it via a jar (or just use the "nobody cares about test code" argument from the SO answer :smile:). However, I'm still not sure about the JUnit extensions, since they are included as source in our project.

[ssoloff]

I received a nod from the author of the TemporaryFolderExtension class to upgrade its license to EPL-2.0 with an explicit grant of GPL-2.0-or-later as a secondary license. I just need to submit a PR to that repo for final approval.

@RoiEXLab Did you get MockitoExtension from here? If so, they are in the process of upgrading their license to EPL-2.0. I can try asking the JUnit team if they would consider adding GPL-2.0-or-later as a secondary license. It should be much easier to get the secondary license for the samples (as opposed to JUnit proper) given that the contributions were fairly recent and the number of contributors are small (apparently EPL-2.0 requires all contributors to agree to GPL-2.0-or-later being deemed a secondary license).

[RoiEXLab]

@ssoloff Yes, that's where the code is from

[DanVanAtta]

License violation is a higher priority than average, marking this as a p1+release blocker to reflect that.

[ssoloff]

The owner of the JUnit 5 Experiments project has graciously upgraded that repo's license to EPL-2.0 or GPL-2.0-or-later. I've updated the license compatibility table appropriately.

[prastle]

noob ? but do we still need certs after this accountant home from holidays tomorrow?
@ssoloff @RoiEXLab

[RoiEXLab]

@prastle This issue is completely unrelated to this topic.
License incompatibility means that the people who wrote the code made some restrictions to the allowed usage of their code which is incompatible with the restrictions of the licence triplea is using (GPL-2.0)

[prastle]

oki dokie i will keep moving on with accountant

[ron-murhammer]

@RoiEXLab @ssoloff Do we have a short-term path forward on this? This is probably the only major issue that remains that might be worth addressing before we start breaking compatibility.

[ssoloff]

@ron-murhammer The easiest way forward would be to upgrade our license to GPLv3. That will ensure all _production_ libraries we use are compatible with our license. I need to research if moving from GPL-2.0-or-later to GPL-3.0-or-later requires all contributors to agree. I'll look into that today.

I've submitted a PR to JUnit to allow us to depend on MockitoExtension as a binary instead of including the source directly in our repo. Even though this extension and JUnit itself will still be incompatible with the GPL (any version), we should be able to apply exceptions for these specific libraries to the license that covers our test code.

[ron-murhammer]

@ssoloff Sounds good. We can hold off for a bit then to start incompatible changes until we determine if we can address this in the short-term.

[ssoloff]

@ron-murhammer There is a pretty good write-up of OSS re-licensing here. Some points of note:

• Registered vs. unregistered copyright holders. There are currently no copyright notices in our code (except in MockitoExtension, which will be removed). I didn't search through the history, so I don't know if such notices used to exist. If such notices did exist in the past, I don't know if we can assume their removal equated to consent of the author(s) to give up their copyright. However, if any contributor did assert copyright, I seriously doubt the author(s) registered their copyright (which seems to be key to having legal status to object to a license change).
• Substantive license change. The text makes a distinction between a substantive license change (e.g. moving from a copyleft license to a non-copyleft license) vs. one that is not. It suggests that non-substantive changes do not have the same requirements of obtaining contributor agreement. The text actually uses changing from GPL to OSL for a standalone application as a practical example of a non-substantive license change. My non-lawyer opinion is that moving from GPLv2 to GPLv3 is probably not substantive.

Another scenario to consider is this... AFAICT, TripleA has always been licensed under GPL-2.0-or-later. The "later" part means that anyone can fork this project and license it using GPL-3.0 without obtaining the consent of any contributor. If that right extends to derivative works, why could the TripleA project itself not make use of the same right? I don't know if an official fork would be required in that case, or if the fact that the legacy GPLv2-licensed source code is still made available would be sufficient.

I think I mentioned this before, but it would be great if there was an IP lawyer in the TripleA community who could "donate" their opinion on this matter. Do you think a forum post soliciting such advice would be helpful?

---

To avoid problems in the future with re-licensing, I would suggest we consider using a Contributor License Agreement. I will open a separate issue to discuss this.

[RoiEXLab]

@ssoloff Thanks for the research. A CLA might be a good idea 👍

[RoiEXLab]

@ssoloff @ron-murhammer @DanVanAtta
Regarding the GPL update: We are probably not going to be able to get all past contributors to this project, to agree on a license update, or even just to sign a CLA, however the important question is whether they are going to sue us or not.
So let's say someone of the original contributors (or even some of the smaller contributors that introduced one or 2 classes), claim their copyright on a part of the code, what would prevent us from changing the affected lines (we can use git blame to see who last changed the lines) to something else? I'd argue that the current code base consists to 95% of code written by me, @ron-murhammer , @DanVanAtta , @ssoloff and @veqryn

[DanVanAtta]

I don't think any of the past contributors would want to sue the project, and if they did have an objection I would be fully inclined to respect that and not change the license.

For me, the issue is that it is hard to clearly identify who they all would be, and to contact them all.

If that right extends to derivative works, why could the TripleA project itself not make use of the same right?

I'm pretty inclined to agree with that reasoning.

[prastle]

agree

[RoiEXLab]

@DanVanAtta

I don't think any of the past contributors would want to sue the project, and if they did have an objection I would be fully inclined to respect that and not change the license.

I agree, but my point is, that if they have any objections we have essentially found a way to contact them ^^
Jokes aside, I think we should try to contact as much people as possible, and if they don't respond assume they don't care enough, or changed their email, but proceed if no objections are being raised.

[prastle]

sadly the npo is taking a while @RoiEXLab

[prastle]

but it will get there
but above is a valid point

[RoiEXLab]

@prastle No problem, if we have anything then it's time.
But I'd recommend PMing me for information about this, so this issue doesn't change the topic ^^

[prastle]

its two sep things I thought?
but np @RoiEXLab

[ssoloff]

the important question is whether they are going to sue us or not

Note that the paper I referenced above makes several points about who would have legal standing to bring a lawsuit:

If all copyrights other than yours are unregistered, you may change the license and no other copyright holder has standing to object, unless they can show that the license change has caused them actual monetary damages.

(Note that the above quote is in the context that the project lead has a _registered_ copyright.)

In theory under the Berne Convention, anyone but you who has contributed code also has a copyright in that portion of the work. In practice, only holders of registered copyrights in the code are likely to even get standing to object.

First, only registered holders of copyright have standing to object on statutory grounds; an unregistered holder must show actual (monetary) damages from the license change.

---

As I stated previously, I seriously doubt there are currently any _registered_ copyright holders on TripleA. It might be worth getting @ron-murhammer or @veqryn to register a collective-work copyright:

We recommended earlier that if you are a project leader, you should assert a collective-work copyright on the project.

Make yourself the copyright holder if your primary concern is maintaining the flexibility to choose and alter the license terms. Making FSF the copyright holder will put some lawyers and funding on your side, but the FSF will be reluctant to accept a non-GPL license, and might at some future date change yours.

---

Apparently, the FSF has a "licensing support" email. From https://www.fsf.org/licensing:

Have a question that you couldn’t find the answer to? For general free software licensing questions please email [email protected].

Maybe they can help us resolve what we need to do to move from GPLv2 to GPLv3?

[prastle]

Roi brought up a valid point in our gitter chat so to make sure everyone understands what I meant I will clarify a bit.

There isn't much point of getting an npo etc if we need every person that ever contributed to TripleA to sign off.

[prastle]

Thus even tho it is two separate things the one really does concern the other.

[ron-murhammer]

@ssoloff @RoiEXLab @DanVanAtta So I believe many of the source files originally had "license headers" on them but we removed this when the files were moved over to github so that it was cleaner to just have the license file. Looking through the history though many of the files actually specified GNU GPL v2 or later: https://sourceforge.net/p/triplea/code/1691/tree/trunk/triplea/src/games/strategy/triplea/delegate/TransportTracker.java

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

Given this, I feel we have a pretty good case on upgrading the license to either GPLv2+ or GPLv3+.

@veqryn @sbridges Any thoughts on this topic? I think outside of the active developers (myself, @RoiEXLab, @DanVanAtta, @ssoloff), the primary historical developers were the 2 of you and comradekev.

[ssoloff]

@ron-murhammer Sorry, I've been periodically loose with my license terminology. When I've said in places that TripleA is GPLv2, I should have said GPLv2+ or GPL-2.0-or-later, as your research confirmed. Therefore, we are already GPLv2+, and the question on the table is upgrading GPLv2+ to GPLv3+ (GPL-3.0-or-later).

[veqryn]

TripleA has always been GPLv2-or-later-versions.

[veqryn]

Can we put the EPL dependencies under a class-path exception?
https://www.gnu.org/software/classpath/license.html

[ssoloff]

@veqryn Yes, I think that's going to have to be the plan, as the JUnit team doesn't seem to be in a position to add GPL-2.0-or-later as a secondary license. They are in the same situation as TripleA in that their project is so old, and they can't seem to track down all previous contributors to agree to that license change.

[veqryn]

I noticed that jUnit5 proper doesn't have a single issue related to getting secondary licensing under GPLv2-or-later. It would be worth creating an issue about that, and then everyone here can +1 it: https://github.com/junit-team/junit5/issues?utf8=%E2%9C%93&q=gpl

[sbridges]

Not a lawyer, but I think if it's already GPL v2+ you can publish it under GPL V3+.

Regardless, I'm fine with GPL V3+ or GPL V2+.

[ssoloff]

Sorry, another mistake slipped through... The com.sun.mail:javax.mail dependency uses GPL-2.0-only, which would not be compatible with GPL-3.0. I updated the table to reflect this. Not a big deal though, as we would just have to add an exception for this library to the license, as we discussed doing with the JUnit stuff.

---

I went ahead and sent off an email to the FSF licensing team asking them to confirm the conclusion that multiple participants in this thread have come to: that GPL-2.0-or-later allows us to upgrade to GPL-3.0-or-later without getting 100% agreement from all past contributors.

[ssoloff]

Here's the response from the FSF (I highlighted the important part):

Hello and thank you for writing in.

Apologies in advance if this isn't an appropriate question for the FSF
licensing team. I was unable to find a straightforward answer to my
question in the FAQ, and I don't have access to an IP attorney.

I am not a lawyer, and we do not provide legal advice. But I'll be happy
to help you with understanding the GPL.

I'm a committer on a very old GPL-2.0-or-later project that has had
numerous contributors over 15+ years. The current team would like to
upgrade the license to GPL-3.0-or-later. However, the project leads
never registered any form of collective copyright, and it is unlikely
we could track down all of the past contributors to solicit their
agreement on the license upgrade. The team's non-legal-professional
consensus is that we would not need to get past contributor agreement
because, if the provisions of GPL-2.0-or-later allow a derivative work
to use any later version of the GPL, then that right would seem to
extend to the original work itself.

We would very much appreciate an opinion if upgrading from
GPL-2.0-or-later to GPL-3.0-or-later is possible without past
contributor agreement.

I understand from your description that the project has been distributed
all this time under the implicit assumption that these contributions
were GPLv2+.

GPLv2 "or later" (aka GPLv2+) can be upgraded to any newer version of
the GPL, including GPLv3+ without additional permission from the
copyright holder/s. This permission is already granted in section 9 of
GPLv2 (section 14 in GPLv3). If you know a work is GPLv2+ you may
upgrade it at your own discretion.

--
I am not a lawyer, the above is not legal advice

Regards, Yoni Rabkin

The services of the GPL Compliance Lab are made possible by
donations from people like you. Please consider supporting us
today by becoming a member [https://my.fsf.org/join] or by making
a donation [https://www.fsf.org/donate].

---

So it looks like we're good to upgrade to GPL-3.0-or-later.

The remaining tasks for this issue are

1. Upgrade _LICENSE_ to GPL-3.0-or-later.
2. Once junit-team/junit5-samples#53 is merged, change the source dependency on MockitoExtension to a binary dependency.
3. Add exceptions for the remaining (5) binary dependencies that are incompatible with GPL-3.0.

While we're waiting for the PR in (2) to be merged, I'll research how other projects note exceptions to the GPL.

[RoiEXLab]

👍

[ssoloff]

I moved the task list to the issue description for better visibility (and added one new task).

---

Boogers.... A quick grep of the source tree shows another potential issue: the MD5Crypt source copied into the codebase is licensed under "the GNU General Public License." The lack of a version and the "or later" clause could be a problem.

@RoiEXLab When you were enhancing security a few months ago, did you by any chance check to see if the Apache Md5Crypt is equivalent to our MD5Crypt? Not necessarily in terms of API (which it's not), but at least in terms of implementation so that they produce the same values? If not, I'll run some tests to check their equivalence because that would be the easiest way to fix this problem.

[RoiEXLab]

@ssoloff No I didn't check anything, I didn't even know this class existed

[ssoloff]

Switching from MD5Crypt to Apache Commons Md5Crypt will introduce some functional changes. In order to avoid hijacking this issue, I opened #2901.

I also updated the license compatibility table with an entry for MD5Crypt.

[ssoloff]

The task "Change the source dependency on MockitoExtension to a binary dependency" is now complete. The license compatibility table has been updated appropriately.

I also split the table into binary and source dependencies to make it easier to distinguish these two cases.

[ssoloff]

The task "Replace MD5Crypt with Apache Commons Md5Crypt" is now complete. I removed the MD5Crypt entry from the source dependency table and added an entry for commons-codec:commons-codec to the binary dependency table.

[ssoloff]

All tasks are now complete. Closing.