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.

[kemitchell]

@throwaway1037 you're harassing the long-serving maintainer of a beloved, decades-old security tool for a license change from a twelve-day-old anonymous throwaway account.

[throwaway1037]

Sorry, I don't mean to harass, just move the discussion along. I apologise for being impatient.

[fyodor]

Since a whole Nmap license re-evaluation is a longer term project due to other critical projects on our plate, we're still looking for possible quick-fixes like the NPSL 0.93 change we made in January that addressed some big concerns. One idea is that we could grant the rights to use Nmap 7.90 and 7.91 under the same pre-NPSL license that Nmap 7.80 had. That way any distribution (or anyone else) that prefers the old license doesn't feel like they need to use/redistribute an older version of Nmap instead. And of course it lets the people who prefer the NPSL continue using that.

I'm not sure whether this will help since most of the NPSL complaints I'm now hearing were in the old license too. But if we hear from any major distribution (like Debian, Ubuntu, Fedora, RHEL, Gentoo, etc.) that they want the option to use these newer releases with the older Nmap license, let me know and we'll make it happen. If none of them want this, we'll go back to the drawing board for other ideas.

[hillu]

I'd have to check with Debian's release team if we can still get an update in (we are in the middle of a freeze for the upcoming Debian 11/"bullseye" distribution release). Assuming they agree, it would be useful to make that change as quickly as possible. @fyodor, thanks for considering this.

[ulm]

Gentoo has effectively reverted to 7.80, so making newer versions available under the old terms would definitely help.

[fyodor]

OK. Effective immediately, Nmap 7.91 (which is the current version) and 7.90 can also be used and redistributed under the previous (Nmap 7.80) license terms. We've also added this license grant statement to the NPSL summary page and posted the old license terms on Nmap.org along with a note that they can apply to 7.90 and 7.91 as well. Meanwhile, everyone who prefers the NPSL can continue using that.

We are still hoping to do a major license review before the next Nmap release, and we will consider all the great feedback posted here. But that release is probably months away, so we hope this new license grant helps in the meantime.

[throwaway1037]

Thank you very much.

[ajorg]

The GPLv2 text was included verbatim (which FSF allows) as an exhibit below the old Nmap license terms which reference the GPL. We did not modify the GPLv2 text itself. This is a common approach for software which adds exclusions/modifications to the GPL terms, such as the common OpenSSL exception (which Nmap also has). The NPSL also includes the GPLv2 text as Exhibit A.

The GPLv2 text also includes this:

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

The "common approach" you reference is used to allow further permissions, such as the Linux syscall exception and the Classpath exception.

GPL version 3.0 further clarifies this original intent with section 7 "Additional Terms" which spells out that you can grant additional permissions, but gives only a specific list of additional restrictions that can be added.

If the FSF has any concerns or objections, they are always welcome to contact us so we can address them right away.

The objection is in the license text itself.

(Update: Meant to post this from my personal account to make it clearer that I'm speaking only on behalf of myself.)

[throwaway1037]

I do not mean to be rude, but are there any blockers for switching to a known free license? What more has to be done other than swapping out the license file? I apologise in advance if I seem rude, but I do not know how else to phrase this.

[nnposter]

Maybe it is the "triviality" of giving away control over intellectual property representing 20+ years of work? You bet I would take my time if I was in the same situation.

[throwaway1037]

Your statement is deeply flawed for the following reasons:

1. Licensing is often trivial, no matter how long the work has been copyrighted for; slapping a license onto a project shouldn't take more than a few minutes in many cases. However, I do agree that auditing can be a pain, especially with 20+ years of contributions and dependencies to sort through, and I also agree that care should be taken over a reasonable period of time. However, it is now 3 months later, and no progress appears to have been made.
2. The phrase "giving away control" is misguided. In reality, select permissions are willingly and carefully licensed in order to allow software freedom. The only power which is sacrificed is the unjust power over the users, which nobody should ever have in the first place.
3. The term "intellectual property" is so fatally flawed that anybody who uses the term is either so deeply confused themselves or is attempting to deeply confuse others, often for their own personal gain. In order to be charitable, I will presume the former. Please do not bundle disparate and wildly different laws together into one group. Copyright, patents, trademarks, trade secrets, and many other laws, are so completely unrelated that you should assume any fact about one is different from all the others. The term you used invites you to lump all these seperate laws, and many others, into one bucket and consider them as a whole, which is a wholly misguided and unjustified thing to do. Please stop spreading this propaganda term as it actively harms society. I would strongly suggest watching Richard Stallman's talks Copyright vs Community, and The Danger of Software Patents, in order to learn more about the specific issues of copyright and software patents, respectively.

[fyodor]

@throwaway1037 - I appreciate your passion about copyrights, but I don't find them constructive or useful here. For example, this really isn't the place for your opinions on the term intellectual property or for you to call any of Nmap's top developers "misguided" from your throwaway account that you seem to use exclusively to complain about copyrights of other people's projects all over GitHub. I haven't removed any of your posts, but am blocking future ones. I'm keeping this issue itself open because it's an important one that we still plan to further address.

[fyodor]

We are delighted to release Nmap 7.92, this year's Defcon release! Since we were too busy working on the technical improvements to put much time into NSPL license improvements, we have placed Nmap 7.92 under both the NPSL 0.93 and Nmap 7.80 licenses just like we did with Nmap 7.90 and 7.91. This way folks and distributors can choose whichever license they prefer. Of course we are also maintaining our Nmap OEM program for companies who wish to redistribute Nmap within their proprietary hardware and software.

[monraku]

Sorry for posting this with a new account. I only had one which is linked to an organization and I am not speaking for it in this thread.

We are still hoping to do a major license review before the next Nmap release, ...

This evidently did not happen. Neither for the new license nor the old license.

The old license was most likely misclassified by all major distros as a FOSS equivalent license for over a decade. The following factors most likely contributed to this.

1. Official nmap descriptions are worded in a way that makes people believe that it is truly FOSS. Text like "Nmap ("Network Mapper") is a free and open source ..." and the inclusion of GPLv2 license text "in" the own license contribute to that.
2. Most people are not license experts and it takes a lot of effort to understand license complexities.
3. People go the path of least resistance and after long and complicated discussions many people will just accept the answer they would like to hear and ignore major red flags.
4. Package maintainers do not have to fight if nmap comes and tries to force developers to buy a license even when nmap is used in full FOSS compliance. So they do not experience the real world conflicts which arise from nmaps licenses (new and old) because nmap would of course never threaten to sue the major distros or force them to buy a license. Only small players have that privilege.

It was mentioned that nmap should contact the FSF (legal@fsf.org) or similar organizations or hire some expert. There is no indication that nmap has followed up on any of this although there was serious intend communicated from nmap side.

Nmap wants to be considered FOSS but in reality it is very likely not FOSS no matter how many ambiguous changes are made to the current licenses.

@funnelfiasco @ulm @etu @hillu Did a review of the old and new licenses of nmap already happen by a third and qualified party? I think I, as a private person, am not high profile enough to get noticed by the FSF legal department (legal@fsf.org).

This still needs to be cleared up rather sooner than later because nmap is currently most likely not FOSS. Nmap should be labeled as non-free software until this is cleared up. The thread raises enough points that there is reasonable doubt about the FOSS status of nmap. This is the case for the new license and the old licenses. All the other nmap projects like Zenmap and Ncat probably have the same license issues.

I personally don't really care about further discussion of license details in this thread because everything which can be said by non legal experts has probably already been said.

[fyodor]

@monraku - In your whole long comment you never mention what parts of the old or new Nmap license you think violate the Open Source Definition. You just declare over and over (without any justification) that Nmap is "very likely not FOSS" and that everyone has been misclassifying it as such for decades.

There are many definitions of "Free Software" and some people even argue what "Open Source" means, but we go by the Open Source Initiative's Open Source Definition. If OSI says they don't believe Nmap's license is open source then we'll either modify the license to comply or we'll stop calling it open source.

[ajorg-aws]

@fyodor what are your thoughts on "1. Free Redistribution" and "9. License Must Not Restrict Other Software" from the Definition? I suspect those are the ones that a lot of us feel the new (and maybe also the old) license doesn't fit, but I can see how the Definition also doesn't spell out how "grabby" a copyleft license can or can't be, so I'm eager to hear your take on it.

(I posted this from an account associated with my employer, but my thoughts are my own and not my employer's.)

[ams]

Multiple people in this thread have raised where the current and old licenses are deemed problematic. To the point that several GNU/Linux distributions have either removed or classified nmap as non-free software based on those comments.

Nmap was also removed from the FSF Free Software Directory due to these reasons. https://directory.fsf.org/wiki/Talk:Nmap

[fyodor]

@ajorg-aws - Good question. Regarding those two sections you mention:

1. Free Redistribution
   The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee for such sale.

The old and new Nmap licenses have always allowed this. Most major free software distributions (such as Linux and BSD distributions) distribute Nmap in exactly this way. This principle means we can't restrict the mere aggregation of Nmap along with other software on a media like a Linux distribution DVD. But that doesn't mean we can't regulate how companies build Nmap into proprietary software products they distribute. If they are actively using Nmap, that's more than mere aggregation. And depending on how the products they distribute along with Nmap use Nmap, they might need to buy an Nmap OEM License. That's how we fund the product and pay developers. Similarly, you can always distribute GPL software along with any other software as long as it's "mere aggregation". But if you try to build the GPL software into your own software, you may have to follow the other GPL rules (such as making your software GPL compatible) if the integration is tight enough (such as incorporating their source code or linking to a GPL library).

9. License Must Not Restrict Other Software
   The license must not place restrictions on other software that is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.

This is also talking about what is "distributed along with the licensed software" in the sense of aggregating different software on one medium. We don't restrict what other software can be "distributed on the same medium". Our rules are for cases where an entity wants to distribute Nmap AND USE IT AS PART OF THEIR PRODUCT. Many certified open source licenses (including the GPL) regulate license compatibility for software that wants to integrate with the GPL software in certain ways. Nmap does differ from the GPL in exactly "how grabby" (as you put it) the license is, but that doesn't affect mere aggregation which is always allowed.

I hope this helps clarify why we think the Nmap license clearly adheres to the Open Source Definition. But we're willing to defer to the Open Source Initiative on that. If they care to review the Nmap license and conclude that it isn't open source, we'll either adjust the license wording to comply or we'll stop calling it open source.

[ajorg]

Thanks for the response. I appreciate it, and I think you've expressed yourself well, regardless if anyone disagrees with your interpretation.

that doesn't affect mere aggregation which is always allowed.

Isn't "Includes Covered Software in a proprietary executable installer" mere aggregation if it doesn't hit any of the other points in "3. Derivative Works"? It also seems a bit weird to include in the license since it's trivial to work around by using an installer format (like .msi on Windows or .pkg on macOS) that isn't an executable installer anyway. InstallShield itself can even output a .msi file for you.

Hypothetically if I wanted to sell an executable installer that installed an aggregation of redistributable (including open source) network and security tools, but none of my software knows anything about NMAP except maybe that it's part of the collection I pulled together, I can't see how using InstallShield makes my aggregation of software anything but a "mere aggregation".

The rest of the grabbiness questions I'm not actually sure I could disagree with you on, at least not against how the Open Source Definition is written today. My peers here should consider me undecided on those for now. Thank you for the food for thought.

(I remembered to respond from my personal account this time. I'm still not speaking for my employer.)

[ams]

Asking FLOSS projects to wait until a third party decides if they can or cannot use nmap is putting every single user of nmap into legal jeopardy. Maybe they are compliant maybe they are not.

Is nmap intended to be either open source software (OSD) or free software (four essential free software freedoms)?

This is even more important now since you mention that you might decide that it is neither.

[fyodor]

@ajorg - That's another good question. The reason we added the "proprietary executable installer" clause is that a number of sketchy companies like Download.com and even Sourceforge (after being acquired by shady parties) were wrapping Nmap and other open source software in trojan executable installers which also installed spyware, malware, adware, and other undesirable junk. Users thought they were just getting Wireshark or Nmap because it was presented as an "Nmap installer", but they ended up having their machine infested with this other crap. And of course they would blame us (Nmap Project) when the "Nmap Install" hosed their systems. There was a lot of press about this at the time. We updated the Nmap license to protect our users from this abuse.

Our view is that "mere aggregation" means users should be able to easily dis-aggregate without having to run a sketchy executable that could damage their system or compromise their privacy. If it's a ISO or ZIP file or tarball or other transparent format, users can dis-aggregate without taking that risk. Some executable installers can be unzipped like zip files, but not all work that way and users often don't know this anyway. If Nmap is combined with other code into a big executable that does who-knows-what other things when run, I don't think that's mere aggregation any more.

[ajorg]

Interesting. I wonder if the existence of open source InstallShield extractors like https://github.com/lifenjoiner/ISx means that such installers, while bad, would meet your definition of a mere aggregation now.

"6. No Discrimination Against Fields of Endeavor" means that open source licenses don't prevent evil uses like installing crapware. From the FAQ:

Can I stop "evil people" from using my program?
No. The Open Source Definition specifies that Open Source licenses may not discriminate against persons or groups. Giving everyone freedom means giving evil people freedom, too.

I'm also just not sure that clause actually stops anyone from doing the bad things they were doing, since they can just switch to .msi, which is not an executable installer.

If that were the only sustainable objection (I'm not sure it is, but personally I'm leaning that way) would you be willing to remove that point from your Derivative Works section?

[fyodor]

@ajorg - I don't know a whole lot about the MSI packaging format. If we start seeing rogue MSI packages of Nmap harming our users, we would have to research it more and figure out if there is anything we can do to prevent that. The reason for the "executable installer" distinction is that we didn't want to affect transparent open packaging/bundling systems like tarballs, zips, deb files, RPMs, ISO images, etc. Also the folks we've caught adding malware and adware to Nmap have all used the executable installer format.

The "no discrimination against field of endeavors" is one reason why we have to restrict executable installers in general instead of saying "no adding malware or crapware" to Nmap. Our rule applies equally to everyone, so there is no field of endeavor discrimination. Plus the malware/adware folks would try to game whatever definition we used to stop them.

If we had to choose between protecting our users from malware versus passing an ideological purity test just to call our software "open source", we would choose protecting our users and cease calling Nmap open source. But we would first try to find a way to do both. We might just have to adjust the license wording to protect our users another way.

[lfam]

I'm sympathetic to the dilemma of the Nmap team. The use of FOSS in malware is hard to accept and dealing with that problem is easier said than done.

In terms of using a legal framework to forbid such activity, maybe it's possible to rely on trademarks rather than copyright. For example, Mozilla has used the "Firefox" trademark to protect their brand, while still releasing the Firefox source code under a free software license that is accepted by the OSI and FSF (the Mozilla Public License). One needs permission to build and distribute "Firefox", although everyone is free to call it something else. Hence the existence of Iceweasel, Icecat, etc.

Well, the situation is different with Nmap, which is more likely to be used "under the hood" in a nefarious way than a browser, so maybe this mechanism is not enough for Nmap. It doesn't really matter what Nmap is called for such a use case. But as a distro packager I thought I should respectfully raise this option. My apologies if you have already considered it.