[licence] specific licenses for backdoor-factory software

[Philippe Thierry]

Le 31/05/2017 à 15:08, Ian Jackson a écrit :
> phil at reseau-libre.net writes ("[licence] specific licenses for backdoor-factory software"):
>> I'm currently packaging "backdoor-factory" for the pkg-security team.
>> The tool is already in kali.
>> The upstream sources are hosted here:
>> https://github.com/secretsquirrel/the-backdoor-factory
>>
>> The main tool is based on the  following license file (LICENSE.txt) :
>> -------------------8<-------------------
>> Copyright (c) 2013-2016, Joshua Pitts
>> All rights reserved.
>>
>> Redistribution and use in source and binary forms, with or without
>> modification, are permitted provided that the following conditions
>> are met:
> This is a perfectly fine licence very like the 3-clause BSD.
Ok thanks.

>
> However:
>
>> The upstream sources also contain a subdir (not required for the tool
>> but existing in the upstream git repository), containing the tool aPlib
>> (a compression library).
>> This tool is using the following license (looks like common license),
>> file aPLib/readme.txt:
> This is evidently a homegrown licence text written by someone without
> the necessary legal knowledge.
>
> Unfortunately:
>
>> You may not edit or reverse engineer any of the files (except the
>> header files and the decompression code, which you may edit as long
>> as you do not remove the copyright notice).
> This is clearly non-free.  It forbids modification.
>
>> - Is the main software legaly acceptable for Debian ?
>
> The upstream part is fine.  But:
>
>> - Do i need to clean the upstream (deleting aPlib dir) making a dfsg
>> package
> Yes.
Ok done. APlib has been cleaned, as binary-only content (one stub file 
for windows).

>
>> or the upstream can be kept in the source package untouched if
>> the aPlib is not installed in the bin packages ?
> No.  Debian's practice is to require the removal of non-free
> components from source packages, even if they are supposedly not
> touched by the build.  This ensures that there is no accidental
> dependency of the non-free parts.
>
>
> Will the program build and work without aPlib ?  Why would it ship
> with its own compression library ?
As far as i tested, it perfectly works withour APlib. Maybe it's a need 
for other type of bin (Windows PE files or others) but i didn't found 
any call to the built binary (appack) in any of the python main project. 
Looks like useless.
I will ask the upstream maintainer about this.

> In the medium to long term it might be worth asking upstream to either
> drop their special compression library, or fix the licence (best done
> by choosing an existing widely-used Free Software licence).
>
> Regards,
> Ian.
>
>
Ok. Thanks to both of you !

Regards,
-- 
Philippe.