Migrate this repo to FINOS

[ColinEberhardt]

This project is being contributed to FINOS. This issue tracks the various tasks around this move.

Steps required for the move to FINOS:

• Gain approval from the Hadouken PMC
• Change from MIT to Apache 2 licence
• Add NOTICE file, see template on https://github.com/finos/project-blueprint
• Move this repo to the FINOS organisation (github.com/finos)
• Add CONTRIBUTING.md, see template on https://github.com/finos/project-blueprint/blob/master/.github/CONTRIBUTING.md
• Add Roadmap and Contributing sections in README.md, see template on https://github.com/finos/project-blueprint/blob/master/README.template.md
• Add node-license-validator as Circle CI build step (check commands on https://finosfoundation.atlassian.net/browse/CONTRIB-57)
• Enable WhiteSource bot by adding .whitesource file in the repo root folder, see https://github.com/finos/project-blueprint/blob/master/.whitesource
• Potentially list openfin-react-hooks into https://www.npmjs.com/org/finos ; by setting the package scope to @finos
• Add FINOS badge to the repo (have we fulfilled the requirements for this to be classified as an 'active' project?)

[ColinEberhardt]

@maoo can you please provide some guidance around how license validation should be run as part of the CI process? I executed the commands at linked in CONTRIB-57, but see many failures:

> npx node-license-validator . --allow-licenses MIT Apache-2.0
Warning: dependency "react" probably not installed.
please install dependencies from npm before running nlf
Warning: dependency "react" probably not installed.
please install dependencies from npm before running nlf
Identified licenses: (MIT OR CC0-1.0), Apache-2.0, BSD, [BSD, BSD-2-Clause], [BSD, BSD-3-Clause], [BSD, ISC], CC-BY-3.0, CC0-1.0, ISC, MIT
Invalid license: cliui@3.2.0: ISC
Invalid license: dezalgo@1.0.3: ISC
Invalid license: diff@3.5.0: BSD, BSD-3-Clause
Invalid license: esprima@4.0.1: BSD, BSD-2-Clause
Invalid license: esutils@2.0.2: BSD
Invalid license: glob@7.1.4: ISC
Invalid license: graceful-fs@4.2.2: ISC
Invalid license: hosted-git-info@2.7.1: ISC
Invalid license: inflight@1.0.6: ISC
Invalid license: inherits@2.0.3: ISC
Invalid license: isexe@2.0.0: ISC
Invalid license: minimatch@3.0.4: ISC
Invalid license: normalize-package-data@2.5.0: BSD, BSD-2-Clause
Invalid license: npm-package-arg@4.2.1: ISC
Invalid license: once@1.4.0: ISC
Invalid license: read-installed@4.0.3: ISC
Invalid license: read-package-json@2.1.0: ISC
Invalid license: readdir-scoped-modules@1.1.0: ISC
Invalid license: semver@5.7.0: ISC
Invalid license: signal-exit@3.0.2: ISC
Invalid license: slide@1.1.6: ISC
Invalid license: spdx-exceptions@2.2.0: CC-BY-3.0
Invalid license: spdx-license-ids@3.0.4: CC0-1.0
Invalid license: sprintf-js@1.0.3: BSD, BSD-3-Clause
Invalid license: which@1.3.1: BSD, ISC
Invalid license: wrappy@1.0.2: ISC
Invalid license: y18n@3.2.1: ISC

[maoo]

Depending on the build stage, the project may already be installed also with build dependencies, therefore the license validator will also take those in consideration. I see spdx-license-ids mentioned in the list, which is normally pulled at build time.

Please try with:

npm clean
npm install --prod
npx node-license-validator . --allow-licenses MIT Apache-2.0

Alternatively, we can "whitelist" all build-time dependencies using (for example) --allow-packages spdx-license-ids spdx-exceptions , but IMO this would be harder to maintain.

HTH!

[ColinEberhardt]

Thanks @maoo that worked.

The demo project includes quite a few additional licenses, for reference these are as follows:

MIT Apache-2.0 BSD-2-Clause BSD-3-Clause ISC

Do these need to be validated as well? And are the above acceptable?

[maoo]

Do these need to be validated as well? And are the above acceptable?

All these licenses are acceptable, as they're labelled as "Category A" licenses, see https://finosfoundation.atlassian.net/wiki/spaces/FINOS/pages/75530375/Contribution+Compliance+Requirements#ContributionComplianceRequirements-Identifyingacceptablelicenses

Feel free to add them into the command, as long as they are listed as Category A. For "Category B" licenses, it's probably better to use allow-packages, instead of whitelisting all packages, given that these licenses normally require changes to the NOTICE file too.

[ColinEberhardt]

@maoo are you happy for us to move this repo into the FINOS org now?

[maoo]

@ColinEberhardt , the contribution criteria expect that code is clean from high and critical CVEs at any time, so I'd like to enable an ongoing CVE scanning before moving forward; we don't have to start with WhiteSource, given that we're discussing - on a separate thread - how we simplify the bot configuration. But adding an npm audit command in the CircleCI build would already be a good start to ensure that no CVEs are shipped with the code; happy to help defining the build step.

What about migrating the npmjs package? Do you want to use the @finos scope for future releases, and therefore instruct all consumers to update their coordinates? Do you prefer to redirect the previous npmjs package to the new package coordinates? Or to use npm-deprecate?

I'd suggest to address these 2 topics prior to the repo move, to make sure that consumers have a clear understanding of what is going to change after this migration.

Thanks!