NPSL License Improvements

[ulm]

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

[fyodor]

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:

• Section 0 -> That is not the meaning we intended, but I agree that it is poorly worded. The intent 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 are planning to rewrite this before the next Nmap release. [UPDATE 2021-01-12: We released NPSL Version 0.93 which removes that clause and replaces it with one that is clearly just advisory.]
• Section 2 -> That text is directly from the RealNetworks Public Source License, which has been approved as a free software license by both the Free Software Foundation and the Open Source Initiative. But that doesn't necessarily make it a good clause to have. Maybe we should just remove it. We will think about this more.
• Section 3 -> That is not how we meant or interpret the clause (which existed in previous Nmap versions too). The intent is to stop companies from trying to avoid complying with the Nmap license by reading and parsing and interpreting the Nmap data files directly rather than through Nmap execution. I wouldn't say that "cat" itself reads Nmap data files, even if it can be used to display them if a user specifically requests that. Maybe we can think of better wording here too.

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.

[etu]

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.

1. Does the nmap project collect CLA's?
2. If not: Have you asked all contributors if they approve of the license change?

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]

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:

By sending these changes to Fyodor or one of the Insecure.Org development mailing lists, or checking them into the Nmap source code repository, it is understood (unless you specify otherwise) that you are offering the Nmap Project the unlimited, non-exclusive right to reuse, modify, and relicense the code...If you wish to specify special license conditions of your contributions, just say so when you send them.

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]

Another problematic section in the license is that it claims that the GNU GPL defines the terms:

Covered Software is licensed to you under the terms of the GPL (Exhibit A), with all the exceptions, clarifications, and additions noted in this Main License Body.

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:

You may not impose any further restrictions on the recipients' exercise of the rights granted herein.

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]

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

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'll leave out the interpretation of section 6, which I do not believe is the correct one here. A more pressing question, I think, is if nmap is free software or not at this point?

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.

Does that mean that nmap is intented to be non-free software (www.gnu.org/philosophy/free-sw.html)? Freedom zero means that anyone can use a program for any purpose, including building and selling commercial products with it which seems to conflict with the above.

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 ***@***.***

Maybe the FSF License and Compliance Lab could help you: legal@fsf.org

[AI0867]

Modifying the GNU GPLv2 for your own purposes also brings along the possible issue that the license itself is licensed under the "verbatim license":

Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.

[fyodor]

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

@fyodor, could you clarify if the intent of nmap is to be free software or not? GNU/Linux and BSD distribution need clarification on this point because they might or might not be able to distribute nmap anymore or have to recategorize where it resides. The NPSL clearly has terms that make it incompatible with both the Free Software and Open Source Definition, @fyodor also acknowledges this point that the intent is to limit who can use nmap. But nmap advertises it self as a "free and open source", and the license preamble says that it should be "compliant with the Open Source Definition" -- it definitly is not. So this is all confusing and conflicting.

[ams]

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

@fyodor An idea that might be worth trying if feasible is reaching out to the EFF as I'm sure they could help

[micahcowan]

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.

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.

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]

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

[patatahooligan]

I believe the "proprietary software vendor" clause is a needless complication. Wouldn't it be simpler to put the code under a normal copyleft license and indicate to interested parties (outside the text of the copyleft license) that they can purchase a proprietary license from you? If you have the right to relicense 100% of the code as stated above, then you can do this dual-license scheme. The end result is that non-proprietary compatibly-licensed copyleft projects can use nmap's code freely, while proprietary projects have to purchase the right from you.

[TechnologyClassroom]

What about GPL-3.0-or-later? Does that license achieve what you are trying to do?

[sluidfoe]

I believe the "proprietary software vendor" clause is a needless complication. Wouldn't it be simpler to put the code under a normal copyleft license and indicate to interested parties (outside the text of the copyleft license) that they can purchase a proprietary license from you? If you have the right to relicense 100% of the code as stated above, then you can do this dual-license scheme.

I agree completely.

The end result is that non-proprietary projects can use nmap's code freely, while proprietary projects have to purchase the right from you.

I don't think this is quite correct, however. Shouldn't "non-copyleft" be substituted for "proprietary?" I don't see that as a problem, but it's an important distinction.

[funnelfiasco]

Fedora has determined NPSL 0.92 is not permitted based largely on the "Proprietary software companies wishing to use or incorporate Covered Software within their programs must contact Licensor to purchase a separate license" text. This constitutes a field of endeavor restriction in our judgment, which is contrary to part 6 of the Open Source Definition.

I understand that this is not the intent. If the text is updated in the future, it can be considered for inclusion in Fedora.

[dnabre]

An issue to consider which likely will make lawyers tell their companies to avoid this software is that "Proprietary software Company" is not a defined term in the License. As there is not widely accepted legal definition of proprietary in this context, "Proprietary software Company" must read no differently than "Software Company".

Use a well established license without modifications or get a lawyer specializing in copyright and software licensing to write it for you.

[RQWorldblender]

What about GPL-3.0-or-later? Does that license achieve what you are trying to do?

I should also mention, are there any authors for nmap that licensed their contributions as GPL-2.0-only? If so, that could make it hard to relicense nmap under GPL-3.0-or-later.

Or as I might suspect, not using GPL-3.0 is likely for making nmap friendlier to companies that avoid GPL-3.0 licensed programs (presumably for its anti-Tivoization clauses).

[stikonas]

I should also mention, are there any authors for nmap that licensed their contributions as GPL-2.0-only? If so, that could make it hard to relicense nmap under GPL-3.0-or-later.

Relicensing under GPL-3.0-or-later can't be any harder than relicensing under NPSL 0.92 which already happened.

[the-maldridge]

Just joining the party here. Void Linux has also made the decision to roll back to the last version that had a clear licensing scheme and to bar further upgrades to the package until this is resolved. Since we roughly track Debian and Fedora for handling of unclear licensing we are prepared to drop the package from our main collection and move it to our nonfree repository if the ultimate decision is to retain the NPSL instead of a recognized copyleft license.

Though we're a smaller project, I believe its worth sharing this as a data point.

My 2c as well as a developer distinct from void is that relicensing is a major change, and was probably worth bumping the left most number, but that's of course a matter of opinion.

[kulikjak]

Hi, I've read this whole discussion and also looked at annotated NPSL, but I am still unsure, so I better ask. Redistribution within OSes like Oracle Solaris, is it ok or not?

We are (at least under some definitions) proprietary software company, and Oracle Solaris is a proprietary OS - you can download and non-commercially use the original 11.4 release (or very recent CBE release), but you won't get immediate access to all periodic software updates we generally release once a month without a support contract.

On the other hand, we do have a public Userland mirror available on GitHub (that anybody can access and build), and I am asking strictly about redistribution within our packages - no linking of proprietary stuff against Nmap or even executing it as part of some software we sell.

Can we redistribute Nmap under current NPSL license in Oracle Solaris?

Thanks!

[fyodor]

Hi @kulikjak. Yes, one goal of the Nmap Public Source License is to permit redistribution with general purpose operating systems like Linux, *BSD, and Solaris. The license notes that "mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License." We would consider Oracle Linux to simply be aggregating Nmap along with a lot of other applications. But when Oracle or other companies ship Nmap with proprietary products that actually use and depend on Nmap, they would generally need to buy an Nmap OEM commercial redistribution license. For example, Oracle is appropriately licensed to use Nmap for asset discovery in their Enterprise Manager product as they document here.

[JamesClarke7283]

@fyodor Whats the status on this?

FSDG complaint distros have currently still locked the Nmap version to 7.80.

I hear this was being analyzed by the guys at GNU/FSF to work this out, have not seen much public discussion on NPSL on the mailing lists for a while, i would presume there are still stuff to be worked out though.

What remaining issues prevent this from being free/libre software, currently?

Which of these 4 freedoms does the NPSL currently(Version 0.94 at time of writing) not guaranty(or satisfy) under the language of the license and what needs to be done to fix it?
http://www.gnu.org/philosophy/free-sw.html#four-freedoms

I think it will give a broader overview, if it was explained in regards to those 4 freedoms. So we are working from first principals.
At least for a lay person like me, it will help a lot.

I realize there is also another c

[fyodor]

All of the Nmap releases since 7.80, including the current 7.92 release, are also available under the old (Version 7.80) license terms for anyone who prefers those as documented here and here. So if distributions are sticking to 7.80 for license reasons, I don't fully understand their reasoning either.

We are still planning to evaluate other license options since the NPSL hasn't been a hit with everyone, but we're currently more focused on technical development work for the upcoming Nmap 25th Anniversary Edition release!

[ajorg]

I understand the situation to be that distributions either didn't consider the NMAP additions to GPL to be relevant or binding, or didn't consider the old license to be enforceable as anything but GPL, because GPL doesn't allow "further restrictions" and is designed to defeat further restrictions imposed. Or they didn't notice that the license wasn't GPL. But with the new license added it's clear that neither the new license nor the old license are acceptable. Sticking to an old version means not taking on any additional risk, or not compromising standards any more than they are already compromised.

If we could agree that the old license is just GPL, and any further restrictions are irrelevant because GPL explicitly prohibits them, then it would be safe to upgrade to new versions under the old license. But we respect you, and if you communicate that you intend further restrictions that the GPL does not impose without your additions, then we ought to respect your intentions and remove NMAP from distributions whose license policies don't allow such restrictions.

[fyodor]

@ajorg - the GPL doesn't allow you to take other people's GPL code and incorporate them with your own restrictions and exceptions. That's why we can't use 3rd party GPL code in Nmap. The GPL does allow you to add restrictions and exceptions to your own code when licensing it out. A common example is the "OpenSSL exception" which many projects add to their GPL license.

That being said, having Nmap's license be based on the GPL (as both the old license and NPSL are) causes confusion for little benefit since the licenses aren't compatible anyway. We can't use outside GPL code in Nmap and other GPL projects can't use Nmap code due to the incompatibilities. So I'm hoping we can find (or only if absolutely necessary hire a lawyer to create) a new license which supports our goals and isn't based on the GPL. The first step in that process is defining those goals. Nmap has had a great run over the last quarter-century and we're trying our best to guide it well for decades more.

[ajorg]

The GPL does allow you to add restrictions and exceptions to your own code when licensing it out.

Exceptions yes, restrictions no, but I can see how you might interpret it that way.

[ajorg]

The first step in that process is defining those goals.

I like this. Do you think one of those goals can be compatibility with the license policies of major Linux distributions?

[JamesClarke7283]

I understand the situation to be that distributions either didn't consider the NMAP additions to GPL to be relevant or binding, or didn't consider the old license to be enforceable as anything but GPL, because GPL doesn't allow "further restrictions" and is designed to defeat further restrictions imposed. Or they didn't notice that the license wasn't GPL. But with the new license added it's clear that neither the new license nor the old license are acceptable. Sticking to an old version means not taking on any additional risk, or not compromising standards any more than they are already compromised.

If we could agree that the old license is just GPL, and any further restrictions are irrelevant because GPL explicitly prohibits them, then it would be safe to upgrade to new versions under the old license. But we respect you, and if you communicate that you intend further restrictions that the GPL does not impose without your additions, then we ought to respect your intentions and remove NMAP from distributions whose license policies don't allow such restrictions.

Its not about the GPL in my opinion, there are so many free software licences out there which exist, its that its not known whether the new license meets those 4 essential freedoms, if it doesn't its non-free software.

See this issue
https://labs.parabola.nu/issues/2966

My opinion is that @nmap should make this clear, what the conflicts are in terms of these 4 freedoms.

NSPL failed the FSF's license review as well last i checked:
https://lists.nongnu.org/archive/html/gnu-linux-libre/2021-07/msg00000.html

Although i dont know that the defect is yet and if they were resolved.

[JamesClarke7283]

@ajorg - the GPL doesn't allow you to take other people's GPL code and incorporate them with your own restrictions and exceptions. That's why we can't use 3rd party GPL code in Nmap. The GPL does allow you to add restrictions and exceptions to your own code when licensing it out. A common example is the "OpenSSL exception" which many projects add to their GPL license.

That being said, having Nmap's license be based on the GPL (as both the old license and NPSL are) causes confusion for little benefit since the licenses aren't compatible anyway. We can't use outside GPL code in Nmap and other GPL projects can't use Nmap code due to the incompatibilities. So I'm hoping we can find (or only if absolutely necessary hire a lawyer to create) a new license which supports our goals and isn't based on the GPL. The first step in that process is defining those goals. Nmap has had a great run over the last quarter-century and we're trying our best to guide it well for decades more.

GPL is one free/libre software license, there are so many. Rest assured the license does not need to be GPL compatible to be considered free/libre software.

There is a list here of software licenses, some of which are not compatible with the GPL, but are still free/libre software licences:
https://www.gnu.org/licenses/license-list.html#SoftwareLicenses

If the license satisfies these 4 freedoms, its free/libre software.

Four essential Freedoms:

The freedom to run the program as you wish, for any purpose (freedom 0).

The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.

The freedom to redistribute copies so you can help others (freedom 2).

The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

If those are met, then its free software the FSF would not have an issue listing it as a free license. But since the audit failed the license review, we need to know why, and then we have a better idea of how it can be resolved.

@fyodor which of those 4 freedoms do the current version(v0.94) of NPSL not guarantee/satisfy and why.
The older version also was not a known free software license so its not clear then either, as stated here.
https://labs.parabola.nu/issues/2966

I refer you guys here: https://lists.nongnu.org/archive/html/gnu-linux-libre/2021-07/msg00000.html

But here is the FSF's statement as of 2021:

This software has failed the license review due to a defect in
the official license. We hid the page to prevent accidental
downloads of non-free code while we investigate the issue.

its not clear what the defects were. If anyone has official statement from FSF saying what it was, let me know.
I don't understand why FSF have not said why it failed, but i would like to figure out why.

[fyodor]

Hi @JamesClarke7283 . You would have to ask someone who thinks the NPSL and/or the previous Nmap license are non-free why they think so. Even though we believe the new NPSL license is an improvement over the old license, we have dual-licensed all versions of Nmap since 7.80 under that same old license, so anyone who wants to keep using that same license we've used for decades is free to do so.

Regarding the FSF Directory Page, it currently says that "we do not yet know if this page exclusively refers or links to free software". The note on the discussion page which says the NPSL "failed the license review due to a defect in the official license." is dated Jan 8, 2021 and so it's probably referring to the poorly-worded "proprietary software vendors" clause in Version 0.92 of the license. We agree that clause was open to unintended and unwanted interpretations so we removed it from the license 4 days later on Jan 12, 2021. So it's not in the current NPSL Version 0.94.

Given that Nmap Version 7.91 is available under the exact same license terms as 7.80, it's strange that people are citing license reasons for distributions not upgrading from 7.80 to 7.91. If they don't like the new NPSL license, they don't have to use it. We added that option to continue using the old license specifically for distributions who didn't like or didn't have the bandwidth to review the new NPSL. We have also made modifications to the NPSL to address specific concerns like the now-removed "proprietary software vendors" clause.

[the-maldridge]

@fyodor this has for sure been mentioned several times above, but it was buried in other threads. As one of the distro people citing license reasons, the old license is either 1) GPL only because the NPSL terms were never valid in the first place, something that others have also asked for the FSF to weigh in on and 2) already in place for decades as you mentioned.

When the choice is, "purge nmap from some of the most heavily used repos in the world (i.e. any and all that use DFSG or OpenSUSE guidelines)" or "maintain the status quo and hope that the nmap team will select to use a vetted well recognized and DFSG/OSI approved license", I'm sure you can agree that the distro preference will typically sit on the second option.

[AI0867]

If you will allow me to summarize:

1. The defense of the new license that "these clauses already existed in some form in the previous license" drew attention to the fact that the old license wasn't plain GPLv2, and may also be non-free in some manner.
2. Inertia has kept nmap pinned at the last pre-controversy version, which had already been distributed under the assumption that it was licensed as plain GPLv2.

[fyodor]

@AI0867 - Thanks for the summary, but I do want to clarify one thing. While it's possible that some distros distributed Nmap "under the assumption that it was licensed as plain GPLv2", they must not have made even a cursory effort to check the actual license terms. Nmap's license details are (and were) included in the man page, at the top of every source code file, and in a license file included with each release. The Windows installer makes users view and accept the license before they can install. The license is (and was) linked to from the Nmap.org front page, and detailed in the legal notices page. We've done our best to make it clear for decades that Nmap isn't under the plain GPLv2, and renaming the license to NPSL was intended to be yet another clear indication for people.

I feel like the NPSL objections I've been hearing here are less about any specific problematic aspects of the license and more that people don't want to deal with "yet another open source license". And I can appreciate that. I think there's a good chance we'll be able to find an existing license which meets our needs well enough and switch to that. That's an important project, but it's only one of many very important projects we're working on. So it may not happen soon.

[JamesClarke7283]

@AI0867 - That's not a bad summary, but I do want to clarify one thing. While it's possible that some distros distributed Nmap "under the assumption that it was licensed as plain GPLv2", they must not have made even a cursory effort to check the actual license terms. Nmap's license details are (and were) included in the man page, at the top of every source code file, and in a license file included with each release. The Windows installer makes users view and accept the license before they can install. The license is (and was) linked to from the Nmap.org front page, and detailed in the legal notices page. We've done our best to make it clear for decades that Nmap isn't under the plain GPLv2, and renaming the license to NPSL was intended to be yet another clear indication for people.

I feel like the NPSL objections I've been hearing here are less about any specific problematic aspects of the license and more that people don't want to deal with "yet another open source license". And I can appreciate that. I think there's a good chance we'll be able to find an existing license which meets our needs well enough and switch to that. That's an important project, but it's only one of many very important projects we're working on. So it may not happen soon.

I think it is odd how no-one checked after all this time and raised the issue. But there is so much software out there.
Also github has this thing where it summerizes the licene. the NSPL is not on that, so maybe that was another factor. That most places dont have a laymans terms breakdown of how that applies to it.

I disagree with the second paragraph.

There are many licenses here and are all acceptable, and more licenses is not necessarily in issue, i think variety is good.
https://www.gnu.org/licenses/license-list.html

I agree that the FSF likely forgot to audit it again, but bill-auger inquired again about it to the licensing officer the other day.

Truth is, FSDG distros have an obligation to make sure no non-free software ends up in their distros, When a licence is not a known free software licence, its down to the maintainers to go through the legal stuff and make the decision which is not what they are meant to do.

Does @nmap have a legal team btw? I was just wondering.

I know some people don't think of this as a big issue, but i think this causes big problems, as the whole idea of why GNU/Linux was started, was to have a libre os.

I would like to help, solve this but i am a programmer who works on free software projects, not a lawyer.

I think its something, mostly the FSFs licencing team, and a lawyer from @nmap should try to workout.

I understand there is a lot of other important stuff to work on from a technical perspective, and i respect that but i would like some clarification on something.

The thing that worried me was when you said "So it may not happen soon"
My worry is if @nmap keeps failing the audit and its not worked to resolve issues for a long period of time(like 1y+ after a failed audit), then it will lead to it being marked as a non-free license officially.
I assume you just meant in the next few months though, but i wanted to clarify.

Which is not what we want, because nmap is a awesome project i have great respect for.

So i am waiting for the review from FSF on the updated license. If anyone can identify more defects which could be problematic under the 4 essential feedoms it might be quite useful to aid in resolving this.

[TechnologyClassroom]

I work at the FSF, but not on the licensing team. You can see my suggestions in this thread here and here which would be to pick GPL-3.0-or-later or AGPL-3.0-or-later instead of maintaining two unique licenses.

The Free Software Directory (FSD) is mostly run by volunteers. The NMAP FSD page has not been edited by any members of FSF staff. NMAP is currently unapproved pending this issue. If you want to participate with the FSD, join the Friday meetings on IRC.

If you want the NPSL to go through a license check or would like licensing help for NMAP in general, reach out to the FSF Licensing & Compliance Team by sending an email to licensing@fsf.org

[DanHakimi]

@ajorg - the GPL doesn't allow you to take other people's GPL code and incorporate them with your own restrictions and exceptions. That's why we can't use 3rd party GPL code in Nmap. The GPL does allow you to add restrictions and exceptions to your own code when licensing it out. A common example is the "OpenSSL exception" which many projects add to their GPL license.

You can do this very easily with a contributor license agreement. Now, I'm not sure how your contributors will feel contributing when they know you also offer the software they write with a paid exception, but if they've been contributing under the current confusing state of affairs, I don't see why they'd stop now.

You could also ask them to contribute under the GPL with an exception that grants permissive use by NMAP. That might be easier.

Either of these options would make much more sense than continuing to use your license, which is still really confusing and not really well-written from a legal standpoint.

I fear, to some extent, that the point of this license is to make it look like you still care about software freedom more than Mongo or Elastic while still scaring the maximum number of companies into paying for licenses they might or might not need. I'm not really clear on what the problem with the GPL was, but from what I've read of your interpretations of "derivative works" and other concepts, it seems like the GPL was too permissive in that it allowed some companies to sometimes use the code on the same planet as the one in which proprietary software exists.

[samueloph]

I would like to get clarification about the Derivative works section of the license:

3. Derivative Works

This License (including the GPL portion) places important restrictions
on derived works. Licensor interprets that term quite broadly. 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:

* Integrates source code from Covered Software

* Reads or includes Covered Software data files, such as nmap-os-db or
  nmap-service-probes.

* Is designed specifically to execute Covered Software and parse the
  results (as opposed to typical shell or execution-menu apps, which
  will execute anything you tell them to).

* Includes Covered Software in a proprietary executable installer. The
  installers produced by InstallShield are an example of
  this. Including Nmap with other software in compressed or archival
  form does not trigger this provision, provided appropriate open
  source decompression or de-archiving software is widely available
  for no charge. For the purposes of this license, an installer is
  considered to include Covered Software even if it actually retrieves
  a copy of Covered Software from another source during runtime (such
  as by downloading it from the Internet).

* Links (statically or dynamically) to a library which does any of the
  above

* Executes a helper program, module, or script to do any of the above.
  This list is not exclusive, but is meant to clarify Licensor's
  intentions with some common examples. Distribution of any works
  which meet these criteria must be under the terms of this license
  (including this Main License Body and GPL), with no additional
  conditions or restrictions. They must abide by all restrictions that
  the GPL places on derivative or collective works, including the
  requirements for distributing their source code and allowing
  royalty-free redistribution.

Thinking specifically about these parts:

* Is designed specifically to execute Covered Software and parse the
  results (as opposed to typical shell or execution-menu apps, which
  will execute anything you tell them to).
  ...
* ... Distribution of any works
  which meet these criteria must be under the terms of this license
  (including this Main License Body and GPL)

Does this mean that any software which calls and parses nmap's output[0] should be licensed under the NPSL?

Because if that's the case, I assume there are quite a considerable number of projects in breach of that, and it might not be the intention of nmap developers.

On Debian [1][2], this seems to be the main point in discussing whether the license is DFSG-free or not, I understand the GPL impose similar restrictions, but they're a bit less strict.

[0] Surely with the exception of the cases listed there: "typical shell or execution-menu apps, which
will execute anything you tell them to"
[1] https://lists.debian.org/debian-legal/2022/09/msg00000.html
[2] https://lists.debian.org/debian-legal/2022/09/msg00008.html

[fyodor]

Hi @samueloph . Good questions and thanks for the links. There are many Nmap frontends and parsers which have different licenses, and we support that. They don't generally need to be "NPSL compliant" because they don't need the special rights that would give them (being able to redistribute Nmap as part of their software). Free software projects are usually fine with the idea that the user already has or will obtain Nmap themselves. There are also expensive proprietary products which include Nmap parsers (for inputting your own Nmap scan results into the product) and we don't complain about those either. It's an interoperability feature.

The main purpose of this section of the NPSL license is to restrict companies from selling proprietary products which include Nmap and for which Nmap is doing much of the work. They often don't even disclose to the users that Nmap is there. We feel that companies selling products based on Nmap should be contributing back by purchasing an Nmap OEM License. This in turn allows the Nmap Project to pay developers. And it helps the Nmap OEM customers too by ensuring the sustainability and active development of the software they are using in their products. And we provide other important OEM benefits like commercial support and indemnification.

All that being said, we agree with many of the criticisms in this thread. We've made a number of small license changes to address people's specific concern, but I don't think that's enough. I'm hoping we can find an existing accepted license which meets our needs. But failing that, I think we should rewrite the NPSL so it doesn't reference the GPLv2 at all.

We've added this to our roadmap, but it's a bigger project than it sounds because we need to better understanding and define our licensing goals and needs before we can choose the best approach to meet them. Much of the current license is structured to support our unusual "business model", but maybe we'd be better off just changing the model. Also we're currently in the midst of a lot of exciting Nmap technical development. Still I believe we'll be able to find and implement a solution to this in 2023. We did offer Nmap 7.90, 7.91, and 7.92 under the "old license" as an alternative for distributions and people who prefer that. But distros mostly seemed to stick with the old version of Nmap (under that same old license) instead. So we didn't bother doing that with 7.93. But we're open to that if any major distro feels that it would help them incorporate Nmap 7.93. We're also open to more specific small changes to the NPSL text like we did earlier in this thread to address specific distribution complaints.

[thesamesam]

We've added this to our roadmap, but it's a bigger project than it sounds because we need to better understanding and define our licensing goals and needs before we can choose the best approach to meet them. Much of the current license is structured to support our unusual "business model", but maybe we'd be better off just changing the model. Also we're currently in the midst of a lot of exciting Nmap technical development. Still I believe we'll be able to find and implement a solution to this in 2023. We did offer Nmap 7.90, 7.91, and 7.92 under the "old license" as an alternative for distributions and people who prefer that. But distros mostly seemed to stick with the old version of Nmap (under that same old license) instead. So we didn't bother doing that with 7.93. But we're open to that if any major distro feels that it would help them incorporate Nmap 7.93. We're also open to more specific small changes to the NPSL text like we did earlier in this thread to address specific distribution complaints.

I'm sorry for missing this part before. It would definitely help us in Gentoo. We have 7.93 in Gentoo but not available by default. Note that Debian have packaged up to 7.92 as well, so I think it did end up being helpful in the end.

[fyodor]

Thanks for the update, @thesamesam! We still plan to address this in a better way this year, but I'm glad Gentoo and Debian have been able to upgrade to later versions anyway.

[samueloph]

I should clarify that on Debian's side it's still unclear whether the NPSL license is DFSG-free or not, I've opened a bug report asking for the ftp-master team to evaluate (the bug got closed by accident but I've reopened it):
https://bugs.debian.org/1025650

It turns out the discussion became about the older versions of the NPSL license too, it's not anymore only about the recent changes (I think this has been pointed out in this thread before).

I don't know when ftp-master will be able to reply, but I'm hoping it will be in the next months, since the new Debian stable release is getting close.

And as @thesamesam mentioned, even though the discussion is now about NPSL in general and not only about the new version of it, the exception made by the nmap team to allow people to use nmap up to 7.92 with the old version of NPSL was really helpful at that time.
It allowed me to update it to 7.92 knowing at least that it wouldn't imply in changes to the license, so whatever the decision on Debian side ends up being, I wouldn't possibly be making it more complicated [0].

Now that the discussion seems to be more around NPSL (and not its recent changes), I'm considering packaging 7.93. Whatever the decision on Debian side is, it will probably not change by the difference in the license between 7.92 and 7.93. By the time 7.93 reaches stable, there should be something that I can refer to and I can take any needed action.

I have to say this whole thing has became the source of some very interesting discussions, and has broaden my understanding of free software in general, even though it's a bit time consuming and stressful (for everyone involved).

[0] This helped at that time of uncertainty, but now that there seems to be a better understanding of the whole thing (basically that we need to re-evaluate NPSL against DFSG), the same exception wouldn't help anymore.

[fyodor]

Thanks @samueloph. And we remain open to making further changes to the NPSL if there are specific issues preventing it from being considered DFSG-free. We just don't want to do (another) major license overhaul right now since we're already planning to do that later this year in consultation with major stakeholders. The goal will be switching to an existing free software license (preferred) or at least redrafting NPSL so that it's not based on GPLv2 the way it is now.

[fyodor]

After further review of the NPSL (Version 0.94), I can see how it could be construed as burdening Nmap-related software such as shell scripts, GUIs, and language-specific parsers that may be free software which doesn't ship with Nmap and doesn't need the extra rights granted by the NPSL (such as redistribution rights). The type of software mentioned by @samueloph at #2199 (comment).

That was never our intention, but we just released NPSL Version 0.95 (annotated HTML version and pure license text) to further clarify that the NPSL is not meant to contaminate other software packages which are separate works that don't incorporate Nmap source code or executables. Thie updated Article 3 (Derivative works) notes that the derivative works definitions and all the other terms only apply to works which "choose to accept this license to benefit from the rights granted herein". It also includes this new paragraph:

Licensor does not purport to control through this license any software which does not require the rights granted herein (such as rights to redistribute and/or incorporate Covered Software executables and source code). In particular, many software packages include the ability to parse Covered Software results provided by an end user or to execute Covered Software that end user may have already installed on their system. To the extent that copyright doctrines such as fair use allow their practices without the need to exercise any rights granted by this license, vendors and distributors of such software are not bound by our definition of derivative works or any other clauses in this license.

A bunch of further clarification was added to the annotated HTML version, including the note that "General purpose Linux distributions which happen to offer both Nmap and 3rd party packages described above for users to choose from are covered by the "mere aggregation" clause of the GPLv2."

Also I fixed a CSS problem which was preventing the annotations on the annotated HTML version from showing up in shaded boxes to clearly differentiate them from the actual license text.

I hope this helps. Just let me know if you have any questions or concerns.

[ulm]

[...] we just released NPSL Version 0.95 [...]

Does this retroactively apply to already released nmap versions? The nmap-7.93 tarball comes with NPSL 0.94 in its LICENSE file.

[fyodor]

Great point, @ulm. We plan to release Nmap Version 7.94 with the new license (and many other improvements) fairly soon, but I've also just added a note to the Changelog that "Versions of Nmap released under previous versions of the NPSL may also be used under the NPSL 0.95 terms."