Is this legal / morally ok?
Download opened this issue · 8 comments
First of all, cool project this! So please don't see this is as negative criticism...
In your readme you state that
note that the date will always show the current year
This is actually pretty common practice but I've always frowned upon it.
Copyright is not unlimited. It expires. This is why copyright notices contain a year. It allows us to know when the copyright has expired (and resolve matters of prior art etc). By always setting it to the current year we are basically extending it infinitely...
The copyright notice does not in itself hold much legal value afaik, so just putting the current year in it is probably not illegal, but it is definitely wrong technically and I wonder about it's moral implications...
It's also a bit weird that all works by a person licensed under the MIT license would have the same copyright year. The license does not change, but the copyright notice should. It should be different for each created work.
The right thing to do would probably be to allow for the copyright notice details to be passed along in the URL itself, so they could be changed for each project:
http://rem.mit-license.org?year=2014
Of course you could always fall back to the current year if no year was passed in the URL. Or better yet, use the year the cname was created. That will also stimulate people to pass the URL argument to 'update' the copyright when they make changes later.
What do you think?
A bit late, but I've been re-reading this (after there was an outage on the hosting and I had to update a few bits).
I've added the ability to pin to a specific year as you suggested: https://rem.mit-license.org/@2010
I guess the real source of the problem is that this is a service tied to a single user, whereas licenses are typically inserted into project code, so they're per project, which allows them to have a fixed date.
@remy i like this feature however it would be nice if we could also specify the starting / ending years within the json.
@belldandu given the context of this open issue, I'm not sure putting in the json file would actually make sense. It would then affect everywhere that you linked from... it's possible it's actually in the code already (I've not checked), and if there demand, I'd be happy to accept a PR for it.
@belldandu On a per-project basis you can link to the relevant range for that project. E.g. https://rem.mit-license.org/2014-2016 or https://rem.mit-license.org/@2012.
This issue seems to have been resolved and gone stale. You can pin the years in the URL like so: https://rem.mit-license.org/2014-2016 or for a single year: https://rem.mit-license.org/@2012. Closing for now.
Updating your copyright dates make your projects appear like they are still relevant in the modern day despite the fact that you might not actually be working on the code.
Besides git provides a much better form of accounting when it comes to preserving evidence of the projects epoch for any claims that might be made against the legal validity of your copyright claims.
Patents should expire fast. Copyrights should last until we expire.