Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Thorsten Alteholz]

On Sat, 28 Dec 2019, Scott Kitterman wrote:

The same information could be included in the machine readable format as
comments.  It's not the format per se that helps, it's how the maintainer
organizes the information.


Yes, sure, but Sean mentioned the copyright file of dgit as a good example 
for a freeform copyright file and I objected.
From my experience Comments: are rather seldom used in File:-blocks and 

are much shorter.


Also, personally, I find understanding what debian/copyright says is a trivial
effort compared to understanding what copyright/licenses actually apply to the
package.


This is true for large packages, but nowadays most packages are simple 
go-, rust-, ruby-, node-, or whatever-fancy-language-packages where you 
just need that trivial effort and I would prefer to have this done as 
fast as possible.


  Thorsten

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Thorsten Alteholz]

Hi Sean,

On Sat, 28 Dec 2019, Sean Whitton wrote:

For packages with simple copyright and licensing, machine readable
copyright files can take longer to write than a freeform copyright file.


this discussion started with possible stuff to reduce the time for NEW 
reviews.
If I look at dgit, why do I need to read sentences like "This is a dummy 
package containing only Debian metadata" in the copyright file? I 
also don't have to be told that GPL is comaptible with GPLv3.
During the time I need to read such freeform prose to understand the 
copyright situation, I could check several machine-readable files where I 
can capture all important information at first view.


  Thorsten

Re: possibly exhausted ftp-masters (Re: Do we still value contributions?

[Thorsten Alteholz]

On Thu, 26 Dec 2019, Roberto C. Sánchez wrote:

   So, what does the FTP team consider that we, as the wider community
   of Debian Developers, can do to help?


What about being more careful when creating the debian/copyright for a 
package?

I know it is boring, but writing a REJECT-mail is not much fun as well.
Seeing a copy error once is ok, but seeing that in a bunch of 
packages, makes me wonder.

Don't neglect fonts, pictures, sound files.

When there is a REJECT and the maintainer used a tool like licensecheck, 
file a bug and let the tools become better.
(I tested some commercial tools a while ago and they were extremely bad in 
detecting correct licenses.)


Make the machine-readable copyright file mandatory.
It is much easier to "parse" than just a bunch of copyright information.

  Thorsten