5

I am trying to understand the general clause contained in most licenses that reads as follows

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

The majority of the libraries in use are MIT and BSD. There are some additional packages with other licenses which I have explicitly documented.

In the documentation of the project do I need to individually reference each packages license in my package.json file or am I covered by just allowing NPM to download the licenses contained in the packages own repositories when the user goes to build the project?

There are three embedded libraries which are redistributed with the library, those licenses I have explicit copies of in my documentation. The libraries in use that are imported by NPM are the ones I am not sure about how to properly follow the licenses. They are used in their 'binary' form in one way or another.

2
  • 1
    Is this for a product or project you redistribute WITH these deps bundled? Or just some app that you build and requires these deps to be installed too? Commented Jan 31, 2017 at 21:31
  • 1
    There are three embedded libraries which are redistributed with the library, those licenses I have explicit copies of in my documentation. The libraries in use that are imported by NPM are the ones I am not sure about how to properly follow the licenses. They are used in their 'binary' form in one way or another.
    – Ilvenis
    Commented Feb 1, 2017 at 14:35

1 Answer 1

3

The theory is that if you redistribute all the deps (and least for all embedded deps) then you would be responsible to comply with their license (including attribution, etc). And this is for all the direct deps and deps of deps, all the way down.

Now for the deps you do not distribute but would be installed by a user of yours at build time, you do not need to attribute... Yet I suggest providing some high level information for these anyway.

The rationale is that it would be best if you provide the least possible surprise to your users:

Say your project is GPL-licensed and somewhere down the dependency chain is a package that is not GPL-compatible...

The same applies if your package is under a permissive MIT-style license and somewhere down the dependency chain is a package that is GPL-licensed, eventually impacting the whole chain with its copyleft.

In both cases as a user I would like to be informed by you about what I am getting with your project. It does not have to be detailed but at least list the few components if any that would have significantly different licensing: e.g copyleft or limited copyleft if permissive, non-copyleft compatible if copyleft, etc.

As an example of a minimalist and useful documentation of third-party deps, openstack provides their Python requirements files with license comments. These files are more or less the equivalent of the deps section in a package.json and in this case they "resolve" them at full depth first (with a pip freeze-like command).

I could imagine an npm-shrinkwrap or yarn.lock file with similar comments or attributes for an NPM deps tree.

As a side note you could use my scancode-toolkit to help collect the license information of your deps.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.