-
-
Notifications
You must be signed in to change notification settings - Fork 106
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
Copyright notice removed #197
Comments
As I maintain hundreds of projects in the Python ecosystem, maintaining an accurate and meaningful system for tracking attribution and copyright is crucial, and a simple notice "Copyright (year) (person)" is rarely adequate. In jaraco/skeleton#78, I was exploring the motivations behind copyright notices and what's necessary and what's valuable. In that research, it became apparent to me that a single line for copyright in a long-lived package is unlikely to be close to accurate. Consider, for example, the copyright removed from this package. It indicated that the code released in 2023 was copyright solely by Paul Dyson in 2010. That's obviously not right. It's based on code written by (and thus copy right to) Paul Dyson back in 2010 (and probably before and after). The problem with the "copyright {year} {entity}" is that it's antiquated. It's based on a distribution model in which software was released infrequently and maintained largely in relative isolation with little or no access to the source development history. In today's world, open source code is rapidly developed in the open with sophisticated tooling for tracking provenance and attribution, rendering the one-line copyright notice more incorrect than correct. In addition to the relatively permanent and fine-grained source history, there's also a publicly-managed PyPI repository of releases that also retain the attribution that was present in releases. Consider the
By my count, that's 56 authors having contributed in some way to this project. And at the same time, that list and the former copyright, fail to capture the copyright held by projects from which this project was derived (both in spirit and in code). The references in jaraco/skeleton#78 reinforced my understanding that the inclusion of an explicit, one-line "copyright notice" is antiquated and obviated by law, practice, and the modern reality. My preference is to work in the open, be transparent and fair and equitable, and avoid unnecessary, toilsome, inaccurate notices for the sake of outdated convention. That said, Paul Dyson's opinion gets an outsized influence on the decision here, given his work as a seminal author. @pwdyson Can you tell me more about your motivation for wanting to keep the copyright notice with your name? The project still lists you as primary author, although my intention is to eventually remove hard-coded author/maintainer and derive it instead from SCM history. Are you concerned with attribution, legal implications, or something else? Help me understand what you'd like to achieve and I'd like to work with you to achieve your objectives. |
From pwdyson in #194:
|
And jayaddison:
|
I've been pondering this issue and I have some thoughts.
I reject this rationale as a good reason to utilize a copyright notice. It suggests that if I have an important message that I wish not to be removed downstream, I could add it to the copyright notice. For example,
I think you'd agree that such a copyright would be abuse of the copyright to elevate its influence and durability.
These are important details that I agree should be acknowledged somewhere that's likely (and verifiably) included in the source. I believe that would better be done in a specific acknowledgements section that avoids abuse of the copyright (even if unintentional), especially when the copyright conveys increasingly incorrect information.
I believe this analogy is a poor one for the reasons mentioned above. Software is not and has not been for a very long time analogous to document publishing. Instead, the content is continuously evolving with the copyright held by a complex history of contributors and dates. We're not talking about reprinting in an updated format, but continued evolution, maintenance, improvements, and refactorings. After all, what should happen should I choose to refactor the code and move some of the code to another module? Should the copyright be replicated? Should it remain in the original file ( There's an additional problem of it being a derived work. If I understand copyright correctly, the original copyright is not held solely by the original author of the Python library if it was derived from another work, but is also held by the authors of the Perl module. In fact, I seem to recall having removed Perl code from this codebase that was presumably copied directly from that project. All of these concerns leave me unconvinced that retaining the copyright is the best option for the project. That said, out of respect for Paul, my plan is to restore the copyright and then propose alternative forms that meet the same goals but avoid the pitfalls laid out above. |
In e640d3a#r120831163, @pwdyson expressed concern about the removal of the copyright notice. In that commit, I'd given some allusion to the motivation behind it, but I'm opening this issue to capture in more detail the motivation and to address Paul's request (alongside #194).
The text was updated successfully, but these errors were encountered: