11

I'll pick one of the most popular React boilerplates as an example here.

Assume I've forked it (the commits history till the fork date remains intact). According to the text of MIT license, the only thing that I have to keep is the license itself. So, does it mean I can change whatever I want in this repository and remove/replace whatever references to the author (e.g. package.json author? Except one thing - reference to original author in the LICENSE file.

And, also, I should replace this line on top of the LICENSE file with this text:

Copyright for portions of project [Original project name] are held by [original author, year] as part of project [New project name]. All other copyright for project Foo are held by [new name, year].

Are these assumptions correct? Where can I find authoritative explanation of such details of the MIT license?

  • If this is an old, unmaintained repository: Apart from the legal considerations, you may like to clearly point out that you intend to maintain your copy and have this officially noted down. This can save other people a lot of searching and insecurities. Here is an example: unmaintained for several years, incompatible forks and a lengthy discussion: github.com/sloisel/numeric/issues/72 I would have liked to contribute but dropped it. – User Jan 28 '18 at 16:21
9

Your assumptions are mostly correct but you can make things a tad simpler...

  1. You are de-facto creating a new package, so you should update your package.json such that it is clear it is something different and a new package. Your users will be thankful for this.

  2. The MIT license requirements are quite minimal: just keep a copy of the copyright and license with the code at all times. For this you simply can carry the original LICENSE file ... And/or add such notice or a simplified SPDX-License-identifier and copyright to every file: that's likely overkill but this is something I personally like as it is an affirmative statement of origin that is inside the files as opposed to external. Note that using SPDX license ids is already part of the NPM package.json spec.

  3. Avoid fancy copyright statements if possible. The common approach is just to slap your own copyright statement on top of the previous one e.g. something like this:

Copyright (c) 2017 stkvtflw

Copyright (c) 2015 Cory House

One of the reason why you want to avoid things like your suggested new notice:

Copyright for portions of project [Original project name] are held by [original author, year] as part of project [New project name]. All other copyright for project Foo are held by [new name, year].

... is that one day I or someone will scan your code for license and copyrights with my tool ... and this new copyright form of yours would unlikely be detected correctly and would require me to update my code to add yet another copyright statement style variation in my copyright parser grammar.

Any other copyright detection tool will likely have the same issue ;)

So be gentle and make it easy for others to mechanically discover your licensing and copyright information by keeping things simple and as "standard" as possible. IMHO if it is detected by scancode then this is quite likely standard and common enough ;)

  • could you also mention legal sources of this information? – stkvtflw Oct 21 '17 at 9:29
  • 1
    @stkvtflw legals sources for which part? – Philippe Ombredanne Oct 22 '17 at 15:40

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.