[baseline practices] Choosing a License and Choosing Dependencies about package-maintenance HOT 28 CLOSED

I think we might be able to strike a balance by explaining the pros/cons along with making it clear how the license choice will affect use (by companies etc.). I don't think we need to say "don't" do this (ie explicitly discourage), but I think we could say "If you want broad use in X community" then these kinds of licences are better than others?

from package-maintenance.

some license stats from the registry.
( in order of popularity )

• MIT
• Apache
• BSD
• ISC
• SEE LICENSE
• MPL
• [object Object]
• GPL
• CC0-1.0
• LGPL
• Unlicense
• pemrouz.mit-license.org
• Artistic-2.0
• WTFPL
• AGPL

1. The license is literally "SEE LICENSE", i.e. it refers to a license.txt
2. [object Object] is again literally the license field when people put JS in it
3. "Unlicense" is "The Unlicense", not un-licensed code
4. The WTFPL really is that popular

from package-maintenance.

We should certainly mandate choosing some license, and ideally discourage "unlicensed".

from package-maintenance.

Note that we should not suggesting to relicensing. A license should be a MUST.

We might decide that GPL and AGPL code is not part of this program, as well as "patent" licenses.

from package-maintenance.

Yes, it’d be great if we could also discourage viral licenses.

from package-maintenance.

Sure, but is it justs me, or does that seem out of scope for this group?

"package maintenance" as a phrase is pretty broad.

IMO, I'd try to focus on "packages" that are published via npmjs.com, consumed via npmjs.com, and that don't have side-band agreements between producer and consumer. After all, if someone is, for example, paying for the right to consume something published via npm (I have worked for a company that published packages like that), you are in a position to do 1-1 support negotiation.

Anyone else who liked and wanted to adopt some aspects for "inside source" (that was a new phrase to me), or Unlicensed, or usb-key distributed packages would be free to do so, of course, but satisfying all those use-cases simultaneously is pretty ambitious. Maybe overly.

from package-maintenance.

The fact that restrictive copyleft hurts adoption, does not mean copyleft is the problem. I think for many people (including myself) licenses like MIT are the easy and safe choice - we've got other things to do as developers. You can't solely blame legal teams and lack of precedence for the standstill (although I've met a legal team that seriously lacked knowledge about software licensing, which is one of the reasons I think education is more important than taking a particular stance).

Saying the situation is "unlikely to change" is realistic, but when we actively discourage copyleft licence X or Y, it becomes a self-fulfilling prophesy. That's what I wish to avoid.

Node does not have to take a position on this, and I would prefer that.

from package-maintenance.

I hope I'm not repeating myself to the same audiences again. But in practicality all the packages that we are likely to support will have an existing license.

To date most of the licenses on the SPDX license list have been tested in the field. Meaning they seem to work. Given the choices and the advice on opensource.guide would it not be more legally appropriate to direct people to these other sites if they do not have a license? If there is a license it really cannot change.

By offering advice on the license rather than saying here are some resources we found and you should think about using them we are in fact offering legal advice. This would not be a good thing as we are not legally qualified to do so. The words are important.

from package-maintenance.

An existing license certainly can change; it can also add additional licenses. We can offer all the legal advice we want, as long as we make it clear we're not lawyers :-)

from package-maintenance.

I'm struggling to find where anyone proposed giving legal advice above. Saying "many individual users will not use any modules licensed with AGPL of GPL licenses" isn't legal advice, its cultural advice. We don't say anything at all about how the license does or does not function, what legal responsibilities it states, etc, just that some people won't use it.

from package-maintenance.

I think we should close this as the doc has been merged.

from package-maintenance.

I think we can put this to bed for now. Obviously as we learn I'm sure we will update. I do have some numbers on @ljharb object object for him from npm that we can go over later. But it is not too many.

from package-maintenance.

useful resources:

• https://choosealicense.com/ is a great reference for newcomers into the world of OSS Licensing.
• https://spdx.org/licenses/ is a list of licenses recognized by the Linux foundation

from package-maintenance.

@rxmarbles will take a first pass.

from package-maintenance.

Glad to lend a hand as I have been meaning to understand all the options we are given in the github LICENSE file, been going for the unlicensed recently!

from package-maintenance.

We should certainly mandate choosing some license, and ideally discourage "unlicensed".

I would agree, with emphasis on the context of Open Source, however, many -if not all- of the guides written here willl also apply to inner-source projects, and I would ideally like to see emphasis on things like "SHOULD" / "MUST" be presented in the right context...

from package-maintenance.

Could you explain why those licenses are at odds with this project?

from package-maintenance.

They discourage a healthy ecosystem - a virally licensed product can not be used by most companies, and as such, either the package, or most companies, are excluded from participating in that part of the ecosystem.

from package-maintenance.

I hope node can be inclusive to both groups. Companies are not saints and copyleft is not a cure-all; both groups have valid viewpoints. Node could even play a role in removing some of the fear surrounding copyleft code and using it in a company (reminder: pretty much everyone is using the GPL-licensed Linux kernel, one way or another). This could bring the groups closer together. Discouraging copyleft achieves the opposite.

from package-maintenance.

There’s a bit of a difference between licenses that allow versus licenses that constrain; the fear you refer to comes from most companies’ legal teams, and short of a precedent-setting court case, that’s unlikely to change.

from package-maintenance.

The npm package format itself discourages non-OSI licenses. I think its worth having an opinon on custom, or bespoke licenses, and "unlicensed" (why publish something that no one has a license to use?). We should encourage the ue of well written, well understood, and meaningful licenses.

I don't agree that we should discourage GPL or AGPL.

We should encourage (require!) people to make the license explicit, of course, so that package consumers can choose to NOT use GPL or AGPL licensed packages (most would, I would!, and authors of packages with those licenses understand that).

from package-maintenance.

I certainly think we should require a valid SPDX declaration, of which "Unlicensed" is one.

However I think we should encourage licenses that maximize the ability of others to adopt the package - eg, non-viral copyleft licenses.

from package-maintenance.

I don't know that the package mainenace guidelines apply to Unlicensed packages, since they can't be legally depended on, they are effectively private-use, aren't they? Aren't the guidelines intended to help people who are publishing packages that are intended to be consumed?

Anyhow, "discourage" is a strong word. Describing the effect of license choice is well worth it.

As far viral licenses, I know lots of people/companies that won't touch a package with those licenses, that's fine, but people who publish using those licenses, in my experience, do so VERY deliberately, and they won't care about our "discouragement".

Perhaps there is a small group of people just think "GPL, hey, Linux uses it, must be good, I will", without thought to its meaning. It might be possible to discourage them.

from package-maintenance.

@sam-github they can be if you get explicit permission from the publisher.

from package-maintenance.

Legally it does not matter if we are say we are not lawyers, if we offer legal advice of any kind we are in general breaking the law in many countries. I would caution against offering any legal advice. I think we need to think about this. As for the point about changing the license. You can of course, but this is not generally recognized in law if you took something under a license then the license you took it under applies.

from package-maintenance.

I would be surprised if freely offered advice, clearly indicating that it’s not from a professional, is regulated - that’d be the same as making it illegal to suggest most anything to anyone that hadn’t paid you for it.

If a project retroactively adds, say, MIT to all of the versions of its product, then every user of any of those versions immediately gains the ability to be “under MIT” merely by claiming that they are.

from package-maintenance.

I'm sorry and really apologize for my being unwavering on this point but if we wish to get support from organizations in the future we have to word as @sam-github has suggested appropriate language. It may be ok to say 'we suggest you have a license' but actually offering an opinion on which one(s) would be a mistake.

from package-maintenance.

Repeating my comment:

to clarify; [object Object] is when they use the antiquated object form of the field, which still, however, can be normalized to a license - unfortunately they didn't seem to apply that normalization.

from package-maintenance.