Bug 1763147

This package built on koji:  https://koji.fedoraproject.org/koji/taskinfo?taskID=38363525

* Package named correctly
* Packaging the latest version
* License text included
* License okay for Fedora
* Builds fine in mock
* SPEC file clean and concise
* rpmlint reasonably happy

1.) The license is not clear

There doesn't seem to be any word in documentation or source files about how they are licensed. The MIT license file is just there, with no indication about how is it relevant.

Please ask upstream to clarify this, preferrably by including a comment in the source files about how are they licensed.

That's only a recommendation of the FSF for GPL. It's not required to annotate all source files, and just take a look at the instructions on the sidebar for choose a license, for example: https://choosealicense.com/licenses/mit/
tldr legal: https://tldrlegal.com/license/mit-license "You must include the license notice in all copies or substantial uses of the work."
or this SE answer: https://opensource.stackexchange.com/questions/4534/how-to-apply-mit-license-in-the-github-repo-for-fully-free-project "No, a license header is not necessary, at least for MIT and the Unlicense. Some other licenses encourage you to add such a header but that is not the case of these two."

Thanks for the response.

(In reply to Elliott Sales de Andrade from comment #3)
> That's only a recommendation of the FSF for GPL. It's not required to
> annotate all source files, and just take a look at the instructions on the
> sidebar for choose a license, for example:
> https://choosealicense.com/licenses/mit/
> tldr legal: https://tldrlegal.com/license/mit-license "You must include the
> license notice in all copies or substantial uses of the work."
> or this SE answer:
> https://opensource.stackexchange.com/questions/4534/how-to-apply-mit-license-
> in-the-github-repo-for-fully-free-project "No, a license header is not
> necessary, at least for MIT and the Unlicense. Some other licenses encourage
> you to add such a header but that is not the case of these two."

None of the above is what I'm talking about, or relevant at all.

What is missing here is any indication by whoever owns the copyright that the LICENSE file that is shipped applies to the source files in the tarball.

>> Please ask upstream to clarify this, preferrably by including a comment in the source files about how are they licensed.

If this was unclear, please let me rephrase this:

Upstream needs to clarify this somehow, because it's not clear at the moment.
The best way to do this is to add a comment in the actual source files.
If there's any reason upstream has to object this, they could do something else, such as adding a statement in the README file.

There's might be a chance that "this software" in the MIT license text could be understood as referring to whatever is in the same directory or tarball, but I don't know whether that's universally understood and would prefer a clarification to guessing.

I'm adding a FE-LEGAL blocker, to give the legal a chance to chime in about this, but I believe it would be much easier if you just asked upstream to clear up how is the software licensed.

Also, one more nit here:

2.) Please add BuildRequires: go-rpm-macros

You're using the macros from the package.

Upstream added a note in the readme.

Spec URL: https://qulogic.fedorapeople.org//golang-github-creack-goselect.spec
SRPM URL: https://qulogic.fedorapeople.org//golang-github-creack-goselect-0.1.1-1.fc30.src.rpm

> 2.) Please add BuildRequires: go-rpm-macros
>
> You're using the macros from the package.

Not necessary; it's added by %gometa:
https://docs.fedoraproject.org/en-US/packaging-guidelines/Golang/#_dependencies

So is there anything left to do now?

Unassigning as per https://fedoraproject.org/wiki/Policy_for_stalled_package_reviews

I need this to fix the FTBFS of golang-bug-serial-1.

 - License ok
 - Latest version packaged
 - Builds in mock
 - Tests ok
 - No rpmlint errors
 - Conforms to Packaging Guidelines

Package approved.

(fedscm-admin):  The Pagure repository was created at https://src.fedoraproject.org/rpms/golang-github-creack-goselect

FEDORA-2020-4ea6922f20 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-4ea6922f20

FEDORA-2020-0d24924e33 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d24924e33

golang-github-creack-goselect-0.1.1-1.fc31 has been pushed to the Fedora 31 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-4ea6922f20

golang-github-creack-goselect-0.1.1-1.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-0d24924e33

golang-github-creack-goselect-0.1.1-1.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.

golang-github-creack-goselect-0.1.1-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report.