-
-
Notifications
You must be signed in to change notification settings - Fork 57
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
year range #2
Comments
Side note: sadly even don't use Don't know. I don't understand copyrights fully. I understand that if it is a range you hold the license for exactly that range of years, no matter modifications are made or not. I believe there should be a difference between Don't know, maybe if you can share some links to learn more. :) In anyway i just started to not putting a year in the file banners - don't know if this is a good thing or not. The only places where some years is set is in the readme, by verb. |
Idk, I just want to be as compliant as possible so that companies and users who are required to follow rigid guidelines will be able to use our code without any worries. |
I think this is a good idea. |
k thx for the feedback @doowb and @tunnckoCore! |
btw, I'm going to be pushing up changes that make Even though you're not using update, I could use your feedback. Should we use |
Maybe yea. It would be good, I like hidden dirs :D
As about that... I just don't have the time to make updaters for me and my cases/templates. |
@tunnckoCore, remember the comment you made about copyright year ranges? I can't remember where that was, but I have an idea for how to improve the logic for determining copyright dates.
As a reminder of what I'm referring to... when the license for project X has something like the following:
It will currently be updated to:
Technically, this is correct, since you are only supposed to list years in which modifications were made, and
update-copyright
doesn't know whether or not I worked on project X during any other years that aren't mentioned in the license.Solution
What if we add an option to fill in additional years? Then, in the
update
updater, we can actually parse the years from the git history and provide those on the options...Thoughts?
The text was updated successfully, but these errors were encountered: