On 5. September 2014 10:14:56 MESZ, Gianfranco Costamagna
<costamagnagianfra...@yahoo.it> wrote:
>Hi Tobias,
>
>
>
>
>> Il Venerdì 5 Settembre 2014 8:46, Tobias Frost <t...@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
>>
>
>
>--
>To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
>with a subject of "unsubscribe". Trouble? Contact
>listmas...@lists.debian.org
>Archive:
>https://lists.debian.org/1409904896.78283.yahoomail...@web171806.mail.ir2.yahoo.com
OK. Then please close the bugs and remove the package from mentors. (Please add
to the ITP a comment regarding the license)
--
Tobias Frost
13C9 04F0 CE08 5E7C 3630 7985 DECF 849A A635 7FB7
