Hello, On Mon 11 Apr 2022 at 05:51PM +01, Ian Jackson wrote:
>> 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.
In this case, I believe I was just passing on the other team member's
comment. What you say seems fine, though it should be documented in
d/copyright -- the code does not become GPL-3+ by being GPL-3-compatible.
>> 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}.
Sounds like I was just being confused by directory structure, then.
>> 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.
Cool. Just wanted to raise the question.
--
Sean Whitton
signature.asc
Description: PGP signature
