Hello Simon, Not speaking for the whole FTP Team in this mail, but maybe I can help a bit. On Wed 25 Mar 2020 at 05:47PM +00, Simon McVittie wrote: > On Wed, 25 Mar 2020 at 09:04:52 -0700, Sean Whitton wrote: >> On Wed 25 Mar 2020 at 08:58PM +05, Andrey Rahmatullin wrote: >> > On Wed, Mar 25, 2020 at 03:43:17PM +0000, Simon McVittie wrote: >> >> maintainers are incentivized >> >> to dot every i and cross every t in the copyright file even if it isn't >> >> strictly necessary >> >> >> > Do you mean it's not essential to track and list all licenses and >> > copyrights? > > Policy just says "a verbatim copy of its copyright information and > distribution license", which is not really enough to answer your question > either way. The ftp team are responsible for interpreting this part > of Policy in order to accept or reject packages, and have made various > announcements about what is or isn't acceptable. > > One thing that the ftp team clarified somewhat recently is that in > most cases, we must track all the copyright notices that exist in the > upstream source, and copy them into d/copyright. > https://lists.debian.org/debian-devel-announce/2018/10/msg00004.html I am not sure that it is quite right to understand the FTP Team as interpreting that particular part of Policy (anymore than any reader of Policy is involved in intrepreting it), because Policy currently requires strictly more than the FTP Team require. For example, if a package's license does not require all copyright notices to be included in binary distributions, and some are missing, we may well ACCEPT and file an RC bug, citing Policy. >> > IIRC only one simplification is permitted and I don't even >> > remember which one is it (maybe combining copyright years and names into >> > one entry? or just years?). >> >> With the machine-readable format, you can combine copyright years and >> names for files under the same license, yes. > > Strictly speaking, I am not aware of the ftp team having said this is > acceptable - although I've had packages ACCEPTed where I did this, so > presumably it must be (and the copyright file for non-trivial packages > would become even larger, and presumably more frustrating for the ftp team > to review, if this was considered to be unacceptable). > > Can you also combine licenses, like this real-life example from gtk+4.0? > > Files: * > Copyright: > 2009-2010 A S Alam > (... 380 other copyright holders ...) > License: LGPL-2+ and LGPL-2.1+ > > (some files are LGPL-2+, some are LGPL-2.1+, keeping track of which ones > significantly increases the length and maintenance cost of the file for > what seems to be little or no benefit) > > or even this? > > Files: * > Copyright: > 2009-2010 A S Alam > (... around 390 other copyright holders ...) > License: LGPL-2+ and LGPL-2.1+ and CC0-1.0 and (Expat or unlicense) and ... > > (some files are LGPL-2+, some are LGPL-2.1+, some are under one of the > permissive licenses mentioned) > > Rationale for wanting to do this: I suspect that for our purposes it > doesn't actually matter which individual files are under which permissive > licenses, as long as we document each license that is applicable, and > each copyright holder. The license that we, and our users, actually > have to obey when dealing with the source and binary packages is the > intersection of all the applicable licenses. I do not believe that you would get a REJECT where the combination involves a single license in the License: field. Your case, to be specific, is - using "and" to combine license shortnames in the License: field, - where the code under different licenses is in different files. (The uncontroversial case of using "and" in License: is when there is code under different licenses in a single file.) I am not sure there exists a consensus within the FTP Team about this sort of case and I agree that it would be useful to develop such a consensus. -- Sean Whitton
Attachment:
signature.asc
Description: PGP signature