Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon
Date: Thu, 07 Sep 2017 21:56:39
Message-Id: CAGfcS_ntDfFE8uzB3qKakPboD4sk2LXWrgNiVWCt_YepQeiA6A@mail.gmail.com
In Reply to: Re: [gentoo-dev] Last rites: games-rpg/nwn-shadowlordsdreamcatcherdemon by "Michał Górny"
1 On Thu, Sep 7, 2017 at 5:18 PM, Michał Górny <mgorny@g.o> wrote:
2 > W dniu czw, 07.09.2017 o godzinie 16∶42 -0400, użytkownik Rich Freeman
3 > napisał:
4 >> On Thu, Sep 7, 2017 at 4:36 PM, Michał Górny <mgorny@g.o> wrote:
5 >> > W dniu czw, 07.09.2017 o godzinie 06∶21 -0700, użytkownik Rich Freeman
6 >> > napisał:
7 >> > > On Thu, Sep 7, 2017 at 6:04 AM, Ulrich Mueller <ulm@g.o> wrote:
8 >> > > > > > > > > On Thu, 7 Sep 2017, Rich Freeman wrote:
9 >> > > >
10 >> > > > Don't you think there is a difference between downloading a package
11 >> > > > that has a known upstream and that is also carried by other distros,
12 >> > > > and downloading a license-less package from a random location on the
13 >> > > > internet?
14 >> > >
15 >> > > Most upstreams do not do much checking about the ownership of their sources.
16 >> > >
17 >> > > Gentoo certainly doesn't - we don't even require developers to submit a DCO.
18 >> > >
19 >> > > Other projects like the Linux kernel require signing a DCO for each
20 >> > > commit, but do not do any checking beyond this. I have no doubt that
21 >> > > they would remove offending sources if they were contacted, but they
22 >> > > do not actively go out and confirm authorship.
23 >> > >
24 >> > > >
25 >> > > > > > The package in question doesn't come with any license though, which
26 >> > > > > > means that only the copyright holder has the right to distribute
27 >> > > > > > it. So I believe that some extra care is justified, especially when
28 >> > > > > > the upstream location of the distfile has changed.
29 >> > > > >
30 >> > > > > Why? We don't redistribute anything that is copyrighted.
31 >> > > >
32 >> > > > Users download the file, and I think that we are responsible to have
33 >> > > > only such SRC_URIs in our ebuilds from where they can obtain the
34 >> > > > package without being exposed to potential legal issues.
35 >> > >
36 >> > > I'm not aware of any court rulings that have found downloading
37 >> > > something like this to be illegal.
38 >> > >
39 >> > > >
40 >> > > > > Perhaps if we want to enforce a policy like this we should take the
41 >> > > > > time to actually write the policy down. As far as I can tell Gentoo
42 >> > > > > has no such policy currently.
43 >> > > >
44 >> > > > The old Games Ebuild Howto [1] has this:
45 >> > > >
46 >> > > > > LICENSE
47 >> > > > >
48 >> > > > > The license is an important point in your ebuild. It is also a
49 >> > > > > common place for making mistakes. Try to check the license on any
50 >> > > > > ebuild that you submit. Often times, the license will be in a
51 >> > > > > COPYING file, distributed in the package's tarball. If the license
52 >> > > > > is not readily apparent, try contacting the authors of the package
53 >> > > > > for clarification. [...]
54 >> > > >
55 >> > > > I propose to add the paragraph above to the devmanual's licenses
56 >> > > > section.
57 >> > > >
58 >> > >
59 >> > > We already know there isn't a license for redistribution. This
60 >> > > doesn't speak about requiring us to ensure that those distributing our
61 >> > > source files have the rights to do so. It merely says to check the
62 >> > > license. We understand the license already. I don't see how this
63 >> > > paragraph pertains to this situation.
64 >> >
65 >> > AFAIK you're a developer. So if you want to keep this package, then
66 >> > please do the needful and take care of it yourself instead of
67 >> > complaining and demanding others to do the work you want done.
68 >> >
69 >>
70 >> Are you saying it is sufficient to just point the SRC_URI at the new
71 >> URL and remove the mask? As far as I can tell that is all that needs
72 >> to be done. Per the policy the license is readily apparent, so there
73 >> is no need to contact the authors.
74 >>
75 >
76 > I don't know what is sufficient. It's your business as the new
77 > maintainer to figure it out and take the responsibility. If there's
78 > nobody willing to do that, then we don't get to keep the package. Simple
79 > as that.
80 >
81
82 And how would I figure it out, considering that simply asking on the
83 list doesn't seem to yield a straight answer? Do you really need me
84 to put it on the Council agenda? Or do we unmask it, let QA mask it
85 10 minutes later, then go back and forth for a month, and THEN put it
86 on the Council agenda?
87
88 --
89 Rich

Replies