Hi Ian,
Thank you for the quick reply, and sorry for the delay. I have a bit
of free time today, but after that I (again) won't have much time for
Debian work for the next two weeks.
On Mon, Aug 14, 2017 at 09:12:04PM +0100, Ian Jackson wrote:
> Nicholas D Steeves writes ("File is BCP 78 or Simplified BSD? Lintian says BCP 78"):
> > I am wondering if Lintian correctly detected a file's copyright as BCP
> > 78, or if it's a false alarm. I want to believe that it's a false
> > alarm, but have submitted a patch to make the package dfsg-free in
> > case it is not a false positive (Bug #868258).
>
> It's a false alarm. I think the file is entirely "Code Components"
> which the text itself says is released under the "simplified BSD"
> licence, and it references sha.h, which is here
> https://raw.githubusercontent.com/kdave/btrfs-progs/master/tests/sha.h
>
> It would be best to tidy up by getting rid of the misleading BCP78
> boilerplate, which doesn't apply to the code, only to the rest of the
> document (none of which seems to be present in sha224-256.c at least).
>
> > The file in question is btrfs-progs/tests/sha224-256.c
> > https://raw.githubusercontent.com/kdave/btrfs-progs/master/tests/sha224-256.c
That's a relief! So this can be solved with (mandatory) additions to
debian/copyright and a patch to upstream.
> > I am writing to you because it seems like this might be a matter of
> > interpretation. eg: that the official specification is BCP 78, but
> > that the code samples are Simplified BSD. It might also be necessary
> > to consult two other files introduced in the same commit. Here is
> > that commit:
> >
> > https://github.com/kdave/btrfs-progs/commit/4ddd6055c333932b561046ad1d41234d773246d2
>
> github says "3 changed files" and then lists changes to 2 files. The
> changes to sha.h are fine. What is the 3rd file ?
I'm not sure why github didn't show changes to the third file when you
checked. When I check it on github, and when I look at
4ddd6055c333932b561046ad1d41234d773246d2 in gitk it shows changes to
tests/sha-private.h, tests/sha.h, and tests/sha224-256.c.
So far we have:
sha.h -> 2-clause (Simplified BSD)
sha224-256.c -> send patch to upstream to remove misleading BCP78
boilerplate
sha-private.h -> "See RFC 6234 for details"? ...so 2-clause?
After consulting RFC 6234, it seems that maybe this header needs a
2-clause boilerplate, because
Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
If this is the case then upstream will also need a patch for
sha-private.h, no?
Kind regards,
Nicholas
Attachment:
signature.asc
Description: PGP signature