Re: Nmap Public Source License Version 0.94 - Is it DFSG-compliant?
Hello all,
On Mon, 5 Sept 2022 at 23:17, Hilko Bengen <bengen@debian.org> 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 <samueloph>
Reply to: