Dear Maintainer,

Considering the following case:

One of the files inside Package A is generated during build time.
However, the generation of the file requires Package B which has
different copyright, and the generated file in Package A is basically a
format conversion of the file in Package B, and the copyright needs to
be retained per license of Package B.  It could be copyright violation
of Package B if copyright status and requirements is not fulfilled in
Package A and we redistribute Package A.

I would suggest a tag "Files-Binary" in copyright-format to fulfill this
situation.

Yao Wei

control: tag -1 +moreinfo

Dear Yao,

What would the definition of this field be?  It is not clear from your
example.

Files-Binary would be package name and file path to the files which its
copyright is not in source package but in binary package.  For example:

  Files-Binary: package-a-data, usr/share/package-a-data/file-in-question
  Copyright:    2038 John Doe
  License:      Expat

---

Another solution to this problem is mark certain file which is generated
using what source package inside the header, and during build process
the copyright information requires to be attached in the binary package.
This should introduce another tag "Depends", like:

  Files-Binary: package-a-data, usr/share/package-a-data/file-in-question
  Depends:      package-b

If the maintainer knows what specific file in package-b it requires,
they can specify it like:

  Files-Binary: package-a-data, usr/share/package-a-data/file-in-question
  Depends:      package-b, data/orig-file

And if the specified file in package-b has the same problem of
package-a, as it only exists in binary package, it can be like this:

  Files-Binary:   package-a-data, usr/share/package-a-data/file-in-question
  Depends-Binary: package-b-data, usr/share/package-b-data/orig-file

---

For real-world use case, I am packaging glyphslib, which has above
problem for a stripped file which needs to be generated from source:

https://anonscm.debian.org/cgit/pkg-fonts/glyphslib.git/tree/debian/copyright

Please comment or propose another idea if the use case of them is not
clear.

Yao Wei

Hello Yao,

Thank you for taking the time to write this up!

If I understand correctly, the use case is when your package contains a
file, but the source is in another package?

I think there are two subcases.  Either

1. your binary package contains a file, and the source is in another
   package (your source package does NOT contain the file; it is
   generated/copied during build)
2. your source package (and maybe also your binary package) contains a
   file, and the source is in another package.

Case (1) is (roughly) what the Built-Using field is for.

The ftp-masters have indicated that case (2) is not acceptable.[1]
CCing them in case they want to expand on that.

So I don't think there is a use case for this.  But please let me know
if I've misunderstood.

[1]  https://bugs.debian.org/882723#35

Hi Sean,

My problem is roughly case 1 (and for me, to solve case 2). However as a
requirement of some licenses the file must come with the copyright notice,
and I am afraid if generates files which it's source comes from another
package cannot comply with such requirements.

The generated file inside the upstream package does have a copy of Expat
license and copyright notice in the file, but the generated file doesn't
include them.

It might be only build dependency but not runtime dependency and the
copyright notice should be carried by the binary package.

Yao Wei

Hello Yao,
this case is precisely what the Built-Using: field is for.

(I thought that this wasn't an issue with the Expat license, anyway;
only the GPL, but I'm not sure)

Hi Sean,

Built-Using doesn't contain copyright notice and license info, for example
Expat has the following clause:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

Yao Wei

Dear Yao,

Okay, I see what you're saying.

We don't add new fields to Policy until they see use in the archive (for
example, in #786470 we are discussing adding License-Grant: because it
is already being used in some packages).  So this bug should wait until
at least a handful of packages are using the field.

But secondly, you are surely not the first person to come across this
issue.  We need to determine how this has been handled before, and
whether the ftp-masters have even permitted packages with the situation
you describe into the archive.

I'll leave this bug tagged moreinfo until the above are determined.  Per
the Policy Changes Process the bug may be closed if the info is not
forthcoming in 30 days; don't be discouraged by this, because you can
always file a new bug when

- we have figured out what the best practice actually is here
- some packages are using that best practice.