[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

Attachment: signature.asc
Description: signature

Reply to: