License isn't OSI approved.

[romainmenke]

path-scurry is now used in node-glob which has 100 million weekly downloads.

Using the current license, which isn't the same as node-glob and isn't OSI approved doesn't seem ideal.

[isaacs]

Using different licenses is fine as long as they're compatible, and afaik, BlueOak is compatible with any BSD/MIT/ISC style liberal non-copyleft license.

If you have a lawyer complaining about it, send them my way. I'm open to changing it if it's causing problems for someone, but otherwise I'm leaning towards using BlueOak for all new work moving forward, as it's much plainer language and easier to understand, and provides much clearer liability and patent protection than most other licenses.

[romainmenke]

Hehe, we don't have any budget for lawyers.
We rely on tools like OSI approved licenses to make sure our FOSS work is ok and usable.

We will likely have to move away from node-glob in this case for our open source work.

[isaacs]

Out of curiosity, who is "we"?

It'd be a bit silly to move not use my code simply because I've promised not to sue you for copyright or patent infringement and granted you a 30 day grace period for license infringements. But you do you. If you're open to purchasing a special license for your organization, I will grant one for a reasonable fee.

[romainmenke]

I indeed represent multiple "we's" :)

---

Work / Mr. Henry

We use node-glob in dev tooling, but it isn't included in any software that is distributed, shared, ...
I am sure that the license of path-scurry is ok for our use case there and that in the case of an issue we can find a reasonable path forward.

---

Open Source

But I also maintain a bunch of open source packages.
For example postcss-preset-env.

I don't know how that is used, who uses it, what their license requirements/obligations are,...

The main issue here is that I am not a lawyer and that a project like postcss-preset-env which doesn't have any sponsors or budget can't afford legal advice.

I have to depend on a heuristic. Today this heuristic is : licenses must be on the OSI approved list for all dependencies.

Even if BlueOak seems compatible, it still isn't on the list and I am not qualified to make any judgements about this.

Even if it seems fine to me, I would be making that choice for thousands of users and again, I am not qualified :)

---

The best way forward for us would be for the BlueOak license to seek OSI approval. But this has to be done by a License steward?

But we don't have to use node-glob, not using it also fine for us :)

This is not something I have strong feeling about, it purely something I am not qualified to make judgements on.

[isaacs]

Thanks for indulging my curiosity. :)

OSI approval is not the heuristic I use. If the license I've chosen makes my code less suitable for for-profit entities concerned with legal liability, while still being completely available for nonprofit entities who contribute to the commons, I actually see that as a benefit rather than a drawback. For-profit entities can buy a different license from me if they want one, or use someone else's labor for free.

[romainmenke]

There seems to be no way to avoid having path-scurry in our projects 😄
Way to many other packages are using it.

We can drop glob to avoid path-scurry but there are other things like puppeteer which we can't trivially replace.

We have no choice but to alter how we handle dependency licenses.
This also implies pushing this issue further downstream.

---

Edit : just to clarify, this was not me being passive aggressive and asking to change the license. I think you are absolutely free to license your work any way you want to.

I only wanted to inform about the state of the issue from our perspective.

[isaacs]

We can drop glob to avoid path-scurry but there are other things like puppeteer which we can't trivially replace.

That's surprising! Usually it takes a lot longer for a semver major to make its way out there, but I guess there was a lot of pent up demand for rimraf and glob rewrites.

We have no choice but to alter how we handle dependency licenses.
This also implies pushing this issue further downstream.

While I can definitely appreciate that it's inconvenient for you, I think that's ultimately a good thing. In my opinion, there's a lot of overdue change needed in our cultural norms around open source, and this kind of reevaluation is part of how that happens. No one wants to be the annoying stubborn one to change the status quo, but someone has to or nothing ever changes 😅

Edit : just to clarify, this was not me being passive aggressive and asking to change the license. I think you are absolutely free to license your work any way you want to.

No worries, that's not how I read it. But thank you for clarifying, and for the update, it's interesting.

I don't expect it'll be too much of an issue, really. Blue Oak gives you pretty much all the same permissions and protections that MIT or BSD-3-Clause would (and in some ways, more, actually).

[mathiasbynens]

I understand your position, isaacs, and I realize that the current license reflects an intentional choice from a principled stance, which I respect. Still, I believe that changing the license would be in the best interests of the entire open source community.

License proliferation is a growing problem in the open source ecosystem. When developers create new open source licenses that are not recognized by the Open Source Initiative (OSI), it makes it difficult for developers to understand what they can and cannot do with open source software, including contributing to it.

MIT and BSD are both recognized by the OSI and are widely used in the open source community. They are well-understood and there is a large body of legal precedent surrounding them. Adopting either MIT or BSD, or any other OSI-approved license really, would make it much easier for developers to use your software and contribute to it.

I understand that you have chosen a different license for your software for a reason. However, I believe that the benefits of using MIT or BSD far outweigh any potential drawbacks.

Thank you for your time and consideration.
Mathias

[igoradamenko]

Even the issue is closed, I'm just stopping by to leave my two cents here.

In the company I'm working for we use some special software written by security folks. This software checks our dependencies to prevent us from installing packages with unknown or unusual licenses. AFAIK it is a common thing in companies bigger than 100 devs.

Once I tried to push some nice-looking licenses into the list of accepted ones. I do not remember what the licenses exactly, but I remember the reply I got. In a nutshell, it's really hard to use uncommon licenses outside of USA. As far as I get, to be able to use a license the law of the country must recognize this license or have a similar one produced by the country. Otherwise in case of any legal litigation it will be impossible to prove in court that you had the right to use the software. That's why our lawyers do not allow to use uncommon OSS licenses.

I'm not a lawyer, but I think that this is not a problem in USA and the countries with a similar laws like Canada, UK or EU. However, it creates much pain for developers not working there.

That's, for sure, not your problem, isaacs. However, this leads to a choice between “fight the lawyers and the law” and “don't use the package”.

The most painful part of the story is that path-scurry is used by glob, which is used by cacache, which is used by pacote, which is used by npm since 9.6.3. I have no idea what to do with it and how my company will deal with the problem when we decide to update from npm@9.5.0 to the next versions. Probably we will be forced to fork the whole npm and replace or fix the version of the deps.

Again, I am not trying to be passive aggressive. Just explaining the side of the pain which nobody noted here. To give you feedback in case it helps. Sorry, if my comment sounded rude for you.

[romainmenke]

The most painful part of the story is that path-scurry is used by glob, which is used by cacache, which is used by pacote, which is used by npm since 9.6.3. I have no idea what to do with it and how my company will deal with the problem when we decide to update from npm@9.5.0 to the next versions. Probably we will be forced to fork the whole npm and replace or fix the version of the deps.

See my comment above : #7 (comment)

Even if you find a way to eliminate/fork one dependency, another will popup.
Too many things depend on glob one way or another and as packages update path-scurry will keep showing up in your stack.

[isaacs]

I do appreciate you all being very careful to point out that you respect my position, it's not coming from a place of passive aggression, etc. I don't read any of it that way, I think we're all being very respectful and understanding here, and that's great. <3

All of these points are totally understandable, and I do have a lot empathy for the position this puts you in. And with the utmost of respect and good faith, I have to say, it doesn't change anything.

I agree that devs going off half-cocked and writing jokey or amateur licenses is a problem. BlueOak is not such a thing. It's a license that was thoughtfully crafted by professional lawyers who understand this space extremely well, and had been working in it for many years. It expresses exactly my intent with the code that I release under it, more than MIT or BSD do, and in clearer language that is more accessible and straightforward.

The only downside is that it does not belong to an arbitrary set of licenses approved by a governing body, making it a challenge for institutions that have substituted the judgement of that governing body for investing in their own investigation into the code that they harvest from OSS developers. Offloading that judgement may be a perfectly rational thing to do! I'm not taking issue with that. But also, why is that any concern of mine?

For most of my adult life, I have created software and given away most of it, free of charge, and with basically no restrictions on its use. I do this because I enjoy the process, and I enjoy the altruistic nature of open source, and the autonomy of creative freedom. It fills my soul. Like those companies that pull in code from the OSS commons and offload their judgement to the OSI, I am seeking to maximize my own benefit, as we all are.

I will keep using my precious lifetime to create useful and beautiful things, and I will keep giving them away for free. But if I need to do so in a way that conforms to arbitrary rules and restrictions imposed on my autonomy by some other party, well, that's not a labor of love anymore, that's a job. I'll do that job, but not for free.

I said at the top of this post, and it is 100% a legitimate offer, if a company has a problem with any of the OSS licenses I've chosen, I will gladly license it to them under different terms for a reasonable fee.

So really, "This license is inconvenient for us!" kind of becomes a feature rather than a bug. You can all already use the code pretty much however you like (assuming you provide the license with any distribution or fork, and don't hold me liable for what you decide to do with it, which is effectively the same in practice as MIT/BSD anyway). I don't believe that any individual person would read the BlueOak license, and conclude that they don't have that permission.

The only problem is for some of the companies that have been profiting from my work for decades, and offering nothing in return. I don't particularly mind them offering nothing in return. I haven't asked for anything, after all. But I also don't see how I owe them anything.

I am not a supplier in a supply chain. I am a random artist making stuff and tossing it out into the world. A corporate entity becoming addicted to my handouts is not a mortgage on my freedom. It is completely divorced from reality to imagine that this would matter to me.

If the BlueOak license is a problem, and you aren't willing or able to pay for a license, then use another path walking library, or another glob matcher. There are plenty out there. If the pushback is "oh, those aren't as good" or "this one is too popular", ok, cool story, good luck working that out. My bad for making something useful and giving it away for free, I guess 🤣

This whole category of issue of makes me want to just license all my code as "free for noncommercial use, paid license for everyone else", tbh. The only thing stopping me is that the overhead of managing and enforcing licenses seems like it wouldn't be very fun.

[igoradamenko]

Before you answered I wanted to ask you to consider using double license, like, BlueOak-1.0.0 OR MIT, until Blue Oak is approved by OSI. This way it would feel more natural, because this package would not use a license that is “not recognized”, especially not recognized internationally. (Because, as I said, it's hard to deal with US licenses outside of US)

But now it looks like this issue is not about the “plainer language” and being “easier to understand”, but mostly about patent protection and so on. So, I should not ask about double licensing, right? Because if you want to get the patent protection, etc. you won't wait.

This whole category of issue of makes me want to just license all my code as "free for noncommercial use, paid license for everyone else", tbh.

Tbh, it would be easier to deal with, because the condition would be much clearer.

Now, instead of asking the company to consider paying you, I'm asking the company to review the license, and the company is paying lawyers, not you.

/shrug

[isaacs]

But now it looks like this issue is not about the “plainer language” and being “easier to understand”, but mostly about patent protection and so on. So, I should not ask about double licensing, right? Because if you want to get the patent protection, etc. you won't wait.

It's both things :) And also, I like the fact that it has a clear remediation for license violations (you fix within 30 days or lose the license), it's not revocable, etc. Being written in plain language is just a bonus. It's a really good license!

Tbh, it would be easier to deal with, because the condition would be much clearer.

When I'm done rewriting node-tap (and apparently literally everything it uses), I'm intending to release it with all the rewritten parts under BlueOak, and then start investigating setting up the infra to have a turn-key licensing system I can wrap around my projects. I think most people mostly follow the rules, so not too much enforcement would be required really, but there is bookkeeping, setting up an LLC, making a website, all that business stuff.

[igoradamenko]

Ah, I see.

Thank you for spending your time to clarify the intentions! Hope you reach the goal you're aiming <3

[sskras]

I guess BlueOak model license just got approved by OSI: spdx/license-list-XML#2352

[isaacs]

I had said you can't force me to use an OSI approved license. Turns out I was wrong 🤣

[sskras]

I don't think OSI approval should serve as a red flag anyways.
@isaacs, I am so happy that you chose BOML :)