Nmap Development mailing list archives

Re: Using Samba code?


From: Fyodor <fyodor () insecure org>
Date: Sat, 27 Sep 2008 15:15:02 -0700

On Tue, Sep 23, 2008 at 07:28:06PM -0500, Ron wrote:

I'm still working on SMB stuff, and there's a couple bits of Samba code
that I'm planning to indirectly use (that is, to translate to Lua or
just to reference). I just wanted to make sure there wouldn't be any
licensing issues (both projects are GPL, I think, but I'd rather be on
the safe side).

Hi Ron.  Good question.  That can be a tricky situation, and of course
I'm not a copyright lawyer.  Any code derived from Samba or any other
GPL source generally CAN NOT be included within Nmap (even as an NSE
script).  Sometimes you can persuade authors to grant an exception
allowing us to use sections of code under a less restrictive license
(such as BSD, MIT, or LUA licenses), which we generally can include
into Nmap.  For example, the Metasploit Project has a different
license than Nmap, so we granted them a license exception so they
could ship Nmap within their Windows installer.  Also, someday (when I
find a good open source lawyer and find time), I might want to change
the Nmap license to a different one such as this draft I made years
ago: http://nmap.org/npsl/npsl-annotated.html .  That Nmap Public
Source License, like our current license, is GPL + some extra terms.
We could not do that if we included other people's GPLv2 code.

This rule only applies to scripts included with Nmap.  If you write a
script and distribute it yourself as GPL, it doesn't really matter to
the Nmap Project since you are then responsible for copyright
compliance.

The main piece to convert to Lua is Samba's NT error codes. SMB has
about 500 different error conditions, which are all documented in
Samba's source. Is that ok to use? Here's an online copy:
http://www.sfr-fresh.com/unix/misc/mc-4.6.1.tar.gz:a/mc-4.6.1/vfs/samba/include/nterr.h

That might actually be OK, since it seems to be purely extracted data
rather than an expressive/creative work such as most code.  The header
says "They were extracted using a loop in smbclient then printing a
netmon sniff to a file".  So if these status codes have the same names
and numbers as given by Microsoft, and are needed for
interoperability, we can probably use them if we have to.  See the
"minimum originality" discussion below.  Still, maybe you can look
around and see if they are available from another source with a more
liberal license?  Are these values in the header files distributed
with MS Visual Studo?

The other piece is the MSRPC function prototypes, but that's so indirect
that I don't know if it even counts as a derivative work. Here's the
file in particular:
http://websvn.samba.org/cgi-bin/viewcvs.cgi/branches/SAMBA_4_0/source/librpc/idl/samr.idl?view=markup

If you are just using this file to determine the API for communicating
with a few functions, that doesn't sound unreasonable.  Though again,
it would be best if you can find the same data from some other source
you can reference which has a more liberal license.

So in conclusion, if you want to use 3rd party GPL code in Nmap
(including NSE scripts), you need to either:

* Persuade the author to license those portions of the code under a
  license we can use, such as BSD no-attribution.  Or for a data like
  this, they might agree that they don't assert copyright control over
  the raw data.

* Rewrite the code yourself in a way which doesn't violate copyright rules

* Find similarly useful code which is already under a more liberal license and use that.

* Or have a valid fair use justification, such as you often see for images
  in Wikipedia.  For example, certain pure data files may not be
  eligible for copyright protection since they are considered a
  compilation of facts and don't satisfy the "minimum originality"
  requirement.  For an example (alphabetical phone books and food
  recipes not qualifying for copyright protection), see: 
  http://en.wikipedia.org/wiki/Feist_v._Rural

I hope this helps clarify things.

Cheers,
-F

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org


Current thread: