Licence workflow automation

[oleersoy]

Cross referencing:
suitcss/base#22

[oleersoy]

Or is there something simple already in place for this?

[oleersoy]

Perhaps it's best to read the license of each direct and transitive dependency and construct a license header containing all of them. Thoughts?

[simonsmith]

If it exists in each repo what is the requirement for adding to the style sheet too?

[oleersoy]

I'm assuming a workflow like:

1. Declare 10 css dependencies (utils-size, non-suit-component1, NSC-2, etc.)
2. Run them through a build resulting in a single optimized CSS file.

This could result in more than 10 different CSS packages being imported, due to transitive dependencies (With the potential of all of them having different licenses), so when the build is done, how do we guarantee that the licenses for each of the individual CSS repositories are reflected in the built file?

I think the easiest thing to do, which does not place any additional requirement on the package maintainer, is to read the package.json license attribute for each css dependency and construct a header containing the specific license information of each file. It would look something like:

/*! 
normalize.css v3.0.3 | MIT License | github.com/necolas/normalize.css 
base.css v1.0.3 | MIT License | github.com/necolas/normalize.css 
custom-component.css v1.0.0 | Apache License 2.0 | github.com/bigpimpin/custom-component.css
custom-component-transitive-dependency.css v1.0.0 | GPL | github.com/alig/custom-component-transitive-dependency.css
*/

When the single optimized CSS file is built, the license header would be inserted at the top using something like gulp-header.

[frekyll]

@oleersoy @simonsmith This is a cool idea, but seems unnecessary. The only library dependency that's built into core is normalize.css. If core were to pull in any other dependency, we'd just have to make sure their license allowed it to be distributed under the SUIT CSS license.

[oleersoy]

@frekyll I'm assuming a larger eco system of components, utilities, etc. Lets just say that boo publishes a component and foo declares it as an NPM dependency and it becomes part of the css that foo deploys.