Le Wed, Nov 04, 2009 at 11:47:52PM +0100, Frank Lin PIAT a écrit : > > Exemple 1: > > File: doc/info/* > > License: GFDL-NON-FREE > > Binary-Package: none > The package contains a file covered by a not-so-free license, but > that file isn't used to build the binary file. And the file isn't > shipped in the binary files. > > > Exemple 2: > > File: foo.c > > License: GPL-2 > > Binary-Package: foo > > > > File: bar.c > > License: GPL-3 > > Binary-Package: bar > The source package contains some files covered by two incompatible > license, but it isn't a problem because the binary aren't combined at > build nor at link time (or example). > > Exemple 2: > > File: foo.c > > License: GPL-2 > > Binary-Package: foo > > > > File: doc/info/* > > License: GFDL-NON-FREE > > Binary-Package: foo-doc-is-non-free > The source package produces both a free and non-free package.
Hello Frank, I think that we are still far from producing copyright files specific to binary packages, but definitely, let's be careful to not close doors, and if we can open some at low cost it is welcome of course. Also, there is nothing in the Policy that prevents maintainers to start doing this with their package if they feel like experimenting: Every package must be accompanied by a verbatim copy of its copyright and distribution license in the file /usr/share/doc/package/copyright. This file must neither be compressed nor be a symbolic link. My understanding is that if source package S produces binary packages A and B, /usr/share/doc/B/copyright does not need to describe the copyright of the files in A. This said, I think that we must care that copyright files are equally readable by humans and machines, and easy to produce. So even if the field you propose is optional, I think we need to consider how the copyright file would look like if its use were widespread. Also, maybe we can acheive a similar result without the using a new field, with an appropriate combination of control sums and helper files. Such a system could become a good safeguard against the inclusion of files that are not free in the wrong package. Note that it is not an issue for the moment as 1) non-free files are not allowed in the source packages, and 2) a source package in main can not produce a binary package for contrib or non-free. The field you propose could be an instrument for changing this, but I am affraid it is not on the agenda, and is not likely to become so in the near future (even if I would love to). In summary, I think that your proposition is quite ahead of its time, but I would have nothing against a ‘Future directions’ addendum to DEP-5 that would contain such a field after it has been more throroughly thought. Have a nice day, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
