Loopback-next: App template generates MIT License file without prompt

[kjdelisle]

Overview

Generating a new application with the lb4 app command generates a LICENSE file, whose contents are the MIT license template. This happens without user interaction!

Problems

• Users can't select a different license
• Users who don't pay attention may end up releasing code to others under a license they never intended (not something we should make possible, however unlikely)
• Users can't opt-out of selecting a license of any kind

@strongloop/loopback-devs What are your thoughts on this?

Acceptance Criteria

As a result:

• [ ] In package.json, have a license property set to empty string ("").
  
  
  
  • This ensures npm install will give a warning to users about the project not having a license.
  
  
• [ ] Not generating LICENSE file at all

[dhmlau]

That's good catch. I didn't realize LICENSE file got generated!
IMHO, i don't think we should generate the LICENSE file for the user.

[virkt25]

+1 on not providing a license file at all

[shimks]

+1

[jannyHou]

+1

[raymondfeng]

There are debates on how npm init handles license. See https://github.com/npm/npm/issues/8918 and https://spdx.org/spdx-specification-21-web-version.

I suggest that we generate the following:

1. Add "license": "SEE LICENSE IN LICENSE" to package.json
2. Generate an empty LICENSE file

[dhmlau]

@raymondfeng , any reasons that we want to generate an empty LICENSE file vs not generating it at all?
Either way we go, I'd like to mark this as MVP.

[raymondfeng]

@dhmlau

1. It's a good practice to include the license with any Node.js module/app
2. npm checks SPDX compliance for license in package.json. You will see warnings during npm i if license property is missing or not complying to SPDX.

[b-admike]

+1 for keeping it out and I like the idea of generating an empty LICENSE file. It won't hurt if it doesn't end up getting used.

[virkt25]

Rejecting. Needs more clarification. Acceptance Criteria needs to address problems. Concerns / questions raised during estimation below.

---

• What does LoopBack 3 do?
• What are the implications of an empty License file vs. not having a license field at all?
• We can't shield everyone across the globe from all the legal implications. We aren't in the business of LICENSE compliance.
• Users should take ownership
• Should CLI tell the user to add a LICENSE themselves
• What does a npm expect for a published package?

[dhmlau]

What does LoopBack 3 do?

No LICENSE file.
In package.json, "license": "UNLICENSED",
(I've tried with LB3 creating an "empty server" app)

What are the implications of an empty License file vs. not having a license field at all?
We can't shield everyone across the globe from all the legal implications. We aren't in the business of LICENSE compliance.

Questions for @jjtang1

Users should take ownership

Yes

Should CLI tell the user to add a LICENSE themselves

It wouldn't hurt. but again, question for @jjtang1

What does a npm expect for a published package?

See this link in npm documentation.
From @raymondfeng's above comment, we'll get a warning for not specifying the license attribute.

[dhmlau]

@raymondfeng @strongloop/sq-lb-apex @bajtos , are you ok with following what we do in LB3:
i.e.

• In package.json, use license": "UNLICENSED"
• Not genenerating LICENSE file at all