> Isn't dual licensing already somewhat popular? To me it seems like what's being proposed is a lot like a SaaS solution for handling the unpleasant legalese-heavy aspects of licensing software, but with some sort of a community weight behind it, or maybe i'm misreading this?
It's more than that. No sane company would pay for `colors` node package, because it would be such a burden compared to how such a ridiculously small part of their project. For the company to go through that legalese would cost more than recreating that package themselves.
The idea is that this company simply pays the NPM Foundation, and gets commercial licensing access to all packages in NPM with one single contract, and then NPM Foundation redistribute. (I'm saying NPM just as an example)
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.
I'm working on a solution that is along the lines of the "package.lock" method that you've mentioned. My solution involves defining payment plans in code:
It's more than that. No sane company would pay for `colors` node package, because it would be such a burden compared to how such a ridiculously small part of their project. For the company to go through that legalese would cost more than recreating that package themselves.
The idea is that this company simply pays the NPM Foundation, and gets commercial licensing access to all packages in NPM with one single contract, and then NPM Foundation redistribute. (I'm saying NPM just as an example)