| 1 |
>>>>> On Thu, 7 Sep 2017, Rich Freeman wrote: |
| 2 |
|
| 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 |
>>> Are you saying it is sufficient to just point the SRC_URI at the |
| 7 |
>>> new URL and remove the mask? As far as I can tell that is all that |
| 8 |
>>> needs to be done. Per the policy the license is readily apparent, |
| 9 |
>>> so there is no need to contact the authors. |
| 10 |
|
| 11 |
Huh? The very problem here is that the package has *no* license. |
| 12 |
|
| 13 |
The LICENSE variable was always mandatory, so originally a package |
| 14 |
without a license (like the one mentioned in the subject) could |
| 15 |
not be added to the tree. Or, devs would tag it with the infamous |
| 16 |
"as-is" license label. Cleaning up the resulting mess was quite a |
| 17 |
nightmare [1]. |
| 18 |
|
| 19 |
Later it was noticed that there is a specific class of software where |
| 20 |
there is no license, but that are up for download at their author's |
| 21 |
site. Examples were dev-libs/djb and other packages related to qmail. |
| 22 |
We then came up with the "all-rights-reserved" license label [2], in |
| 23 |
order to permit such software in the tree. (You should be aware of |
| 24 |
this, because you were a trustee back then). |
| 25 |
|
| 26 |
Quoting from "all-rights-reserved": |
| 27 |
|
| 28 |
| This package has an explicit "all rights reserved" clause, or comes |
| 29 |
| without any license, or only with a disclaimer. This means that you |
| 30 |
| have only the rights that are granted to you by law. If you have |
| 31 |
| lawfully acquired a copy of the program (e.g., by buying it or by |
| 32 |
| downloading it from the author's site) then in many legislations you |
| 33 |
| are allowed to compile it, run it, make a backup, and to patch it as |
| 34 |
| necessary, without permission from the copyright holder. |
| 35 |
|
| 36 |
Note that it explicitly says "downloading from the author's site". |
| 37 |
I still think that we should handle this in a restrictive way, and |
| 38 |
permit only sites where we can be reasonably certain that they |
| 39 |
distribute the software with the copyright holder's approval. |
| 40 |
|
| 41 |
>> I don't know what is sufficient. It's your business as the new |
| 42 |
>> maintainer to figure it out and take the responsibility. If there's |
| 43 |
>> nobody willing to do that, then we don't get to keep the package. |
| 44 |
>> Simple as that. |
| 45 |
|
| 46 |
> And how would I figure it out, considering that simply asking on the |
| 47 |
> list doesn't seem to yield a straight answer? Do you really need me |
| 48 |
> to put it on the Council agenda? Or do we unmask it, let QA mask it |
| 49 |
> 10 minutes later, then go back and forth for a month, and THEN put it |
| 50 |
> on the Council agenda? |
| 51 |
|
| 52 |
Why not follow kentnl's suggestion? If you don't want to figure out |
| 53 |
what the connection between the author and the download site is, then |
| 54 |
make the ebuild fetch restricted, and have the user download the |
| 55 |
file manually. I'd also suggest to put only the file's basename in |
| 56 |
SRC_URI then. |
| 57 |
|
| 58 |
Ulrich |
| 59 |
|
| 60 |
|
| 61 |
[1] https://bugs.gentoo.org/436214 |
| 62 |
[2] https://bugs.gentoo.org/444424 |
Archives