6

For my case, I have open source projects in Node JS that use the MIT license for which I have only added "MIT" to the license field in the package.json config file. There are no contents of the license and no link to any license file so could be considered ambiguous. Would this without a LICENSE file be considered enough for distribution?

This could be applied to any other programming language and license, and would probably be considered more ambiguous if the license is less well known. If the license is very rare then even if the license contents can be searched online, if there are very few copies, how can someone be certain that the contents have not changed.

Improve this question
7
  • 4
    Possible duplicate of How to use software published under MIT without copyright notice? Commented Aug 15, 2018 at 5:51
  • 1
    Why do this? If you're trying to entrap people, don't do that. It's not like it's hard to put the actual license file in and a copyright notice. Commented Aug 15, 2018 at 5:54
  • @PhilipKendall Yes, this seems to be a duplicate. The other question has not been answered yet though, so an answer here or there would be appreciated. Commented Aug 15, 2018 at 6:54
  • 2
    I hypothesise you've spent more time writing this question than you would have done copying the MIT license into every project you've ever written xkcd.com/1205 Commented Aug 15, 2018 at 8:00
  • 2
    @DamienGolding The MIT license is short and it includes the statement "The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software." so to comply with your own license i.e. to lead by example, it would only make sense to actually include it in your software. Commented Aug 16, 2018 at 7:01

3 Answers 3

Reset to default
6

For people and organizations that are serious about copyright, just a statement in a package.json file is not enough.

Copyright licenses are legal documents and in legal documents the smallest details matter. For that reason, people that are interested in using your project want to know the exact terms under which the work is licensed, which means that the exact text of the license should be part of the project or linked from within the project.

The "licence: MIT" line in the package.json file is at most a tool in quickly determining if the project has licensing terms that make it worth considering.

Improve this answer
3
  • "or linked from within the project" - Correct me if I am wrong, but you mean containing an external link to the MIT text would be allowed. Is this really allowed? Are there any examples of this in popular software projects? Commented Aug 16, 2018 at 5:05
  • 1
    @DamienGolding: The MIT license is short enough that you should just include it. However, the Apache License Version 2.0 mentions in its "How to apply" page that you should link to the license text. Commented Aug 16, 2018 at 7:23
  • Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on Open Source Meta, or in Open Source Chat. Comments continuing discussion may be removed. Commented Oct 20, 2024 at 7:09
2

Let's look at the MIT license.

The first line is: Copyright <YEAR> <COPYRIGHT HOLDER>.

We can debate the importance of the year, but stating the copyright holder is quite important. Without this first line, what does the rest of the license even mean where it says

The above copyright notice

and so on?

When you don't state the copyright holders in a standard way, you force reusers to figure out more creative ways to respect the license. (For example they may link the canonical location of the source repository in the hope that any required information is available there.)

Improve this answer
0

TL;DR:

Is "license": "MIT" in config enough to be a valid license in a software project?

  • Maybe, so consider the answer no.

If a project does not have a valid enough license, what should I do?

  • It is probably not the highest priority, but consider prompting them to include a valid LICENSE file.

From the answers and comments kindly received here and research done myself, I have decided it is important to answer this myself.

Due to law being more vague than software, there seems to be disparity between what the law wants and what tools/services want.

Looking at the documentation for npm package.json license, it does seem programmatically that the "license" field does provide enough information to know the type of license used:

However, as both @BartvanIngenSchenau and @nemo have kindly explained, the MIT license expects the year and copyright holder. Therefore, it is expected that a license is provided that includes this information too. Given that the intention is quite clear even without these parameters for at least the MIT license, it may be implied that this would be enough, and may be so. However, this is clearly prone to being technically invalid, and is also an unnecessary risk, so is not advisable.

Considering this, how should the license with the correct parameters be stored and linked to? For npm, there is the following example: { "license": "SEE LICENSE IN " } This seems to be the only current way to link explicitly to a file. However, this means that an SPDX identifier can not be used here. The deprecated license and licenses object formats did include a "type" and "url" field, making this possible. However, for some reason this has become deprecated. Looking at the documentation for "files" shown below, it shows that LICENSE is a known file type, so linking to this license should be possible by just using this name.

Therefore, it can be inferred that the correct way to handle this in npm is:

  • Use an SPDX identifier for "license".
  • Include the license with parameters in the LICENSE file.

This does mean that a license file needs to be made for each project, instead of just using the license type or linking to a common license. Creating a common license and copying that into the project each time either manually or automatically seems to be the best solution.

This solves the license being programmatically available and linked properly issue. It is also important that people reading the page can see the license. For a repository, the top files are shown by default, so if using the standard LICENSE file format, it could be considered enough. The repository service might also show the license as a link by default for LICENSE files. If there is no license link, or just in case, a link to the license file should be added.

This comes to the main reason for asking the question. What should I do if a repository/package does not meet these expectations? It is very common for repositories to just have a license field and nothing more. This is why I asked the question in the first place. It doesn't seem to be a high risk to use these dependencies, especially if it is easy to replace them with something else if necessary, but it does seem to be something worth prompting repository owners to fix. At least a proper license file would be enough to make the license file valid and clear.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.