Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add GPLv3 license #124

Merged
merged 2 commits into from
Nov 18, 2017
Merged

Add GPLv3 license #124

merged 2 commits into from
Nov 18, 2017

Conversation

pluehne
Copy link
Contributor

@pluehne pluehne commented Nov 18, 2017

I just packaged python-miio for Arch Linux in the Arch User Repository.

In doing so, I noticed that, while the GLPv3 license is stated in setup.py, there is no explicit license file. I know that dealing with licenses is somewhat annoying, but proper packages should install license files to /usr/share/licenses/. Additionally, this is useful information for users, and the GLPv3 license will be displayed nicely by GitHub for clarity.

I took the license template from GLPv3 in Markdown and filled in the necessary information in the second commit, 18fdce1, to make reviewing the actual changes more easy.

Feel free to make adjustments as necessary 😃.

@coveralls
Copy link

coveralls commented Nov 18, 2017

Coverage Status

Coverage remained the same at 44.944% when pulling 18fdce1 on pluehne:patrick/license into 88bd3c9 on rytilahti:master.

@rytilahti
Copy link
Owner

rytilahti commented Nov 18, 2017

Well spotted, and it is indeed a good idea to have an explicit LICENSE file delivered with the package (needs adjusting also to setup.py? I'm unsure..). However, I think it makes more sense to have a verbatim copy of original, text-based (non-markdownized) version of the license to make it plain enough. What do you think?

edit: another point, is COPYING or LICENSE preferred naming for the file, or does that really matter at all?

@pluehne
Copy link
Contributor Author

pluehne commented Nov 18, 2017

That’s up to you, after all, this project is mostly your effort 😃.

I usually prefer Markdown license files, because they are easier on the eye should you really want to read them. And even if nobody actually reads the license file, why not make it look nicer?

@pluehne
Copy link
Contributor Author

pluehne commented Nov 18, 2017

Aside from my earlier comment, I think that naming it LICENSE.md is fine. My understanding is that most systems will look for any variations like LICENSE, COPYING, LICENSE.txt, LICENSE.md, etc.

And I don’t know what the convention for handling licenses in setup.py is, as I’m haven’t build Python setup scripts so far.

@rytilahti
Copy link
Owner

https://stackoverflow.com/questions/9977889/how-to-include-license-file-in-setup-py-script makes a remark that using a metadata for pointing out the license is fine, so I don't think it's necessary to ship the license file with it. Let's ship the LICENSE.md for those who want to have it available, the verbatim copy of the license is available anyway e.g. in https://www.gnu.org/licenses/gpl-3.0.en.html . Thanks again!

@rytilahti rytilahti merged commit 8240863 into rytilahti:master Nov 18, 2017
@rytilahti
Copy link
Owner

rytilahti commented Nov 18, 2017

I added also a verbatim copy of the license in text as provided by github's "add license file" feature. It doesn't seem to show the license on the front page as of yet, maybe it's something that gets added at some point after some sort of analysis procedure is run on the repo..

edit: btw, as soon as #121 gets merged I will do a new release, which will include the addition of explicit license file alongside some other changes.

@pluehne pluehne deleted the patrick/license branch November 20, 2017 17:44
@pluehne
Copy link
Contributor Author

pluehne commented Nov 20, 2017

@rytilahti: I’m curious about the new release 😃. Is there anything left to do for 0.3.2 that I could help with?

@rytilahti
Copy link
Owner

@pluehne I think the only thing to do for a new release would be updating the README to contain a link to the new documentation (and updating the documentation where necessary!). If you want to contribute, a read-through & updates to the docs would be more than welcome :-)

The preliminary docs are now available in https://python-miio.readthedocs.io/en/latest/ - a local copy can be compiled just by calling make inside docs directory. My plan was to have it in such a state that it could be e.g. linked inside homeassistant's documentation instead of duplicating the information (see https://home-assistant.io/components/vacuum.xiaomi_miio/#retrieving-the-access-token).

@pluehne
Copy link
Contributor Author

pluehne commented Nov 20, 2017

@rytilahti: Cool 🙂! Unfortunately, I’m very busy until the weekend, so maybe, I’ll have a look at the docs then. Would that be fine?

@rytilahti
Copy link
Owner

That'd we awesome, thanks :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants