spdx / license-list-XML

This is the repository for the master files that comprise the SPDX License List
Other
336 stars 264 forks source link

New license request: NMAP Public Source License #2492

Open ataraxus opened 1 month ago

ataraxus commented 1 month ago

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/

karsten-klein commented 3 weeks 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.

karsten-klein commented 3 weeks ago

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

swinslow commented 2 weeks ago

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.

swinslow commented 2 weeks ago

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.

New submission review

Definitive Factors

These must all be satisfied to allow inclusion in the license list

  1. Is the submitted license unique, that is, it does not match another license already on the License List as per the matching guidelines?
    • [X] Yes
    • [ ] No
  2. If a software license, does it apply to source code and not only to executables?
    • [X] Yes
    • [ ] No
  3. Does the license have identifiable and stable text, and is not in the midst of drafting?
    • [X] Yes => note that the last time that Nmap licenses were reviewed, in #1121, there were multiple different versions that were being published by the license steward in parallel with the review; and this was one of the primary reasons for rejecting the earlier version submission.
    • [ ] No
  4. Has the license steward, if any, committed to versioning new versions and to not modify it after addition to the list?

Other factors for inclusion

Roughly in order of descending importance

  1. Does the license substantially comply with one of the free/open content definitions? (examples include the Open Source Definition and the Debian Free Software Guidelines) (Approval by the organisation that publishes the definition is not required)
    • [ ] Yes
    • [X] No => or at least probably not; see my comments below
  2. Is the license structured to be generally usable by anyone, and not specific to one organisation or project?
    • [ ] Yes
    • [X] No => Specifically structured for Nmap, including naming them as the "Licensor" and including terms that are specific to Nmap's products in sections 3 and 10
  3. Does the license have substantial use such that it is likely to be encountered (ie. use in many projects, or in one significant project)? (For recently written licenses, definitive plans for it to be used in at least one or a few significant projects may satisfy this)
    • [X] Yes => Nmap is widely used and encountered in various Linux distributions, albeit not necessarily under this Nmap license. Gentoo appears to be using this license version. @ataraxus indicated that Red Hat is, though I can't view that from the link that was shared in this submission. The Fedora wiki seems to suggest that Fedora does not use this version.
    • [ ] No
  4. Is the license primarily intended to facilitate the free distribution of content with limited restrictions?
    • [ ] Yes
    • [ ] No
    • [X] Maybe? see my comments below regarding the open-source-ish-ness of this one...
  5. Does the license steward support this submission, or is at least aware of and not in opposition of it?
    • [ ] Yes
    • [ ] No
    • [X] Unknown => I don't think we have any input on this

more details on "is it open source"

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.

Summary of factors, outcome, comments

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.

richardfontana commented 1 week ago

@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/).

swinslow commented 1 week ago

@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?

richardfontana commented 6 days ago

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/

richardfontana commented 6 days ago

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.