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

Bug#760453: RFS: amap/5.4+dfsg-1



Hi Tobias,




> Il Venerdì 5 Settembre 2014 8:46, Tobias Frost <tobi@debian.org> ha scritto:
> > On Thu, 2014-09-04 at 14:36 +0100, Gianfranco Costamagna wrote:
>> 
>>  > 
>>  > Hi Gianfranco,
>>  > 
>>  > Well, amap has been previously been removed from Debian due to 
> licesnse
>>  > reasons. (Please see #346313) You write in #753704 that is no longer 
> is the
>>  > case -- I just saw that LICENSE.AMAP is still there without any 
> further
>>  > digging; can you briefly update me?
>>  > 
>> 
>>  Hi Tobias,
>> 
>>  In #346313 the developer says:
>> 
>>  "hmmm so basically I need to edit the LICENSE.GNU file to remove the
>>  license name as well as to remove the "no further restrictions"
>>  paragraph from it?
>>  ok, I will do that then for the next release ..."
>> 
>> 
>>  Seems that the developer didn't do this, but in the source files 
> (headers) you can see the license is GPL,
>>  and the LICENSE.GNU is almost the same as the one in 
> usr/share/common-licenses.
>> 
>>  So IANAL, but we can just refer to the GPL-2 license, because the other one 
> is not actually used?
> 
> Well, the presence of the LICENSE.AMAP file and stating that this is the
> "LICENCE FOR AMAP (all version)" brings some doubt that GPL-2 (or 
> GPL-2+
> as in the souce) is the effective license; it could be "GPL-2 witorth
> AMAP Restrictions" (lets look at those below) and that would be indeed 
> I just checked debsnap olds version (doing just a lazy "gbp import-dscs
> --debsnap amap") and compared it to the current source: The license
> headers in the *.(c|h) has not been changed since.
> 
> (So I fear that we cannot say it's GPL without a clear statement from
> upstream.)
> 
> Unfortunatly, LICENSE.AMAP is not dfsg-free: For example, it fails The
> Desert Island test ("must be made available to
> the author free of charge"). and maybe The Dissident Test (enforcing
> that commercial use say that it uses the programm; 4. and 5. of the
> license. [1] 
> (The special requirements for use in commercial fields are non-free as
> well, DFSG §5)
> 
> Licenses' §2 "except for a small transfer/medium fee" is non-free 
> (see
> 12j and 21 in [1])
> 
> Licenses' §3 is clearly non free (DFSG §6); refer to the famous JSON
> Licsense "Must used for good not evil" (see also 
> 
> (BTW, License 6 is a contradition to the source -- the source says
> "GPL-2+" while §6 says only "GPL-2")
> 
> [1] https://people.debian.org/~bap/dfsg-faq.html
> 
> So its non-free... Unless the authors relicenses in a way that
> LICENSE.AMAP is not applicavble anymore.
> 
> Trickier is to evaluate if the AMAP and the GPL are compatible, because
> if not the whole would be not even distributeable. (GPL §7)
> So my concerns are GPL §6 -- "You may not impose any further
> restrictions on the recipients' exercise of the rights granted herein.
> You are not responsible for enforcing compliance by third parties to
> this License." 
> Is "herein" the complete license or just the GPL part? I think I read
> somewhere (couldn't find the source now) the latter, and then it would
> become not distributeable at all 
> I absolutely not sure on the above -- this question should be directed
> to debian-legal... (If I'd be right, amap would not even suitable for
> non-free)
> 
>>  > Otherwise, would be non-free possible (I need to think about it -- its 
> complex
>>  > topic -- if an upload to non-free could be possible instead 
> license-wise)
>>  > 
>> 
>>  I don't know about this, I still don't understand this kind of 
> licenses war (I mean, I understand them but I don't like them) ;)
> 
> Yes, copyright/licenses are hard, tedious and boring, but unfortunatly
> it is very important to be accurate here, as these might create legal
> risks for the project. 
> 
>>  > Upstream also writes that amap is depreciated in favour of nmap... Do 
> you have
>>  > any specific *why* wee still should have it in Debian, this question 
> is not to
>>  > torture, but this question could come up from other parties.
>> 
>>  some tools (e.g. openvas) uses it, moreover for some specific applications 
> should perform better than nmap.
>> 
>>  "So today, I recommend to rather use nmap -sV for application 
> fingerprinting rather than amap (although in some circumstances amap will yield 
> better results, but these are rare)."
>> 
>>  "    Currently there are two tools for this purpose: amap (you are 
> looking
>>      at it), and nmap (www.insecure.org/nmap).
>>      Both have their strength and weaknesses, as they deploy different 
> techniques.
>>      We recommend to use both tools for reliabe identification.
>>  "
>> 
>>  I know some penetration testing distros uses it, but I don't know how 
> better performs than nmap, so maybe we can just leave it go.
>> 
> 
> Ok, it seems that for (the niche of) pentesting this program could be
> interesting in addtion to nmap. (I think the website says that amap can
> do IPV6, but nmap not -- I don't know if this is real or just old
> information)
> 
> 

I suspect the license problem is too risky, even if upstream is *clearly* don't caring about the wrong license files (yes, they are wrong since they conflicting each others).

So maybe we need just to close this one among with the other and let the package go :)

thanks for the reply!

cheers,

Gianfranco
> -- 
> tobi
>


Reply to: