Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.project > #11253 > unrolled thread

Do we still value contributions?

Back to article view | Back to linux.debian.project

Contents

  Do we still value contributions? John Goerzen <jgoerzen@complete.org> - 2019-12-24 17:00 +0100
    Re: Do we still value contributions? Scott Kitterman <debian@kitterman.com> - 2019-12-24 17:20 +0100
      Re: Do we still value contributions? John Goerzen <jgoerzen@complete.org> - 2019-12-24 19:20 +0100
      Re: Do we still value contributions? Charles Plessy <plessy@debian.org> - 2019-12-25 21:20 +0100
        Re: Do we still value contributions? John Goerzen <jgoerzen@complete.org> - 2019-12-26 05:00 +0100
        Re: Do we still value contributions? Xavier <yadd@debian.org> - 2019-12-26 08:00 +0100
    Re: Do we still value contributions? Pierre-Elliott Bécue <peb@debian.org> - 2019-12-24 19:00 +0100
      Re: Do we still value contributions? John Goerzen <jgoerzen@complete.org> - 2019-12-24 19:10 +0100
        Re: Do we still value contributions? Jonathan Carter <jcc@debian.org> - 2019-12-25 23:00 +0100
          Re: Do we still value contributions? John Goerzen <jgoerzen@complete.org> - 2019-12-26 04:50 +0100
            Re: Do we still value contributions? Bernd Zeimetz <bernd@bzed.de> - 2019-12-26 15:00 +0100
              Re: Do we still value contributions? Mo Zhou <lumin@debian.org> - 2019-12-26 16:40 +0100
                Re: Do we still value contributions? Jonas Smedegaard <dr@jones.dk> - 2019-12-26 17:10 +0100
                  Re: Do we still value contributions? Ryan Kavanagh <rak@debian.org> - 2019-12-26 17:20 +0100
                    Re: Do we still value contributions? Jonas Smedegaard <dr@jones.dk> - 2019-12-26 17:40 +0100
                      Re: Do we still value contributions? Pirate Praveen <praveen@onenetbeyond.org> - 2019-12-26 18:00 +0100
              Re: Do we still value contributions? Charles Plessy <plessy@debian.org> - 2019-12-26 17:30 +0100
              Re: Do we still value contributions? Steffen Möller <steffen_moeller@gmx.de> - 2019-12-27 02:00 +0100
                Re: Do we still value contributions? Jonas Smedegaard <dr@jones.dk> - 2019-12-27 12:40 +0100
                  Re: Do we still value contributions? Charles Plessy <plessy@debian.org> - 2020-01-04 04:10 +0100
          possibly exhausted ftp-masters (Re: Do we still value contributions? Mo Zhou <lumin@debian.org> - 2019-12-26 05:20 +0100
            Re: possibly exhausted ftp-masters (Re: Do we still value  contributions? Roberto C. Sánchez <roberto@debian.org> - 2019-12-26 15:10 +0100
              Re: possibly exhausted ftp-masters (Re: Do we still value  contributions? Thorsten Alteholz <debian@alteholz.de> - 2019-12-26 17:20 +0100
                Re: possibly exhausted ftp-masters (Re: Do we still value  contributions? Roberto C. Sánchez <roberto@debian.org> - 2019-12-26 17:40 +0100
                  Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Jonas Smedegaard <dr@jones.dk> - 2019-12-26 18:10 +0100
                    Re: possibly exhausted ftp-masters (Re: Do we still value  contributions? Roberto C. Sánchez <roberto@debian.org> - 2019-12-26 18:10 +0100
                  Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Sean Whitton <spwhitton@spwhitton.name> - 2019-12-28 11:10 +0100
                    Re: possibly exhausted ftp-masters (Re: Do we still value  contributions? Michael Banck <mbanck@debian.org> - 2019-12-28 11:50 +0100
                      Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Sean Whitton <spwhitton@spwhitton.name> - 2019-12-28 15:40 +0100
                Re: possibly exhausted ftp-masters (Re: Do we still value  contributions? Holger Levsen <holger@layer-acht.org> - 2019-12-26 17:40 +0100
                  Re: possibly exhausted ftp-masters (Re: Do we still value  contributions? Andrey Rahmatullin <wrar@debian.org> - 2019-12-26 20:00 +0100
                    Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Scott Kitterman <debian@kitterman.com> - 2019-12-26 20:10 +0100
                      Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Sean Whitton <spwhitton@spwhitton.name> - 2019-12-28 11:00 +0100
                        Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Jonas Smedegaard <dr@jones.dk> - 2019-12-28 11:40 +0100
                          Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Sean Whitton <spwhitton@spwhitton.name> - 2019-12-28 15:50 +0100
                            Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Scott Kitterman <debian@kitterman.com> - 2019-12-28 16:10 +0100
                              Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Ole Streicher <olebole@debian.org> - 2019-12-28 21:10 +0100
                            Re: possibly exhausted ftp-masters (Re: Do we still value  contributions? Thorsten Alteholz <debian@alteholz.de> - 2019-12-28 16:20 +0100
                              Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Scott Kitterman <debian@kitterman.com> - 2019-12-28 16:50 +0100
                                Re: possibly exhausted ftp-masters (Re: Do we still value contributions? "Paul R. Tagliamonte" <paultag@gmail.com> - 2019-12-28 17:10 +0100
                                Re: possibly exhausted ftp-masters (Re: Do we still value  contributions? Thorsten Alteholz <debian@alteholz.de> - 2019-12-28 17:30 +0100
                                Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Sean Whitton <spwhitton@spwhitton.name> - 2019-12-29 16:00 +0100
                                  Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Scott Kitterman <debian@kitterman.com> - 2019-12-29 16:10 +0100
                                    Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Sean Whitton <spwhitton@spwhitton.name> - 2019-12-31 23:00 +0100
                              Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Sean Whitton <spwhitton@spwhitton.name> - 2019-12-29 16:00 +0100
                                Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Jonas Smedegaard <dr@jones.dk> - 2019-12-29 17:50 +0100
                                Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Russ Allbery <rra@debian.org> - 2019-12-29 19:20 +0100
                    Re: possibly exhausted ftp-masters (Re: Do we still value  contributions? Holger Levsen <holger@layer-acht.org> - 2019-12-26 20:30 +0100
                Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Sean Whitton <spwhitton@spwhitton.name> - 2019-12-28 11:10 +0100
                  Re: possibly exhausted ftp-masters (Re: Do we still value  contributions? Roberto C. Sánchez <roberto@debian.org> - 2019-12-28 14:30 +0100
                    Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Sean Whitton <spwhitton@spwhitton.name> - 2019-12-28 15:40 +0100
                      Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Jonas Smedegaard <dr@jones.dk> - 2019-12-28 17:40 +0100
                        Re: possibly exhausted ftp-masters (Re: Do we still value  contributions? Clint Adams <clint@debian.org> - 2019-12-28 21:30 +0100
                          Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Jonas Smedegaard <dr@jones.dk> - 2019-12-28 23:00 +0100
                            Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Russ Allbery <rra@debian.org> - 2019-12-28 23:20 +0100
                              Re: possibly exhausted ftp-masters (Re: Do we still value  contributions? Mo Zhou <lumin@debian.org> - 2019-12-29 03:30 +0100
                                Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Russ Allbery <rra@debian.org> - 2019-12-29 04:00 +0100
                      Re: possibly exhausted ftp-masters (Re: Do we still value  contributions? Enrico Zini <enrico@enricozini.org> - 2019-12-29 09:20 +0100
                        Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Judit Foglszinger <fgrfgr@freenet.de> - 2019-12-29 10:30 +0100
                          Re: possibly exhausted ftp-masters (Re: Do we still value  contributions? Enrico Zini <enrico@enricozini.org> - 2019-12-29 16:00 +0100
                        Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Sean Whitton <spwhitton@spwhitton.name> - 2019-12-29 16:10 +0100
            Re: possibly exhausted ftp-masters (Re: Do we still value  contributions? Roberto C. Sánchez <roberto@debian.org> - 2019-12-26 15:10 +0100
            Re: possibly exhausted ftp-masters (Re: Do we still value contributions? Sean Whitton <spwhitton@spwhitton.name> - 2019-12-28 11:00 +0100
              Re: possibly exhausted ftp-masters (Re: Do we still value  contributions? Mo Zhou <lumin@debian.org> - 2019-12-28 12:10 +0100

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

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

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

[toc] | [prev] | [next] | [standalone]

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

Hello,

On Sat 28 Dec 2019 at 10:46am -05, 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.
>
> Also, personally, I find understanding what debian/copyright says is a trivial
> effort compared to understanding what copyright/licenses actually apply to the
> package.

I agree with your general points, here, but for very complicated
packages with a lot of different licenses, the machine-readable format
can be easier to work with.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Sunday, December 29, 2019 9:56:00 AM EST Sean Whitton wrote:
> Hello,
> 
> On Sat 28 Dec 2019 at 10:46am -05, 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.
> > 
> > Also, personally, I find understanding what debian/copyright says is a
> > trivial effort compared to understanding what copyright/licenses actually
> > apply to the package.
> 
> I agree with your general points, here, but for very complicated
> packages with a lot of different licenses, the machine-readable format
> can be easier to work with.

I agree with that, but I don't think the advantage is sufficient that we should 
burden contributors with making it a requirement.

Scott K

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Sun 29 Dec 2019 at 10:09am -05, Scott Kitterman wrote:

> On Sunday, December 29, 2019 9:56:00 AM EST Sean Whitton wrote:
>> Hello,
>>
>> On Sat 28 Dec 2019 at 10:46am -05, 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.
>> >
>> > Also, personally, I find understanding what debian/copyright says is a
>> > trivial effort compared to understanding what copyright/licenses actually
>> > apply to the package.
>>
>> I agree with your general points, here, but for very complicated
>> packages with a lot of different licenses, the machine-readable format
>> can be easier to work with.
>
> I agree with that, but I don't think the advantage is sufficient that we should
> burden contributors with making it a requirement.

I agree with this too.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

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

Hello Thorsten,

On Sat 28 Dec 2019 at 04:14pm +01, Thorsten Alteholz wrote:

> 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.

The main reason I referred to dgit's copyright file in this discussion
was because I think the "Contributions are accepted upstream ..."
section is useful to include in d/copyright rather than somewhere else
in the source package, as then all licensing and copyright information
is in one place.  I don't think its inclusion there would noticeably
slow down NEW review.

I agree with you that there is some superfluous information in the
other parts of the file.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

Quoting Sean Whitton (2019-12-29 15:52:57)
> On Sat 28 Dec 2019 at 04:14pm +01, Thorsten Alteholz wrote:
> > 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.
> 
> The main reason I referred to dgit's copyright file in this discussion
> was because I think the "Contributions are accepted upstream ..."
> section is useful to include in d/copyright rather than somewhere else
> in the source package, as then all licensing and copyright information
> is in one place.  I don't think its inclusion there would noticeably
> slow down NEW review.

I agree that it is sensible to include contribution notice in copyright 
file.

I don't follow, however, what makes such notice longer to write (or 
lesser readable, or whichever other reason) in machine-readable format - 
e.g. in a Comment field for the top section.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

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

Sean Whitton <spwhitton@spwhitton.name> writes:

> The main reason I referred to dgit's copyright file in this discussion
> was because I think the "Contributions are accepted upstream ..."
> section is useful to include in d/copyright rather than somewhere else
> in the source package, as then all licensing and copyright information
> is in one place.  I don't think its inclusion there would noticeably
> slow down NEW review.

I'm going to disagree here (although I don't feel strongly about it): I
don't think this belongs in the debian/copyright file.  I think of the
copyright file as a repository for the licensing information and mandatory
notices for the package as delivered as a Debian package, and this isn't
any of those things, so it makes the file longer and is more for anyone
reviewing licensing to read through, while (I think) not being relevant to
the license of the code or binaries.

This sort of upstream contribution policy in my mind should be put as
close as possible to the place where someone is submitting code upstream.
If the project is based on pull requests, for instance, it should ideally
be prominant in the interface where one submits a pull request.  For a
package where most contributions are expected to come through the BTS, I
would instead put the "Contributions are accepted upstream..." paragraph
in README.Debian and the certificate of origin in a separate file in
/usr/share/doc, since I think that would increase the chances that someone
who was preparing a patch would read it. (I personally would never look at
debian/copyright when submitting a patch to the BTS, but would probably
read README.Debian.)

This is just one anecdotal opinion, though, so please take with a grain of
salt.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Thu, Dec 26, 2019 at 11:21:08PM +0500, Andrey Rahmatullin wrote:
> On Thu, Dec 26, 2019 at 04:29:57PM +0000, Holger Levsen wrote:
> > > Make the machine-readable copyright file mandatory.
> > > It is much easier to "parse" than just a bunch of copyright information.
> > hear hear. (as in: what's blocking us from doing this?)
> I'm sure some people will orphan or RM their packages instead of writing
> machine-readable debian/copyright. I suspect it will be worse than
> mandating source format 3.0.

that can be worked around easily be only requesting this for NEW
packages...


-- 
cheers,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

Hello Thorsten,

On Thu 26 Dec 2019 at 04:30pm +01, Thorsten Alteholz wrote:

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

The other side of this is that using that format tends to encourage
documenting a bunch of information about the source package which we
don't need to document, but which the ftp team member processing NEW is
still going to have to verify as correct.

So I'd like to append to your point: do take advantage of the
machine-readable copyright format for complex source packages, but don't
add more "Files:" stanzas than are strictly necessary.

For example,

    Files: *
    Copyright: (c) 1994 A. Developer
    License: GPL-2+

    Files: foo.js baz/bar.js
    Copyright: (c) 1995 Google
    License: GPL-2+

could be combined into

    Files: *
    Copyright: (c) 1994 A. Developer
     (c) 1995 Google
    License: GPL-2+

i.e. you generally only need separate stanzas when the license is
different, not simply because there are different coyright holders.  In
most cases you should should not need more stanzas than there are
different licenses.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

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

On Sat, Dec 28, 2019 at 09:47:20AM +0000, Sean Whitton wrote:
> Hello Thorsten,
> 
> On Thu 26 Dec 2019 at 04:30pm +01, Thorsten Alteholz wrote:
> 
> > Make the machine-readable copyright file mandatory.
> > It is much easier to "parse" than just a bunch of copyright information.
> 
> The other side of this is that using that format tends to encourage
> documenting a bunch of information about the source package which we
> don't need to document, but which the ftp team member processing NEW is
> still going to have to verify as correct.
> 
> So I'd like to append to your point: do take advantage of the
> machine-readable copyright format for complex source packages, but don't
> add more "Files:" stanzas than are strictly necessary.
> 
> For example,
> 
>     Files: *
>     Copyright: (c) 1994 A. Developer
>     License: GPL-2+
> 
>     Files: foo.js baz/bar.js
>     Copyright: (c) 1995 Google
>     License: GPL-2+
> 
> could be combined into
> 
>     Files: *
>     Copyright: (c) 1994 A. Developer
>      (c) 1995 Google
>     License: GPL-2+
> 
> i.e. you generally only need separate stanzas when the license is
> different, not simply because there are different coyright holders.  In
> most cases you should should not need more stanzas than there are
> different licenses.
> 
Oh, wow.  I've been doing this wrong all along.  I am not sure how I
developed the impression that it was necessary to distinguish different
copyright holders (even same copyright holders with different copyright
years), but your approach is most certainly simpler and more compact.

How about licenses with slight variations?  I'm thinking BSD-like and
MIT-like licenses which mention the copyright holder usually as the
first thing in the in license text.  Could those be combined into a
single stanza in the way you describe?

Also, I assume that it is good practice to verify actual license texts
included by upstream against known good sources since that seems like
something FTP masters would have to do as well.  Is that correct?

Regards,

-Roberto
-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

Hello,

On Sat 28 Dec 2019 at 08:21am -05, Roberto C. Sánchez wrote:

> Oh, wow.  I've been doing this wrong all along.  I am not sure how I
> developed the impression that it was necessary to distinguish different
> copyright holders (even same copyright holders with different copyright
> years), but your approach is most certainly simpler and more compact.

Right.  This is the sort of overdocumentation that I worry our
machine-readable copyright format implicitly encourages us to do.

> How about licenses with slight variations?  I'm thinking BSD-like and
> MIT-like licenses which mention the copyright holder usually as the
> first thing in the in license text.  Could those be combined into a
> single stanza in the way you describe?

IANAL, but my understanding is that the statement of copyright does not
actually form part of the license text, so you can consolidate, indeed.

> Also, I assume that it is good practice to verify actual license texts
> included by upstream against known good sources since that seems like
> something FTP masters would have to do as well.  Is that correct?

You should check for variant licenses, though with GNU licenses it is
unlikely to come up because those licenses do not permit derivative
works.

-- 
Sean Whitton

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

Quoting Sean Whitton (2019-12-28 15:35:50)
> On Sat 28 Dec 2019 at 08:21am -05, Roberto C. Sánchez wrote:
> 
> > Oh, wow.  I've been doing this wrong all along.  I am not sure how I 
> > developed the impression that it was necessary to distinguish 
> > different copyright holders (even same copyright holders with 
> > different copyright years), but your approach is most certainly 
> > simpler and more compact.
> 
> Right.  This is the sort of overdocumentation that I worry our 
> machine-readable copyright format implicitly encourages us to do.

I worry that *not* using machine-readable copyright format implicitly 
encourages us to document only _project-wide_ licensing - e.g. what some 
upstreams write in a top-level LICENSE or COPYRIGHT file or in some 
metadata file - without checking licensing of each and every _file_ 
which we *must* do (machine-readable or not).

ftp-masters check all files, which I guess is slower when only they do 
so.

...which is the topic of this discussion!

Both you and I worry about subjective implicit encouragements, however - 
not about the actual demands of machine-readable format.

The definition of machine-readable format includes this:

> Nothing in this proposal supersedes or modifies any of the 
> requirements specified in Debian Policy regarding the appropriate 
> detail or granularity to use when documenting copyright and lice> nse 
> status in debian/copyright.

In other words, debian/copyright need *same* amount of detail, 
regardless of the file being machine-readable or not!

machine-readable format does *not* require more detail.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

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

On Sat, Dec 28, 2019 at 05:32:02PM +0100, Jonas Smedegaard wrote:
> metadata file - without checking licensing of each and every _file_ 
> which we *must* do (machine-readable or not).

Why do you believe this to be true?

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

Quoting Clint Adams (2019-12-28 21:20:03)
> On Sat, Dec 28, 2019 at 05:32:02PM +0100, Jonas Smedegaard wrote:
> > metadata file - without checking licensing of each and every _file_ 
> > which we *must* do (machine-readable or not).
> 
> Why do you believe this to be true?

Beware that I say we must _check_ every file - not that we must _list_ 
every file in debian/copyright.

All that Debian distributes must be legal to distribute.

You may argue that you need not check e.g. if PNG files in your package 
contain embedded non-free ICC profiles, but that just means that you 
rely on ftpmasters to check it on your behalf.

You may argue that your upstream has already checked that for you.  I'd 
call that a sloppy check, and there is a real risk that again you then 
burden ftpmasters with digging out dirt because upstream has a different 
view than Debian what is legally acceptable.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

[toc] | [prev] | [next] | [standalone]

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

Jonas Smedegaard <dr@jones.dk> writes:

> Beware that I say we must _check_ every file - not that we must _list_
> every file in debian/copyright.

> All that Debian distributes must be legal to distribute.

> You may argue that you need not check e.g. if PNG files in your package 
> contain embedded non-free ICC profiles, but that just means that you 
> rely on ftpmasters to check it on your behalf.

> You may argue that your upstream has already checked that for you.  I'd 
> call that a sloppy check, and there is a real risk that again you then 
> burden ftpmasters with digging out dirt because upstream has a different 
> view than Debian what is legally acceptable.

Requiring ftpmasters to do this check is a choice that Debian has made.
Maybe it's the right choice, but other choices exist, and other entities
make different choices.

For example, we could chose to trust upstream license assertions and fix
them later if upstream turns out to be wrong.  Or we could chose to adopt
a specific tool for automated license checks and base the accept decision
on the output of that tool plus upstream assertions in the knowledge that
this could be incorrect, and later fix problems that are drawn to our
attention.  (Note that thorough license review has not completely
eliminated license problems that we have had to fix later, although it
certainly reduces the number of them.  We will be fixing some issues
retroactively under any approach.)

In the context of limited project resources, it seems worth asking not the
absolute question of whether thorough license checks have desirable
properties (obviously they do), but instead whether this is the most
effective use to which the project could be putting this energy, or if we
should consider alternatives so that we can redirect some of that energy
to other things the project considers important.

Another way of asking that question is to ask whether this sort of
thorough license double-checking is something we consider a core mission
of the project, or something that we're doing for secondary reasons (such
as reducing the risk of legal liability).  If it's a core mission of the
project, then maybe we do want to reaffirm our decision to spend
significant resources on it.  If we're only doing this for secondary
reasons like legal liability, it might be worth looking around and seeing
if other organizations with similar legal risks take the same precautions,
or asking for legal advice on whether this precaution is legally necessary
or if we're creating work for ourselves that exceeds the legal risk we'd
be accepting by doing something more automatable.

To be clear, it may be that we'll ask this question and decide that yes,
detailed license review is something we consider important and we want to
keep doing it the way that we have been doing it, and we need to figure
out how to make that work scale.  But I do think it's worth occasionally
explicitly asking the question and then making an intentional choice,
rather than assuming we're obligated to continue doing what we're doing.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

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

On Sat, Dec 28, 2019 at 02:13:55PM -0800, Russ Allbery wrote:
> If we're only doing this for secondary
> reasons like legal liability, it might be worth looking around and seeing
> if other organizations with similar legal risks take the same precautions,
> or asking for legal advice on whether this precaution is legally necessary
> or if we're creating work for ourselves that exceeds the legal risk we'd
> be accepting by doing something more automatable.

Don't know what Red Hat family does, but at least Archlinux and Gentoo
treat the license checking problem in a very permissive way.
However, Debian is sometimes an important reference to these friend
distros when they encountered some problems about license.
 
> To be clear, it may be that we'll ask this question and decide that yes,
> detailed license review is something we consider important and we want to
> keep doing it the way that we have been doing it, and we need to figure
> out how to make that work scale.

Making that process scalable seemed like a workflow change, which often
takes centuries to enforce in this community. Even if that process can
be scaled to a larger group of workers, without proper tool every worker
node will still work in low efficiency (and still easily get mentally
bored).

Assuming "license reviewing is inevitable to Debian", someone must
manually check the debian/copyright file.  In Chinese there is an old
saying "工欲善其事，必先利其器", which means "one who wants to get the
work done has to sharpen their tools first" (note, not a standard
translation).

So, trying to design a human-oriented tool for more efficient license
review should be worth consideration, at least. That's what my thread on
-devel is trying to do.

[toc] | [prev] | [next] | [standalone]

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

Mo Zhou <lumin@debian.org> writes:

> Don't know what Red Hat family does, but at least Archlinux and Gentoo
> treat the license checking problem in a very permissive way.  However,
> Debian is sometimes an important reference to these friend distros when
> they encountered some problems about license.

I do think we can maintain that property without hand-checking every file
in every source package we upload.  My sense (I could be wrong) is that
other distributions look at us more for our analysis of the license terms
than for our ability to dig out obscure issues from source trees.  And
even if it's finding obscure issues in the source tree, we still have a
lot of eyes and a community that cares about these things and it's always
possible for people to do volunteer reviews.

Another option that I forgot to mention is that we could continue to ask
the package maintainer to do a thorough license review and treat licensing
problems as bugs.  One way to think about the current ftpmaster review is
that we treat licensing bugs far more seriously than other bugs and thus
have mandatory code review for licensing issues but not for anything else
in Debian.  And again, that could be exactly what we want to do, but it's
worth calling it out as a deliberate choice.  We could decide to treat
licensing bugs as less special (with appropriate legal advice, of course).

> Making that process scalable seemed like a workflow change, which often
> takes centuries to enforce in this community. Even if that process can
> be scaled to a larger group of workers, without proper tool every worker
> node will still work in low efficiency (and still easily get mentally
> bored).

Well, in this case the workflow is already centralized, so I think it's
more tractable than that.  But yes, thank you for starting the discussion
of the tool.  I think such a tool is extremely valuable for maintainers
regardless, and will make any workflow that involves any central review
under any circumstances much easier.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Sat, Dec 28, 2019 at 02:35:50PM +0000, Sean Whitton wrote:

> On Sat 28 Dec 2019 at 08:21am -05, Roberto C. Sánchez wrote:
> 
> > Oh, wow.  I've been doing this wrong all along.  I am not sure how I
> > developed the impression that it was necessary to distinguish different
> > copyright holders (even same copyright holders with different copyright
> > years), but your approach is most certainly simpler and more compact.
> 
> Right.  This is the sort of overdocumentation that I worry our
> machine-readable copyright format implicitly encourages us to do.

I see similar things on nm.debian.org, which I ended up calling in my
head something like "the law of inflation of bureaucracy".

That is, I see that when people are asked to do some work, that later
will be checked by someone else, over time there is a tendency for the
perceived amount of work to inflate.

I guess the incentives are such that doing one bit less feels like
making it more likely that review will fail, and doing one bit more
feels like making it more likely that review will pass.

The result over time is an increase in the amount effort that both
people who are doing the work and people who are doing the checking end
up putting into the system.

For example, an Application Manager in the NM process will tend to err
for asking a question more, that DAM will have to read.

I haven't yet seen easy ways of introducing a feedback mechanism to
counter this: saying "you didn't need to do this" feels to me like
arbitrarily undervaluing someone's work, and maybe the person really
found it important to do it.

I would be very much interested in reasoning about this.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

> For example, an Application Manager in the NM process will tend to err
> for asking a question more, that DAM will have to read.
> 
> I haven't yet seen easy ways of introducing a feedback mechanism to
> counter this: saying "you didn't need to do this" feels to me like
> arbitrarily undervaluing someone's work, and maybe the person really
> found it important to do it.
> 
> I would be very much interested in reasoning about this. 

Maybe instead of saying "you shouldn't have done that",
rather explain which parts of questions asked in one specific process
one found sufficient to approve the NM as a DAM and why,
so there is some more orientation and more insight,
what exactly DAM finds important to ask.

On the other hand given that quite some people find their process
a valuable experience, it would be sad to reduce it to the bare minimum,
as long an AM takes the effort to ensure, that
the NM is not forced to do unnecessary things they rather wouldn't want to do.
(if some stuff is more clearly optional, it might also easier for DAM to skip it)

[toc] | [prev] | [next] | [standalone]

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

[Multipart message — attachments visible in raw view] — view raw

On Sun, Dec 29, 2019 at 03:15:07PM +0600, Judit Foglszinger wrote:

> Maybe instead of saying "you shouldn't have done that",
> rather explain which parts of questions asked in one specific process
> one found sufficient to approve the NM as a DAM and why,
> so there is some more orientation and more insight,
> what exactly DAM finds important to ask.
> 
> On the other hand given that quite some people find their process
> a valuable experience, it would be sad to reduce it to the bare minimum,
> as long an AM takes the effort to ensure, that
> the NM is not forced to do unnecessary things they rather wouldn't want to do.
> (if some stuff is more clearly optional, it might also easier for DAM to skip it)

Thanks! I like the angle of documenting what was found sufficient,
rather than what was not needed.

Probably the documentation shouldn't be public, to avoid applicants to
build an expectations of a bare minimum work required and then get angry
at the AM if the AM feels like asking more than that, but it could be,
for example, a monthly post to the am@ alias.


Enrico

-- 
GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini <enrico@enricozini.org>

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | linux.debian.project

csiph-web