This does sound like it makes a lot of sense! Though why couldn't we have something like "npm fund", maybe "npm license --commercial", which would just give a

This does sound like it makes a lot of sense! Though why couldn't we have something like "npm fund", maybe "npm license --commercial", which would just give a summary of everything that you have to pay for in the list of current project dependencies, if you want to use the packages for commercial use? Just curious about the pros and cons of solving this at the package manager level, since handling licensing there would probably be easier, than creating external orgs for that? Who knows, maybe just a Stripe integration with the particular company behind distributing the funds down the line would be sufficient, maybe with package.license that could be the equivalent for package.lock within the projects being generated then? For example, if you look at the Unity game engine, they have their own Unity Asset Store, which is tightly integrated with the rest of the platform and actually makes commercial packages viable, since everything is so easy to do! So much so, that in the game development community, "asset flip" has become a term to describe a surprisingly common (yet detrimental) approach to development, where someone makes a game almost entirely out of these packages and tries to sell it. With how most of the web development (and other types too) projects, both front end (Angular, Vue, React, Svelte etc.) and back end (Spring, Django, Rails, Laravel, ASP.NET Core etc.) rely on bunches of external dependencies, i fail to see why things should be any different there.