You sure that's not just for GPL? I worked at a place that had a strict no-GPL policy due to the legal risks of non-compliance. LGPL and MIT software was fine though.

"The legal risks of non-compliance" are the exact FUD the old Microsoft spread. If someone doesn't follow the GPL then they don't have a right to reproduce the software and can be liable for copyright infringement, which is the same as any software license proprietary or otherwise.

That someone wouldn't be liable if they distribute the source for their modifications doesn't increase the risk, it decreases it by providing an alternative to paying damages for infringement that they otherwise wouldn't have, since the GPL author will typically accept compliance in lieu of monetary damages.

It is way, way, way easier to ensure that you follow a commercial license.

Commercial licenses are long and frequently contain terms that are unintuitive or ambiguous which are trivial to violate when most of the employees using the software aren't aware they exist.

And the easiest way to violate them is simply to have installed more copies than you're licensed for, which is an issue the GPL doesn't have.

Trying to figure out exactly which production licenses were needed to be in compliance used to be a recurring nightmare back in the day when I did B2B bespoke system rollouts. A licensing guide, not the license itself but the document trying to explain which licenses have to be acquired under which circumstances, could run well over 100 pages. Microsoft had licensing specialists that the channel could call for help, but if you called them twice or more for the same case you would never get the same answer twice. It was that complex, their own specialists couldn't make heads from tales on it.

>Microsoft had licensing specialists that the channel could call for help, but if you called them twice or more for the same case you would never get the same answer twice.

Do they preface with a "I'm not a lawyer" disclaimer and claim that anything they say is non binding?

And that service only exists as leadgen.

Unless it's with Oracle.

It's not open source so much as it is GPL. In industry, GPL software is essentially anathema. MIT/BSD and other licenses are far easier to get approval to use.

I can understand their perspective, especially if they're non technical. Much of the time they see open source as some ragtag community project that has no real support so they believe in terms of risk, it can seem lower to build or buy.

If they don’t even know enough about open source (and are resistent to being enlightened), they shouldn’t be making this decision.

Devil’s Advocate - it’s not their job to educate themselves about the vagrancies of open source, it’s the developer’s (or more accurately tech lead’s) job to educate them about the particulars of a project, to prove that the project is healthy with good support today and will be healthy with good support tomorrow.

Without those assurances, and without investigating the project myself, I’d probably turn it down too.

Are they that wrong? What real support does an npm module have?

What support do you get by buying a non-open source module?

A support contract, typically. Few people sell code alone. They sell code plus a contract to support that code.

Support contracts can be very lucrative.

It's usually included when you purchase a commercial license.

I work with a company that generally stays away from open source software, unless they have an in-house developer that can maintain it.

Most open source projects (unless it's backed by a huge company that also charges for support) are run by volunteers that have a day job. This means that support will be non-existent beyond what the developer(s) feel like and bug fixes/updates may or may not happen. This doesn't work that well when a company relies on this software for any critical task.

Exactly. Given the absolute shitshow maintaining anything in the JavaScript ecosystem I can't blame them.

Replace "open source" with "GPL" and I think you'd be correct.