[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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.

| 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

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


Reply to: