The mpich [1] and mpich2 [2] licenses are identical aside from the name (have the same checksum). The mpich2 license, used for sys-cluster/mpich2, is in the @FREE license set. The mpich license, used for sys-cluster/mpich, is not. This seems like a mistake, but I am not a lawyer. According to bug #547208, sys-cluster/mpich (license not in @FREE) is the recommended package for people using currently using sys-cluster/mpich2 (license in @FREE), which is planned to be removed. This prevents switching without allowing a license not in @FREE. Is this intended? Thanks. [1]: https://gitweb.gentoo.org/repo/gentoo.git/plain/licenses/mpich [2]: https://gitweb.gentoo.org/repo/gentoo.git/plain/licenses/mpich2
Confirmed: diff licenses/mpich* Files are identical. The only consumers are sys-cluster/mpich sys-cluster/mpich2 sys-cluster/mpe2 I think we can reduce it to one license "mpich" and update the ebuilds. I add the maintainers to CC, please check if we miss something. For example: "Is our mpich2 file wrong and there is another license upstream?..." The license team will review the remaining mpich* licenses afterwards and check the categories. see also: https://github.com/pmodels/mpich/blob/master/COPYRIGHT mpich source tree ships code with other licenses too. Do we use it? Do we have to include it in the LICENSE? (example: https://github.com/pmodels/mpich/tree/master/contrib)
(In reply to Jonas Stein from comment #1) > Confirmed: diff licenses/mpich* > Files are identical. > > The only consumers are > sys-cluster/mpich > sys-cluster/mpich2 > sys-cluster/mpe2 > > I think we can reduce it to one license "mpich" and update the ebuilds. > > I add the maintainers to CC, please check if we miss something. > For example: "Is our mpich2 file wrong and there is another license > upstream?..." I agree to the above, except that licenses/mpich2 should be kept and licenses/mpich should be deleted: - In case of duplicates, we regularly delete the newer file, which is mpich. - Fedora lists the license as "MIT, mpich2 variant": https://fedoraproject.org/wiki/Licensing:MIT#mpich2_variant - mpich2 is the name used in bug 449344 and in license groups. > The license team will review the remaining mpich* licenses afterwards and > check the categories. Already done in bug 449344, and mpich2 was added to @MISC-FREE. > see also: > https://github.com/pmodels/mpich/blob/master/COPYRIGHT > mpich source tree ships code with other licenses too. Do we use it? Do we > have to include it in the LICENSE? > (example: https://github.com/pmodels/mpich/tree/master/contrib) If those files are installed then their license should be added to LICENSE.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2fd7b98a2e39553530df083fedf6d6550d00f783 commit 2fd7b98a2e39553530df083fedf6d6550d00f783 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2018-06-11 10:50:37 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2018-06-11 10:50:37 +0000 licenses/mpich: Remove duplicate license. Bug: https://bugs.gentoo.org/657686 licenses/mpich | 39 --------------------------------------- 1 file changed, 39 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=560d743fba27c1fa84132a436a6effd435997e12 commit 560d743fba27c1fa84132a436a6effd435997e12 Author: Ulrich Müller <ulm@gentoo.org> AuthorDate: 2018-06-11 10:49:22 +0000 Commit: Ulrich Müller <ulm@gentoo.org> CommitDate: 2018-06-11 10:49:22 +0000 sys-cluster/mpich: Update LICENSE. The mpich license is a duplicate of mpich2. Bug: https://bugs.gentoo.org/657686 Package-Manager: Portage-2.3.40, Repoman-2.3.9 sys-cluster/mpich/mpich-3.0.4.ebuild | 4 ++-- sys-cluster/mpich/mpich-3.1.3.ebuild | 4 ++-- sys-cluster/mpich/mpich-3.1.4.ebuild | 4 ++-- sys-cluster/mpich/mpich-3.2-r1.ebuild | 4 ++-- sys-cluster/mpich/mpich-3.2.ebuild | 4 ++-- 5 files changed, 10 insertions(+), 10 deletions(-)
The mpich2 license is actually the older one. The package has gone through three renames: mpich -> mpich2 -> mpich. If we're trying to pick the newest, it'd be mpich.
Justin is right in the "mpich -> mpich2 -> mpich" rename. The original mpich supported just MPI-1. "mpich2" was introduced as a new project to support both MPI-1 and MPI-2. The latest mpich (starting from v3.0) is essentially a rename of mpich2, when support for MPI-3 was added. The mpich >= v3.0 includes all of the features from mpich2. So, there's no reason to still maintain the mpich2 package, for which the latest mpich can serve as a drop-in replacement.
It doesn't matter how the package is named. The license is generally referred to as "mpich2". For example, it is named so in the SPDX license list: https://spdx.org/licenses/mpich2.html By policy of the licenses team (discussed in September 2012), the SPDX name (if one exists) is the preferred name for any new license file entering the tree.
(In reply to Ulrich Müller from comment #6) > It doesn't matter how the package is named. The license is generally > referred to as "mpich2". For example, it is named so in the SPDX license > list: > https://spdx.org/licenses/mpich2.html > > By policy of the licenses team (discussed in September 2012), the SPDX name > (if one exists) is the preferred name for any new license file entering the > tree. That's fine, but you're now quoting a different policy then: > - In case of duplicates, we regularly delete the newer file, which is mpich. which was what brought me to mention the actual package history.
(In reply to Justin Bronder from comment #7) > That's fine, but you're now quoting a different policy then: > > > - In case of duplicates, we regularly delete the newer file, which is mpich. Sorry. When I wrote that, I wasn't aware (and neglected to check) that the license has an SPDX entry. I had mentioned that mpich2 is the name used by Fedora, though. In any case, it leads to the same conclusion.
