Firstly, thanks to ftpmaster for your thorough review of this package.
For transparency, I am CCing this reply to debian-devel, and quoting
the whole of the REJECTED mail. There does not seem to be anything in
here that ought to be private. Please let me know if there is
somewhere better. (I considered -legal but it didn't seem
appropriate.)
FTAOD, I am not, with this mail, asking -devel for a peer review of my
package's licensing status, nor of the ftpmaster decision; just using
-devel as a catch-all list.
Sean Whitton writes ("secnet_0.6.2_multi.changes REJECTED"):
> +----------------------+
> | REJECT reasoning |
> +----------------------+
>
> Another team member identified that there is code in this package
> under a number of different licenses other than GPL-3+, but that is
> not specified in sufficient detail in d/copyright. That contravenes
> both Debian Policy and the terms of those licenses.
My apologies. You are completely correct. I don't understand how I
came to think that the approach I took was sufficient. I guess it is
a long time since I prepared a package with so many different bits and
pieces in it.
> They also pointed out that there is some code from StackOverflow,
> which is not GPL-3+.
I think this is not right? I think you are referring to
`argparseactionnoyes.py`. As I documented in the file header, it is
part of StackOverflow's TOS that contributors grant a CC-BY-SA 4.0
licence for the snippets they upload, which would make the
contributions GPL3+-compatible. My file comment gives the relevant
references. [1]
It seems to me that StackOverflow have chosen this approach (making
the upload licence part of the TOS) precisely to enable people to copy
code fragments out of StackOverflow into their own projects. ISTM
that in (unless it appears that the posting StackOverflow user did not
write the code in question), we should be able to rely on that.
Can you please confirm whether the opinion of the ftpmaster team, that
is not sufficient? If it is not sufficent, I guess I will find
someone to write a clean room implementation of this 22-line class.
> I noticed that b91dec.{php,awk} have no license information at all.
As you observe, these files as provided by upstream do not themselves
contain licence information. But the file base91-c/README (which is
provided by upstream) says, amongst other things:
All source code in this package is released under the terms of the BSD license.
See the file LICENSE for copying permission.
And these files were (according to their copyright notice) written by
the same author and clearly part of the base91-c project. I think
this licence therefore applies also to the files b91dec.{php,awk}.
> +----------------------+
> | Other comments |
> +----------------------+
>
> Your changelog mentions changes to comply with modern Policy, so please
> consider upgrading the standards-version too.
Thank you. I appear to have omitted to do this when doing my
standards update review.
> Shouldn't subdirmk be a separate package?
Well. It is designed to be "git-subtree"'d into one's package. That
is the way the upstream package uses it.
It would be possible to make it a separate package and build-depend on
it, at the cost of some additional work. The upside would be a very
small amount of disk space saving, and largely theoretical saving of
work in case of a need to do a security update for subdirmk (which
seems unlikely to be critical since it's build system software which
is designed to execute its input) - and that all only in the case
where a second package in Debian uses subdirmk.
It seemed me best to me to defer this work until subdirmk becomes more
widely used.
Thanks,
Ian.
[1]
https://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?p=secnet.git;a=blob;f=argparseactionnoyes.py;h=a7eef77771c46345be27eaa90a17858bc52a3f60;hb=HEAD
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
Pronouns: they/he. If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.
