Open ataraxus opened 1 month ago
Just for clarity... The license you are referring to is https://svn.nmap.org/nmap/LICENSE (Nmap Public Source License Version 0.95). https://nmap.org/npsl/ itself is not a license, rather explanatory text.
Please also note that the original request referred to version 0.92 (instead of the current 0.95 version of the license). Please also mind that versions 0.93 and 0.94 have been recorded as well.
There is also:
We need to determine the scope of this request.
With respect to the 0.95 version:
{metæffekt} Universe canonical name: Nmap Public Source License 0.95 short name: NPSL-0.95 markers: Display Obligation Marker, Incompatible with Secondary License Marker, No Patent Rights Granted Marker, Patent Information Marker category: NPSL ScanCode reference id: npsl-exception-0.95 OSI status: none
To @karsten-klein's point, yes, if this is added then the name and ID should refer to the specific version. I'd suggest "Nmap Public Source License Version 0.95" as name since that reflects the title in the license, and NPSL-0.95
as the identifier.
For what it's worth, also this is structured as sort of an add-on to GPL-2.0, I would not put it on the Exceptions List since it is not merely "an exception to a license condition or additional permissions beyond those granted in" GPL-2.0. It imposes additional requirements beyond GPL-2.0, e.g. section 6 with additional requirements for "External Deployments".
I'll follow this comment up with a writeup of where I think this one lands on the license inclusion principles.
Note that I initially marked this as "used in major distro" based on Fedora including Nmap -- but it's possible that might actually be Fedora using an older version of Nmap under a prior license; see https://fedoraproject.org/wiki/Licensing/Nmap. So I'm removing that label for the moment as this may need a bit more digging.
These must all be satisfied to allow inclusion in the license list
Roughly in order of descending importance
This license appears to take GPL-2.0, and make "exceptions, clarifications, and additions" to it. Those additions include among other things the following:
The last two items in particular make it hard for me to look at this and comfortably call it an open source license. For the derivative works definition, I haven't dug deeply into it, but I don't think it aligns with how OSI has viewed similar licenses. For example, it appears to deem something to be a derivative work because it reads an Nmap data file or executes a script or "helper program" to perform certain actions. The intent seems to be to then deem any of those things to be subject to copyleft requirements. To me, that loosely feels like it's trying to do something similar to the super-broad copyleft effect that (I think?) led to the OSI withholding approval for SSPL-1.0.
Similarly, the Nmap product-specific terms in section 10 give me pause. It appears to be saying that it is not possible for a recipient of the Nmap Windows builds to redistribute them as-is. If I'm understanding correctly, that makes it a straightforward OSD 1 violation. (Maybe it can be an open source or open-source-ish license for non-Windows builds?)
In any case, for me I think it's unlikely that this meets "Other factor" 1; and depending on your views on the Nmap Windows build language, it might not meet "Other factor" 4 either. I'd greatly welcome others' thoughts on this one.
This review is a bit of a mess, unfortunately, because of the complications for what parts of this license we're actually taking into account.
As applied to Nmap Windows builds, no, I don't think it meets Other factor 1 or even Other factor 4. But looking at other Nmap products where section 10 isn't relevant (e.g. Linux builds), I think that it probably doesn't meet Other factor 1 but would satisfy Other factor 4.
Taking that, together with its use in at least some Linux distros like Gentoo and its progeny, I'm a hesitant +1 to add this to the License List. But I'd really like to have others' thoughts on this as well, because I'm not at all convinced on this as the correct answer here.
@swinslow I think this assessment is premature because it is not clear what license text @ataraxus is referring to in this request (despite linking to https://nmap.org/npsl/).
@richardfontana That's a fair point!
@ataraxus Are you referring specifically to Nmap Public Source License Version 0.95, which is currently (at this moment) available at https://svn.nmap.org/nmap/LICENSE; or a different version of the Nmap license?
From an SPDX-matching-guidelines-ish perspective, I believe there are four distinct Nmap licenses. I finally attempted to go through all of them from the Fedora standpoint. See my summary here: https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/thread/Q67UGCHSCKCLJOVOHSLYU4AERAHBS5YE/
I would add that while the Fedora conclusion is that all of these licenses are "not-allowed", and thus Fedora ordinarily wouldn't seek SPDX identifiers for them, one of them (what as far as I know is the original one) was treated by Fedora as "good" under the pre-SPDX system, and continues to be permitted under a policy exception. Given how confusing this collection of licenses is, and how widely used Nmap is, I wonder if there is a good justification for adding some or all of them to the SPDX license list to help clear up confusion.
How license meets inclusion principles
License is needed due to image scanning of RHEL UBI images with installed ncat
Also see discussion here: https://github.com/spdx/license-list-XML/issues/1121
License Name
Nmap Public Source License
Suggested short identifier
NPSL
License or Exception?
license
URL to license text
https://nmap.org/npsl/
OSI Status
I don't know
License author or steward
Unknown
URL to project(s) that use license
https://catalog.redhat.com/software/containers/ubi9/ubi/615bcf606feffc5384e8452e
paste text of license here
https://nmap.org/npsl/