d/copyright entries for licenses and copyright data

[Ross Vandegrift]

Hello,

Suppose project A includes code from project B. To be good stewards of license
and copyright data, A incorporates B's license and copyright files into their
source distribution.

How should these files appear in d/copyright? I don't see any suggestion in
[1] or [2].

Thanks,
Ross

(Please CC me, I'm not subscribed.)

[1] https://dep-team.pages.debian.net/deps/dep5
[2] https://www.debian.org/doc/debian-policy/ch-docs#s-copyrightfile

[Ross Vandegrift]

Hi Paul,

On Sat, Jan 06, 2024 at 01:12:50PM +0800, Paul Wise wrote:

> On Mon, 2024-01-01 at 13:16 -0800, Ross Vandegrift wrote:
>
> > Suppose project A includes code from project B.
>

> The best option would be to talk to upstream about removing the copy,
> further advice about embedded copies is on the wiki:
>
> https://wiki.debian.org/EmbeddedCopies

Definitely agreed in general. I had a different kind of situation in mind.

Imagine I take some code from a freely licensed reference implementation and
customize it. The result is a derived work. But this embedding isn't
removable - the reference implementation shouldn't accept changes to integrate
it into a specific project. It'd be reasonable to include the original license
and copyright statements.

If I do, Debian requires packagers to describe the license and copyright on
those embedded license/copyright files. And I'm puzzled about how to do that
best.

Maybe the answer is to repack it away? But that seems weird. It's freely
redistributable, and that'd be *obscuring* license/copyright details. We
usually like that. :)

The same issue arises for disabled conveience copies. The wiki suggests
Files-Excluded, but also alternatives that involve Debian redistributing the
convenience copy (and so probably it's license/copyright files) in source
packages.


(I realize not much hangs on this - but cme/licensecheck raised the issue to
me. I can ignore it, but also got curious and tried to figure out what to do.)

> > How should these files appear in d/copyright?

> > (Please CC me, I'm not subscribed.)
>

> Richard Laager responded but forgot to CC you, I bounced the message:
>
> I document them the same, except that I also add use the DEP-5 "Comment"
> field to indicate that it came from "B".

Thanks!

Ross

[Ross Vandegrift]

Hi Richard,

On Tue, Jan 02, 2024 at 10:31:23PM -0600, Richard Laager wrote:
> I document them the same, except that I also add use the DEP-5 "Comment"
> field to indicate that it came from "B".

That's a nice idea. If I claim my software distribution is licensed under the
GPL, then it's natural to think I mean all of the software distribution.
Simple way to represent what project B probably intended.

(I realize there's also something fishy - that GPL isn't really under the GPL -
but IANAL and this is still better than I'd thought of before.)

Ross

[Ross Vandegrift]

Hi Paul,

On Mon, Jan 08, 2024 at 12:54:25PM +0800, Paul Wise wrote:

> On Fri, 2024-01-05 at 22:31 -0800, Ross Vandegrift wrote:
>
> > Imagine I take some code from a freely licensed reference implementation and
> > customize it.  The result is a derived work.  But this embedding isn't
> > removable - the reference implementation shouldn't accept changes to integrate
> > it into a specific project.
>

> The reference implementation should be flexible enough to work as a
> library imported/loaded/linked by any project that wants to use it.

Perhaps - but some people provide code without having any interest in the
implementation details that users might run into. Still, that code might be
useful to use & distribute.

This is one of many ways Debian and upstream might have different or
conflicting goals.

> > It'd be reasonable to include the original license and copyright statements.
>

> Right.

>
> > If I do, Debian requires packagers to describe the license and copyright on
> > those embedded license/copyright files.  And I'm puzzled about how to do that
> > best.
>

> Same as for any other file in the source package, list in the
> debian/copyright which files have which copyrights and licenses.

Heh, right - the problem is executing that. :) Folks typically take care to
document the copyright on code, not so often licenses (the FSF licenses being
the exception, they are clear).

> > (I realize not much hangs on this - but cme/licensecheck raised the issue to
> > me.  I can ignore it, but also got curious and tried to figure out what to do.)
>

> What issue did it print? Which package/code is this about BTW?

src:efl is a pastice of original work, dervied code, and vendored copies. The
situation I asked about is somewhat simplified from real ones. Here's two
harder cases than what the wiki considers:


- https://salsa.debian.org/pkg-e-team/efl/-/blob/debian/sid/src/static_libs/rg_etc/README

This is a Zlib license statement for code derived from another project. This
copy has been rewritten from C++ -> C. So the changes wouldn't be appropriate
for the upstream project.

What license and copyright holders can I write for this file? The text is
derived from the Zlib license, but I also don't know who wrote that.

- https://salsa.debian.org/pkg-e-team/efl/-/blob/debian/sid/src/static_libs/fnmatch/COPYRIGHT

This is from an included copy of musl's fnmatch algorithm. I think EFL
includes this for portability, to ensure that the same fnmatch is used on
Linux, BSD, and Windows. Even if that's not needed in Debian, I don't think I
can link to musl and glibc.


Interestingly, base-files (which contains /usr/share/common-licenses) doesn't
contain any copyright information for some of it's licenses. It also doesn't
use dep5 copyright, and so probably not licensechcek/cme. So no one is being
bugged to document who holds the copyright to the MPL-1.1.

Ross


[1] - src:efl has those too. I'm recently trying to remove a libunbreak copy
in the static_libs directory.