Licensing issues with big amount of production dependencies

Summary

It’s quite hard to find out which Dependencies are actually bundled and shipped with a Gatsby App.

I have the issue, that some (nested) dependencies of gatsby-cli seem to be published under licenses that might be critical for a commercial app (Copyleft).

I’m aware that Gatsby is a generator. But I’m wondering if it’s possible to differ between some kind of "Gatsby Core" (shipped as part of a bundled App) and gatsby-cli. Both published as separate packages. That would allow to list gatsby-cli as devDependency. The current gatsby package could still bundle "Gatsby Core" and gatsby-cli to prevent breaking anything.

[Purii]

Any updates @wardpeet ?

[Purii]

Hi @wardpeet!

Yes, you are right. Exactly these two parts (development server and build server) actually belong together. But gatsby-link is neither needed by the development server, nor by the build server, but part of the production bundle (output from development server and build server).

gatsby-link and gatsby-cli are not on the same level / type, but both are listed as dependencies of gatsby. To check for license compliance one need to know exactly which dependencies are eventually part of a production bundle and shipped to the customers.

I see three types of dependencies in the gatsby package:

• Development Dependencies (currently devDeps) to develop gatsby itself further, like eslint,…
• „Build“ Dependencies (currently deps) needed to develop a gatsby site and create a production bundle, like autoprefixer, gatsby-cli, @typescript/, dotenv,…
• Production Dependencies (currently deps) bundled as part of a gatsby app (which is created using the „build dependencies“), like gatsby-link, @reach/router,…

To separate these „Build Dependencies“ and „Production Dependencies“ I suggest to introduce a new package. To stay compatible the „Build dependencies“ can simply depend on the „Production dependencies“. Unfortunately I don’t know the internals, which dependencies the gatsby build process injects into the production bundle (like core-js).

-> QUESTION: Can you point me to the specific files? Then I can play around and possibly suggest a concrete solution.

Random Examples of Dependencies

• gatsby > gatsby-cli > gatsby-recipes > react-icons: Comes with a lot of different licenses, because of the included icons
• gatsby > gatsby-cli > gatsby-recipes > urql > wonka: Contains references to GPL licenses (/esy.lock/**)
• gatsby > webpack-dev-server > selfsigned > node-forge: Comes with a lot of different licenses (/LICENSE), like GPL

There are similar issues with some plugins, like gatsby-plugin-sharp: > imagemin-pngquant > pngquant: GPL. I guess for these issues I have to check each plugin individually and move that to the devDeps, if nothing gets bundled.

Sourcecode-map-explorer

Sourcecode-map-explorer is a great idea, but I guess by scanning the bundle we cannot be 100% sure to identify all bundled dependencies. Simply because they are bundled. The normal way to scan licenses is to traverse though the lock files (yarn.lock or package-json.lock) and then scan every single line of the dependency (deep scan). Unfortunately just scanning the license, which is declared in the package.json is not enough. Sometimes a dependency is dual licensed, or the declared package license is different from a license comment in the header of a single file deep in the package.