DEV Community

Discussion on: A System for Sustainable FOSS

Collapse
 
simonua profile image
Simon Kurtz

At least gulp but also all its gulp plugins that can be used. I originally thought that I would still need to have awareness of license types for all dependent packages, too, but rereading your post makes it clearer to me that that should be abstracted enough. I wonder where the ultimate responsibility lies if a package has a dependency but does not honor its license or payment model correctly. Is only the package at fault or also my organization for including (and possibly paying) this package while satisfying its but perhaps not its dependent's licenses? That's what made me worry about my large amount of dependencies originally.

As a believer in markets typically finding and providing good solutions, I wholeheartedly agree with you that tooling will improve to satisfy both provider and consumer of these products.

Thread Thread
 
simonua profile image
Simon Kurtz

From an ease-of-use perspective, I suspect that one avenue would simply be a subscription model through a registry. You could have registries such as npm compete with other registries similarly to how music and video subscriptions are done. Reducing barriers of entry for consumers is key to choosing services. If an organization was charged X per month or year to have unlimited downloads of packages, that would be a much easier pill to swallow than dealing with individual licensing requirements on a per package or per author basis. With that would come the expectation that service providers a) pay out their package authors / contributors appropriately, and b) some assurances that packages are safe, curated, inspected, etc.