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 |