search

jonschlinkert / update-copyright

Update a copyright statement with the current year. Also makes minor corrections.
MIT License
15 stars 57 forks source link

year range #2

Open jonschlinkert opened 7 years ago

jonschlinkert commented 7 years ago

@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:

Copyright (c) 2014 Jon Schlinkert

It will currently be updated to:

Copyright (c) 2014, 2017 Jon Schlinkert

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?

tunnckoCore commented 7 years ago

Side note: sadly even don't use update et al.

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 2014-2017 and 2014, 2017 - in the first case is that you hold the license for all the years in range, in the second case you hold only for 2014 and 2017, that's how i understand it.

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.

jonschlinkert commented 7 years ago

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.

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.

doowb commented 7 years ago

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...

I think this is a good idea.

jonschlinkert commented 7 years ago

k thx for the feedback @doowb and @tunnckoCore!

jonschlinkert commented 7 years ago

sadly even don't use update et al.

btw, I'm going to be pushing up changes that make update easier to override and customize. maybe that will help.

Even though you're not using update, I could use your feedback. Should we use ~/.update/ as the default directory for storing custom, user-defined config values for update (as well as any updaters)?

tunnckoCore commented 7 years ago

Maybe yea. It would be good, I like hidden dirs :D

btw, I'm going to be pushing up changes that make update easier to override and customize. maybe that will help.

As about that... I just don't have the time to make updaters for me and my cases/templates.