-
Notifications
You must be signed in to change notification settings - Fork 98
v4.0.0? #147
Comments
One thing i was wondering about, given the fact that more people have contributed to the project than are listed in the copyright statement, is whether it might be good to move the code to being in the Public Domain and not asserting copyright or a license of any kind. What do people think about that, especially @gsf, @anarchivist and @Wooble? |
I'm not up to date on the latest moods around licensing, so don't know if there are negatives around going public domain, but I hereby relinquish my copyright claim if you decide to do so. |
I'm all for a public domain but I would ask us to consider an explicit license or declaration like CC0 or the Unlicense. We could also consider 0BSD along with an explicit copyright waiver. |
I also relinquish my copyright claim. |
@edsu maybe it could be time to announce the end of py2 support ? For now by just updating the readme/docs/setup.py/travis.yml, and, one day, do a big cleanup (linting, proper typing, no more six, etc.) that will definitely break py2 compatibility. |
same; I have no strong opinion either way as long as whatever we do doesn't make it suddenly hard for some subset of our users to keep using the library. (IANAL but I've heard vague things about public domain not being a thing in some jurisdictions?) [this is re: copyright, not py2 support. I'm more than happy to make the subset of our users who refuse to use py3 unhappy ;) ] |
@Wooble yes, I think that's an argument for using CC0 as @anarchivist suggested. Thanks everyone for being open to exploring this. @herrboyer do you think now is the time to lint and type, and remove six? |
It's always time to lint ! I think a combination of flake8 + flake8-docstring + black would provide a clean base for future development. I use this config for most of my projects : [flake8]
ignore =
# line length is handled by black
E501
# Missing docstring in public nested class (ex. Meta)
D106
# Missing docstring in magic method (__str__ ...)
D105
# First line should be in imperative mood -> I've never really like/understood this one...
D401
# E203 & W503 are not PEP 8 compliant
# @see https://github.com/psf/black
W503
E203
per-file-ignores =
# empty init does not really require doctrings
__init__.py D104
# no need for doctrings in tests
test_* D103 And we could easily add a step in the CI to check linting before running the tests, this will avoid noise related to formatting in future PRs. I'll be happy to work on this if everybody's OK with it. Then we could work on typing and removing six / py2 support ? |
This would be awesome @herrboyer and is worth waiting for in v4 I think. I will create new issues for both pylint and python3. If you take the first then I will take the latter (but I will wait till linting is completed before doing it). I haven't used types much in my own work, does your linter setup do something with them? |
Great ! I started working on #148 here #150 : please note that I plan to use flake8 instead of pylint which is a bit easier to configure (and to please...). You'll be using mypy to check types the same you use flake8/pylint for linting (mypy something.py). I think this Python Type Checking (Guide) helped me when I started typing my code especially with custom types, Dict, Union, etc. |
I only have a handful of commits in the project's history, and I'm not listed in the contributors list, but I would prefer to maintain the current well-understood permissive license. I don't think moving to a public domain-type license would remove the burden of maintaining a list of code contributors. See the CC0 FAQ:
They suggest this because, under the copyright law of many nations, anything you write automatically falls under copyright by you, and you somewhat paradoxically have assert your copyright to be able to license it or dedicate it to the public domain. Given that licensing is the focus of their organizations, it's probably best to take it seriously. If the real problem is that it's a drag to list all of the contributors, could we solve this problem with code? e.g. something like using "git blame" to generate a list of all of the contributors to a given release and use that to create an accurate first line of the LICENSE file? |
On that last point, building on this StackOverflow suggestion, here's what the current master branch list of contributors looks like:
It's not perfect but maybe not so bad to run once per tag/release? |
Incidentally, I switched a work project last fall to use all-contributors. I happen to like it, but I won't push for it too hard since it adds another set of dependencies (Node + associated modules) to the toolchain. (There's a bot too that uses Github actions, but I haven't used it.) |
@anarchivist thanks for sharing that! How did you end up expressing the copyright statement--was it an institution? |
@dbs that's a nice hack. Would it help with the copyright statement though? |
@edsu yes, it was. (unfortunately 😄 ) |
It would help if you just concatenate the list of contributors to the copyright statement. So add in a
This could be adjusted to include email addresses, too, as those are more precise identifiers than just names. There are a few names in there that I suspect are just github nicks; if desired, a .mailmap file for the project could be used to expand those into full names & email addresses (or consolidate those who use multiple email addresses). |
@dbs I don't think I've ever seen a copyright statement like that before. Have you? |
Nope. But it's the truth (or something close to it) if we extend the current practice of trying to use just a single copyright statement for the entire project, instead of applying license headers to each file in the project that state both the license of that file and the accurate list of copyright holders for / contributors to each file. The latter approach is recommended by the GPL and Apache license, as well as the Open Source Initiative and the Producing Open Source Software book. Note that the copyright & licensing best practices include specifying in which years a given file was actually modified by each contributor, instead of just giving the blanket range of years for the entire project. See stp/stp#199 for an example of a project that went through that exercise a few years ago. My guess is nobody really wants to go through that level of granularity, however. As an alternative to file-level copyright and licensing notices, the Software Freedom Law Center documents a centralized license notice. You still end up putting a header in each file, but that header simply states something like:
Given that the Software Freedom Law Center gravitated towards copyleft rather than permissive licenses, maybe that last sentence could be more encouraging for a BSD-2 project like pymarc, e.g. "pymarc may be copied, modified, propagated, or distributed according to the terms contained in the LICENSE file." And then the LICENSE file contains the license and list of copyright statements. Something like:
It would be easy to apply the headers, and a centralized LICENSE file with contributions broken out by year should be straightforward enough to generate periodically from the git logs. I would be willing to work on a branch to implement the centralized license notice approach. |
And what about switching the ownership of the project to a « pymarc » organization, transferring the license to it and maintaining an
|
I've wanted to move edsu/pymarc to code4lib/pymarc for some time. But I wonder if moving it to a new pymarc organization might be a bit cleaner. According to this discussion, assigning copyright to a GitHub org should be ok as long as the existing copyright holders sign off on it? So the proposal would be to:
@dbs & others what do you think? |
The accepted response to that discussion states that the Github org would not be a legal entity and cannot hold copyright (1st and 4th paragraph). And the accepted response still recommends "a full list of named copyright responses" (4th paragraph). So this doesn't really change much. You still need a centralized license header for each file. And you still need a list of the contributors, whether it's in a LICENSE file, a README, or a separate CONTRIBUTORS file. I'm -1 to the idea of assigning copyright, especially to a non-legal entity. (I don't want to do it for journal articles, either...) The bonus of the centralized license header approach suggested by the Software Freedom Law Center is that it doesn't include any dates, so we wouldn't have to go through and touch each file in 2021, 2022, etc. Just an automated process to update the copyright notices in the LICENSE file on a regular basis. |
@dbs fair point, I guess I didn't really read that very closely :-) Let me merge in @herrboyer's Linting PR #150 and then it would be great if you would be willing to put together a PR that addresses how we might best deal with the licensing, if you are still up for that? |
@edsu, I would be happy to do so! |
See https://github.com/dbs/pymarc/tree/147_apply_license_headers for a rough first pass. It generates the LICENSE file with the list of contributors below the license, and adds headers to all Python files with the exception of docs/source/conf.py (which appears to be largely stock?) The contributors are currently sorted by first name, but could pretty easily be sorted by number of commits or some other way if so desired. |
Given the recent changes to the leader, I was thinking that a new major release was warranted, v4.0.0. Are there any other major changes we might want to consider as part of this release, or should we just go for it?
The text was updated successfully, but these errors were encountered: