Closed yorinasub17 closed 2 years ago
Thanks for review. Merging now.
@brikis98 and/or @josh-padnick : Do we need to retroactively update the license through git history?
A retroactive update would be ideal, but I'm not sure it's worth prioritizing. We have a single customer who's had access to boilerplate up until now. That customer should understand that because boilerplate is in a private repo, the actual license is governed by our terms of service, not the LICENSE
file here, but retroactively updating repo history makes that crystal clear. Still, I think the risk is pretty low, so I'm ok to do nothing unless the retroactive update is a trivial (i.e. <5 mins) operation.
A retroactive update would be ideal, but I'm not sure it's worth prioritizing. We have a single customer who's had access to boilerplate up until now. That customer should understand that because boilerplate is in a private repo, the actual license is governed by our terms of service, not the LICENSE file here, but retroactively updating repo history makes that crystal clear. Still, I think the risk is pretty low, so I'm ok to do nothing unless the retroactive update is a trivial (i.e. <5 mins) operation.
It might become an issue if we ever open boilerplate up to other customers, as legally all those commits are licensed as MIT.
It would be a bit of a pain to retroactively update the LICENSE file, especially with all the release tags. I think the best way to handle this would be to fork boilerplate and start the history a new when we are ready to start sharing it with more people.
That sounds like a good compromise!
Shouldn't the year on this license be 2016? #114
Fixes https://github.com/gruntwork-io/boilerplate/issues/101