Re: length of Debian copyright files
On 4/11/20 4:47 PM, Wouter Verhelst wrote: > My point is that the machine-readable format is being "abused" to > deep-check the copyright status of all the files, and to reject > stuff/file bugs/... based on that. Probably, but you're not forced into doing it. For example, if you find that some files have different copyright holders with the same license, it's fine to just merge both in a single paragraph, if you mention both copyright holders. I believe you could generalize this by also merging multiple license and copyright holders in a single paragraph. > Yes, a machine-readable copyright format is useful for our users. It > is, however, not useful if it is being used to inspect packages and kick > maintainers for not doing useless busywork. It is my belief that this is > actually happening, and therefore I don't want to do the > machine-readable copyright format. > > People who care enough about the license of a piece of software that > they *do* need to know *all* these details can do the damn busywork > themselves; I will not. With what I wrote above, you don't need to go into details, but still use a format which can be parsed by a machine. Something like this: Files: * Copyright: (c) YEAR copyright holder 1 (c) YEAR copyright holder 2 Comments: Parts of this software are released with license-1 and others with license-2. See individual files for details. License: license-1-or-license-2 License-1 . foo . license-2 . bar As much as I know, writing the above is still Debian compliant, you don't go into each file details, and everyone is happy. If the above is wrong, please someone (from the FTP team?!?), explain me (and everyone else) why it's legally wrong. Cheers, Thomas Goirand (zigo) P.S: I personally don't do the above, and make the extra effort of copyright holding and license attribution to each individual files.
Re: length of Debian copyright files
Hello, On Sat 11 Apr 2020 at 11:56AM -04, Scott Kitterman wrote: > It's nonsense. There is zero difference in what's accepted or not based on if > the machine readable copyright format is used. We may point out errors in use > of the machine readable format, but it's not a criteria for rejection since > its use is optional (note: there may have been occasional instances of this > when combined with other problems). Yes, except when the misuse of the machine-readable format makes the copyright file say the wrong thing, or makes it too ambiguous. -- Sean Whitton signature.asc Description: PGP signature
Re: length of Debian copyright files
On Saturday, April 11, 2020 11:41:50 AM EDT Jonas Smedegaard wrote: > Quoting Wouter Verhelst (2020-04-11 16:47:13) > > > On Sat, Apr 11, 2020 at 11:29:22AM +0200, Jonas Smedegaard wrote: > > > Quoting Wouter Verhelst (2020-04-11 10:36:44) > > > > > > > On Wed, Mar 25, 2020 at 03:43:17PM +, Simon McVittie wrote: > > > > > Debian: > > > > > https://tracker.debian.org/media/packages/g/gtk%2B4.0/copyright-3.98 > > > > > .0-1 > > > > > plus we ship the LGPL in base-files' common-licenses. > > > > > > > > This kind of insanity is actually why I refuse to use the > > > > machine-parseable copyright format. > > > > > > > > Nobody cares that some file somewhere deep down in the source tree > > > > is perhams maybe somewhat more permissive than the license on the > > > > whole. If the license on the whole is a copyleft license, then > > > > that file somewhere deep down is made available to you as that > > > > copyleft license, due to "copyleft". > > > > > > > > Anything else is insanity, and I refuse to waste my time on it. > > > > > > You seem to conflate two issues: > > > > > > a) writing debian/copyright in a machine-parsable format > > > b) writing debian/copyright with too much detail included > > > > > > Please use the machine-readable format because then machines can > > > help us. If you find it insane how detailed machine-readable format > > > _can_ be, then please use the format _without_ the insanity. > > > > My point is that the machine-readable format is being "abused" to > > deep-check the copyright status of all the files, and to reject > > stuff/file bugs/... based on that. > > Abuse is seriously bad. Not sure what you mean by "abuse" in quotes, > though, so let me try break it apart. Please tell me if I totally > missed what you tried to say (I genuinely want to understand, not mock). > > Real bugs should be identified and reported, and using machine-readable > data to aid in that is great. Or do you disagree with that? > > Filing bugreports for non-bugs is wrong, and doing it in automated ways > (e.g. by use of machine-readable data) is abuse (unquoted) and should be > stopped - regardless of who does it. If that's what you are talking > about, then could you perhaps point at some examples that might help > identify a pattern for countering such abuse? > > Since it keeps coming up that ftpmasters rejects for wrong reasons: > Assuming good faith, I can only imagine it be _rumors_ only, stemming > from a) clumsy behaviours in past dark ages and/or b) misinterpretation > of rejection messages. Therefore: Please if anyone can shed more light > on such rumors(!) please do - e.g. share recent(!) rejection emails > showing it is fact, not rumor. It's nonsense. There is zero difference in what's accepted or not based on if the machine readable copyright format is used. We may point out errors in use of the machine readable format, but it's not a criteria for rejection since its use is optional (note: there may have been occasional instances of this when combined with other problems). Scott K signature.asc Description: This is a digitally signed message part.
Re: length of Debian copyright files
Hello, On Sat 11 Apr 2020 at 12:49PM +01, Simon McVittie wrote: >> Files: * >> Copyright: The GTK Team and others >> License: LGPL-2+ and LGPL-2.1+ >> Comment: >> Specific authors omitted (unneeded for this license, and list is long). > > My understanding is that the ftp team would consider this to be a bug, > and possibly a RC one, because: > > - the permissive licenses have been omitted (it should say > "LGPL-2+ and LGPL-2.1+ and Expat and (Expat or unlicense) and ..."); Policy says it's an RC bug: "Every package must be accompanied by a verbatim copy of its distribution license in the file /usr/share/doc/package/copyright." (§2.3 and elsewhere). Whether the FTP Team would reject it depends on our judgement as to whether Debian would be violating any license terms by not including it in d/copyright; I can't say without looking at the package. The main factor is usually whether the files ends up in the binary package or not. In general, whether something is an RC bug is not really an FTP Team matter; that's Policy and the Release Team. When we file bugs based on NEW review, severities are chosen based on Policy. That's why we sometimes ACCEPT a package but then file an RC bug. > - not all of the copyright notices that exist in the source code have > been copied into the copyright file I've recently patched Policy to be much more specific and more inline with the FTP Team's consensus on this point. https://salsa.debian.org/dbnpolicy/policy/-/commit/0dc2eefc784d064b6398aa3f5233eb5b81b9e260 (not released yet) -- Sean Whitton signature.asc Description: PGP signature
Re: length of Debian copyright files
Quoting Wouter Verhelst (2020-04-11 16:47:13) > On Sat, Apr 11, 2020 at 11:29:22AM +0200, Jonas Smedegaard wrote: > > Quoting Wouter Verhelst (2020-04-11 10:36:44) > > > On Wed, Mar 25, 2020 at 03:43:17PM +, Simon McVittie wrote: > > > > Debian: > > > > https://tracker.debian.org/media/packages/g/gtk%2B4.0/copyright-3.98.0-1 > > > > plus we ship the LGPL in base-files' common-licenses. > > > > > > This kind of insanity is actually why I refuse to use the > > > machine-parseable copyright format. > > > > > > Nobody cares that some file somewhere deep down in the source tree > > > is perhams maybe somewhat more permissive than the license on the > > > whole. If the license on the whole is a copyleft license, then > > > that file somewhere deep down is made available to you as that > > > copyleft license, due to "copyleft". > > > > > > Anything else is insanity, and I refuse to waste my time on it. > > > > You seem to conflate two issues: > > > > a) writing debian/copyright in a machine-parsable format > > b) writing debian/copyright with too much detail included > > > > Please use the machine-readable format because then machines can > > help us. If you find it insane how detailed machine-readable format > > _can_ be, then please use the format _without_ the insanity. > > My point is that the machine-readable format is being "abused" to > deep-check the copyright status of all the files, and to reject > stuff/file bugs/... based on that. Abuse is seriously bad. Not sure what you mean by "abuse" in quotes, though, so let me try break it apart. Please tell me if I totally missed what you tried to say (I genuinely want to understand, not mock). Real bugs should be identified and reported, and using machine-readable data to aid in that is great. Or do you disagree with that? Filing bugreports for non-bugs is wrong, and doing it in automated ways (e.g. by use of machine-readable data) is abuse (unquoted) and should be stopped - regardless of who does it. If that's what you are talking about, then could you perhaps point at some examples that might help identify a pattern for countering such abuse? Since it keeps coming up that ftpmasters rejects for wrong reasons: Assuming good faith, I can only imagine it be _rumors_ only, stemming from a) clumsy behaviours in past dark ages and/or b) misinterpretation of rejection messages. Therefore: Please if anyone can shed more light on such rumors(!) please do - e.g. share recent(!) rejection emails showing it is fact, not rumor. > Yes, a machine-readable copyright format is useful for our users. It > is, however, not useful if it is being used to inspect packages and > kick maintainers for not doing useless busywork. It is my belief that > this is actually happening, and therefore I don't want to do the > machine-readable copyright format. > > People who care enough about the license of a piece of software that > they *do* need to know *all* these details can do the damn busywork > themselves; I will not. My point is that writing copyright file (as short as possible, and) machine-readable is *not* busywork. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: length of Debian copyright files
On Sat, Apr 11, 2020 at 11:29:22AM +0200, Jonas Smedegaard wrote: > Quoting Wouter Verhelst (2020-04-11 10:36:44) > > On Wed, Mar 25, 2020 at 03:43:17PM +, Simon McVittie wrote: > > > Debian: > > > https://tracker.debian.org/media/packages/g/gtk%2B4.0/copyright-3.98.0-1 > > > plus we ship the LGPL in base-files' common-licenses. > > > > This kind of insanity is actually why I refuse to use the > > machine-parseable copyright format. > > > > Nobody cares that some file somewhere deep down in the source tree is > > perhams maybe somewhat more permissive than the license on the whole. If > > the license on the whole is a copyleft license, then that file somewhere > > deep down is made available to you as that copyleft license, due to > > "copyleft". > > > > Anything else is insanity, and I refuse to waste my time on it. > > You seem to conflate two issues: > > a) writing debian/copyright in a machine-parsable format > b) writing debian/copyright with too much detail included > > Please use the machine-readable format because then machines can help > us. If you find it insane how detailed machine-readable format _can_ be, > then please use the format _without_ the insanity. My point is that the machine-readable format is being "abused" to deep-check the copyright status of all the files, and to reject stuff/file bugs/... based on that. Yes, a machine-readable copyright format is useful for our users. It is, however, not useful if it is being used to inspect packages and kick maintainers for not doing useless busywork. It is my belief that this is actually happening, and therefore I don't want to do the machine-readable copyright format. People who care enough about the license of a piece of software that they *do* need to know *all* these details can do the damn busywork themselves; I will not. -- To the thief who stole my anti-depressants: I hope you're happy -- seen somewhere on the Internet on a photo of a billboard
Re: length of Debian copyright files
Quoting Simon McVittie (2020-04-11 13:49:53) > On Sat, 11 Apr 2020 at 11:29:22 +0200, Jonas Smedegaard wrote: > > You seem to conflate two issues: > > > > a) writing debian/copyright in a machine-parsable format > > b) writing debian/copyright with too much detail included > > > > Please use the machine-readable format because then machines can > > help us. If you find it insane how detailed machine-readable format > > _can_ be, then please use the format _without_ the insanity. > > I agree with this part: the machine-readable format should just be an > alternative encoding for whatever you would say (with whatever high or > low level of detail you are using) in a plain-text copyright file. > > However: > > > Files: * > > Copyright: The GTK Team and others > > License: LGPL-2+ and LGPL-2.1+ > > Comment: > > Specific authors omitted (unneeded for this license, and list is > > long). > > My understanding is that the ftp team would consider this to be a bug, > and possibly a RC one, because: > > - the permissive licenses have been omitted (it should say > "LGPL-2+ and LGPL-2.1+ and Expat and (Expat or unlicense) and ..."); > > - not all of the copyright notices that exist in the source code have > been copied into the copyright file > > I would be delighted to be told I'm wrong about that by someone who > speaks for the ftp team, but I'm reluctant to get software that I want > in Debian kicked out of Debian by using its acceptance or rejection as > an oracle to discover the ftp team's policy. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956286 was opened at > RC severity two days ago, saying that folks' copyright file is > RC-buggy precisely because it does not replicate a list of copyright > statements from the source code. So you expect RC bugreports from ftp-masters, and fear NEW rejection. Me too. But those are different actions. I do not _fear_ RC bugs from ftp-masters: Those are transparent and open for interpretation. What I fear from ftp-masters is lack of transparency and lack of dialogue and (no doubt unintended only perceived therefore quoted) "punishment" by further delays of yet another NEW processing. This is my understanding of current ftp-master procedures (from earlier in this same thread, as a reply to you): Quoting Sean Whitton (2020-03-25 20:20:59) > 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. [...] > I do not believe that you would get a REJECT where the combination > involves a single license in the License: field. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: length of Debian copyright files
On Sat, 11 Apr 2020 at 11:29:22 +0200, Jonas Smedegaard wrote: > You seem to conflate two issues: > > a) writing debian/copyright in a machine-parsable format > b) writing debian/copyright with too much detail included > > Please use the machine-readable format because then machines can help > us. If you find it insane how detailed machine-readable format _can_ be, > then please use the format _without_ the insanity. I agree with this part: the machine-readable format should just be an alternative encoding for whatever you would say (with whatever high or low level of detail you are using) in a plain-text copyright file. However: > Files: * > Copyright: The GTK Team and others > License: LGPL-2+ and LGPL-2.1+ > Comment: > Specific authors omitted (unneeded for this license, and list is long). My understanding is that the ftp team would consider this to be a bug, and possibly a RC one, because: - the permissive licenses have been omitted (it should say "LGPL-2+ and LGPL-2.1+ and Expat and (Expat or unlicense) and ..."); - not all of the copyright notices that exist in the source code have been copied into the copyright file I would be delighted to be told I'm wrong about that by someone who speaks for the ftp team, but I'm reluctant to get software that I want in Debian kicked out of Debian by using its acceptance or rejection as an oracle to discover the ftp team's policy. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=956286 was opened at RC severity two days ago, saying that folks' copyright file is RC-buggy precisely because it does not replicate a list of copyright statements from the source code. smcv
Re: length of Debian copyright files
Quoting Wouter Verhelst (2020-04-11 10:36:44) > On Wed, Mar 25, 2020 at 03:43:17PM +, Simon McVittie wrote: > > Debian: > > https://tracker.debian.org/media/packages/g/gtk%2B4.0/copyright-3.98.0-1 > > plus we ship the LGPL in base-files' common-licenses. > > This kind of insanity is actually why I refuse to use the > machine-parseable copyright format. > > Nobody cares that some file somewhere deep down in the source tree is > perhams maybe somewhat more permissive than the license on the whole. If > the license on the whole is a copyleft license, then that file somewhere > deep down is made available to you as that copyleft license, due to > "copyleft". > > Anything else is insanity, and I refuse to waste my time on it. You seem to conflate two issues: a) writing debian/copyright in a machine-parsable format b) writing debian/copyright with too much detail included Please use the machine-readable format because then machines can help us. If you find it insane how detailed machine-readable format _can_ be, then please use the format _without_ the insanity. You can have a) without b) - e.g. like this: Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ Upstream-Name: GTK Source: https://download.gnome.org/sources/gtk/ License: LGPL-2.1+ Files: * Copyright: The GTK Team and others License: LGPL-2+ and LGPL-2.1+ Comment: Specific authors omitted (unneeded for this license, and list is long). If ftp-masters then file bugreports about missing or too vague entries, you lower that to lower severity (if you are confident that it really is) and take it to the tech-CTTE if that causes a dispute. If ftp-masters then reject the package with missing or too vague entries being their reason, you bring that up here on -devel, because that's a different praxis than they currently give the impression that they are follow (nowadays - how they did in the past is irrelevant here). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: length of Debian copyright files
On Wed, Mar 25, 2020 at 03:43:17PM +, Simon McVittie wrote: > Debian: > https://tracker.debian.org/media/packages/g/gtk%2B4.0/copyright-3.98.0-1 > plus we ship the LGPL in base-files' common-licenses. This kind of insanity is actually why I refuse to use the machine-parseable copyright format. Nobody cares that some file somewhere deep down in the source tree is perhams maybe somewhat more permissive than the license on the whole. If the license on the whole is a copyleft license, then that file somewhere deep down is made available to you as that copyleft license, due to "copyleft". Anything else is insanity, and I refuse to waste my time on it. -- Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22
Re: length of Debian copyright files
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 +, 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/msg4.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 signature.asc Description: PGP signature
Re: length of Debian copyright files
Quoting Keith Packard (2020-03-25 19:07:33) > Simon McVittie writes: > > > 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. > > As an example, I've got a package in the new queue with a 5077 line > copyright file, with 75 'unique' licenses (BSD licensed software picks > up a lot of variation over thirty years). Wauw, that sounds like a great challenge for licensecheck. Looking at https://ftp-master.debian.org/new.html it seems to be picolibc. Thanks for that! If anyone else have good examples of complex source packages, please do let me know. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: length of Debian copyright files
Simon McVittie writes: > 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. As an example, I've got a package in the new queue with a 5077 line copyright file, with 75 'unique' licenses (BSD licensed software picks up a lot of variation over thirty years). -- -keith signature.asc Description: PGP signature
Re: length of Debian copyright files
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 +, 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/msg4.html #904729 is a related Policy bug that would benefit from ftp team input. > > 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. smcv
Re: length of Debian copyright files
Hello, On Wed 25 Mar 2020 at 08:58PM +05, Andrey Rahmatullin wrote: > On Wed, Mar 25, 2020 at 03:43:17PM +, Simon McVittie wrote: >> I think part of the problem might be this vicious cycle: the NEW queue >> is an asynchronous gatekeeper/progress blocker, which gives maintainers >> a strong incentive to get things accepted first time (because a NEW >> rejection will double the delay), which means maintainers are incentivized >> to dot every i and cross every t in the copyright file even if it isn't >> strictly necessary, which means the ftp team are given larger and more >> verbose copyright files to read, which presumably means the NEW queue >> takes longer than it otherwise could. > Do you mean it's not essential to track and list all licenses and > copyrights? 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. Policy currently requires you to include all copyright claims and all licenses (§§ 2.3, 4.5, 12.5). If a d/copyright doesn't include all copyright claims but it's not a license violation -- some licenses require they all be included in binary distributions but some don't -- the FTP team typically ACCEPT but file an RC bug citing Policy. -- Sean Whitton signature.asc Description: PGP signature
Re: length of Debian copyright files
On Wed, Mar 25, 2020 at 03:43:17PM +, Simon McVittie wrote: > I think part of the problem might be this vicious cycle: the NEW queue > is an asynchronous gatekeeper/progress blocker, which gives maintainers > a strong incentive to get things accepted first time (because a NEW > rejection will double the delay), which means maintainers are incentivized > to dot every i and cross every t in the copyright file even if it isn't > strictly necessary, which means the ftp team are given larger and more > verbose copyright files to read, which presumably means the NEW queue > takes longer than it otherwise could. Do you mean it's not essential to track and list all licenses and copyrights? 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?). -- WBR, wRAR signature.asc Description: PGP signature
Re: length of Debian copyright files
Hello, On Wed 25 Mar 2020 at 03:43PM +00, Simon McVittie wrote: > I think part of the problem might be this vicious cycle: the NEW queue > is an asynchronous gatekeeper/progress blocker, which gives maintainers > a strong incentive to get things accepted first time (because a NEW > rejection will double the delay), which means maintainers are incentivized > to dot every i and cross every t in the copyright file even if it isn't > strictly necessary, which means the ftp team are given larger and more > verbose copyright files to read, which presumably means the NEW queue > takes longer than it otherwise could. Yes, I think this is exactly what happens. -- Sean Whitton signature.asc Description: PGP signature
Re: length of Debian copyright files
On Wed, 25 Mar 2020 at 15:32:20 +0100, Tomas Pospisek wrote: > On 25.03.20 15:19, Andrey Rahmatullin wrote: > > Or you can look at the Redhat approach as a minimal working one. > > You know it can be done much easier and still work: in Redhat. > > (in case it hasn't already been discussed in this thread, but don't > bother rehashing...): What are they doing differently? Here is a concrete example of a medium-to-large package with a relatively typical licensing situation (LGPL plus some more-permissive bits): GTK 4, for which I redid the copyright file somewhat recently in preparation for getting it through NEW. Debian: https://tracker.debian.org/media/packages/g/gtk%2B4.0/copyright-3.98.0-1 plus we ship the LGPL in base-files' common-licenses. Fedora: one line in gtk4.spec "License: LGPLv2+", plus they ship these files in their binary package: https://gitlab.gnome.org/GNOME/gtk/-/blob/master/AUTHORS https://gitlab.gnome.org/GNOME/gtk/-/blob/master/COPYING (it's the LGPL) I'm pretty sure the long list of maybe-copyright-holders in the Debian package is still incomplete; merge requests welcome. I'm also fairly sure we are the only distribution that does this (not counting our derivatives like Ubuntu), even though some of the others have lawyers. If people have recommendations for how to make gtk+4.0's copyright file more minimal, I'd be happy to review merge requests or otherwise receive suggestions. I think part of the problem might be this vicious cycle: the NEW queue is an asynchronous gatekeeper/progress blocker, which gives maintainers a strong incentive to get things accepted first time (because a NEW rejection will double the delay), which means maintainers are incentivized to dot every i and cross every t in the copyright file even if it isn't strictly necessary, which means the ftp team are given larger and more verbose copyright files to read, which presumably means the NEW queue takes longer than it otherwise could. smcv
