Repository navigation
NPSL License Improvements #2199
Description
Reporting this issue on behalf of the Gentoo licenses team. It has been brought to our attention that nmap-7.90 and later is distributed under updated license terms. We see several clauses in version 0.92 of the Nmap Public Source License as problematic, to the point where we can no longer consider it as a FLOSS license. Therefore, it is license-masked, i.e., with the default distro-wide settings, Gentoo users won't be able to install the latest version of nmap.
In particular:
- In section 0 (Preamble): "Proprietary software companies wishing to use or incorporate Covered Software within their programs must contact Licensor to purchase a separate license."
This won't allow "proprietary software companies" to use or incorporate the software within their programs (i.e., create a derivative work), even if the resulting work was distributed under a free software license. Essentially this is a non-commercial restriction and as such directly violates the Open Source Definition, section 6 "No discrimination against fields of endeavor". - In section 2 (General Terms): "In addition, you agree to the terms of this License by clicking the Accept button or downloading the software."
This type of language is typically found in an EULA but not in a FLOSS license. If I download the software from a third party (like Github or a distro mirror), I won't enter into any contract with either Insecure.Com LLC or the third party. Therefore nothing forces me to accept the license unless I would do any actions (like redistributing) that are covered by copyright law. Also, in the typical case, I won't even have the chance to read the license before downloading. - In section 3 (Derivative Works): "To avoid any misunderstandings, we consider software to constitute a 'derivative work' of Covered Software for the purposes of this license if it does any of the following: [...] Reads or includes Covered Software data files, such as nmap-os-db or nmap-service-probes."
We're aware that this point existed in previous versions of the license, but we still find it somewhat problematic. For example, it would make GNU coreutils a derived work of nmap because its programs can read those files, e.g., "cat /usr/share/nmap/nmap-os-db".
Gentoo bug: https://bugs.gentoo.org/749390
Debian bug: https://bugs.debian.org/972216
Guix discussion: https://lists.gnu.org/archive/html/guix-devel/2020-10/msg00227.html
Metadata
Metadata
Assignees
Labels
No labels
Activity
fyodor commentedon Dec 7, 2020
Hi Ulrich. Thanks for posting your feedback. We aren't licensing or copyright experts, but we want the NPSL to be an improvement over the previous license (which also had problems). Regarding your three points:
I'm changing this issue title to something more actionable so I can assign it to myself and add it to our ProjectBoard for the next release. If anyone else has comments or suggestions regarding the NPSL, feel free to post them here as well. For the next Nmap release, we at least want to have the Section 0 thing fixed, but we're also considering bigger changes or even move to another license if we find ones that meet our needs well.
[-]NPSL version 0.92 is not a free software license[/-][+]NPSL License Improvements[/+]etu commentedon Dec 7, 2020
This is not an attempt at thread hijacking, it's just a question regarding this license change. I'm the one that brought this up for NixOS. But something that I haven't seen discussed anywhere really is if the nmap project actually could change the license to begin with.
So I'm questioning both if this new license is free software, just as this thread is about. But I'm also questioning if this license change is legal to begin with.
fyodor commentedon Dec 7, 2020
Hi @etu . Good question. Yes, we do have more than 100 signed copyright assignment contracts from major developers (everyone we have paid), and those probably represent at least 95% of the code changes in recent years. We don't do signed contracts for one-off small code contributions, but we do make it very clear that we only accept the code on the condition that the contributor is offering us full rights to relicense the code in our work. The text of the previous license included:
This note is also on the top of every source code file, in the man page, HACKING file, etc. We have been offering Nmap under different licenses to customers for more than 20 years so it has always been important that we can relicense code contributions. This is how we fund the project and pay developers. We have also made many changes to the open source Nmap license over the years.
We also repeatedly discussed and solicited comments on the NPSL on the Nmap development list before it was ever applied to the code. If any Nmap contributor has concerns about the license, we'd be happy to hear their thoughts. Finding the right license is tough.
ams commentedon Dec 7, 2020
Another problematic section in the license is that it claims that the GNU GPL defines the terms:
But there are terms that directly conflict with the GNU GPL (some mentioned above), which prohibits adding terms that would put future restrictions on the user of the software. See section 6 of the GNU GPL:
The text is hard to understand which license is applicable (GNU GPLv2 or the NPSL, because it cannot be both).
Wouldn't it be better to choose a plain free software license that is approved by the FSF and the OSI?
fyodor commentedon Dec 7, 2020
@ams - The GPLv2 section about not adding further restrictions to the GPL means that if you receive code under the GPLv2, you can't add any further restrictions when you redistribute that code. This means, for example, that we can't take GPL code from 3rd parties and put it under the NPSL. So we can't and don't put GPLv2 code from 3rd parties into Nmap. And NPSL code cannot be integrated into GPLv2 programs. They aren't compatible licenses. The FSF does allows people to create new licenses based on GPL text (even if the new licenses aren't GPL-compatible), which is what we have done with the NPSL.
Regarding cases where the NPSL main body license text conflicts with the GPLv2 text in Exhibit A, Section 2 says that "Where the terms in this Main License Body conflict in any way with the GPL, the Main License Body terms shall take precedence." The license also clearly states that it is not GPLv2 compatible.
I agree that it would be cleaner to rewrite the NPSL so it doesn't depend on the GPLv2 Exhibit and has all the key terms in the main body itself. And it would be cleaner still to just use an existing well-written license as you suggest. We will be looking into those options, but we have a lot of other work on our plate too. The NPSL terms are not very different than the previous license (which was also based on GPLv2 but with various exceptions and clarifications which made it not-GPLv2-compatible). I think giving the NPSL its own names makes it more clear that it is under its own GPLv2-incompatible license so there is less confusion. And I think some of the terms are improved from the old license and that we can fix regressions such as the Section 0 problem that @ulm pointed out.
Our main goal with the license, in case it's not clear, is to allow unlimited free use of Nmap by end users (including commercial use), while charging companies who want to build and sell commercial products on top of Nmap through our Nmap OEM program. The goal has been to avoid the much more common tact of having a "free version" with limitations and then a non-free pro version with extra features. So we need to either have a license which supports the current business model, or switch to a different business model, or give up on a business model and lay off the developers who are currently working full time improving Nmap. So we're trying to find the best balance for everyone. We are also hoping to hire another full time developer next year.
I hope this helps. If anyone wants to recommend a great copyright lawyer with open source experience that we could hire to consult on these matters and potentially help draft a new license, please email me at fyodor@nmap.org. Cheers!
ams commentedon Dec 8, 2020
AI0867 commentedon Dec 8, 2020
Modifying the GNU GPLv2 for your own purposes also brings along the possible issue that the license itself is licensed under the "verbatim license":
fyodor commentedon Dec 9, 2020
@AI0867 - That is a good point, but the FSF does allow folks to make modified licenses based on the GPL. It's in their FAQ. Also, the copy of the GPL that we include as Exhibit A in the NPSL is verbatim except that we cut out the "How to Apply These Terms to Your New Programs" section as the FSF requests in their FAQ entry. That section would be confusing in this context.
We have worked closely with the FSF in the past, donationed to them, and greatly respect them. If the FSF ever tells us that they don't want us including the GPL license in the NPSL in this way, we will change it ASAP.
ams commentedon Dec 9, 2020
ams commentedon Dec 21, 2020
@fyodor Would it be possible to get a clarification?
The only choice GNU/Linux have right now is to remove nmap from their distributions or mark it as non-free software.
L1ghtn1ng commentedon Dec 21, 2020
@fyodor An idea that might be worth trying if feasible is reaching out to the EFF as I'm sure they could help
micahcowan commentedon Dec 21, 2020
It sounds to me like section 0 (preamble) is the only one mentioned in this bug description that actually prevents this software from being FLOSS, and that it also probably differs from its intended meaning, which I think also likely differs from @fyodor's explanation of its intended meaning. (Perhaps section 3 can be interpreted as "not FLOSS" as well, but at least it's not new and had previously been accepted, so I'm addressing the "what actually turned this license non-FLOSS" question.)
The license speaks about usage by "proprietary software companies", which does sound like field restriction to me (for instance, "proprietary software company" can include software companies that are owned by someone or a body of people (AFAIK, any software company fits this interpretation), or (more reasonably) it could mean a company that creates software and licenses as proprietary, but that only use nmap as part of FLOSS-licensed software they distribute.
I'd like to suggest (and @fyodor please correct me if this is mistaken), that what was actually meant here, is "while charging companies who want to build and sell proprietary commercial products". In which case, all that's really needed here AFAICT is clearer language to say the intended thing. Perhaps simply moving the word "proprietary", as: "
Proprietary sSoftware companies or authors wishing to use or incorporate Covered Software within their proprietary programs must contact Licensor to purchase a separate license."I think that phrasing still has a problem with the word "use", though. AIUI a program can't be Free/open if it restricts execution by another program (this is different from linking, of course). But perhaps my understanding there is inaccurate.
fyodor commentedon Dec 21, 2020
@micahcowan - Thanks for your suggestions. Yes, our intent of that section is to simply explain that because the NPSL terms do not allow inclusion within proprietary software, "proprietary software vendors" (like anyone else) would have to purchase the Nmap OEM license to include it within their proprietary software. If a "proprietary software vendor" also releases free software in compliance with the NPSL, that is great and we certainly don't want or mean to take away that right from them. We do understand how the wording is problematic and we are planning to rewrite this before the next Nmap release.
111 remaining items
TechnologyClassroom commentedon Jan 19, 2024
It is not clear that the NPSL license has been reviewed by the FSF. Just to clarify again, FSF's Free Software Directory is largely run by volunteers. The mailing list entry is from Bill who leads the Parabola project and is not FSF staff. The history page for the cited source lists two editors for that page. One of which (Donaldr3) is former FSF licensing team staff. They said these statements:
I also want to point out to AMS' point there is an article by RMS about selling exceptions which can be done with the GPL licenses. Selling exceptions does not inherently make a project nonfree, but it is odd that it is included within the text of the license IMO. I share this because it is not a commonly known page and I believe the protections with GPL-3.0-or-later or AGPL-3.0-or-later are what you are after with the intent of the NPSL.
dgregscott commentedon May 23, 2024
Here is a sticky one for you. I'm a Technical Account Manager with Red Hat supporting Red Hat's largest customers. This landed in my lap yesterday.
The explanation in the annotated NPSL says,
Fair enough. But it opens a can of worms. And now it's under a microscope.
Red Hat distributes Red Hat Enterprise Linux (RHEL), which includes nmap. Red Hat's customers might package RHEL into appliances, or resell RHEL as part of some other offering, which likely includes proprietary pieces. Other Linux distributions probably do the same thing. Seems to me, if we follow NPSL to its logical conclusion, it means we can no longer package Nmap with Linux distributions.
I doubt anyone likes that conclusion. This thread is 5 years old. Let's find a way that supports the Nmap business model and works for everyone.
fyodor commentedon May 29, 2024
Hi @dgregscott . Thanks for your comments. We consider RHEL's redistribution of Nmap to be "mere aggregation" of Nmap with all the other packages you distribute. The NPSL restrictions are for "derivative works" as defined in Section 3. If someone "resells RHEL as part of some other offering, which likely includes proprietary pieces" then the Nmap part is still mere aggregation and not a NPSL violation as long as the "proprietary pieces" aren't using Nmap so intimately that they would be considered a derivative work of Nmap. And if a company is selling a proprietary Nmap derivative, requiring them to contribute to the project by purchasing an Nmap OEM redistribution license is an intentional NPSL license goal. The idea is that companies selling products derived from Nmap should pitch in to support the Nmap Project itself. Hundreds of companies already do, and it's how we hire full-time developers to work on Nmap and Npcap. And our customers (along with millions of free users) in turn benefit from our constant Nmap improvements. For example we just released Nmap 7.95 last month. This is similar to the way RedHat has engineered things so that RHEL users generally have to buy a subscription.
While the NPSL is fairly unique, this situation is similar to many other packages in RHEL. For example RHEL includes many software libraries that are licensed under GPLv2. RHEL can do that under the "mere aggregation" clause and so can RHEL resellers if they are also doing mere aggregation. But if they link their own proprietary software to those GPLv2 libraries that are part of RHEL, they would be violating the license if they don't receive special permission from the copyright holders. In the case of Nmap, our OEM redistribution license serves as that special permission. And since Nmap isn't a library, the NPSL explicitly defines derivative works more broadly to cover the ways that proprietary software typically builds on top of Nmap (executing Nmap and parsing the results). This is similar to the way the AGPL is often used for software that is typically offered as a network service rather than a library or downloaded executable.
I hope this helps. We are keeping this issue open because still plan to re-evaluate the Nmap license and ditch or improve the NPSL, but we are a very small organization and are always juggling many other important project priorities as well.
andreasstieger commentedon May 29, 2024
openSUSE moved nmap to non-free: https://bugzilla.opensuse.org/show_bug.cgi?id=1211571
richardfontana commentedon Jul 5, 2024
Fedora has reviewed NPSL 0.95 and concluded it is "not-allowed".
https://gitlab.com/fedora/legal/fedora-license-data/-/issues/539
https://gitlab.com/fedora/legal/fedora-license-data/-/merge_requests/588
In part due to confusion caused by this succession of Nmap licenses, it appears Fedora is currently distributing versions of Nmap under this license (with inaccurate license metadata). This is an error and I'll look into figuring out how to correct this.
Fedora bugzilla filed: https://bugzilla.redhat.com/show_bug.cgi?id=2296006
FWIW, the main problems I identified in reviewing NPSL 0.95 were the "External Deployment" badgeware-ish provision and the section redefining "Derivative Works". I viewed this version of the license text: https://github.com/nmap/nmap/blob/47919b8dac98ad0f2639018e2b99ea3ad6b5e70a/LICENSE
and not possibly different versions appearing on an Nmap website or elsewhere.
fyodor commentedon Jul 5, 2024
Thanks for your detailed review, @richardfontana . We will keep your points in mind as we re-evaluate the Nmap license with the goal of ditching or improving the NPSL. We definitely want to get rid of the "based on the GPLv2" aspect, and it will be even better if we can switch to an already-widely-approved existing license rather than writing our own. Just to properly set expectations: This license restructuring is an important project on our roadmap, but we're currently focused on some exciting technical improvements for the next release. If any distributions feel that they have to put Nmap in their "nonfree" section or even stop distributing it in the meantime, we understand that and respect whatever acceptable license policies they choose for themselves.
richardfontana commentedon Jul 6, 2024
Update: Fedora has now classified all known Nmap licenses as "not-allowed", but the pre-NPSL one that takes the form of a GPLv2 gloss will be permitted under a policy exception.
https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.org/thread/Q67UGCHSCKCLJOVOHSLYU4AERAHBS5YE/
fyodor commentedon Jul 6, 2024
Thanks @richardfontana. If it would be helpful for us to dual-license the latest Nmap 7.95 under the pre-NPSL license so you can use it under your policy exception, just let me know and we will do so.
mercmobily commentedon Jan 18, 2025
@richardfontana just wondering if this has progressed after @fyodor 's answer?
nmap: add recipe for 7.92
nmap: add recipe for 7.92
bwarden commentedon Jun 3, 2025
For Clear Linux, it would be helpful to have dual-license for 7.95, if this is still possible.
XWwalker commentedon Nov 2, 2025
XWwalker commentedon Nov 11, 2025
Hi @fyodor Fyodor, Does the dual-license policy apply to Nmap versions after 7.92 (7.93, 7.94, 7.95, etc.)? Thank so much for your time!
pierre94 commentedon Nov 28, 2025
Tracking in progress! @fyodor