[licence] specific licenses for backdoor-factory software

Ian Jackson ijackson at chiark.greenend.org.uk
Wed May 31 13:08:51 UTC 2017


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.

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.

> 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 ?

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.



More information about the Pkg-security-team mailing list