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

2022-09-08 Thread 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?

2022-09-05 Thread 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