Re: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?

[Florian Weimer]

* Sam Hartman:

>> "Francesco" == Francesco Poli  writes:
> Francesco> I am under the impression that a more correct way to
> Francesco> achieve the same results (free or non-free) would be to
> Francesco> create a different license, possibly reusing some parts
> Francesco> of the GNU GPL v2, but without referring to the GNU GPL
> Francesco> v2 (except for the acknowledgment that the new license
> Francesco> includes some modified pieces taken from the GNU GPL v2).
> Francesco> In other words, following the [FAQ].
>
> That's certainly what the FSF would prefer you do, yes.
> However, there are a few things to consider:
>
> 1) It's not clear that the FSF's copyright on the GPL allows you to
> borrow text from it for your license.  I believe it does not.

The FSF actually does on their web site:

| Can I modify the GPL and make a modified license?
|
| You can use the GPL terms (possibly modified) in another license
| provided that you call your license by another name and do not
| include the GPL preamble, and provided you modify the
| instructions-for-use at the end enough to make it clearly different
| in wording and not mention GNU (though the actual procedure you
| describe may be similar).
|
| If you want to use our preamble in a modified license, please write
| to  for permission. For this purpose we would
| want to check the actual license requirements to see if we approve
| of them.
|
| Although we will not raise legal objections to your making a
| modified license in this way, we hope you will think twice and not
| do it. Such a modified license is almost certainly incompatible with
| the GNU GPL, and that incompatibility blocks useful combinations of
| modules. The mere proliferation of different free software licenses
| is a burden in and of itself.

Re: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?

[Francesco Poli]

On Thu, 08 Sep 2022 23:32:34 -0600 Sam Hartman wrote:

[...]
> That's certainly what the FSF would prefer you do, yes.
> However, there are a few things to consider:
> 
> 1) It's not clear that the FSF's copyright on the GPL allows you to
> borrow text from it for your license.  I believe it does not.
> 
> 2) It will be harder to figure out how a license constructed as you
> propose differs from the GPL and may be harder to analyze such a
> license.
> 
> Keep in mind that the FSF, authors of the FAQ you point to want to make
> it hard to "fork" the GPL both because they would rather you simply pick
> the GPL and because they want to discourage license proliferation.
> There's nothing wrong with those goals; as an example Debian almost
> certainly wants to discourage license proliferation too.
> But those goals do create a certain bias in what the FSF recommends.

I agree with what you say here.

> 
> In either case, I think we're well beyond the scope of this list.

Yes.   :-)

-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpu7VoMGl5dp.pgp
Description: PGP signature

Re: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?

[Sam Hartman]

> "Francesco" == Francesco Poli  writes:
Francesco> I am under the impression that a more correct way to
Francesco> achieve the same results (free or non-free) would be to
Francesco> create a different license, possibly reusing some parts
Francesco> of the GNU GPL v2, but without referring to the GNU GPL
Francesco> v2 (except for the acknowledgment that the new license
Francesco> includes some modified pieces taken from the GNU GPL v2).
Francesco> In other words, following the [FAQ].

That's certainly what the FSF would prefer you do, yes.
However, there are a few things to consider:

1) It's not clear that the FSF's copyright on the GPL allows you to
borrow text from it for your license.  I believe it does not.

2) It will be harder to figure out how a license constructed as you
propose differs from the GPL and may be harder to analyze such a
license.

Keep in mind that the FSF, authors of the FAQ you point to want to make
it hard to "fork" the GPL both because they would rather you simply pick
the GPL and because they want to discourage license proliferation.
There's nothing wrong with those goals; as an example Debian almost
certainly wants to discourage license proliferation too.
But those goals do create a certain bias in what the FSF recommends.

In either case, I think we're well beyond the scope of this list.

Re: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?

[Francesco Poli]

On Thu, 08 Sep 2022 01:35:59 -0600 Sam Hartman wrote:

> > "Francesco" == Francesco Poli  writes:
> 
> Francesco> So licensing under the terms of the GNU GPL v2 and then
> Francesco> adding further restrictions creates a self-contradiction.
> Francesco> That does not seem a correct way to apply the GPL...
> 
> No, it does not.  That term--the term that forbids you from adding
> restrictions--clearly conflicts with the "main body of the license," so
> the main body of the license rather than the GPL controls.  Clearly such
> a license is not GPL compatible, although it may be free.  Other
> discussion in this thread suggests it is in fact non-free, but I want to
> push back on the idea that the license is self-contradictory (and thus
> non-distributable).

OK, maybe it does not create a self-contradiction.

However, I think that it is at least a bit misleading that this license
claims to be the GNU GPL v2 with exceptions/clarifications/additions,
when these exceptions effectively disable one of the main points of the
GNU GPL v2 (that is to say: "You may not impose any further
restrictions on the recipients' exercise of the rights granted herein").

I am under the impression that a more correct way to achieve the same
results (free or non-free) would be to create a different license,
possibly reusing some parts of the GNU GPL v2, but without referring to
the GNU GPL v2 (except for the acknowledgment that the new license
includes some modified pieces taken from the GNU GPL v2).
In other words, following the [FAQ].

[FAQ]: 


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpmuPQ7LkHRH.pgp
Description: PGP signature

Re: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?

[Hilko Bengen]

* Samuel Henrique:

> So now having read a bit more about this whole thing.
>
> The GPL restrictions do seem quite similar to what the NPSL have,
> related to Derivative Works, have a look at this from the FSF
> website[0]:
> """
> What is the difference between an “aggregate” and other kinds of
> “modified versions”?
> ...
> By contrast, pipes, sockets and command-line arguments are
> communication mechanisms normally used between two separate programs.
> So when they are used for communication, the modules normally are
> separate programs. But if the semantics of the communication are
> intimate enough, exchanging complex internal data structures, that too
> could be a basis to consider the two parts as combined into a larger
> program.
> """

An example of such "intimate enough" semantics might be a strictly
interpreted serialization format that is only practical to implement by
generating code from a formal specification such as Protocol Buffers.

For NMAP, there is no 2-way communication. To think that any ad-hoc
parser for NMAP's ad-hoc default output format (see below) makes it a
derivative work is, in my opinion, laughable.

,
| PORT STATE  SERVICE
| 21/tcp   open   ftp
| 80/tcp   open   http
| 139/tcp  open   netbios-ssn
| 445/tcp  open   microsoft-ds
| 515/tcp  open   printer
| 631/tcp  open   ipp
| 5431/tcp closed park-agent
| 9100/tcp open   jetdirect
`

I have no idea how many such more-or-less such parsers (for the default
or the XML-based format) there are in Debian but I'd be surprised if
even one of those were NSPL-licensed.

>From the reverse dependencies and package descriptions, there are at
least:

- gnome-nettool
- nmapsi4
- some openstack-related packages
- OCS iventory
- OpenVAS
- nikto
- brutespray
- 2 Python libraries
- 1 Perl library
- 1 Golang library

> The DFSG item 9 is also more about contamination by means of
> distribution other than interaction between the tools, as it says:
>  "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 free software."
>
> Considering both things, I'm inclined to say that the license is 
> DFSG-compliant.

I disagree: The NSPL *does* place such restrictions. Consider the last
bullet poiont of section 3:

,
| * 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.
`

I still think that nmap should go to non-free. I believe (but am not
sure) that this is unproblematic as long as there is not other software
in non-free that is a "derived work" according to the NSPL.

Cheers,
-Hilko

Re: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?

[Sam Hartman]

> "Francesco" == Francesco Poli  writes:

Francesco> So licensing under the terms of the GNU GPL v2 and then
Francesco> adding further restrictions creates a self-contradiction.
Francesco> That does not seem a correct way to apply the GPL...

No, it does not.  That term--the term that forbids you from adding
restrictions--clearly conflicts with the "main body of the license," so
the main body of the license rather than the GPL controls.  Clearly such
a license is not GPL compatible, although it may be free.  Other
discussion in this thread suggests it is in fact non-free, but I want to
push back on the idea that the license is self-contradictory (and thus
non-distributable).

Re: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?

[Francesco Poli]

On Sun, 04 Sep 2022 20:29:24 -0700 Walter Landry wrote:

[...]
> 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. Where the terms in this Main License
> Body conflict in any way with the GPL, the Main License Body terms
> shall take precedence.
[...]

But the GNU GPL v2 clearly states:

[...]
> 6. Each time you redistribute the Program (or any work based on the
> Program), the recipient automatically receives a license from the
> original licensor to copy, distribute or modify the Program subject to
> these terms and conditions. You may not impose any further
> restrictions on the recipients' exercise of the rights granted
> herein.
[...]

So licensing under the terms of the GNU GPL v2 and then adding further
restrictions creates a self-contradiction.
That does not seem a correct way to apply the GPL...

See also some [old discussions] about this kind of issue.

[old discussions]: 


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE


pgpcwps2k9X45.pgp
Description: PGP signature

Re: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?

[Francesco Poli]

On Mon, 05 Sep 2022 23:48:38 +0200 Hilko Bengen wrote:

[...]
> It has been suggested that upstream switch the
> license to AGPL3 instead, but nothing of the sort has happened and I
> don't expect such a change to happen anytime soon.
[...]

Speaking for myself: please, no.

Although the GNU AfferoGPL v3 is currently [accepted] by Debian FTP
Masters, it's a [controversial] license that a [number of people]
(including [myself]) consider non-free.

[accepted]: 
[controversial]: 
[number of people]: 
[myself]: 


-- 
 http://www.inventati.org/frx/
 There's not a second to spare! To the laboratory!
. Francesco Poli .
 GnuPG key fpr == CA01 1147 9CD2 EFDF FB82  3925 3E1C 27E1 1F69 BFFE

Re: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?

[Samuel Henrique]

So now having read a bit more about this whole thing.

The GPL restrictions do seem quite similar to what the NPSL have,
related to Derivative Works, have a look at this from the FSF
website[0]:
"""
What is the difference between an “aggregate” and other kinds of
“modified versions”?
...
By contrast, pipes, sockets and command-line arguments are
communication mechanisms normally used between two separate programs.
So when they are used for communication, the modules normally are
separate programs. But if the semantics of the communication are
intimate enough, exchanging complex internal data structures, that too
could be a basis to consider the two parts as combined into a larger
program.
"""

This does seem quite similar to what the NPSL does when it mentions
software that calls and parses data from NMAP, the difference being
that the GPL is not as explicit about it (it's a bit vague, probably
on purpose), although FSF states clearly that something like a shell
script that calls a binary and uses its output could fall into
Derivative Works.

The DFSG item 9 is also more about contamination by means of
distribution other than interaction between the tools, as it says:
 "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 free software."

Considering both things, I'm inclined to say that the license is DFSG-compliant.

Does this change your mind, Hilko, or are you still in the same position?

I'll try to get somebody else's opinion on this as well, maybe someone
from the ftp-master team could help.

[0] https://www.gnu.org/licenses/gpl-faq.html#MereAggregation

-- 
Samuel Henrique 

Re: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?

[Samuel Henrique]

Hello all,

On Mon, 5 Sept 2022 at 23:17, Hilko Bengen  wrote:
> My analysis posted there in March 2021 still stands: Upstream's broad
> definition about what constitutes a "derivative work" (a term that
> matters a lot in GPL 2) conflicts with the DFSG #9 "License Must Not
> Contaminate Other Software". For example, any program that is designed
> to parse NMAP's output would be considered a "derivative work".

Ah, got it, I had the impression this was addressed in 0.94 (your
comment was about 0.93 I believe), but this hasn't changed.

I'm assuming you're talking specifically about the following items
under the "Derivative Works" section:
"""
* 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).
"""

And indeed that sounds problematic to me too.
Upstream has mentioned that this has always been present in NMAP's
license, which is true as per our d/copyright file[0].
This means that if we consider 0.94 non-free due to these restrictions
under "Derivative Works", it means we consider the current release on
main to be non-free too, so it should be moved to non-free by
bookworm. If we only have issues with version 0.94 of the license,
this would mean the current release can stay on main and only new ones
go to non-free.

I'm gonna add a comment later today to that github issue, to rectify
that the "Derivative Works" section can be problematic (I know you
already did so, Hilko, but I'm afraid upstream might have not paid
enough attention due to the multiple threads going on there).
I think that by using the example of a shell script which calls NMAP
and parses its output, the issue might become more clear, as in this
example the script would have to be licensed under NPSL, due to nmap's
license. I assume this is something that wouldn't happen on any other
DFSG-approved licenses (and it would be really important to know about
DFSG-approved licenses where this would happen, if any).

I have to say these discussions about "Derivative Works" do make me
question the fragility of the definition even for GPL.
The GPL "contaminates" software which is linked against it, but if you
think about it, for softwares that doesn't expose a library (the usual
case is software with a machine-readable output), this would be the
equivalent of calling the software and parsing its output.
At the end you get the same result, the only difference is that
instead of using a symbol/API from a library, you're calling the
binary with parameters that will give you the output you want (could
be the very same output you would get from a given API). So in a way
that restriction on NPSL seems equivalent to what the GPL does to
libraries.
The line that is drawn here seems a bit arbitrary, I'm gonna study
more about this to see if I'm missing something. I appreciate others'
comments on it as well.

> The motivation for this peculiar license seems to come from grievances
> against producers of commercial, proprietary software and devices that
> incorporated NMAP. It has been suggested that upstream switch the
> license to AGPL3 instead, but nothing of the sort has happened and I
> don't expect such a change to happen anytime soon.

(this comment is more for other readers since I know Hilko knows what
I'm writing below)
Yes, although upstream is somewhat responsive on this matter, they're
not able to dedicate a lot of time on it.
I still have hopes that the situation is gonna improve.
Nmap changing it to AGPL3 doesn't seem very likely right now, but they
seem eager to make changes on NPSL.

> Ignoring the messy license does not seem to be an option and I don't
> want us to drop the NMAP package entirely, therefore I think it should
> be moved to non-free.

I agree with this, but I'd like to see if upstream would do something
to address the concerns about the "Derivative Works" definition.

[0] For someone who might not have context yet: yes, it might happen
that we find out the current license we have in main is non-free, so
this is not necessarily about the new one only.
Some relevant comments here:
https://github.com/nmap/nmap/issues/2199#issuecomment-787623648
https://github.com/nmap/nmap/issues/2199#issuecomment-787625270
https://github.com/nmap/nmap/issues/2199#issuecomment-787847234


--
Samuel Henrique 

Re: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?

[Hilko Bengen]

* Samuel Henrique:

> Nmap has just released its version 7.93, and it comes with a new
> license, similar to what it used to be, but it raised people's
> attention so the license got more scrutiny than ever and that resulted
> in long threads with no broad consensus.

nmap 7.90 with a license similar to the current version was released in
October 2020, almost two years ago. The upstream issue about the license
was started in December 2020, without any resolution.

My analysis posted there in March 2021 still stands: Upstream's broad
definition about what constitutes a "derivative work" (a term that
matters a lot in GPL 2) conflicts with the DFSG #9 "License Must Not
Contaminate Other Software". For example, any program that is designed
to parse NMAP's output would be considered a "derivative work".

The motivation for this peculiar license seems to come from grievances
against producers of commercial, proprietary software and devices that
incorporated NMAP. It has been suggested that upstream switch the
license to AGPL3 instead, but nothing of the sort has happened and I
don't expect such a change to happen anytime soon.

Ignoring the messy license does not seem to be an option and I don't
want us to drop the NMAP package entirely, therefore I think it should
be moved to non-free.

Cheers,
-Hilko

Re: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?

[Walter Landry]

Samuel Henrique  writes:
> Nmap has just released its version 7.93, and it comes with a new
> license, similar to what it used to be, but it raised people's
> attention so the license got more scrutiny than ever and that resulted
> in long threads with no broad consensus.

For the record, here is the complete text of the NPSL from

  https://svn.nmap.org/nmap/LICENSE

Cheers,
Walter

-

Nmap Public Source License Version 0.94
For more information on this license, see https://nmap.org/npsl/

0. Preamble

The intent of this license is to establish freedom to share and change
the software regulated by this license under the open source model. It
also includes a Contributor Agreement and disclaims any warranty on
Covered Software. Companies wishing to use or incorporate Covered
Software within their own products may find that our Nmap OEM product
(https://nmap.org/oem/) better suits their needs. Open source
developers who wish to incorporate parts of Covered Software into free
software with conflicting licenses may write Licensor to request a
waiver of terms.

If the Nmap Project (directly or through one of its commercial
licensing customers) has granted you additional rights to Nmap or Nmap
OEM, those additional rights take precedence where they conflict with
the terms of this license agreement.

This License represents the complete agreement concerning subject
matter hereof. It contains the license terms themselves, but not the
reasoning behind them or detailed explanations. For further
information about this License, see https://nmap.org/npsl/ . That page
makes a good faith attempt to explain this License, but it does not
and can not modify its governing terms in any way.

1. Definitions

* "Contribution" means any work of authorship, including the original
  version of the Work and any modifications or additions to that Work
  or Derivative Works thereof, that is intentionally submitted to
  Licensor by the copyright owner or by an individual or Legal Entity
  authorized to submit on behalf of the copyright owner. For the
  purposes of this definition, "submitted" means any form of
  electronic, verbal, or written communication sent to the Licensor or
  its representatives, including but not limited to communication on
  electronic mailing lists, source code control systems, web sites,
  and issue tracking systems that are managed by, or on behalf of, the
  Licensor for the purpose of discussing and improving the Work, but
  excluding communication that is conspicuously marked or otherwise
  designated in writing by the copyright owner as "Not a
  Contribution."

* "Contributor" means Licensor and any individual or Legal Entity on
  behalf of whom a Contribution has been received by Licensor and
  subsequently incorporated within the Work.

* "Covered Software" means the work of authorship, whether in Source
  or Object form, made available under the License, as indicated by a
  copyright notice that is included in or attached to the work

* "Derivative Work" or "Collective Work" means any work, whether in
  Source or Object form, that is based on (or derived from) the Work
  and for which the editorial revisions, annotations, elaborations, or
  other modifications represent, as a whole, an original work of
  authorship. It includes software as described in Section 3 of this
  License.

* "Executable" means Covered Software in any form other than Source Code.

* "Externally Deploy" means to Deploy the Covered Software in any way
  that may be accessed or used by anyone other than You, used to
  provide any services to anyone other than You, or used in any way to
  deliver any content to anyone other than You, whether the Covered
  Software is distributed to those parties, made available as an
  application intended for use over a computer network, or used to
  provide services or otherwise deliver content to anyone other than
  You.

* "GPL" means the GNU General Public License Version 2, as published
  by the Free Software Foundation and provided in Exhibit A.

* "Legal Entity" means the union of the acting entity and all other
  entities that control, are controlled by, or are under common
  control with that entity. For the purposes of this definition,
  "control" means (i) the power, direct or indirect, to cause the
  direction or management of such entity, whether by contract or
  otherwise, or (ii) ownership of fifty percent (50%) or more of the
  outstanding shares, or (iii) beneficial ownership of such entity.

* "License" means this document, including Exhibits.

* "Licensor" means Nmap Software LLC and its successors and assigns.

* "Main License Body" means all of the terms of this document,
  excluding Exhibits.

* "You" (or "Your") means an individual or Legal Entity exercising
  permissions granted by this License.

2. General Terms

Covered Software is licensed to you under the terms of the GPL
(Exhibit A), with all the exceptions, clarifications, and 

Nmap Public Source License Version 0.94 - Is it DFSG-compliant?

[Samuel Henrique]

Nmap has just released its version 7.93, and it comes with a new
license, similar to what it used to be, but it raised people's
attention so the license got more scrutiny than ever and that resulted
in long threads with no broad consensus.

There have been lots of discussions going on about it, and I think
it's better to post the links here and see what people think of it.

There doesn't seem to be a consensus on whether or not the license is
free overall, but upstream has made changes from feedback received
from the discussions.
The license seems to be a bit better now, but I should not make a
decision just by myself (I'm leaning towards considering it
DFSG-compliant but I'm not 100% sure yet).

I invite you to have a look at these discussions [0] [1], the latest
version of the NPSL [3], and also consider that some of the things
discussed have been addressed in the latest version.

My understanding is that the trouble revolves around the license
talking about proprietary products that ship nmap needing to buy an
OEM license, which I don't think it conflicts with the DFSG as this is
pretty much like a copyleft license with an extra hint that people can
buy the software at a different license if they don't want to respect
the copyleft aspect.
The discussions started due to some poor wording of that part, which
has been changed to address the concerns raised, so it looks fine to
me now.

Hilko has also done quite a good work reviewing and commenting on the
Github issue, although I don't know what his position is on the latest
version of the license, so I'm cc'ing him just in case.

I think we as the Debian project can contribute a lot by analysing
this license and declaring whether or not it is DFSG-compliant.

[0] https://github.com/nmap/nmap/issues/2199
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=972216
[3] https://nmap.org/npsl/npsl-annotated.html

Regards,

-- 
Samuel Henrique