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